Array
(
    [content] => 
    [params] => Array
        (
            [0] => /forum/index.php?threads/how-to-verify-complex-risc-v%E2%80%93based-designs.12686/
        )

    [addOns] => Array
        (
            [DL6/MLTP] => 13
            [Hampel/JobRunner] => 1030170
            [SV/ChangePostDate] => 2010200
            [SemiWiki/Newsletter] => 1000010
            [SemiWiki/WPMenu] => 1000010
            [SemiWiki/XPressExtend] => 1000010
            [ThemeHouse/XLink] => 1000670
            [ThemeHouse/XPress] => 1010394
            [XF] => 2011072
            [XFI] => 1030270
        )

    [wordpress] => /var/www/html
)

How to Verify Complex RISC-V–based Designs

Daniel Nenni

Admin
Staff member
Henderson, Nevada, USA – June 3rd, 2020 As RISC-V processor development matures and the core’s usage in SoCs and microcontrollers grows, engineering teams face new verification challenges related not to the RISC-V core itself but rather to the system based on or around it. Understandably, verification is just as complex and time consuming as it is for, say, an Arm processor-based project.

To date, industry verification efforts have focused on ISA compliance in order to standardize the RISC-V core. Now, the question appears to be, How do we handle verification as the system grows?

Clearly, the challenge scales with multiple cores and the addition of off-the-shelf peripherals and custom hardware modules.

We can see two verification challenges here. Firstly, we need to ensure the core is correct and ISA compliant and, secondly, we need to test the system using the core. In both cases, transaction-level, hardware emulation is the perfect choice — particularly if the emulation is based on the Accellera SCE-MI standard, which allows for reusability between different platforms and vendors. Combined with automatic design partitioning and wide debugging capabilities, this makes a complete verification platform.

When the processor core becomes more powerful and brings in more functionality, register transfer level (RTL) simulation is not enough. Nor does it provide complete test coverage in a reasonable time. With emulation, the speed of testing is much higher (in the MHz), which — combined with the cycle accuracy — allows us to increase the length and complexity of tests (that run quickly).

When using emulation, the core itself might be automatically compared with the RISC-V ISS golden model to confirm its accuracy and that it meets ISA compliance requirements. Figure 1 shows a RISC-V CPU under test.

The testbench used during simulation can be reused for emulation, so it is worth making sure the testbench is “emulation ready” even at the simulation stage. This will enable a smooth switch between simulator and emulator without developing a new testbench.

Figure 1. A RISC-V CPU under test


Figure 1. A RISC-V CPU under test. It is implemented in the emulator while RISC-V ISS is part of an advanced UVM testbench.

This strategy will also pay off in the case of adding custom instructions to the RISC-V (instructions intended to accelerate algorithms in the design) because, with hardware emulation, it is possible to test and benchmark these instructions against developed algorithms faster than in a pure simulation environment.

For the rest of this article, please visit EEtimes.com.
 
Top