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

tomda (tom_dagostino@mentorg.com)
Mon, 26 Jul 1999 09:22:35 -0700

Tom Dagostino

-----Original Message-----
From: Roy Leventhal [SMTP:Roy_Leventhal@mw.3com.com]
Sent: Friday, July 23, 1999 5:35 PM
To: si-list@silab.eng.sun.com
Subject: RE: [SI-LIST] : Best type of models, edge rates & load

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" <Robert.Haller@compaq.com> on 07/22/99 07:57:34 AM

Please respond to si-list@silab.eng.sun.com

Sent by: "Haller, Robert" <Robert.Haller@compaq.com>

To: "'si-list @silab.eng.sun.com'" <si-list@silab.eng.sun.com>
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
robert.haller@compaq.com

-----Original Message-----
From: Roy Leventhal [mailto:Roy_Leventhal@mw.3com.com]
Sent: Wednesday, July 21, 1999 2:33 PM
To: si-list@silab.eng.sun.com
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 switc
hing
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" <dc.sessions@vlsi.com> on 07/21/99 11:54:43 AM

Please respond to si-list@silab.eng.sun.com

Sent by: "D. C. Sessions" <dc.sessions@vlsi.com>

To: si-list@silab.eng.sun.com
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:richard.mellitz@intel.com]
> Sent: Tuesday, 20 July, 1999 11:54 PM
> To: 'si-list@silab.eng.sun.com'
> 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:markn@rccorp.com]
> Sent: Tuesday, July 20, 1999 11:57 AM
> To: si-list@silab.eng.sun.com
> 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
> majordomo@silab.eng.sun.com. 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
> majordomo@silab.eng.sun.com. 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
> majordomo@silab.eng.sun.com. 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
majordomo@silab.eng.sun.com.
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
dc.sessions@vlsi.com

**** To unsubscribe from si-list: send e-mail to majordomo@silab.eng.sun.com. 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 majordomo@silab.eng.sun.com. 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 majordomo@silab.eng.sun.com. 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 majordomo@silab.eng.sun.com. 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 majordomo@silab.eng.sun.com. 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 ****