comp.lang.verilog Google Group

Re: weird simulation problems for a PC module

spamt...@icarus.com (Stephen Williams) — Fri, 12 Mar 2010 19:28:13 UT

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

sh...@cadence.com — Fri, 12 Mar 2010 04:03:17 UT

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?

wtx...@gmail.com (Weng Tianxiang) — Fri, 12 Mar 2010 03:11:58 UT

Andy,
Thank you for your comments.
Weng

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

jonesa...@comcast.net (Andy) — Thu, 11 Mar 2010 20:08:24 UT

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?

wtx...@gmail.com (Weng Tianxiang) — Thu, 11 Mar 2010 19:38:09 UT

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?

jonesa...@comcast.net (Andy) — Thu, 11 Mar 2010 17:29:31 UT

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?

jonesa...@comcast.net (Andy) — Thu, 11 Mar 2010 17:15:24 UT

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?

martin.j.thomp...@trw.com (Martin Thompson) — Thu, 11 Mar 2010 11:48:33 UT

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

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

wtx...@gmail.com (Weng Tianxiang) — Thu, 11 Mar 2010 02:44:44 UT

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?

ed.mcgetti...@xilinx.com (Ed McGettigan) — Thu, 11 Mar 2010 01:42:46 UT

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?

jim.granvi...@gmail.com (-jg) — Thu, 11 Mar 2010 01:10:12 UT

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?

ed.mcgetti...@xilinx.com (Ed McGettigan) — Thu, 11 Mar 2010 01:01:39 UT

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?

jonesa...@comcast.net (Andy) — Thu, 11 Mar 2010 00:25:53 UT

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.

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

al...@sbcglobal.net (Peter Alfke) — Wed, 10 Mar 2010 21:44:07 UT

On Mar 10, 12:31 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu>
wrote:
Glen: from the Virtex-6 User Guide Lite:
The look-up tables (LUTs) in Virtex-6 FPGAs can be configured as
either 6-input LUT (64-bit ROMs) with one output, or as two 5-input
LUTs (32-bit ROMs) with separate outputs but common addresses or logic

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

g...@ugcs.caltech.edu (glen herrmannsfeldt) — Wed, 10 Mar 2010 20:31:26 UT

(snip)

I didn't know that!
There is discussion in another newsgroup about recreating the
IBM 360/91 in an FPGA. I believe that is the machine that the
Earle latch was invented for. (Maybe it was the Stretch.)
The Earle latch pretty much takes one level of logic and combines
it with the logic of a transparent latch. When every propagation