I've recently been doing some post-route / pre-fab analysis on some 25G
channels
between an FPGA and a couple QSFPs on one of our boards. Some
"discoveries" (for me at
least) I thought worth sharing. These might be obvious to those sage
gurus and
experts out there, but to us mumbling meathead skulkers who normally sit
back with
our shades on and bask in the wisdom and knowledge that flows forth from
this
illustrious forum there might be something to be gained herein - or, as
likely, debated.
As mentioned, the channels under evaluation run between an FPGA and two
QSFPs on
board and are intended to operate at 25Gbps (each, 100Gbps aggregate).
No connectors (other than the QSFP itself) are involved. The board has an
impedance controlled stackup, a G-S-G-S-G layer assignment, (relatively)
low loss
material, spread weave glass, VLP copper and will have back-drilling.
The longest channels
are ~16 cm in length. The longest channel actually routes south, east,
north, west,
and finally, south - making a net 360 degree route - all without skew
compensation
(a flag went up!).
For channel analysis I pulled out the SFF-8679 standards which call out
IEEE 802.3bj
OIF CEI v3.1 (among others), which subsequently led to the 100GBase-KR4
and CEI-28G-SR
specifications as being applicable to these particular channels (optical
SFPs).
I built 3D models of all vias. Since I want to include via-to-via
coupling between
channels to include in the FEXT/NEXT analysis, the 3D models included
multiple via
pairs where appropriate (my engineering guess). Coupling was set to
pick up multiple
neighbors and the channel "bundles" (all Tx/Rx channels to/from each
QSFP) were
exported into a single .s32p Touchstone file for analysis.
Results:
100GBase-KR4:
- Sdd21 - passes with margin
- Sdd11 - passes with margin
- Sdd22 - passes with margin
- COM - passes with margin (~7 dB)
CEI-28G-SR:
- Sdd21 minimum - passes with margin
- Sdd21 maximum - passes with margin
- Sdd11 - passes with margin
- Sdd22 - passes with margin
- NEXT - (don't have a real good way of explicitly
displaying/viewing this,
so since COM is good, I assume this is ok)
- FEXT - ditto NEXT
- Fitted attenuation - calculated - ok
- IL Deviation - passes with margin
- ICN - not calculated, but based on COM analysis - ok
Initial conclusion - all metrics associated with the channels look good
- all pass with margin.
Surprisingly, even without skew compensation, the channels look good!
Hey! we're good to go!
Not.
Product management steps in and says they want to have the option of
running copper SFPs.
Oops. Re-open the book and add 100GBase-CR4 to the mix.
Results:
100GBase-CR4 as applied to the Host board (Annex 92A)
- Sdd21 - fails (but this is for a 5m cable, we anticipate a 2m
cable, so need to investigate further)
- Sdd11 - passes with margin
- Sdd22 - passes with margin
- COM - passes with margin
Still looking good. However, 802.3bj for the cable assembly has a few
additional requirements. For
good measure, I choose to apply these to the host board as well:
- Scd11 - passes with margin
- Diff to com mode conversion loss: |Scd21 - Sdd21| - I see
failures!!!!!!
- Scc11 - passes with margin
- Scc22 - passes with margin
After all the analysis, the only metric showing a problem is the
differential to common mode conversion
loss. A little thinking tells me this could be due to the lack of skew
management on the channels - the
worst offender is the longest channel with the most bends and, hence,
the greatest skew.
I export the channel to a sandbox, add skew compensation to every bend,
extract new S-parameters
and run them through the various analyses: all pass with greater margin
than before, and the
diff to com mode conversion metric now passes with flying colors.
Overall observations / conclusions:
*) At these rates, skew is important - we know that - why do the channel
specifications in the
100GBase-KR, CEI-28G-SR (and likely many others) not detect skew?
*) At 25Gbps, a bit is only 6mm "long" on a typical PWB trace (someone
can check my math - I'm
notorious for dropping decimal points). A typical backplane channel
might have as many as 50 or more
bits simultaneously propagating on it at any point in time. Wrap
you head around that!
*) One rule of thumb says for a 25Gbps channel we want no more than
~75um skew at any point in the channel - yet
each bend on this board added about 260um of skew - yet all of the
"standard" channel metrics were
happy - in fact had margin - with a net total of 2mm skew on the
worst channel analyzed!???
and finally,
*) I don't care what standard is appropriate for future analysis of any
particular channel - I will
be applying the differential to common mode conversion test to ALL
channels operating near
or above 25Gbps. I'm also interested/open to other S-parameter
metrics that are suitable
as channel skew indicators.
Thanks for listening,
Ralph Wilson
Nokia
------------------------------------------------------------------
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
