RE: [SI-LIST] : Best type of models, edge rates & load

Roy Leventhal ([email protected])
Fri, 23 Jul 1999 19:35:05 -0500

Bob,

You may be observing the same thing I was warned of where a simulator in
calculating propagation (wire) delay compensates for (subtracts) buffer delay
and can end up with negative numbers for propagation delay. This happens when
the buffer delay stored with the model is significantly larger than the actual
buffer delay simulated. That is what you would expect when the stored buffer
delay was a heavily loaded case and the simulated buffer delay is a lightly
loaded case. Usually, a simulator can recalculate the buffer delay and store the
correct value for the lightly loaded case for use in extracting wire delay. But,
you may have to remember to manually intervene and instruct the simulator to do
so.

This is pretty much what you have written. But, I thought I would restate it
from that perspective.

My real reason for responding is the continuing discussion of correlation of
tested values for specification numbers with simulations, results from different
test setups, etc.

First, it bears repeating that all rise/fall (and related numbers) are not
created equal. There is the historical convention of measuring rise/fall between
10% to 90% of low steady state to high steady state. This applied to situations
where the expected swing would be, say 0 V to Vcc. Then there is the IBIS
convention of 20% to 80% of low steady state to high steady state. But, output
swing might be -Vcc to +2Vcc and there might be the non-linearities of clamps
present. Finally, there are various semiconductor house data sheet conventions
such as the "transition (rise/fall) time" measurement of 30% to 70% of low
steady state to high steady state. Needless to say, confusion can arise.

Next, there are the magnitude of the switching currents, loading, etc., that can
differ from situation to situation as you, D.C. Sessions and others have pointed
out. This is why we often desire that semiconductor houses or others set up test
fixtures that duplicate our actual in-use situation. This request often leads to
grief for the semiconductor house for reasons that I'll illustrate. Further,
there is the issue of the actual units tested an/or simulated and whether they
have been correlated from fixture to fixture, etc.

Then there is the possibility that the ringing for a given test fixture
situation or simulation may be such that the "steady state" high or low state is
never really reached. Testing and/or simulation then becomes very
non-repeatable. At the switching speeds we are considering merely moving a cable
or standing closer to a test fixture can change the result. More so if you have
a measurement on a waveform with excessive ringing.

I was involved in cleaning up a production test situation. A policy had been
followed that resulted in a few thousand high speed testing fixtures, each one
built to a customer submitted test circuit. The fixtures had not been laid out
or bypassed with a sensitivity to high frequency issues. Switching speeds were
usually only a few nanoseconds or less. Therefore, the majority of them rang
excessively. Often, the switching currents differed by only a small amount from
fixture to fixture, yet there were all the issues with getting the test setup
right. There were equipment accuracy and measurement dispersion issues to deal
with. I could go on.

There was no such thing as repeatability, verification and quality control in
this situation.

Obviously, the place to start is to simplify (standardized) the production test
situation. Clean (RF / high-speed switching wise) up the customer test fixtures.
Correlate them to a standardized (high, medium or low switching current)
production test fixture - usually left permanently set up on the test floor.

Etc.

I will tell you with certainty that ALL the problems went away. Further,
meaningful comparisons could be made between product lines and good information
was fed to product characterization, statistical process control etc.

The point of my story is that correlation and verification of specifications can
be difficult and suppliers may be resistant to non-standard product and/or
testing. While we may have very legitimate needs for selectable edge rates and
good characterization of models under our particular design conditions.

I think early simulation, pro-activity RE: possible supplier responses, and
co-operative agreements will be keys to success in high speed digital products.
Device characteristics that are well centered in their product application
windows with lots of design margin (Six Sigma) are what we want to target.
Marginal applications lead to excessive efforts at correlation, control, problem
solving and aggravation. Excessive edge rates (i.e., MUCH shorter (less than 5%)
than their highest intended clock speeds) are not the way to go. There is more
than enough work to go around for signal integrity engineers without make-work
dumb problems.

In today's world of shrunken feature sizes Some Semiconductor Edge Rates Are Way
Too Fast.

Regards,

Roy

"Haller, Robert" <[email protected]> on 07/22/99 07:57:34 AM

Please respond to [email protected]

Sent by: "Haller, Robert" <[email protected]>

To: "'si-list @silab.eng.sun.com'" <[email protected]>
cc: (Roy Leventhal/MW/US/3Com)
Subject: RE: [SI-LIST] : Best type of models, edge rates & load

Roy and D.C.,

I have found if your actual load is close to or larger then the
"standard load" then the time of flight calculation appear reasonable. (Time
of flight is the difference between your I/O driver driving the standard
load and the I/O driver driving the actual load, usually calculated by your
behavioral simulator). By reasonable, I mean the numbers look positive which
seems to make sense to a casual observer. But when you drive loads lighter
than you standard load (which happens often for today's topologies and
technologies) the time of flight comes out negative. I have spent a lot of
time explaining why this happens to bewildered engineers and I think there
are 2 key points for the discussion.

1. When you (or your timing verifier) adds up all the delay contributors in
the path like I/O cell delay, time of flight, skew, ... etc. it is
important that there is no double counting or missing contributors and thus
you will calculate an accurate setup and hold slack (or lack thereof).

2. If you plot capacitance versus delay for a particular I/O cell (this is
done in ASIC I/O cell data books) and it is linear between the capacitance
of YOUR load and the capacitance of the Standard load, then the delta
calculation between the I/O driver driving the actual and standard load will
be accurate (and just ignore the casual observer). If you intentionally make
your standard load 'close' to your actual load then the possibility for
error is reduced. Most semiconductor users can not define the standard load,
but if the folks who do this definition used more realistic loads (that IBIS
can handle, or maybe we can enhance IBIS) then the possibility for error in
the calculation can be minimized.

I have noticed that some vendors (specifically high speed cache Rams) have
started a nice trend of using terminated transmission lines, which is closer
to a real load than a 50 pF cap. I hope this trend continues. There are not
to many 50 pF loads in the servers I work on :-) .

This is just my opinion..... bob

Robert J. Haller
Compaq Computer Corporation
AlphaServer Product Development
Phone: (978) 493-4112
Fax: (978) 493-0941
[email protected]

-----Original Message-----
From: Roy Leventhal [mailto:[email protected]]
Sent: Wednesday, July 21, 1999 2:33 PM
To: [email protected]
Subject: Re: [SI-LIST] : Best type of models, edge rates & load

D.C.

It seems to me too that the assumption of behavioral modeling under IBIS is
that
switching behavior is
quite non-linear and best handled with V-I & V-T curves fed into a Bergeron
Method Reflection Diagram simulator for the IC elements, a SPICE model
simulator
for terminations, etc., and an RLGC field solver matrix extractor for the
distributed structures (transmission lines, connectors, cables) seems to be
working out well. Especially for modeling large signal non-linear behavior.
That
way we don't get into Miller capacitance, die thermal resistance and a whole
host of other things that are usually only valid under linear, small signal
assumptions anyway. Or, am I missing something?

True, we loose something when we increase the level of abstraction as in
IBIS.
We can't for instance model the effects of power supply regulation directly.
But, are we attempting to blend the device physics world with the abstracted
IBIS model world here in an entirely productive discussion?

I do agree that we need some realistic characterizations of buffer switching
speeds into transmission line loads as opposed to 30pf (45pf, 50pf, what?)
low
pass filter. and some work on the standards and definitions of Tco and other
parameters.

Best Regards,

Roy

"D. C. Sessions" <[email protected]> on 07/21/99 11:54:43 AM

Please respond to [email protected]

Sent by: "D. C. Sessions" <[email protected]>

To: [email protected]
cc: (Roy Leventhal/MW/US/3Com)
Subject: Re: [SI-LIST] : Best type of models, edge rates & load

"Beal, Weston" wrote:
>
> Richard,
>
> Would you please explain your statement, "Actually it would be more
accurate
> to get the VT data with out even the
> buffer capacitance." It seems to me that removing capacitance that exists
> is as bad as adding capacitance that doesn't exist.

The objective is to describe, in as much detail as possible, phenomena that
aren't easily calculated such as capacitance. The V/T plots are there to
indicate the predriver behavior, and ANY capacitance hides some of that
information by filtering out high frequencies.

That said, it's probably not worth worrying about. There are second-order
effects (thanks to Miller capacitance) that aren't readily accounted for in
IBIS and which have more effect than small amounts of driver capacitance.

> -----Original Message-----
> From: Mellitz, Richard
[mailto:[email protected]]
> Sent: Tuesday, 20 July, 1999 11:54 PM
> To: '[email protected]'
> Subject: RE: [SI-LIST] : Best type of models, edge
> rates & load
>
> Actually it would be more accurate to get the VT data with
> out even the
> buffer capacitance. That raises some interesting testing
> problems when it
> comes to determining real Tco. The problem is that the
> behavioral models are
> most accurate when the Tco, VT, and IV is defined at the
> load of the target
> design.
> Richard Mellitz
> Intel
> -----Original Message-----
> From: Mark Nass [mailto:[email protected]]
> Sent: Tuesday, July 20, 1999 11:57 AM
> To: [email protected]
> Subject: Re: [SI-LIST] : Best type of models, edge rates &
> load
>
> We are not a foundry, just design the logic and rely on
> the foundry to
> provide
> HSPICE models. No magic with the models just use HSPICE
> models and vary the
> process and temperature.
>
> Weak models are > Slow process, high temp and low voltage
> typical models are > typical process, nominal temp &
voltage
> Strong models are > Fast process, low temp and high
voltage
>
> I have no control over the accuracy of the HSPICE
models,
> they come from
> the
> foundry. I am just curious if any knowledgeable people out
> there have
> definite
> ideas on which parameters are best for generating Tco
values
> and IBIS models
> that they have had good results with. I think I hear
> everybody agreeing that
> 40pf is not useful, so then my question is what is useful?
>
> Mark
>
> At 04:58 PM 7/20/99 -0500, you wrote:
> >
> >
> >Mark Nass wrote:
> >>
> >> There has been some discussion recently about
> parameters of parts
> >> specified into 40pf caps and accuracy of models. I
> generate this type
> >> of data for our devices for our own use and our
> customers. So I am
> >> curious as to what people think would be the optimal
way
> to generate
> >> Tco, Tsu, jitter parameters and IBIS models so that
they
> would be
> confident
> >> they were getting exactly what they needed for signal
> integrity and
> timing
> >> analysis. Any feedback?
> >>
> >> Mark Nass
> >
> >
> >Mark,
> >
> >Can your provide the SI community some insight on how you
> generate these
> >parameters now. Specifically, do you take measurements
on
> a number
> >of different samples over temp/voltage ranges and with
> different loads?
> >Are they SPICE derived? Do you specify a certain amount
of
> 'cushion'
> >in the parameters? This might be helpful to those of us
> who don't know
> >how vendors derive the numbers.
> >
> >Thanks,
> >David Haedge
> >Raytheon
> >
> >**** To unsubscribe from si-list: send e-mail to
> [email protected]. In the BODY of message put:
> UNSUBSCRIBE
> si-list, for more help, put HELP. si-list archives are
> accessible at
> http://www.qsl.net/wb6tpu/si-list ****
> >
> >
> >
>
> **** To unsubscribe from si-list: send e-mail to
> [email protected]. In the BODY of message put:
> UNSUBSCRIBE
> si-list, for more help, put HELP. si-list archives are
> accessible at
> http://www.qsl.net/wb6tpu/si-list ****
>
> **** To unsubscribe from si-list: send e-mail to
> [email protected]. In the BODY of message put: UNSUBSCRIBE
> si-list, for more help, put HELP. si-list archives are accessible at
> http://www.qsl.net/wb6tpu/si-list ****
>
> **** To unsubscribe from si-list: send e-mail to
[email protected].
In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP.
si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list ****

--
D. C. Sessions
[email protected]

**** To unsubscribe from si-list: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list ****

**** To unsubscribe from si-list: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list ****

**** To unsubscribe from si-list: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list ****

**** To unsubscribe from si-list: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list ****