State machine transition on internal signals - is it legal?

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

Divyang M

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

Ralf Hildebrandt

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?

Divyang M

Divyang M wrote:

> 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

Divyang M wrote:
> 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

Mike Treseler

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

Divyang M

Divyang M wrote:
> 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

Andy Peters

Andy Peters wrote:
> Divyang M wrote:
>>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

Amen to that!
Time to recycle those books.

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


-- Mike Treseler

Mike Treseler

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.

Divyang M