( ESNUG 409 Item 1 ) -------------------------------------------- [03/25/03]
Subject: ( ESNUG 395 #8 ) Coping With IBM's 12% On-Chip Timing Variations
> Our current ASIC vendor, IBM, is having us do timing analysis with an
> on-chip variation of 12%, applied to both cell delays and
> interconnect delays.
>
> This makes certain kinds of timing very difficult to pass. For example,
> using a PLL to zero out a 5 ns insertion delay requires a 5ns feedback
> path. But 12% variation between the two is 600 ps, which is a big chunk
> of time these days. Source-synchronous interfaces have similar problems.
>
> How realistic is this sort of thing? Has anyone done a paper on this?
>
> - Paul Zimmer
> Cisco Systems
From: Howard Landman <domain=riverrock.org user=howard>
Hi, John,
Srinivas Kakumanu wrote in his ESNUG 395 #8 reply to Paul's question that
4-corner analysis "is an alternative to the on-chip-variance in PrimeTime".
I must disagree. Consider two distinct paths, perhaps in a manually-laid-
out clock tree, which have exactly equivalent layouts. Any corner analysis
will say that they are the same since the computation is given exactly the
same transistor sizes and parasitics; therefore it will show no difference.
But the On-Chip Variance (OCV) could be as much as half a nanosecond!
Paul Zimmer asks: "If your path goes through 20 or so elements, and the
variation is sort-of random, isn't all-min vs all-max a little extreme?"
Yes it is. The mathematics of it would be that if you had N stages which
all had equal delay, and you model OCV as independent random variables,
then the variance goes up linearly with N and the standard deviation goes
up as the square root of N. So you'd expect 16 equal stages to be about
four times as bad as one stage.
However any deviation from the above assumptions could make it worse. For
example, some of the variation can be systematic rather than independent.
Or not all the stages could be equal in delay. And some of these sources
of variation are linear, not square-root. So a simplified but moderately
realistic model of OCV might look something like:
On-Chip Variance (OCV) = a*D + (b*D)/sqrt(N)
where D is the total path delay from the point at which the two paths
diverged. It seems that most tool (and silicon) vendors simplify this
further to just a linear model. This isn't quite right, but it's not
too unreasonable.
Matt Weber writes "IBM is the only ASIC vendor I know of that requires
this analysis". I know of at least one other, but I'm under NDA. :-) His
discussion of common path pessimism removal was excellent, and this issue
is critical in OCV analysis; so I'd recommend everyone read it through
carefully and make sure they understand it. The only thing I'd change is
that I'd put more emphasis on hold checks - in my experience they are often
the biggest problem from OCV because of the added clock skew and the large
number of delay elements needed to fix a big hold violation.
The moral of the story: Keep your clock tree insertion delay as low as
possible, or use clock distribution methods which are not subject to
as much OCV as a tree. For example, in the Emotion Engine of the Sony
PlayStation 2, the last stage of the clock network is a mesh with all
outputs shorted together. This smooths out OCV-induced skews, although
you need to analyze possible EM problems caused by not all the drivers
switching at the same time.
- Howard A. Landman
Riverrock Consulting Fort Collins, CO
|
|
