( ESNUG 366 Item 6 ) --------------------------------------------- [02/23/01]
Subject: ( ESNUG 365 #11 ) PrimeTime With Real & Falsely Monotonic Libs
> 1. You do need the cell delays to be monotonically increasing with output
> capacitance. This is I belive, quite a realistic requirement. If for
> some reason your library is not monotonic with increasing load, then I
> think its a library problem.
>
> - [ One Of The Lessor Pokemon ]
From: Keith Howick <howick@siliconmetrics.com>
John,
I was glad to see that many people agreed with Ajay's complaint, but was
disappointed to see the belief that cell delays must be monotonically
increasing with time. In my own experience characterizing hundreds of cell
libraries I've seen several with cells that exhibit real non-monotonic
behavior (and many more that exhibit false non-monotonic behavior). Though
uncommon, real behavior is usually a result of:
(1) Slew-control circuitry. This is most often the case for I/O cells,
but sometimes appears unintentionally in high-drive internal cells
because of how the cell was designed or extracted. If large output
transistors are broken apart and placed in parallel with some parasitic
resistance between them, a basic slew-control circuit is created.
Resistance isn't regularly extracted today, but it's becoming more
popular as frequency increases.
(2) Miller capacitance between complimentary output pins (e.g., Q and
QB on a flip-flop). How a secondary output is loaded can have a
dramatic affect on the delay behavior of the primary pin-under-test.
This is especially true if a large single-stage inverter separates the
pins. Though the value of capacitance seen through the miller effect is
constant vs. slew when measuring through a complete state transition,
the plot of current used to charge and discharge the miller capacitance
is not. This has a non-monotonic affect on the circuit's delay as
output load changes the output slew.
(3) Finally, and very rarely, if a small cell is characterized across a
large enough sweep of slew it can appear like a band-pass filter, and a
"duck-tail" appears at the very end of both the slew and load sweeps.
This is very rare as most people aren't interested in the very long
slews required to see it, but it crops up from time to time. Though
I've never taken the time to fully investigate the phenomena, I do know
from experimentation that the effect is sensitive to imbalances between
N and PMOS drive strengths and the hysteresis caused by disparate totem
thresholds.
However, what's the #1 reason for non-monotonic delay behavior across load?
Simulator Accuracy! I've too often met library developers that try to
meet unrealistic library development schedules by dialing-back the
accuracy of their characterizing simulations. Nothing will cause
non-monotonic behavior faster than this, and the behavior often looks
quite random. It's unfortunate that many managers consider library
development to be of small importance and require it to complete
rapidly, even though it's usually the some of the most leveragable time
spent in any design's development.
I agree that non-monotonic behavior is undesirable, but it nevertheless exists.
Ridding a library of it requires giving in to one or more truths of library
development. Developers and users must:
* increase simulator accuracy
* reduce the range of load and slew sweeps
* pay close attention to how cells are designed and extracted
* and know which cells will exhibit non-monotonic behavior anyway.
Thanks for your efforts with ESNUG, John! I enjoy the list immensely.
- Keith Howick, Sr. Methodology Engineer
Silicon Metrics Corp.
---- ---- ---- ---- ---- ---- ----
> A cell's library data is created by simulating the cell with a set of
> different output capacitances. If this output capacitance is increased,
> then it will take more time to charge up, and the delay and slew times
> will both increase as well. This sensitivity to output capacitance is
> used by PrimeTime to set the drive resistance in its driver models used
> in RC delay calculation. Therefore, PrimeTime uses this physics rule
> and requires that delay and slew in the cell's library data to both
> increase as output capacitance increases. A violation of this rule
> in the library data prevents PrimeTime from creating a driver model
> since the drive resistance will not be positive. A failure to create
> a driver model subsequently prevents any calculation of C_effective.
>
> - [ PrimeTime Tech Support ]
From: [ The Librarian ]
Johm - keep me anonymous, please. Just call me "The Librarian."
Delay and slew times will not always increase with capacitance; if the
capacitance is low enough and the input ramp large enough, you get the DC
transfer curve you remember from your undergrad days. The output waveform
depends only on the input ramp.
In theory your characterized cell would show the same ramp time for a range
of increasing capacitance here, but SPICE gets in the way. For the same
circuit, the same input ramp time, the same output load, but slightly
different characterization parameters, you will get delay and ramp variance
of about 0.5% just due to "numerical noise" in SPICE. This error can be
reduced but not totally eliminated by using a smaller TSTEP, but of course
that makes characterization take much longer.
If you have SPICE (and device models) available, measure the delay and ramp
of an inverter or buffer with a fixed load and input ramp as TSTEP
changes. Better yet, measure them when your input ramp starts at 1.01 *
TSTEP, 1.02 * TSTEP, etc. (don't laugh; I've seen SPICE decks that change
in the middle of a TSTEP increment). The results will surprise you as much
as they surprised me when I was trying to correlate SPICE to libraries.
Operating in the region where output ramp time does not depend on output
load is inefficient (lots of crowbar current) but not all library vendors
assign operating condition limits on a cell-by-cell basis. Thus there may
be cells operating in these odd corners and the 0.5% numerical error will
bite you.
If the no-dependency-on-output-load pops up outside the low-load, high-ramp
corner, the library probably has a problem. But in this corner, the
"negative drive resistance" is probably SPICE noise and you probably want
PrimeTime to assume a fixed delay within that narrow load range.
- [ The Librarian ]
|
|
