( ESNUG 410 Item 11 ) ------------------------------------------- [04/02/03]
Subject: ( ESNUG 393 #4 ) Only Fools & Idiots Use #1 Delays In Their Code
> 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...
>
> - Darren Jones
> MIPS Technologies Mountain View, CA
>
From: Mark Curry <goldfish=mcurry bowl=ti jot prom>
John,
Using #delays ANYWHERE in RTL code is not allowed in my coding style. I
just went back and checked my code for the last three chips designs. No
#delays anywhere. Not a one. And now since we're starting to code
synthesizable testbenches (for use in hardware acceleration/emulation), the
#delays are disappearing there, too. My only #delays is at the top level
testbench for generating the clock. That's it.
At best case, #delays can only offer a clutch for those to hold when viewing
waveforms. It allows them to "see" the clk-Q delay of a flip-flop.
At worst case it can introduce real bugs in designs.
Somewhere in the middle - you're just creating more problems for folks down
the line trying to reuse your code, or use a different simulator.
A couple of counterpoints to Darren's arguements for #delays:
>
> 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.
These event ordering rules are well defined rules that all simulators must
follow. Of course I rely on them. So do you. Better to rely on explicit
well defined behaviours rather than random ones which change with any change
in code or simulator.
> The problem is that the PLI interface does not guarantee these intra-
> timetick ordering rules.
Huh? We use the PLI extensively, and have never had issues with the lack of
#1s. Last time I looked, when driving Verilog objects from the PLI you're
given many options on when the PLI's "drive" takes place. Effectively, we
had the C model drive our Verilog in the same style as our Verilog non-
blocking type assignments to clocked registers (without delays).
> 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 is a bug. Period. See Cliff's paper in ESNUG 409 #10. If it's your
code fix it. If it's in someone else try and get them to fix it. If not,
then you're forced to work around it. Which kind of leads to my original
point. If the original person had never used the delays and other dangerous
coding styles in the first place it wouldn't cause problems later on for
someone reusing the code.
> 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 have code that fails when dumping is off, then passes when dumping is
on, it is because you're not following the blocking/non-blocking rules, and
should fix it. It's not because of the lackof #1's. The #1's are simply
poor work-arounds.
Our team has now followed the recommended blocking/non-blocking coding
styles for quite a few years. Some still do use the #1 in non-blocking
assigns for flip-flops. It's OK as long as they follow the blocking/non-
blocking rules, and don't mind seeing 1 nsec glitches in their sim dumps
(where signals from #1's and non-#1's come together through non-sequential
logic.)
I'm still working on them though. We'll convert them over yet! #1's
really offer you nothing. And have the potential of causing soo
much grief.
We are able to simulate our designs in many sim environments including:
Verilog-XL, NC-SIM, ModelSim, and Axis XSIM (both software and hardware
acceleration). Other teams take our designs an map it onto Quickturn boxes.
All have no issues (with respect to this coding style). We're able to
switch back and forth with just changes to run scripts.
- Mark Curry
Texas Instruments Broadband Access Group
---- ---- ---- ---- ---- ---- ----
> 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.
From: Cliff Cummings <dancer=cliffc nightclub=sunburst-design rot mom>
Hi, John,
There are a few problems with Darren's statement.
1) mixed blocking and nonblocking assignments are a problem with or
without the #1 delay. It is possible for a blocking-assignment flop
to execute before the right-hand-side (RHS) of a nonblocking assignment
is sampled, causing a race condition. If there are flops modeled with
blocking assignments in the design, they should be fixed, period.
2) semi-correct on the mixed gate+RTL simulations, but not completely
correct. Most gate-level register models have hold time requirements
of less than 1 nsec so the #1 will fix those problems. It's not
unusual for a RAM model to have a hold time requirement of greater
than 1nsec, in which case the #1 is not sufficient.
The only place you need an intra-assignment delay included with a non-
blocking assignment for mixed gate+RTL delays is on the outputs of the RTL
model that could drive the inputs of a gate-level model with hold-time
requirements. You also need to verify that all of the gate-level inputs
have hold time requirements of less than 1nsec, otherwise some of the RHS
delays will need to be increased. A semi-simple ifdef-ed block of code to
drive all module outputs with the typical #1 delay could be added to the
module to address this rare condition, otherwise, running regressions on
large RTL designs would benefit from the accelerations described by Mark.
> 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...
Race conditions can be avoided by following some simple guidelines. See my
updated paper in ESNUG 409 #10.
The idea of adding #1 delays to see the races is the wrong emphasis. Avoid
the races, period. The recommended guidelines in the pending IEEE Verilog
Synthesis Interoperability Standard were included to help engineers avoid
the race conditions.
Yes, adding #1 can be useful for waveform displays, as noted. It does make
it easier to see the clk-to-q output delays as opposed to viewing the clock
edge and transition at the same time. Even this is not bad if you avoid
mixing blocking assignments and nonblocking assignments in the same
procedural blocks, which would cause some of the waveform inputs to also
transition on the clock edge. Most confusing (and should be avoided).
Under no circumstances should delays be added to either the left or right
side of blocking assignments in an RTL model. This can be the source of
missed events and simulations that do not behave like any real hardware in
existence.
> 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. :)
I typically find that adding the #1 to all nonblocking assignments is
rooted in misunderstanding the Verilog scheduling queue, paranoia and poor
adherence to following proven guidelines to avoid Verilog race conditions.
This is my biggest complaint about most Verilog training courses, that they
do not cover nonblocking assignments and guidelines well and so course
graduates are now among the semi-educated dangerous.
I will gladly enforce a few simple guidelines to get non-race simulations
that run vcs +rad fast. Thanks, Mark for sharing the "under the covers"
info about VCS.
- Cliff Cummings
Sunburst Design, Inc. Beaverton, OR
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 16,683 other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@TheWorld.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
|
|
