> > > > IMHO the best bet for minimizing SSO transients is to use balanced codes
> > > > such as 8b/10b so that there isn't any substantial common-mode current.
> > > > Actually saves pins and cuts jitter too.
> > >
> > > Not sure where you are coming from here. 8b/10b will work if you
> > > have a DC block in your system. But for SSO transients you've got
> > > to get current supplied during the switching event - not just average
> > > out the current demand over 10 bits.
> >
> > Parallel 8b/10b. Explained in another message.
>
> OK, I just read in more detail your explanation of parallel 8b/10b.
> First off, what is your worst case switch imbalance?
There are 254 codes with 5 high and 5 low. Add one each with 6/4 and
the worst case imbalanced transition goes from 6 high/4 low to 4 high
and 6 low (or vice versa). Either way the unbalanced currents go out
not only over the supplies but over the other signal lines (so the net
supply inductance is pretty low.)
> Secondly, you
> seem to be more concerned about balancing current going into
> the off-chip (on-board) termination supply.
That's just one consideration. If the off-chip termination supply doesn't
have to handle large unbalanced currents it takes quite a bit of cost out
of the system. It also does a lot towards reducing EMI.
> I would think that
> noise on the termination supply is much less of a concern than
> noise on the chip power or ground supplies (SSO).
For performance, yes. For EMI, probably. For cost, maybe.
Fortunately all three are in the same direction so the comparison
is somewhat academic.
> > > Can the confusion be that you have a single rail output driver, such
> > > as GTL, in mind whereas many of us are thinking more of a two-rail
> > > output driver such as LVTTL or full-swing CMOS?
> >
> > Wash your mouth!
> >
> > Actually, I *have* done some really fast current-mode stuff that had
> > to be open-drain because we couldn't manage the crossover distortion
> > across process. I'd rather everyone forgot it, though, and GTL is
> > one sin I've never committed. Push-pull is *much* more fun. (e.g.,
> > SSTL, HSTL, GLVDS, etc.)
>
> Not having designed with SSTL and HSTL, I'm guessing that both
> these I/O are terminated with 50 ohms to some VTT supply.
Yuppers. You can get the details at
http://www.jedec.org/download/freestd/jesd8-xx/
> Their
> HIGH and LOW state currents must be high enough so that when
> one pin switches from HIGH to LOW and another switches from
> LOW to HIGH, then dI/dt current into both ground and power
> supplies is approximately zero?
Two and oh.
> If so, then parallel 8b/10b
> can be attractive if the worst case SSO event is still fairly
> well balanced.
Indeed.
> We are looking into the future and realize that full swing
> CMOS won't cut it. My thoughts were that GTL was a good option.
> So your comments on GTL are timely. Four questions:
>
> 1) Do you envision push-pull to be more attractive as you
> can split dI/dt noise between power and ground rails (whereas
> with GTL it all gets dumped into ground).
That's one reason.
> 2) Can you explain what you meant by "crossover distortion?"
A push-pull rising edge has to coordinate the turnoff of the
pulldown with the turnon of the pullup. In the analog camp
the unavoidable noice accompanying the transition from sinking
to sourcing current is called "crossover distortion" and for
want of a better term I use it to describe the jitter that
can be introduced in digital signaling under the same conditions.
> 3) Why were you so negative on GTL?
GTL is slow, noisy, and burns lots of power. If that's what
you need, you're in luck.
Slow because an open-drain signaling system is extremely sensitive
to line impedance mismatch. Noisy because the currents are unbalanced
and and tend to form large loops. Power-hungry because the open-drain
signaling requires that common-mode potential be maintained by current
in the terminators.
> 4) What is GLVDS?
A (currently proprietary) low-swing signaling method that Ericsson uses.
Stands for Ground-referenced Low-Voltage Differential Signaling.
-- D. C. Sessions [email protected]**** To unsubscribe from si-list: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list ****