Board layout for FPGA
in [FPGA]
|
From: TSMGrizzly on 4 Feb 2010 00:22 Hi guys.. I'm getting ready to start working on my first board layout with a BGA package (FG456). First will be a prototype for sure. I was just wondering a few things... Probably the critical part of my design will be interface to a few asynchronous SRAMs. In a relatively low speed design (buses at 10-25MHz) do I need to worry about things like termination and trace length on the RAM buses? Should I dedicate address/data pins to each chip in a shared memory space, or is it better to daisy chain them on a bus? (It seems to me that routing will be a little easier if each chip gets its own lines..) If I won't be using the innermost IO pins, can I get away with a 4- layer design, two signal layers and power/ground? Looking at a Xilinx app note with a suggested escape route for this package, they have three signal layers with 5 mil width traces, the third of which I believe I can do without... And lastly, I guess that I will be needing 1.8 and 2.5V supplies, as well as 3.3V for all of my I/O supplies.. should these all be routed in the dedicated power layer? If the layer is mostly covered a plane, which voltage is supposed to be the plane? 3.3V? And lastly, when connecting I/Os, is there any sensible approach? My tendency is to want to choose the I/Os so that everything lines up nicely, but I find it to be a hassle in this case, that in Eagle we have to connect nets in the schematic first and can't back-annotate from the board. Anything else I should be worrying about? Cheers, Steve
From: rickman on 4 Feb 2010 02:04 On Feb 4, 12:22 am, TSMGrizzly <sbatt...(a)yahoo.co.jp> wrote: > Hi guys.. I'm getting ready to start working on my first board layout > with a BGA package (FG456). First will be a prototype for sure. > I was just wondering a few things... > > Probably the critical part of my design will be interface to a few > asynchronous SRAMs. > > In a relatively low speed design (buses at 10-25MHz) do I need to > worry about things like termination and trace length on the RAM buses? > Should I dedicate address/data pins to each chip in a shared memory > space, or is it better to daisy chain them on a bus? (It seems to me > that routing will be a little easier if each chip gets its own > lines..) You don't say how many SRAM chips. The first thing to consider in evaluating SI (Signal Integrity) issues without a simulation is to compare the length of the traces to the length of the edges of your signals. The rule of thumb I have seen is that if the rising/falling edges of your signals are six times longer than the length of the trace (round trip) then you don't need to worry with reflections no matter how many chips are in the path. All chips will see essentially the same edges and there will be little ringing. Using an FPGA, you can control the edge rates on the address bus. But on the data bus, you can't control the edge rate from the SRAM chips. If it is too fast (very likely with fast SRAM parts) the data bus will need to be terminated. Terminating multipoint busses is nearly impossible and even a simple two point bi-directional bus is not optimal but can be done using series termination. If you have enough I/O pins on your FPGA to use separate data busses to the SRAMs, you can terminate each bus using a series resistor to match impedance of the driver to the impedance of the trace. This results in a reflection from the receiver, but the receiver sees the proper transition (since it is the point of reflection) and the reflection will not be reflected from the driver. If any other chips are connected in the middle of this signal, they will see a half voltage rise followed by a second rise to the full waveform voltage... not what you want. But then, if you allow time for reflections to settle in your timing analysis, you can ignore the SI issues on the data and address busses and only be concerned about the timing signals like the Write strobe. The address has to be stable by the leading edge of the write strobe and the data has to be stable by the trailing edge. On a read, you simply need to allow some extra time for bus settling before the FPGA clocks the data in. > If I won't be using the innermost IO pins, can I get away with a 4- > layer design, two signal layers and power/ground? Likely, but you will need to consider a number of thing such as your design rules in the layout. > Looking at a Xilinx app note with a suggested escape route for this > package, they have three signal layers with 5 mil width traces, the > third of which I believe I can do without... > And lastly, I guess that I will be needing 1.8 and 2.5V supplies, as > well as 3.3V for all of my I/O supplies.. should these all be routed > in the dedicated power layer? If the layer is mostly covered a plane, > which voltage is supposed to be the plane? 3.3V? Any voltage that will have switching currents on them should have a power plane to optimally filter out the transients... in other words, all of them. What family are you using that requires 2.5 volts as well as 1.8??? I thought the recent stuff was all at 1.2 volts for internal logic and the I/O voltage to match your needs. Are you planning on using 2.5 volts for I/O or are you looking at an old family? Or maybe I'm not remembering correctly??? > And lastly, when connecting I/Os, is there any sensible approach? My > tendency is to want to choose the I/Os so that everything lines up > nicely, but I find it to be a hassle in this case, that in Eagle we > have to connect nets in the schematic first and can't back-annotate > from the board. They why use Eagle? I do my layouts in FreePCB. It doesn't support back annotation actually, but I use forward annotation (updates). I plan my pin swaps and add them to the schematic, reload the new net list and then finish up the routes at the FPGA. It has been a while since I have done this, so it may be trickier than I am remembering. I find it very nice to be able to route with minimal vias. That also helps to minimize the number of layers needed. > Anything else I should be worrying about? If this is your first board layout, leave yourself plenty of time and do a lot of checking of your work as well as checking the tool. There's many a slip twixt cup and lip. I found my first board layout to be a real education... Rick
From: David Brown on 4 Feb 2010 03:23 On 04/02/2010 08:04, rickman wrote: > On Feb 4, 12:22 am, TSMGrizzly<sbatt...(a)yahoo.co.jp> wrote: >> Hi guys.. I'm getting ready to start working on my first board layout >> with a BGA package (FG456). First will be a prototype for sure. >> I was just wondering a few things... >> >> Probably the critical part of my design will be interface to a few >> asynchronous SRAMs. >> >> In a relatively low speed design (buses at 10-25MHz) do I need to >> worry about things like termination and trace length on the RAM buses? >> Should I dedicate address/data pins to each chip in a shared memory >> space, or is it better to daisy chain them on a bus? (It seems to me >> that routing will be a little easier if each chip gets its own >> lines..) > > You don't say how many SRAM chips. The first thing to consider in > evaluating SI (Signal Integrity) issues without a simulation is to > compare the length of the traces to the length of the edges of your > signals. The rule of thumb I have seen is that if the rising/falling > edges of your signals are six times longer than the length of the > trace (round trip) then you don't need to worry with reflections no > matter how many chips are in the path. All chips will see essentially > the same edges and there will be little ringing. Using an FPGA, you > can control the edge rates on the address bus. But on the data bus, > you can't control the edge rate from the SRAM chips. If it is too > fast (very likely with fast SRAM parts) the data bus will need to be > terminated. Terminating multipoint busses is nearly impossible and > even a simple two point bi-directional bus is not optimal but can be > done using series termination. > You have a lot more experience at this sort of thing than me, Rick, so I'm a little wary of disagreeing with you. But I'm sure you'll tell me if I get something wrong! I don't see that you have to worry about any termination here. With fast enough signal edges, you can get ringing - but that typically will not matter because you don't sample the signals until the ringing has subsided. When the FPGA is driving the signals, you have (as Rick says) controllable rise and fall rates to avoid ringing. If you don't have that, you will want to terminate critical signals like the read and write strobes (or clock, for synchronous rams) to avoid triggering multiple accesses. But other than that, just make sure the data and address lines are stable before the strobes are sent. For reads, it's possible that you will get ringing due to fast edges from the ram chips (though that would require very over-spec'ed ram chips far away from the FPGA), but you time your read sampling for after the lines have settled. Ringing can cause a few problems - the overshoot/undershoot can go outside the voltage range of the pins on the line, it can cause interference for neighbouring signals, you can't read the signal while it is ringing, and it can cause big trouble when connected to edge-sensitive inputs. But most of these are not going to be a problem in your case, I think. If you need to access your rams in parallel, you will need multiple data buses, and perhaps multiple address and control buses - that depends on the application. But if you just want to access one at a time, I'd put them all on the same bus. Routing between the chips will be easy, and you have less lines from the FPGA to worry about. At the speeds you are talking about, you should have no difficulties. > If you have enough I/O pins on your FPGA to use separate data busses > to the SRAMs, you can terminate each bus using a series resistor to > match impedance of the driver to the impedance of the trace. This > results in a reflection from the receiver, but the receiver sees the > proper transition (since it is the point of reflection) and the > reflection will not be reflected from the driver. If any other chips > are connected in the middle of this signal, they will see a half > voltage rise followed by a second rise to the full waveform voltage... > not what you want. But then, if you allow time for reflections to > settle in your timing analysis, you can ignore the SI issues on the > data and address busses and only be concerned about the timing signals > like the Write strobe. The address has to be stable by the leading > edge of the write strobe and the data has to be stable by the trailing > edge. On a read, you simply need to allow some extra time for bus > settling before the FPGA clocks the data in. > > >> If I won't be using the innermost IO pins, can I get away with a 4- >> layer design, two signal layers and power/ground? > > Likely, but you will need to consider a number of thing such as your > design rules in the layout. > > >> Looking at a Xilinx app note with a suggested escape route for this >> package, they have three signal layers with 5 mil width traces, the >> third of which I believe I can do without... >> And lastly, I guess that I will be needing 1.8 and 2.5V supplies, as >> well as 3.3V for all of my I/O supplies.. should these all be routed >> in the dedicated power layer? If the layer is mostly covered a plane, >> which voltage is supposed to be the plane? 3.3V? > > Any voltage that will have switching currents on them should have a > power plane to optimally filter out the transients... in other words, > all of them. What family are you using that requires 2.5 volts as > well as 1.8??? I thought the recent stuff was all at 1.2 volts for > internal logic and the I/O voltage to match your needs. Are you > planning on using 2.5 volts for I/O or are you looking at an old > family? Or maybe I'm not remembering correctly??? > There is a big difference between "optimal" and "good enough". If the design is fairly small and slow, with low currents, then wide traces to the power pins and some capacitors is going to be perfectly sufficient - there is no need for dedicated power planes for each supply. > >> And lastly, when connecting I/Os, is there any sensible approach? My >> tendency is to want to choose the I/Os so that everything lines up >> nicely, but I find it to be a hassle in this case, that in Eagle we >> have to connect nets in the schematic first and can't back-annotate >> from the board. > > They why use Eagle? I do my layouts in FreePCB. It doesn't support > back annotation actually, but I use forward annotation (updates). I > plan my pin swaps and add them to the schematic, reload the new net > list and then finish up the routes at the FPGA. It has been a while > since I have done this, so it may be trickier than I am remembering. > I find it very nice to be able to route with minimal vias. That also > helps to minimize the number of layers needed. > > >> Anything else I should be worrying about? > > If this is your first board layout, leave yourself plenty of time and > do a lot of checking of your work as well as checking the tool. > There's many a slip twixt cup and lip. I found my first board layout > to be a real education... > > Rick
From: TSMGrizzly on 4 Feb 2010 04:04 Thanks for the input so far, guys! I will have two SRAM chips and one parallel EEPROM in one memory space, and one additional RAM chip in a separate memory space so I know for sure that that one gets its own dedicated address/control/ data lines. I was just wondering if the signal integrity would be hurt by extra loading in chaining up the ones that are on the same bus, but I had a hunch that at these speeds it wouldn't be such a big problem. And probably I will be using 10ns RAMs (I haven't looked at the rise/ fall times though) and keeping them physically as close as I can get them to the FPGA.. maybe about a centimeter away, tops. Looking at this old Digilent Spartan 3 board I have kicking around, I don't see any termination between the FPGA and the ISSI SRAMs on there, but each chip has its own address and data lines.. I dunno if that's good enough to use as an example or not though. As for the supply voltages, I'll be using a Virtex II, but this is the first time I have started to think about implementing my own board and thus needing to worry about power supplies, and I seemed to remember some of my dev boards in the past having a couple or three different regulators on board, but I didn't really think much about it. Looking at the datasheet though, you're right, Rick, it appears that I just need a single 1.5V supply for core voltage, and 3.3V for VCC_aux and all of my I/O. I should have checked that and had the numbers right before asking, sorry about that. So if I need power planes for both of these voltages, do they each need their own layer or can I arrange it carefully in one layer? Thanks again, Steve
From: Uwe Bonnes on 4 Feb 2010 05:24
TSMGrizzly <sbattazz(a)yahoo.co.jp> wrote: .... > And lastly, when connecting I/Os, is there any sensible approach? My > tendency is to want to choose the I/Os so that everything lines up > nicely, but I find it to be a hassle in this case, that in Eagle we > have to connect nets in the schematic first and can't back-annotate > from the board. Perhaps the net2ucf.pl Perl script I just uploaded to CADSOFT can help you to generate LOC cobnstrains from an eagle netlist. -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- |