chipsalliance / UHDM-integration-tests

Apache License 2.0
30 stars 8 forks source link

Asking for help with `yosys` synthesis of a RISC-V CPU written in SystemVerilog #670

Open jeras opened 2 years ago

jeras commented 2 years ago

I wrote a RISC-V processor in heavy SystemVerilog with a lot of:

The most complex SV code is in instruction decoders for base I and C extension. There is another file with a lot of SV code containing CSR definitions, but I did not test this part of the code much yet.

The code was developed with vanilla Verilator, my aim was not to cover the SystemVerilog standard. The main two issue I had with Verilator were:

  1. lack of support for unpacked structures, so I just used packed structures everywhere, which is a bit ugly,
  2. X propagation is not simulated well, so I had to run regression tests with mapping X separately to 0 and 1. The CPU is passing all I ISA tests, the C decoder is also in a good shape, but I avoided using it in FPGA synthesis.

I synthesized the code in Vivado 2021.2 (Artix), Quartus 21.1 (Cyclone V), and LatticeDiamond/SynplifyPro (EPC5), I did not test any of the FPGA builds yet, the aim was to get past tool errors. Vivado and Quartus produced apparently reasonable results. Synplify was able to parse the code without significant warnings, but synthesis optimized everything out due to constant propagation. I suspect there are some issues with don't care values (X propagation), so in the next step I plan to test with Vivado Simulator and QuestaSim/ModelSim, and probably try to run some netlist simulations.

My main aim for yosys synthesis would be Sky130 PDK. The CPU has a 2-stage pipeline and IPC=1 (all instructions execute in a single clock cycle, without exceptions). The register file requires asynchronous reads, on FPGA I used distributed memories, so I had to use FPGA families which support this memory type (see above), Cyclone 10 and iCE40HX families do not support asynchonous read distributed memories. For Sky130 I would use DFFRAM, the 32x32-bit words (2R1W) register file. Instruction and data closely coupled memories use standard ASIC/FPGA SRAM, so OpenRAM would be just fine.

mithro commented 2 years ago

Some potentially useful links;

I would recommend first getting your core added to our SystemVerilog test suite @ https://github.com/chipsalliance/sv-tests -- this would allow you to see if the parser front ends are able to process your code.

On a semi-related note, you should also look at using Verible (https://github.com/chipsalliance/verible) for linting and code formatting of your code base. There are some nice GitHub Action integrations - see https://antmicro.com/blog/2021/08/verible-integration-with-github-actions/

On an unrelated note, I would recommend getting your CPU into the LiteX ecosystem. It already supports a large number of CPUs and has a great community. It can also be useful for comparing and benchmarking your CPU against other options using embench -> https://antmicro.com/blog/2020/09/automatic-cpu-testing-with-embench/ and multiple people are looking at doing ASIC tapeouts with SKY130 using this ecosystem.

mithro commented 2 years ago

PTAL @kgugala / @hzeller / @alaindargelas aka leaders in the SystemVerilog tooling space.

alaindargelas commented 2 years ago

After a couple of bug fixes, latest Surelog supports this core: https://github.com/chipsalliance/Surelog/blob/master/third_party/tests/Rp32/rp32.log To be noted:

kamilrakoczy commented 2 years ago

@jeras It looks like r5p_wbu module uses wbu_t typedef without including riscv_isa_pkg that defines it: https://github.com/jeras/rp32/blob/master/hdl/rtl/core/r5p_wbu.sv#L50 https://github.com/jeras/rp32/blob/master/hdl/rtl/riscv/riscv_isa_pkg.sv#L583