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

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

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.

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.

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

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.

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

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