You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the more fragile but critical pieces of logic in the FPGA interchange nextpnr arch is the site routing logic. For clarity, this is the collection of code that implements the isBelLocationValid part of the nextpnr Arch API. This implementation must both be fast (amortized over the entire placement step) and precise and accurate. That is a mixture that means that it should be well tested, so that as complexity increases or speed improvements are done, there is a way to verify that it is still correct.
The suggested site routing test framework would consists of 3 parts:
A way to define a logical netlist that is very specific. This part could be as simple as a verilog file that requires no elaboration or synthesis.
A way to specify test cases. Each test case would consist of:
A batch of cell placement directives (e.g. place this cell at this BEL)
A set of BELs and whether they are valid
A way to evaluate test cases and gather performance data (both memory and wallclock times).
test_case:
- place:
# Place cell `lut_2` at BEL `SLICE_X1Y8.SLICEL/A6LUT`
lut_2: SLICE_X1Y8.SLICEL/A6LUT
- test:
# Make sure this placement is accept
SLICE_X1Y8.SLICEL/A6LUT: true
- place:
lut_1: SLICE_X1Y8.SLICEL/B6LUT
- test:
# Make sure this placement is accept
SLICE_X1Y8.SLICEL/A6LUT: true
SLICE_X1Y8.SLICEL/B6LUT: true
- place:
lut_1: SLICE_X1Y8.SLICEL/A6LUT
lut_2: SLICE_X1Y8.SLICEL/A5LUT
- test:
# The site is now invalid because too many signals into the A6/A5LUT
SLICE_X1Y8.SLICEL/A6LUT: false
SLICE_X1Y8.SLICEL/A5LUT: false
- unplace:
- lut_2
- test:
# By removing lut_2, the site is valid again
SLICE_X1Y8.SLICEL/A6LUT: true
SLICE_X1Y8.SLICEL/A5LUT: true
@litghost I believe that the create_logical_netlist_from_verilog.py scripts already exists, so the main part to implement here is the test script part in nextpnr, right?
This probably makes most sense in a script that is run --pre-place or --pre-route (in the latter case, first ripping up the existing placement), with --no-route also passed to nextpnr.
One of the more fragile but critical pieces of logic in the FPGA interchange nextpnr arch is the site routing logic. For clarity, this is the collection of code that implements the isBelLocationValid part of the nextpnr Arch API. This implementation must both be fast (amortized over the entire placement step) and precise and accurate. That is a mixture that means that it should be well tested, so that as complexity increases or speed improvements are done, there is a way to verify that it is still correct.
The suggested site routing test framework would consists of 3 parts:
Example:
Netlist:
Test case:
Invocation might look like:
Alternate designs are welcome and accepted.
The text was updated successfully, but these errors were encountered: