[SI-LIST] Re: Rise / Fall time
- From: "Lynne D. Green" <lgreen22@xxxxxxxxxxxxxx>
- To: si-list@xxxxxxxxxxxxx
- Date: Tue, 01 May 2012 19:57:29 -0700
Hello, Zack,
* IBIS is not a "tool". IBIS is a "portable"
electronic datasheet with a formal specification.
* A signal integrity tool (simulator) can help you
determine the rise/fall times, based on the IBIS
data. If you use the package and load data from
the datasheet, and use the voltage points that
define Tr and Tf in the datasheet, then the IBIS
simulation results for Tr and Tf should match the
datasheet.
* If the datasheet and the IBIS file are not in
agreement, there are several possible causes:
- As Arpad noted, the definition of Tr and Tf is
in the IBIS specification. However, there is no
standard for a datasheet, so it might use 10-90%,
20-80%, Vih-to-Vinl, or whatever else that
manufacturer chooses.
- Also, Tr and Tf are load dependent. IBIS uses a
resistive load, while data sheets might use a
capacitive load or a different resistor load value.
- IBIS and the datasheet might not address the
package in the same way. IBIS tables represent
"unpackaged" behavior, with the package info
addressed at the component level. Datasheets
often give Tr and Tf for packaged devices. Hence
the need to do an "apples to apples" comparison in
simulation.
Regards,
Lynne
"IBIS training when you need it, where you need it."
Dr. Lynne Green
Green Streak Programs
http://www.greenstreakprograms.com
425-788-0412
lgreen22@xxxxxxxxxxxxxx
On 5/1/2012 10:36 AM, Muranyi, Arpad wrote:
> Zack,
> As I said it in my previous reply, if you want to find out your
> buffer's rise or fall ***time*** (not slope, or slew rate), you
> can look at its IBIS model's dt number in the [Ramp] keyword,
> or equivalently, the time it takes for the waveforms stored in
> the [*** Waveform] keywords to transition. I am not sure what
> in addition to that are you asking about in your most recent
> email. Also, I would tend to believe the IBIS model more than
> the data sheet numbers if both are available.
>
> Thanks,
>
> Arpad
> =================================================================
>
> From: Zack B [mailto:zacksilist@xxxxxxxxx]
> Sent: Tuesday, May 01, 2012 11:37 AM
> To: Muranyi, Arpad
> Cc: si-list@xxxxxxxxxxxxx
> Subject: Re: [SI-LIST] Re: Rise / Fall time
>
> Arpad,
>
> Basically, If I need to know my driver's minimum tr or tf, what do you think
> is the best way is to find out if that data is not available in the
> datasheet. For that reason, I assumed the tool could give me a start point in
> estimating, but the results are different. I will email you separately
> regarding that. But in general, either we rely on the datasheet spec or IBIS
> to derive the values without having to do spend an exhaustive amount of time
> initially?
> On Tue, May 1, 2012 at 3:47 PM, Muranyi,
> Arpad<Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>> wrote:
> The "Approximate Output Switching Time" in HyperLynx is not only
> based on the IBIS [Model]'s transition time. There are other
> factors which are taken into consideration in the calculation of
> that. I would be glad to help you off line with that question.
>
> Regarding the notion of obtaining the true transition time of the
> buffer before or after the simulation, we need to be careful
> with the terminology we use in this discussion. Here is why:
>
> Internally, the buffer's transition time depends on how quickly
> the pre-driver stage turns the output transistors on or off.
> This time is usually not effected much or at all by the load
> on the output of the buffer. So we can assume that "dt" in
> the IBIS [Ramp] keyword is a useful number by itself. On the
> other hand, the amount of voltage the signal goes up or down
> will depend on the voltage division that is established between
> the buffer's impedance and the load impedance. A CMOS buffer
> might go rail to rail if there is no load on it, but it might
> only go half as much if there is a matched load on its output.
> For this reason the "dV" number in the [Ramp] keyword is only
> meaningful at a given load impedance. This is why the "R_load"
> parameter is so important for the [Ramp] keyword.
>
> The reason I am explaining all this is because it is OK to talk
> about switching time or rise/fall time just by looking at the
> "dt" number in the [Ramp] keyword, but it is not OK to talk
> about "slew rate" or "slope" without simulating the buffer with
> its load.
>
> I hope this helps,
>
> Arpad
> ==================================================================
>
> -----Original Message-----
> From: si-list-bounce@xxxxxxxxxxxxx<mailto:si-list-bounce@xxxxxxxxxxxxx>
> [mailto:si-list-bounce@xxxxxxxxxxxxx<mailto:si-list-bounce@xxxxxxxxxxxxx>] On
> Behalf Of Zack B
> Sent: Tuesday, May 01, 2012 9:14 AM
> To: Joseph.Schachner@xxxxxxxxxx<mailto:Joseph.Schachner@xxxxxxxxxx>
> Cc: si-list@xxxxxxxxxxxxx<mailto:si-list@xxxxxxxxxxxxx>
> Subject: [SI-LIST] Re: Rise / Fall time
> Hi Joe,
> Thanks for the reply. As stated in my initial post, I'm trying to arrive at
> the critical length and hence the rise / fall times are quite important.
> Before I simulate, the tool estimates the switching times (based on IBIS)
> as 0.240 ns. And, when I simulate and measure the rise/fall time at the
> driver, the value is 0.850 ns. In this case, there is no degradation as
> both measurements are at the driver. As there are two different values of
> the rise time for the same driver, my critical lenght also varies. So, is
> my technique right?
>
> Zack
>
> On Tue, May 1, 2012 at 2:59
> PM,<Joseph.Schachner@xxxxxxxxxx<mailto:Joseph.Schachner@xxxxxxxxxx>> wrote:
>
>> Re "the switching time automatically reported for my
>>
>> address signals are 0.240 ns. However, when I simulate, the rise and fall
>> times values are in 0.850 ns range. There is a similar discrepancy for my
>> data signals too. Any idea why is the difference?
>> "
>>
>> I'm not sure what Hyperlinx can show you before you simulate. I suspect
>> (just a guess) that it is showing you the rise time it is going to create
>> at the source of that signal. I don't exactly know what's in the signal
>> path in your simulation between that source and where the 0.850ns is
>> reported, but that 0.850ns number surely includes the degradation due to
>> that path.
>>
>> You should ask someone who knows more about Hyperlinx if my guess is
>> correct.
>>
>> If this is not just a Hyperlinx question, and you are asking "what
>> degrades rise time like this?" ... that's a much more interesting
>> question, and I recommend Eric Bogatin's book "Signal Integrity Simplified"
>> which he recently updated to include power distribution networks. Some of
>> the things that cause rise times to degrade:
>>
>> 1) increasing loss with frequency ... some materials are worse than
>> others, FR4 is pretty horrible.
>> 2) different propagation speed in air and in the board material, in
>> microstrip traces - stretches transitions.
>> 3) any impedance discontinuities (ie, vias?) may cause reflections
>> (reflected energy), so it will take longer for the signal to reach its
>> final value at the end of the path.
>> 3a) at very fast rise times, the woven construction of FR4 causes
>> impedance ripples as the wave front passes over just resin, then over a
>> fiberglass bundle in resin, then over just resin, etc.
>> 4) inductance - for example, the connection from the internal IC pad to
>> the pin and down the pin to the board ... may be a serious issue. Can be
>> mitigated somewhat, see the book I recommended.
>> 5) Skin effect. Very high frequencies are carried only near the outer
>> surface of a trace, increasing ohmic resistance. Probably not a
>> significant issue, compared to those mentioned above.
>>
>> If you don't want to read a book, there is LOTS of information about these
>> topics on the web, much of it mentioned in previous SI-LIST posts.
>>
>> --- Joe S.
>
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List forum is accessible at:
http://tech.groups.yahoo.com/group/si-list
List archives are viewable at:
//www.freelists.org/archives/si-list
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
Other related posts:
