Unable to synthesize using Yosys

[Harshitha276]

Is there an existing CVA6 bug for this?

• [x] I have searched the existing bug issues

Bug Description

I am trying to synthesize the CVA6 core using open-source tools. Our synthesis flow involves Yosys, a synthesis tool. Because Yosys doesn't read SystemVerilog, we are using Zach's sv2v tool https://github.com/zachjs/sv2v to convert SystemVerilog to Verilog and synlig for parsing https://github.com/chipsalliance/synlig. Despite our efforts, we have encountered several issues that are preventing successful synthesis. I observed that there were tcl scripts provided for Synopsys DC. Is there a way for us to use tools like Yosys and synthesize it?

[JeanRochCoulon]

Hello, Nice to try Yosys. Unfortunately, no Yosys support is provided so far. But we are of course open for contributions !

[cliffnotes]

Jean: To create an SOC that uses CVA6, we need Synopsys or Cadence? Is that what you are saying?

[JeanRochCoulon]

No, I do not say it. Synopsys is used to do CVA6 synthesis. We have no experience with Cadence or Yosys.

[cliffnotes]

We will attempt to get Yosys working this week with the latest versions of Surelog, etc. If successful, we will try to make create layouts on ts40, gf22, ts16, and gf14. this month. If all goes well, we will be happy create CVA6 layouts for free (even for Synopsy users) if our liberty file is used. We generate our own standard cells to get around NDAs

[JeanRochCoulon]

That's a great news ! We would be please to learn more on your flow. When ready, I would be pleased to invite you to the cva6 meeting to present it.

[Moschn]

FYI, there is a project that tests compatibility of open-source system-verilog tools with popular open-source SV projects: https://chipsalliance.github.io/sv-tests/. They also include CVA6 (under the old name Ariane) in the cores category. The dashboard shows that no tool is able to compile CVA6. However, I believe the way they build CVA6 is broken as they rely on the old Makefile. I recently started to fix the build procedure on this dashboard.

In general, we mostly use verilator and synopsis tools. I believe other people have successfully used Cadence tools and Yosis before, but this usually requires some effort to read the error messages and fix the issues that pop up.

[phsauter]

We are actually able to use SV2V and our own tool SVase to successfully convert CVA6 to Verilog and then read it into Yosys. As you can see there are still a handful of patches necessary to convert some RTL features to make this toolflow handle it successfully

You can find the flow here: https://github.com/pulp-platform/cheshire-ihp130-o/tree/main/target/ihp13/pickle

And it is also described a bit here: https://arxiv.org/abs/2405.04257 And also here: https://arxiv.org/abs/2406.15107

In the future there should also be Yosys-Slang which uses the top performing Slang parser to implement a Yosys frontend, this is still in early development though.

P.S: If someone would like to work on improving this compatibility by slightly rewriting 10-20 RTL constructs I would be glad to help with the things we learned so far.

[cliffnotes]

Thank you!

My analog, SRAM, DSP teams perform well, but we have been very unsuccessful on the CPU side. Digital is not our strong suit (until recently, we went by the name "Analog Rails"). We are completely reliant on Verilator, YosysHQ and a CPU to complete our IC tools and IP to go against the EDA oligopoly. We have put over 200 man years into this and it is time to deliver.

I won't allow our company to use any of our competitors tools, so we are reliant on YosysHQ succeeding. Any help that you can offer us to see Yosys work on your project is appreciated. I will put a bunch of our new MSEEs onto rewriting 10-20 RTL constructs TODAY. Please guide us.

[phsauter]

The necessary RTL patches we apply are pretty well documented in https://github.com/pulp-platform/cheshire-ihp130-o/tree/main/target/ihp13/pickle

You would have to track down where exactly they come from and figure out how to rewrite these parts to make them go through the various tools.

But I have another question, have you ever tried the commercial YosysHQ offering Tabby CAD? It comes with SystemVerilog support, I think via Verific.

[cliffnotes]

We just started using Tabby on Monday. It helped tremendously, but we are still facing some issues. We are still working through it. We will keep you posted. Thanks for the tips. My team will follow your lead.

[hhhsiang]

Hi @Moschn , I want to check some problem about the EDA tool you use about cva6. I know it is weird to ask you these problems, but I have to tape out cv64a6 core in three months, the time is urgent.

1. Is cva6 core is a synthesizable IP? I found that the cva6 core also instantiate some modules from vendor/pulp-platform/common_cells/src, such as lzc.sv、rr_arb_tree.sv. And some modules instantiated under cache_subsystem are from common/local/util. These modules seems to be non-synthesizable.
2. Is it available to run smoke-tests for gate-simulation with verialtor after synthesis with design compiler? Or I need to use vcs to run gate-simulation?
3. Is it available to run smoke-tests for post-simulation with verialtor after APR? Or I need to use vcs to run post-simulation?
4. Is there any correct steps to do cv64a6 core synthesize and run smoke-tests for gate-simulation? Because the guideline in README seems to be old and have some problems.

I had tried to synthesize cva6 core by the makefile under cva6/pd/synth, but lots of errors occures. A large number of errors are about "Constant expression too complex. (ELAB-937) ", like this:

Error: ../..//core/scoreboard.sv:303: Constant expression too complex. (ELAB-937)

As a result, lots of modules are not synthesized.

Additionally, are there any other important issues or considerations I should be aware of before synthesizing the system?

Any advice or suggestions would be greatly appreciated. Thanks in advance!

[cliffnotes]

I am appalled that the open hardware groups is pushing the proprietary EDA software (Synopsys). UVM is a scam to push everybody towards VCS. The CVA6 group should make it clear that they only support Synopsys tools.

We decided to create our own RISC-V architectures that enable us to use Verilator and Yosys. If there are any US based companies interested needing our help in taping out chip involving with a RISC-V core in TSMC 16/12 or GF14, we can help free of charge. We have analog IP and a complete IC design environment that can get out the door 50x faster than using VXL, but the core must be Verilator and Yosys friendly.

Verilator/Yosys users: Please feel free to contact Western Semiconductor. We have complete standard cell libraries, analog IP, and soon SRAM, along with the entire suite of tools to get your chip out the door. We are looking for US partners.

Note: We are only on this forum because we didn't know that VCS is a requirement. This was a shocker.

[Moschn]

Hi @hhhsiang,

1. CVA6 is definitely synthesizable and has been taped out multiple times. Most modules in common cells should be synthesizable as well. If you encounter errors, take a look at the source code in the offending modules. Maybe you did not set a define correctly. I believe the modules in common/local/util are not all synthesizable. However, the compilation for a hardware target is usually different than for simulation (in verilator) and includes different files and sets different defines. As far as I am aware, there is not ready-made script or list of files to include for a hardware target. You will have to get your hands dirty and take a look at the source code. Often, we provide two versions of a module, one not synthesizable and the other synthesizable.
2. I am not sure if Verilator can be used in this way. I assume that this can be done with VCS or Questasim but I am no expert in this area. If you are targeting a tapeout, you probably have to invest some time developing a testbench that can be run post-synthesis and post-layout. Our simulation infrastructure is not necessarily able to target hardware as we, for example, sometimes pre-load the memory for faster simulation speed.
3. see 2. above
4. see 2. above

@cliffnotes

Note: We are only on this forum because we didn't know that VCS is a requirement. This was a shocker.

VCS is not a requirement. Since at least 5 years, I have not used commercial EDA software in my work on CVA6. Admittedly, I only worked in a very limited fashion with the core, and I never went past simulation. Nevertheless, you can run all simulations using verilator.

Since CVA6 is written in systemverilog, it is quite tricky to use yosys with it as yosys does not fully support systemverilog. But that is not necessarily our fault but rather a missing feature for yosys.

[Moschn]

After I thought some more on this, I think there is a misunderstanding of the verification infrastructure in CVA6. The goal of the verification effort is to find as many bugs as possible. We use any tool that helps us on this path. However, as a user of CVA6 you do not have to use the verification infrastructure that is provided. You can easily roll your own testbench that can run in your simulator/EDA tool of choice. You still benefit from the work done in the CVA6 verification effort as any bugs found will be fixed in the RTL that you can use.

Maybe there would be a case for a minimal testbench that is easy to adapt for any tool. This could be an interesting feature request, but as far as I know such a testbench does not exist yet.

Take all of this with a grain of salt as I am not deeply involved in the verification effort, nor in the development of CVA6.

[phsauter]

I am appalled that the open hardware groups is pushing the proprietary EDA software (Synopsys). UVM is a scam to push everybody towards VCS. The CVA6 group should make it clear that they only support Synopsys tools.

We decided to create our own RISC-V architectures that enable us to use Verilator and Yosys. If there are any US based companies interested needing our help in taping out chip involving with a RISC-V core in TSMC 16/12 or GF14, we can help free of charge. We have analog IP and a complete IC design environment that can get out the door 50x faster than using VXL, but the core must be Verilator and Yosys friendly.

Verilator/Yosys users: Please feel free to contact Western Semiconductor. We have complete standard cell libraries, analog IP, and soon SRAM, along with the entire suite of tools to get your chip out the door. We are looking for US partners.

I have pointed you in this direction before but we have a completely open flow for a CVA6 based system here: https://github.com/pulp-platform/cheshire-ihp130-o

The major downside before was that you needed this complex pre-processing pipeline to get SystemVerilog code into Yosys (or buy Tabby Suite). This is no longer the case, yosys-slang can successfully parse and elaborate CVA6. Verification is still a pending item we are working on, at the same time povik is continuously improving yosys-slang to support as many language concepts as possible.

We are firmly committed to continue to improve the open-source tools and providing reference flows for open-source IPs.
In fact we are currently in the process of finding missing yosys-slang features and reporting them to povik by feeding it our largest IPs. At the same time we are fixing flagged problems in the code to eventually be able to integrate CI with Yosys elaboration.

As for simulation, as @Moschn mentioned RTL simulation should work fine with Verilator. Similarly you can also simulate using Yosys' internal cells (provided you give the path to the cell descriptions). It is also possible to simulate netlists using the Verilog models of the cells but crucially, they may not contain any user defined primitives (UDP) and some other things.
To my knowledge, there is currently no good way to simulate with proper timings using open-source tools. Icarus Verilog should be able to do so but it does not support SystemVerilog testbenches which is a major limitation.

You also mentioned standard cells and SRAM. IHP130nm is a open-source technology with SRAM macros. Everything can be found here with tapeouts here.
For more advanced nodes there are stand-in technologies namely ASAP7 (7nm proxy) and Nangate45 (45nm proxy).

A new open-source RISCV effort with open-source tool support and even (proxy?) standard cells lead by your team would also be welcome.

[cliffnotes]

I suspect that Synopsys will continue pushing the IEEE "standards" to force Verilator to attempt to always play catch up. Synopsys is playing you guys. This thread has caused us to change policy and require all of our MSEE graduates who want to work on our CPUs to go through this tutorial: https://itsembedded.com. I am anti-UVM and I not thrilled with your TBs using these constructs, but using these constructs in the DUT is inexcusable. You guys just push the monopoly.

I am CEO of a commercial EDA company, so I am not an open source guy on all parts, especially analog. That is our crown jewels. We are happy to work with individuals from this forum on a RISCV effort. At least I will provide full disclosure. Also, we will only work with US companies and our closest allies. This disqualifies us from working full open source. We will supply our tools and IP for free for pre-screened people and groups.

We are working on 3 chips (push button migration, even for analog) between 40nm, 16nm, and 14nm) that use our (or your) RISC-V CPU. Any takers?

[phsauter]

So I just spent 20 man minutes reading cva6 into yosys (I attached the HDL, script and netlist).
To do this I used the provided file list, this script and then I ran the command yosys -m slang.so -s yosys.ys (requiring yosys and the newest version of yosys-slang). There is exactly one (ONE!) language feature I had to fix (slicing with index-up on a complex datatype), thats being implemented as we speak.

It seems to me like any competent engineer should be more than capable to use this project with open-source tools. cva6-export.zip

[hhhsiang]

Apologies for the interruption, everyone. I’m just a master’s student from Taiwan and have been working with the CVA6 core. I believe open-source tools offer a great opportunity for development with the CVA6 core. However, I need to modify certain parts of the circuit, which requires running a full set of tests, including gate-level simulation and post-layout simulation.

I understand there might be challenges when it comes to backend simulations using open-source tools, but I truly appreciate the guidance and assistance from you. Perhaps I will use the open-source tools you recommend in the future, if I no need to modify the cva6 core.

Thanks again for all your assistance.

@Moschn , I'm sorry to bother you, but if it's possible, could I exchange contact information with you? I'd like to ask you more detailed questions about CVA6.

[cliffnotes]

Our current team will stick to our own un-parameterized RISC-V CPU with our SRAM, ALU, standard cells, and TileLink. We rely on Verilator, Icarus, and Yosys. We now try to avoid anything that breaks Verilator and Yosys directly. We think you guys in the open source TOOLs arena are fantastic and we certainly would rather use your stuff on the front-end.

We expect a surge of newly graduated MSEE button pushers to apply to work as volunteers in the middle of December. We will be happy to have them try out your conversion utilities on the open source hardware that uses Synopys constructs that the open hardware communities insist on using, but our preference is to work with US based RISC-V startups that will be created due to layoffs.

We plan on continuing to check on the progress that the SV to Verilator/Icarus/Yosys and Tabby developers make. Please keep this task open. It has valuable feedback, and our team (and probably others) will want to try out this open source hardware and software flow. It will be interesting to see if the tools guys can keep up with the monopoly's advocates.

[thommythomaso]

Our current team will stick to our own un-parameterized RISC-V CPU with our SRAM, ALU, standard cells, and TileLink. We rely on Verilator, Icarus, and Yosys. We now try to avoid anything that breaks Verilator and Yosys directly. We think you guys in the open source TOOLs arena are fantastic and we certainly would rather use your stuff on the front-end.

As @phsauter wrote multiple times at this point, we CAN synthesize and implement CVA6 and for sure one of its SoCs with only open-source tools. In fact, we have already completed two open-source tapeouts, and we will have a third one in November.

We expect a surge of newly graduated MSEE button pushers to apply to work as volunteers in the middle of December. We will be happy to have them try out your conversion utilities on the open source hardware that uses Synopys constructs that the open hardware communities insist on using, but our preference is to work with US based RISC-V startups that will be created due to layoffs.

Again, we NO LONGER USE CONVERSION TOOLS. Yosys can read in almost any synthesizable SystemVerilog constructs thanks to yosys-slang.

Even though it is not directly project-related, I would like to emphasize GitHub's Community Guidelines here, which clearly states to use open-minded, respectful, and empathic language. Calling your employees button pushers and a strong US-centric view is clearly not in sync with open-source's free and open-minded philosophy. There is no European or US open source as open source does not know any borders.

We plan on continuing to check on the progress that the SV to Verilator/Icarus/Yosys and Tabby developers make. Please keep this task open. It has valuable feedback, and our team (and probably others) will want to try out this open source hardware and software flow. It will be interesting to see if the tools guys can keep up with the monopoly's advocates.

As @phsauter demonstrated, CVA6 can successfully be elaborated with Yosys. In that sense, this current issue could be closed. It might make sense to open a follow-up issue to implement elaboration of CVA6 with Yosys directly in CI.

[cliffnotes]

"Calling your employees button pushers and a strong US-centric view is clearly not in sync with open-source's free and open-minded philosophy. There is no European or US open source as open source does not know any borders."

I receive resumes every day from US MSEE graduates who believe that Cadence invented the electron. The voluntary MSEEs who just push the button do not become employees.

We have borders, well, we used to anyway. Sorry that you are offended.

Flo has stated that he wants the commercial sector to use the open hardware groups designs. We would like to offer US (and US friendly) customers our mixed-signal EDA platform, which includes extensive analog, logic, and soon SRAM library. We would like to demonstrate the CVA6 (we use the "It's embedded" verification flow) in our tools, along with peripherals. We have automated both analog (everything) and digital P&R on TSMC and GF's finfet processes.

I am giving you honest feedback. The open hardware group allows DUTs to have constructs written in constructs that are commercial vendor specific. Flo and CVA6 developers told me this is the case. Doing this at the TB level is one thing. Doing this at the DUT level is another. The open source TOOLs (including conversions) hopefully continues to play catch up, and we will try this out every other month.

It seems that you are afraid of getting honest feedback. I have no intention of closing this task. You can try to sweep this under the rug and shut me out. This will prove YOUR close mindedness. We are an EDA company (and mixed signal design house) with an entire suite of tools except for 2 items, simulators and synthesis. We rely on these open source tools, and plan to continue using them. My criticism is directed at a policy that doesn't discourage the use of constructs that break the open source tools within the DUTs.

We intend on proving in the CVA6 while working on our own KISS CPU. We want you to succeed in a non-proprietary flow. I doubt all of your team shares your opinion. I spoke to many of my friends in the industry. They are equally shocked that the "open source" hardware is being created will only work on Synopsys tools. I guess you have to start somewhere, but hopefully that practice won't continue, or perhaps the OpenHW group will create a new CPU based on open source friendly constructs. We will be reporting our findings to your claim that the open source tools will work an SoC-able version of the CVA6 within 1 month. I will put new MSEEs on this task. We just got 2 new applicants while I am typing this retort.

Note: We forgot to check the RTL with Tabby. We need to do that. We are happy to work with them. Our recent focus was our own CPU since temporarily giving up on the CVA6.

[phsauter]

The open hardware group allows DUTs to have constructs written in constructs that are commercial vendor specific

Personally I have not seen this and it does seem to work with the open-source tools I use (Verilator and Yosys).
Can you please point out which constructs these are and where in CVA6 they are used (ideally the file and line number).

Also to make this clear to others reading this as well:
We are committed to making CVA6 work with any tool
This means both improving the open-tools and also writing the RTL and scripts in a reasonable way.
However, this does not mean we are against people using Synopsys. We also want to support the commercial tools, in fact ideally it should be as accessible for anyone on this planet to use open-source hardware with whatever tool they prefer.

[cliffnotes]

I am very happy that you use Verilator and Yosys. I am 10x more confident now that you are saying this. I'm on it!

Thanks!

[MikeOpenHWGroup]

Hello @cliffnotes, @phsauter, @thommythomaso, @hhhsiang, @Moschn and @Harshitha276. First of all, thanks for your interest in OpenHW IP, specifically the CVA6. Your contributions will always be welcome!

I see there is a lot of confusion about the OpenHW Group's stance on EDA tools. We are not creating IP that only works with a single vendor tools, and we use both proprietary and open-source tools as appropriate. A good summary of our position on tools can be found here.

If you are interested in making a contribution to this repo to support a specific synthesis flow, please feel free to open an Issue (as you have done) and/or submit a pull-request (maybe we'll see one from @cliffnotes?).

Please do not use Issues on our repositories to host debates about which tools and methodologies are best. The place for those debates is in one of our Technical Working Group or Task Group meetings. If you would like to attend these meetings, please email me at mike@openhwgroup.org.

[cliffnotes]

Why would you allow advance constructs in the DUT? I read your policy on the TB. I am talking about the DUT. This task is absolutely the right place to ask this question.

[MikeOpenHWGroup]

Why would you allow advance constructs in the DUT?

Same reason. At the OpenHW Group, our purpose is to curate "Industrial grade" IP for industrial users. We do not limit ourselves to the capabilities of open-source EDA tooling because our members want to use OpenHW IP in the same design flows they are using for their internal product development.