Feature: Verification
Figure 2: Opportunities for hardware Trojan insertions
Verifying safety, security and trust Some RISC-V cores are used in safety-critical applications with industry standards that require functional safety analysis and higher diagnostic coverage to meet certification requirements. The automotive market, governed by the ISO 26262 standard, demands a particularly rigorous development methodology. This requires using specific verification techniques and a well-defined, thorough verification process. What is needed is an automated functional safety analysis that enables higher diagnostic coverage. Whilst these requirements may not apply to a RISC-V processor core, they will arise at the SoC level for relevant application domains and DO-254 standards. Some applications for RISC-V have rigid security
requirements to prevent malicious agents exploiting vulnerabilities in the design. Effective hardware security to guard against adversary attacks requires innovation beyond traditional functional verification, which focuses on target use cases. Bugs that break these use cases are fixed, but bugs exposed in artificial use cases are often dismissed. Hardware bugs with software workaround may also remain in the design. These shortcuts are unacceptable when security is a concern. Security verification must include a rigorous process to detect all bugs and flaws, establishing precisely what can and can’t happen in the design. The development process for cores and SoCs is complex,
often involving multiple teams in multiple locations, with a mix of reused design components and third-party IP (3PIP) blocks such as RISC-V cores. There may be multiple opportunities for introduction of hardware Trojans or other malicious agents. The original specification might include issues that could lead to design errors or unintended and exploitable features. Problems may creep in during
46 September/October 2020
www.electronicsworld.co.uk
RTL synthesis, either by deliberate action or via the tools. Integration of 3PIPs presents extra risk since the SoC team does not know the details of those designs. Tool bugs or intentional netlist modifications can occur during the place-and-route (P&R) process. FPGA designs are especially vulnerable because of the extensive optimisations performed during synthesis/P&R and because changes may be made when generating the bitstream to program the device. A trusted design flow must ensure that no hardware
Trojans are inserted at any point; see Figure 2. Many applications, from autonomous vehicles and financial data servers to defence/aerospace and nuclear power plants, must be protected from Trojans since the consequences of adversary attacks could be severe.
Great potential RISC-V has great potential in the industry, but it must meet significant verification challenges to succeed against entrenched processor competition. This means verifying functional correctness, ensuring proper operation in safety- critical applications, checking that designs are secure and trusted, free of unintentional or deliberate vulnerabilities, and establishing proof of compliance to the ISA. SoC teams evaluating RISC-V cores should demand that their providers run complete integrity verification and document the results. This process must include automated code inspection, RISC-V verification and any other applicable formal method to prove functional correctness. Verification of safety, security and trust must also be performed when the requirements of the end application demand it. SoC teams should be able to re-run all these verification steps themselves as part of their acceptance criteria for RISC-V cores.
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
