( ESNUG 227 Item 3 ) ---------------------------------------------- [10/13/95]
[ Editor's Warning: DON'T DRIVE CLOCKS (EVEN WITH INFINITE DRIVE!) What
follows is not a quasi-academic discussion of an obscure Synopsys bug,
but something that was an independent confirmation of a nasty show-stopper
I just got back from helping a client on. To better understand what
Steve is describing, here's a quickie Synopsys timing tutorial:
Total Delay = Edge Delay + Intrinsic Delay +
Transition Delay + Connect Delay
Edge Delay: The delay from an input pin to an output pin because of the
slow rise or fall being applied at the input pin.
Intrinsic Delay: The build-in delay from the input to an output of a gate
(usually output resistance mulpitied by the sum of loads.)
Transition Delay: The delay due to capacitive loading on a gate's output.
Connect Delay: the time it takes for a waveform to travel along a wire.
NOTE: Setting infinite drives on clock pins, for some reason, doesn't get
rid of the Transition Delay that Design Compiler sees. - John ]
From: sgolson@trilobyte.com (Steve Golson)
Subject: (ESNUG 220 #5 221 #2) "Non-Linear Libs, Weird Delays & Clock Drives"
John,
Here's a follow-up on my weird timing problem as reported in ESNUG 221,
the problem appears as follows:
> Run report_timing and see a path with 20 ns delay, then put a
> non-inifinite drive on the clock pin with "set_driving_cell" and
> report_timing shows 210 ns delay. A 10X delay gain!
According to Synopsys, here is what is going on:
1. Setting a drive on a clock port has problems. With an "ideal" clock you
get 0 ns propagation delay and thus the drive strength is ignored, however
you *will* get a transition delay. This transition delay will be *huge*
because the load on the clock is large.
2. The non-linear delay model (NLDM) tables in the library are not
characterized to handle such huge transition delays. As a result you
may end up with *negative* propagation delays.
3. Design Compiler uses the largest transition delay it can find, rather
than the transition delay for the critical path.
The result is that you get calculated delays that are totally bogus.
Here are my comments on each item above:
1. Do not put a drive on a clock port (unless you plan to use
"set_clock_skew -propagated"). Be careful using "all_inputs()" with
"set_driving_cell". A STAR has been filed, so that Design Compiler will
ignore the driving cell on ideal clocks.
2. If you have the library sources you can use report_delay_calculation to
try and figure out what is going on. Without access to the library
sources, how can a user hope to know if the NLDM tables are being pushed
past their characterized limits?
Enhancement request: all library tables should have a characterization
limit specified by the vendor, and if Design Compiler ever exceeds that
limit, a warning is output.
This is a Design Compiler bug. A STAR has been filed. You can use
set_disable_timing in the v3.3b release to guide Design Compiler to pick
the correct transition value.
- Steve Golson
Trilobyte Systems
|
|
