-
Notifications
You must be signed in to change notification settings - Fork 58
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
Using Yosys with Xilinx Series 7 devices (and non-standard tool flows) #92
Comments
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. |
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. |
Do you have suggestions for the most maintainable way to extend the The code already has a lot of flexibility thanks to the 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. |
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:
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. |
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'm wondering if it makes sense to split the build stuff into separate synthesis and place and route tooling?
The goal is that Yosys should be able to accept the exact same Verilog as Vivado (and the other commercial tools), so in theory nmigen doesn't need to change the Verilog output?
Alternatively, if Yosys is the primary frontend and nmigen is already using Yosys directly, is there something better that could be done?
I'm interested in;
See diagram at https://j.mp/openfpga-diagram and below;

The text was updated successfully, but these errors were encountered: