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:[email protected]]
> Sent: Friday, July 23, 1999 5:35 PM
> To: [email protected]
> 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" <[email protected]> on 07/22/99 07:57:34 AM
>
> Please respond to [email protected]
>
> Sent by: "Haller, Robert" <[email protected]>
>
> To: "'si-list @silab.eng.sun.com'" <[email protected]>
> 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
> [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 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" <[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 ****
**** 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 ****