RE: [sv-bc] time unit specification

An interesting discussion but I don't think there is a problem with 
the description of timescales with the possible exception of how they 
work with $unit (I don't do $unit so I have not seen this issue).

RTL models do not need a timescale as long as none of the models 
compiled has a timescale or as long as the first model compiled has a 
timescale.

I put a timescale in my testbench and compile it first. After that, 
0-delay RTL models compile just fine.

I always give these timescale guidelines:
(1) If the module has a delay, add a timescale in front of the module 
- otherwise you are at compile-order mercy with other timescales in the design.
(2) Put a timescale in the testbench module and compile it first. 
This becomes the default timescale if subsequently compiled files do 
not have a timescale (but still obey guideline #1).

I further explain that if you compile a 0-delay RTL model with no 
timescale or some other testbench module with delays but without a 
timescale (which would violate my first guideline), the compiler 
assumes that a default timescale is fine (and different vendors have 
different default timescales), but then if a subsequent file has a 
timescale, the compiler basically cries "whoaa!" (funny to hear a 
compiler cry! :-) ), "you just changed the rules about delays in the 
design. First you said I could use default values for delays but now 
you claim that delays have specific meaning. You just changed the 
rules about delays in the design. Go fix the first files and try 
again!" (very verbose compiler!)

The only part missing from section 3.14.2.1 as quoted by Shalom is 
that if another timescale is read, it becomes the new default for all 
files read after the last timescale read and reading more files with 
more timescale directives keeps resetting the defaults for all files 
read after each new timescale becomes active.

Years ago I used IP from a vendor who did not add a timescale to the 
model. After some time, the model started running ten times too fast. 
We had added more modules to the design, the compile order changed 
and the vendor IP was now compiled after a module with a faster 
timescale. I was not amused that the vendor had failed to add a 
timescale to their design.

I tell engineers that like most compiler directives, timescales are 
compile-order dependent.

The reason we need to include timescales in the first file read if 
subsequent files have a timescale is because the vendors did not 
agree what the default timescale value should be. I don't have a 
problem with that. With a couple of guidelines, all timescale problems go away.

Regards - Cliff

At 01:34 AM 11/20/2008, jonathan.bromley@doulos.com wrote:
>It may be that this could be resolved simply, at the same time fixing
>a tiresome feature of Verilog that afflicts RTL designers.
>
>Many RTL designs contain no non-zero time delays of any kind.  It is
>irksome to be obliged to add a completely redundant
>timescale/unit/precision to such design files merely to avoid
>errors from simulators that strictly enforce the "all or none"
>rule; such a timescale plays no role in the RTL design.  If the
>"all or none" rule  were changed to apply not to every design
>unit, but instead to every #time delay in the elaborated
>model, then my RTL problem would go away and so, I suspect,
>would most of the related issues about $unit.
>
>(Caveat: there might be some issues about "#time delay"; it's
>clear, for example, that the #0 syntax in deferred assertions
>doesn't count as a time delay for the purposes of this argument,
>and it's not obvious whether #0 and #1step in clocking blocks
>should either.)
>--
>Jonathan Bromley
>Consultant

At 01:43 AM 11/20/2008, you wrote:
This is made more confusing by the first sentence in 3.14.2.1, which
says,

"The `timescale compiler directive specifies the *default* time unit and
precision for all design elements that follow this directive and that do
not have timeunit and timeprecision constructs specified within the
design element.

Shalom


----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, SystemVerilog, Synthesis and Verification Training


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.