Feature: Verification
SoC developers give little thought to re-verifying a licensed core, trusting the vendor to perform thorough verification of functional correctness, and other aspects of integrity
Verifying RISC-V SoCs
By Rob van Blommestein, Head of Marketing, OneSpin Solutions
T
he open RISC-V processor architecture is shaking up both worlds – that of intellectual property (IP) and system-on-chip (SoC). Tere’s much industry activity and interest, with RISC-V cores already finding their way in new designs. However, successful RISC-V core providers
must verify all aspects of integrity for those designs, including functional correctness, safety, security and trust. Core-level verification steps may need to be re-run, plus some additional tasks performed, to ensure that the cores have been integrated properly. Verification of RISC-V designs is especially challenging because of optional features, implementation flexibility and provisions for customer extensions.
44 September/October 2020
www.electronicsworld.co.uk
Verifying open-source cores Two industry associations have formed expressly to support RISC-V evolution and deployment. Many RISC-V cores and some of the SoCs built around them are available as open-source, with some of these already commercially available with soſtware titles ported into designs. It might seem that nothing can stop the ascension of this new Instruction Set Architecture (ISA), but no evolution happens without challenges. For RISC-V, one of the biggest questions is how to verify the integrity of the cores and the SoCs that contain them. Open source may mean easy access to cores, but how can their implementation be confirmed as correct and acceptable for designs? Te attraction of the new architecture is clear: anyone can
design anything based on RISC-V with no license fees or royalty payments, since the ISA is open and available to all. Further, implementations are available from many sources, enabling comparative evaluations by SoC teams and establishing a stronger position for negotiation if choosing a commercial solution. Tis is in sharp contrast to most established processor architectures, available only from a single vendor that controls the ISA and charges for its licensing. On the other hand, established processor families offer huge ecosystems and years of proven silicon. SoC developers give little thought to re-verifying a licensed core, trusting the vendor to perform thorough verification of functional correctness, and other aspects of integrity. To build a viable business, RISC-V core vendors must compete
successfully with the proven established options. Open-source implementations must be vetted so that SoC developers are comfortable integrating them into designs, which comes back to verification. Tere is no one central team designing and verifying RISC-V cores. For the RISC-V ecosystem to thrive, core suppliers need an independent verification solution to ensure that their designs are compatible with one another, free from bugs and compliant with the ISA specification. Similarly, SoC developers must ensure that the cores they license are fully verified and ISA compliant. For applications with safety, security and trust requirements, other aspects of design integrity are also critical,
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62 |
Page 63 |
Page 64 |
Page 65 |
Page 66 |
Page 67 |
Page 68
