Source-linked AI summary
Yosys+nextpnr: an Open Source Framework from Verilog to Bitstream for Commercial FPGAs
David Shah, Eddie Hung, Clifford Wolf, Serge Bazanski, Dan Gisselquist, Miodrag Milanović
TL;DR
Closed vendor CAD tools limit access to FPGA silicon, while theoretical architectures do not natively represent commercial devices. Yosys+nextpnr provides an open framework targeting commercial FPGAs, and its ECP5 database deduplication reduces the largest device database from 1GB to 38MB. The authors envision it complementing rather than replacing certified vendor flows.
Problem
Closed vendor CAD tools constrain access to FPGA silicon, and VTR's theoretical architectures lack native public support for commercial devices.
Source: §I · p. 1Method
Yosys+nextpnr combines Verilog synthesis with timing-driven placement and routing for commercial FPGAs, using architecture-specific interfaces and database deduplication.
Source: §I · p. 1, §IV · pp. 2–3Results
The largest supported ECP5 device database shrinks from 1GB uncompressed to 38MB after deduplication.
Source: §IV · p. 3Takeaways & Limitations
The framework targets two Lattice FPGA families, with the stated aim of helping researchers evaluate real-silicon devices and lowering the barrier to deploying CAD innovations.
Source: §VI · p. 4The authors do not expect the framework to compete with certified vendor flows for production, mission-critical designs, envisioning it instead for experimental or incremental tasks and custom-computing applications.
Source: §VI · p. 4
Abstract
from arXiv · showhide
This paper introduces a fully free and open source software (FOSS) architecture-neutral FPGA framework comprising of Yosys for Verilog synthesis, and nextpnr for placement, routing, and bitstream generation. Currently, this flow supports two commercially available FPGA families, Lattice iCE40 (up to 8K logic elements) and Lattice ECP5 (up to 85K elements) and has been hardware-proven for custom-computing machines including a low-power neural-network accelerator and an OpenRISC system-on-chip capable of booting Linux. Both Yosys and nextpnr have been engineered in a highly flexible manner to support many of the features present in modern FPGAs by separating architecture-specific details from the common mapping algorithms. This framework is demonstrated on a longest-path case study to find an atypical single source-sink path occupying up to 45% of all on-chip wiring.
I. INTRODUCTION
FPGA use in industry and academia is growing, but closed vendor CAD tools limit access to silicon and make it difficult to realize academic innovations on commercial devices. Yosys+nextpnr targets commercial FPGAs directly, including their real-world imperfections.
I. INTRODUCTION
- FPGA technology is extensively studied in academia and gaining industry traction, including large-scale cloud-datacenter deployments.The introduction likens FPGA reconfiguration to an Etch-A-Sketch, while noting that the technology remains difficult to master.Source: §I · p. 1
- Closed vendor CAD tools are the sole entry point to FPGA silicon, limiting the realization of academic innovations on real devices.The framework is presented as a first step toward experimenting with custom-computing machinery outside that walled garden.Source: §I · p. 1
- VTR supports research on theoretical architectures, but lacks native public support for commercial devices; extending it to real architectures can be difficult and theoretical conclusions can mislead.VTR supports architecture questions such as LUT input counts and CAD-algorithm research.Source: §I · p. 1
- Yosys+nextpnr targets commercial-off-the-shelf FPGAs and accounts for their imperfections and real-world considerations.The paper positions the framework relative to VTR and vendor tools in Figure 1.Source: §I · p. 1
II. RELATED WORK
Prior work offers open-source synthesis, placement and routing, or support for real commercial devices, with different capabilities and constraints. The paper compares these approaches with Yosys+nextpnr.
II. RELATED WORK
- Odin II supports synthesizable Verilog and hard IP for VTR architectures, while Yosys also outputs EDIF and Verilog and supports flexible coarse-grained technology mapping.Odin II primarily produces BLIF netlists used in research; Yosys supports BLIF as well as those additional formats.Source: §II · p. 1
- VPR targets procedurally generated architectures, enabling architecture-limit and routing-algorithm studies that fixed commercial devices cannot support.Examples include finding the smallest FPGA a benchmark can fit on and the minimum routing channel width needed.Source: §II · p. 2
- VTR-to-Bitstream supports a Xilinx Virtex-6 using device data, while RapidSmith offers a sandbox for multiple Xilinx families and RapidWright provides an escape hatch into Vivado.Figure 1 compares nextpnr with VPR and vendor FPGA tools.Source: Figure 1 · p. 1, §II · p. 2
III. YOSYS – VERILOG SYNTHESIS
Yosys synthesizes Verilog through generic optimization and architecture-specific mapping, while nextpnr separates shared placement and routing algorithms from device-specific implementation details. The framework also supports custom flows and reduces ECP5 database size through deduplication.
III. YOSYS – VERILOG SYNTHESIS
- Yosys supports synthesis and verification for Verilog-2005, targets FPGAs and ASICs, and uses ABC alongside custom optimizations and memory and arithmetic mapping passes.Source: §III · p. 2
- A typical Yosys flow optimizes elaborated logic, infers generic hard-logic cells, then maps remaining cells through gates and ABC LUTs to target-device primitives.Source: §III · p. 2
- An 8-input LUT can map to two LUT7s, then four LUT6s and three muxes for Xilinx 7-series; recursive mapping reduces effort when targeting new architectures.Figure 2 illustrates recursive decomposition of 7- and 8-input LUTs into 6-input LUTs with muxes.Source: §III · p. 2, Figure 2 · p. 2
- nextpnr implements architectures through an API that can supply custom packing, device-database checks, timing models, routing passes, and bitstream generation.Source-compatible architecture implementations are built as separate executables, avoiding virtual-function overhead in frequently called code.Source: §IV · pp. 2–3
- nextpnr uses JSON netlists, architecture-specific packing, simulated-annealing or analytic placement, and timing-driven iterative rip-up-and-reroute A* routing.The JSON format supports cell names, inout ports, attributes, and parameters unavailable in BLIF.Source: §IV · p. 3
- The iCE40 and ECP5 flows use Project Icestorm and Project Trellis data for device resources, timing, and bitstreams, and support hard IP including PLLs, DSPs, and transceivers.Source: §IV · p. 3
- For ECP5 devices up to 85K logic elements, 4M wires, and 28M routing switches, deduplication shrinks the largest device’s uncompressed database from 1GB to 38MB.This one-off compile-time process exploits FPGA symmetry and redundancy to reduce database disk and memory use, improving cache efficiency and runtime.Source: §IV · p. 3
- Python scripts can replace nextpnr’s flow or run around individual stages for constraints, floorplanning, custom placement or routing, and design analysis.The Python API and GUI are optional, allowing operation on embedded platforms such as FPGA-SoCs.Source: §IV · p. 4
V. EXAMPLE APPLICATION: LONGEST PATH ROUTING
The case study modifies nextpnr to seek a longest simple route on a commercial FPGA, demonstrating an atypical routing objective with physical delay measurements and reachable-wire coverage.
V. EXAMPLE APPLICATION: LONGEST PATH ROUTING
- Because longest paths in directed cyclic graphs are NP-hard, the case study uses a heuristic to seek a path as long as possible.The authors note that constructing such paths may be useful for online testing.Source: §V · p. 4
- The experiment routes a single-input, single-output design on an iCE40 UltraPlus UP5K with 125K wires and 1.3M programmable routing switches.A modified nextpnr replaced its shortest-path router with a longest-simple-path heuristic using successive relaxation; the modifications added 87 lines of code.Source: §V · p. 4
- Table I compares delay and reachable-wire usage for the shortest-path algorithm and longest-path heuristic, with delay measured using a 100 MS/s logic analyser.The reachable-wire fraction is an upper bound on wires any path can use, not a guarantee that a Hamiltonian path exists.Source: §V · p. 4, Table I · p. 4
VI. CONCLUSION
Yosys+nextpnr targets commercial FPGA devices and currently supports two Lattice families. The authors envision it complementing, rather than competing with, certified vendor flows.
VI. CONCLUSION
- Yosys+nextpnr implements Verilog designs on commercial FPGAs and currently supports two Lattice families.The framework is available under a permissive open-source license.Source: §VI · p. 4
- The framework is intended to let researchers evaluate innovations on real-silicon devices and lower industry barriers to deploying CAD innovations.The stated industry aims also include accelerating time-to-market and reducing risk when supporting novel FPGA architectures.Source: §VI · p. 4
- The authors expect vendor flows to remain for production and mission-critical designs, with Yosys+nextpnr serving experimental, incremental, or unorthodox custom-computing work.They do not expect the framework to be competitive with existing commercial flows.Source: §VI · p. 4