comp.lang.verilog Google Group

Re: Why doesn't this situation generate a latch?

2010-03-13T03:34:18Z

My understanding is the global set/reset is what we are talking about
when we say "async reset". That is what it is mapped to in all of my
designs.
Rick

Re: Why doesn't this situation generate a latch?

2010-03-13T03:32:47Z

I don't follow that at all. I use async resets all the time, but I
use them appropriately. I don't expect them to release all FFs at the
same time and design that way. That's all it takes. No magic, mo
complex design techniques. I just don't assume a counter will have
all bits start at the same clock cycle, give or take one cycle. But a

Re: weird simulation problems for a PC module

2010-03-12T19:28:13Z

Right, it doesn't really mean much even if it were true to say
that a variable were "born" with the initialized value. The value
will still need to be propagated through expressions, some of which
may involve system functions, user defined functions; all manner
of stuff that can't necessarily be evaluated without starting the

Re: weird simulation problems for a PC module

2010-03-12T04:03:17Z

Not necessarily "born" with it, no. Just guaranteed to be assigned it
before any initial or always blocks execute. If you look at it using
the simulator's UI before starting simulation, it may still be X.
Some simulators may execute some or all initializers at compile time,
while others may execute them at simulation time before any initial or

Re: Why doesn't this situation generate a latch?

2010-03-12T03:11:58Z

Andy,
Thank you for your comments.
Weng

Re: Why doesn't this situation generate a latch?

2010-03-11T20:08:24Z

I'm not sure why you are concerned about this. Everyone seems to agree
that inferring latches is not a good idea. The fact that it slows
performance (at least in FPGA's, see below) is just one more reason to
avoid them.
It just so happens that in FPGAs, the clock enable mux is always there
on the front of the flip-flop, so there is no timing penalty whether

Re: Why doesn't this situation generate a latch?

2010-03-11T19:38:09Z

Andy,
We don't argue about the latch replacement as you show. What we argue
about is when a fast next state signal StateA_NS is replaced by a
slower latched version.
It occurs if a condition in an if statement misses a signal assignment
statement as we have been discussing about.
Weng

Re: Why doesn't this situation generate a latch?

2010-03-11T17:29:31Z

Example:
A <= B when ENABLE; -- implies a latch for A
C <= A when rising_edge(CLK); -- a register using A
E <= A or D; -- another combinatorial function using A
If not for E, the latch could be replaced by a clock enable on the C
register. I suppose C could still use a clock enable and the B input
directly, but it does not wholly "replace" the latch, because the

Re: Why doesn't this situation generate a latch?

2010-03-11T17:15:24Z

OK, now I see where we're missing each other: in the definition of
what constitutes a reset function. When I say reset, I mean "device
initialization", either upon power up, power failure, BIT failure,
system watchdog event, etc. that resets darn near the whole device.
When you say "reset" you mean anytime the logic loads a zero or other

Re: Why doesn't this situation generate a latch?

2010-03-11T11:48:33Z

And the Microblaze core uses 3 (yes a whole 3 :) of them as well!
Martin

Re: Why doesn't this situation generate a latch?

2010-03-11T02:44:44Z

Andy,
"Some synthesis tools may be getting smart enough to optimize an
inferred latch from a combinatorial process into a clock enable on
the
corresponding register implied by the clocked process. But if there
are any other combinatorial processes that use that latched output of
the first combinatorial process, then the latch cannot be replaced by

Re: Why doesn't this situation generate a latch?

2010-03-11T01:42:46Z

I absolutely agree that asynchronous resets have a very valid use in
certain cases. My position is that should be avoided in the general
case.
FPGAs with the asynchronous global set/reset can also get you into
that known state before any clocks are applied.
Ed McGettigan

Re: Why doesn't this situation generate a latch?

2010-03-11T01:10:12Z

For Logic 'buried deep', that would be correct, but
for pin-drive logic, having a defined state BEFORE the clock, can be
quite mission-critical.
-jg

Re: Why doesn't this situation generate a latch?

2010-03-11T01:01:39Z

I wouldn't take it as a given that most resets are not already
synchronized to the clock domains. Resets are routinely used based on
termination count, end of packet, return to state0 from other states
or invalid states, etc.... All of these cases would be within the
same clock domain.
Placing the onus of creating a reliable design on software tools to

Re: Why doesn't this situation generate a latch?

2010-03-11T00:25:53Z

Given that most sources of reset signals are not already synchronized
to the clock domain(s) that need resetting, both asynchronous and
syncrhonous resets require at least the deasserting edge to be
synchronized. Proper syncrhonization for each case takes the same
amount of design effort and resources.