What FSM should I use ?

[KJ]

"Mike Treseler" <mike_treseler@comcast.net> wrote in message
news:51fcr8F1jduk9U1@mid.individual.net...

KJ wrote:

Why? An entity/architecture is (or should be) implementing a specific
function and everything should be pulling together to implement this and
creating a new signal as a flag to indicate when you're in a state gives
opportunities to be less than clear. For example, using your approach
the
process that needs to know when you're in a specific state would have
code
something like...

if (Were_In_The_Important_State = '1') then
....
whereas if the state variable is available throughout the
entity/architecture it would be
if (Current_State = The_Important_State) then ...

In a single process entity, all variables
including state variables *are* available everywhere.
It can't be simpler than that.

-- Mike Treseler

Replace 'variable' with 'signal' and the same statement regarding scope pops
out....and typing 'signal' takes 2 fewer keystrokes than 'variable'.

Kevin Jennings

 

[Jim Lewis]

KJ

With one process all output of the process are registered.

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.

In the end all techniques seem to produce reasonable results.
So find the one that suits you.
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 don't like one process as it does not work well for all
people. I have worked on projects where someone inherited
a one process statemachine and was unable to effectively
maintain it. As a result it was an issue.
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]

Andy wrote:

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

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
From Python to silicon:
http://myhdl.jandecaluwe.com