Verify arm emulator operation verification#
When using a hardware emulator, we can test all RTL modules at higher speed with flexible debugging functions, but there is even more: an emulator host interface API (usually C/C++ based) allows us to connect the virtual platform used by the software team to create one integrated verification environment for the software and hardware domains of the project. The solution is, again, transaction-level emulation. How do we make sure those two worlds can work together and be synchronized while developing and testing the whole project? When the system grows with peripherals and custom modules, the software must support not only the RISC-V and its close surroundings (which can be modeled in software too) but also the rest of the hardware modules by providing operation system drivers, API, or high-level apps. Software teams usually start the development in isolation, using software ISS or virtual platforms/machines, which tend to be enough when there is no reliance on interacting with the new hardware. This means software and hardware engineering teams working on the same project with complex verification requirements and big challenges on the software-hardware interface. We need to remember though that SoC projects these days require not only hardware development but also complicated, multilayer software code. Such a methodology allows for long test sequences (UVM constrained random, for example) to build complicated test scenarios and accelerated SoC architecture benchmarking simulations in order to optimize the hardware structure and components. All SoC elements, including the RISC-V core, can be implemented in an emulator and verified with the same UVM or SystemC testbench used during the simulation. All can be implemented in the emulator and verified with the same universal verification methodology (UVM) or SystemC testbench used during the simulation. Thankfully, the same technique can be used for the verification of the other hardware elements of the SoC, custom hardware, and peripherals. Once the processor or CPU subsystem is checked, we can move on to verifying the whole system. 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.
Verify arm emulator operation simulator#
This will enable a smooth switch between simulator and emulator without developing a new testbench.
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. It is implemented in the emulator while RISC-V ISS is part of an advanced UVM testbench. 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. 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). Nor does it provide complete test coverage in a reasonable time. When the processor core becomes more powerful and brings in more functionality, register transfer level (RTL) simulation is not enough. Combined with automatic design partitioning and wide debugging capabilities, this makes a complete verification platform. 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. Firstly, we need to ensure the core is correct and ISA compliant and, secondly, we need to test the system using the core. We can see two verification challenges here. Now, the question appears to be, How do we handle verification as the system grows?Ĭlearly, the challenge scales with multiple cores and the addition of off-the-shelf peripherals and custom hardware modules. To date, industry verification efforts have focused on ISA compliance in order to standardize the RISC-V core. Understandably, verification is just as complex and time consuming as it is for, say, an Arm processor-based project. 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.
0 kommentar(er)
