I've got a case of the latches....

[Shannon]

Ok, I know how latches can be inferred from missing assignments. Here
is what I have:

process(clk, reset)
begin
if reset = '1' then
...
x < = '0';
...
elsif rising_edge clk then
x <= '0';
case state is
when....
when....
when....
if something then
x <= '1';
elsif something_else then
....
else
....
end if;
end case;
end if;
end process;

why is 'x' a latch?

Shannon

 

[Mike Treseler]

Ok, I know how latches can be inferred from missing assignments.

Only in an unclocked process.

Here is what I have:
...
why is 'x' a latch?

I don't see how it could be.
Post a complete entity.

-- Mike Treseler

 

[Shannon]

Only in an unclocked process.


I don't see how it could be.
Post a complete entity.

      -- Mike Treseler

I think I misunderstood the error message. I was getting (from
Quartus) the message: "analyzing combinational loop as a latch: "x" is
a latch"
What this error means is that 'x' is not a latch but how I'm using it
is.

The offending statement was where I was using 'x' outside of a clocked
process:

y <= z or x; (or some such thing). The point being y was being
assigned outside of the clocked process (mistakenly). It was THAT
that was forming the combinational loop. Moving the 'y' assignment
inside the clocked process fixed it.

Shannon

 

[Mike Treseler]

The offending statement was where I was using 'x' outside of a clocked
process:
y <= z or x; (or some such thing). The point being y was being
assigned outside of the clocked process (mistakenly). It was THAT
that was forming the combinational loop. Moving the 'y' assignment
inside the clocked process fixed it.

That's it.
An assignment 'outside' of a process
is in fact, an asynchronous process.