How do you suggest adding support for using Yosys for Synthesis and Vivado for place and route to the https://github.com/m-labs/nmigen/blob/master/nmigen/vendor/xilinx_7series.py file?

I don't. I think what you're suggesting will result in a compatibility nightmare for essentially no practical benefit. In my opinion, supporting 4 distinct flows, each with their own set of obscure bugs, for Series 7 alone (much less doing this for every conceivable target) is an anti-goal.

• (ECP5) Yosys (synthesis) -> nextpnr (place and route + bitgen)

Note that this is an exception in this list, since it's an officially supported and reasonably stable already flow. I actually have most code for it already, I just need to polish it.

@whitequark

Do you have suggestions for the most maintainable way to extend the nmigen.vendor flow as an external party? Does it make sense to just subclass the existing upstream (this repositories) vendor flows?

The code already has a lot of flexibility thanks to the script_(before|after)_xxx hooks but I can't see an easy way to just override the synthesis part?

I would like to have a good set of IP and applications which can be used to compare the open flows to the vendor versions. As MiSoC + LiteX are some of the most advanced users who truly care about open source I would like to see the open flows working really well with them.

@mithro

I think it'd be perfectly fine to override both file and command templates. The Yosys synthesis part is very minimal and I deliberately duplicate it among in-tree platforms because that makes it easier to understand how exactly it works. You can just copy and paste it as it's not really changing much if at all.

The buffer instantiation code would be shared, of course.

ECP5 with Yosys and nextpnr is done.

I thought more about this issue, and came to two conclusions:

1. Supporting a combinatorial product of toolchain components is not desirable per se: it has many drawbacks described above, and in general I would expect that adding one more supported configuration would make the user experience worse by ensuring there will be more bugs, since none of the flows you are describing above are anywhere close to being feature-complete or just production ready.
2. Nevertheless, supporting experimental combinations of toolchain components is a useful goal for reasons also described above. Indeed, that is how a new flow will come into existence in the first place.

Now, given these conclusions, I do not want to make any changes to existing flows solely to support these many new combinations that will almost never be used in practice. However, I am open to making changes to existing flows that are generally useful (for example, factoring out IOB instantiation code). To understand exactly which changes should be made, I would need to examine the particular flows in detail, and consider this in the wider context of nMigen design issues.

If you have a specific flow in mind that you would like to support, I encourage you to add this flow to nMigen and report your experience and pain points so that the nMigen design can be adjusted to accomodate this. (Of course, you can also contract me to do so.) However, I will not be adding any features to support non-standard tool flows that are not justified by real-world experience (i.e. working code that is not as good as it should be).

Replacing the Vivado synthesis front-end with Yosys may be useful (or may not, if there are other problems with Yosys) to work around certain bugs that Xilinx are taking forever to fix.

As far as I know, at this point Yosys still cannot infer many primitives that Vivado can, so it is unlikely that ARTIQ will pass timing. That said it is an interesting experiment, though of course ARTIQ will need to be ported to nMigen first (which has many dependencies like a MiSoC port.)

FYI, @eddiehung is working hard to make a LiteX SoC with VexRISC-V, DDR and Ethernet on Artix 7 work with a Yosys->Vivado flow.