Board layout for FPGA
in [FPGA]
|
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: http://www.waves.utoronto.ca/prof/gelefth/Backup_Old/jpub/ is the index of all his papers. http://www.waves.utoronto.ca/prof/gelefth/Backup_Old/jpub/pdf/6.pdf should be the one. http://www.waves.utoronto.ca/prof/gelefth/Backup_Old/jpub/pdf/3.pdf also looks like a related paper, and should probably be read first. All seem to be unusual problems involving transmission lines. (snip) > 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 > analysis? It is specific to power/ground planes on PC boards with vias. -- glen
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 > 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.
From: TSMGrizzly on 8 Feb 2010 07:24 On Feb 8, 6:45 pm, David Brown <da...(a)westcontrol.removethisbit.com> wrote: > 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! Steve
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. http://www.linear.com/designtools/software/ 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:- http://www.murata.com/products/design_support/mcsil/index.html Signals are:- 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 experiment 2. 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 capacitor'. (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. experiment 4. 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. Experiment 5. 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. Thanks, Syms. Model planes.asc :- Version 4 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
<big snip> > >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. > >Thanks, Syms. > <snip> So, are X7R 'crappy' enough Q, or would Y5U be worse/better? --------------------------------------- Posted through http://www.FPGARelated.com |