Runtime-First FPGA Interchange Routing Contest

Sponsored by; contest hosted at the FPGA24 conference.

Hosted on GitHub Pages using the Dinky theme

Contest Details

Key Details

Framework

As stated in the Introduction, the input to the router will be a pre-placed but partially routed FPGAIF design. Specifically, to lower the barrier to entry, only signal nets are required to be routed -- all global (e.g. clock) and static (VCC/GND) nets are pre-routed and must be fully preserved (i.e. cannot be ripped up and rerouted). Furthermore, the existing placement (including all intra-site routing) must also be fully preserved. Violation of these requirements result in being ranked last on such benchmarks. A more detailed look at the contest flow is shown below:

image

Pre-routing

Starting from benchmarks described in RTL, Vivado is used to synthesize, place, and route each design. RapidWright then takes that fully-routed Vivado result, unroutes all signal nets (preserving only global, VCC and GND nets) and writes this result out into FPGA Interchange Format Logical and Physical Netlists. These steps are not mandatory for contestants to run -- a number of FPGAIF benchmarks are provided (with more to follow).

Should contestants wish to test/train with more benchmarks than those that are provided, the DcpToFPGAIF utility is provided.

Router

With just the pre-placed but partially-routed input Physical Netlist, competitors are required to route all signal nets while preserving all existing placement and routing. In practice this is achieved by only inserting FPGAIF routeSegment objects of the type pip into the netlist. This fully-routed result must then be written out as a new Physical Netlist.

Post-routing

Once this fully-routed Physical Netlist is ready, RapidWright takes it again and combines it with the previous Logical Netlist in order to reconstitute a Vivado Design Checkpoint. Here, Vivado’s report_route_status command is used to verify that the design is indeed fully-routed -- that no nodes have multiple drivers (overlaps), and that all there is complete connectivity from all source pins to all sink pins. Returning the design into Vivado allows us to take advantage of its robust legality checking capabilities, as well as demonstrating that the FPGAIF is able to capture all the design state required to interface with an industrial tool. In addition, for the cases where a contestant’s router does not behave as expected, one can also leverage the GUI and other capabilities of Vivado to aid debugging.

The output Physical Netlist will also be analyzed to compute its critical-path wirelength, which will make up a small weight of the score. This metric serves as a simple-to-compute proxy for critical-path delay thus incentivizing contestants to not give up on quality-of-results entirely. The details of how Critical-Path Wirelength will be computed are presented on the Scoring Criteria webpage. Additionally a tool to compute this Critical-Path Wirelength, called wa.py is supplied in the GitHub repository.

Finally, all scoring components – legality of routing solution, wall-clock router runtime, and critical-path wirelength will be combined to produce a per-benchmark score. These scores will be used to rank each team and averaged to determine the overall winners of the contest. The exact scoring formula and ranking algorithm is described in detail on the Scoring Criteria webpage.

Getting Started

Get started here!