Actually, the best way to find out is to experiment. Once you have
set up spice to ibis to perform the extractions, it is easy to perform
multiple extractions and test the results in your simulator against
varying load conditions.
Setup the identical test case in you ibis simulator and in spice.
Perform the "exact" spice simulation. Then perform ibis simulations
with the different extracted models and compare the results. Once done,
you will know which extraction to use.
scott
Mark Nass wrote:
> Bob,
>
> Could you expand on this a little bit. Lets say you are going to derive
> Tco(Clock to out) values and IBIS models from HSPICE models for a driver
> driving a memory bus. The memory bus can have 1 DIMM with 1 load populated
> (4.5pf load)or 4 dimms with 2 loads(36pf load. Lets assume a 60 ohm board
> impedance.
> What loading parameters would you use to get the most accurate simulations?
> Would you use the standard 50 ohm pullup & pulldown for the 4 rising &
> falling
> waveform generation in IBIS . And for Tco use a 60 ohm xline into 20pf? How
> long would the xline be?
> Or would you use a 60 ohm pullup & pulldown plus 20pf cap for the 4 rising
> & falling waveform generation also?
> Or something different?
>
> Mark
>
> At 08:57 AM 7/22/99 -0400, you wrote:
> >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 ****
**** 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 ****