As regular readers know, Agnisys is the leader in specification automation. From various forms of executable design specifications, we generate the SystemVerilog RTL design, Universal Verification Methodology (UVM) testbench models for simulation, assertions for formal analysis, C/C++ code for embedded processors, sequences for both UVM and C/C++ and user documentation. The designers incorporate the RTL code into their chip, the verification engineers use the UVM models, sequences, and assertions to verify the RTL design, and the embedded programming team uses the C/C++ code as a starting point for their firmware and drivers.
Ultimately, we need to validate the system by running the hardware and production software together. Ideally, this validation occurs using an emulator or an FPGA prototype before the tapeout, to avoid any unexpected issues when the software is executed on the fabricated chip in the bring-up lab. However, there exists an intermediate step between hardware verification and system validation, often referred to as system-level verification or early validation, which is crucial for complex system-on-chip (SoC) designs. At this stage, the verification team runs both a UVM testbench and embedded C/C++ test code together in simulation.
I’d like to address system-level verification today and show how we can automate this process from your chip specifications. I’m going to focus on registers because they’re universal in SoCs and central to their operation, and on the sequences used to access, program, and test the registers from both the UVM testbench and the embedded software. There are many challenges associated with traditional system verification of registers and sequences, including:
An ever-growing number of registers for more functionality and configurability
Duplication of effort across design, verification, firmware, and validation teams
Tests are manually written for different types of verification and validation platforms
Mismatches between specification and implementation, lead to bugs in the design
Unclear or poorly documented sequence descriptions
Inability to measure the quality of the verification and validation performed (coverage)
Difficulty in checking the functional correctness of the transaction (scoreboard)
To ensure that these challenges are addressed, we help users create a golden specification for design, verification, firmware, validation, and documentation. We automatically generate a complete system-level verification and validation environment as well as implementation-level sequences that span both UVM testbenches and C/C++ embedded test programs. The registers are specified in our IDS NextGen (IDS-NG) intuitive graphical environment. If you have an existing register specification in text form, for example using the SystemRDL standard, you can import that easily. IDS-NG also generates SystemRDL and numerous other formats as output.
For hardware verification and for the UVM portion of system verification, we generate all components needed for a complete UVM testbench. These include bus agents, drivers, adaptors, sequencers, and sequences, as well as the Makefiles for all major simulators. The sequences we generate guarantee 100% functional coverage, as measured by register-focused cover groups, right from the start. This pushbutton approach and the inherent UVM features provide the best way to adopt a coverage-driven verification methodology for your design.
When IDS-NG generates C/C++ tests and they are run on a processor model in simulation, maintaining 100% coverage requires synchronization of the tests with the UVM sequences. Examples of generated C/C++ tests include:
Random value test
Walking 1 tests
Write/read 0s and 1s tests
Special software register access test
Tests for special registers (lock, shadow, alias, etc.)
In most cases, users will run these tests on their own model of the chosen CPU for their SoC. If this model is not yet available, users can still run synchronized UVM-C/C++ tests out of the box. Our solution includes the open-source SweRV EH1 RISC-V processor core from Western Digital for this purpose. We also ship with Zephyr, an open-source real-time operating system (RTOS), so that users can run applications in the simulation environment. The tests are built using an application programming interface (API) library for register access supplied as part of our IDS-NG solution.
Users may wish to write their own test sequences to supplement those we generate. The API is flexible enough to support custom sequences, but you do not have to learn the details. Instead, IDS-NG includes an intuitive graphical interface for sequence specification using abstract commands such as “read” and “write”. Users can easily specify the register programming and test sequences, and then automatically generate tests ready to use in UVM testbenches, embedded processor simulation models, and the actual silicon in the bring-up lab. Sequences can also be exported for use in automatic test equipment (ATE) during chip manufacturing.
Of course, the verification and validation teams need to know how much coverage is provided by the sequences, and we provide these metrics. The standard register model defined by the UVM standard includes default coverage types, including fields, bits, and address-map. Users can determine the type of coverage code to generate for any specific register or block. IDS-NG automatically generates the coverage code for all the registers in the design. The coverage results are gathered during test simulation and the results are reported to the users.
In this post, I’ve hit on only a few key points of how we support thorough and fully automated system-level verification of all your registers, including many special types. There’s much more to say about how IDS-NG synchronizes UVM and C/C++, handles interrupts, supports debugging, and more. You can view the detailed webinar “IDS-NG for System Verification” here to learn much more about how we improve your verification productivity and quickly achieve 100% coverage closure out of the box.