«

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

Shannon wrote:
> 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

On Jun 29, 9:21*am, Mike Treseler <mtrese...@gmail.com> wrote:
> Shannon wrote:
> > 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

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

Shannon wrote:

> 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.