RTL Verification and Physical Device Verification

One of the great attractions of real device verification using FPGA is that it can verify the system (not the FPGA, but the entire device) at high speed, but it is not good at debugging by observing internal nodes when there is a problem.

Therefore, we recommend a verification style that eliminates major bugs at the RTL stage, where debugging efficiency is high (fixes and verifications are fast), and eliminates corner bugs during system verification using FPGAs.

SystemVerilog's verification capabilities not only improve verification efficiency at the RTL stage compared to traditional logic simulation techniques, but also reduce both design and verification efforts by increasing design reusability.

Improved verification efficiency with advanced verification methods

Verification man-hours are said to account for more than 60% of development man-hours.
It may not seem like much, but verification is not just the final system verification. Since the design work is a repetition of "small-scale design & verification", a lot of verification work is done during the design work. SystemVerilog is a state-of-the-art language that can handle logic and verification simultaneously.

Key verification features supported by SystemVerilog (requires compatible EDA tools).

Assertion-based verification

Automatic Constrained Random Testbench Generation

functional coverage

(1) Assertion-based verification (ABV)

Just like cracking down on drunk drivers at road checkpoints, the assertion system is designed to verify the movement of signals at key points within the circuit, or to set traps within the circuit to identify the cause of bugs. Base verification.

Define important movements as specifications (verification items), and automatically verify whether or not the specifications are violated. In normal logic simulation, the presence of bugs is not noticed until the erroneous signal due to the bug reaches the output pin, but assertion-based verification can find defects near the bug inside the circuit.

Not only can internal bugs that were difficult to find with conventional methods be found early, but it is also useful during failure analysis. By adding the traps that were effective in failure analysis to the internal design rules, the design level within the company gradually improved.

In fact, the ASIC industry has been using assertion-based verification in specialized tools and languages for decades. When we were expanding our IP lineup, defects were frequently discovered when IPs that had already been used in mass production were reused in other designs, and assertion-based verification helped improve the quality of design reuse such as IP. rice field. Since it is highly effective, we standardized the verification language that was different for each tool and incorporated it into SystemVerilog. Recently, assertion-based verification has become commonplace, and new products such as tools that efficiently generate testbenches and tools that perform static analysis without executing logic simulation are being released one after another.

SystemVerilog is very convenient because it allows you to define verification items (specifications) for dangerous locations and locations with poor visibility while logically designing. For example, constraints (traps) can be defined in the following places and automatically verified during logic simulation.

Locations where designers are likely to see malfunctions　

FIFO overflow/underflow, state machine interrupts, etc.

Places that experienced bugs in the past

Define constraints so that defects can be detected early from past bug experiences.

Input conditions for each block

Define the input signal conditions for each block as constraints.

It protects against errors in the next block due to bugs in the previous block.

Mentor Graphics' ModelSim ^® DE and Questa ^® Core/Prime/Ultra support this function.

Learn more about assertion-based verification here 

(2) Automatic generation of constrained random testbench

A testbench is required to perform assertion-based verification in (1) with logic simulation. Many of the testbenches created by circuit designers are not for detecting bugs, but for confirming that the circuit operates according to specifications, so the designer does not notice bugs caused by unintended behavior. The "Constrained random testbench automatic generation" function automatically generates and verifies a testbench that the designer does not expect, which is effective in detecting corner bugs. Also, you don't need to create expectations for output pins. Completely random patterns will produce spurious errors, so constrained test patterns can be generated. As for tools, Mentor Graphics Questa Prime/Ultra supports this function.

In addition, when the coverage approaches 100%, the same pattern increases, slowing down the improvement of the coverage rate and increasing the simulation time. doing.

(3) Functional coverage

It is a function to check the achievement rate of the function, how many times the part where the assertion constraint was defined was executed during the simulation. Use the random testbench to check how well the assertions are covered and use that as a guideline for the end of verification. Mentor Graphics' Questa Prime/Ultra supports this functional coverage, but even if the coverage rate is 100%, it would be troublesome if the points to be verified were omitted, so what should be verified and what should be excluded from verification Equipped with convenient functions for setting up verification scenarios.

(4) Static assertion-based verification

Dynamic assertion-based verification uses functional simulation, which requires creating testbenches and running functional simulations. Static assertion-based verification (formal verification) analyzes input signal combinations that fail from RTL logic and assertion constraints without the need to create testbenches or run functional simulations. Among tools, Questa CDC from Mentor Graphics supports this function.

(5) UVM (Universal Verification Methodology)

You can create your own assertions/constraints, but it becomes difficult to create large-scale circuits. Therefore, we have standardized (1) verification IP, (2) testbenches, user guides for verification methods, etc. created by verification specialists for SystemVerilog and released the sources free of charge. Click here for details 

SystemVerilog introduces object orientation and class handling, so you can use UVM to incorporate state-of-the-art verification techniques into your designs.

UVM's predecessor, OVM, has a Japanese user guide, so I think UVM will also support Japanese in the future.

Just as code coverage has become one of the criteria for design quality, it is said that in the future whether verification using UVM will be one of the criteria for design quality.

As for tools, Mentor Graphics Questa Prime/Ultra supports this function.

Introducing the concept of interfaces!

SystemVerilog supports popular interfaces in SystemC. In Verilog-HDL, connections between multiple modules were difficult to describe and error-prone, but in SystemVerilog, connections between modules can be defined independently using “interfaces”. This is convenient when reusing RTL because it can be handled by changing the interface part without changing the inside of the block. The tool supports all ModelSim products including the free ModelSim AE and Questa Core/Prime/Ultra products.

Easy interface with C language!

SystemVerilog makes it easier to write testbenches than Verilog-HDL, but it's still more convenient to use C language for complex descriptions.

Therefore, SystemVerilog supports DPI (Direct Program Interface), which simplifies interfacing with C language. DPI makes it easy to read C program functions from SystemVerilog and vice versa to call SystemVerilog functions from C programs. Unlike PLI supported by Verilog-HDL, it is easy to use and has less overhead in simulation speed. This function is useful for co-verification of software and hardware. The tool supports all ModelSim products including the free ModelSim AE and Questa Core/Prime/Ultra products.

To introduce an example of use, instead of simulating Nios ® II with RTL, the application is processed by the CPU on the PC, the Avalon ® bus and I/F, and the unfinished blocks of RTL are operated with C programs, and the existing RTL Some people run logic simulations mixed with blocks, programmatically generate complex testbenches, automatically match expected values with simulation results, and email summaries to their phones.

Many EDA tools support SystemVerilog!

No matter how good the language is, it cannot be used if the EDA tool does not support SystemVerilog. In that respect, EDA vendors took the lead in standardizing SystemVerilog, so each EDA vendor responded early. Also, for SystemC, etc., not only do you have to repurchase all tools such as lint checkers, synthesis tools, and simulations, but there are many tools that cannot be supported, such as emulators, but for SystemVerilog, many tools only have a Verilog-HDL license. can handle SystemVerilog. (However, the functions that Verilog-HDL does not have, such as assertion-based verification, automatic generation of constrained random testbench, and functional coverage, can only be handled by tools that support them.)

是非、皆さんも SystemVerilog を導入して、設計＆検証工数の削減にお役立てください。

Appeal of SystemVerilog 1 (Basics)