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

Mark Nass ([email protected])
Thu, 22 Jul 1999 08:48:56 +0100

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