I have used a FPGA module, XPS, microblaze, verilog etc for a personal project. This was very interesting and now, I am trying to design my own FPGA mini board. This is also a learning experience, and of course, because I like that stuff. It turns out to be very interesting. I have read lots of datasheets, app notes, etc to try to get it right.
So, the question is, would experienced people be willing to spend a few minutes reviewing my schematics to tell me if I have some obvious errors ? What format should I use ? I use Eagle, so I can give Eagle files or plain PDF.
If this was for a business, we (the FPGA Lab) do this, as a service at Xilinx. Companies send me their schematics in pdf format, along with their board stackup (layer assignments, and thicknesses), and we review them.
We do not promise anything (for guarantees, you would need to go to Xilinx Design Services, and pay for a formal review with a formal report), but we do our best to comment on the bypassing, configuration, signal integrity, and whatever else we can see.
It is in our best interests that a pcb gets built, and works (parts get ordered that way).
But for an individual with a hobby, we are unable to offer this service. Perhaps someone else will volunteer?
Good luck.
You may also want to look at pcb documentation for demo pcbs that are available on our website:
Obviously ! I wanted to ask for the preferred format first, though. I have used FPGAs but this is the first time I design a FPGA board, so it would really be cool to have some "divine intervention" from the experts here to zap my bugs before they are comitted into copper. So, here is a PDF of the schematics :
formatting link
Since the free version of Eagle supports only one schematic sheet, this isn't very printable (since everything is on one page !)... also, it somehow converted the text to vector. Duh.
Anyway, this is a simple FPGA board with a Spartan 3E-500, 32 bit SDRAM, and a SMSC LAN9117 as network MAC+PHY. I went for simplicity so it has linear regulators ; and I didn't try to use the OpenCores MAC. This MAC chip has a nice interface and is supposed to be easy to program. Also drivers are available for happy hacking. I won't be using any OS since application is Ethernet streaming up to 100 Mbps and the Linux TCP/IP overhead is way too large for poor Microblaze. SDRAM and MAC do NOT share a multiplexed bus since I want to be able to extract some good network performance from this design.
Board layout needs to be done. This depends on the actual parts matching the Eagle libraries. Since I drew most of the large parts footprints from the datasheets, this means this will have to wait until I actually order and receive the parts from DigiKey, and put them into a laser printed paper version of the PCB to check alignment of the pins with the pads and holes. I hate it when the pins don't fit in the holes.
And, the FPGA pin-swapping obviously depends on the routing. Which is waiting for the parts. Chicken and egg !
Hence, in this schematic, all the address and data busses are not connected, and some signals too. Please do not look at this, since this is the easy part. Instead, I would really like some advice on the FPGA specific stuff, which is the hard part for me since it's the first time :
- did I route the clocks to the right pins so the DCMs are happy ?
- should the FPGA generate the clock to be sent through the connector or should I send the oscillator's output ?
- is the power supply OK ?
- will it really program itself from the flash as the datasheet says ?
- will my JTAG work ?
- is my Ethernet jack schematic and layout OK ?
- will it smoke ?
- will my SPI interface & prog_b jumper be enough to rescue a crapped up flash bitstream ?
- does it suck ?
- do I need to add resistors to the data lines ?
Well I guess you get the idea ;) I will build a shrine to a guy nice enough to save me a PCB iteration !!!
Normally I would illustrate the regulator (like your LT1764A) with the required output cap right next to it, just to clarify which cap is meeting the requirements of the regulator. Considering the datasheet dedicates about 3.5 pages to the output cap...
Also, I'd question your 220u on that rail. Take a look at the datasheet figure 9 -- it illustrates the performance of the 1.2V regulator with different output cap networks. Notice the 100u poly cap has a 35mOhm ESR. If your 220u is a plain old elecrolytic it's probably useless.
Offhand I'm not seeing where you get voltage rails like MAC_VDD_PLL, but if they are other common voltages you should make semi-isolated versions of them with cap-ferrite bead-cap. If any of the key analog voltages are your 3.3V (which you get from off-board) I'd strongly consider making a special, clean 3.3V from some higher rail just for that.
You might need a multi-voltage reset controller to avoid power sequencing problems. You'd have to check all the datasheets to see if they're all tolerant of their rails coming up in the order produced by your board.
Speaking of which, I wouldn't drive your MAC reset with FPGA_DONE. Use a dedicated IO for it. You can end up making it 'assign MAC_RESET=0' but if you need it it will be changable.
Where you split your clk into CLK_OUT and FPGA_CLK, put a series R on both legs.
You need some pullups there for when the jtag connector is not hooked up.
Nah, if you make schematic errors it probably just "won't work", unless your symbols have mistakes, in which case it might smoke. ;-)
Via what? You'll be able to load bitstreams directly via JTAG no matter what the state of the flash.
It's probably going to cost you more than buying a dev board with equivalent functionality. But what would you learn from that??
You can always stuff them with 0R if you need to. If your design rules allow it, something like a CTS 742C083 series resistor array would be easy to fit in the layout. That package is basically 3 0603 resistors side by side in one 1206 package.
Oh yeah, give yourself some pushbuttons to force reprogram, reset, etc. And some LEDs. You'll want something dead simple to do your initial bringup tests.
Maybe for the address lines, but the data lines are bidirectional. If you plan to run the SDRAM at 10MHz, I wouldn't give it a second thought. If you're aiming at >100MHz then you probably want to give yourself the option.
I just pulled out an old SODIMM and it has 16 4x 10R arrays (64 lines total).
OK, I had forgotten that the SDRAM chip doesn't have a drive strength limit option...
I'll use Xilinx mch_opb_sdram controller with XCL links to the CPU. The "mch" (multichannel) part isn't of any use to me but I tested this core versus the standard SDRAM core in a previous FPGA design and found this one to be much faster, and it plays well with the DMA controller's bursts.
So the SDRAM will probably run around 50-70 MHz if I believe the core's datasheet, on SPartan-3E.
I will locate the single 32-bit SDRAM chip below the FPGA, on the other side of the board (it's a PQFP 208) so trace length and skew will be minimal (about 1 cm). I may still have room for the resistor arrays, though. Since the FPGA limits its drive strength, I should place the resistors at the SDRAM pins, I think ?
However, for the connector IO, I believe I can use the FPGA drive strength setting for signals sent by the FPGA, and place resistors (source-termination) at chips on the carrier board which will send data to the FPGA, right ?
For a point-to-point solution on a small board, I'd suggest the series resistors are overkill for data and address lines. If there were multiple loads, those resistors could be very handy. If the routing length was 6" or more, those resistors could be very handy. For even a
200 MHz SRAM interface placed very close to the FPGA, I had no qualms about point-to-point connections.
For the signals that are *edge* critical, the resistor placeholder could be helpful to avoid some overshoot or troubles with monotonicity but I'd expect a smooth signal regardless if the transmission length is that short. __________________
One additional quick item - how are you hooking up the JTAG? If you're using the Xilinx programming adapter (I really prefer the Platform Cable USB) I'd suggest using the connector and pinout that plays nice with the ribbon cable connection.
If this is board will have very few items produced, I'd also suggest using a memory that has a JTAG interface such that programming the Flash and reconfiguring the FPGA on the fly are both done with the same connect-in and forget-it interface. It may be a few dollars rather than
50 cents for a chip that gives you the flexibility, but I'd glagly take a $40 hit to avoid reconnecting those darned header signals over and over. A quick on-and-off connection with the 1mm spaced ribbon cable is so much easier than dealing with the flying leads and, perhaps, better for signal fidelity which can be an issue sometimes.
I have tried to apply all the advice given by Ben Jackson and John-H. So, here is the updated schem & now fully routed board.
formatting link
Thanks a lot ! I guess I've got to order the parts now, check footprints with the real thing...
OK. That's cool, because when putting the SDRAM below the FPGA there isn't much space for resistors...
I have a JTAG parallel port gizmo from Trenz ; it works well and is compatible with the Xilinx tools. I'll use a compatible header on my board so a simple ribbon will work.
iMPACT can write the flash via the FPGA's own JTAG, I will use this feature.
Oh yeah. Flying leads are a pain. How come they could agree on everything in JTAG to make it a standard, except the pinout ????
Your schematic shows a JTAG header and an external programming interface header for the ATMEL flash. If you're suggesting that Impact will reach out of the FPGA on the passive serial lines and program the flash there, I don't know the tools like I thought I did.
If I do understand the tools, the FPGA can be programmed with the JTAG but the flash will have to be reconnected through your external programming header. If you used a JTAG-compatible memory rather than the economical ATMEL chip, you would have a daisy-chain of the two devices in your JTAG chain. Programming the FPGA or the Flash would be a simple matter of selecting which chip for Impact to target.
XAPP 445 page 9 seems to hint at this. I could also upload a bitstream containing a bootloader and SPI flash driver, an send configuration via the serial port. I reprogrammed the parallel Flash on my previous FPGA module this way.
Can you point to a suitable Flash chip supporting JTAG, just in case ?
The Xilinx XCS04S would give you the JTAG connections for reprogramming and is certainly supported well by the Impact tools.
The Spartan-3E Family Complete Data Sheet's section on Configuration (in the Functional Description) has a direct link to the Platform Flash product page in the Spartan-3E Configuration Mode Options and Pin Settings table.
I don't know if Xilinx can do that, but there's an Altera megafunction called "Serial Flash Loader" (SFL) which can do that with the Quartus II programming tool. That means you can have just one external header (JTAG) and have access to do direct bitstream loads, signaltap and flash programming.
OK, I'll include one, found it on DigiKey, it fits nicely. I'm keeping the SPI DataFlash, though, but it will only contain the software code that the BRAM microblaze bootloader will copy into SDRAM, you know the story. I don't know if I will need it though, if the Ethernet driver fits in BRAM, it would be able to load the software from the PC via ethernet on boot, so it'll always be up to date without flashing !
Actually, I possibly skrewed up ;) in my datasheet reading... XPS can load a parallel flash if your design contains an opb_emc memory controller though. So for safety I put a JTAG Platform Flash to configure the FPGA. SPI flash will just store software (or maybe even not be populated).
formatting link
I think I'll order the stuff at DigiKey tomorrow. Yes !!
Yes, if you make a design with some RAM and a parallel flash, the Xilinx tools will build an application to run on this design (I'm thinking PPC here, but maybe it also does this if you include microblaze?) that will program the flash memory.
It's pretty slow, though. As soon as we had our own stuff booting and talking on the network we switched to programming that way.
If it makes you feel better, the hardware guys at work put platform flash down on the first few revs of a much more complex board than yours (ultimately booted by a CPLD sequencing the parallel flash) just to be sure the FPGA would configurable right away...
(btw, I just got my pcbs today and assembled my FLEX board and everything works! yay!)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.