From: glen herrmannsfeldt on 8 Feb 2010 01:35
In comp.arch.fpga rickman <gnuarm(a)gmail.com> wrote:
(snip, I wrote)
>> ? ?http://www.waves.utoronto.ca/prof/gelefth/Backup_Old/jpub/6.pdf
> I still can't read it. 404 not found error again.
OK, try again:
is the index of all his papers.
should be the one.
also looks like a related paper, and should probably be read first.
All seem to be unusual problems involving transmission lines.
> I'll have to wait until another day. BTW, does he actually relate
> this to power supply decoupling or is this just a transmission line
It is specific to power/ground planes on PC boards with vias.
From: David Brown on 8 Feb 2010 04:45
On 05/02/2010 03:43, TSMGrizzly wrote:
>> Are there any examples out there of how to route memory chips on a
>> bus? I'm kind of new to routing and don't really know what the
>> strategy is for this kind of thing. I was thinking about this when
>> designing a board to interface to expansion headers on a dev board for
>> a first prototype, but I couldn't think of a way to do it with just
>> two layers, so I gave each chip its own lines in that case since I had
>> plenty of I/O.
> Now that I think of it, I suppose I could make the bus connection job
> a little simpler if I take advantage of the fact that RAM is "random
> access," so the address/data line numbers from chip to chip don't
> necessarily have to match up. Then the address/data lines could be
> connected in whatever order is easiest and cleanest, since on the FPGA
> side the data would go in and come out in the desired order either
> Would this for any reason be a bad design practice?
Are you thinking that, for example, pin D0 on one ram device is on the
same bus line as pin D3 on the next ram device? That's certainly
possible - for static ram, there is no difference between the data lines
or most of the address lines (if the ram supports bursting of some sort,
then some address lines are specific).
However, the easiest way to connect multiple identical ram devices on a
pcb is to simply place them close together and carefully aligned - then
you can "bus route" between them with a neat pattern of routes straight
across. Only the chip select line is handled separately. Mixing the
bus numbering is not going to be of any benefit here, and it will make
your schematics somewhat more confusing.
From: TSMGrizzly on 8 Feb 2010 07:24
On Feb 8, 6:45 pm, David Brown <da...(a)westcontrol.removethisbit.com>
> On 05/02/2010 03:43, TSMGrizzly wrote:
> >> Are there any examples out there of how to route memory chips on a
> >> bus? I'm kind of new to routing and don't really know what the
> >> strategy is for this kind of thing. I was thinking about this when
> >> designing a board to interface to expansion headers on a dev board for
> >> a first prototype, but I couldn't think of a way to do it with just
> >> two layers, so I gave each chip its own lines in that case since I had
> >> plenty of I/O.
> > Now that I think of it, I suppose I could make the bus connection job
> > a little simpler if I take advantage of the fact that RAM is "random
> > access," so the address/data line numbers from chip to chip don't
> > necessarily have to match up. Then the address/data lines could be
> > connected in whatever order is easiest and cleanest, since on the FPGA
> > side the data would go in and come out in the desired order either
> > way.
> > Would this for any reason be a bad design practice?
> > Steve
> Are you thinking that, for example, pin D0 on one ram device is on the
> same bus line as pin D3 on the next ram device? That's certainly
> possible - for static ram, there is no difference between the data lines
> or most of the address lines (if the ram supports bursting of some sort,
> then some address lines are specific).
> However, the easiest way to connect multiple identical ram devices on a
> pcb is to simply place them close together and carefully aligned - then
> you can "bus route" between them with a neat pattern of routes straight
> across. Only the chip select line is handled separately. Mixing the
> bus numbering is not going to be of any benefit here, and it will make
> your schematics somewhat more confusing.
Yes, that's what I was kind of thinking. It did occur to me that it
would add confusion to the schematics.
The devices are 44 pin TSOP-II packages, so I don't think I can
squeeze any traces between the pads, so I'm trying to think of two
things now.. how to get the traces to both sides of the chip in a tidy
way, and how to get the traces to daisy-chained chips (though out of
four chips, probably only two, maybe three will share a bus). I think
I've come up with a scheme, though it requires a little bit of layer
jumping, and the trace lengths will be different for each side of the
chip.. I don't suppose it matters much at this low speed though.
Looks like this thread has been pretty popular.. got lots of good
information to consider!
I have to get my first revision done and ordered in about four or five
weeks, so it's time to get to work!
From: Symon on 9 Feb 2010 07:18
On 2/8/2010 5:14 AM, rickman wrote:
> On Feb 6, 7:37 pm, Symon<symon_bre...(a)hotmail.com> wrote:
>> On 2/6/2010 5:38 PM, rickman wrote:
>>> I keep asking you if you have done any real analysis or measurements
>>> of what you are stating?
>> Well, this was the first time you asked IIRC, but thank you for doing
>> so. The answer is "For sure". I've used Hyperlynx and Spice on my
>> boards. I guess you have also, or else you would not be able to post
>> your opinions without worrying you might giving someone a bum steer.
> So are you going to share the results of these simulations on the vias
> you are talking about?
Sure Rick, let's go through it together with some cheap tools (free!)
from t'internet. OK, you can get a nice copy of Spice from here. maybe
you already have it.
At the bottom of this post you will find a model of a PCB with a power
plane bypass. I've used lumped components to model it. If you
cut'n'paste the text into an editor and save it as 'planes.asc' or
somesuch, you should be able to load it into the simulator you downloaded.
So, if you look at the model, here's what each bit does.
V1 DC power supply.
L3 Big inductor to represent the PDS supply impedance.
C2, R2, L4 model a 0402 1uF bypass capacitor. L4 includes the vias.
C4 Models the power plane bypass. No parasitics on this baby!
L1 Models the power via and ball from the plane to the FPGA die.
C3, R3, L5 model the bypass capacitor on the FPGA BGA package.
R1, C1, V2 model a IOB switching with 500ps rise time. Rout=20,Cpin=10p
L2 Models the ground via from the PCB plane to the FPGA die.
BTW, you can find models of bypass capacitors here:-
PCB_PWR is the power on the PCB
FPGA_PWR is the power on the BGA package.
FPGA_GND is the ground on the BGA package.
Vout is used to show when the switching happens.
(1) If you press the little 'running man' button, a simulation window
will appear. You can now click on nets in the schematic. I clicked on
FPGA_PWR, FPGA_GND, Vout and PCB_PWR. I also clicked on Windows -> tile
vertically to give a nicer picture. Whatever, let's call this experiment 1.
OK, we see the power on the BGA is quite well behaved as expected. 60mv
of overshoot and ground bounce.
(2) So, what happens if we remove the bypass made from the power plane
being next to the ground plane, and instead use a ground plane near the
surface? If you make the schematic the active window by clicking in it,
then click the scissors symbol, then click on C4, that's got rid of the
power bypassing. If we right click on L2 and change it to 0.5n, (N.B.
don't forget the 'n'!) that's the same as moving the ground plane near
to the surface, as the via inductance is reduced by this much. Call this
Here we see a little difference. The power overshoot is now a bit
bigger, maybe 110mV. The ground bounce is less, about 30mV.
(3) If we add another bypass capacitor, using the copy feature (next to
the scissors!) to copy L4, R2 and C2, we can do experiment 3.
Here we see smaller overshoot, maybe 100mV, showing that if a few bypass
capacitors are added we would get back the performance of a 'plane built
(4) Let's go back to the original design. If you press F9 enough times
you'll undo any changes. Try deleting the 'on BGA' bypass capacitor C3.
You will now see much bigger overshoots and ground bounce. That's why
the FPGA manufacturers put bypassing on the BGA.
(5) OK, back to the original design again with F9. Let's try this. Let's
say we only have a small board, a few square inches, and the plane
capacitance is only 200pF. Right click on C4 and change it to 200p.
Here we see the potential danger of using a power plane derived
bypassing system. The high-Q power plane is resonanting with L1, the via
and ball inductance to start an oscillation. With ordinary bypass
capacitors only, this doesn't happen as the caps have far less Q. If you
remove the 'on-bga' bypassing, C3, you'll see this effect get even worse.
I hope this crude model has given you some insight into why I choose to
eschew the power plane bypassing idea in the middle of the board, and
use ground planes near the surface instead.
1) From experiment 2 we can have less ground bounce by using a ground
plane very close to the FPGA. The ground is connected to all the FPGA
supplies, not just the Vcco we are simulating here, so is most
important. Any ground bounce affects the whole device, core, DCMs, PLLs,
everything. Any rises in Vcco overshoot from losing the power plane can
be mitigated with more bypass caps as shown in experiment 3.
2) The manufacturers put bypassing on the device for a reason, as we see
from experiment 4, and this is highly effective.
3) Power plane bypassing systems can give rise to nasty unexpected
resonances unless they are designed very carefully as shown in
experiment 5. Using crappy Q bypass capacitors instead precludes this
from ever being a problem.
I'd appreciate your critique.
Model planes.asc :-
SHEET 1 880 680
WIRE -144 -224 -192 -224
WIRE -16 -224 -64 -224
WIRE 128 -224 -16 -224
WIRE 272 -224 128 -224
WIRE 336 -224 272 -224
WIRE 336 -192 336 -224
WIRE -16 -128 -16 -224
WIRE 336 -96 336 -112
WIRE 528 -96 336 -96
WIRE 560 -96 528 -96
WIRE 336 -80 336 -96
WIRE 336 -80 224 -80
WIRE 336 -64 336 -80
WIRE 224 -48 224 -80
WIRE -16 16 -16 -48
WIRE 128 48 128 -224
WIRE 224 48 224 32
WIRE 336 48 336 16
WIRE -192 80 -192 -224
WIRE 336 128 336 112
WIRE 528 128 336 128
WIRE 560 128 528 128
WIRE 224 144 224 128
WIRE 336 144 336 128
WIRE -16 176 -16 96
WIRE 224 256 224 208
WIRE 336 256 336 224
WIRE 336 256 224 256
WIRE 336 288 336 256
WIRE 528 288 336 288
WIRE 560 288 528 288
WIRE 336 320 336 288
WIRE -192 432 -192 160
WIRE -16 432 -16 240
WIRE -16 432 -192 432
WIRE 128 432 128 112
WIRE 128 432 -16 432
WIRE 256 432 128 432
WIRE 336 432 336 400
WIRE 336 432 256 432
WIRE 256 464 256 432
FLAG 256 464 0
FLAG 528 -96 FPGA_PWR
FLAG 528 288 FPGA_GND
FLAG 528 128 Vout
FLAG 272 -224 PCB_PWR
SYMBOL ind 320 -208 R0
SYMATTR InstName L1
SYMATTR Value 1n
SYMBOL ind 320 304 R0
SYMATTR InstName L2
SYMATTR Value 1n
SYMBOL voltage -192 64 R0
WINDOW 123 0 0 Left 0
WINDOW 39 0 0 Left 0
SYMATTR InstName V1
SYMATTR Value 3.3
SYMBOL voltage 336 128 R0
WINDOW 123 0 0 Left 0
WINDOW 39 0 0 Left 0
SYMATTR InstName V2
SYMATTR Value PULSE(0 3.3 0 0.5n 0.5n 9.5n 20n)
SYMBOL cap 320 48 R0
SYMATTR InstName C1
SYMATTR Value 10p
SYMBOL res 320 -80 R0
SYMATTR InstName R1
SYMATTR Value 20
SYMBOL ind -48 -240 R90
WINDOW 0 5 56 VBottom 0
WINDOW 3 32 56 VTop 0
SYMATTR InstName L3
SYMATTR Value 10�
SYMBOL cap -32 176 R0
SYMATTR InstName C2
SYMATTR Value 1�
SYMBOL res -32 0 R0
SYMATTR InstName R2
SYMATTR Value 0.25
SYMBOL cap 208 144 R0
SYMATTR InstName C3
SYMATTR Value 10n
SYMBOL ind 208 -64 R0
SYMATTR InstName L5
SYMATTR Value 0.7n
SYMBOL cap 112 48 R0
SYMATTR InstName C4
SYMATTR Value 1n
SYMBOL ind -32 -144 R0
SYMATTR InstName L4
SYMATTR Value 0.7n
SYMBOL res 208 32 R0
SYMATTR InstName R3
SYMATTR Value 0.25
TEXT -312 -72 Left 0 !.tran 50n
From: RCIngham on 9 Feb 2010 08:26
>3) Power plane bypassing systems can give rise to nasty unexpected
>resonances unless they are designed very carefully as shown in
>experiment 5. Using crappy Q bypass capacitors instead precludes this
>from ever being a problem.
>I'd appreciate your critique.
So, are X7R 'crappy' enough Q, or would Y5U be worse/better?
Posted through http://www.FPGARelated.com