Current Challenges in FPGA Prototyping

Complicated PCB Requirements

Designing PCB for the latest big FPGA is not an easy task. For example, Xilinx's Virtex-5 LX330 FPGA has 1700 pins with 1300 user IOs. It requires at least 18 layers to route the PCB. These FPGAs also require multiple voltages to operate, so if a design contains different IO standards, the PCB board may require up to five different voltages. Complexity increases even more when you try to put multiple FPGA on a single PCB.

Solution: Source a prototyping tool with comprehensive self-test capabilities to detect and deal with hardware issues as soon as they happen.

Long Bring-Up Time

Designers need a clear board-testing strategy prior to manufacturing because there will be thousands of pins to test. Without a good test plan, it will be hard to pinpoint problems if the board does not operate according to specifications.

The key question you should answer before you decide to build your own FPGA prototyping board is “How long it will take to bring up the board and test thousands of IOs?”. In many cases, your FPGA prototypes might require re-spin in order to work, which may add up to 2 months to your project.

Solution: Source a prototyping tool with comprehensive self-test capabilities to detect and deal with hardware issues as soon as they happen.

Performance

Designers always prefer to run the FPGA prototype at real-time or near real time speed to more closely approximate performance of the end product.

FPGA prototyping performance might not be able to achieve the actual performance of the target SoC/ASIC. There are generally two reasons for this performance discrepancy: FPGA limitations and PCB board limitations.

Solution1. FPGA limitation: Use different synthesis tools, tighten timing constraints, or modify your design. Solution2. PCB board limitation: Work with a well-designed prototyping board with equal-length clock traces, equal length IOs, and stable power and ground to accommodate prototyping at high speeds. Impedance matching may also be needed for extreme high-performance IOs such as DDR memory interfaces.

Reusability

The ability to reuse your existing prototype or at least part of your prototype can save development time and lower implementation risk for future projects.

SoC design sizes continue to grow as new semiconductor process become available and new application features are desired by consumers. Your FPGA prototype will probably require upgrading as well. Many designers like to build the interface to external systems directly on the FPGA board. This approach may serve for single projects but renders both the FPGA and the peripheral interface unfit for reuse in other projects if the design size is larger or the peripheral interface is different.

Solution: Structure your FPGA prototyping system into independent FPGA and interface boards to create modularity that allows for a high level of FPGA reusability.

Design Partition

Design partitioning is needed for designs that cannot fit into one FPGA.

Partitioning problems arise when the number of FPGA pins is limited, and is further is magnified as the number of FPGAs increases. There are generally two main issues to deal with: - How do you interconnect the IO among multiple FPGAs on your prototype? - How do you partition your design to fit the architecture of your FPGA prototype board. Hand partitioning a design to multiple FPGAs is error-prone and time-consuming. Examples of potential problems include: insufficient number of pins, clock synchronizations, failure to meet performance expectations, and external pin entry point.

Solution: Employ an integrated HW/SW prototyping system that upholds interconnect quantity and quality (via HW) and automatic partitioning (via SW), thereby saving development time.

Debug-ability

Taking steps to ensure a design is debug friendly minimizes the time spent on debugging later on in the process/schedule.

It's unlikely your design will work the first time after you download it to FPGA. Your design might not be working because 1) the FPGA prototypes itself has problems, 2) the design may have a problem and/or 3) error have accrued during design compiling (eg. wrong pin assignments). Ideally, you would first need a good testing method to identify if the hardware is running correctly and all the pins in the design are functioning normally. Then, either an External Logic Analyzer and/or Internal Logic Analyze (eg. Xilinx's Chipscope) would be needed to identify problem arising from design or mapping errors. This sometimes requires tedious work to get internal signals out to the boundary for external LA probing. Moreover, most internal logic analyzers today do not support debugging design mapped to multiple FPGAs – making your debugging job even more difficult.

Solution: Select a prototyping system that includes self-test function capabilities and supports logic analyzers that can debug multiple FPGAs.