[SI-LIST] bandwidth: based on edge rate or data rate?
- From: "Zabinski, Patrick" <zabinski.patrick@xxxxxxxx>
- To: <si-list@xxxxxxxxxxxxx>
- Date: Mon, 8 Mar 2010 16:29:04 -0600
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
Other related posts:
