[SI-LIST] Re: timing analysis
- From: "Peterson, James F (EHCOE)" <james.f.peterson@xxxxxxxxxxxxx>
- To: <si-list@xxxxxxxxxxxxx>
- Date: Mon, 23 Mar 2009 11:34:41 -0400
I always enjoy the timing analysis dialog on the SI-List.
I'll add a couple points to this well-answered thread :
1) this is already been stated, but there is a line you can't cross in
timing analysis... you can squeeze your margin, push the limits, and get
less conservative, but when you're finished, you should have a
defendable position.
2) I agree that the 60xbus can be a challenge. Especially Freescale's
60xbus. Their processor io that drive this bus have rise times of 250ps
(it's crazy to allow a 250ps rise time on a 3.3v driver in a design with
a tco of 5.5ns!!!). At 100MHz, that 250ps rise time makes it very very
difficult to have anything but a point-to-point topology.
Regards,
Jim Peterson
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Gregory R Edlund
Sent: Monday, March 23, 2009 10:10 AM
To: Morton.Harwood@xxxxxx; si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] timing analysis
Mort,
Great posting! Well articulated. I've been thinking about it all
weekend. Over the years, I've had the chance to be involved in many
similar discussions at Cray Research, DEC, and Supercomputer Systems.
They
go straight to the heart of what we do as engineers.
I did timing for the 60x bus a few years ago. Our philosophy was very
similar to yours, but we didn't get much push-back on the margin. One
of
the first things I would ask is whether or not the 100 MHz bus is a
performance bottleneck. You could go through a lot of work to make the
bus run faster only to find out that it didn't buy you anything in
system
performance.
Let's list your statistically independent variables and the underlying
process variables they represent:
1. Driver delay
a. driver chip threshold voltage (gate oxide thickness, doping,
dielectric constant)
b. driver chip effective gate length
2. Receiver setup time
a. receiver chip threshold voltage (gate oxide thickness, doping,
dielectric constant)
b. receiver chip effective gate length
3. Receiver thresholds - track with setup time but don't vary much
4. Transmission line impedance & delay
a. line width
b. dielectric thickness
c. line thickness (to some degree)
d. dielectric constant
6. Clock chip pin-to-pin skew - mostly on-chip and package routing, not
process variation
So you have three main sets of statistically independent variables:
driver
chip, receiver chip, and transmission line. I think you would be
justified in taking a root-sum-square of the delay deviations because
they
are independent, but only the deviations, not the actual delay numbers
themselves. I'm not sure this would buy you 15 MHz. though, and it
could
get squirrely if you have a reflection close to a threshold. You are
correct to question this method and to point back to the physics. As
you
mentioned, you have not yet accounted for crosstalk - or load
capacitance
on the clock input pins.
I find Vih and Vil to be a large source of conservatism on the part of
the
chip suppliers. Threshold windows, as defined by receiver unity gain
points, are typically much smaller than specifications would lead you to
believe. And how about dc and mid-frequency supply voltage variations?
Do
you really need the 5% or 10% silicon designers typically use for
on-chip
static timing analysis?
If you're really motivated to solve this, you could ask your silicon
vendors for a history of their process monitors. (IBM is probably one
of
them.) It they are mature processes (which they probably are), they
might
have them dialed in. Of course, they always have the right to ship you
corner silicon without telling you according to most contracts.
Ultimately, it's a statement of risk vs. performance. You don't have
the
machinery in place to do a complete Monte Carlo analysis using the
process
variables I outlined above. I find it's best to put all the cards on
the
table and make the decision as a team. Then if something blows up,
you're
all in it together! No finger-pointing.
Greg Edlund
Senior Engineer
Signal Integrity and System Timing
IBM Systems & Technology Group
3605 Hwy. 52 N Bldg 050-2
Rochester, MN 55901
Hello all,
I have a question about what other people do for timing analysis
methodology.
My example is a simple synchronous 100 MHz PowerPC 60X bus. The bus has
three devices on it (CPU and two FPGAs). Hundreds of boards have been
built and they all run great, even at temperature extremes. Now, after
the fact (I'm also fixing our process so in the future it won't be
"after the fact"), I am doing a worst-case timing analysis on this bus,
and it shows negative setup timing margin at 100 MHz. This has
rekindled a debate at our company. One camp says we should play it safe
and not run the bus faster than our worst-case timing analysis says.
The other camp says that if we aren't "aggressive" in running faster
than our worst-case timing analysis says, then our products won't be
competitive performance-wise. I'm wondering what other people are doing
when faced with this situation.
As background, let me describe my worst-case timing analysis methodology
for determining setup timing margin. I take the max clock-to-out time
spec from the driver data sheet, and the max input setup time spec from
the receiver data sheet. I get the interconnect delay from a HyperLynx
simulation using slow-weak IBIS. I am properly subtracting out the
delay from running a separate reference load simulation, which HyperLynx
refers to as "flight-time compensation". I make sure that, in my
receiver IBIS file, vinl and vinh match the worst-case data sheet
values. I make sure that, in my driver IBIS file, the reference load
matches the data sheet reference load. For my PCB stackup, I adjust the
dielectric constant to be 10% greater than nominal, and I adjust the
characteristic impedance to be 10% lower than nominal (we are using
controlled impedance), since I expect this should be worst-case from a
setup time perspective. I use the max output skew and jitter specs from
the clock driver data sheet. I also simulate the clock traces in
HyperLynx to get the delays, in order to get the skew there. Whatever
clock driver IBIS setting (fast-strong, slow-weak, typical) I use to
simulate one clock trace, I also use that to simulate the other clock
trace, since both clock traces are driven by the same clock
driver...i.e. same PVT. I take all the resulting delays (driver
clock-to-out, interconnect delay, receiver setup, clock skew, etc.) and
simply subtract them all from my timing path (which is 10 ns for 100
MHz).
As I mentioned, there is a camp in our company that says the methodology
I described above is too pessimistic. As evidence, they point to the
fact that all our boards work at 100 MHz over temperature, even though
worst-case timing analysis says we have negative margin above 85 MHz.
They are asking me to adjust my methodology in order to show positive
"worst-case" margin at 100 MHz.
I can accept the fact that the boards pass test at 100 MHz even though
worst-case timing analysis says 85 MHz; this just means not everything
is worst-case on these particular boards.
What I don't really see, however, is how I can legitimately change the
numbers "on paper" to show other than 85 MHz as the worst-case limit.
This is what a certain group of people are asking me for, claiming that
we need to be more "aggressive" -- perhaps by taking an RMS
(root-mean-square) sum of delays or something of that nature -- instead
of subtracting from the 10 ns path a straight sum of delays like I am
doing. Another idea is to reduce the delays by some percentage to be
less than worst-case. (I counter with the argument that even though I
describe my timing analysis methodology as "worst-case", it actually
doesn't even consider the effects of noise -- such as from the power
distribution network or crosstalk. So I could make my timing analysis
even more pessimistic by adding some noise margin to the data sheet
values for vinl and vinh. And regarding an RMS sum of timing delays, I
think that's a fudge, not a valid method.)
Well anyway I'm wondering what alternative timing analysis methodologies
other people use, or how other people deal with this situation at their
companies.
Thanks very much if you have comments.
Mort
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List technical documents are available at:
http://www.si-list.net
List archives are viewable at:
//www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List technical documents are available at:
http://www.si-list.net
List archives are viewable at:
//www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
Other related posts:
