INTRODUCTION
As SoC developers adopt RISC-V and the design freedoms that an Open ISA (Instruction Set Architecture) offers, DV teams will need to address the new verification challenges of RISC-V based SoCs. The established SoC verifications tasks and methods are well proven, yet depend on the industry wide assumption of ‘known good processor IP’ based on the quality expectations associated with IP providers such as Arm or MIPS Technologies. However, the new DV challenges are not purely focused on the processor IP, since an Open ISA allows much greater design freedom whose impact extends well into the SoC itself.
With RISC-V there are possibly four new verification challenges to address for SoC projects:
- Verification of the RISC-V processor IP (including different source options)
- Verification of the Processing Element (PE) containing the RISC-V core(s) (especially relevant in SoCs with a fabric designed for AI processing)
- Connection of the processor itself or the PE to the network on chip (NoC)
- Multiple PEs communicating through the NoC to each other
For the processor core verification, three different scenarios exist: the processor IP (RTL) can be purchased from one of the many processor IP vendors in the RISC-V community, the processor IP can be downloaded from one of the open source repositories or the SoC developer can build the processor RTL from scratch. In the first two situations, there will have been a significant amount of verification performed on the processor IP; however, it is almost a certainty that the processor IP will have less verification and less maturity than a core from a traditional processor IP vendor. Also, if custom instructions are added to the core, no matter the source of the original RTL, the core needs to be thoroughly verified for both the new features and to confirm the original base core quality has not been compromised.
