State machines

[sprocket]

Rookie question, but I can't see a clear answer:

State machines in text books and examples seem to be practically always
coded as two or three processes. Is the single- process model morally
dangerous in some subtle way? Is the three- process model just for
readability, or is there yet another subtlety involved?

As a many- years embedded C and assembler man painfully learning VHDL, I
find it hard to change the sequential programming thought processes to
an image of separate registers connected by knotted string...

JS

 

[Mike Treseler]

State machines in text books and examples seem to be practically always
coded as two or three processes. Is the single- process model morally
dangerous in some subtle way?

No.
An entire design will fit nicely
in a single process if you like.

Is the three- process model just for
readability, or is there yet another subtlety involved?
Tradition.

As a many- years embedded C and assembler man painfully learning VHDL, I
find it hard to change the sequential programming thought processes to
an image of separate registers connected by knotted string...

I agree. See my sequential examples here.
http://home.comcast.net/~mike_treseler/

-- Mike Treseler

 

[Pieter Hulshoff]

State machines in text books and examples seem to be practically always
coded as two or three processes. Is the single- process model morally
dangerous in some subtle way? Is the three- process model just for
readability, or is there yet another subtlety involved?

I am not sure what the 3 process setup is like, but I am familiar with the
separation of combinatorial logic and the clocked registering for an FSM.
Separating the two allows for easy switch between FF and RAM based design, where
it is also possible to reuse the same logic on a time slot base for multiple
channels. Having said that, I personally prefer the 1 process model as well if
I'm not designing with such specific switching in mind.

Regards,

Pieter Hulshoff

 

[Brian Drummond]

I am not sure what the 3 process setup is like, but I am familiar with the
separation of combinatorial logic and the clocked registering for an FSM.

The three process further decomposes the next-state generation and
output signal generation into two separate processes.

Having said that, I personally prefer the 1 process model as well if
I'm not designing with such specific switching in mind.

I'd cast another vote for the single process version.

- Brian

 

[Andy]

I am not sure what the 3 process setup is like, but I am familiar with the
separation of combinatorial logic and the clocked registering for an FSM.
Separating the two allows for easy switch between FF and RAM based design, where
it is also possible to reuse the same logic on a time slot base for multiple
channels. Having said that, I personally prefer the 1 process model as well if
I'm not designing with such specific switching in mind.

Regards,

Pieter Hulshoff

IIRC, in the early days of logic synthesis, storage (flip-flops) could
not be inferred, it had to be instantiated. However, combinatorial
logic was described in combinatorial processes, and necessarily was
separate from the register instantiations. Later on, when registers
could be inferred, the least disruptive coding style was to infer
registers from separate processes from the combinatorial processes
(i.e. simply replace register instantiations with synchronous
processes, and leave the combinatorial code alone).

I have designed many a TDM'ed state machine and other circuitry from a
single process, inferring RAM from an array in the same process. There
is no negative impact of using single process on designs that infer
RAM.

I strongly prefer synchronous processes over combinatorial ones or
over combinations of the two. Among other things, it allows cycle-type
optimizations in simulation, and the use of variables for local data
(registered, combinatorial or both) that is not shared between
processes.

Andy

 

[David Schetz]

I usually find that I write different tasks with different state machine representations. Sometimes it's just one synchronous process, with next-state logic and outputs together. Sometimes it's nice to have the next-state logic in an asynchronous process, and a synchronous process that assigns state <= next_state. This makes it clearer when you want an output to be dependent on a transition, not just the current state (ie, if state = state1 and next_state = state2 then ...). Of course, you could probably do this in one process, but I imagine it would start to look ugly and get confusing. I personally don't do 3-process machines, but if it makes the code easier to follow, I'm all for it.