[SI-LIST] Re: Rise / Fall time
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "si-list@xxxxxxxxxxxxx" <si-list@xxxxxxxxxxxxx>
- Date: Tue, 1 May 2012 17:36:49 +0000
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<mailto: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<mailto: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
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx<mailto: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<mailto: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
------------------------------------------------------------------
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:
