Why OpenFPGA?

Note

If this is your first time learning OpenFPGA, we strongly recommend you to watch the introduction video

OpenFPGA aims to be an open-source framework that enables rapid prototyping of customizable FPGA architectures. As shown in Fig. 1, a conventional approach will take a large group of experienced engineers more than one year to achieve production-ready layout and associated CAD tools. In fact, most of the engineering efforts are spent on manual layouts and developing ad-hoc CAD support.

Fig. 1 Comparison on engineering time and effort to prototype an FPGA using OpenFPGA and conventional approaches [All the layout figures are publishable under the proper licenses]

Using OpenFPGA, the development cycle in both hardware and software can be significantly accelerated. OpenFPGA can automatically generate Verilog netlists describing a full FPGA fabric based on an XML-based description file. Thanks to modern semi-custom design tools, production-ready layout generation can be achieved within 24 hours. To help sign-off, OpenFPGA can auto-generate Verilog testbenches to validate the correctness of FPGA fabric using modern verification tools. OpenFPGA also provides native bitstream generation support based on the same XML-based description file used in Verilog generation, avoiding the recurring engineering in developing CAD tools for different FPGAs. Once the FPGA architecture is finalized, the CAD tool is ready to use.

OpenFPGA can support any architecture that VPR can describe, covering most of the architecture enhancements available in modern FPGAs, and hence unlocks a large design space in prototyping customizable FPGAs. In addition, OpenFPGA provides enriched syntax which allows users to customize primitive circuits designed down to transistor-level parameters. This helps developers to customize the P.P.A. (Power, Performance and Area) to the best. All these features open the door of prototyping/studying flexible FPGAs to a small group of junior engineers or researchers.

In terms of tool functionality, OpenFPGA consists of the following parts: FPGA-Verilog, FPGA-SDC, FPGA-Bitstream and FPGA-SPICE. The rest of this section will focus on detailed motivation for each of them, as depicted in Fig. 2.

Fig. 2 OpenFPGA: a unified framework for chip designer and FPGA programmer

Fully Customizable Architecture

OpenFPGA supports VPR’s architecture description language, which allows users to define versatile programmable fabrics down to point-to-point interconnection. OpenFPGA leverages VPR’s architecture description by introducing an XML-based architecture annotation, enabling fully customizable FPGA fabric down to circuit elements. As illustrated in OpenFPGA architecture description language enabling fully customizable FPGA architecture and circuit-level implementation, OpenFPGA’s architecture annotation covers a complete FPGA fabric, including both the programmable fabric and the configuration peripheral.

Fig. 3 OpenFPGA architecture description language enabling fully customizable FPGA architecture and circuit-level implementation

The technical details can be found in our papers [TGMG19] [TGA+19].

FPGA-Verilog

Driven by the strong need in data processing applications, Field Programmable Gate Arrays (FPGAs) are playing an ever-increasing role as programmable accelerators in modern computing systems. To fully unlock processing capabilities for domain-specific applications, FPGA architectures have to be tailored for seamless cooperation with other computing resources. However, prototyping and bringing to production a customized FPGA is a costly and complex endeavor even for industrial vendors.

OpenFPGA, an opensource framework, aims to rapidly prototype customizable FPGA architectures through a semi-custom design approach. We propose an XML-to-Prototype design flow, where the Verilog netlists of a full FPGA fabric can be autogenerated using an extension of the XML language from the VTR framework and then fed into a back-end flow to generate production-ready layouts. FPGA-Verilog is designed to output flexible and standard Verilog netlists, enabling various backend choices, as illustrated in FPGA-Verilog enabling flexible backend flows.

Fig. 4 FPGA-Verilog enabling flexible backend flows

The technical details can be found in our papers [TGC+20] [TGG+20] [GTG21]

FPGA-SDC

Design constraints are indepensible in modern ASIC design flows to guarantee the performance level. OpenFPGA includes a rich SDC generator in the OpenFPGA framework to deal with both PnR constraints and sign-off timing analysis. Our flow automatically generates two sets of SDC files.

• The first set of SDC is designed for the P&R flow, where all the combinational loops are broken to enable well controlled timing-driven P&R. In addition, there are SDC files devoted to constrain pin-to-pin timing for all the resources in FPGAs, in order to obtain nicely constrained and homogeneous delays across the fabric. OpenFPGA allows users to define timing constraints in the architecture description and outputs timing constraints in standard format, enabling fully timing constrained backend flow (see FPGA-SDC enabling iterative timing constrained backend flow).

• The second set of SDC is designed for the timing analysis of a benchmark at the post P&R stage.

Fig. 5 FPGA-SDC enabling iterative timing constrained backend flow

The technical details can be found in our papers [TGA+19] [TGC+20] [TGG+20].

FPGA-Bitstream

EDA support is essential for end-users to implement designs on a customized FPGA. OpenFPGA provides a general-purpose bitstream generator FPGA-Bitstream for any architecture that can be described by VPR. As the native CAD tool for any customized FPGA that is produced by FPGA-Verilog, FPGA-Bitstream is ready to use once users finalize the XML-based architecture description file. This eliminates the huge engineering efforts spent on developing bitstream generators for customized FPGAs. Using FPGA-Bitstream, users can launch (1) Verilog-to-Bitstream flow, the typical implementation flow for end-users; (2) Verilog-to-Verification flow. OpenFPGA can output Verilog testbenches with self-testing features to validate users’ implemetations on their customized FPGA fabrics.

The technical details can be found in our papers [TGMG19] [TGA+19].

FPGA-SPICE

The built-in timing and power analysis engines of VPR are based on analytical models [BRM99, GW12]. Analytical model-based analysis can promise accuracy only on a limited number of circuit designs for which the model is valid. As the technology advancements create more opportunities on circuit designs and FPGA architectures, the analytical power model requires updates to follow the new trends. However, without referring to simulation results, the analytical power models cannot prove their accuracy. SPICE simulators have the advantages of generality and accuracy over analytical models. For this reason, SPICE simulation results are often selected to check the accuracy of analytical models. Therefore, there is a strong need for a simulation-based power analysis approach for FPGAs, which can support general circuit designs.

It motivates us to develop FPGA-SPICE, an add-on for the current State-of-Art FPGA architecture exploration tools, VPR [RLY+12]. FPGA-SPICE aims at generating SPICE netlists and testbenches for the FPGA architectures supported by VPR. The SPICE netlists and testbenches are generated according to the placement and routing results of VPR. As a result, SPICE simulator can be used to perform precise delay and power analysis. The SPICE simulation results are useful in three aspects: (1) they provide accurate power analysis; (2) they help to improve the accuracy of built-in analytical models; and moreover (3) they create opportunities in developing novel analytical models.

SPICE modeling for FPGA architectures requires detailed transistor-level modeling for all the circuit elements within the considered FPGA architecture. However, current VPR architectural description language [LAR11] does not offer enough transistor-level parameters to model the most common circuit modules, such as multiplexers and LUTs. Therefore, we are developing an extension on the VPR architectural description language to model the transistor-level circuit designs.

The technical details can be found in our papers [TGM15] [TGMG19].