What does 1-, 2-, or 3-process mean for an FSM in VHDL?

Question

It seems like there is quite some debate about how to code finite state machines (FSMs) in VHDL. People talk about 1-process, 2-process, or 3-process FSMs as if everyone knew exactly what it means and what each process does. However, I've been unable to find a precise definition, and the examples that exist seem to be contradictory.

This is an objective question: What is the difference in terms of code for each FSM style (1-process, 2-process, 3-process)? I understand that there is a component of personal preference, but certainly it is possible to answer the question objectively and list the advantages of each approach.

Thanks,

Answer 1

The correct answer is that you do not need any processes at all. The best FSM code has zero processes. Every FSM has three parts: storage, next state logic, and output logic. All of those are best described in VHDL using concurrent statements. VHDL = Very high speed integrated circuit HARDWARE DESCRIPTION Language.

The goal is to describe hardware, not to write algorithms. You can describe hardware directly with concurrent statements, or go off in the weeds and describe it using processes. If you really understand the language, then you will never use a process. Your code will be more concise, easier to read, easier to debug, and easier to maintain.

Using processes in VHDL is similar to using inline assembly in C. If you understand the language, then you can specify what you want directly, writing code that uses fewer resources with fewer lines of code.

However, learning to write elegant VHDL code means that you have to wrap your brain around the concept of declarative programming. That is something that takes practice, so most people stick with the imperative style of processes.

Answer 2

As a comment to the answer by Thomas D of July 30, 2021: Three-process state machines divide

1 Register assignment

2 Next state logic

3 State output logic

They can be used to create both Moore- and Mealy-type state machines. Three process state machines are generally easy to check if they match diagrams used to specify FSM behavior. If you find it hard to find where each part is situated, modularity should be revised.

If you combine 2 and 3 you have a two-process state machine. The upside of dividing into three is that it is very easy to debug, since there is no interference between next-state logic and sorting when to activate output.

If you combine 1 with 2 and 3, you have a 1-process state machine. It is technically possible to create any logic this way. Using a single process yields shorter code, but it is error prone as it tends to hide away logic that leads to extra registers (without giving any warning), where a 2- or 3-process solution would normally yield a compiler warning when poor logic is constructed. The complexity of a single process structure also take more time to debug by reading.

Using single process FSMs to avoid creating latches is an active choice in not bothering to address the issue of poor design methodology.

Using three processes (or three -statement when there is little decoding) is a choice of making clear distinction in code functionality and thus prioritizing verifiability over code length. It does often lead to fewer reiterations after simulation which tend to speed up the design process as a whole.

Answer 3

I am only aware of the one and two process state machine designs as shown in the answer by eta32carinae. However as an older experienced electronic engineer I have to say that experience tends to push you toward the single process solution (as preferred by SW engineers). In my experience it is only graduates and academics that use a multiprocess FSM style.

Multi process FSM implementations suffer from several problems, the main ones being:

1. It is very easy to accidentally infer a latch in your design. You almost never want that.
2. Distribution of logic across processes makes it harder to keep track of what is going on which makes the code harder to understand, debug, and maintain. This is super important because you will be back to fix or modify your code at some point in the future, or worse some other poor developer will have to do it.
3. It is easy to get a Mealy machine when you generally want a Moore machine. If you need a Mealy machine, have a separate combinatorial process for the Mealy signals to highlight this fact as Mealy machines can lead unforseen timing closure problems.

Answer 4

As far as I know, there are 4 types of FSM. Mealy, Moore, Medvedev, and registered output. In registered output, you can have up to 4 processes (you can find an example here). In Medvedev, there can be 1 or 2. In others, there can be 1 or 2 processes for the state-machine, and 1 process for output that can be merged with the combinational process.

Suppose this FSM:

One-Process FSM VHDL code for that would be:

FSM_FF: process (CLK, RESET)
begin
    if RESET='1' then
        STATE <= START;
    elsif CLK'event and CLK='1' then
        case STATE is
        when START =>
            if X=GO_MID then
                STATE <= MIDDLE;
            end if;
        when MIDDLE =>
            if X=GO_STOP then
                STATE <= STOP;
            end if;
        when STOP =>
            if X=GO_START then
                STATE <= START;
            end if;
        when others => STATE <= START;
        end case;
    end if;
end process FSM_FF;

Two-Process FSM VHDL code:

FSM_LOGIC: process( STATE, X)
begin
    case STATE is
    when START =>
        if X=GO_MID then
            NEXT_STATE <= MIDDLE;
        end if ;
    when MIDDLE =>
        ...
    when others => NEXT_STATE <= START;
    end case;
end process FSM_LOGIC;
---------------------------------------------
FSM_FF: process(CLK, RESET)
begin
    if RESET='1' then
        STATE <= START;
    elsif CLK'event and CLK='1' then
        STATE <= NEXT_STATE;
    end if;
end process FSM_FF;

WHICH ONE SHOULD YOU USE?

According to Jensen,

It depends on a number of things. Do you need a Moore machine or a Mealy machine? Is the downstream logic that received the output signal synchronous or combinatorial? It also depends on which style of coding you prefer.

Prof. Saheb Zamani compared the 1-Process and 2-Process from three aspects (slide 86):

• Structure and Readability: From the hardware perspective, combinational and sequential elements are two different things, so a separated design is closer to hardware. On the other side, the graphical FSM (without output equations) resembles more a 1 process than a 2 process description.
• Simulation: Error detection easier with two state processes due to access to intermediate signals.
• Synthesis: 2 state processes can lead to smaller generic netlist and therefore to better synthesis results (depends on synthesizer but in general, it is closer to hardware)

P.S. I couldn't find the original sources for these links, so I just added the sources that I used. But this one is more comprehensive and includes some examples as well.