One segment vs two segment State Machine style

I don't think the book claim is worth it. separating logic from registers is already the very structure of FPGA.

Resource depends on your design and in this case you have added extra counter for the two segment case.

I normally use one clocked process for any state machine, clean, timing safe,no latches and readable at the expense of extra registers.

Thanks for reply.

By author opinion, two-segments style is better way for optimization of combinational logic by analysis&syntesis module, because it is separated from registers. And It`s seems to be true. If it is, by such reorganization of code, we can get some additional le for other blocks. My attempts has no positive results, but may be anybody has them.

Counters in two-segment and one-segment code are the same, I use it for waiting for the end of external process in my project. So I added it to my example.

--- Quote Start ---

Thanks for reply.

By author opinion, two-segments style is better way for optimization of combinational logic by analysis&syntesis module, because it is separated from registers. And It`s seems to be true. If it is, by such reorganization of code, we can get some additional le for other blocks. My attempts has no positive results, but may be anybody has them.

Counters in two-segment and one-segment code are the same, I use it for waiting for the end of external process in my project. So I added it to my example.

--- Quote End ---

What really matters is your design. after all it is all registers and logic that you ask for whichever way. The state machine is just an old design concept or methodology that translates to registers and logic. For example a two states machine(s1,s2) may end up as two registers(s1,s2). You might equally just use explicit registers:

if s1,s2 = 00 then s1,s2 <= 01 ..etc (in fact a counter is same). any other logic can be tied up to these registers e.g. if s1,s2 = 11 then...

so in short, it is just a way to clear the mind about the design and I don't see any evidence of better or worse resource.

Functional equivalent designs can be expected to give identical or at least almost equal gate level implementation.

The shown examples are functionally different in two regards:

- outp is registered in the single process style FSM and combinational in the "two segment" FSM

- count works different, resulting in 3 versus 4 counter bits

The resource count is different by only one 1 LE in Cyclone 3/4

Choosing one or the other style for resource usage efficiency makes no sense.

Personally I prefer single process style for this reasons

- visual representation of FSM behaviour, particularly with additional registered signals, may be internal signals like counters or design outputs

- no risk of unintentional latch generation by lack of attention

- FSM outputs are automatically registered as usually wanted

The two-process FSM has the advantage of being able to generate 'combinatorial' outputs which are often necessary, e.g. for the 'valid' and 'ready' signals in ST-modules. In the case of a single-process FSM you still have to maintain a second (combinatorial) process to generate this kind of outputs. As you now have to 'copy' some of the transition rules over from the synchronous FSM, you end up with two separate processes which can generate a harder debugging chore than weeding out the latches (which Quartus II warns you about).

I personally use two-process FSMs 9 times out of 10. I almost never use embedded counters in the FSM but instantiate external components, this produces nicer RTL diagrams.

I once spent a lazy Sunday afternoon writing up a contrived example to test this. See the attached .qar.zip.

The results are (for Cyclone IV E, auto device):

style

les

registers

mhz

Two-Process

44

17

386

Synchronous

46

17

378

Hybrid

36

16

380

Hybrid JosyB

35

16

380

Note that the example doesn't have combinatorial outputs.

Many thanks for helpfull answers.

It's a pity, but I'll continue to use one-segment and will try to find other ways of optimization.

--- Quote Start ---

See the attached .qar.zip.

--- Quote End ---

Can you reattach it or send to giggsoff@gmail.com? Thank you in advance.

Hi all, according to josyb, two-segmented style is better.

But FvM and kaz prefer one-segmented style.

Also on this handbook - recommended hdl coding styles (http://www.altera.com/literature/hb/qts/qts_qii51007.pdf) in State Machines chapter (page 61)

I found recommendation - "Separate the state machine logic from all arithmetic functions and data paths,

including assigning output values."

So however what is the right way? I currently use one-segmented style, but facing near 95% logic usage is interested in variants of better area utilization.

--- Quote Start ---

Usually this is the 1 process style.

--- Quote End ---

There is no proof that the 1-process style would deliver better comments or be easier to understand.

Neither do I claim superiority of the two-process. It just works better for me as most of the times I need combinatorial outputs from the FSM, in which case one always ends up with 2 processes no matter what style one started with. Generating the combinatorial outputs in a 2-process FSM is much more 'natural' than maintaining a separate process where you have to duplicate conditions from the 1-process FSM. I use Sigasi HDT to edit my VHDL work, it has templates so it inserts both processes (with default statements etc) in a few keystrokes.

@vanDNK: FSMs are most likely not dominant on LE-resource usage. Except when you instantiate a large 2D or 3D array of them :)

--- Quote Start ---

- visual representation of FSM behaviour, particularly with additional registered signals, may be internal signals like counters or design outputs

--- Quote End ---

Beauty lies in the eye of the beholder. If you mix the datapath and counters etc inside the 1-process FSM visibility is rather lost then gained.

--- Quote Start ---

- no risk of unintentional latch generation by lack of attention

--- Quote End ---

Quartus II will warn you about this. If you get too many warnings because of using Altera's IP, you can promote the 'Latch' warning to throw an error.

--- Quote Start ---

- FSM outputs are automatically registered as usually wanted

--- Quote End ---

This is not always the case, especially for ST modules the ready and valid signals are (at least in my work) combinatorial.

Come another lazy Sunday afternoon, I'll work out a better representative comparison.

Thanks for your answers, Tricky and josyb!

Waiting for josyb's another lazy afternoon)