Moore State Change

Hi i have a VHDL Code for a State Machine
This is a part of a standard VHDL Template for a Moore State Machine
This is it

NEXT_STATE_DECODE: process (state, <input1>, <input2>, ...)
begin
--declare default state for next_state to avoid latches
next_state <= state; --default is to stay in current state
--insert statements to decode next_state
--below is a simple example
case (state) is
when st1_<name> =>
if <input_1> = '1' then
next_state <= st2_<name>;
end if;
when others =>
next_state <= st1_<name>;
end case;
end process;



Can anyone tell me what is
"next_state <= state; " kind of assignment inside a sequential
process
There are two assignments for the same signal "next_state" inside the
process, one like concurrent and another inside the case statement.
How is this valid..?
Suppose <input_1> changes to '1' ... won't this "next_state <= state;
" execute..???

knight

On Nov 10, 7:14*am, knight <krshe...@gmail.com> wrote:
> Hi i have a VHDL Code for a State Machine
> This is a part of a standard VHDL Template for a Moore State Machine
>
> Can anyone tell me what is
> *"next_state <= state; " kind of assignment inside a sequential
> process
> There are two assignments for the same signal "next_state" inside the
> process, one like concurrent and another inside the case statement.
> How is this valid..?

The way a VHDL process works is
- It starts executing when any of the signals in the sensitivity list
change. In your example this is the line "process (state, <input1>,
<input2>, ...)" so if 'state', 'input1', 'input2',... change then the
process will start executing.
- The process runs from top to bottom. If there are multiple
assignments to the same signal, the last assignment takes precedence.
- Signals that are assigned inside a process do not actually change
until the process suspends.
- A process suspends either when it reaches the end of the process or
it encounters a 'wait' statement.

> Suppose <input_1> changes to '1' ... won't this "next_state <= state;

It will execute and the statement "next_state <= st2_<name>;" will
execute as well. By the above mentioned rules, since "next_state <=
st2_<name>;" will happen last, it will override the assignment of
"next_state <= state;".

Kevin Jennings

KJ

On Nov 10, 8:35*am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> Also read about the single-process form of state machine, for greater
> reliability and simpler maintenance.

I agree with single-process forms. If you absolutely have to use a
combinatorial process, "default" assignment statements placed right up
front, outside of any conditional statements, are a good way to avoid
latches, since there is no path through the process that can avoid
assigning to the signal. Using default assignment statements is much
easier to write and maintain than older practices such as "every if
needs an else", etc.

Note that clocked processes do not have this problem of
unintentionally creating latches.

Andy

Andy

On Nov 10, 7:12*pm, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> Andy makes a very good point about avoiding surprises with combinatorial
> processes. Another is the problem of keeping the sensitivity lists
> correct. Again, that problem is much simpler with single-process state
> machines (where the list should include only clock. And arguably reset)
>
> - Brian

I think VHDL-2008 will make the issue of updating combinatorial
process sensitivity lists by letting you use a syntax something like:

process(all) -- automatically includes all referenced signals
begin
...
end process;

Dave