1) Is it important to propagate unknown values through
an RTL model that will be synthesized?
2) How can you code in Verilog to tell the simulator
that you don't care what comes out of a combinational
block, but that the values must be 0 or 1 and not x?
// EXAMPLE 1: ===============================================================
module cases ( o, i );
output [1:0] o;
input [3:0] i;
reg [1:0] tmp;
always @ ( i ) begin
casez ( i )
4'b0000: tmp = 2'bxx; // don't care what comes out, would like 0/1's
4'b1???: tmp = 2'b00;
4'b01??: tmp = 2'b01;
4'b001?: tmp = 2'b10;
4'b0001: tmp = 2'b11;
default: tmp = 2'bxx; // propagate x values
end // always
endmodule // cases() =======================================================
EXAMPLE 1 synthesizes (Synopsys) to an inverter, nor and AOI cell.
However, the RTL model doesn't simulate they way I would like because
the first case statement outputs x's. Synopsys sees that you are
implying a don't care condition and minimizes the terms down. Also
any unknown values that come in to this module are propagated to the
outputs.
// EXAMPLE 2: ==============================================================
module cases ( o, i );
output [1:0] o;
input [3:0] i;
reg [1:0] tmp;
always @ ( i ) begin
casez ( i )
4'b0000: tmp = 2'b00;
4'b1???: tmp = 2'b00;
4'b01??: tmp = 2'b01;
4'b001?: tmp = 2'b10;
4'b0001: tmp = 2'b11;
default: tmp = 2'bxx; // propagate x values
end // always
endmodule // cases() ======================================================
EXAMPLE 2 synthesizes to a larger implementation because don't cares
were not specified in the first case statement. It does simulate the
way I like (it just as easily could have been 01, 10, or 11, one
of which would synthesize to the same implementation as EXAMPLE 1).
---
Is is necessary to write your model to simulate the propagation of
x values? Or does it not really matter because typically there is
no timing modeled in an RTL model (no setup/hold checks, no prop
delay etc). It seems to me that the propagation of unknown values
in an RTL model would be useful in comparing simulation results
with the gate level implementation, however, I am not sure it is
worth the work.
opinions please?
thanks,
- dave
---------------------------------------------------
Dave Sluiter
Logic Design Group, ARTIST GRAPHICS, INC
Internet: slu...@artgraphics.com
US MAIL: 2675 Patton Road, St. Paul, MN 55113
---------------------------------------------------
: However, the RTL model doesn't simulate they way I would like because
: the first case statement outputs x's.
Why do you like 00 and not xx in the simualtion. Does something later in the
model care?
It's sort of a big-endian/little-endian pc/mac etc/etc. thing
for this kind of group.
The problem is that historically x's have been overloaded
with two meanings. And we're suffering because of that.
X propagation for illegal operations was important for gate
level simulators, where the idea of behavioral monitors didn't
exist.
But now that we can stop the simulation whenever anything bad
happens (with appropriate monitor code), we shouldn't rely
on propagating x's to a "visible" pin or something, to make
illegal operation halt the simulation.
You can't be sure that x propagation happens correctly thru behavioral code
(it usually doesn't and you can't be sure that you'll stop on the x....
some x's are okay...and it can be hard to validate an "illegal x" way far down
the activity chain. (because it's in a different context)
So I'd vote for consistently using x's for don't cares, and
develop another method for making sure you detect all illegal
cases. There's no common wisdom, though.
But if you're using someone else's libraries, they may rely
on x propagation for illegal operation detection...oh well.
Once you get the hang of it, you'll realize that you can detect
all sorts of "architectural" problems with monitors, that you ordinarily wouldn't
have thought of detecting through an "x propagation" solution.
But you can make x mean anything you want....
I speak for all asic designers from 1920-1930 :)
-kevin