[SI-LIST] Re: John De Falco paper on crosstalk

 
http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F8128%2F22796%2F01057902.pdf%3Farnumber%3D1057902&authDecision=-203


Brian Schieck
NVIDIA Corporation
2701 San Tomas Expressway
MS-12 / E133
Santa Clara, California   95050
Direct Phone #  (408) 486-2697
Main Phone  #  (408) 486-2000
Facsimile      #  (408) 486-4697 Email Delivery
Facsimile      #  (408) 486-2902 Hard Copy
Email                 bschieck@xxxxxxxxxx



-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On 
Behalf Of David Oka
Sent: Monday, March 23, 2009 1:09 PM
To: 'Bradley Henson'; 'Peterson, James F (EHCOE)'
Cc: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: John De Falco paper on crosstalk

I've looked on the internet and the IEEE site and have not found a copy of
this John De Falco article on crosstalk. I've found several references to
the article and would like to read it. Can anyone scan and email me a copy?

David Oka

Ps. I'm pretty sure that my father worked with John at Honeywell and that
I've met him when I was a college student studying EE in the late 70's.

-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On
Behalf Of Bradley Henson
Sent: Monday, March 23, 2009 12:12 PM
To: Peterson, James F (EHCOE)
Cc: si-list@xxxxxxxxxxxxx; si-list-bounce@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: timing analysis

Excellent posts.
I grew up in digital processing in the early 80's learning Signal
Integrity before it had a name. We read John De Falco on XTALK, used
Teledeltos conductive telegraphers paper to model crosstalk (!), and ran
batch SPICE with punch cards!!! I even made crude IBIS models of IC output
stages after curve-tracing I/Os and scoping dV/dT! These early experiences
were usually based on hardware problems: I was part of a fix-it team. We
learned as a group to *add* more margin. In other words, what came out of
these investigations was to design to a higher Fmax (or shorter clock
period) to allow for uncertainties and tolerance build up at various
levels of test (vendor's component test, SPICE accuracy, module test, unit
test, System test etc.).

By the late-80's I had earned the reputation to lead my own design effort
and be responsible for large processor design project approach, margins
and so forth. I fought the exact same battles described in this email
trail: RMS/RSS, too conservative, tweak the analysis, semiconductors are
never worst case etc. As Jim articulated, you can sharpen the pencil, but
there are limits. I never went past the limits I thought I could defend if
things went wrong. When the customer or situation dictated a "compromise"
greater than I felt was prudent, it was well documented, and. like Jim, I
used a Team approach, making sure all members, including the customer,
understood all aspects and bought into the proposed compromise.

It's been over 20 years and many new programs since my first big
processor, and almost without exception, those that overruled me were
sorry at some point down the line. Many times problems took years to show
up: a part change, a software activity change, and so forth. Now, many
processors later,  most of those that used to push back and call me too
conservative seek me out for their projects: My designs are proven to be
robust over time and variables. Follow the sage advice in this thread,
stick by solid, documented defensible good practice and get informed team
buy-in at all levels.

These are the fun battles you'll remember throughout your career. Relish
it.

Brad




"Peterson, James F (EHCOE)" <james.f.peterson@xxxxxxxxxxxxx>
Sent by: si-list-bounce@xxxxxxxxxxxxx
03/23/2009 08:37 AM

To
<si-list@xxxxxxxxxxxxx>
cc

Subject
[SI-LIST] Re: timing analysis






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







------------------------------------------------------------------
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


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
------------------------------------------------------------------
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: