> > > and if
> > > we had enough capacitance on-chip then we can still run high data
> > > rates with a poor power return for outputs that are CMOS that use
> > > both pull-up and pull-down such as CMOS full-swing and LVTTL.
> >
> > Ummmm... Yeah, but that's a LOT of capacitance. Assuming that you're
> > running 12:1:3 into 50 ohms reflected-wave with ground inductance of
> > 5 nH/pin, you have a per-pin L/R of (12)(5 nH)/(100 ohms) or 600 ps.
> > To get the RC product into the same ballpark you'd have to have
> > (600 ps)/(100 ohms) or 6 pF per pin. In practice this would be quite
> > a bit short of sufficient even with a very favorable 5 nH per pin, but
> > 6 pF/pin is still enough to nearly double the size of your I/O ring.
> >
> > Urk.
>
> I'm not sure of the relavance to your formulas above. I can certainly
> try to validate them so I feel comfortable using them. Have you
> verfied them against a simple SSO simulation?
Strictly order-of-magnitude (hey, I'm old enough to have learned on slide
rules!) The basic idea is that the capacitance has to be large enough to
dominate. Cap holdup is proportional to 2C*Z0, and inductive spike is
proportional to L/2Z0 -- thus the comparison above. For good results the
cap should be quite a bit bigger than the parity value I came up with so
your 150 pF/pin isn't unreasonable (except in die area!)
> > > So
> > > in some cases it is a 'limited benefit' but in others it is not.
> >
> > I suppose if you have a design that's massively core-limited (as in less
> > than half of the available I/O ring used) then it might make some sense,
> > but for low-pincount devices with modest I/O needs it's about as cheap
> > to use a better package -- and at best this stunt will only work to get
> > I/O performance into the 'modest' range.
>
> Our simulations showed that we needed about 150pf per pin for
> driving about 6" of interconnect. Since we had high I/O and
> the core logic was not sufficiently sparse we could not get
> by with adding capacitance in the core area.
Agreed that the core is not the place for I/O bypass. Since a cap the size of
a typical I/O cell runs in the 10 pF range, you'd be increasing your I/O
real estate by more than an order of magnitude. Since you're already in an
I/O-limited design space that's Not Cheap. Plan B is a different package.
-- 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 ****