[SI-LIST] Re: timing analysis

Mort,
        You are performing a worst case analysis which will in general provide 
a conservative and robust design. There are assumptions and approximations 
built into the simulation algorithms and models and often worst case 
specifications are conservative. But you are designing a bus/system that you 
need to insure is robust over the product lifetime (5 years?), and there are 
certainly effects that you are not including in your analysis (Power 
Distribution, SSO, crosstalk, ...). You may find if you do a very detailed 
comparison between simulations and measurement, that the longest nets will show 
most margin.

In a server design quite some time ago, we had access to a relatively large 
sample size of shipping product, which we were able to test and create a 
statistically significant sample size. We tested at an increase frequency to 
determine margin and then implement an ongoing (sample) manufacturing screen. 
That in conjunction with minor modifications to improve performance on marginal 
worst case nets, created a mid-life kicker that realized a significant 
performance improvement without significant cost increase.

Regards,
Bob Haller
HW Architect
Enterasys networks

-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On 
Behalf Of Harwood, Morton (GE Infra, Aviation, US)
Sent: Friday, March 20, 2009 3:08 PM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] timing analysis

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:
http://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:
                http://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:
http://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:     
                http://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: