openhwgroup
Updated CVA6 PA document
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).
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.
@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.
This "divide and conquer" approach was presented in Marseille and I felt there was consensus on it.
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.
After February 20th CVA6 meeting, we did not reach a consensus. The PR is withdrawn.
Reopening after we reached a consensus within CVA6 project. Let's see if the recent commits to the branch are seen here.
@fatimasaleem @JeanRochCoulon I have only added minor modifications to your version.
@jquevremont the TWG ballot succeeded. For that reason I'm merging this now and removing the do not merge label
