[TASK] Enable heterogeneous CVA6 instantiations

[Jbalkind]

Is there an existing CVA6 task for this?

• I have searched the existing task issues

Task Description

We are interested in having multiple, heterogeneous instances of CVA6 in a single design. At present, the configuration mechanism doesn't support this well. As discussed during the CVA6 meeting, a number of us are interested in figuring out a mechanism that does support this use case.

My read of the situation is that the struct types are the biggest issue. If we passed around ariane_cfg_t with appropriate defaults (set via the configs) then I don't think there would be much trouble for things like XLEN when they are used within modules or even for port widths. The trouble I see is that the sizes of struct fields need to be set more globally in a way that is less compatible with the heterogeneity idea.

I've created this as a task but am looking more to stir up some brainstorming about how to resolve the issue. Hopefully that's appropriate if we actually come up with a solution and can use this task to track it.

Description of Done

The ability to instantiate multiple heterogeneous CVA6 cores without duplication of necessary files.

Associated PRs

No response

[JeanRochCoulon]

Hello @Jbalkind thank you to open this Github issue. Since a while we try to setup a strategy to configure easily CVA6. The stakeholders are (so far) @zarubaf, @cfuguet @Jbalkind @JeanRochCoulon and maybe @MikeOpenHWGroup .

To continue your intoduction, I would say that:

• I did not find so far a perfect solution.
• For some aspects I like Pass AXI parameters uniquely through the CVA6 parameters #1223, but the drawbacks I have identified are :
  - it makes CVA6 dependant from the module that instantiates it. Doing a synthesis without good CVA6 wrapper removes the AXI ports for instance. But by taking care of it, this can be solved.
  - If one day CVA6 is TRL5 (hope so!), we will declare CVA6 TRL5 only if called with good parameters. How to communicate it to the user? That's not so common. Usually module gets default parameters, as CV32E40, and that default version corresponds to the TRL5 version.
  - Today we focus on AXI configuration for heterogeneous instantiation. But I know users that would be pleased to instantiate one 32 and one 64 CVA6 in the same product. As verilog is not the best friend of the designer, two XLEN configurations cannot be declared. We could think about declaring XLEN as CVA6 input parameter? But as a lot of typedefs depend on XLEN, all typedef shoul dbe declared as input parameter, it will be a mess.

I get the problem in mind for a while. If someone can help me to find a solution, I would really pleased to offer him good drink(s) (wine for Mike, maybe beer for Florian) at Barcelona RISCV Summit. (If not, we can drink anyway).

[zarubaf]

Fully support that notion. Likely requires quite some changes in how we do the parameterization. Maybe we can discuss a staged plan where we start with the most important parameter(s) (I guess XLEN).

• it makes CVA6 dependant from the module that instantiates it. Doing a synthesis without good CVA6 wrapper removes the AXI ports for instance. But by taking care of it, this can be solved.

Having default AXI structs could solve this. Also a synthesis wrapper (which is quite a common technique) for stand-alone PPA synthesis could be used.

• If one day CVA6 is TRL5 (hope so!), we will declare CVA6 TRL5 only if called with good parameters. How to communicate it to the user? That's not so common. Usually module gets default parameters, as CV32E40, and that default version corresponds to the TRL5 version.

I think if we pack everything in a good configuration struct we could denote this as TRL5. Any other parameterization would be "at own risk".

FYI @domenicw

[cfuguet]

Yes, I agree with the approach mentioned by @zarubaf regarding parametrization.

1. Have a synthesis wrapper with default AXI parameters.
2. When we'll need to tag a version as TRL5, we mention which are the configurations fully verified. This shall be mentioned probably in the specification document.

[JeanRochCoulon]

The synthesis wrapper will not garanty that the configuration synthetized is aligned withe the configuration simulated. The RTL should be self-supporting (wrapper should not be needed, except if this wrapper is used to verify cva6, but it is not our case). The strategy is to define AXI in ariane_pkg as done for the ArianeCfg parameter. The default configuration for AXI will be aligned with cv32a60x which corresponds to the step1. Do you approve it ?

[cfuguet]

Yes, Ok for me.

[JeanRochCoulon]

Here is the status about parametrization. To go ahead, I need help.

1. Remove the instruction trace (instr_trace_if.sv, instr_tracer.sv), to keep only the RVFI tracer which has been identified as golden monitor. => need approval
   Remove instr_tracer and keep RVFI tracer #1265
2. Replace l15/axi ports by an unique noc as CVA6 ports => Need @florian @Jbalkind approval !
   merge axi and l15 ports into noc port #1267
   merge axi and l15 ports into noc port core-v-verif#1993
3. Condition RVFI port by parameter => Need @florian @Jbalkind approval !
   Define RVFI as CVA6 input parameter #1275
   Define RVFI as CVA6 input parameter core-v-verif#1998
4. Move wt_cache_pkg functions from wt_cache_pkg.sv to verilog files where it is used. We can observe that each function is used by only one module.
   Move wt_cache_pkg functions which depend on cva6 input paramaters #1274
5. Create cv6_config_t type to propagate the cva6 top parameters through the cva6 hierarchy
   declare cva6_cfg_t to pass the configuration through the hierarchy #1278
6. Move types depending from wt_cache_pkg.sv to cva6 top parameters
7. Implement AXI parameters as done in Add cva6_params hierachy to allow AXI (easier) configuration #1248
8. Move localparam depending on PLEN from wt_cache_pkg to cva6 top parameters
9. Move PLEN from riscv_pkg to cva6 top parameters