( ESNUG 393 Item 4 ) --------------------------------------------- [04/25/02]
Subject: ( ESNUG 387 #16 ) Missing #1 Delays In VCS Will Burn You In Debug
> Blocking assigns with delays are not recommended:
>
> always @(posedge clk)
> a = #1 b;
>
> Blocking assignments do not ensure proper ordering of events in daisy-
> chained flip-flops, so they require a #1 on the RHS to avoid race
> conditions. Since this inhibits VCS cycle-based optimizations, this
> coding style is also not recommended.
>
> - Mark Warren
> Synopsys, Inc. Cupertino, CA
From: Darren Jones <dj@mips.com>
Hi John,
In ESNUG 387 #16, Mark Warren claims that the following flip-flop
coding style uses an unnecessary #1 delay:
always @(posedge clk)
a <= #1 b;
If you do not include the #1 delay above, then you are relying on the
intra-timetick event ordering rules of Verilog. The problem is that
the PLI interface does not guarantee these intra-timetick ordering
rules. Thus, if you use PLI to model circuit behavior, you may have
latent race conditions. (This applies to VMC models, too)
In addition, using the #1 does in fact avoid races when you have code
which may not always use non-blocking assignments for flops. This can
happen if a designer accidentally uses a blocking assignment, or if
you are trying to do mixed gate+RTL simulations, or if you are using
code not produced by your team - for instance compiled RAM models, 3rd
party BIST controllers, IP cores, etc.
Furthermore, if you eliminate all #1 delays on flops and then have a
race condition, it is notoriously difficult to debug. Just turning on
waveform dumping may cause the simulation to pass...
If you don't use PLI, and have bug-free RTL and all of it follows the
given style recommendations, the #1 is not needed. However, using #1
does give your design some degree of resiliency to the many coding
styles in use today. I do not dispute that VCS may run faster, but it
doesn't help me to have a fast simulation that doesn't work. :)
- Darren Jones
MIPS Technologies Mountain View, CA
|
|
