Want flag to keep value through all states

[Shannon]

I am using a single-process state-machine style of coding. I have a
flag that gets set or cleared in one state. I want it to keep
whatever value that is throughout the rest of the state machine until
the machine returns to that state. What is the correct way of doing
this?

Please note that I am not referring to a "default" state. That much I
understand. I just want the flag to be set once and then stay that
way regardless of the condition that set it changing later.

Process (clk)
begin
if rising_edge(clk) then
case state
when one =>
flag <= input;
...
when two =>
if flag = '1' then
....
else
....
etc...

Thanks,
Shannon

 

[Shannon]

I am using a single-process state-machine style of coding.  I have a
flag that gets set or cleared in one state.  I want it to keep
whatever value that is throughout the rest of the state machine until
the machine returns to that state.  What is the correct way of doing
this?

Please note that I am not referring to a "default" state.  That much I
understand.  I just want the flag to be set once and then stay that
way regardless of the condition that set it changing later.

Process (clk)
begin
  if rising_edge(clk) then
    case state
      when one =>
         flag <= input;
         ...
      when two =>
         if flag = '1' then
          ....
         else
         ....
etc...

Thanks,
Shannon

I'm suffering post traumatic "send" disorder....

I'm betting that I don't have to do anything since it is in a clocked
process and will become a register.

Shannon

 

[Dave]

I am using a single-process state-machine style of coding.  I have a
flag that gets set or cleared in one state.  I want it to keep
whatever value that is throughout the rest of the state machine until
the machine returns to that state.  What is the correct way of doing
this?

Please note that I am not referring to a "default" state.  That much I
understand.  I just want the flag to be set once and then stay that
way regardless of the condition that set it changing later.

Process (clk)
begin
  if rising_edge(clk) then
    case state
      when one =>
         flag <= input;
         ...
      when two =>
         if flag = '1' then
          ....
         else
         ....
etc...

Thanks,
Shannon

If you simply don't assign the signal's value in those states where
the signal should remain unchanged, then the value will remain the
same until the next clock tick. The synthesizer will implement this by
making the clock enable for the signal's register '0' for those states
where the signal is not assigned. This is one of the nice things about
single-process state machines.

Dave

 

[Mike Treseler]

If you simply don't assign the signal's value in those states where
the signal should remain unchanged, then the value will remain the
same until the next clock tick. The synthesizer will implement this by
making the clock enable for the signal's register '0' for those states
where the signal is not assigned. This is one of the nice things about
single-process state machines.

Yes.
Describing changes takes less text
than describing the full state and output.

It is unfortunate that asynchronous processes
and the default assignments they require,
are so well covered in vhdl instruction.

Some designers retain this verbose
style in all cases, out of habit.

-- Mike Treseler

 

[Andy]

Yes.
Describing changes takes less text
than describing the full state and output.

It is unfortunate that asynchronous processes
and the default assignments they require,
are so well covered in vhdl instruction.

Some designers retain this verbose
style in all cases, out of habit.

        -- Mike Treseler

What's worse, most texts that promote dual processes also don't
promote the best way to avoid latches in the combinatorial processes:
default assignments right up front in the process. With those, you
have your choice of default signal behavior being unchanged, set or
reset for each signal. Most texts try to focus on an else for every
if, and complete assignment lists in every state, both of which are
much harder to write, read and update/maintain.

You still have all the default behavior choices with a single clocked
process, which is much better in the first place.

Andy

 

[Shannon]

What's worse, most texts that promote dual processes also don't
promote the best way to avoid latches in the combinatorial processes:
default assignments right up front in the process. With those, you
have your choice of default signal behavior being unchanged, set or
reset for each signal. Most texts try to focus on an else for every
if, and complete assignment lists in every state, both of which are
much harder to write, read and update/maintain.

You still have all the default behavior choices with a single clocked
process, which is much better in the first place.

Andy

thanks for the help. I suspected the answer moments after I pressed
send. I used to be a two-process person but you guys convinced me
otherwise. I never was a three-process person.

Shannon

 

[Mike Treseler]

I'm suffering post traumatic "send" disorder....

And yet the "send" button is the source of all enlightenment