Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: 16-bit 625Mbaud XGMII




Jonathan Thatcher wrote:

> Jaime makes an excellent point here. In fact, it wasn't as bad as it might
> have been because the parallel I/O of the chip were probably already 8B/10B
> encoded (please verify Jaime) and were therefore much closer to a
> differential interface than will be true with the XGMII. Simultaneous
> switching noise is such a pain.
>
> Speed is not the only reason high speed chips use differential logic. It is
> also much easier to control noise.
>
> jt
>

Jonathan,

The 8b/10b is a good coder so why blame it for
something that it does not deserve ? ...

The 266 MHz chip I designed included the two PLLs, SERDES
and 8b/10b coder (I designed the PLLs and SERDES,
a colleague of mine designed the 8b/10b) and it
included two options: 1) bypass the 8b/10b, or 2) use
the 8b/10b. The reason for these two options was that
some customers had already included the 8b/10b in their
upper layer chip.

Hence, at the receiver side, the output drivers either
delivered the raw octets of data ("MII" interface) or
the 10-bit wide 8b/10b-encoded symbols to the "MAC".

In principle, if we deliver encoded symbols to the
"MAC" we will have more switching noise, specially
because the 8b/10 coder is so rich in transitions.

And if we deliver raw octets of data to the "MAC"
we will have, in principle, less switching noise
(imagine, for example, that your raw data consists
of "all '1's": you will not have any switching noise
at all from the output drivers, they would stay 'high'
all the time).

Therefore, from the point of view of switching noise
the 8b/10b would make things worse (and not the opposite,
as you suggested).

However, I will end this note emphasizing my opening
sentence:

Both in the 266 MHz Fiber Channel chip I designed
in the past and in the present 10 GbE chips we are
talking about, the coding scheme (8b/10b or scrambling)
is really unrelated to the problem of the switching noise
generated by the 32 output drivers. You will have to
fight in practice the same amount of switching noise
in both cases.

Jaime

Jaime E. Kardontchik
Micro Linear
San Jose, CA 95131




>
> > -----Original Message-----
> > From: Jaime Kardontchik [mailto:kardontchik.jaime@xxxxxxxxxxx]
> > Sent: Tuesday, March 21, 2000 3:51 PM
> > To: stds-802-3-hssg@xxxxxxxx
> > Cc: Mittal, Millind
> > Subject: Re: 16-bit 625Mbaud XGMII
> >
> >
> >
> > Millind,
> >
> > I do not really want to open another front, but here
> > are my two cents ...
> >
> > From the point of view of moving 10 Gbps from point A
> > to point B on a PCB or backplane - I prefer to use
> > the 4-lane architecture. I think it is better.
> >
> > With respect to the definition of the XGMII (number of
> > I/Os and electrical characteristics) I think that it
> > would be worthwhile to take an additional look at this
> > issue. The 32-bit wide I/O at 312.5 Mbaud (as specified
> > electrically by H. Frazier in his "10Gig MII update",
> > Kauai, Nov 99) is very nice, simple and easy to implement
> > if one so desires.
> >
> > However I think that one aspect of this 32-bit I/O has
> > been overlooked and could pose a headache to the designers
> > of the PCS/PMA chip: 32 output drivers in the receiver
> > side of the PCS/PMA chip switching at 312.5 Mbaud create
> > a lot of noise that could propagate to the serial outputs of
> > the transmitter and create a lot of jitter on the 3.125 Gbaud
> > (or 2.578 or 1.25) waveforms.
> >
> > I had this problem six years ago when I designed a 266 MHz
> > transceiver in CMOS for Fiber Channel, with the Tx and Rx
> > integrated in the same chip: the 10 output drivers in the
> > receiver side switching each at 26.6 Mbaud created a lot of
> > jitter on the serial output at 266 Mbaud in the transmitter
> > side (that was far away on the opposite side of the chip).
> > Not so much in the loopback mode but specially in the normal
> > operating mode when the Rx and Tx PLLs had slightly different
> > frequencies.
> >
> > I had used the normal precautions that everyone does: separate
> > power supply for the output drivers, heavy isolation rings, and
> > so on. I used initially the standard I/Os buffers provided by the
> > library. These standard drivers were well designed and had
> > slew-controlled slopes. However, I had to redesign these
> > drivers and slow the rise and fall time as much as I could
> > until I finally got the jitter on the serial 266 Mbaud line
> > at the transmitter side under control.
> >
> > Now we have 32 output drivers in the receiver side pointing
> > to the MAC, each of them switching at 312 Mbaud. How are
> > we going to control the jitter on the four serial waveforms at
> > the transmitter on the other side of the PCS/PMA chip ?
> > From this point of view, fully-differential low-swing drivers
> > would be preferable.
> >
> > Jaime
> >
> > Jaime E. Kardontchik
> > Micro Linear
> > San Jose, CA 95131
> >
> >
> > "Mittal, Millind" wrote:
> >
> > >      Curt, Jaime - But in this discussion, pin count is not the only
> > > consideration. Other important consideration is the length
> > of the wire that
> > > you can drive. Isn't LVDS 16 bit interface is better than
> > half speed single
> > > ended interface?
> > >
> > > Can someone refer me to some discussion where we have comparison of
> > > different options done in one place
> > >
> > >     for example something like this ..
> > >
> > >                                          XAUI             LVDS
> > > singled ended
> > > speed                                3 GHz          625 MHz
> >        312 MHz
> > > pin count                           20+              70+
> >             70+
> > > distance drive ability           20"               ??
> >            2"
> > > coding scheme requried      yes               no                 no
> > > design complexity
> > > etc...
> > >
> > > also did any proposal consider something in between 4 wide
> > and 16 wide, for
> > > example 8 wide differential signaling interface?
> > >
> > > Millind Mittal
> > > Level One Communications/An Intel Company
> > > mmittal@xxxxxxxxxx
> >