Want flag to keep value through all states

Discussion in 'VHDL' started by Shannon, Jun 15, 2009.

  1. Shannon

    Shannon Guest

    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, Jun 15, 2009
    #1
    1. Advertising

  2. Shannon

    Shannon Guest

    On Jun 15, 1:34 pm, Shannon <> 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
     
    Shannon, Jun 15, 2009
    #2
    1. Advertising

  3. Shannon

    Dave Guest

    On Jun 15, 4:34 pm, Shannon <> 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, Jun 15, 2009
    #3
  4. 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
     
    Mike Treseler, Jun 16, 2009
    #4
  5. Shannon

    Andy Guest

    On Jun 16, 12:22 pm, Mike Treseler <> 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
     
    Andy, Jun 16, 2009
    #5
  6. Shannon

    Shannon Guest

    On Jun 16, 10:36 am, Andy <> wrote:
    > On Jun 16, 12:22 pm, Mike Treseler <> 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, Jun 17, 2009
    #6
  7. Shannon wrote:

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


    And yet the "send" button is the source of all enlightenment ;)
     
    Mike Treseler, Jun 18, 2009
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. S.Guhananth
    Replies:
    1
    Views:
    572
    Alvin Bruney [Microsoft MVP]
    Apr 30, 2005
  2. hazz
    Replies:
    0
    Views:
    2,645
  3. Bobby Edward
    Replies:
    3
    Views:
    333
    Cowboy \(Gregory A. Beamer\)
    Oct 28, 2008
  4. BlackHelicopter
    Replies:
    0
    Views:
    1,144
    BlackHelicopter
    Dec 9, 2010
  5. hisan
    Replies:
    1
    Views:
    1,407
    Dan Stromberg
    Jun 25, 2012
Loading...

Share This Page