Cv32a65x-act4

[arshiarifat-10x]

This PR integrates the RISC-V Architectural Compatibility Test (ACT) v4.0 framework for the CV32A65x configuration of the CVA6 core, enabling architecture compliance test generation and execution within the CVA6 simulation environment.

[cainria]

Hi @arshiarifat-10x

Please add a description to this pull request so that we can understand the rationale of these changes and discuss them.

[JeanRochCoulon]

Hello @arshiarifat-10x
Thanks for your interest in cva6.
It would be useful to integrate your tests, or a part of them (depend on the duration), to the Github Actions CI. The scope is to prevent regression. Of course, to run on Github Actions, they should be executed with Verilator (possible?)

[arshiarifat-10x]

@JeanRochCoulon
I have integrated all the tests into the GitHub Actions CI using Verilator.
The current full regression takes approximately ~25 minutes to complete in CI. This is within a workable range, but if needed, we can later review the suite and discuss trimming specific tests to optimize runtime while preserving regression coverage.

[JeanRochCoulon]

As specified in CONTRIBUTING.md, can you give me the right to rebase your branch.

[arshiarifat-10x]

@JeanRochCoulon
Yes, I’ve enabled maintainer access for rebasing.

[cainria]

Shouldn't we add a README to document how to use this new testing framework?

[cainria]

I think this recipe should be moved to a new script file. What do you think about it?

[arshiarifat-10x]

Keeping the logic in the Makefile allows developers to see the entire execution flow( from address discovery to signature validation) in a single place without needing to track down external helper scripts.
As we integrate this into GitHub Actions, having a self-contained Makefile target ensures that the CI runner only needs to execute make certify. This avoids the overhead of managing absolute/relative pathing issues across different environments.

[arshiarifat-10x]

But if you suggest i can move this recipe to new script file. However, I am open to either approach. Would you prefer:
1- A clean separate script (e.g., verif/sim/run_certification.sh) with the Makefile target acting as a simple wrapper?
2- Keeping it in the Makefile to match the existing simulation target patterns in this repository?
Please let me know which direction aligns better with the project's long-term coding standards, and I will
update the PR accordingly.

[cainria]

We have a lot of scripts in verif/regress/, you might be interested in looking at these. Maybe verif/regress/ is a suitable place to add certify.sh?

For CVA6 designers, these scripts are our entry points to run most simulations: they call the relevant tools (cva6.py and make) for us.
So I think we do not need a Makefile wrapper as make it is not the user-facing entry to run simulations.

[arshiarifat-10x]

The current implementation is already aligned with the verif/regress/ flow, the wrapper is placed there intentionally and acts as a standard entry point, similar to existing scripts. It handles environment setup and then invokes the existing Makefile targets (gen and certify) under the hood.

From a user perspective, this keeps the interface consistent with other regression flows:

bash verif/regress/wrapper-cv32a65x-act.sh

So users are not expected to interact with the Makefile directly.

I’ll add a short README section to make the flow and entry point clearer.