Feature: Embedded design
Figure 1: The RISC-V Verification Interface (RVVI)
The RVVI A processor verification plan needs to specify all the design features and establish the metrics for completion, typically with test suites and coverage targets. While RISC-V processor cores may differ significantly in features and implementations, since they are based on the same RISC-V specification some similarities can be leveraged in the verification methods and infrastructure. This enables the efficiency and reuse of verification IP and infrastructure from project to project, instead of the inefficiencies from time-consuming and error-prone bespoke approaches. The RISC-V Verification Interface
(RVVI) addresses the key interfaces for a RISC-V processor testbench with three open standards: • Test bench interface to the DUT (RISC-V core RTL): RVVI-TRACE;
• Test bench to the reference model: RVVI-API;
• Peripheral interfaces to the DUT: RVVI-VVP. Figure 1 shows the components
that form an RVVI-compliant processor verification environment, with key interfaces being the DUT to the testbench (RVVI-TRACE), the testbench to the RISC-V verification IP
Figure 2: RISC-V verification with ‘Lock-Step-Compare’ and asynchronous events
(RVVI-API), and the virtual peripheral interfaces to the core (RVVI-VVP). Not shown in the diagram are test suites and the output of test generators that are processed with a software toolchain for forming input test programs/ stimulus. Finally, the asynchronous events
are generated and recorded with a reproducible control process, to support both the coverage analysis and the debug process if discrepancies arise.
RISC-V processor verification For a simple processor with a modest verification requirement, it may be possible to use a logfile compare flow. In this setup, the same input stimulus is applied to both the reference model and the DUT, and the results are
captured in log files. A post-simulation comparison helps to identify areas of potential discrepancies for analysis. However, this approach has several
drawbacks: it does not help the debug analysis, the logfiles can become large, and any simulation after the point of first failure can be wasteful of time and resources. Yet, the biggest disadvantage is the inability to align asynchronous events between the DUT and reference, since they are running at different levels of abstraction – the reference model being instruction-accurate and the DUT being RTL-cycle-accurate. The latest RISC-V processor
verification methodologies are based on a Lock-Step-Compare co-simulation flow, as shown in Figure 2. The DUT and reference model are run synchronously,
www.electronicsworld.co.uk May 2023 19
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
