State Variable latch error

Discussion in 'VHDL' started by Shannon, Oct 7, 2008.

  1. Shannon

    Shannon Guest

    Quartus is giving me the following error:

    Warning (10631): VHDL Process Statement warning at Ramp.vhd(97):
    inferring latch(es) for signal or variable "Ramp_State_Next", which
    holds its previous value in one or more paths through the process

    I'm doing the classic two-process state machine that I've done a
    million times before. Of course "Ramp_State_Next" holds its previous
    value in one or more paths!!! It's THE state variable!!!

    So assuming the error is misleading as they usually are, what is it
    that I should be looking for? I've looked through the code and in
    every state Ramp_State_Next is being assigned to something regardless
    of all the If..Then statements. Can some other signal infering a
    latch and then through a dependancy on it, make the Ramp_State_Next
    signal be latched? I guess I'm just at a loss where to go looking for
    this.

    Any ideas?

    Shannon
    Shannon, Oct 7, 2008
    #1
    1. Advertising

  2. Shannon

    Shannon Guest

    On Oct 7, 2:38 pm, Shannon <> wrote:
    > Quartus is giving me the following error:
    >
    > Warning (10631): VHDL Process Statement warning at Ramp.vhd(97):
    > inferring latch(es) for signal or variable "Ramp_State_Next", which
    > holds its previous value in one or more paths through the process
    >
    > I'm doing the classic two-process state machine that I've done a
    > million times before.  Of course "Ramp_State_Next" holds its previous
    > value in one or more paths!!! It's THE state variable!!!
    >
    > So assuming the error is misleading as they usually are, what is it
    > that I should be looking for?  I've looked through the code and in
    > every state Ramp_State_Next is being assigned to something regardless
    > of all the If..Then statements.  Can some other signal infering a
    > latch and then through a dependancy on it, make the Ramp_State_Next
    > signal be latched?  I guess I'm just at a loss where to go looking for
    > this.
    >
    > Any ideas?
    >
    > Shannon


    Classic. As soon as I hit the send button.....

    I found an incomplete If..Then statement. For the record:

    If a='1' then
    If b='1' then
    state_next <= state_one;
    ElsIf c='1' then
    state_next <= state_two;
    End If; -- oooops!
    Else
    state_next <= state_zero; -- this doesn't cover the incomplete
    If..Then above.
    End If;

    Repair:
    If a='1' then
    If b='1' then
    state_next <= state_one;
    ElsIf c='1' then
    state_next <= state_two;
    Else
    state_next <= state_zero;
    End If;
    Else
    state_next <= state_zero;
    End If;

    I'm convinced that if we all had virtual newsgroups on our desktop
    we'd cut down on a lot of this kind of clutter I just did. You could
    just write a virtual post to your virtual newsgroup and then BANG the
    answer hits you.

    Shannon
    Shannon, Oct 7, 2008
    #2
    1. Advertising

  3. Shannon

    Andy Guest

    On Oct 7, 4:47 pm, Shannon <> wrote:
    > On Oct 7, 2:38 pm, Shannon <> wrote:
    >
    >
    >
    > > Quartus is giving me the following error:

    >
    > > Warning (10631): VHDL Process Statement warning at Ramp.vhd(97):
    > > inferring latch(es) for signal or variable "Ramp_State_Next", which
    > > holds its previous value in one or more paths through the process

    >
    > > I'm doing the classic two-process state machine that I've done a
    > > million times before.  Of course "Ramp_State_Next" holds its previous
    > > value in one or more paths!!! It's THE state variable!!!

    >
    > > So assuming the error is misleading as they usually are, what is it
    > > that I should be looking for?  I've looked through the code and in
    > > every state Ramp_State_Next is being assigned to something regardless
    > > of all the If..Then statements.  Can some other signal infering a
    > > latch and then through a dependancy on it, make the Ramp_State_Next
    > > signal be latched?  I guess I'm just at a loss where to go looking for
    > > this.

    >
    > > Any ideas?

    >
    > > Shannon

    >
    > Classic.  As soon as I hit the send button.....
    >
    > I found an incomplete If..Then statement.  For the record:


    I've found that having default assignment statements for every output
    of a combinatorial process, right up front in that process, is a much
    more easily verified way of making sure there will be no latches in
    combinatorial processes. When I tried doing the "every if has an else"
    thing, it was too easy to miss assignments in "else" clauses that I
    had dutifully added. For the default assignment to next_state, just
    assign it to state.

    But that's only if I have to use a combinatorial process. Whenever
    possible, I use clocked, single process representations that can't
    create latches.

    Andy
    Andy, Oct 8, 2008
    #3
  4. Shannon

    Shannon Guest

    On Oct 8, 9:39 am, Andy <> wrote:
    > On Oct 7, 4:47 pm, Shannon <> wrote:
    >
    >
    >
    >
    >
    > > On Oct 7, 2:38 pm, Shannon <> wrote:

    >
    > > > Quartus is giving me the following error:

    >
    > > > Warning (10631): VHDL Process Statement warning at Ramp.vhd(97):
    > > > inferring latch(es) for signal or variable "Ramp_State_Next", which
    > > > holds its previous value in one or more paths through the process

    >
    > > > I'm doing the classic two-process state machine that I've done a
    > > > million times before.  Of course "Ramp_State_Next" holds its previous
    > > > value in one or more paths!!! It's THE state variable!!!

    >
    > > > So assuming the error is misleading as they usually are, what is it
    > > > that I should be looking for?  I've looked through the code and in
    > > > every state Ramp_State_Next is being assigned to something regardless
    > > > of all the If..Then statements.  Can some other signal infering a
    > > > latch and then through a dependancy on it, make the Ramp_State_Next
    > > > signal be latched?  I guess I'm just at a loss where to go looking for
    > > > this.

    >
    > > > Any ideas?

    >
    > > > Shannon

    >
    > > Classic.  As soon as I hit the send button.....

    >
    > > I found an incomplete If..Then statement.  For the record:

    >
    > I've found that having default assignment statements for every output
    > of a combinatorial process, right up front in that process, is a much
    > more easily verified way of making sure there will be no latches in
    > combinatorial processes. When I tried doing the "every if has an else"
    > thing, it was too easy to miss assignments in "else" clauses that I
    > had dutifully added. For the default assignment to next_state, just
    > assign it to state.
    >
    > But that's only if I have to use a combinatorial process. Whenever
    > possible, I use clocked, single process representations that can't
    > create latches.
    >
    > Andy- Hide quoted text -
    >
    > - Show quoted text -


    Yeah I seem to go back and forth between both styles. Sometimes the
    explicit two process S.M. just seems more clear to me. Both are good
    though. I've seen three and four process S.M.'s and I've never seen
    that help.

    I did in fact go back and do the default assignment style for the
    problem in the original post. I agree that it is a better way to go.
    Sometimes however it's good to go through the mental process of "every
    if has an else". Not for catching latches but for performance
    reasons. Asking yourself the question, "Did I think of everything?"

    Shannon
    Shannon, Oct 9, 2008
    #4
  5. Shannon

    Shannon Guest

    On Oct 9, 8:13 am, Shannon <> wrote:
    > On Oct 8, 9:39 am, Andy <> wrote:
    >
    >
    >
    >
    >
    > > On Oct 7, 4:47 pm, Shannon <> wrote:

    >
    > > > On Oct 7, 2:38 pm, Shannon <> wrote:

    >
    > > > > Quartus is giving me the following error:

    >
    > > > > Warning (10631): VHDL Process Statement warning at Ramp.vhd(97):
    > > > > inferring latch(es) for signal or variable "Ramp_State_Next", which
    > > > > holds its previous value in one or more paths through the process

    >
    > > > > I'm doing the classic two-process state machine that I've done a
    > > > > million times before.  Of course "Ramp_State_Next" holds its previous
    > > > > value in one or more paths!!! It's THE state variable!!!

    >
    > > > > So assuming the error is misleading as they usually are, what is it
    > > > > that I should be looking for?  I've looked through the code and in
    > > > > every state Ramp_State_Next is being assigned to something regardless
    > > > > of all the If..Then statements.  Can some other signal infering a
    > > > > latch and then through a dependancy on it, make the Ramp_State_Next
    > > > > signal be latched?  I guess I'm just at a loss where to go looking for
    > > > > this.

    >
    > > > > Any ideas?

    >
    > > > > Shannon

    >
    > > > Classic.  As soon as I hit the send button.....

    >
    > > > I found an incomplete If..Then statement.  For the record:

    >
    > > I've found that having default assignment statements for every output
    > > of a combinatorial process, right up front in that process, is a much
    > > more easily verified way of making sure there will be no latches in
    > > combinatorial processes. When I tried doing the "every if has an else"
    > > thing, it was too easy to miss assignments in "else" clauses that I
    > > had dutifully added. For the default assignment to next_state, just
    > > assign it to state.

    >
    > > But that's only if I have to use a combinatorial process. Whenever
    > > possible, I use clocked, single process representations that can't
    > > create latches.

    >
    > > Andy- Hide quoted text -

    >
    > > - Show quoted text -

    >
    > Yeah I seem to go back and forth between both styles.  Sometimes the
    > explicit two process S.M. just seems more clear to me.  Both are good
    > though.  I've seen three and four process S.M.'s and I've never seen
    > that help.
    >
    > I did in fact go back and do the default assignment style for the
    > problem in the original post.  I agree that it is a better way to go.
    > Sometimes however it's good to go through the mental process of "every
    > if has an else".  Not for catching latches but for performance
    > reasons.  Asking yourself the question, "Did I think of everything?"
    >
    > Shannon- Hide quoted text -
    >
    > - Show quoted text -


    And for the sake of completeness....

    Final Repair:
    state_next <= state_zero;
    If a='1' then
    If b='1' then
    state_next <= state_one;
    ElsIf c='1' then
    state_next <= state_two;
    End If;
    End If;

    Shannon
    Shannon, Oct 9, 2008
    #5
    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. dangerlee

    logical left shifter or latch ??

    dangerlee, May 5, 2004, in forum: VHDL
    Replies:
    4
    Views:
    829
    Egbert Molenkamp
    May 7, 2004
  2. Lee
    Replies:
    3
    Views:
    3,693
  3. Patrick
    Replies:
    5
    Views:
    567
    Thomas Stanka
    May 28, 2004
  4. M.A.Khader

    Beginner: Simple D latch

    M.A.Khader, Aug 19, 2004, in forum: VHDL
    Replies:
    3
    Views:
    5,079
    ivailokroumov
    Aug 19, 2004
  5. bob
    Replies:
    1
    Views:
    4,324
    Tim Hubberstey
    Feb 15, 2005
Loading...

Share This Page