--- 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.
Honored Contributor
