Why not a two-process state machine in VHDL?

Question

When I learnt how to express finite state machines in VHDL, it was with a two-process architecture. One process handles the clock/reset signals, and another handles the combinatorial logic of updating the state and output. An example is below.

I've seen this style criticised (see the comments and answer to this question for example), but never in any detail. I'd like to know whether there are objective(ish) reasons behind this.

Are there technical reasons to avoid this style? Xilinx' synthesiser seems to detect it as a state machine (you can see it in the output, and verify the transitions), but do others struggle with it, or generate poor quality implementations?

Is it just not idiomatic VHDL? Remember to avoid opinion-based answers; if it's not idiomatic, is there a widely used teaching resource or reference that uses a different style? Idiomatic styles can also exist because, eg. there are classes of mistakes that are easy to catch with the right style, or because the code structure can better express the problem domain, or for other reasons.

(Please note that I'm not asking for a definition or demonstration of the different styles, I want to know if there are objective reasons to specifically avoid the two-process implementation.)

Example

Some examples can be found in Free Range VHDL (p89). Here's a super simple example:

library ieee;
use ieee.std_logic_1164.all;

-- Moore state machine that transitions from IDLE to WAITING, WAITING
-- to READY, and then READY back to WAITING each time the input is
-- detected as on.
entity fsm is
    port(
        clk    : in std_logic;
        rst    : in std_logic;
        input  : in std_logic;
        output : out std_logic
    );
end entity fsm;

architecture fsm_arc of fsm is
    type state is (idle, waiting, ready);
    signal prev_state, next_state : state;
begin
    -- Synchronous/reset process: update state on clock edge and handle
    -- reset action.
    sync_proc: process(clk, rst)
    begin
        if (rst = '1') then
            prev_state <= idle;
        elsif (rising_edge(clk)) then
            prev_state <= next_state;
        end if;
    end process sync_proc;

    -- Combinatorial process: compute next state and output.
    comb_proc: process(prev_state, input)
    begin
        case prev_state is
            when idle =>
                output <= '0';
                if input = '1' then
                    next_state <= waiting;
                else
                    next_state <= idle;
                end if; 
            when waiting =>
                output <= '1';
                if input = '1' then
                    next_state <= ready;
                else
                    next_state <= waiting;
                end if;
            when ready =>
                output <= '0';
                if input = '1' then
                    next_state <= waiting;
                else
                    next_state <= ready;
                end if;
        end case;
    end process comb_proc;
end fsm_arc;

(Note that I don't have access to a synthesiser right now, so there might be some errors in it.)

Answer 1

I always recommend one-process state machines because it avoids two classes of basic errors that are exceedingly common with beginners:

1. Missing items in the combinational process's sensitivity list cause the simulation to misbehave. It even works in the lab since most synthesizers don't care about the sensitivity list.
2. Using one of the combinational results as an input instead of the registered version, causing unclocked loops or just long paths/skipped states.

Less importantly, the combinational process reduces simulation efficiency.

Less objectively, I find them easier to read and maintnain; they require less boiler plate and I don't have to keep the sensitivity list in sync with the logic.

Answer 2

The only two objective reasons I see are about readability and simulation efficiency in the case of Moore state machines (where primary outputs depend only on the current state, not the primary inputs).

Readability: if you merge together in a single process outputs and next state computations it might be more difficult to read / understand / maintain than with separate combinatorial processes for separate concerns.

Simulation efficiency: in the 2-processes solution your combinatorial process will be triggered on every primary input and / or current state change. This makes sense for the part of the process that computes the next state but not for the part that computes the outputs. The latter shall be triggered only on current state changes.