Add Spike-specific extension option in cva6.py for issue #3249

[sjo99-kr]

This PR adds support for Spike-specific extension options in cva6.py, based on Issue #3249.

Current state

In cva6.py, the isa argument is currently shared across all ISS configurations and is also passed to the riscv-compiler (risc-gcc).
Because of this, when I try to compare traces between Spike and Verilator while working on Svadu, the current argument handling causes problems.

• Using --isa_extension applies the extension to both Spike and GCC, which leads to errors because the ISA string is shared.

• Using --spike_params is not sufficient either, because it does not update the Spike ISA/variant.

In my opinion, for robust verification of extensions to RVA23/RVB23, it is useful to configure Spike-specific ISA extensions independently from the compiler ISA.

--

What this PR changes

This PR updates the simulation framework in cva6.py by:

• adding a new argument, --spike_extension
• applying the provided extension only to the Spike ISA setup

- Using `--spike_extension` (what I modified), it accurately reflects the spike-specfici extensions to `variant` for Spike.

--

Why PR?

I'm working on Svadu extension to the CVA6 core in my local environment, but it is hard to verify my changes with this cva6.py framework for using Spike as a golden reference against Verilator.
It keeps triggering errors by sharing ISA between the compiler and Spike, making executing each step independently.
(It can be my fault, which I'm not familar with this CVA6 verification framework, but I tried my best....)

So I believe this makes it easier to use Spike as a golden reference for verification without affecting the GCC ISA configuration or other ISS settings.
And it is helpful to separate ISA for compiler (i.e., toolchain) and ISA for Spike for future RVA23/RVB23 extensions.

--
This modification may not be necessary for extensions that mainly affect the core pipeline, but it can be useful for extensions that affect architectural/MMU behavior than normal compiler-visible core extensions.

Thank you for reviewing this PR. If any concerns about the approach or the naming, please feel free to let me know :)

[cainria]

Hi, thanks for your contribution!

Here are a few formatting suggestions (spacing and diff reduction).
Maybe @valentinThomazic or @zchamski could review the changes in more depth?

[valentinThomazic]

Hi @sjo99-kr thank you for your contribution!
I am failing to understand how using spike_params to set the isa for spike is insufficient.
For instance, if I set the spike ISA to rv32i_xcvif_xdummyExt, spike will activate the cvxif extension and will try to enable dummyExt extension

CVXIF extension is used in the verification flow and is not specified to the compiler.
I am not familar with svadu extension so maybe I am missing something.

Could you explain a bit more on this part?
Thank you.

[sjo99-kr]

Hi! @valentinThomazic

Thank you for the detailed explanation 👍 !!

As I mentioned above, I am still not very familiar with the CVA6 verification framework, so my testing was based on my custom .yaml file through cva6.py.
This PR is also motivated by my experience with cva6.py, so its behavior may differ from directly using the Spike-related Makefile.

This is the baseline Makefile (in ~/verif/sim) code for Spike simulation with spike_params:

spike_params_final = $(spike_params)
ifneq ($(wildcard $(spike_yaml)),)
  spike_params_final := $(spike_params_final) --param-file $(spike_yaml)
  spike-yaml-plusarg = +config_file=$(spike_yaml)
  spike-yaml-makearg = config_file=$(spike_yaml)
else
  spike_params_final := $(spike_params_final) --extension=cvxif
endif

spike:
	LD_LIBRARY_PATH="$$(realpath ../../tools/spike/lib):$$LD_LIBRARY_PATH" \
		$(tool_path)/spike $(spike_stepout) $(spike_extension) --log-commits --isa=$(variant) --priv=$(priv) $(spike_params_final) -l $(elf)

The spike_params option is appended to the final Spike command line, so it can be used to pass additional Spike arguments such as --isa=... or --priv=....

However, it is different when you use cva6.py, not directly Makefile for verification :( .

--

In cva6.py based execution

I think the important difference appears when spike_params is used through cva6.py, rather than directly through the Makefile.

For example, when I run cva6.py for golden-reference checking,

python3 cva6.py --target cv64a6_imafdc_sv39 --iss=veri-testharness,spike --iss_yaml=cva6.yaml --testlist=../tests/testlist_Svade_Sv39.yaml --test L0_load_svadu_pass --gcc_opts="-I/root/cva6/verif/tests/riscv-arch-test/riscv-target/spike -Wl,--defsym=_start=0x80000000 -DXLEN=64 -DTEST_CASE_1=True" --spike_params=--isa=rv64gc_zba_zbb_zbs_zbc_zbkb_zbkx_zkne_zknd_zknh_svadu

The actual execute command is like this.

make spike steps=2000000 target=cv64a6_imafdc_sv39 variant=rv64gc_zba_zbb_zbs_zbc_zbkb_zbkx_zkne_zknd_zknh priv=msu elf=/root/cva6/verif/sim/out_2026-04-21/directed_tests/Svade_test.o tool_path=/root/cva6/tools/spike/bin log=/root/cva6/verif/sim/out_2026-04-21/spike_sim/L0_load_svadu_pass.cv64a6_imafdc_sv39.log spike_params='--param=--isa=rv64gc_zba_zbb_zbs_zbc_zbkb_zbkx_zkne_zknd_zknh_svadu' &> /root/cva6/verif/sim/out_2026-04-21/spike_sim/L0_load_svadu_pass.cv64a6_imafdc_sv39.log.iss

As you can see, the spike_params for Makefile is set up as "--param=--isa=rv64gc_zba_zbb_zbs_zbc_zbkb_zbkx_zkne_zknd_zknh_svadu", not just svadu.

--

Makefile-based execution

However, as you mentioned, when I run Spike directly through the Makefile like this:

make ~(same others) ~ spike_params='--isa=rv64gc_zba_zbb_zbs_zbc_zbkb_zbkx_zkne_zknd_zknh_svadu' ~

It works as same as your example!

--

Conclusion

From the examples above, I think the key point is that spike_params is handled differently in cva6.py and in direct Makefile-based execution.

So I believe there are two possible ways to solve this problem:

1. modify how cva6.py handles spike_params, (specifically in line 849~850), or
2. add a new option in cva6.py, as proposed in this PR.

This is the codes of line 849~850 in cva6.py

def get_full_spike_param_args(spike_params: list[str]):
  return ' '.join(list(map(lambda s: "--param=" + s, spike_params.split(','))))

Sorry for my imperfect English, and thank you for your patience.
I hope this clarifies what I meant.

Thanks :)

[valentinThomazic]

Hi @sjo99-kr, I now understand what you want to achieve.
Actually the feature is already implemented though undocumented (as far as I know) which is probably the real issue.
Simulations should be run using cva6.py, not the Makefile.

The spike_params argument refers to the parameters used by the modified version of spike that we use from https://github.com/openhwgroup/core-v-verif. They do not refer to the parameters of the spike binary.
These parameters are used to fine-tune the behavior of spike to adapt it to the CVA6 behavior, allowing us to verify it through co simulation.
The spike parameters can be passed either via command line, or a config file (see https://github.com/openhwgroup/cva6/blob/master/config/gen_from_riscv_config/cv32a60x/spike/spike.yaml for instance).

You should be able to pass --spike_params=/top/core/0/extensions:str=svadu (not using the ISA as I said earlier) to cva6.py and this should enable Svadu extension in Spike.
Could you try using this to see if this works for you?

I think it would be better to fix the current flow instead of adding another redundant functionality to cva6.py which is already rather complex

[sjo99-kr]

Sorry to bother you, @valentinThomazic .
I tried your suggestion using --spike_params=/top/core/0/extensions:str=svadu, but unfortunately it still does not work.

python3 cva6.py --target cv64a6_imafdc_sv39 --iss=veri-testharness,spike --iss_yaml=cva6.yaml --testlist=../tests/testlist_Svade_Sv39.yaml --test L0_load_svadu_pass --gcc_opts="-I/root/cva6/verif/tests/riscv-arch-test/riscv-target/spike -Wl,--defsym=_start=0x80000000 -DXLEN=64 -DTEST_CASE_1=True" --spike_params=/top/core/0/extensions:str=svadu

When I ran this, the commnd line shows

make spike steps=2000000 target=cv64a6_imafdc_sv39 variant=rv64gc_zba_zbb_zbs_zbc_zbkb_zbkx_zkne_zknd_zknh priv=msu elf=/root/cva6/verif/sim/out_2026-04-22/directed_tests/Svade_test.o tool_path=/root/cva6/tools/spike/bin log=/root/cva6/verif/sim/out_2026-04-22/spike_sim/L0_load_svadu_pass.cv64a6_imafdc_sv39.log spike_params='--param=/top/core/0/extensions:str=svadu' &> /root/cva6/verif/sim/out_2026-04-22/spike_sim/L0_load_svadu_pass.cv64a6_imafdc_sv39.log.iss

It seems that whatever I pass through spike_params gets automatically converted into the form --param=....
So I suspect the problem may be in lines 834–835 in cva6.py.

Please let me know if I am misunderstanding the intended usage, or if you would prefer that I investigate the current handling and propose a fix.

Thank you :)

[valentinThomazic]

Hi @sjo99-kr, For these kind of parameters, giving --param argument to spike is the expected behaviour (you can run spike -h to confirm it).
Could you take a log at the Spike log, to see if the parameter was taken into account?

[JeanRochCoulon]

BTW the plan is to replace cva6.py by a more convenient script within the next weeks... Saying that, does this PR is useful ?

[valentinThomazic]

@JeanRochCoulon the code would need to change but the feature in itself could still be discussed.
It is supposedly already supported by the current flow though.

[sjo99-kr]

Hi, @valentinThomazic . Thank you for the clarification!

I now understand that spike_params in cva6.py is intended for the modified Spike flow used in co-simulation, and I agree that fixing the current flow is better than adding another redundant option to cva6.py.

However, I tried running cva6.py with:

--spike_params=/top/core/0/extensions:str=svadu

but in the generated command it still becomes:

spike_params='--param=/top/core/0/extensions:str=svadu'

As I mentioned above response, this still does not enable Svadu in Spike in my test.

I attached two figures for comparison: one using the current PR code, and one using spike_params (in cva6.py) to enable Svadu in Spike.

In this case, the return-code error comes from my directed assembly test, which raises an error when hardware-based page-table updates are not supported. With the PR code, the same directed test passes.

If there are any missing points, please feel free to tell me.

Thank you.

[valentinThomazic]

Hi, taking a look at the spike log should be helpful to investigate the issue

[sjo99-kr]

Hi @valentinThomazic,

I'm sorry to bother you again, but I still think this cannot be handled with the current flow, at least for the cv64a6 target.

Here are the three issues what I'm still describing.

First, --spike_params in cva6.py seems to be passed to Spike as --param=....
However, this only works when the corresponding parameter tree exists, usually through a spike.yaml file passed with --param-file.

For cv64a6, I could not find a corresponding spike.yaml file under config/gen_from_riscv_config/<target>/spike/spike.yaml.
Therefore, the parameter node for extensions does not exist, and passing something like:

--param=/top/core/0/extensions:str=svadu

fails with:

** Could not get newly set parameter '/top/core/0/extensions' !!!

The figure comes from cva6/verif/sim/Makefile , showing the point that --spike_params= is handled.

Second, the fallback path uses --extension=cvxif, but according to spike -h, --extension=<name> is for RoCC/custom extensions.
Therefore, it does not seem to be the right mechanism for enabling privileged extensions such as Svadu.
For example, passing --extension=cvxif,svadu makes Spike look for a custom extension named literally cvxif,svadu, which fails.

Third, the fallback path reuslts --spike-params=<content> in cva6.py to --params=<content> in spike.
I guess the option of --params in spike is for setting specific parameters of hardware, not for privileged instruction extension.

In my local test, enabling Svadu through the ISA string works:

--isa=rv64gc_..._svadu

So I currently cannot find a way to enable Svadu for the cv64a6 target using only --spike_params in cva6.py.

Could you please let me know if I am missing something, or provide much more details about usage of --spike_params..?

Thanks.