[SI-LIST] Re: bandwidth: based on edge rate or data rate?
- From: Iliya Zamek <i_zamek@xxxxxxxxx>
- To: si-list@xxxxxxxxxxxxx, PatrickZabinski <zabinski.patrick@xxxxxxxx>
- Date: Tue, 9 Mar 2010 20:36:22 -0800 (PST)
I deleted unintended characters presented in my previous email.
Good discussion was going about bandwidth modeling, and many useful comments
have been done regarding the channel BW.
The BW requirements in a serial link are govern by specified Bit error rate.
BER limits the acceptable level of Jitter, Noise, crosstalk, reflections, and
so on. Therefore, choosing BW correctly we should analyze different Jitter
components, noise to jitter contribution (Jn), crosstalk, reflections, etc. Two
Jitter components plays significant role in this
regards: ISI and Jn. Both rise when BW decreases.
Jn.
When signal in the link travels from the driver to the receiver, its slew rate
degrades: channel BW affects the signal rise time and losses in the link reduce
the pulse amplitude. Decreased slew rate increases Jn.
ISI.
With BW decreasing the ISI is rising.
Let us illustrate it on two examples with different BW. First calculations done
for BW=Bit rate and second for BW=3xBit rate. We used settings at receiver
end*.
Suppose we have random Jitter RJ 10ps and BER=1xE-12. RJ will take 14x10ps of
the Unit interval 166ps and 26ps remain for the
ISI and Jn only.
1. BW=Bit rate. Jn exceed 27ps and there is no room for ISI; the channel BER
will fail the spec.
2. BW=3xBit rate.
At this BW Jn = 20ps; there is some room for ISI (6ps) and design might be
valid if ISI value is within 6ps.
However, raising the BW to 18GHz is safe if we do not have reflections, or high
frequency coupling in the range from
6GHz to 18GHz, as Istvan also noted.
The "rule of thumb" is to increase the BW balancing between ISI+Jn and
Crosstalk + Reflections.
Regards,
Iliya Zamek
*used 250mv pulse amplitude at the receiver, low frequency noise RMS=5mv,
driver rise time=UI/3.
--- On Mon, 3/8/10, Zabinski, Patrick <zabinski.patrick@xxxxxxxx> wrote:
From: Zabinski, Patrick <zabinski.patrick@xxxxxxxx>
Subject: [SI-LIST] bandwidth: based on edge rate or data rate?
To: si-list@xxxxxxxxxxxxx
Date: Monday, March 8, 2010, 2:29 PM
The debate over what "rule of thumb" to use with regard to modeling
bandwidth has been going on before I joined the SI-List. Some folks say
the bandwidth should be based on edge rate, some say it should be based
on data rate. With the more recent discussion, I stepped back and
reconsidered my recollection of the impetus for the two most prevalent
guidelines, and I felt compelled to toss a few ideas in the air and see
where they land. I invite discussion/debate.
I'll first start with high-speed serial links, where "high speed" by my
definition is where the data rate is high enough that some form of
equalization is requied. In other words, if equalization is not used,
then the eye is effectively closed and the receiver has no clue what's
coming in. Yeah; it's a fuzzy/vague definition, but it's the best I got
for now.
I contend (for sake of argument) that this scenario does not care about
edge rate. In effect, the attenuation at the upper frequencies is so
high that any resemblance of an edge is absorbed in the channel.
Considering an X Gbps serial link, the "Nyquist" frequency (I hate that
term, but it's convenient) is X/2 GHz. Looking at all the SerDes I've
used, they commonly compensate for up to 20 dB attenuation at Nyquist X/2.
Going back to Fourier expansion, the first harmonic that contributes to
the edge rate is 3X/2 GHz. Looking at it differently, I have never seen
a SerDes that provides any equalization at 3X/2 (anyone else?). I
believe there are two reasons for not doing so: 1) CMOS simply doesn't
have the bandwidth to address 3X/2 frequency without a huge penalty in
power; and 2) it is not needed (as demonstrated by all the SerDes out
there working today).
For this particular scenario where active channel equalization is
required, I make the case that Nyquist (X/2) bandwidth is sufficient.
Buy that?
The next scenario is for the traditional low-loss situation like a DDR
interface where the channel losses are present but basically leave the
waveform in good shape. An interesting aspect of these interfaces is
that they run much slower in raw serial speeds, but their timing
constraints are often more challenging (mostly due to the large
setup/hold times of the interfaces). To alleviate the timing
challenges, we need to squeeze out every picosecond of horizontal eye
opening we can, which results in speeding up the edge rates.
Here, the data rate is certainly a factor in the overall eye opening,
but I've often been surprised at how much time we spend squeezing out
the last 10 ps to 20 ps of timing margin. To get these last few
piecseconds, we skip over the data rate (which is often fixed for DDR
interfaces) and work on the edge.
Again, we can look at the data rate to determine how many odd harmonics
we need to preserve the edge, but someone smart once told me that the
associated bandwidth of these harmonics can be derived form the edge
rate. Yeah; 0.35/tr is not an exact number, but it gives us a rough
baseline to start with (I believe this equation came from test equipment
manufacturers). I seem to recall (don't have a reference handy) that a
3 dB bandwidth of 0.35/tr captures something like 90% of the energy of a
digital signal. Seems like a lot, but it is not enough if you're
squeezing out the last few picoseconds from a timing-constrained link.
Instead, we often need to go 3X higher (~ 1/tr) or 5X higher (1.5/tr) to
preserve the speedy edge we need to make timing.
So, I contend that in this scenario with low-loss, timing-constrained
links, that the modeling bandwidth should be based on the edge rate.
Buy that?
Regardless of the minimum bandwidth is needed, I do strongly suggest
that all modeling go beyond the minimum. As indicated by several people
over the years, there are several "gotchas" associated with ignoring
what happens above the minimum bandwidth, where "minimum" is based on
several assumptions/premises that do not always apply.
As indicated by previous recent postings, my mind is not all that clear
the past few weeks (that's another story...), so don't be shy about
pointing out the flaws in my arguments.
Pat
------------------------------------------------------------------
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 technical documents are available at:
http://www.si-list.net
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 technical documents are available at:
http://www.si-list.net
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:
