( ESNUG 322 Item 7 ) ---------------------------------------------- [6/15/99]
Subject: ( ESNUG 321 #8 ) MUX Models Must Be Redundant To Handle 'X' Selects
> One advantage of this style of mux model (as opposed to a behavioral "if"
> or "?:" model) is that it will propagate X values. (The Verilog language
> spec requires an if statement to treat an X as if it were a 0.) However,
> there's a subtlety that many people miss. You want it to be the case
> that, if your select is X, but both data values are the same, then the
> output is the data, not X. (You can trust me on this, or learn from
> painful experience. :-)
>
> Therefore, your mux models need to include a "redundant" term. Here's an
> example (the "a & b" term is redundant for 0-1 values):
>
> module mux2 (z, a, b, s);
>
> output z;
> input a, b, s;
> reg z;
>
> always @(a or b or s)
> begin
> // redundant term to get correct behavior when s is X .
> q = (~s & a) | (s & b) | (a & b);
> end
>
> endmodule
>
> I *STRONGLY* recommend all behavioral mux models be written in this manner.
>
> - Howard A. Landman
> SiTera, Inc. Longmont, CO
From: Kim Flowers <kimf@translogic.com>
John, I saw this message in the ESNUG mailing list. What happens if you
do not model MUXes in this manner? This is actually a practical
question for us -- we need to model various mux-like cells and I would
really like to know the reasoning. Thanks!
- Kim Flowers
Translogic Technology
---- ---- ---- ---- ---- ---- ----
From: Howard Landman <HowardL@SiTera.com>
John,
If you don't model MUXes redundantly, then under some circumstances you will
get an X as the output of the mux when in reality the value is known. This
can sometimes cause problems in simulation. A typical issue can be failure
of a chip to reset -- once certain signals become stuck at X, it may be hard
to force them to 0. This is especially true in synthesized netlists where
reset may be buried far back in a cone of logic.
- Howard A. Landman
SiTera, Inc. Longmont, CO
---- ---- ---- ---- ---- ---- ----
From: Shalom Bresticker <shalom@msil.sps.mot.com>
Hello, Howard,
You lump "if" and "?:" together. However, "?:" does propagate X values.
And if the select is X, but both data values are the same, then the output
is the data, not X. That's our experience, at least in Verilog-XL.
- Shalom Bresticker
Motorola Semiconductor Israel, Ltd. Herzlia, Israel
---- ---- ---- ---- ---- ---- ----
From: Howard Landman <HowardL@SiTera.com>
Hi Shalom,
Actually, I think what's happening here is that Verilog treats the X on
select as 0, so it chooses the second value. If both values are the same,
this of course is the same as the first value.
But if the values are different, then ?: gets the wrong answer.
"1'bx ? 1'b1 : 1'b0" should evaluate to X to be safe, but Verilog makes it
0, which may not be correct and will probably not match gate-level sim.
So, the problem with "if" and "?:" is not when the values are the same, but
rather when they are different (and select is X). The problem with the
gate level model (without redundant term) is when the values are the same
(and select is X). Sorry if I was unclear.
- Howard A. Landman
SiTera, Inc. Longmont, CO
---- ---- ---- ---- ---- ---- ----
From: shalom@msil.sps.mot.com (Shalom Bresticker)
Sorry, Howard.
I just tried it on my Verilog-XL in all sorts of modes, and got x each
time, just as it should, not 0. If you have a test in which Verilog-XL
gives you 0, please send it to me so that I can check it.
In the meantime, I stand by my statements.
- Shalom Bresticker
Motorola Semiconductor Israel, Ltd. Herzlia, Israel
---- ---- ---- ---- ---- ---- ----
From: Howard Landman <HowardL@SiTera.com>
Hi Shalom,
I don't have XL here, but VCS also behaves as you describe. So, you're
right and I was wrong -- the "?:" operator propagates X's correctly. I
ran all possible 0-X-1 combinations and they all behaved identically to
the model I recommended.
The "if" operator, on the other hand, gets the wrong answer in several
cases.
- Howard A. Landman
SiTera, Inc. Longmont, CO
|
|
