feat(cv32e40p): add CV32E40P ISS core model

[marpac3]

Summary

Add CV32E40P (PULP RI5CY) core model to the GVSOC ISS, enabling cycle-accurate simulation and DPI co-simulation with the CV32E40P UVM testbench.

What's included

• Core model (models/cpu/iss/include/cores/cv32e40p/): CSR subclassing, IRQ handling, exception model, privilege mode, register file — all behind #ifdef CONFIG_GVSOC_ISS_CV32E40P guards
• CoreV2 ISA handlers (corev.hpp): PULP custom instructions (hardware loops, post-increment load/store, SIMD, bit manipulation) unified for both ISS v1 and v2
• CSR implementation (csr_cv32e40p.cpp): Full CV32E40P CSR map with configurable write masks, reset values, and volatile flags driven by JSON config
• IRQ controller (irq_cv32e40p.cpp): PULP-style fast interrupt handling with 16 local interrupts
• Exit device (cv32e40p_exit_device.cpp): Memory-mapped exit device for standalone simulation
• Build system: CMakeLists.txt updates, ISA generator for CoreV2 encoding

Base class extensions (non-breaking)

Small extensions to csr.hpp, exception.hpp, irq_riscv.hpp, exec_inorder.cpp to support core-specific subclassing. All changes are backward-compatible — existing cores (snitch, ri5ky, ara) are unaffected.

Validation

• GVSOC standalone: 5 config variants tested (default, PULP, FPU, ZFINX, PULP+FPU+ZFINX)
• DPI co-simulation: 39/43 test×config pairs PASS against CV32E40P RTL (Questa 2025.3)
• Upstream build: make build TARGETS=rv64 passes without regressions

Related PRs

• gvsoc-pulp: CV32E40P platform definition and core config (to be linked)

[haugoug]

Hi Marco,
thanks a lot for your contribution !
It seems you used co-simulation to do fine-grain comparison with RTL, can you give more details ?

[marpac3]

Hi Germain!
Yes I'm using GVSOC as an ISS to use it in the cv32e40p testbench (this is the docs of the current TB to get the idea, it uses a proprietary ISS (ImperasDV) https://docs.openhwgroup.org/projects/core-v-verif/en/latest/cv32_env.html)

The idea is to have a full model of the cv32e40p in GVSOC, so inside the testbench, at each instruction retire of bot the RTL and the GVSOC implementation, PC, GPRs and CSRs are compared.

I opened the PR since the model, GVSOC side, is stable enough. It does follow this openHW docmentaion (https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/cv32e40p_v1.8.3/intro.html).
I will add more stuff for the GVSOC "testbench"part, maybe I'll map more Virtual Peripherals to completely recreate the TB that is used in the cv32e40p project.

[haugoug]

Nice thanks !

[haugoug]

There are lots of modifications in the generic part of the ISS. Unfortunately, this ISS is still used for some old targets for which I don't have access to the tests anymore.
Could you please surround all the modifications in the generic part with ifdef ?
There are a few new files with my name, it's better if you put yours :)
Could you also put the exit device in the pulp repo ? I try to put only generic devices in this repo.

[marpac3]

Branch refreshed — ready for review @haugoug

The branch has been refactored and force-pushed. Head is now c03a77f5 (9 commits on top of 81298676 "Fix to build correctly on Mac OS").

Commit history (linear, cleaned)

c03a77f5 doc: drop residual internal markers from ISS comments
945fb065 fix(iss): guard target-specific code paths in shared ISS sources
09f27f9e doc(iss): clean up comments and author headers
74fb5918 fix(iss): restore CV32E40P isolation + mcountinhibit RO default
e3b10d6a fix(iss/cv32e40p): hwloop immediate target encoding — word offset
020b8051 refactor(iss/cv32e40p): use config fields for simple per-target masks
c2de42ff refactor(iss): move CV32E40P specifics out of shared ISS files
635cf8c2 refactor(devices): move cv32e40p_exit to gvsoc-pulp
11cafde1 feat(cv32e40p): add CV32E40P ISS core model

Each commit is atomic, has a focused subject, and a short generic body without internal jargon.

Cross-target safety

The 4 cross-template call sites that touch shared headers (rv32i.hpp, csr.cpp, exec_inorder.cpp) are gated with #ifdef CONFIG_GVSOC_ISS_CV32E40P — verified against origin/master (commit 81298676) that no virtual hook call is left unguarded for the other targets.

Upstream make all cross-target build: ISA generators for RV64 / Snitch / Spatz (32+64) / CVA6 (with vector) / PULP FC / PULP cluster / FlexFloat all compile clean. Only pre-existing fail is pulp/redmule/include/config.h _Float16 (unrelated to this PR — same fail in origin/master).

Related PRs

• gvsoc/gvsoc-pulp#74 — companion: standalone platform, exit device, core config (head d52f70c).
• gvsoc/gvsoc#252 — submodule pointer bump (head 86e2e87).

Suggested merge order: this PR first, then #74, then #252 (after submodule pointers are re-pointed to upstream).

Happy to address any feedback.

[marpac3]

Hi @haugoug I have reviewd and modified most of the files, at least I have cleaned up commetns, added a few ifguard and restructured the code a bit.

There are a few part of the shared code which have been modified, but every single of them is commented and explained on how the modification of the sahred code does not affects the functionality of GVSOC.

I cannot be really sure obviusly, I have build other targets with make all in GVSOC to check if nothing else was having problems, and it looked like it. But let me know if i can do other checks that you know to validate that this PR does not break anything!

[haugoug]

Unfortunately I don't have access anymore to part of the tests, so I just prefer to have zero modification in the generic. There are still modifications, can you guard them as well ?
Also what is the purpose of memory_config.hpp ?

[marpac3]

memory_config.hpp was an unused leftover, it's gone. All the CV32E40P changes
in the shared sources are now guarded by CONFIG_GVSOC_ISS_CV32E40P — without
the define they preprocess back to the upstream sources, byte for byte.
Force-pushed with a cleaned-up history; diff vs the previous state:
https://github.com/marpac3/gvsoc-core/compare/c03a77f5b680..22216971a572