Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need site routing test framework #234

Open
litghost opened this issue Feb 25, 2021 · 3 comments
Open

Need site routing test framework #234

litghost opened this issue Feb 25, 2021 · 3 comments
Assignees
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@litghost
Copy link

litghost commented Feb 25, 2021

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:

  1. 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.
  2. 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
  1. A way to evaluate test cases and gather performance data (both memory and wallclock times).

Example:

Netlist:

module testcase(input [5:0] lut_1_in, input [4:0] lut_2_in, output lut_1_out, output lut_2_out);

LUT6 lut_1 #(.INIT(64'hFFFFFFFFFFFFFFFF)) (
 .I0(lut_1_in[0]),
 .I1(lut_1_in[1]),
 .I2(lut_1_in[2]),
 .I3(lut_1_in[3]),
 .I4(lut_1_in[4]),
 .I5(lut_1_in[5]),
 .O(lut_1_out)
);


LUT5 lut_2 #(.INIT(32'h0)) (
 .I0(lut_2_in[0]),
 .I1(lut_2_in[1]),
 .I2(lut_2_in[2]),
 .I3(lut_2_in[3]),
 .I4(lut_2_in[4]),
 .O(lut_2_out)
);

endmodule

Test case:

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

Invocation might look like:

python3 create_logical_netlist_from_verilog.py circuit.v circuit.netlist
nextpnr-fpga_interchange --chipdb xxx.bin --netlist circuit.netlist --run run_placement_test.py

Alternate designs are welcome and accepted.

@issuelabeler issuelabeler bot added the invalid This doesn't seem right label Feb 25, 2021
@litghost litghost added this to To Do in FPGA interchange bootstrapping via automation Feb 25, 2021
@litghost litghost added enhancement New feature or request and removed invalid This doesn't seem right labels Feb 25, 2021
@issuelabeler issuelabeler bot added the invalid This doesn't seem right label Feb 25, 2021
@litghost litghost removed the invalid This doesn't seem right label Feb 25, 2021
@litghost litghost added the good first issue Good for newcomers label Mar 30, 2021
@tmichalak tmichalak moved this from To Do to In progress in FPGA interchange bootstrapping Apr 1, 2021
@tmichalak tmichalak self-assigned this Apr 1, 2021
@tmichalak
Copy link

tmichalak commented Apr 1, 2021

@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?

@litghost
Copy link
Author

litghost commented Apr 1, 2021

so the main part to implement here is the test script part in nextpnr, right

Yes

@gatecat
Copy link

gatecat commented Apr 15, 2021

See YosysHQ#681

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.

The relevant Python functions will be:

  • ctx.remove_site_routing()
  • ctx.bindBel('<bel name>', ctx.cells['<cell name>'], STRENGTH_WEAK)
  • ctx.isBelLocationValid('<bel name>')
  • ctx.unbindBel('<bel name>')

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Development

No branches or pull requests

3 participants