834.vpr_s
FPGA Place and Route
VPR was started by Vaughn Betz <vaughn[at]eecg [dot] utoronto [dot] ca> and has had many contributors.
834.vpr_s was modified for the SPEC CPU v8 Benchmark Search Program by Amin Mohaghegh <amin1377 [dot] mohaghegh[at]gmail [dot] com>.
VPR (Versatile Place and Route) is an open source academic CAD tool designed for the exploration of new FPGA architectures and CAD algorithms, at the packing, placement, and routing phases of the CAD flow. Since its public introduction in 1997, VPR has been used extensively in many academic projects partly because it is robust, well documented, easy-to-use, and can flexibly target a range of architectures.
VPR takes, as input, a description of an FPGA architecture along with a technology-mapped user circuit. It then performs packing, placement, and routing to map the circuit onto the FPGA, and also reports a final analysis of the work. The output of VPR includes the FPGA configuration needed to implement the circuit and statistics about the final mapped design (eg. critical path delay, area, etc). Here are more details about these steps:
Packing: The packing algorithm tries to combine primitive netlist blocks (e.g. LUTs, FFs) into groups, called Complex Blocks (as specified in the FPGA architecture file). The results from the packing process are written into a .net file. It contains a description of complex blocks with their inputs, outputs, used clocks and relations to other signals. It can be useful in analyzing how VPR packs primitives together.
Placement: This assigns a location to the Complex Blocks (produced by packing) with the FPGA grid, while optimizing for wirelength and timing. The output from this step is written to the .place file, which contains the physical location of the blocks from the .net file.
Routing: This step determines how to connect the placed Complex Blocks together, according to the netlist connectivity and the routing resources of the FPGA chip. The router uses a Routing Resource (RR) Graph to represent the FPGA available routing resources.The output of routing is written into a .route file. The file describes each connection from input to its output through different routing resources of the FPGA.
Analysis: This step analyzes the resulting implementation, producing information about resource usage (block types, wiring), timing (critical path delays and timing paths), and power (total power used broken down by blocks).
The VPR flow is a linear pipeline of the four stages listed above. The output generated from each step is used as the input for the next step. In addition, VPR provides the ability to read the output generated from a step from an external file, instead of re-executing it. For instance, the tool can read the output file generated from the packer stage (.net file) and directly use it as the input for the placement stage, without re-executing the packer.
The SPEC CPU benchmark relies on this ability to break apart the pipeline stages. The Packing step of the algorithm tends to be sensitive to system parameters and the output may vary by ISA or compiler optimization, since there are multiple "correct" answers. As a result, the benchmark skips running the Packing step, and instead starts with a pre-packed netlist. It starts directly with Placement, followed by Routing/Analysis. The benchmark is also given a known good output from Placement to feed into Routing/Analysis, to ensure there is no dependency between the individual workloads.
Every command line needs these three files to start the flow:
Since we have performed Packing already, the Placement command lines require this input:
And since we want a totally deterministic Routing flow, we have a well-known output of Placement for use in the Routing command lines:
The final file is the output from Routing/Analysis:
Here are the other options used in the command lines for the workloads:
| parameter | description |
| --place_algorithm | Controls which placement algorithm is used |
| --RL_agent_placement | Controls reinforcement learning, which is turned off for SPEC CPU to ensure deterministic execution |
| --init_t | Initial temperature for manual annealing schedule |
| --exit_t | Temperature at which annealing terminates for manual annealing schedule |
| --alpha_t | Temperature scaling factor for manual annealing schedule |
| --max_criticality | Sets the maximum fraction of routing cost derived from delay (vs routability) for any net |
| --router_initial_timing | Controls how criticality is determined at the start of the first routing iteration. |
| --routing_failure_predictor | Controls how aggressively the router will predict a routing as unsuccessful |
| --route_chan_width | Specifies a fixed channel width to route at |
| --max_router_iterations | Maximum number of Pathfinder-based routing iterations before the circuit is declared unroutable at a given channel width |
| --router_lookahead | Controls what lookahead the router uses to calculate cost of completing a connection. |
| --initial_pres_fac | Sets the present overuse factor for the second routing iteration |
| --pres_fac_mult | Sets the growth factor by which the present overuse penalty factor is multiplied after each routing iteration |
| --router_profiler_astar_fac | Controls the directedness of the timing-driven router's exploration when doing router delay profiling |
| --seed | Placement random number generator seed |
| --sdc_file | Path to timing constraints file in SDC format |
| --pack_verbosity | Controls how verbose clustering's output is; higher values produce more output |
| --netlist_verbosity | Controls how much detail netlist processing produces about detected netlist |
| --inner_num | Used in Placement. Controls the number of moves per temperature: inner_num * num_blocks ^ (4/3) |
| --place | Run the placement phase |
| --route | Run the routing phase |
| --analysis | Run analysis. This is always run after routing for a legally routed circuit. |
Increasing verbosity may be useful in debugging verification errors. The two verbosity knobs listed above are set to to 0 in a normal benchmark run, to limit the output and suppress unnecessary I/O. Upstream VPR sets verbosity to 2, so that is a good number to start with in order to show more information in the place.log and route.log files.
The input files come from the Titan Benchmarks, a set of large modern FPGA benchmark files. These are representative of large-scale FPGA architecture and CAD research, and widely used today as vehicles for new algorithm development. Although the files were chosen to fit within the run rules for refrate and refspeed sizes, there are also others in the Titan set which run longer and have a much larger memory footprint. A savvy user could craft their own inputs to VPR by downloading the Titan Benchmark inputs, and change the command lines to point to those circuits. Additionally, SPEC has added two additional circuit workloads for both place and route, so there are a total of four extra command lines for research purposes (in data/all/extra).
[circuit_name].blif.log: The VPR log file contains all the messages printed during the execution of VPR, displaying statistics at each stage of packing, placement, routing, and analysis. We use this file to obtain the necessary information for comparing VPR's output to the expected outputs.
Verification occurs through scraping the log file for key metrics that check the amount of work accomplished by the run and the quality of the circuit. A new tool was built (on your SPEC CPU 2026 distribution media as $SPEC/benchspec/CPU/834.vpr_s/src/compare/vpr_out_compare.cpp) which reads in the .place and .route files, and prints out the following key metrics:
We can then use the output of the comparison tool for verification purposes. All the steps have zero tolerance and the metric outputs should match exactly.
VPR is also now integrated as a key component of the VTR CAD flow, which collectively comprises approximately 1 million lines of code and performs all the CAD flow phases needed to transform Verilog HDL hardware descriptions into a programming file for a broad range of research and commercial FPGAs.
C++, C
Both the SPECrate and SPECspeed variants of the benchmark are single-threaded.
If you see run errors that include a message like one of these...
...that means you have built your executable with improper compilation flags. VPR relies on correct floating-point math, and in particular the way it handles NaN. You can enable correct math evaluations using -fno-finite-math-only, or the more conservative -fno-fast-math flag for the GNU compiler. For other compilers please find the appropriate equivalents for using correct IEEE math.
The VPR software is available in the verilog-to-routing github repository: github.com/verilog-to-routing/vtr-verilog-to-routing/tree/master/vpr.
The SPEC CPU benchmark started with commit hash 1cd6b9d8 from that repository on April 7, 2023, with added changes for portability and algorithmic stability, which were upstreamed to the community.
VPR source is distributed under the MIT License. VPR sources also come with the following libraries with their own licenses:
A few files in libblifparse and libsdcparse are distributed under MIT despite being marked as GPL because they contain the Bison exception: "As a special exception, you may create a larger work that contains part or all of the Bison parser skeleton and distribute that work under terms of your choice..."
SPEC added a version of the Mersenne-Twister PRNG that is licensed by its authors (Makoto Matsumoto, Takuji Nishimura, and Mutsuo Saito) under a BSD license.
Data inputs: the Stratix IV FPGA architecture file and the Titan blif and sdc files are all distributed under the MIT License. 834.vpr_s does not make use of any verilog or other HDL files besides the Arch, blif, and sdc.
Copyright © 2026 Standard Performance Evaluation Corporation (SPEC®)