What FSM should I use ?

[Mike Treseler]

I usually don't separate related counters, shifters, etc. from a
controlling state machine, preferring to code them in one process.

I agree.
I put everything that uses an
enumerated value in the same process
that creates it. If it's
too unrelated to be there, I move it
to another entity.

However, I prefer to use separate processes for separate
state machines, if for no other reason than to avoid combinatorial
control loops between them.

I don't follow the "combinational" part,
but this is really a matter of style.
Nests of wires or nests of procedures.
It's all about updating registers.
A bad count is no better than a bad state.

I prefer to concatenate CASE and IF
expressions sequentially in the same process.
If they get too big, I declare a procedure
and call it from below. Enumerated types
themselves provide some protection against
poor typing.

That's where I most commonly use flags
instead of direct state decoding in the other state machine.

With a single threaded description,
I can already see the upstream variable assignments.

Even in a single process entity, one can use blocks around chunks of
sequential code, with an enclosed declarative region to define local
variables, visible only within that block.

If I need "protection" I declare
a common subprogram inside the main procedure scope.
I have gone nuts trying to use blocks for this.

I prefer not to have to use entities to hide implementation details,
especially when lightweight processes with variables can give me the
same benefits with less code. Entities tend to be on more structural
boundaries in my designs.

I agree. I see it as a test boundary.
That's the size limit for me.
I like to put all my signals in
a top entity of instances and port maps.
In the functional entities, I use port references only.
I like the compile time checking I get
from the IN and OUT port directions.

But if all of us designed alike, it'd be an awfully boring world.

Indeed.

-- Mike Treseler

 

[Jim Lewis]

KJ

Mike Tressler would disagree with this statement for sure. You can use
variables and create combinatorial outputs. Personally I don't use this
technique but it does work.

Show me one.

That's some bum advice. I'll accept that some people for whatever reasons
prefer the two process approach (and maybe three who knows) but the one
process approach is superior from the standpoint of designer productivity.
I contend that the new person starting out would end up being more
productive (i.e. working and tested lines of code per time period) with the
one process approach because of the two fundamental drawbacks I mentioned
earlier regarding the two process approach (more code and manual checks).

If you are not disciplined, whether you are creating hardware or
software, your code will be plagued with problems.

I am most productive when I adopt something that suits my
thought process and design style (as opposed to coding style).
I don't spend much time on design entry. If you do,
I recommend taking a typing class.

A two (or three) process statemachine does require discipline.
1) Check your sensitivity list.
2) Initialize all outputs to a default value before the case statement.

If you don't do #2 in your one process statemachine, and you have more
than one output and two states, your code will be much longer than mine
- even counting the "extra" process I use for the state register.

WRT #1, as soon as vendors adopt Accellera VHDL-2006, you can replace
the items in your sensitivity list with the key word "all".

So with the above methodology, making a mistake in a two process
is no more likely than making a mistake in a one process.

Going further, productivity is finishing. Finishing requires a
working simulation and a design that meets area, timing, and power
goals. I find it easiest do this by keeping objects separate.
This helps isolate any issues that may crop up. Also for people
who are hardware centric, it keeps all of the blocks in a hardware
block diagram in separate processes.

My style may not suit your thought process, so by all means, do
what makes you successful and productive.

And I agree, you have to try out methodologies to fully understand them.

I have been through enough projects with enough other personalities
to come to understand that some design and coding styles just plain
don't work for some people.

I'm betting that this ... Clear thinkers can write clearly.

Not everyone is a clear thinker - including those who are
tasked to maintain a simple one process statemachine.


Cheers,
Jim

 

[Jan Decaluwe]

I usually don't separate related counters, shifters, etc. from a
controlling state machine, preferring to code them in one process.
Rather than setting a flag in a given state that tells another chunk of
code to increment the counter, I just increment the counter from within
the state.

I believe this is the crucial point about the single process paradigm:
it makes it natural to move beyond FSMs towards FSMDs (FSM with data
operations), unlike the two process paradigm.

Consider two very common hardware elements: FSMs and counters.
Note how the single vs two process debate only shows up for FSMs. On the
other hand, even die-hard hardware thinkers find it natural to code
a counter in a single clocked process. Consequently, combining the two
is natural for the first camp, but not for the second.

I believe that the FSMD paradigm realizes the true potential of RTL design,
and that the difference with other paradigms is rather dramatic.

Recently I have carried out a small experiment that everybody can review.
The example is the 'stopwatch' in the 'ISEExamples' directory in the free
Xilinx Webpack distrbution. Review the Verilog or VHDL code and compare
it to the code on my web page here:

http://myhdl.jandecaluwe.com/doku.php/cookbook:stopwatch#top_level_design

Note that the controlling logic was so simple that I didn't even bother
to create a state machine - just some state variables. As as sidenote, note
also that the 'counting' variable is both registered and used combinatorially.

For the curious, the page contains much more info, including synthesis logs.

Jan