( ESNUG 246 Item 5 ) ---------------------------------------------- [8/8/96]
Subject: (ESNUG 242 #6 243 #4 244 #5) Simulators Giving Frustrating X's
> The simulation problem of 'X' propagation is due to the cell definition
> of all the MUX cells. If users check their simulation library cell MUX,
> it must be built with the simulator primitive ("and", "or", "not" ...).
> To avoid the 'X' propagation, users need to define their MUX cell by
> using a UDP (User defined primitive table).
From: landman@hal.com (Howard Landman)
Not true. Adding a "redundant" gate level primitive gives the same result.
That is, making the mux function be ((s&d1)|(~s&d0)|(d0&d1)) also fixes
the problem. We do this routinely.
Of course, one can argue that users *should* want to know when mux selects
have gone unknown! In practice, however, it seems that this often causes
problems with initialization.
The bigger problem, which is not solvable at the moment, is that many high
level Verilog statements kill the propagation of Xs, but their gate-level
implementations don't. For example, in "if (a)", if a is X it gets treated
as if it were 0. Thus there will always be a difference in X simulation
between HDL and gates, in such a direction that no amount of HDL simulation
can guarantee that the gates won't go to X.
- Howard A. Landman
HAL Computer Systems
---- ---- ---- ---- ---- ----
From: mr@symbionics.co.uk (Martin Ryder)
John,
It should be possible to build a 2-to-1 MUX from logic primitives (AND, OR,
NOT) to give correct behaviour when the two data inputs are the same,
regardless of whether the select is known. I.E. for data inputs A and B,
select S, and output Q .......
_
Q = (A.B) + (A.S) + (B.S)
Of course this relies on the primitves having reasonable X-handling:
_
X = X, X+1 = 1, X+0 = X, X.0 = 0, X.1 = X
- Martin Ryder
Symbionics Developments Ltd.
---- ---- ---- ---- ---- ----
From: erstad@ssec.honeywell.com (Dave Erstad)
John,
It's true that poor library modeling can exacerbate this problem. However,
even with robust simulation models it can be a problem. Around five years
ago we were synthesizing a TM bus slave chip and ran into major headaches.
We were using our own library (Honeywell is an ASIC vendor in the space
and military markets) which correctly handles X's. The problem was that
there can be reconvergent logic where the "correct" X handling occurs across
several primitives. (As a thought experiment, think about a library
without a MUX gate. Synopsys would build the equivalent logic out of
primitives, and the behavior described by you could not be corrected
within the model library.)
The specific problems we had were due to attempting to synthesize scan
logic and synchronous resets. The synchronous reset wouldn't work because
there were two logic paths from the reset to the D input, one gated with
the Q output of the previous stage and another with the Qbar. Boolean-wise,
it reset, but in the simulator it didn't. Of course, nowadays Test Compiler
can insert scan after-the-fact, and there are Synopsys controls specifically
for the synchronous reset problem.
- Dave Erstad
Honeywell SSEC
---- ---- ---- ---- ---- ----
From: "Victor Duvanenko" <victor_duvanenko@quickmail.truevision.com>
John,
On the subject of X's in simulation caused by a synthesis created logic.
Muxes are not the only structures that cause problems (they are simply the
most obvious.) Other synthesized logic can sometimes be very tricky with
X handling; we've run into them many times.
The only true solution is for the logic simulation vendors to keep
track of X and "not X" on each particular net -- but they currently don't.
For simplicity they simply say "not X is an X, and I don't care if not X
is exactly opposite of X on that particular net." Keeping track of this
would be more difficult and would slow gate-level simulations down, -- but
then gate-level simulation would actually behave like gates!
- Victor J. Duvanenko
Truevision
|
|
