"generate" function

[paz]

I have this code:

generate
for (i=0; i< DATA_WIDTH; i=i+1)
begin
always @(d)
begin
$display("loop of bit %d with value %b->%b of sync %m -at time
%t ,last time change at %t",i,d_delay1,d,$time,t_prev);
spike_time = $time - t_prev;
if (SPIKE_MON_EN == 1 && start_monitor == 1 && en == 1 &&
spike_time < `MIN_SPIKE_TIME)
begin
#1 if (rst_b)
$display("SYNC SPIKE MONITOR ERROR: at time %t, in
%m.d[%d], spike = %d ps", $time, i, spike_time);
end
t_prev = $time;
end
end
endgenerate

I'm getting this line in my log:

loop of bit 130 with value 0->0 of sync testbench.genblk1[130]
-at time 669.300ns ,last time change at 191.770ns


How can it be? as you can see the value of the bit didn't change.

The result is that when the value is changing I'm getting the error
message.

I have checked the fsdb dump, and couldn't see any spikes there.

any idea?

 

paz wrote:

I'm getting this line in my log:

loop of bit 130 with value 0->0 of sync testbench.genblk1[130]
-at time 669.300ns ,last time change at 191.770ns


How can it be? as you can see the value of the bit didn't change.

I would guess that you are getting a zero-width
glitch on the value, too narrow to be seen by
the always block. For example, if this is a variable,
it might be assigned a 1 and then a 0 again in
consecutive statements.

Alternately, if this is a net, the drive strength of the
value might have changed without the value
changing. The always block shouldn't wake up
for that, but your tool might be handling it wrong.

 

[paz]

Hi,

Actually, I'm using ncverilog, so I guess that this is not the second
case.
How can I check for races?
I found that "hal" (cadence tool) is doing that, but I also found that
it detects the race conditions only in synthesizable HDL code, and my
code is not synthesizable (has delays on it)
Is there any other tool that might help?





On Feb 8, 9:54 pm, s...@cadence.com wrote:

paz wrote:

I'm getting this line in my log:

loop of bit 130 with value 0->0 of sync testbench.genblk1[130]
-at time 669.300ns ,last time change at 191.770ns

How can it be? as you can see the value of the bit didn't change.

I would guess that you are getting a zero-width
glitch on the value, too narrow to be seen by
the always block. For example, if this is a variable,
it might be assigned a 1 and then a 0 again in
consecutive statements.

Alternately, if this is a net, the drive strength of the
value might have changed without the value
changing. The always block shouldn't wake up
for that, but your tool might be handling it wrong.

 

[Ajeetha (www.noveldv.com)]

Hi,
If I'm not mistaken, you didn't show us how "d" and "d_delay" are
related, sounds from name like a "delayed version", but how - through
always? assign?

More answers below:

On Feb 11, 9:00 pm, "paz" <pazi...@walla.com> wrote:

Hi,

How can I check for races?
I found that "hal" (cadence tool) is doing that, but I also found that
it detects the race conditions only in synthesizable HDL code, and my
code is not synthesizable (has delays on it)
Is there any other tool that might help?

Since many races appear in TB as well, a race detetcion inside
simulator is desirable at times. This will be a dynamic data and hence
may become too much to analyze. I know VCS has +race option to do
this. Not sure about NC though, sorry.

Try adding a #0 before the $display in your always block, that might
filter this.

Also try using %0d, %0b to beautify your $displays.


Regards
Ajeetha, CVC
www.noveldv.com

-at time 669.300ns ,last time change at 191.770ns

How can it be? as you can see the value of the bit didn't change.