search

openhwgroup / programs

Documentation for the OpenHW Group's set of CORE-V RISC-V cores
Other
186 stars 97 forks source link

Updated CVA6 PA document #650

Closed jquevremont closed 2 months ago

jquevremont commented 5 months ago

A new PA gate is needed as the CVA6 project evolves to address more TRL5 configurations. Sub-projects will be created to handle the verification of the various configurations. Reviews from all CVA6 contributors are welcome (although I only designate 1 reviewer to avoid clogging GitHub).

ASintzoff commented 5 months ago

I'm wondering if splitting the verification work in multiple sub-projects would be an efficient way to proceed. Such split will introduce the risk of fragmentation if managed by several projects.

As the CVA6 design is managed as a unique entity, I'm not sure it is useful to have a different organization for verification.

Currently, a lot of the verification work is not configuration specific (e.g. Spike, test generation with riscv-dv/corev-dv). And for the part which is configuration specific, the same UVM code is used by all configurations. For instance, the ISACOV part of the verification.

Instead of having sub-projects, I would prefer to have verification inside the CVA6 project as we have done until now. This will reduce the risk of redundant work.

It would be great to have @MikeOpenHWGroup opinion.

MikeOpenHWGroup commented 5 months ago

@ASintzoff said:

Instead of having sub-projects, I would prefer to have verification inside the CVA6 project as we have done until now. This will reduce the risk of redundant work.

In general, I agree with this approach. It assumes that a team exists that will continue to administer the CVA6 project as a whole, independent of the various products (e.g. CV64A65X, etc.) that may be derived from it. Up to now, this team has been Thales TRT and TSS. We should organize the CVA6 project such that this role could be transferred in the future should Thales no longer be interested/able to fulfill this role (hopefully they will continue for years to come!).

Assuming people agree with this strategy we should take some time to define it a little more rigorously. It is not clear that this PR should be gated by that discussion.

jquevremont commented 5 months ago

This "divide and conquer" approach was presented in Marseille and I felt there was consensus on it.

JeanRochCoulon commented 5 months ago

So far the verification is done by one team, on one configuration, with generic verification strategy. As discussed before the workshop, I am not yet convinced to divide the verification between different subprojects. As only one configuration is under verification, we do not worth deciding Today. Delaying the 65X subproject definition would be better. We could take the decision with the second verification team.

jquevremont commented 4 months ago

After February 20th CVA6 meeting, we did not reach a consensus. The PR is withdrawn.

jquevremont commented 4 months ago

Reopening after we reached a consensus within CVA6 project. Let's see if the recent commits to the branch are seen here.

jquevremont commented 4 months ago

@fatimasaleem @JeanRochCoulon I have only added minor modifications to your version.

DBees commented 2 months ago

@jquevremont the TWG ballot succeeded. For that reason I'm merging this now and removing the do not merge label