Open-source (yosys) synthesis of CVA6 (possible ?)

[isa084]

I am aware of PULP Platform's pulp-platform/croc and pulp-platform/cheshire that support Yosys. Croc is a tiny RISC-V chip for educational purposes, whereas Cheshire is a SoC with CVA6 sitting at its core.

As per my understanding, they have a separate development trajectory compared to this repository (openhwgroup/cva6). Please correct me if I am wrong.

The comment on this thread https://github.com/openhwgroup/cva6/issues/2319#issuecomment-2405623605 suggests that it is possible to synthesize CVA6. It is clear that it works for Cheshire, but it is not clear whether the answer applies to OpenHWGroups's repository as well.

My questions are :

1. Whether synthesis with yosys has been successfully attempted on the RTL associated with this repository ?
2. What is a reasonable scope for which synthesis should be attempted ? Is it possible to confine the scope to the core only (i.e. only SV files and RTL configs inside "core" folder) ? Or does the synthesis step require the integration of the core with peripherals (e.g. files associated with corev_apu) ?
3. Once a scope is selected, what should be the starting point ? I was able to parse Systemverilog files to verilog with some hacks suggested here (https://github.com/openhwgroup/cva6/issues/2319#issuecomment-2405623605)

Apart from this, if there is a general roadmap for supporting open source VLSI design tools such as Yosys, OpenROAD and Klayout, please point me to it.

Thanks

[JeanRochCoulon]

Good point ! We are discussing within OpenHW to support open source design flow in the CI.

[isa084]

I would like to learn more about this. If there is an opportunity to contribute, please let me know. I struggled with this quite a lot and have halted further work. Might as well make it worthwhile by contributing back to the mainstream.

[phsauter]

You should be able to use yosys-slang to read CVA6 into yosys, this should work without problem as it is one of the test cases used. As for synthesis flow, a simple synth in yosys followed by dfflibmap and abc with a target technology will suffice but might not produce optimal results.

I would also be glad to help any efforts to include open-source tools in the CI or as examples.

[isa084]

@phsauter , so I got something and I will need some help in confirming whether I am on the right track :

First, I checked out commit f314dcb. There is an issue with the AES module (added recently as part of Scalar crypto extension) which was giving me some sv parsing error, so I reverted to an older commit.

Then, I ran the following script (bash script.sh ) :

export PATH=<path-to-oss-cad-suite-linux-x64-20250315>/oss-cad-suite/bin:$PATH
export CVA6_REPO_DIR="<path_to_cva6_repo>"
export HPDCACHE_DIR="${CVA6_REPO_DIR}/core/cache_subsystem/hpdcache"
export TARGET_CFG="cv64a6_imafdc_sv39"
yosys -s test.ys

where, the contents of test.ys are :

plugin -i slang
read_slang --top cva6 -f cva6/core/Flist.cva6 -keep-hierarchy
hierarchy
synth
stat

Instead of supplying all sv files one by one (as shown in the demo example for yosys-slang), I directly passed the Flist.cva6 and HOPED for the best.

I had initially added dfflibmap and abc as per your suggestion. That resulted in an error (missing liberty file). I removed dfflibmap and abc, then reran with the test.ys file that you see above.

I finally got a complete run and some numbers printed towards the end :

   Number of wires:             279338
   Number of wire bits:         597452
   Number of public wires:        6467
   Number of public wire bits:  324107
   Number of ports:               3435
   Number of port bits:         148133
   Number of memories:               0
   Number of memory bits:            0
   Number of processes:              0
   Number of cells:             323471
     $_ANDNOT_                   54738
     $_AND_                       9861
     $_DFFE_PN0N_                   93
     $_DFFE_PN0P_                20816
     $_DFFE_PN1P_                   31
     $_DFFE_PP_                     69
     $_DFF_PN0_                   5400
     $_DFF_PN1_                     10
     $_MUX_                     125806
     $_NAND_                      6373
     $_NOR_                       9709
     $_NOT_                      10724
     $_ORNOT_                     6823
     $_OR_                       40747
     $_XNOR_                      8565
     $_XOR_                      23703
     $pow                            3

Warnings: 2898 unique messages, 2898 total

What more steps are needed to refine the steps further ? I can see there is LOT of stuff in Cheshire. This pales in comparison, but at least provides a starting point (I guess).

[phsauter]

This already looks pretty good. Yosys-slang was able to parse and elaborate the entire tree otherwise it would have failed earlier. Giving the flist is the right thing to do as well. It is correct that both the dfflibmap and the final abc pass require at least one liberty file as an argument.
The liberty file contains the logical description of the cells you have available in your technology (eg a NAND cell with 2 inputs or a OR cell with three inputs). If you want to synthesize to a specific technology for ASICs you need to give it your liberty file. If you want to synthesize for any ASIC technology you can select one of the open standard cells (sky130hd, ihp13-open, GF180) or a stand-in technology (ASAP7, nangate45).
If you want to synthesize for an FPGA instead I recommend you search the Yosys command line reference for the appropriate synth_* command to use (eg synth_ice40).

[isa084]

I will try with IHP130-open and nangate45, and then post about my findings here.

I also have a side question about post-GDSII simulation, and whether it has been tried on CVA6 (whether with proprietary or open source tools). It might become significant as we try to ramp up the core's frequency and/or implement on lower technology nodes. On this repository, I have seen the directory pd/synth but I am not sure if it covers this part.

[OlivierBetschi]

In the paper "Insights from Basilisk: Are Open-Source EDA Tools Ready for a Multi-Million-Gate, Linux-Booting RV64 SoC Design?", the PULP team manage the synthesis of CVA6 using 3 tools (Morty, Svase and sv2v) to preprocess the CVA6 before giving it to yosys. Another possibility is using synlig from CHIPS Alliance (https://github.com/chipsalliance/synlig). Maybe these are worth investigating for a full open-source flow ?

[xtofalex]

Hi everyone, I tried with the instructions proposed by @isa084 and getting following output:

 /----------------------------------------------------------------------------\
 |  yosys -- Yosys Open SYnthesis Suite                                       |
 |  Copyright (C) 2012 - 2025  Claire Xenia Wolf <[email protected]>         |
 |  Distributed under an ISC-like license, type "license" to see terms        |
 \----------------------------------------------------------------------------/
 Yosys 0.53+81 (git sha1 0fcf5c080, c++ 17.0.0 -fPIC -O3)

-- Executing script file `yosys.ys' --

1. Executing SLANG frontend.
Top level design units:
    cva6

While generating the netlist content of HDL instance cva6.ex_stage_i.aes_gen.aes_i
	of module aes
	with parameters CVA6Cfg=17176'd46176991798803398957572234142658603336...e5125 fu_data_t=aes.fu_data_t
	wire for symbol aes_pkg::gfmul.temp is missing
	(id $root.aes_pkg.gfmul.temp)
remapped scopes:
 (none)
ERROR: Internal frontend error at /Users/xtof/WORK/yosys-slang/src/slang_frontend.cc:3046, see details above

Am I missing something or is it related to different versions (cva6, yosys or slang) ?

Thanks !

[isa084]

@xtofalex , please see my previous comment where I have mentioned this problem. I worked around it by checking out an earlier version of the repository.

The error message shown by you requires a fix in the AES module.

[phsauter]

@povik do you by chance see the problem from the error? It is coming from this function: https://github.com/openhwgroup/cva6/blob/master/core/include/aes_pkg.sv#L71

[povik]

@xtofalex please report the plugin version you're using. You can find out with the slang_version Yosys command.

[povik]

This looks like it might be a case of https://github.com/povik/yosys-slang/issues/110 (fixed as of master)

[phsauter]

This looks like it might be a case of povik/yosys-slang#110 (fixed as of master)

Perfect thanks, then assuming @xtofalex is using the IIC-OSIC-TOOLS container image this should be fixed in the next release.

[povik]

Note the OpenROAD project evaluates the tool on CVA6 among other designs (ingested with yosys-slang): https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/tree/master/flow/designs/asap7/cva6

[phsauter]

Note the OpenROAD project evaluates the tool on CVA6 among other designs (ingested with yosys-slang): https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/tree/master/flow/designs/asap7/cva6

Nice to hear, thats a lot better than the pre-processed version used previously.
Though it doesn't seem to use upstream (which is understandable) and currently doesn't have AES.

[xtofalex]

@xtofalex please report the plugin version you're using. You can find out with the slang_version Yosys command.

yosys-slang revision 9c274f560248fe855ddc234b41890801c31b3a1a slang revision 78664c45ae15892f33c87fda93b77e6a51d150f3

I'm currently updating yosys and yosys_slang to latest version and will try on CVA6.

[povik]

Thanks, your revision looks to include the fix for https://github.com/povik/yosys-slang/issues/110 so this might be a new issue

[povik]

@xtofalex I cannot reproduce. I can run the script provided by @isa084 to completion on CVA6 f314dcb1 and yosys-slang 9c274f56

[xtofalex]

@povik I relaunched with everything updated to latest and getting the following:

 /----------------------------------------------------------------------------\
 |  yosys -- Yosys Open SYnthesis Suite                                       |
 |  Copyright (C) 2012 - 2025  Claire Xenia Wolf <[email protected]>         |
 |  Distributed under an ISC-like license, type "license" to see terms        |
 \----------------------------------------------------------------------------/
 Yosys 0.54+1 (git sha1 c0f52c6ea, c++ 17.0.0 -fPIC -O3)

-- Executing script file `yosys.ys' --
yosys-slang revision 52875e39f60715d97f4f6ad969908982d500a7d7
slang revision 78664c45ae15892f33c87fda93b77e6a51d150f3

1. Executing SLANG frontend.
Top level design units:
    cva6

While generating the netlist content of HDL instance cva6.ex_stage_i.aes_gen.aes_i
	of module aes
	with parameters CVA6Cfg=17176'd46176991798803398957572234142658603336...e5125 fu_data_t=aes.fu_data_t
	wire for symbol aes_pkg::gfmul.temp is missing
	(id $root.aes_pkg.gfmul.temp)
remapped scopes:
 (none)
ERROR: Internal frontend error at /Users/xtof/WORK/yosys-slang/src/slang_frontend.cc:3047, see details above
zsh: exit 1     /Users/xtof/WORK/yosys/install/bin/yosys yosys.ys

To be clear, I'm also using latest cva6.

[isa084]

@xtofalex instead of using the latest commit of CVA6, use this commit https://github.com/openhwgroup/cva6/commit/f314dcb136ed373db8332e30a897fa06db4aae43 . You should see same results as I have reported. @povik has confirmed this.

[isa084]

Continuing where I left off previously

I got the synthesis results for nangate45, but not sky130hp. sky130hp was a bit confusing, and I will come to it later.

---

So, about nangate45 :

I downloaded the liberty file from OpenROAD flow scripts repository.

Then I used the following script :

plugin -i slang
read_slang --top cva6 -f cva6/core/Flist.cva6 -keep-hierarchy
hierarchy
synth -top cva6
dfflibmap -liberty <path-to-nangate45 lib file>
abc -liberty <path-to-nangate45 lib file>
stat

I got stuck on "abc" command for quite some time. My guess is that the optimization pass can go on for a long time. I commented the "abc" line and reran again. This gave me the results in a format similar to my previous reported result. However, the gate and transistor counts were different (this is expected as we have specified a different technology).

---

Addendum :

I looked further into the "stat" command, and found that yosys "temporarily" maps the netlist to "cmos" technology if you use "stat -tech cmos". I tried to find the closest description of what actually constitutes the "cmos" library and landed here. This page says that "cmos" consists of NAND NOR AOI3 OAI3 AOI4 OAI4 NMUX MUX XOR XNOR .

You can read about the "stat" command here.

The following script shows how to perform this technology mapping for CVA6 :

plugin -i slang
read_slang --top cva6 -f cva6/core/Flist.cva6 -keep-hierarchy
hierarchy
synth -top cva6
stat -tech cmos

Using the above script, I was able to generate area results, which happen to be exactly the same as I reported earlier in https://github.com/openhwgroup/cva6/issues/2975#issuecomment-2914516520 .

@phsauter, I will appreciate if you can confirm whether this is the right track. I find the options to optimize the netlist, as well as choosing tech files quite overwhelming (e.g. in sky130hp). It is not straightforward what optimization passes should be applied at which stage of the flow. What are your thoughts on this ? Also, what is the default technology mapping used by "stat" command in yosys (is it cmos ?)

[isa084]

About sky130, my confusion is that there are multiple options available (e.g. see this directory . I can see sky130hd, sky130hs, sky130io, sky130ram. Each of them has their own set of liberty files. The choice is not clear immediately.

For reference, I looked at the work in Cheshire IHP 130 (e.g. the technology.mk file . Looking at it, one gets the idea that we may use different lib files for different components. If yes, how do we do that in context of this repository ?

[phsauter]

Yes you are on the right track. I would expect abc to take some time as it internally runs another script in abc.
I would recommend some additional things added to the script below:

plugin -i slang
read_slang --top cva6 -f cva6/core/Flist.cva6 -keep-hierarchy
keep_hierarchy <module>
synth -top cva6 -flatten -noabc
dfflibmap -liberty <path-to-nangate45 lib file>
abc -liberty <path-to-nangate45 lib file>
hilomap -singleton -hicell <HICELL> <PORT> -locell <LOCELL> <PORT>

Importantly I use keep_hierarchy to mark all modules I am interested in keeping separate (eg register files or different stages) and then I use flatten to flatten the rest together. This should reduce runtime and improve the results.
Additionally you can use -noabc as we are running abc with the technology data later anyway, this should again reduce runtime a bit.
Finally you also need hilomap to map the tie cells (tie to logic high and tie to logic low, they implement constants).

As for sky130, I recommend you use syk130hd if you don't have a good reason to use syk130hs.
And yes, for Cheshire-ihp-130-o we use IHPs 130nm open PDK. You can find it here, the standard cells are here.

[xtofalex]

@xtofalex instead of using the latest commit of CVA6, use this commit f314dcb . You should see same results as I have reported. @povik has confirmed this.

Hi @isa084 , yes I understood. But from https://github.com/openhwgroup/cva6/issues/2975#issuecomment-2959262348 and following answers, I understood that latest yosys_slang (https://github.com/openhwgroup/cva6/issues/2975#issuecomment-2963335578) might contain a fix.

@povik, do you confirm this ? I see above that you are using https://github.com/openhwgroup/cva6/commit/f314dcb136ed373db8332e30a897fa06db4aae43 for cva6.

[povik]

@xtofalex going to CVA6 head I got the same error as you. I've pushed a fix to yosys-slang: https://github.com/povik/yosys-slang/commit/8e3df11b7846611748602165a05dbd61711090ea

[xtofalex]

@xtofalex going to CVA6 head I got the same error as you. I've pushed a fix to yosys-slang: povik/yosys-slang@8e3df11

Thanks a lot @povik, i confirm that it works.

[isa084]

@everyone I have captured the learnings from our discussion in the form of a repository :

https://github.com/isa084/cva6-synthesis

I have provided a dockerfile to setup the environment for this purpose. There are multiple dependencies : yosys, yosys-slang, compiler versions, liberty files, etc. that are best managed in a docker container.

I have also provided a couple of simple scripts to synthesize openhwgroup/cva6 for different tech libraries (e.g. nangate45 , cmos).

I hope that this will be useful towards incorporating open source design flow for openhwgroup/cva6, which has been the original point of this issue.

[xtofalex]

Hi @isa084, I’m working on something close: embedding a GitHub Action that leverages Docker-packaged tools like Yosys, Slang, and najaeda. So far, I’ve been targeting Xilinx FPGA library, but I’m currently extending the action to support synthesis across multiple libraries. I’m using Najaeda to extract various stats from the resulting netlists, such as gate count, fanout, and more. If anyone has additional ideas for metrics or analyses, I’d be happy to integrate them via custom scripts. You can check out the latest run here: https://github.com/xtofalex/cva6/actions/runs/15783821379/job/44495675857

[isa084]

@xtofalex This is neat ! Please feel free to use this repository's template scripts for your project.

Also, are you building your project on Github hosted runners, or self-hosted ones? Few weeks back, I setup Github actions CI on self-hosted runner(s) for a project. The upstream CI scripts require minor tweaks to allow self-hosted runners. I would like to know and share if you plan something in that direction.

---

Coming back to the yosys synthesis for CVA6, I am still facing issues ( at least two of them) :

Issue 1 : Passing environment variables to yosys .ys scripts

Consider this script https://github.com/isa084/cva6-synthesis/blob/master/hw/cv64a6_imafdc_sv39_nangate45.ys . I declared NANGATE45_LIB_PATH to point to a shell environment variable associated with the nangate45 liberty file. This script doesn't work, because it seems I am using the wrong syntax. Please advise on this part.

Issue 2 : Getting runtime errors with flatten argument : As suggested by @phsauter , I ran the following script.

plugin -i slang
read_slang --top cva6 -f cva6/core/Flist.cva6 -keep-hierarchy
synth -top cva6 -flatten -noabc

However the flatten argument causes an error :

ERROR: Conflicting init values for signal 1'0 (\ex_stage_i.lsu_i.i_pmp_data_if.i_pmp_data.gen_pmp.$4.i [4] = 1'x != 1'0).

If I run the synth command without flatten, I am able to proceed to next steps.

With flatten, the issue seems to be occurring in this file : https://github.com/openhwgroup/cva6/blob/master/core/pmp/src/pmp_entry.sv . I haven't narrowed down the root cause. It could be from the RTL, or from yosys/yosys-slang.

Please see if any of you are able to reproduce this. Also provide feedback for improvement.

Thanks

[povik]

Issue 2 : Getting runtime errors with flatten argument :

This is due to https://github.com/povik/yosys-slang/issues/119 and can be worked around by inserting

setattr -unset init

after read_slang