Types of finites state machine in FPGA design

Question

There are 2 types of FSM:

1- block of combinational logic + clocked block that hold only the current state

2- clocked block

For example, if we take a look to how an SDRAM controller is made, most of the controllers are composed by combinational block + clocked block, and only just a few of them are written using just one clocked block.

-What are the main considerations to choose one type or another?

-Regarding to the SDRAM controller, why most of the people choose the first type?

Thanks in advance!

Answer 1

There are 2 types of FSM:

The two types of FSM are Mealy machines and Moore machines.

In a Mealy machine, the output is a function of the inputs and the current state. In a Moore machine, the output is purely a function of the current state.

^{simulate this circuit – Schematic created using CircuitLab}

The types of FSMs you're trying to describe in your question are a little unclear. It sounds as though you are referring to two ways of structuring a FSM in a hardware description language. These don't correspond to different types of FSMs; they're simply differences in coding style. Neither one is inherently better.

Answer 2

There are generally two types of state machines - one where the outputs are only a function of the current state (Moore-style), and one where the outputs are a function of the current state and the inputs to the state machine(Mealy-style).

In either case, there is combinational logic that determines the next state and the outputs. Then there is sequential logic representing the "state" registers. Some people prefer to model these in separate blocks for clarity.

You can always model both FSM styles with two blocks, but you cannot model the Mealy-style with one block - the input values used for the output logic will be a clock cycle behind. Since FSMs wind up being a mixture of the two styles, it's safer to model them with two blocks.

Answer 3

This paper by Clifford Cummings goes into a detailed comparison of the advantages/disadvantages of a two always block (with a clocked block and a separate combinatorial block, "1-" on your list) compared to a single always block ("2-" on your list).

The main advantages of the two always block coding style are:

1. fewer lines of code, especially for large state machines
   1. (less repetition)
   2. also generally smaller diffs for ECOs to fix bugs
2. better timing/area

The main disadvantage is:

1. your state machine code is now split over two always blocks, instead of being in just one place.

At first, it seems kind of counter-intuitive that the two-always-block style would have fewer lines of code, since it is split over two separate always blocks. The main reason is there is less repetition by having to specify the outputs of the current state only once. With the one-always-block coding style, the output assignments must be made for every transition arc to the state, leading to more repetition. (Also, it can be less intuitive to think "when I transition to this next state, the output values should be..." instead of "in this state, the output values should be").

Read the paper for a more detailed comparison (53 pages), including the code used for each FSM coding style. Some of the code is slightly dated (the paper is from 2003), and a lot more synthesizers now do support the constructs in section 10.0 "SystemVerilog enhancements" such as using enums for the states, and always_comb/always_ff.

With regards to the timing/area argument, a sufficiently advanced FSM synthesizer should give very similar timing/area for the different coding styles, although it might be easier for a synthesizer to infer a more efficient FSM implementation using the two-always-block style. This may be relevant for your example of an SDRAM controller, although I wouldn't personally consider it to be a deciding factor for how to code FSMs.

See also the question here for more advantages/disadvantages.

Answer 4

Perhaps I'm a bit too practically-minded - to me there are two types of state machines:

• those that do what you want them to
• those that don't

Any other differentiation is of merely academic interest.

I write them the same as I write all my logic - inside a single clocked process which describes the functionality that I need.