6
\$\begingroup\$

I am planning to design a custom FPGA PCB. the PCB will contain sensors. I need to read the output of the sensors and process them in the processor. I have completed many projects using FPGA's, but this will be my first custom design where I need to consider the hardware configuration as well. I have done research lately, but it is still hard for me to start from a point. Therefore I am asking you to help me and other individuals who wants to design their custom FPGA what are the points they need to consider at each step. Are there books/online resources which can help us in this process? I will also make a document after I have finished my project so people can make use of it.

\$\endgroup\$
  • \$\begingroup\$ Perhaps you should mention the physical size of the FPGA you plan to use, the number of pins, required supply voltages, ... \$\endgroup\$ – Dzarda Sep 3 '14 at 9:47
  • \$\begingroup\$ These are not specified yet. Maybe my question was unclear, but I am looking for a guideline. \$\endgroup\$ – omid Sep 3 '14 at 10:00
  • \$\begingroup\$ Ok, fair enough. \$\endgroup\$ – Dzarda Sep 3 '14 at 11:07
  • \$\begingroup\$ This question appears to be off-topic \$\endgroup\$ – Roh Sep 3 '14 at 12:00
  • 4
    \$\begingroup\$ The big question is if you are willing to use a BGA package, or if you are going to restrict yourself to the subset of offerings (and reduced electrical performance) available in handwork-friendly TQFP packages. Next, are you hoping to get all your supplies and signals routed on two layers (tricky but possible for limited goals) or are you willing to use 4 or more? How fast are your sensor signals? At what rate were you hoping to clock the internal logic? Do you have any noise-sensitive analog? Have you considered making a daughterboard to use with an existing FPGA board? \$\endgroup\$ – Chris Stratton Sep 3 '14 at 15:03
8
\$\begingroup\$

At my company, we've previously designed some custom FPGA boards, and have recently started using commercial off-the-shelf ("COTS") FPGA boards with custom FMC daughterboards.

Prototype stage

If you're still in the early project definition stage, plan on buying at least one COTS FPGA board for prototyping. You can wire up one of your sensors to the I/O headers and do a quick proof-of-concept. That gives you an idea how the project might perform when scaled to many sensors, and estimate how many you can support with a given FPGA.

If the FPGA is too small or too slow or the tools are inadequate for the job, it's easy to swap in a different COTS FPGA at this stage. (Well not easy but at least manageable...)

If the firmware doesn't work at this stage, it's clearly because of a firmware problem, not a custom PCB design error. With custom firmware and custom PCB, it's sometimes hard to tell which side is at fault for a problem.

Custom FPGA board versus Commercial Off-The-Shelf FPGA board

Designing a custom FPGA board makes sense if the project will have a short life cycle, high volume, or requires a smaller form factor than you can achieve with COTS FPGA board and PMOD or FMC add-on boards.

If the project life cycle exceeds the product lifetime of a DDR memory chip (a couple of years), then designing a custom FMC daughterboard may be a better alternative.

Cost is a factor in this decision. Most COTS FPGA boards are somewhat general-purpose, designed for maximum flexibility. If you're making a high-volume, cost-sensitive product, then it is probably worthwhile to make a custom design; but for low-volume you are probably better off concentrating on making a daughtercard.

Regardless of which approach you choose, there are certain interfaces that require clear, master documentation: at the interface between the FPGA toplevel I/O pins and the rest of the board, and at the connector interface between boards. These are places where pin locations, internal net names, and external net names sometimes get mismatched and swapped. A table is sufficient documentation; be sure to keep this interface table versioned and under source control. Before sending PCB files to fabrication, print out a copy of this interface table, a copy of the schematic, and a copy of the FPGA pin/pad report. Drag a highlighter across the papers to check off each signal connects where it should.

For connectors, I've learned the hard way to provide a mechanical "system drawing" that shows both boards and mating connectors together on a single, dimensioned drawing. I first got burned by a VME connector system where pin "A1" on one connector did not map to pin "A1" on the other connector. I've also seen designers forget that a pair of right-angle connectors results in a mirror image connection (90 degrees + 90 degrees = 180 degrees). This was a problem when I was responsible for the motherboard and several other project managers were responsible for various daughterboards.

Custom FPGA board tips

Start with the "reference design" from the FPGA vendor, and then omit whatever parts aren't required for your application. Don't remove any bypass capacitors from the FPGA, and don't try to get away with using fewer PCB layers. Pay attention to the layer stack (often found alongside the drill drawing); fine pitch components typically use 0.5oz copper instead of the standard 1oz copper foil thickness.

BGA package is a pain to work with. Yield is never as good as with TQFP or TQFN packages, and reworking a BGA is near impossible. Even inspecting for assembly problems requires an X-Ray imager. Be sure to use a Contract Manufacturing service provider you trust.

Power supplies are always tricky when working with FPGA boards. The actual power requirements of the FPGA depend very strongly on the configuration bitstream. Xilinx provides a "power estimator" tool, but the estimate is only valid if the firmware is complete. There's a risk when making a last-minute firmware change, that the power requirements are greater than expected. Plan on leaving some supply current margin. If the initial power estimate says you need 560mA, go ahead and use a 1000mA regulator. The extra available output current does no harm, but having insufficient output current will result in aberrant system behavior.

If there are any uncommitted FPGA pins, bring out as many as possible to a header. When there is a problem, these uncommitted pins become a valuable diagnostic resource for probing signals inside the FPGA.

\$\endgroup\$
9
\$\begingroup\$

I've designed over a dozen FPGA based boards that employed a wide range of different types of FPGAs from low power Lattice Mach X02s to high performance Virtex 6's with 24 SERDES channels. The normal steps I follow are:

Find a COTs board (similar to MarkU) and get a rough idea of the internal FPGA resources you will need, in particular I pay attention to:

  • LUT (look up table) count: (does the design fit into the LUTs on the reference board?) If you don't have the resources or an exhaustive method to determine a precise estimate of the LUT usage (< 1K LUT accuracy) because perhaps the design isn't finished. Use this rule of thumb. If the design is nearly finished take the size of the design (LUT count) and find an FPGA with at least 30% more LUTs. if the design is not close to finished go up to 50% or 100% more LUTs. So if the design fits into 9K LUTs make sure to use an FPGA with 12K LUTs or greater. I tend to go overkill and probably would go up to 25K LUTs. This will save you excruciating headaches later. Whomever is commissioning this board design should understand that there should be more than one spin of this design so it is understandable to oversize the first version of the FPGA. There are a lot of available FPGAs that have different LUT counts in the same package size so for example the Xilinx Spartan 6 LX45 Package is the same as the LX75 so you can start out by using a the LX75 (75K LUTs) and if your design easily fits into less than 40K LUTs then you can save costs on the design with just a BOM Change.
  • BRAM (Block RAM count): Determine if your design requires more memory resources than your FPGA has internally. This is easily overlooked at first but in a design you tend to use block RAM for various reasons (ROMs, FIFOs, etc...) I ran out of block memory on a design and attempted to use distributed RAM (using the LUTs as RAM) and it ate up all my LUTs very fast. It's important to determine if you will require external memory. This adds a lot of risk to designs because if the design requires any level of performance you can't just use an external SRAM or SDRAM as your memory because their data transfer rates from these components are terribly slow compared to the speed at which you can move data around in your FPGA so the only comparable way to move data is with DDR2 and DDR3 and if you have to use these you add risk due to mistakes in schematics and layout and more work for the HDL team.
  • Enumerate all signaling standards and possible voltage levels your will use: This is important because some of the signaling standards you wish to use (LVDS, LVSPEC, LVCMOS) may have voltage restrictions. Go through the user guides and make sure all these standards are supported.
  • Power supply requirements: I sympathize with all the previous gripes about undersized power supplies getting the core voltage spec'ed is tuff, lately I have been using a lot of TI Nano modules for the large but low end FPGAs (Spartan LX45(T) - LX75(T) and Lattice ECP3). Fortunately you can mitigate some of the risks on when sizing the power supplies used for the I/O. In particular if this bank is not driving an unknown source (expansion connector) then the process is as follows: Find all the components that this bank will attach to, determine the input capacitance for all of those components, find out the maximum clock rate you will be driving these signals then you can calculate both the power requirement and roughly estimate the bypass requirement, although a lot of the FPGA manufacturers have been putting on the minimum bypass capacitor requirements in something like the DC Switching Guidelines.

Using the equation [P = (1/2)CV^2 * (f)] where C = input capacitance, f = frequency. of the input your FPGA must drive (For each signal!). you can find out worst case estimate on how much power is required to drive all output signals.

You will also need to consider the power loss associated with internal termination resistors (based on the I/O standards you use)

I have also been using the TI Webbench tool more and more lately with a lot of success:

TI Webbench (I don't work for TI)

Schematics:

  • Set up your schematic with an idiot in mind You and all the HDL designers will be coming back to this schematic a lot so make it easy for everyone to find what they need quick without requiring future you or them to research the entire schematic to find out if Pin 20 is the clock input. This includes lots of notes on the schematic (if possible), describe the purpose of a circuit, expected outcome and even concerns. Because FPGAs can be broken down into banks consider breaking the FPGA component into multiple parts and maybe even dedicate an entire schematic page for an individual bank.

  • PUT HUGE ANNOYING NOTES IN YOUR SCHEMATIC ABOUT ATTACHING CLOCKS TO THE CORRECT PINS: I've banged my head against many walls when I was building my first image for the design and get the dreaded 'clock signal routed on a non-clock enabled pin'. Live in fear of the various types of clock pins on the FPGA. Make sure you understand that some clock pins are intended for use on a quadrant of an FPGA or else you will face everyone saying: "Hey did you know there are certain clock pins that are intended for use on a quadrant of an FPGA". It only takes 15 people telling you this to make sure you never do it again.

  • SPEND A LOT OF TIME ON THE FPGA CONFIGURATION DESIGN: Make sure you bring out the JTAG pins even if you don't plan to use them. It is the difference between a workable error and a fatal flaw.

  • When in doubt bring out extra signals buttons and LEDs and dip switches: I have griped a lot about the extra work associated with routing extra signals to breakout headers LEDs, dip switches and buttons but it has ALWAYS helped out.

Layout:

  • Communicate with the Fab house early: Especially if you might need impedance controlled routing ask for a layer stack up for the desired layer count. It's much easier to route high speed signals when you have the trace widths defined first as apposed to figuring out that you could have used 6 mil traces instead of 8 mil traces to accomplish your 50 ohm impedance.

  • Start with bypass caps: Design the power system early. The first thing I do is start by placing all the small caps under the FPGA or close to the pins. The larger ones outside the FPGA and route an entire power supply circuit and place it roughly where I expect it to be. This way you won't be fighting the routing puzzle and making compromises.

  • High speed signals second: These will be ones you don't want to jump too many layers.


I'm always learning more things and would love any other tips that other designers have come across so please add them.

\$\endgroup\$
5
\$\begingroup\$

I think a good starting point for a custom PCB equipped with a FPGA will be the reference design boards from the FPGA vendor. You can inspect these designs for example for the power supply, but be aware that reference design boards are sometimes undersized. We had many trouble with Xilinx ML605 boards loosing there configuration, because of an undersized power supply.

Answere to omid's comment:

One of my colleagues implemented a systolic computation algorithm on a Virtex-6 LXT240. The data input was supplied by Gigabit Ethernet. Due to the systolic approach the FPGA did nearly nothing if no data was in the input fifos or mainly all flip flops of the FPGA were toggling with 200 MHz if a new ethernet frame arrived. This imbalance in computation caused the TIs power supply circuits to shutdown the ML605 board which could only be recovered from this state by switching the main power switch.

We gave this design to the department of electrical engineering at our university and they figured out, that there is no way to adjust the regulator coefficients based on the installed capacitors.

Yes, one could say: bad design or use bigger fifos or ...

My colleagues solution was a reduced FPGA utilization of 80%.

Nevertheless, a prototyping board and reference design should be capable of handling extremes workloads, especially if this board holds a FPGA which has not an as regular power usage as a CPU.

\$\endgroup\$
  • \$\begingroup\$ Can you explain what do you mean by "undersized" that I should be aware of? \$\endgroup\$ – omid Sep 4 '14 at 7:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.