State Variable latch error

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

On Oct 7, 2:38*pm, Shannon <sgo...@sbcglobal.net> 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

On Oct 7, 4:47*pm, Shannon <sgo...@sbcglobal.net> wrote:
> On Oct 7, 2:38*pm, Shannon <sgo...@sbcglobal.net> 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

On Oct 8, 9:39*am, Andy <jonesa...@comcast.net> wrote:
> On Oct 7, 4:47*pm, Shannon <sgo...@sbcglobal.net> wrote:
>
>
>
>
>
> > On Oct 7, 2:38*pm, Shannon <sgo...@sbcglobal.net> 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

On Oct 9, 8:13*am, Shannon <sgo...@sbcglobal.net> wrote:
> On Oct 8, 9:39*am, Andy <jonesa...@comcast.net> wrote:
>
>
>
>
>
> > On Oct 7, 4:47*pm, Shannon <sgo...@sbcglobal.net> wrote:
>
> > > On Oct 7, 2:38*pm, Shannon <sgo...@sbcglobal.net> 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