Sponsored by; contest hosted at the FPGA24 conference.
Hosted on GitHub Pages using the Dinky theme
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:
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.
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.
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.
Get started here!