PRGA: An Open-Source FPGA Research and

Prototyping Framework
Ang Li David Wentzlaff
angl(at)princeton(dot)edu wentzlaf(at)princeton(dot)edu
Princeton University Princeton University
Princeton, New Jersey Princeton, New Jersey

ABSTRACT 1 INTRODUCTION
Field Programmable Gate Arrays (FPGA) are being used in a fast- Field Programmable Gate Arrays (FPGAs) have become an in-
growing range of scenarios, and heterogeneous CPU-FPGA systems creasingly important tool to enable application performance in
are being tapped as a possible way to mitigate the challenges posed a post Moore’s Law [19] world. Whether they are being used as
by the end of Moore’s Law. This growth in diverse use cases has a standalone compute fabric or a supplement to processors at the
fueled the need to customize FPGA architectures for particular chip-level [8, 10, 29], board-level [20], system-level, or datacenter-
applications or application domains. While high-level FPGA models level [1, 5], the diversity of use cases and importance of FPGAs
can help explore the FPGA architecture space, as FPGAs move to have been increasing. Ideally, an FPGA architecture should be op-
more advanced design nodes, there is an increased need for low- timized for each unique use case. In practice, though, it is very
level FPGA research and prototyping platforms that can be brought challenging to evaluate different FPGA designs in detail and even
all the way to fabrication. more challenging and time-consuming to prototype and bring those
This paper presents Princeton Reconfigurable Gate Array FPGAs to fabrication. This is because FPGA chip design flow has
(PRGA), a highly customizable, scalable, and complete open-source diverged from the design flows of other digital ASICs like pro-
framework for building custom FPGAs. The framework’s core func- cessors. Commercial FPGAs are often designed with custom cells
tions include generating synthesizable Verilog from user-specified and specialized EDA tools that are publicly unavailable. Likewise,
FPGA architectures, and providing a complete, auto-generated, each unique FPGA requires the creation of customized CAD tools.
open-source CAD toolchain for the custom FPGAs. Developed in Due to this high design cost, commercial FPGA vendors typically
Python, PRGA provides a user-friendly API and supports use both offer a limited set of designs optimized across common, but poten-
as a standalone FPGA as well as an embedded FPGA. PRGA is a tially non-characteristic, use cases. Due to similar reasons, FPGA
great platform for FPGA architecture research, FPGA configuration architecture studies often use and stop at high-level models [4, 21].
memory research, FPGA CAD tool research, and heterogeneous To facilitate FPGA architecture research and enable designs op-
systems research. It is also a completely open-source framework timized for custom applications, tools are needed to evaluate, opti-
for designers who need a free and customizable FPGA IP core. An mize, and prototype FPGA architectures all the way down to the
FPGA designed with PRGA is placed and routed using standard fabrication level. An ideal framework would be easy-to-use, exten-
cell libraries. The design is evaluated and compared to prior works, sible, scalable, and open-source. A framework that provides synthe-
providing comparable performance and increased configurability. sizable RTL enables gate-level or transistor-level implementation
using commercial ASIC design flows and standard cell libraries. By
CCS CONCEPTS enabling such physical prototyping, a framework can be used to
• Hardware → Reconfigurable logic and FPGAs. evaluate timing, power, and area with the utmost fidelity. Likewise,
RTL-level prototyping incorporates the details of the configuration
KEYWORDS memory, enabling research on bitstream format and partial or dy-
namic reconfiguration. High-level modeling tools are an important
FPGA; FPGA architecture; open-source hardware
first step, but there exists a need for low-level (RTL and below)
ACM Reference Format: frameworks that can be used to study low-level issues such as
Ang Li and David Wentzlaff. 2021. PRGA: An Open-Source FPGA Research floorplanning, design regularity, signal integrity, and other physical
and Prototyping Framework. In Proceedings of the 2021 ACM/SIGDA Interna-
design issues all while providing the path to then take the optimized
tional Symposium on Field Programmable Gate Arrays (FPGA ’21), February
28-March 2, 2021, Virtual Event, USA. ACM, New York, NY, USA, 11 pages.
design through prototyping and fabrication.
https://doi.org/10.1145/3431920.3439294 In this paper, we present Princeton Reconfigurable Gate
Array (PRGA), a highly customizable, scalable, and complete
Permission to make digital or hard copies of all or part of this work for personal or open-source framework for building custom FPGAs. PRGA is
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation available at https://parallel.princeton.edu/prga. Fig. 1 shows
on the first page. Copyrights for components of this work owned by others than the the workflow used to design a custom FPGA and then develop an
author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or application that uses it. The PRGA FPGA architecture is highly
republish, to post on servers or to redistribute to lists, requires prior specific permission
and/or a fee. Request permissions from [email protected]. customizable, and it supports user-provided modules such as SRAM
FPGA ’21, February 28-March 2, 2021, Virtual Event, USA macros, hard arithmetic units, and routing switches, all of which
© 2021 Copyright held by the owner/author(s). Publication rights licensed to ACM. can be easily added into the flow. PRGA is developed in Python and
ACM ISBN 978-1-4503-8218-2/21/02. . . $15.00
https://doi.org/10.1145/3431920.3439294 provides a well-defined Python API. Extensions are encouraged and
 Figure 1: Overview of a typical PRGA workflow
supported through modularization and low-level APIs. To further with support for partial reconfiguration. Custom configura-
lower the barrier of extending the framework, most output files tion circuitry can also be designed using low-level API.
are generated from human-readable Jinja [25] templates that are • CAD Support
customizable without changing the Python codebase. At the end of (1) Auto-generated Yosys script for synthesis: BRAM inference,
the FPGA design flow, PRGA produces human-readable, industry- hard logic techmap, and post-synthesis simulation.
standard, Verilog files that are synthesizable and physically imple- (2) Auto-generated, FASM-annotated VPR inputs for place-
mentable using commercial EDA Tools. PRGA is ASIC-friendly and ment, routing and raw bitstream generation.
can be used to generate standalone FPGAs as well as embedded • ASIC Compatibility
FPGAs, where the customization that PRGA provides is critical. (1) Bring-Your-Own-Circuits: replace generated modules with
PRGA is not derived from prior FPGA modeling/exploration custom Verilog modules or hard macros.
tools. Therefore, it is not restricted by the internal representations (2) ASIC-friendly module hierarchy: fracturable switch box
of legacy tools. This enables PRGA to support flexible hierarchies to maximize regularity; arbitrary levels of sub-arrays to
that match physical implementation needs. Likewise, the generated balance ASIC QoR and ease-of-backend.
configuration circuitry is highly flexible and is decoupled from the • Framework Extensibility
design hierarchy, opening up the ability for researchers to explore (1) Modularized, pass-based workflow. Passes may be added
novel configuration strategies (order, storage, and topology) which or modified without affecting the rest of the flow.
is a key component to building efficient FPGAs. Such physical- (2) Core data structure can be serialized to disk. Tools don’t
aware customizability is critical to the design of large-scale, high- need to rerun the entire building process every time.
performance, fabrication-ready FPGAs. In this paper, we evaluate PRGA by characterizing its scalability
In addition to designing the FPGA itself, PRGA offers a complete in terms of memory usage and runtime and find that it enables
HDL-to-bitstream solution using open-source CAD tools, config- the creation of very large designs with reasonable computational
uring and parameterizing those FPGA implementation CAD tools resources. In addition, we take a design through place and route to
for the created custom FPGA. Specifically, this flow uses Yosys [28] tape-in quality to show that PRGA is production-ready. Finally, we
for technology mapping and synthesis, VPR [21] for place & route, compare designs created with PRGA with prior and commercial
FASM [23] for raw bitstream generation, and a custom bitstream designs in terms of area and delay, and show that we are competitive
generator to convert the raw bitstream into binary format. The with other standard-cell-based FPGA generators.
target application can be verified by simulation with various levels PRGA enables many exciting applications. It is a great platform
of abstraction throughout the flow, making it easy to debug both for FPGA architecture research, in particular bridging the gap from
the FPGA itself and the application. Scripts and data files for the high-level FPGA architecture exploration tools down to low-level
same FPGA are reusable across application development runs. implementation details, as well as enabling RTL-in-the-loop FPGA
In summary, the key features of PRGA include: architecture optimization studies. It can also be used to build targets
• Architecture Customizability for FPGA CAD tool research, for example, security-aware place-
(1) Fully-customizable, heterogeneous logic blocks: LUT count, and-route tools. PRGA is a framework that allows the creation and
LUT size, local interconnect, hard adder chains, multi-modal exploration of many different FPGA designs, which makes it more
primitives, logic elements, and more. than an FPGA generator that can only generate a certain type of
(2) Bring-Your-Own-IP: block RAM, hardened multiplier/accu- FPGA. The FPGAs built with PRGA can be used either as standalone
mulator, and even big IP cores like CPUs, memory/network FPGAs or integrated into SoCs. It can even be an excellent platform
controllers, etc. for CPU-FPGA heterogeneous system research.
(3) Fully-customizable routing structure: switch box pattern,
connection box pattern, non-uniform channel, long wires, 2 PRGA WORKFLOW
and global wires. Fig. 1 shows an overview of a typical PRGA workflow. The FPGA
(4) Extensible configuration circuitry: simple scanchain-based design flow is driven by a user-written Python script, while the HDL-
configuration or complex, NoC-based, packetized bitstreams to-bitstream flow integrates open-source CAD tools to generate
valid bitstreams for the created custom FPGA.
Figure 2: FPGA architecture modeled by PRGA. The position, shape and size of the modules do not reflect the physical prop-
erties in an ASIC implementation. Programmable connections are shown as many-to-one connections in routing boxes and
blocks. ○1 are bridging nets discussed in Sec. 3.3.3; ○
2 is an unroutable clock pin directly connected to the global clock tree.

2.1 Database Preparation 2.3 Transformation and Generation Passes

PRGA offers various basic components for building an FPGA, includ- PRGA does all the heavy-lifting work through transformation and
ing look-up tables (LUT) and registers. However, it is common that generation passes. The passes shown in Fig. 1 are the most com-
FPGA designers want to add custom components into the design, monly used ones:
for example, SRAM macros, hard arithmetic units, or even complex Configuration Circuitry Insertion expands the functional, abstract
IP cores such as memory controllers. These components are clas- description of the FPGA by elaborating the configuration circuitry
sified as Logic Primitives in PRGA and elaborated in Sec. 3.3.1. and implementing the configurable connections with programmable
During the database preparation step, users can add custom Logic switches. The configuration circuitry does not need to match the
Primitives by creating proper models for them, whether they are logical design hierarchy. Typically, each type of configuration cir-
hard macros or synthesizable HDL designs. cuitry has its own implementation of this pass.
Synthesis Script Generation discovers all the logical resources
2.2 Architecture Customization available in the FPGA, then generates technology mapping and
After database preparation, the users can build the desired custom synthesis scripts for mapping applications onto the custom FPGA.
FPGA architecture by creating programmable blocks and assem- Place and Route Script Generation generates the XML files needed
bling them in a hierarchical manner, as shown in Fig. 2. In summary, by VPR [21] to place and route for the FPGA. To accurately model
the top level of the hierarchy is a 2-dimensional Array composed of the highly customizable routing resources, PRGA generates the
Tiles, Switch Boxes, and nested Arrays. Each Tile contains one Routing Resource Graph XML in addition to the Architecture Descrip-
Logic Block or multiple IO Blocks, in addition to various num- tion XML. PRGA uses FASM [23] for raw bitstream generation, so
bers of Connection Boxes. Logic Blocks and IO Blocks consist additional annotations are added to the XML files accordingly.
of zero to many Slices and Logic Primitives. Last but not least, RTL Generation generates industry-standard, human-readable,
Slices are composed of nested Slices and Logic Primitives. synthesizable Verilog files for the FPGA. As mentioned in Sec. 1,
Each of these modules will be discussed in detail in Sec. 3. PRGA uses Jinja [25] for text file generation, and the templates can
One key feature of PRGA is the decoupling of the functional be changed without affecting the rest of PRGA.
abstraction of the FPGA, the underlying configuration circuitry, Passes may be bound to specific execution order constraints,
and the physical implementation of the circuits. During architecture depend on other passes, or conflict with each other. For example,
customization, FPGA designers can focus on describing the logical RTL Generation depends on Configuration Circuitry Insertion to
function and connectivity, and leave the implementation details to fill in the physical implementations of the abstract architecture
later steps that are independently customizable. For example, to specifications, while Configuration Circuitry Insertion passes for
create a configurable connection in a Logic Block, users do not different types of configuration circuitry conflict with each other.
need to explicitly specify how the MUX tree should be constructed, Graph analysis algorithms are applied to determine the correct
or the order of the configuration bits for the MUXes. execution order of passes, making it easier to add or modify passes.
The high customizability of PRGA opens up a huge design space In addition to these built-in passes, users are encouraged and well-
for exploration, which is critical to architecture researchers and supported to add their own passes to optimize, analyze and create
experienced FPGA designers with specific needs. On the other hand, custom reports for their custom FPGAs.
to make this highly flexible framework easy to use for new users,
PRGA provides abundant built-in algorithms to ease the generation 2.4 ASIC Implementation
of decent FPGAs from meta parameters. For example, while routing PRGA is designed and optimized with a strong emphasis on en-
boxes are customizable on a per-wire, per-connection basis, various abling gate-/transistor-level prototyping or even fabrication, espe-
default algorithms are provided for populating them, including cially as a target of modern ASIC design flow using commercial
Fc-based Connection Box patterns [4], Universal [6], Wilton [27], EDA tools and standard cell libraries. Common ASIC implementa-
and Cycle-Free [15] Switch Box patterns, etc. tion techniques are taken into consideration during RTL generation.
For example, the configuration enable signal is registered at dif-
ferent levels across the hierarchy to reduce potential skew of this
high-fanout net. In addition, the flexible hierarchy and customizable
RTL generation grant FPGA designers the freedom to explore and
optimize the layout strategy specific to their process and design.
(a) Two modes in Abstract View
2.5 Application Development and Verification
All the files required by the open-source HDL-to-bitstream toolchain
are generated by the generation passes in the FPGA design flow,
and they can be reused across different runs of the application de-
velopment and verification flow. Furthermore, PRGA offers various
executable Python scripts for generating the Verilog testbenches,
constraints, and Makefiles to automate the flow. A valid and verified
bitstream is thus only a few commands away from the HDL inputs.
With the RTL-level model of the FPGA, we can simulate the (b) Design View implemented with the Scanchain
configuration circuitry. Mode selection bit high-
FPGA from power-on reset, bitstream loading, all the way to appli-
lighted with red box and arrow.
cation emulation. This Emulation-over-Simulation approach offers
great fidelity of the architecture, and simplifies debugging both the
Figure 3: Different views of a fracturable LUT3 which can be
FPGA and the application. Moreover, after pushing the RTL through
used as one single LUT3, or two LUT2s with shared inputs.
an ASIC implementation flow, we can run gate-/transistor-level
simulation with more accurate timing and power characteristics.
view is to generate RTL files for ASIC implementation, which are
3 ARCHITECTURE different from those used in simulation.
In this section, we describe PRGA’s highly flexible and customizable
architecture. 3.3 Hierarchy and Customizability
In this section, we dive into how PRGA organizes the hierarchy of
3.1 Routing Resources the FPGA architectures and show the customizability of each level
PRGA currently supports straight, uni-directional routing tracks, in the hierarchy.
global nets, and direct inter-block wires. Routing tracks, also called
3.3.1 Logic Primitive. Also known as logic elements or logic re-
wire segments, are grouped by length in the unit of logical tiles. By
sources, Logic Primitives are the building blocks of FPGAs. In
default, PRGA fills every routing channel in the custom FPGA with
PRGA, all hard logic that is targeted by technology mapping and
all groups of tracks. However, if certain tracks are not driven by any
synthesis are categorized as Logic Primitives, including but not
Switch Box or Connection Box, they are depopulated from the spe-
limited to LUTs, flip-flops, hard arithmetic units, SRAM macros, or
cific routing channel, enabling per-wire, per-channel customization.
even complex IP cores like memory controllers.
We intentionally dropped support for bi-directional routing tracks
Logic Primitives are further classified into three types:
because they are not compatible with common ASIC implementa-
tion flows, and they are no longer used in newer generations of • Non-Programmable primitives, e.g., simple flip-flops.
commercial FPGAs either. Global nets and direct inter-block wires • Programmable primitives, e.g., LUTs. The functions provided
(Tunnels in PRGA’s terminology) are non-programmable routing by these primitives are altered by configuration.
resources. Global nets are typically used for clock or reset trees, • Multi-Modal primitives, e.g., fracturable LUTs. These prim-
while Tunnels are usually used to implement fast carry-chains. itives can be configured to one of its many modes, each
offering a unique function. Multi-modal primitives are not
3.2 Views directly targeted by synthesis. Instead, logical primitives em-
As outlined in Sec. 2.2, PRGA decouples the logical abstraction, ulated by its various modes are targeted by synthesis, then
configuration circuitry, and physical implementation of the FPGA matched with the corresponding mode during packing.
to maximize modularization. This is achieved by using different Ideally, we would like to design primitives in a configuration-
Views, a concept borrowed from the EDA world, at different steps agnostic manner to maximize reusability and extensibility. Unfortu-
throughout the FPGA design flow: nately, this is not always feasible. For example, LUTRAM, one mode
The Abstract View offers a high-level abstraction of the archi- of a LUT which can be used as a RAM, requires the capability of
tecture. It is primarily used during the architecture customization writing to the underlying configuration memory. Addressing this
and CAD script generation steps. issue, PRGA exploits the views as discussed in Sec. 3.2. PRGA uses
The Design View is usually the output of the Configuration the Abstract View to specify the logical function of a primitive,
Circuitry Insertion pass, implementing the Abstract View specified and uses the Design View for the actual implementation. Fig. 3
by users. Synthesizable Verilog can be generated from this view. shows the two Abstract Views and one Design View of a "fracr-
The Physical View offers more flexibility over the Design View turable" LUT3, which can be used as one single LUT3, or two LUT2s
and is primarily reserved for extensions. One typical use of this with shared inputs.
 All three types of primitives are customizable in PRGA. Non- and two Connection Boxes. Multiple Tiles can be created for the
programmable primitives can be easily added by creating new same block, enabling the usage of different Connection Boxes as
Logic Primitive objects with their interfaces and Verilog source mentioned in Sec. 3.3.3. Helper functions are provided for automat-
files. Programmable primitives can be added in a similar way, only ically generating Tiles for each block, as well as properly creating,
that an additional Design View matching the selected configu- populating, and instantiating Connection Boxes.
ration circuitry is required. Multi-modal primitives require more This extra level of hierarchy is primarily aimed to improve ASIC
hands-on development: Each mode of a multi-modal primitive is implementation, and may be useful for certain configuration pro-
similar to a Slice in the Abstract View. A Design View imple- tocols. When used as the lowest-level physical block other than
menting all the different modes and the mode-selection mechanism the Logic Block wrapped in it, it allows the EDA tools to work
specific to the selected configuration circuitry is also required. on a larger design and exploit more optimization opportunities,
while guaranteeing that each Logic Block has only one physical
3.3.2 Slice, Logic Block, and IO Block. Slices (also called ALMs implementation.
or clusters), Logic Blocks, and IO Blocks are modules built upon
Logic Primitives, as shown in Fig. 2 (c). The purpose of these 3.3.5 Array. The top level in the FPGA architecture hierarchy is
modules are three-fold: For the FPGA CAD tools, they serve as the an Array composed of Tiles, Switch Boxes, and nested Arrays.
targets for packing as well as routing terminals for place & route; For Fig. 2 (a) & (b) shows the nesting and internals of Arrays. Each
RTL-level simulation, they serve as hierarchical wrappers around Array is a 2-dimensional mesh. Each tile in the mesh can accom-
Logic Primitives, making the latter easier to monitor and debug; modate up to four Switch Boxes (one on each corner) plus one
For ASIC implementation, they can be designed as the lowest-level Tile or Array. Large Tiles or Arrays may occupy more than one
physical block and reused across the chip, minimizing performance tile. Switch Boxes are not allowed at any routing channel cross-
variation across block instances. points that are covered by these large Tiles or Arrays, and routing
Logic Blocks may be logically wide, tall, or both, spanning tracks around them are truncated if not allowed to run through
across multiple tiles. It is also configurable if routing tracks are or over them. PRGA offers helper functions for automatically, cor-
allowed to run through or over these large blocks. This logical size rectly connecting the wires in an Array. If any built-in routing box
only affects the topology of the routing resources around it, and may population algorithm is used, PRGA can also automatically create,
mismatch the physical size or shape in the ASIC implementation. populate and instantiate proper Switch Boxes.
PRGA offers great regularity and scalability through the use
3.3.3 Connection Box and Switch Box. Routing boxes are catego-
of nested Arrays. Special configuration circuitry features such as
rized into two classes in PRGA: Connection Boxes that connect
partial or dynamic reconfiguration can also take advantage of this
routing tracks to the pins of Logic Blocks and IO Blocks; and
flexible hierarchy. For example, to implement partial dynamic recon-
Switch Boxes that connect routing tracks to other routing tracks.
figuration, we can divide the FPGA into dynamically reconfigurable
By default, each side (north, east, south, and west) of a block
regions, each region being an Array. We can add one configuration
needs a Connection Box, although it is very common to omit some
controller per region and expose a well-defined interface of the
Connection Boxes when there are no routable pins on certain
controller into adjacent regions, enabling dynamic reconfiguration
sides of a block. Fig. 2 (c) shows an example where Connection
from adjacent regions.
Boxes are only needed on the east and west side of the Logic Block.
Creating more Connection Boxes for the same side of a block is also
supported, enabling fine-grained customization around different 3.4 Configuration Circuitry
instances of the same block. For tall and wide blocks, the number Configuration circuitry, including memory cells and peripheral cir-
of Connection Boxes needed on each side is equal to the width or cuits, is one of the biggest commercial secrets in the FPGA industry
height of the block. yet is often neglected in FPGA architecture research, despite it mak-
Switch Boxes are modeled in a highly flexible way. As shown ing up a large proportion of on-chip area (20%-40% reported [12, 14])
in Fig. 2 (a) & (b), each corner (northeast, northwest, southeast, and static energy consumption. Studying and modeling configura-
and southwest) in a tile fits one Switch Box, allowing up to 4 tion circuitry is necessary to fully understand FPGA architecture
Switch Boxes wherever routing channels cross, although it’s not implications. In addition, optimization of configuration circuitry
necessary to fill all corners. No limit is set on the number of distinct enables novel architectures [7, 9, 11, 16].
Switch Boxes used across the FPGA, though in practice, a small Two types of configuration circuitry and comprehensive sup-
set of Switch Boxes are often reused to reduce design complexity. ports for them are included in PRGA at the time of this paper:
Since uni-directional routing tracks cannot have more than one Scanchain and Pktchain, respectively.
driver, a Connection Box may conflict with a Switch Box when
they drive the same routing track. To solve this conflict, PRGA adds 3.4.1 Scanchain. As its name suggests, Scanchain employs a shift
bridging nets to connect Connection Box outputs into Switch register chain across the entire FPGA. The bitstream format is
Boxes and merges them to the switches inside Switch Boxes, as also straightforwardly a literal stream of bits. The chain may be
highlighted in Fig. 2 (b). single-bit wide or multi-bit wide, offering a trade-off between faster
configuration and higher metal usage. Fig. 3b shows the single-bit
3.3.4 Tile. A Tile wraps one Logic Block instance or multiple configuration chain segment inside a fracturable LUT3.
instances of an IO Block, together with the Connection Boxes Though it seems naïve, careful design is still required to avoid
around them. Fig. 2 (c) shows a tile wrapping one Logic Block potential hazards:
 • Configuration reset and enable. Even a small FPGA may
contain thousands of configuration bits, and this number
grows quickly into millions as the size of the FPGA increases.
To synchronize the reset and enable signals for this huge
number of registers, PRGA automatically registers the reset
and enable signals along the hierarchy.
• Chain ordering with physical considerations. Logically,
the registers on the chain can be ordered arbitrarily. Physi-
cally, however, it is better to put the configuration bits close
to the modules they control, and order the chain so that reg-
isters are connected only to adjacent registers. PRGA makes (a) Floorplan of the example FPGA. Top-level Array is composed
good guesses by default, but user-provided hints are also of LOGIC Arrays and IO Tiles. Each LOGIC Array consists of 89
accepted. Logic Blocks (L), 5 BRAMs (M), and 1 physical-only configuration
router (C). Each IO Tile provides 8 GPIOs. Each Logic Block con-
3.4.2 Pktchain. For large FPGAs, Scanchain is not only slow but tains 10 FLE6 (multi-modal LUT6 with hard adders and flipflops).
also energy-hungry, because all the registers on the scan chain Each BRAM provides 32Kbits memory. Routing boxes are omitted
must be enabled during programming. Pktchain addresses this in the figure.
issue by dividing the single Scanchain into segments and adding
high-bandwidth NoC routers between them. This design only adds
a small amount of extra wires, minimizing the impact on metal
resources that are precious for the logical routing resources. The
high bandwidth of the NoC allows fast delivery of the bitstream
segments. Once delivered, each bitstream segment is independently
shifted in the corresponding chain segment. Multiple chain seg-
ments can operate in parallel, thus increasing the programming
speed. This design also greatly reduces unnecessary switching of
the registers, thus reducing the energy consumption.
(b) Configuration network and chain segments
3.4.3 Extensions. Scanchain and Pktchain are both developed
upon the low-level API provided by PRGA, and they are great Figure 4: Floorplan and configuration circuitry of the exam-
proof-of-concept designs showcasing the strong extensibility of the ple FPGA in Sec. 4.
framework. Other configuration circuitry types, for example, the
industry-standard SRAM-based design, can be added in a similar hard adder, and one optional D-flipflop. The figure describing the
way. It is also possible to implement more complex configuration structure of this primitive can be found in [12].
circuitry and protocols, such as the dynamic partial reconfiguration In addition, a third-party 512 × 64𝑏 SRAM macro is added to the
design described in Sec. 3.3.5. build. To give more flexibility to synthesis and packing, we can add
extra muxing logic around the SRAM to support smaller word sizes,
4 CASE STUDY: BUILDING A 14K-LUT6 FPGA for example, 1𝐾 × 32𝑏, 2𝐾 × 16𝑏, 4𝐾 × 8𝑏, etc. This is achieved by
In this section, we illustrate the FPGA design flow by going through creating Abstract Views for each mode, writing custom Verilog
the process of building an example FPGA using PRGA. Fig. 4 shows files, and creating a Design View to link them together, as shown
the abstract, hierarchical floorplan and the configuration circuitry in line 7-40 in Listing 1 (Verilog not shown).
settings. Table 1 summarizes the key parameters of the FPGA. List-
ing 1 shows the Python script for building this example FPGA us- 4.2 Architecture Customization
ing the PRGA Python API. This FPGA provides 14240 multi-modal After adding all the custom Logic Primitives, we can start cus-
LUT6s, 28480 registers, 2.56Mbits memory, 1279 GPIOs, and one IO tomizing the FPGA architecture. First, routing tracks and global nets
dedicated for clock. are added to the FPGA, as shown in line 43-46 in Listing 1. Then,
This example design is very similar to the synthesizable FPGAs we customize each Logic Block and IO Block (line 50-81). As
presented in prior works [12, 24]. PRGA is capable of generating discussed in Sec. 2.2, we only need to describe the functional struc-
very different architectures, and we choose the similar design so tures of these blocks. Pack patterns (line 62) and direct inter-block
that we can evaluate and compare our design with prior works. wires (line 70) are added for the carry chain. After describing the
blocks, we construct Tiles (line 85-94) and Arrays (line 100-116),
4.1 Database Preparation then adopt built-in algorithms to automatically create, populate,
We choose the FLE6 multi-modal primitive used in prior works [12, and instantiate routing boxes.
24] as the basic logic element for this example FPGA. FLE6 supports
two modes: (1) one LUT6 and an optional D-flipflop, (2) two BLEs 4.3 Transformation and Generation Passes
that are independently configurable. Each BLE also supports two After specifying the FPGA architecture, we prepare our Jinja [25]
modes: (1) one LUT5 and an optional D-flipflop, (2) two LUT4s, one text renderer, then set up the transformation and generation passes,
 Listing 1: Python script for building the example FPGA de- Listing 2: (Continued)
scribed in Sec. 4. Some API syntax is abbreviated for clarity. 70 # -- create direct inter-block wires --
This script alone drives the entire FPGA design flow. It also ctx.create_tunnel(name="carrychain", offset=(0, -1),
source=clb.ports["cout"], sink=clb.ports["cin"])
generates all the RTL as well as all the files needed by the
CAD tools. # -- IO block --
75 bdr = ctx.build_io_block(name="iob")
1 from prga import * # ... ports, instances and connections
iob = bdr.commit()
# == database preparation ==
# ctx is an Context object for our workspace # -- BRAM block (tall block) --
ctx = Pktchain.new_context(noc_width=8, chain_width=1) 80 bdr = ctx.build_logic_block(name="bram", width=1, height=2)
6
bdr.instantiate(model=memory, name="i_ram")
# == design and add multi-modal primitive for block RAM == # ... ports, instances and connections
# bdr is a Builder object bram = bdr.commit()
bdr = ctx.build_multimode(name="memory")
bdr.create_clock (name="clk") 85 # == automatically create and populate tiles ==
11 bdr.create_input (name="D", width=64) # -- IO tiles --
bdr.create_output(name="Q", width=64) iotiles = {}
# ... and more ports for edge in ["west", "north", "east", "south"]:
bdr = ctx.build_tile(block=iob, capacity=8, edge=edge)
# -- create abstract views for the modes -- 90 bdr.fill(fc=(0.15, 0.15)).auto_connect()
16 for name, AW, DW in [ iotiles[edge] = bdr.commit()
["512x64b", 9, 64],
["1K32b", 10, 32], # -- CLB tile --
# ... and more modes bdr = ctx.build_tile(block=clb)
]: 95 clbtile = bdr.fill(fc=(0.055, 0.1)).auto_connect().commit()
21 mb = bdr.build_mode(name="mode_"+name)
# abstract view of non-programmable memory modules # -- BRAM tile --
dpram = ctx.build_memory(name="dpram_"+name, bdr = ctx.build_tile(block=bram)
addr_width=AW, data_width=DW, vpr_model="dpram", bramtile = bdr.fill(fc=(0.055, 0.1)).auto_connect().commit()
).commit() 100
26 inst = mb.instantiate(model=dpram, name="i_ram_core") # == arrays ==
mb.connect(mb.ports["clk"], inst.pins["clk"]) sb_pat = SwitchBoxPattern.cycle_free
mb.connect(mb.ports["D"][0:DW], inst.pins["data1"])
mb.connect(inst.pins["out2"], mb.ports["Q"][0:DW]) # -- LOGIC array --
# ... and more connections 105 bdr = ctx.build_array(name="logic", width=10, height=10)
31 mb.commit() for x, y in product(range(bdr.width), range(bdr.height)):
if x == 5:
# -- link design view -- if y % 2 == 0:
# user Verilog implementation provided by user bdr.instantiate(model=bramtile, position=(x, y))
bdr = bdr.build_logical_counterpart( 110 elif not (x == 0 and y == 0): # reserved for router
36 verilog_template="memory.v") bdr.instantiate(model=clbtile, position=(x, y))
# ... design-specific settings logic = bdr.fill(sbox_pattern=sb_pat).auto_connect().commit()
# -- commit the design -- # -- top-level array --
memory = bdr.commit() 115 bdr = ctx.build_array(name="top", width=42, height=42,
41
is_top=True)
# == add routing resources == # ... instantiate LOGIC arrays and IO tiles
glb_clk = ctx.create_global(name="clk", is_clock=True) top = bdr.fill(sbox_pattern=sb_pat).auto_connect().commit()
glb_clk.bind(position=(0, 21), subtile=0) # bind to an IO
l4 = ctx.create_segment(name='L4', width=32, length=4) 120 # == customize configuration circuitry insertion ==
46 l16 = ctx.create_segment(name='L16', width=1, length=16) # callback function for customize router & chain ordering
def order_submodules(module):
# == customize blocks == # ...
# -- logic block --
bdr = ctx.build_logic_block(name="clb") 125 # == apply transformation and generation passes ==
51 clk = bdr.create_global(global_=glb_clk, side="south") # -- Jinja2 template renderer --
in_ = bdr.create_input (name="in", width=30, side="east") renderer = Pktchain.new_renderer()
ci = bdr.create_input (name="ci", width=1, side="south")
out = bdr.create_output(name="out", width=20, side="east") # -- transformation and generation flow --
co = bdr.create_output(name="co", width=1, side="north") 130 flow = Flow(
56 xbar_i, xbar_o = [], [] TranslationPass(), # generate design views
xbar_i.extend(in_) Pktchain.Insert(order_submodules),
for idx, inst in enumerate(bdr.instantiate( VPR_Arch_Gen(output_file="vpr/arch.xml"),
model=ctx.primitives["fle6"], name="i_fle", reps=10): VPR_RRG_Gen(output_file="vpr/rrg.xml"),
bdr.connect(clk, inst.pins["clk"]) 135 Yosys_Scripts_Gen(output_dir="syn"),
61 bdr.connect(inst.pins["out"], out[idx*2:(idx+1)*2]) Verilog_Gen(output_dir="rtl"),
bdr.connect(ci, inst.pins["cin"], # ... and more
vpr_pack_patterns=["carrychain"]) )
ci = inst.pins["cout"]
xbar_i.extend(inst.pins["out"]) 140 # -- fire the workflow --
66 xbar_o.extend(inst.pins["in"]) flow.run(ctx, renderer)
bdr.connect(ci, co)
# ... connect each "xbar_o" to 50% "xbar_i"s # -- save core data structure on disk --
clb = bdr.commit() ctx.pickle("ctx.pkl")
 Param. Value Note
Routing Resources
𝑊 288 Routing Channel Width
1×16
𝑛×𝐿 Track count & length per direction per channel
32×4
𝐹𝑠 3 Switch Box connectivity. Pattern: cycle-free [15]
Logic Block
𝑁 𝐹 𝐿𝐸6 10 #FLE6s per block
𝑋 50% Local connectivity
𝐹𝑐,𝑖𝑛 0.055 Connection Box input connectivity
Figure 5: Layout photos of the custom FPGA
𝐹𝑐,𝑜𝑢𝑡 0.1 Connection Box output connectivity
BRAM Area (𝜇𝑚 2 ) [12] [24] Stratix IV 1 This work
𝑚 32Kbits Memory capacity
LAB/CLB 15333 -2 -2 15254
𝐹𝑐,𝑖𝑛 0.055 Connection Box input connectivity
30625 17648 11050 34209
𝐹𝑐,𝑜𝑢𝑡 0.1 Connection Box output connectivity Tile
(277%) (160%) (100%) (310%)
IO Block 1 Data reported by [12].
𝑐 8 #IOs per block 2 Unreported.
𝐹𝑐,𝑖𝑛 0.15 Connection Box input connectivity Table 2: Area Comparison
𝐹𝑐,𝑜𝑢𝑡 0.15 Connection Box output connectivity
Configuration Circuitry: Pktchain Path Delay (𝑛𝑠) [12] [24] Stratix IV 1 This work
𝐵 8b NoC data width 0.46 0.14 0.27 0.55
LUT-5
𝑊𝑐 1b Leaf scanchain width (170%) (52%) (100%) (204%)
Table 1: Parameters of the example FPGA built in Sec. 4 0.50 0.15 0.28 0.64
LUT-6
(179%) (54%) (100%) (229%)
as shown in line 125-136 in Listing 1. The Flow object then resolves 0.70 0.54 0.77 0.72/0.09 2
1-bit Adder
the dependencies between the passes and determines the correct (90%) (70%) (100%) (94/12%)
execution order. Finally, we start the Flow to apply all the passes 1.63 1.10 1.23 0.98/0.82 2
20-bit Adder
to the core Context data structure, ctx (line 139). (133%) (89%) (100%) (80/67%)
After all the passes finish transforming the core data structure 0.27 0.12 0.17 0.34/0.92 3
Local Routing
or generating files, we save the core data structure onto hard disk (159%) (71%) (100%) (200/541%)
for future use (line 142). 4 2.53 0.40 0.59 2.22
L4 Track
(429%) (68%) (100%) (376%)
4.4 ASIC Implementation 4 4.02 0.78 1.02 2.91
L16 Track
The FPGA design is broken down into 3 levels of hierarchy and 5 (394%) (76%) (100%) (285%)
physical blocks: 1) CLB Tile; 2) BRAM Tile; 3) IO Tile; 4) LOGIC L4 →L4 Switch 5 - - - 1.21
Array composed of CLB Tiles and BRAM Tiles; and 5) Top-level L4 →L16 Switch 5 - - - 1.20
Array composed of LOGIC Arrays and IO Tiles. Note that this L16 →L4 Switch 5 - - - 1.20
partitioning is for this example design only, and can be changed L16 →L16 Switch 5 - - - 1.46
1 Data reported by [12].
freely for other designs. We then lay out the FPGA using standard
2 First number is the delay from addends to carry-out; second is carry-in to carry-out.
cell libraries on a state-of-the-art FinFET technology. 3 First number is the delay from block inputs to FLE6 inputs; second is the delay of the feedback
As discussed in Sec. 3.3.4, Tiles are chosen as the bottom-level connections from FLE6 outputs back to FLE6 inputs.
4 [12] and [24] have different definitions for this metric. We adopt the definition from [12], i.e.
physical block instead of Logic Blocks to improve the Quality
delay from a CLB output pin to a CLB input pin, connected via one straight track.
of Result (QoR). In the LOGIC Array, Tile instances are placed 5 Delay from the driver of the source track to the driver of the destination track.

in almost perfect alignment with their logical positions. We adopt Table 3: Representative Path Delays
the cycle-free Switch Box pattern [15] and flatten the Switch Box
instances in the Arrays. Compared to a black-boxed approach in Once the layout is finished and verified, Static Timing Analysis
which blocks and routing boxes are designed individually then (STA) using automated EDA tools can be applied to extract the tim-
simply stitched together at the top level, this design flow applies ing and power characteristics from the FPGA. This information can
proper constraints at Array level, enabling the EDA tools to resolve be passed back into the generation passes to get timing-annotated
many hazards that are otherwise unidentifiable, for example, hold scripts for the HDL-to-bitstream toolchain.
time violations, clock skew, crosstalk, IR drop, etc.
Different challenges arise when designing the top-level Array 5 EVALUATION
because of its scale. To minimize EDA tool runtime without sacri-
ficing QoR, we reduce the logic left in the top-level Array to the 5.1 ASIC Implementation
minimum. Pins of the LOGIC Arrays are also aligned, reducing In this section, we evaluate the layout of the example FPGA built
wiring congestion. in Sec. 4, and compare the results with previous works [12, 24] and
 from 2K LUT6s up to 512K LUT6s, and compare the memory usage,
Peak Memory (MB)

6 × 102
runtime, and output file sizes.
4 × 102
As shown in Fig. 6, PRGA has a low memory footprint, and ex-
3 × 102
cept for Routing Resource Graph (RRG) generation, PRGA only needs
2 × 102
a short amount of time to generate all the files needed. Memory
usage and runtime both scale linearly as the capacity of the archi-
103 Architecture Customization
Transformation & Generation Passes
tecture increases, but even for the half-million-gate architecture,
102 Pickling
PRGA finishes with less than 1GB memory within 5 minutes.
Runtime (s)

Unpickling
101 The bottleneck is RRG generation. RRG can be read by VPR
100 in addition to the architecture specification XML, overriding the
10−1 default auto-generated routing resource graph in VPR at a per-
Total runtime for RRG_GEN (s)

wire, per-connection basis, thus enabling the high customizability

104
PRGA aims for. However, RRG was initially an internal file format
designed for debugging and not intended to scale. Therefore, it
103
stores the the entire routing graph of an FPGA in human-readable
XML format, which easily grows beyond Gigabytes as the FPGA
102
size grows. This has been noticed by the maintainers of VPR, and
VPR arch.xml updates are being planned.
Total file size (MB)

Generated Verilog
101 Pickled Context

6 ENABLED APPLICATIONS
100
This section outlines some of the compelling applications that
10−1 PRGA enables. PRGA can be used not only as a research platform
but also as a generator of custom FPGA IP cores.
RRG.xml file size (MB)

104

103 6.1 FPGA Architecture Research

102 PRGA enables research into the architectures of FPGAs. The need
101
for a good low-level FPGA framework comes in multiple forms. First,
2 8 32 128 512
#LUTs (K) PRGA can be used as a perfect platform to perform FPGA design
Figure 6: Scalability and performance of PRGA as the plat- optimization. Coupled with an optimization engine (hill-climbing,
form itself. All axes are in log scale. genetic algorithm, simulated annealing, etc.), PRGA is the ideal
platform to automate the optimization of the hardware side of an
FPGA design. The high configurability of PRGA enables automated
Stratix IV (data reported by [12]). Since we are not using 40nm tech-
searching of a huge design space. FPGA optimization becomes
nology, we use the CMOS scaling model [22] to scale our evaluation
even more powerful when optimizing for a set of applications or
results to 40nm.
application domains [13].
5.1.1 Area. Table 2 summarizes the area comparison. For Logic Second, PRGA is complementary to high-level design tools such
Block, our result is almost the same as the previous standard-cell- as VPR. While high-level FPGA design tools enable even faster
based FPGA [12] (within 1% difference). As for Tile area (including architectural design space exploration, they can miss many of the
Connection Boxes and Switch Boxes), our area is 11.7% larger than implementation details which are especially important in advanced
the previous standard-cell-based FPGA [12], 1.94x the area of the device nodes. This leads to a complimentary need for low-level
previous FPGA built with standard cells and custom switches [24], design tools such as PRGA which can be run through commercial
and 3.1x the area of Stratix IV. However, the overall utilization rate EDA tools to gather accurate power, performance, and area results
is much lower than 80% as reported by prior works due to the use that can be used by researchers to evaluate different FPGA designs.
of a FinFET technology, and the area may be optimized further by An important feature of PRGA is that the configuration circuitry,
using a more efficient type of configuration circuitry. configuration topology, and storage strategy are all customizable
and independent of the design hierarchy. This flexibility enables
5.1.2 Performance. The typical path delays inside the Logic Block research into the design of the configuration circuitry, which in-
in this work are slightly worse than the previous standard-cell- herently requires the low-level capabilities that PRGA provides.
based FPGA [12], but the routing track delays are slightly better. PRGA also supports dynamic and partial reconfiguration via its
However, when compared to Stratix IV, or the FPGA built with both SoC interface which opens the door to architectures like DPGA [9]
standard cells and custom switches [24], the example FPGA in this and Tabula [26].
work is almost 2-4x worse.
6.2 FPGA CAD Research
5.2 Scalability PRGA can be used as a target for FPGA CAD tool research. FPGA
In this section, we evaluate the scalability and performance of CAD tools need FPGA platforms to target. PRGA provides copious
PRGA as a software. We scale the architecture described in Sec. 4 different designs and, most importantly, can be characterized to
 Project [17] [14] [12] [24] This work capable of generating synthesizable RTL from an extended XML
Std. Cells ✓ ✓ ✓ ✓ ✓ schema based on the VTR architecture description file format. Most
Custom Cells ✗ ✗ ✗ ✓ ✓ VTR features are supported, including heterogeneous blocks, multi-
Hetero. Blocks 1 ✗ ✗ ✓ ✓ ✓ modal primitives, carrychains, BRAMs, and so on. In addition, user-
Custom Config. ✗ ✗ ✗ ✓2 ✓ defined components and custom cells are also supported. The major
Split SB/CB ✗ ✗ ✗ ✗ ✓ differences between PRGA and OpenFPGA are the followings:
Custom Hier. 3 ✗ ✗ ✗ ✗ ✓ (1) Currently, OpenFPGA can only generate RTL in a fixed hier-
Open-Source ✓ ✗ ✗ ✓ ✓ archy: Top-level array → logic and IO blocks, routing boxes
1 Support for tall/wide blocks. → programmable switches and primitives. PRGA provides
2 Configuration pins may be exposed for manual connection; No bitstream generation more customizability in module hierarchy and RTL genera-
or RTL support. tion, which not only enables more diverse ASIC implemen-
3 Customizable hierarchy of generated RTL.
tation strategies but also improves scalability.
Table 4: Taxonomy of FPGA Prototyping Works
(2) OpenFPGA is developed on top of VTR [18] and tightly inte-
grated with the VTR codebase. PRGA is instead decoupled
provide area, timing, and energy information to feed the FPGA
from VTR and uses VTR only as an open-source FPGA place-
CAD tools.
and-route tool. This decoupling, along with the modularized
Beyond CAD tools for FPGAs, PRGA is also a good candidate
workflow, greatly reduces the bar for PRGA users to cus-
for being a test design for the greater ASIC CAD tool research
tomize and extend the framework, and allows them to focus
area. By providing large and parameterized designs, PRGA can be
on their interested part.
used as a parameterizable benchmark to test chip-design CAD tools.
(3) OpenFPGA currently supports 4 types of configuration cir-
PRGA has already been used as a test case for some emerging open
cuitry: chain-based, frame-based, memory-banked, and flat-
source CAD tools.
tened, in which the last one exposes all configuration bits as
6.3 SoC Integration ports of the RTL modules, enabling custom configuration cir-
cuitry with limited support for bitstream generation. PRGA
PRGA is not only a research platform. It generates FPGA fabrics allows users to directly modify RTL generation, and provides
that can be implemented in chips. One of the most promising use various levels of support for bitstream generation.
cases where free (open-source) or customized FPGAs are desirable
is as an embedded FPGA in a System on Chip (SoC). SoCs are be- 8 CONCLUSION
coming increasingly heterogeneous, and it is difficult to always
In conclusion, PRGA is a great platform for building custom FP-
know what functionality is needed in an SoC before fabrication.
GAs. Whether it be enabling researchers or SoC chip builders, the
Likewise, applications are evolving faster than ASIC design cycles,
open-source nature, easy-to-use design, and high configurability
pushing more designs to reconfigurable hardware. This has created
make it an excellent low-level FPGA framework in a post-Moore’s
a growing need for embedded FPGAs [3]. Unlike commercial em-
Law world. By providing full Verilog RTL of all of the generated
bedded FPGA providers (e.g., Achronix, Flex Logix, QuickLogic)
designs, area and performance can be modeled with ultimate ac-
which require licensing fees, PRGA’s open-source nature provides
curacy. PRGA is scalable and provides reasonable runtimes even
an opportunity to add embedded FPGA functionality without IP
for large designs (an important consideration for commercial use).
licensing cost. This can be especially impactful in two use cases (1)
PRGA provides comparable area and timing delay as other projects
when only a very small amount of FPGA resources are needed or (2)
built out of the same technology (standard-cell-based FPGAs). We
when the embedded FPGA functionality is needed in low-budget
look forward to many years of supporting PRGA and expect it to
or academic designs.
serve as the basis for FPGA research and FPGA designs for years
7 RELATED WORK to come.

In this section, we qualitatively compare PRGA with other FPGA 9 ACKNOWLEDGEMENTS

prototyping works. Table 4 summarizes the key differences between
We want to thank our colleagues from the Princeton Parallel Group,
this work and previous works.
especially Ting-Jung Chang, and Fei Gao, for their help with the
Archipelago [17] is the first open-source project for designing
ASIC backend flow. This material is based on research sponsored
standard-cell-based FPGAs. It is developed in Chisel [2] and coarsely
by the NSF under Grant No. CCF-1453112, Air Force Research Lab-
parameterized, providing limited customizability. It uses an early
oratory (AFRL) and Defense Advanced Research Projects Agency
version of VTR for bitstream generation. Various designs gener-
(DARPA) under agreement No. FA8650-18-2-7852. The U.S. Govern-
ated by Archipelago were placed and routed using a 65nm process
ment is authorized to reproduce and distribute reprints for Govern-
technology. Unfortunately, the project is no longer maintained.
mental purposes notwithstanding any copyright notation thereon.
There are two [12, 14] successful, standard-cell-based FPGAs
The views and conclusions contained herein are those of the au-
built with commercial EDA tools. Based on the VPR/VTR series [18],
thors and should not be interpreted as necessarily representing the
these projects provide independent data points in the design space,
official policies or endorsements, either expressed or implied, of Air
but are not open sourced as publicly available research tools.
Force Research Laboratory (AFRL) and Defense Advanced Research
OpenFPGA [24] is another open-source FPGA prototyping frame-
Projects Agency (DARPA), the NSF, or the U.S. Government.
work that is well-maintained and actively developed. OpenFPGA is
REFERENCES SOC Conference. 279–282.
[1] Amazon. 2020. Amazon EC2 F1 Instances. https://aws.amazon.com/ec2/instance- [14] Jin Hee Kim and Jason H. Anderson. 2015. Synthesizable FPGA Fabrics Targetable
types/f1/ by the Verilog-to-Routing (VTR) CAD Flow. In 25th International Conference on
[2] Jonathan Bachrach, Huy Vo, Brian Richards, Yunsup Lee, Andrew Waterman, Field Programmable Logic and Applications, FPL 2015. https://doi.org/10.1109/
Rimas Avižienis, John Wawrzynek, and Krste Asanović. 2012. Chisel: Construct- FPL.2015.7293955
ing Hardware in a Scala Embedded Language. In Proceedings of the 49th Annual [15] Ang Li, Ting-Jung Chang, and David Wentzlaff. 2020. Automated Design of
Design Automation Conference (DAC ’12). Association for Computing Machinery, FPGAs Facilitated by Cycle-Free Routing. In 2020 30th International Conference
New York, NY, USA, 1216–1225. https://doi.org/10.1145/2228360.2228584 on Field-Programmable Logic and Applications (FPL). 208–213. https://doi.org/10.
[3] Brian Bailey. 2019. The Case For Embedded FPGAs Strengthens And Widens. 1109/FPL50879.2020.00042
https://semiengineering.com/embedded-fpga-becomes-a-viable-option/ [16] Ting-Jung Lin, Wei Zhang, and Niraj K Jha. 2012. FPGA Based on 10T Low-Power
[4] Vaughn Betz. 2000. Architecture and CAD for Speed and Area Optimization of SRAMs. 20, 11 (2012), 2151–2156.
FPGAs. Ph.D. Dissertation. University of Toronto. [17] Hao Jun Liu. 2014. Archipelago - An Open Source FPGA with Toolflow Support.
[5] Adrian M. Caulfield, Eric S. Chung, Andrew Putnam, Hari Angepat, Jeremy Master’s thesis. University of Toronto.
Fowers, Michael Haselman, Stephen Heil, Matt Humphrey, Puneet Kaur, Joo- [18] Jason Luu, Jeffrey Goeders, Michael Wainberg, Andrew Somerville, Thien Yu,
Young Kim, Daniel Lo, Todd Massengill, Kalin Ovtcharov, Michael Papamichael, Konstantin Nasartschuk, Miad Nasr, Sen Wang, Tim Liu, Nooruddin Ahmed,
Lisa Woods, Sitaram Lanka, Derek Chiou, and Doug Burger. 2016. A Cloud-Scale Kenneth B. Kent, Jason Anderson, Jonathan Rose, and Vaughn Betz. 2014. VTR
Acceleration Architecture. In The 49th Annual IEEE/ACM International Symposium 7.0: Next Generation Architecture and CAD System for FPGAs. ACM Trans.
on Microarchitecture (MICRO-49). IEEE Press, Article 7, 13 pages. Reconfigurable Technol. Syst. 7, 2, Article 6 (July 2014), 30 pages. https://doi.org/
[6] Yao-Wen Chang, D. F. Wong, and C. K. Wong. 1996. Universal Switch Modules 10.1145/2617593
for FPGA Design. ACM Trans. Des. Autom. Electron. Syst. 1, 1 (Jan. 1996), 80–101. [19] Gordon E. Moore. 1965. Cramming More Components Onto Integrated Circuits.
https://doi.org/10.1145/225871.225886 Electronics (April 1965).
[7] Paul Chow, Soon Ong Seo, Jonathan Rose, Kevin Chung, and P Gerard. 1999. The [20] Duncan J. M. Moss, Eriko Nurvitadhi, Jaewoong Sim, Asit Mishra, Debbie Marr,
Design of an SRAM-Based Field-Programmable Gate Array — Part I : Architecture. Suchit Subhaschandra, and Philip H. W. Leong. 2017. High Performance Binary
7, 2 (1999), 191–197. Neural Networks on The Xeon+FPGA™ Platform. In 2017 27th International
[8] Eric S. Chung, Peter A. Milder, James C. Hoe, and Ken Mai. 2010. Single-chip Conference on Field Programmable Logic and Applications (FPL). 1–4.
Heterogeneous Computing: Does the Future Include Custom Logic, FPGAs, and [21] Kevin E. Murray, Oleg Petelin, Sheng Zhong, Jia Min Wang, Mohamed Eldafrawy,
GPGPUs? Proceedings of the Annual International Symposium on Microarchitecture, Jean-Philippe Legault, Eugene Sha, Aaron G. Graham, Jean Wu, Matthew J. P.
MICRO (2010), 225–236. https://doi.org/10.1109/MICRO.2010.36 Walker, Hanqing Zeng, Panagiotis Patros, Jason Luu, Kenneth B. Kent, and
[9] André DeHon. 1996. DPGA Utilization and Application. In Proceedings of the Vaughn Betz. 2020. VTR 8: High-Performance CAD and Customizable FPGA
1996 ACM Fourth International Symposium on Field-Programmable Gate Arrays Architecture Modelling. ACM Trans. Reconfigurable Technol. Syst. 13, 2, Article 9
(FPGA ’96). Association for Computing Machinery, New York, NY, USA, 115–121. (May 2020), 55 pages. https://doi.org/10.1145/3388617
[22] Aaron Stillmaker and Bevan Baas. 2017. Scaling Equations for the Accurate
https://doi.org/10.1145/228370.228387
Prediction of CMOS Device Performance from 180nm to 7nm. Integration, the
[10] Brian Gaide, Dinesh Gaitonde, Chirag Ravishankar, and Trevor Bauer. 2019. Xilinx
VLSI Journal 58, January (2017), 74–81. https://doi.org/10.1016/j.vlsi.2017.02.002
Adaptive Compute Acceleration Platform: Versal™ Architecture. In Proceedings
[23] SymbiFlow. 2020. FPGA ASM (FASM). https://fasm.readthedocs.io/en/latest/
of the 2019 ACM/SIGDA International Symposium on Field-Programmable Gate
[24] Xifan Tang, Edouard Giacomin, Aurélien Alacchi, Baudouin Chauviere, and
Arrays (FPGA ’19). Association for Computing Machinery, New York, NY, USA,
Pierre-Emmanuel Gaillardon. 2019. OpenFPGA: An Opensource Framework
84–93. https://doi.org/10.1145/3289602.3293906
Enabling Rapid Prototyping of Customizable FPGAs. In 2019 29th International
[11] Mingyu Gao, Christina Delimitrou, Dimin Niu, Krishna T. Malladi, Hongzhong
Conference on Field Programmable Logic and Applications (FPL). 367–374. https:
Zheng, Bob Brennan, and Christos Kozyrakis. 2016. DRAF: A Low-Power DRAM-
//doi.org/10.1109/FPL.2019.00065
Based Reconfigurable Acceleration Fabric. SIGARCH Comput. Archit. News 44, 3,
[25] The Pallets Projects. 2020. Jinja. https://palletsprojects.com/p/jinja/
506–518. https://doi.org/10.1145/3007787.3001191
[26] Tom R. Halfhill. 2010. Tabula’s Time Machine. Microprocessor Report.
[12] Brett Grady and Jason H. Anderson. 2018. Synthesizable Heterogeneous FPGA
[27] Steven J.E. Wilton. 1997. Architectures and Algorithms for Field-Programmable
Fabrics. In 2018 International Conference on Field-Programmable Technology (FPT).
Gate Arrays with Embedded Memory. Ph.D. Dissertation. University of Toronto.
222–229.
[28] Clifford Wolf. 2020. Yosys Open SYnthesis Suite. http://www.clifford.at/yosys/.
[13] Mark Hammerquist and Roman Lysecky. 2008. Design Space Exploration for
[29] Xilinx. 2020. Zynq-7000 SoC. https://www.xilinx.com/products/silicon-devices/
Application Specific FPGAs in System-on-Chip Designs. In 2008 IEEE International
soc/zynq-7000.html