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

Adrian Shiner (adrian.shiner@virgin.net)
Mon, 26 Jul 1999 21:42:49 +0100

Surely all this data sheet spec rise & fall times info is becoming "foo dust" as switches become faster? The slew rate of a voltage waveform at a given point on a printed circuit, driven from a perfect switch (zero switch time)
depends solely on the current source/ sink capability of the generator being switched, its approximation to a current or voltage source and the circuit impedance.
Why don't the IC manufacturers defne the output driver broadly in line with the above?

On the subject of semiconductor properties definition, In a broad band (500kHz to 150MHz) physically short antenna amplifier application: I get higher gain from an input circuit using 2N4393 FETs than using BF245A FETs. The former
is a switch, the later is a VHF/UHF amplifier device. Strange world !!

tomda wrote:

> Roy
>
> Most of what you said sounds good but I'm not sure about your voltage swing
> range. The parts will swing within the range of GND to Vcc but the
> external system may cause voltage swings greater because of reflections.
> That increased swing is not part of the switching characteristic that is
> supposed to be modeled by IBIS but is what the SI simulator is supposed to
> tell you.
>
> >From my historical perspective 10 to 90% risetimes came from the scope
> manufacturers and academia. Motorola with its ECL logic families in the
> 60's started with the 20 to 80% numbers and I think that, the semiconductor
> industry, is where IBIS got the 20-80 standard. It also shows the highest
> slew rate area. I've not seen the 30-70% numbers before though, that's
> less than 50% of the swing.
>
> 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 ****

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