Question about how this env fetches the RTL

[MikeOpenHWGroup]

In this repo, the RTL is fetched as a recursive cloning operation, that is, git clone --recursive git@github.com:openhwgroup/cvfpu-uvm. That is a normal practise. However, the CVFPU is not cloned directly as a submodule of this repo. Rather, entire CVA6 is cloned as a submodule of this repo and the CVFPU is cloned as a submodule of the CVA6 repo.

This means that the CVA6 repo, not this repo controls the version of the CVFPU that we are verifying.

Is the above correct?

[IhsaneTahir]

Hi @MikeOpenHWGroup,

Yes, your understanding is correct. This means that if a fix or modification is made directly to the CVFPU repository, this verification environment cannot pick it up until CVA6 bumps its own CVFPU submodule to a commit that includes that change.

The version of CVA6 used in the environment is controlled through Bender by pinning specific commit hashes in Bender.yaml

dependencies:
  cva6        : { git: "https://github.com/openhwgroup/cva6.git", rev: 3868a61} # branch master
  core-v-verif: { git: "https://github.com/openhwgroup/core-v-verif.git", rev: 13a6c80} # branch master

Therefore, to retrieve any updates to CVA6, such as a bump to its CVFPU submodule, the CVA6 commit hash in Bender.yaml must be manually updated to a revision that includes those changes.

[MikeOpenHWGroup]

I am not comfortable with this. This repo is the verification environment for CVFPU, it should not be dependent upon the CVA6 repo. I am aware that the instantiation wrapper of the CVFPU used in this environment is adopted from the CVA6 - that is fine. Whether that wrapper module is copied from the CVA6 or integrated as a submodule is something we can discuss. But the RTL (CVFPU) we are verifying must come from the openhwgroup/cvfpu repo directly.

[IhsaneTahir]

I agree, I will add cvfpu as a direct submodule of this repo so that the RTL being verified comes directly from openhwgroup/cvfpu.

However, even after that change, a dependency on CVA6 will remain due to the following:

• ariane_pkg, which defines types used in the DUT ports
• The CVA6 configuration packages used to parametrize the DUT
• fpu_wrap

One option would be to copy these files locally into this repo, but that would mean any upstream modifications to those files in CVA6 would need to be manually tracked and updated.

My preference would be to keep CVA6 as a submodule for now to avoid that maintenance burden, but I am open to the local copy approach if that is preferred. What would you recommend?

[MikeOpenHWGroup]

OK, I created #8 to track a task to update the usage of the cvfpu submodule.

As far as the package files are concerned, I do have a preference, but will not impose my view on the majority. @rgiunti, @JeanRochCoulon, @ASintzoff and @khandelwaltanuj what are your thoughts? The question before us is should the testbench for the CVFPU directly use a specific CVA6 package from the CVA6 repo to configure the FPU, or should it use a local copy?

[khandelwaltanuj]

Hi @MikeOpenHWGroup

If CVFPU is seen as an IP independent of CVA6 and which can be ported to any RISCV processor, I would suggest, it to have a local copy.

Regards
Tanuj

[IhsaneTahir]

To provide more context for the decision, here is a breakdown of the concrete CVA6 dependency.
The DUT is fpu_wrap, instantiated as follows:

fpu_wrap # (
    .CVA6Cfg     ( CVA6Cfg     ),
    .fu_data_t   ( fu_data_t   ),
    .exception_t ( exception_t )
) dut (
    .clk_i  ( clk   ),
    .rst_ni ( rst_n ),
    ...
);

The CVA6 dependency stems from the two parameters, CVA6Cfg and fu_data_t, which pull in the following files:

• For CVA6Cfg: config_pkg.sv, build_config_pkg.sv and cv64a60ax_config_pkg_cvfpu-uvm.sv
• For fu_data_t: riscv_pkg.sv and ariane_pkg.sv

So in addition to fpu_wrap.sv itself, these five files would need to be copied locally to fully decouple from the CVA6 submodule.

[MikeOpenHWGroup]

In the CV32E40P, the cv32e40p_fp_wrapper.sv uses fpnew_pkg.sv which eliminates all dependancies on CV32E40P-specific packages. How much effort would it be to do something similar for the this environment?

[IhsaneTahir]

Actually it seems that cv32e40p_fp_wrapper.sv uses two cv32e40p-specific packages cv32e40p_pkg.sv and cv32e40p_apu_core_pkg.sv imported lines 40 and 15 respectively.