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