8

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,

VHDL Addict
  • 171
  • 1
  • 10
  • 2
    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. –  Oct 28 '14 at 21:55
  • @DavidKoontz What would be the 2nd variant of the 2-process FSM? One process for the state register and another process for everything else? – rick Oct 28 '14 at 22:24
  • The XST pdf is a nice reference, thank you. @DavidKoontz – VHDL Addict Oct 28 '14 at 22:31
  • XST can be found at [XST User Guide UG627 v12.4](http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_1/xst.pdf), and the relevant section is "FSM HDL Coding Techniques" on page 217. – Morten Zilmer Oct 29 '14 at 05:09
  • just a note about the update of the sensitity list: The editior (emacs, eclipse, ..) should take care of that. IMHO – vermaete Oct 29 '14 at 07:47
  • Peter Chambers document 'The Ten Commandments of Excellent Design' (http://www.ic.unicamp.br/~cortes/mc542/10_1.pdf) has some nice thoughts about the topic. – vermaete Oct 29 '14 at 07:52
  • 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? – VHDL Addict Oct 30 '14 at 09:26
  • @VHDL Addict. I like this kind of coding a FSM in VHDL: http://opencores.org/websvn,filedetails?repname=spacewire_light&path=%2Fspacewire_light%2Ftrunk%2Frtl%2Fvhdl%2Fspwstream.vhd 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. – vermaete Oct 30 '14 at 09:51
  • 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! – VHDL Addict Oct 30 '14 at 10:00

2 Answers2

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:

FSM enter image description here

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.

eta32carinae
  • 473
  • 4
  • 12
  • Green, Christian, "Analyzing and implementing SDRAM and SGRAM controllers," EDN, Feb 2, 1998, pg 155: https://www.edn.com/02-02-98-analyzing-and-implementing-sdram-and-sgram-controllers/ – tim Feb 25 '20 at 21:48
0

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.
ThomasD
  • 71
  • 1
  • 3