Board layout for FPGA
in [FPGA]
|
From: rickman on 5 Feb 2010 00:48 On Feb 4, 9:43 pm, TSMGrizzly <sbatt...(a)yahoo.co.jp> 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 In response to your other post about the bus timing, async memories are the hardest to design I have found. Sync memories like SDRAM are a snap really, you just meet the setup and hold times and you are done! The rest is all just a state machine. Async busses require all sorts of timing numbers to be checked, I bet you will have over 30 numbers you will need to validate while doing this. If you don't push the timing to the max it can be much easier. As to the randomization of the address/data lines, I have never done that, but others have. On the RAMs it shouldn't be a problem. It can even be worked around on the EEPROM if you have a program to remap all the bits in the memory map, but that is such a PITA. Getting your schematic to optimize the layout without randomization of the lines shouldn't be a real problem. Rick
From: TSMGrizzly on 5 Feb 2010 01:43 On Feb 5, 2:26 pm, rickman <gnu...(a)gmail.com> wrote: > On Feb 4, 4:04 am, TSMGrizzly <sbatt...(a)yahoo.co.jp> wrote: > > > 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. > > Signal integrity is not normally a direct result of the "loading" of > the parts. On most boards the effect of a pin on a bus is minimal. > If you split a run, like a fork in a river, it results in an impedance > mismatch and causes a reflection. The end of a trace is a high > impedance which also is an impedance mismatch and causes a > reflection. Three chips can be added to the board with trances as > short as maybe 2 inches. This is 4 inches round trip or about half a > ns. To avoid effects of reflection, the edge transition time should > be at least 3 ns. That is a *slow* edge. So expect noticeable > ringing. As has been said, on the data and address lines, you just > need to extend the setup times to wait it out to sample the bus when > it has quieted down. Figure three round trips or 1.5 ns extra. But > the write enable signal should be clean. The best way I know to do > that is to provide a separate write enable driver for each chip. Then > you can use series impedance matching in a point to point wiring so > that the receiver does not see any effects from reflection. Of course > this is assuming the write enable is the controlling pin when doing > writes. Some designs use the chip select to control the write > timing. > > > 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. > > Are you going to try to use them as fast as possible? That can be > hard. If you can give each chip separate drivers for all signals, may > be able to keep the traces short enough to not see any reflection > effects. I may have muffed the math on this. That's the trouble with > rules of thumb. If you recall them incorrectly, it can be hard to > spot the error. Looking at this document, > > http://techcircuits.net/docs/CriticalLength.pdf > > It looks like I was overly pessimistic on the length. The rule of > thumb seems to be 1/3 instead of 1/6 so a 1 ns rise time won't cause > significant reflections, but I'm not sure about that. On page 7 they > use an analysis that I don't agree with. Basically, they are saying > this is the critical edge of timing and I don't think it is that clear > cut. I say use 1/6, but you can choose your own poison. > > > 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. > > I would pick a newer family myself, but there is nothing wrong with a > Virtex II device. However, a newer family will be faster, lower power > and you will likely get better support. Of course you can overdo that > too. If you try to use the newest family, you may not get parts for > months and the tools may be a bit buggy... But Virtex 2??? Why not > Virtex 5 or even Virtex 4? The Spartan 3 chips are pretty good and > have been updated quite a bit although I don't recall which are the > latest and greatest. I know the S3 parts are FAPP not recommended for > new designs (at least by those of us here I expect) and the S3A parts > are pretty old at this point. Anyone, what are the newer S3x parts? > > If you want to keep the power supply simple, Lattice has XP and > perhaps XP2 parts that use a single 3.3 volt supply and internally > drop it to the core voltage. > > > 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? > > Yes, you can use one layer. I have a very tiny board <1" x 4.5" with > no less than four power planes on one layer, +12, +5, +3.3 and an > audio 3.3. There is another 1.8 volt plane in case I want to use an > FPGA with separate core voltage inputs, but that plane is on a > different layer shared with signal traces. I can't stress enough the > importance of power planes in keeping switching noise down. It is not > just a matter of adding a high frequency capacitor to the power rail, > it acts as a very low impedance transmission line connecting the > capacitors to the power pins of the chip. It is counter intuitive, > but it actually is not so important to keep the caps so close to the > chip if you are using good power planes. BTW, to maximize the > effectiveness of the power planes (read that as minimum impedance) you > want to have the power and ground plane as close together as > possible. 5 mils spacing should be practical and will go a long way > to doing a good job. > > I found doing layout to be fun, but very intense! Most design > requires you to go back and forth between specs and data sheets and > the schematic capture package. Layout has some up front work getting > all the inputs and making the footprints, but then it just becomes a > really complex rubics cube with many possible solutions. Your job is > to find one that is pretty good without spending tons of time on it. > > When I did my first layout, I contacted a couple of colleges and asked > them to do a design review with me. I was willing to pay them > consulting rates, but I was turned down. It turned out ok in the end, > but there were a couple of things that likely would have been caught > in a review. I am not very busy right now. If you would like and > when you are ready, I'd be willing to go through a design review with > you without charge. I'm pretty bored and would enjoy it. > > Rick Rick, thanks for all the help, and I appreciate the offer! I might take you up on it. If you send me an e-mail to the address displayed here, I can reply with a more useful e-mail address.. I use a kind of junk-ish secondary address to access google groups because of all the spam. I'd like not to be on google groups but I don't have a news server at the moment, and don't know where to go for one.. I have some other things to do (including programming and testing the first iteration on an already made dev board) so it's going to be a little while before my layout is ready to go. I have some reasons why Virtex-II and not something newer, and why SRAM and all that, and there is a little bit more to the overall system than I've mentioned though. As for remapping the EEPROM, I'm not too worried about that because I was going to whip up a second FPGA configuration just to write the contents of the EEPROM, so the addresses and bit orders will come out the same. But yeah I'd rather keep all the address lines as they are. I probably won't be pushing timing to the max.. the critical thing is that I can write continuously to RAM on a ~25MHz clock (or maybe I can afford to go with half that) for a certain period. Steve
From: Nial Stewart on 5 Feb 2010 05:12 > 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? Cypress don't even define address and data pin numbers for their synchronous rams (apart from A0 and A1). Go for it. Nial
From: Nial Stewart on 5 Feb 2010 05:15 > John, > I don't think I can get away with only the outer two rows of balls, > I'll probably need the two inside of that as well-- I was thinking of > breaking out the outer two on one signal layer and the inner two in > another, as suggested in the Xilinx app note I saw. It was a tight > squeeze but they wrote .127mm traces, and .3/.6mm on the vias, which > is the standard offering of the board house we're using.. it's > possible to ask for smaller, for an extra chunk of change. With 1mm ball pitch I use 0.5mm pads, 0.5mm vias with 0.25mm drills. This is pretty much run of the mill for fab houses and shouldn't add much to costs. The first four balls can then be routed out on the top and bottom layers. Nial
From: Martin Thompson on 5 Feb 2010 06:48
rickman <gnuarm(a)gmail.com> writes: > BTW, you are aware that the power plane is just as effective as the > ground plane for determining the impedance. Yes, but the OP needs to be aware that care can be required when switching your signal trace from one layer to another. When you switch to a layer which references the other supply rail, then the return current has to also switch layers. If the way it has to do that is via a decoupling cap a long way away then the current loop can be quite large. I got Henry Ott's new book just this morning, and he has some discussion on p630... If you use Amazon's "search in this book" feature from here: http://www.amazon.co.uk/Electromagnetic-Compatibility-Engineering-Henry-Ott/dp/0470189304/ and search for "Changing Reference Planes", you can see pp 630-631. To the OP - ...and then buy it :) Cheers, Martin -- martin.j.thompson(a)trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.html |