Need to create integrated FPGA interchange CI

[litghost]

Currently there are CI's for the individual components of the FPGA interchange (P&R: nextpnr, tooling: python-fpga-interchange, schema: fpga-interchange-schema), but there needs to be a CI that tests the integrated flow.

What the CI should do:

• Compile nextpnr-fpga_interchange
• Generate target device databases:
  • Initial targets should be:
    • A50T parts (e.g. basys3, arty) via RapidWright
    • A100T parts (e.g. arty100) via RapidWright
    • A200T parts (e.g. Nexys) via RapidWright
    • 7-series Zynq (e.g. Zybo) via RapidWright
• Use python-fpga-interchange to patch device databases (see https://github.com/SymbiFlow/python-fpga-interchange/blob/master/Makefile.rapidwright)
• Generate BBA and run archcheck
  • See https://github.com/litghost/nextpnr/blob/1ad83228e299fe446219bf59c60a5d50f48aac68/fpga_interchange/examples/create_bba/Makefile#L69-L82
  • See https://github.com/YosysHQ/nextpnr/blob/de107da5b3c66d329de0a0430a67ca843e27f3bd/fpga_interchange/examples/archcheck/Makefile#L8-L11
• Run nextpnr/check_arch_api.py to verify some specific paths
  • See https://github.com/YosysHQ/nextpnr/blob/de107da5b3c66d329de0a0430a67ca843e27f3bd/fpga_interchange/examples/archcheck/Makefile#L14-L17
  • See https://github.com/YosysHQ/nextpnr/blob/master/fpga_interchange/examples/archcheck/test_data.yaml
    • Note that test data will be architecture specific
• Run basic circuits, generate bitstream via open tooling and Vivado. Diff FASM output, verify no differences
  • Bitstream via open tooling will require Need a FPGA interchange to FASM generator #27 to be done
  • Example circuits to test:
    • wire
    • const wire
    • FF
    • LUT
    • LUT+FF
    • counter
    • murax

Future work:

• Stand up initial US+ target, Ultra96+
• Stand up second vendor arch

[litghost]

Once SymbiFlow/nextpnr#234 is completed, run those site routing tests should be integrated into this CI as well.

[acomodi]

@litghost I was thinking about taking this issue unless there are some other priorities.

I see that we cannot get to the full fpga-interchange diff FASM test with Vivado, but I guess we can get to test whether the circuits get placed and routed, with no bitstream generation, is this correct?

One other question regards the CI itself. Given that this is an integration test between different moving parts, I wonder what would be the best approach here.
Were you thinking of something similar to symbiflow-arch-defs, where we use pinned version of the various parts and test the whole flow? In this case we might need to create a new repo, with the only purpose to do integration testing.

[litghost]

but I guess we can get to test whether the circuits get placed and routed, with no bitstream generation, is this correct?

Yes, kind of. We can use Vivado to generate a bitstream from the RapidWright DCP. But as you say, until we have a direct FPGA interchange -> FASM generator, there is no way to do the diff fasm test yet.

[litghost]

One other question regards the CI itself. Given that this is an integration test between different moving parts, I wonder what would be the best approach here.
Were you thinking of something similar to symbiflow-arch-defs, where we use pinned version of the various parts and test the whole flow? In this case we might need to create a new repo, with the only purpose to do integration testing.

In terms of how I think the CI should work, I believe it should have 3 bits:

• Submodules of the relevant tightly coupled systems:
  • nextpnr
  • python-fpga-interchange
  • RapidWright
  • fpga-interchange-schema
• A set of CMake projects/functions for building:
  • Building a nextpnr chipdb from RapidWright
  • Defining tests
• A conda environment for bringing in little coupled components:
  • capnproto
  • yosys
  • fasm
  • prjxray
  • prjxray-db

The CMake files shouldn't care where components are coming from, either because they are on the PATH (and CMake cache var'd) or specific explicitly (e.g. RAPIDWRIGHT_PATH or part names).

I think the place to start would be to just create some CMake scripts and add them to YosysHQ/nextpnr in the FPGA interchange directory.

[acomodi]

@litghost I was able to reproduce locally the whole flow after some issues with capnproto versions and python setups.

As far as I understand, the generation of the chipdb uses Makefiles and data files present in the python-fpga-interchange project, which is cloned in the nextpnr/fpga_interchange. What I do not completely understand is what the CMake in nextpnr should be provided with in order to generate the chipdb.

In other words, should nextpnr be able to reproduce what the RapidWright Makefile does? The fact is that we may need to add the python-fpga-interchange as a submodule, as some [test_data] is present in the python-fpga-interchange repo.

Apart from that, I have started to get some CMake infrastructure in place to add the creation of the chipdb and tests targets.

[litghost]

I think there are different aspects. We need a independent CMake function / set of functions for doing:

• RapidWright part -> device database
• device database -> chipdb
• yosys output -> logical netlist
• logical netlist + device database / chipdb -> physical netlist
• logical + physical netlist + RapidWright -> DCP
• logical + physical netlsit + (future tool) -> FASM

That make sense? As more arches come online, the device database won't come directly from RapidWright.

[acomodi]

@litghost with the CI PR merged, can this be closed?

[litghost]

@litghost with the CI PR merged, can this be closed?

No? We need to stand up more parts (Zynq 7-series, A7-100, A7-200), and we need to integrate with a runner that can run Vivado.