State machine transition on internal signals - is it legal?

[Divyang M]

Hi,

In two of the states of my state machine I need to transition (or stay
in the same state) depending on internal signals (and not the inputs).
These signals are essentially counters. Is this OK to do and
synthesize?
Or should I make a separate state for each of the counter values?

Below is a skeleton of my state machine to explain what I am saying
above (definitely not final VHDL code but just gives an idea. I am
looking up correct styles of coding state machines with two processes).

The Input / Output ports are as follows
(horiz and vert will be assigned to x and y)

entity my_sm
port(
clk : in std_logic;
newline : in std_logic;
x : out std_logic_vector(7 downto 0);
y : out std_logic_vector(9 downto 0)
);

and the state machine:

signal vert, horiz, mydelay (length as appropriate)

process(clk)
begin
if (clk = '1' and clk'event) then
case next_state is
when RESET =>
mydelay <= 0;
horiz <= 0;
vert <= 0;
next_state <= WAIT_16;

when WAIT_16 =>
if (newline = '1') then
mydelay <= mydelay + 1;
end if;
if mydelay = 16 then
next_state <= PROCESS;
else
next_state <= WAIT_16;
end if;

when PROCESS =>
if (horiz = 640) then
next_state <= WAIT_FOR_NEWLINE
else
horiz <= horiz + 1;
next_state <= PROCESS;
end if;

when WAIT_FOR_NEWLINE =>
if (newline = '1') then
horiz <= 0;
if (vert = 240) then
vert <= 0;
else
vert <= vert + 1;
end if;
next_state <= PROCESS;
else
next_state <= WAIT_FOR_NEWLINE;
end if;

end case

Thanks,
Divyang M

 

[Ralf Hildebrandt]

Divyang M wrote:

In two of the states of my state machine I need to transition (or stay
in the same state) depending on internal signals (and not the inputs).
These signals are essentially counters. Is this OK to do and
synthesize?

Sounds good.
And this has two additional advantages:
* Your state-variable is "freezed" for a while (until the counter has
reached it's final value) and therefore all combinational logic, that
depends on the state variable will not change. This saves power,
because unnessecary transitionas are avoided. I call this counter "a
substatemachine inside a masterstatemachine".
* You can re-use the counter in many master-states. This may save
flipflops.

Or should I make a separate state for each of the counter values?

If such an counter is used only in one or two master-states and the
bitwidth of your master-state variable is wide enough, you would need
more flipflops using the masterstatemachine plus the counter than only
using a normal state machine.
Otherwise if the counter is reused extensively, you will save power and
may save flipflops.

process(clk)
begin
if (clk = '1' and clk'event) then

Just a hint: No reset?

when WAIT_16 =>
if (newline = '1') then
mydelay <= mydelay + 1;
end if;
if mydelay = 16 then
next_state <= PROCESS;
else
next_state <= WAIT_16;
end if;

Looks good.


Ralf

 

[Divyang M]

Jerzy Gbur and Ralf - Thanks for replying and sorry for the double
posting. I will soon remove the duplicate posting.

I was going through some older posts in the forum and saw that the
WAIT_16 state can be interpreted as a 'Moore' state machine whithin a
'Mealy' state machine. And from a Mentor Graphics white paper on FSMs,
Moore machines have output glitches.

Now, since I have no output assignments in the WAIT_16 state, can I
safely assume that the output glitching will not affect my state
machine or is 'output glitching' a general term which can also affect
internal signals (in this case, mydelay)?

when WAIT_16 =>
if (newline = '1') then
mydelay <= mydelay + 1;
end if;
if mydelay = 16 then
next_state <= PROCESS;
else
next_state <= WAIT_16;
end if;

If 'output glitching' is an issue, I can easily split the WAIT_16 state
into 16 different states but I am concerned with coding efficieny in
case this ever has to be done for a counter counting into the hundreds
or thousands.

Or will the following solution take care of the glitching and code
efficiency issue at the same time?

when WAIT_16 =>
if (mydelay = 16) then
next_state <= PROCESS -- (I know PROCESS is a reserved word and has
to be changed)
elsif (newline = '1') then
mydelay <= mydelay + 1;
next_state <= WAIT_16;
else
mydelay <= mydelay;
next_state <= WAIT_16;
end if;

And Ralf, thanks for pointing out the reset condition, I need to
include that.

--Divyang M

 

[Divyang M]

Also, for a one process state machine do the internal signals need to
be on the process sensitivity list or just clk and reset signals?

 

[Mike Treseler]

I was going through some older posts in the forum and saw that the
WAIT_16 state can be interpreted as a 'Moore' state machine whithin a
'Mealy' state machine. And from a Mentor Graphics white paper on FSMs,
Moore machines have output glitches.

All your code is inside a clocked
process, so all outputs are registered.
No glitches.

-- Mike Treseler

 

[Mike Treseler]

Also, for a one process state machine do the internal signals need to
be on the process sensitivity list or just clk and reset signals?

just clk and reset

-- Mike Treseler

 

[Divyang M]

Thanks Mike, state machines have now started to make more sense now

 

[Andy Peters]

Thanks Mike, state machines have now started to make more sense now

And they'll make even more sense once you forget the following two
words:

Moore
Mealy

-a

 

[Mike Treseler]

And they'll make even more sense once you forget the following two
words:

Moore
Mealy

Amen to that!
Time to recycle those books.

I expect D-flops were more trouble
to wire up in 1954.


-- Mike Treseler

 

[Divyang M]

Slowly but surely those words are becoming history for me
I've been doing quick synthesis using Precision Synthesis
for small state machines to see how coding style afftects
synthesis and that has definitely helped.