Fpga Design Process And Tool Flow

Using field programmable gate arrays (FPGAs) can significantly increase the complexity of the design process. As seen in the previous FAQ on the application considerations when selecting FPGAs, these devices can bring improved performance to complex functions and improve overall system performance. This FAQ will consider the design process for FPGAs while the next and final FAQ in this series will review system integration issues to be addressed when using FPGAs.

There are several steps in the design process when using any programmable logic, including FPGAs. These steps include design entry, design synthesis, and design verification (including functional verification and timing verification and takes places at different points during the design flow), design implementation, and device programming. The design process for FPGAs presents a variation on that basic process.

FPGA floorplanning identifies structures and functions that should be placed in proximity to each other. It can be used to reduce the amount of delay in a critical path. Floorplanning can be implemented when starting the FPGA design process before the first design iteration for design entry (place and route). It can also be used after a problem is identified during various steps of the design verification process to correct timing problems. With floorplanning, designers can identify portions of logic contributing to timing problems and correct the design entry information to reduce the routing delay.

Using floorplanning, the best grouping and connectivity of the FPGA blocks is implemented manually to increase density and performance while reducing delays. The designer uses floorplanning to guide the synthesis tool to structure the gates as determined by the floorplan. Floorplanning is also an important part of the iterative process of optimizing FPGA performance. It can help improve/optimize timing performance and consistency.

FPGA design flow process flow. (Image: Xilinx)

Design entry

After floorplanning, design entry is the first step in FPGA design and implementation. It can be accomplished using schematic entry tools or a hardware description language such as Verilog, VHDL, or ABEL that produce register transfer level (RTL) code. Some designers use a mix of both schematic entry and language-based tools.

Schematic entry can take more time, but it also provides designers with more control over the partitioning of the FPGA logic and over the interconnect scheme's physical placement. The use of language-based tools can speed the design entry process and result in lower performance or lower density. Language-based tools have been improved to the point that there is often little practical difference in using them versus using the more manual schematic entry process.

The use of predefined cores for specific functions such as PCI bus interfaces and DMA controllers, or even complete processors can speed the design entry process. Cores are predefined functions specifically implemented and verified. They can be hard cores (fixed-function gate-level IP within the FPGA fabric) or soft cores (implemented in an HDL language without extensive optimization for the target architecture). Soft cores are typically easier to use and lower in cost but offer lower performance and are less efficient than hard cores. The use of predefined cores can reduce design and verification time for commonly used functions.

Color-coded map of the I/Os of a multi-bank FPGA with different types of configurable pins. (Image: Cadence)

Design synthesis

Design synthesis uses instructions from a schematic entry tool or HDL language and produces a gate-level representation or netlist. Synthesis tools generate a bitstream of code for uploading into the FPGA.

Boolean algebra is used to formulate FPGA logic and circuit design. Synthesis tools interpret this logic into the look-up tables, flip flops, RAM blocks, and other elements that make up the FPGA. An FPGA synthesis tool serves a similar purpose to a software complier.

High-level synthesis (HLS) of FPGAs based on C++ can automatically add pipelining stages and clock constraints that improve performance. HLS can result in up to 5-times more design productivity than writing in RTL, and the resulting C++ code can be 5 to 10 times shorter than the RTL code. C++ can also result in easier readability and fewer bugs since it is expressed at a higher level of abstraction.

HLS verification can be simpler than comparable verification using RTL, and the use of HLS can result in greater FPGA design portability. Whether RTL or HLS is used, the automation of the logic design and synthesis processes can result in a level of standardization across various FPGA designs.

Design verification

Simulation and design verification takes place throughout the FPGA design flow. In general, three simulation methods are used at different stages of the design flow; behavioral, structural, and timing.

Initially, behavioral simulation provides a high-level of abstraction to the RTL description before and during design synthesis. High-level operations are considered without including specifics of how the design is to be implemented. Behavioral simulation is performed using a pre-synthesis HDL description of the FPGA. It runs the fastest but provides the least information about the design.

Behavioral simulation verifies syntax and functionality without timing information. This is an important part of the verification process. Early identification of errors ultimately speeds the design process and reduces the final cost to produce the FPGA design. Once the design's behavioral aspects have been finalized, structural and timing simulation methods are used to get more detailed verification data and optimize the design.

Once the structural and timing simulations have been successfully completed, the design is mapped to a netlist. At this stage, multiple iterations of simulation can be run. For example, the netlist can be translated to a gate-level description and a simulation run to confirm the performance of the synthesis. Finally, the design is ported to the FPGA, and propagation delays can be added, and the simulation rerun for more complete verification of functionality.

Design implementation

Following design synthesis, the design is ready to be implemented on the target FPGA. First, the design might need to be converted into a format supported by the design implementation tools supplied by the FPGA vendor. This should be quick, even automatic since most implementation tools can read netlist formats.

The tools translate the netlist and perform a design rule check and optimization. Next, the design is partitioned into the logic blocks available on the specific FPGA being used. Partitioning is important since good partitioning results in higher routing completion and better performance for the FPGA.

Once the optimal set of logic blocks has been developed, the implementation software identifies the optimal locations for each of the blocks to reduce the amount of interconnects needed and maximize the use of available resources, thus maximizing s performance. The routing lengths and possible points of routing track congestion are identified. In some cases, the absolute track delays are also identified by the implementation software to meet defined timing constraints for the design.

Simplified example of an FPGA logic cell (LUT – Lookup table, FA – Full adder, DFF – D-type flip-flop). (Image: Wikipedia)

The implementation process is analogous to the place-and-route programs used to design printed circuit boards. After the implementation has been successfully completed and verified, the software produces a binary programming file that can be used to program the FPGA.

In the case of large/complex FPGA designs, the implementation software may not successfully complete the design. The implementation software may try several different options and run through multiple iterations to arrive at a fully-routed design. It is generally recommended that designers use less than 85% of the available resources on the FPGA to ensure that the design can be implemented to result in a good level of performance.

FPGA programming

Once the programming file is finalized, it is time to program the FPGA. The programming method is dependent on the type of FPGA being used. For one-time programmable FPGAs, a device programmer is usually needed. In-system programmable FPGAs such as SRAM-based devices may not require a dedicated programmer, but they still need intelligent system devices to download the programming file into the device. This can be done with a microprocessor, microcontroller, or through a JTAG test port.

Finally, the programming can be done at the FPGA supplier, by a distributor, or the system maker can do the programming in the factory. Programming by the system maker can provide the highest level of IP security.

The design flow process for FPGAs is similar to that of other programmable devices and custom ICs such as ASICs. Floorplanning and the use of predesigned hardware or software functional cores can help to speed the process. The next and final FAQ in this series will dive into the system integration issues when using FPGAs.

References

Field programmable gate array, Wikipedia
Floorplanning Methodology Guide, Xilinx
FPGA design guidelines, Intel
FPGA system planner, Cadence