PR for adding Questa support for CVA6

[kasunb-accelr]

This PR contains the necessary updates to run Questasim (version: 2023.2) for CVA6.

[github-actions]

❌ failed run, report available here.

[MikeOpenHWGroup]

Hi @kasunb-accelr, thanks for this PR. Adding support for Questa would be a significant addition. Some of your suggested updates are significant, and we will need several people to review these. Before doing that, I would like to understand why this PR changes some of the submodules - why is this necessary?

Also, GitHub is reporting that This branch is out-of-date with the base branch. Please refactor your PR to the base branch.

[kasunb-accelr]

Hi @MikeOpenHWGroup, There is a small change in the core-v-verif submodule only.

[ASintzoff]

Could you propose a clean pull request without commits adding/removing debugging statements and white spaces?

[JeanRochCoulon]

Great. Can you rebase your PR?

[kasunb-accelr]

yes. I have rebased it. @JeanRochCoulon @ASintzoff
Thank you

[JeanRochCoulon]

Thanks @kasunb-accelr but the submodules do not seem updated: core-v-verif, hpdcache and ridcv-compliance.

As you can read on this page, the PR is "out-of-date"

[kasunb-accelr]

Hi guys @ASintzoff @JeanRochCoulon, I have submitted again can you guys recheck it? Thank you

[JeanRochCoulon]

The cva6 configuration called cv32a60x is deprecated. Please do not use it. Configurations called cv32a65x or imac_sv32 or imafc_sv32 are preferred.

[github-actions]

✔️ successful run, report available here.

[github-actions]

✔️ successful run, report available here.

[github-actions]

✔️ successful run, report available here.

[github-actions]

✔️ successful run, report available here.

[ASintzoff]

hello @AnouarZajni could you take a look at this PR as there are some modifications in the UVM testbench?

[JeanRochCoulon]

@kasunb-accelr This new questa-uvm is very promising. To maintain it over time, a CI job should be defined to use it. What do you think about adding in .gitlab-ci.yml the target in smoke job. In that way, the questa-uvm will be included in Thales CI, and all regression would be triggered.

[github-actions]

✔️ successful run, report available here.

[kasunb-accelr]

@JeanRochCoulon, I appreciate your feedback. I added "questa-uvm" to the .gitlab-ci.yml. I do not know if it is correct or not because I am new to this CI.

[github-actions]

❌ failed run, report available here.

[AnouarZajni]

Hi,
Seems that interface name/generate block name is missing suffix "i" to be able to set it individually in config dB

[kasunb-accelr]

Hi @AnouarZajni,
Thank you for your feedback. I think block names can be accessed using "i" automatically. Like following examples

for (genvar i = 0; i < RVFI_NRET; i++) begin  : rvfi_csr_if
      uvma_rvfi_csr_if#(uvme_cva6_pkg::XLEN)   rvfi_csr_if_inst (
        .clk            (clknrst_if.clk),
        .reset_n        (clknrst_if.reset_n),
        .rvfi_csr_rmask (rvfi_if.rvfi_o[i].mem_rmask),
        .rvfi_csr_wmask (rvfi_if.rvfi_o[i].mem_wmask),
        .rvfi_csr_rdata (rvfi_if.rvfi_o[i].mem_rdata),
        .rvfi_csr_wdata (rvfi_if.rvfi_o[i].mem_wdata)
      );
   end

for (int j = 3; j < 32; j++) begin
            uvm_config_db#(virtual uvma_rvfi_csr_if )::set(null,"*", $sformatf("csr_mhpmevent%0d_vif%0d", j, i),         rvfi_csr_if[i].rvfi_csr_if_inst);
end

Please let me know is it correct or not. or how to fix that issue?

[AnouarZajni]

Exact, but depending on the simulator the generate block will have different names. It's better to give an explicit name in generate block to be reused in uvm_config_db::set

[JeanRochCoulon]

The CI is failed, you can access the fail logs under https://riscv-ci.pages.thales-invia.fr/dashboard/