«

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

On Jun 15, 1:34*pm, Shannon <sgo...@sbcglobal.net> wrote:
> 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

On Jun 15, 4:34*pm, Shannon <sgo...@sbcglobal.net> wrote:
> 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

Dave wrote:

> 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

On Jun 16, 12:22*pm, Mike Treseler <mtrese...@gmail.com> wrote:
> Dave wrote:
> > 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

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

On Jun 16, 10:36*am, Andy <jonesa...@comcast.net> wrote:
> On Jun 16, 12:22*pm, Mike Treseler <mtrese...@gmail.com> wrote:
>
>
>
> > Dave wrote:
> > > 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
>
> 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

Shannon wrote:

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

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