( ESNUG 352 Item 6 ) --------------------------------------------- [5/17/00]
Subject: ( ESNUG 351 #7 ) Curry's Holy War On Oren's Verilog "<= #1" Idea
> I didn't see Cliff's presentation at SNUG (I was in a different session),
> but this is indeed a very thorough analysis of the different cases. All of
> Cliff's guidelines have been standard practice for us, for a long time.
>
> I'd add one guideline of my own - add a #1 in the nonblocking assignments
> to sequential elements:
>
> a <= #1 b;
>
> instead of
>
> a <= b;
>
> There are two reasons for this:
>
> 1. It allows mixed RTL and gate-level simulations to run correctly,
> by providing 1ns of hold time to the gate-level flip-flops.
> 2. It's so much easier to understand what you see on the waves display
> when you're trying to debug something, because signals change 1 ns
> after the clock edge.
>
> Good paper, Cliff.
>
> - Oren Rubinstein
> GigaPixel Corp. Santa Clara, CA
From: Mark Curry
Hi, John,
Argh. Actually I was quite pleased when Cliff's paper did NOT have these #1
all over the place. I assumed it was on purpose. I've been on a crusade in
my group to get everyone to DROP these silly #1s all over the place.
Why I hate #1s.
1. They make your code ugly. It ties timing info to something that
really shouldn't have or need timing. No timescale's appear in any
of my RTL because it's not needed. What happens if your clock (from
the testbench) ends up being faster than a #1 ( whatever unit it is )?
2. They cause more problems than than they solve. #1 insertion in our
group has been mix and match. Some have it, some don't. Some add it
to combo blocks as well as flip-flops. With all of these differences,
one starts getting glitches at the RTL level debug. Doesn't really
matter, but's it's disconcerting to see glitches in your waveforms
when you're only runnning RTL.
Oren's #1 (bad pun) reason above is usually easily solvable by turning on
zero delay models, and/or function only models for the gate level portions
of designs.
As to his #2 reason. This is designer preference. I have no problem
debugging waveforms. Actually, doing it this way for so long, I feel I have
a better understanding of the event-scheduling in verilog, and Cliff's
paper made perfect sense!
In the end, it's pretty much still designer preference on the #1 in our
group. But, I'm still not giving up. And I can't keep quiet when someone
else suggests to use 'em!!
- Mark Curry
Texas Instruments Broadband Access Group
|
|
