FPGA Development Process
 | FPGA Minutes to Become an Expert RidgeRun documentation is currently under development. |
| FPGA Minutes to Become an Expert |
|---|
|
| Introduction |
| FPGA Knowledge |
|
Synthesis Flows
|
| Xilinx FPGAs |
|
Evaluation boards Development workflow and tools Getting Started |
| Lattice FPGAs |
|
Evaluation boards |
| Simulation Tools |
| CocoTB |
| AI and Machine Learning |
| Contact Us |
Development Process
Developing for FPGAs is different from developing software for CPUs or GPUs. In previous sections, we have discussed that, unlike CPUs or GPUs, FPGAs do not execute instructions but implement hardware. Therefore, to develop for an FPGA, we have to design an electronic circuit to be implemented through the logic cells inside of the FPGA.
The starting point of the development for FPGAs is the hardware description, where the digital logic is described through domain-specific languages called Hardware Description Languages (HDL). Within the options, we can highlight the following:
- VHDL
- Verilog
- Chisel
- Simulink (even though it is a tool)
We can associate these languages with the assembly for FPGAs. They are within the lowest levels of abstraction. Nowadays, hardware descriptions can be done using high-level languages like C/C++ or even Rust. The hardware generation process, which starts from these high-level languages, is called High-Level Synthesis (HLS), and it is becoming popular as the complexity of the tasks and the required productivity increases in exigence. It is possible to find HLS in FPGA-based acceleration like in Cloud FPGAs, which can use OpenCL like CPUs or GPUs.
From the Code to the Bitstream
The process begins with the hardware description in an HDL. It is an abstraction that describes logic through combinational behaviours and sequences (through clock sensitivity). However, the hardware description requires a translation into the FPGA architecture, transforming the logic to fit into logic cells. The combinational logic maps to LUTs and mux configurations, whereas the sequential logic requires D-type Flip-Flops to integrate the clock sensitivity. This translation process is called Synthesis.
The following steps are Placement and Routing. In this step, the synthesised units are mapped into the FPGA, placing blocks of the implementation into FPGA slices, which can be pure logic, or it can make use of special cells, such as the I/O blocks, DSP/Multipliers, or Block RAMs. Moreover, it connects the blocks.
Once the design is placed into the FPGA, the next step is the Design Analysis. In this step, an optimiser analyses the design already placed and routed, determining the critical paths for timing and the use of resources. Usually, the tools have presets for the optimiser, which balances area and timing. Nevertheless, the designer can establish optimisation goals (or constraints) that the optimiser will try to meet by iterating between the placement, routing, and design analysis until a Pareto optimal is reached. If the goals cannot be reached, the user is notified to relax or act on the design, i.e. splitting logic through pipelining or reorganising the circuit.
The final step is the Bitstream Generation, which generates the configuration file. This configuration file contains all the configurations the FPGA needs, such as the LUT functions, netlist, and mux configurations.
In summary, the workflow is as follows:
- Hardware description code in HDL
- Synthesis
- Implementation: Placement and Routing
- Bitstream generation
Regarding the use of HLS. It adds an extra step at the beginning, compiling the HLS code to generate HDL.
Novel Development Processes for FPGA-based Acceleration
The process described above is the legacy workflow for FPGAs. It is still followed under the hood by the novel development processes. Now, Altera and AMD have been working on new ways to simplify the development process, abstracting unnecessary complexity from users who are only required to accelerate applications by using FPGAs as accelerators.
The process has become quite similar to software development, where the code (in HLS) generates "object files" (called kernels). In the case of AMD, they call them .xo files, which are HDL descriptions wrapped into a standard AXI4 interface. Under the hood, the process can be summarised as the HLS compilation into HDL.
Once the .xo files are generated, they are "linked" altogether with a base design. The base design is a canvas that reserves the AXI4 connections and PL clocks for later reconfiguration required by the kernels. The linkage consists of generating the base design as a bitstream and the kernels as overlays placed on top of the base design to connect the clocks and the AXI4 ports. In a few words, it uses reconfiguration, but the process is still the same: Synthesis, Placement and Routing and Bitstream Generation.
Tooling
FPGA vendors propose their own tools for their FPGAs. They are
complete ecosystems or applications that integrate the synthesisers, simulators, optimisers, place and routers, etc. Below is a list of the most common tooling proposed by the vendors.
AMD:
- Vitis HLS
- Vivado Design Suite
- Xilinx Simulator (xsim)
Altera:
- Quartus HLS
- Quartus Prime
Lattice:
- Lattice Diamond (legacy)
- Lattice Radiant
Microchip:
- Libero SoC Design Suite
- SmartHLS (formerly LegUp)
There are open-source tools, such as Google's XLS. However, they will be explained in further posts.
Note: Vitis HLS, Vivado Design Suite and Xilinx Simulator are registered by AMD. Quartus HLS and Quartus Prime by Altera. Lattice Diamond and Lattice Radiant by Lattice, and Libero SoC and SmartHLS by Microchip.
RidgeRun Services
RidgeRun has expertise in offloading processing algorithms using FPGAs, from Image Signal Processing to AI offloading. Our services include:
- Algorithm Acceleration using FPGAs.
- Image Signal Processing IP Cores.
- Linux Device Drivers.
- Low Power AI Acceleration using FPGAs.
- Accelerated C++ Applications.
And it includes much more. Contact us at https://www.ridgerun.com/contact.