On Wed, Aug 03, 2005 at 07:17:37PM +0200, Attila Kinali wrote:
>
> That shouldn't be an issue here. We are talking about a chip
> that is clocked with at most 300MHz. I'd say that even a stone
> age LCC is good enough. Anything more advanced is more than
> enough for us.
Well, let's look at the arithmetic (using rough numbers). For that
clock rate, the rise time would be no more than 1 nS. For 3.3V logic
swings, that's 3.3e9 V/S. Assuming 50 pf loading on the outputs, that's 165
mA per output during a logic transition. What bus width are we driving when
we read data out? 32 bits? So for a worst-case code transition, the peak
current through the ground and Vcc rails is 5.3A, and it starts and stops in
roughly 500 pS, so dI/dt is in the ballpark of 10.5e9 A/S. That obviously
can't be stuffed through a single pin, whose inductance is in the range of 1
to 4 nh; V = -L * (dI/dt) would be 10.5 to 42V, an impossible condition. If
we use 8 pins per rail spaced evenly around the chip, a well-designed ground
plane, and individual low-inductance chip capacitors merged with the Vdd
pads, we could probably reduce the overall inductance by an order of
magnitude, maybe more with careful design of the on-chip power buses and
their method of connection to the output driver FETs. So at best, we're
talking about ground bounce levels that eat up pretty much the whole noise
margin of the logic family. Better not have this happen synchronously with
any clock edges.
Several things can help. Restrict the loading to 15 pf instead of
50. Use more power pins. Select the lead frame with pin inductance in
mind. Write good application notes on the proper method of laying out the
power pads and bypass caps. Don't use any of the chip's outputs to clock
other chips. Arrange the timing so there's adequate time for the outputs to
settle before other devices look at data outputs. And of course, as Tim
pointed out some time back, it's essential that any DACs on chip be
electrically isolated from the logic, so that ground bounce doesn't get
added to their analog outputs.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
