Reason for x propagation in RTL code?

[ptrnxt]

Here's the code. read_data is all X's which X pessimism is turned on in the simulator. Any ideas how to fix it? Thanks!

wire [15:0] dout = read_data;

always @*
if (~(&dout)) // keep incrementing till saturation
data = (dout + 16'd1);
else
data = 16'hFFFF;

always @(posedge clk)
if (rst) begin
en <= 1'b0;
adr <= 8'd0;
end else if (busy) begin
en <= cnt[4];
adr <= ram_adr;

always @(posedge clk)
we <= update;

REGF_SP_HD_256x16_m2b1w0c1p1d0t1_wrapper mem(
.CLK (clk),
.WE (we),
.ME (en),
.ADR (adr[7:0]),
.D (data[15:0]),
.PIPEME (1'b1),
.LS (1'b0),
.DS (1'b0),
.SD (1'b0),
.Q (),
.QP (read_data[15:0])
);

 

On Wednesday, 30 July 2014 04:17:33 UTC+2, ptrnxt wrote:

Here's the code. read_data is all X's which X pessimism is turned on in the simulator. Any ideas how to fix it? Thanks!
SNIP

REGF_SP_HD_256x16_m2b1w0c1p1d0t1_wrapper mem(

Hi,
I assume that this memory cell contains timing checks and you have timing errors - look for violations in your logfile.

To fix - check to see if there is a `define you can use to disable timing checks in the model (look in verilog or documentation)

Or, set simulator delay mode to 0 - not sure how you do this in modelsim.

Cheers,
Steven

 

Hi Steven,

Actually, I'm running an RTL 0-delay simulation with X-propagation turned on. So there are no timing violations. The sim passes when the switch is off.. But I'd ideally want to fix this in RTL so we don't to debug X-propagation issues later in gate level simulation.

 

[rickman]

On 7/30/2014 1:07 PM, redditorred@gmail.com wrote:

Hi Steven,

Actually, I'm running an RTL 0-delay simulation with X-propagation turned on. So there are no timing violations. The sim passes when the switch is off. But I'd ideally want to fix this in RTL so we don't to debug X-propagation issues later in gate level simulation.

I'm not clear on why it is a problem finding the source of the 'X'
values. Can't you just trace them back to the problem? It may be a
reflection of an initialized value in memory in which case the 'X'
propagation is showing you everything that will become undefined after
executing with an unknown value. If the problem is an 'X' value on an
input to the RAM, your problem is in your circuit.

I'm not familiar with Verilog. Does it initialize registers by default?
If not, this may be your problem...

always @*
if (~(&dout)) // keep incrementing till saturation
data = (dout + 16'd1);
else
data = 16'hFFFF;

I don't see initialization code.

If you are designing for some hardware that initializes data by default
and you don't want to include anything in your code which would
duplicate this, is there a way to initialize this by default in the
simulator? Perhaps the test bench can set data to a value at the start?

--

Rick

 

[Robert Miles]

On 7/30/2014 11:30 PM, rickman wrote:

On 7/30/2014 1:07 PM, redditorred@gmail.com wrote:
Hi Steven,

Actually, I'm running an RTL 0-delay simulation with X-propagation
turned on. So there are no timing violations. The sim passes when the
switch is off. But I'd ideally want to fix this in RTL so we don't to
debug X-propagation issues later in gate level simulation.

I'm not clear on why it is a problem finding the source of the 'X'
values. Can't you just trace them back to the problem? It may be a
reflection of an initialized value in memory in which case the 'X'
propagation is showing you everything that will become undefined after
executing with an unknown value. If the problem is an 'X' value on an
input to the RAM, your problem is in your circuit.

I'm not familiar with Verilog. Does it initialize registers by
default? If not, this may be your problem...

always @*
if (~(&dout)) // keep incrementing till saturation
data = (dout + 16'd1);
else
data = 16'hFFFF;

I don't see initialization code.

If you are designing for some hardware that initializes data by
default and you don't want to include anything in your code which
would duplicate this, is there a way to initialize this by default in
the simulator? Perhaps the test bench can set data to a value at the
start?

The Verilog programs I've used initialize all registers to X by default,
so you need to initialize the registers yourself if they need to be
initialized to anything else.