[SI-LIST] Re: Rise / Fall time
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <zacksilist@xxxxxxxxx>, <Joseph.Schachner@xxxxxxxxxx>
- Date: Tue, 1 May 2012 10:53:59 -0400 (EDT)
Zack,
You really need to define switching time very carefully. Normally,
switching time is measured at the receiver when the voltage crosses the
receiver threshold voltages VinL and VinH, minus the time the same
transmitter (driving into its standard load) crosses the transmitter
threshold voltage Vmeas. Timing rules for synchronous and asynchronous
transfers make this assumption. Depending on the length and impedance of
the transmission line between the transmitter and the receiver, and the
impedance of the receiver, the voltage at the drive often only swings half
the full output voltage range, gets doubled when reflected at the
receiver, and if not attenuated very much by the time it gets back to the
transmitter completes the voltage swing at the transmitter. It is not very
difficult to create scenarios where the voltage swings through the
receiver threshold voltages before the transmitter driving into its
standard load crosses its Vmeas threshold, thereby created a negative
delay.
Walter
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Zack B
Sent: Tuesday, May 01, 2012 10:14 AM
To: Joseph.Schachner@xxxxxxxxxx
Cc: 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> 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
------------------------------------------------------------------
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:
