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,

Kernite

The XST PDF from Xilinx shows examples of 1,2 and 3 process FSMs (oddly enough only one of two variants of the 2 process). It's in part a Mealy-Moore issue and large part personal preference or rote learning. Those with an analytical bent might pay attention to the implications of the elements present in sensitivity lists. – Coelenterate

@DavidKoontz What would be the 2nd variant of the 2-process FSM? One process for the state register and another process for everything else? – Sophister

The XST pdf is a nice reference, thank you. @DavidKoontz – Kernite

XST can be found at XST User Guide UG627 v12.4, and the relevant section is "FSM HDL Coding Techniques" on page 217. – Porterfield

just a note about the update of the sensitity list: The editior (emacs, eclipse, ..) should take care of that. IMHO – Voltaism

Peter Chambers document 'The Ten Commandments of Excellent Design' (ic.unicamp.br/~cortes/mc542/10_1.pdf) has some nice thoughts about the topic. – Voltaism

Peter Chambers's doc is a very nice design reference, thanks @vermaete. I don't think I get the direct relationship between the doc and the number of processes, though. It would seem that by Peter's guidelines either a 1-, 2-, or 3-process FSM would be ok, as long as the outputs are registered. Am I missing something here? – Kernite

@VHDL Addict. I like this kind of coding a FSM in VHDL: opencores.org/… Although probably not the most efficient way (speed and area). Team members with limited knowledge of VHDL can still read, understand, debug and modify it. – Voltaism

Thanks for the pointer @vermaete. If I understand correctly, this is a 2-process FSM, with unregistered outputs. One process generates the next state logic and the outputs, and the other process is the state register. An interesting difference in this particular example is that the reset logic comes last, reducing one level of indentation. I had never thought of that! – Kernite

Answer 1

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.

Golf

Green, Christian, "Analyzing and implementing SDRAM and SGRAM controllers," EDN, Feb 2, 1998, pg 155: edn.com/… – Plenum

Answer 2

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.

Tumor

Answer 3

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.

Ander

A three process statemachine is like drawing the bubble diagram twice - once for the present state next state logic and once for the output logic. I find the disassociation of the present state next state logic and output logic harder to track what is going on. – Ectophyte