Cannot compile the CV32E40S model due to errors in testbench wrapper

[pcotret]

Bug Title

Cannot compile the CV32E40S model.

Type

Indicate whether the type of problem you found:

• Compile error (hopefully nobody has committed anything that doesn't compile!)

Steps to Reproduce

git clone https://github.com/openhwgroup/core-v-verif
cd core-v-verif/cv32e40s/sim/core 
export CV_CORE=cv32e40s 
export CV_SW_PREFIX=riscv32-unknown-elf-
export CV_SW_TOOLCHAIN=/opt/corev-openhw 
export PATH=/opt/corev-openhw/bin:$PATH
make

Generates this error:

%Error: /home/pascal/core-v-verif/core-v-cores/cv32e40s/rtl/cv32e40s_register_file_wrapper.sv:85:35: syntax error, unexpected ')', expecting "'{"
   85 |     assign rdata_o[i] = (rf_data_t)'(rf_rdata[i][REGFILE_DATA_WIDTH-1:0]);
      |                                   ^
%Error: Exiting due to 1 error(s)

I know this is a RTL error. Let's fix it locally as in the master branch and re-run make:

%Error-PINNOTFOUND: /home/pascal/core-v-verif/cv32e40s/tb/core/cv32e40s_tb_wrapper.sv:118:11: Pin not found: 'irq_ack_o'
  118 |          .irq_ack_o              ( irq_ack               ),
      |           ^~~~~~~~~
                    ... For error description see https://verilator.org/warn/PINNOTFOUND?v=5.006
%Error-PINNOTFOUND: /home/pascal/core-v-verif/cv32e40s/tb/core/cv32e40s_tb_wrapper.sv:119:11: Pin not found: 'irq_id_o'
                                                                                                                 : ... Suggested alternative: 'irq_i'
  119 |          .irq_id_o               ( irq_id_out            ),
      |           ^~~~~~~~
%Error: Exiting due to 2 error(s)

Refers to this part: https://github.com/openhwgroup/core-v-verif/blob/master/cv32e40s/tb/core/cv32e40s_tb_wrapper.sv#L117-L119

core-v-verif should clone this hash of the CV32E40S core: https://github.com/openhwgroup/cv32e40s/tree/103056f0deeac8e6cc10244c86bff83d3014f66f

It uses CLIC interface to play with interrupts: https://github.com/openhwgroup/cv32e40s/blob/103056f0deeac8e6cc10244c86bff83d3014f66f/rtl/cv32e40s_core.sv#L110-L118

Additional context

Steps to Reproduce worked with a CV32E40P, Verilator 5.006.

[pcotret]

openhwgroup/cv32e40s@a122cae

The first RTL issue has been fixed in April 2022 while the hash is from February 2022.
Maybe we could update the cv32e40s commit to something more recent ?

It should fix the interrupt interface signals as well.

[MikeOpenHWGroup]

Hi @pcotret, thanks for your interest in CORE-V-VERIF. Unfortunately, the CV32E40S "core" testbench does not support Verilator. The last time I attempted this, Verilator could not compile the RTL, and I see that may still be the case, so there was little point attempting to get the testbench up and running.

Having said that, it is possible that Verilator v5.x can support the RTL, so maybe it is time to try again.

The first thing to do is get the scriptware to fetch the most recent version of the RTL. To do that edit the value of CV_CORE_HASH in cv32e40s/sim/ExternalRepos.mk to select a more up-to-date version. As you probably know, the RTL is cloned to core-v-cores/cv32e40s, so you can manually checkout specific hashes there if you like). I am sure there will be a good deal of updating required to the testbench as well.

[pcotret]

We had a look at this today with a student. We have a Verilator model but the hello world example is stuck in a loop :

*******************************************************************************************
* Running with Verilator: logfile in simulation_results/hello-world/hello-world.log
*******************************************************************************************
mkdir -p cobj_dir/logs
simulation_results/hello-world/verilator_executable \
	 \
	"+firmware=../../tests/programs/custom/hello-world/hello-world.hex" \
	| tee cobj_dir/logs/hello-world.log
  scopesDump:
    SCOPE 0x7f528841e1c0: TOP.tb_top_verilator
    SCOPE 0x7f528841e1f8: TOP.tb_top_verilator.cv32e40s_tb_wrapper_i.ram_i
    SCOPE 0x7f528841e230: TOP.tb_top_verilator.cv32e40s_tb_wrapper_i.ram_i.dp_ram_i
       DPI-EXPORT 0x55db492d6e0c: read_byte
       DPI-EXPORT 0x55db492d6e19: write_byte

[tb_top_verilator] finished dumping memory
/*
Normally, we should have the hello world + a few registers here
*/

• RAM files aren't the same between the 40S and the 40P. Is there a reason for that ?
• Otherwise, we made a really simple testbench that is compatible with the 40S core. Maybe there's an issue with interrupt requests...

[MikeOpenHWGroup]

Thanks for working on this @pcotret.

RAM files aren't the same between the 40S and the 40P. Is there a reason for that ?

Nothing of consequence. I cleaned up some code replication in the 40P version (see the setup_transaction() function) and it appears that @silabs-hfegran made a few modifications to the 40S version. (That is a bit of a surprise since I was under the impression that SiLabs had no interest in supporting the core tb.)

Otherwise, we made a really simple testbench that is compatible with the 40S core. Maybe there's an issue with interrupt requests...

AFAIK, there has never been any attempt to exercise the interrupts or debug-requests in any of the core testbenches. To get started you may want to tie these off on the core inputs.