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.

Tools that support this feature include Siemens EDA's ^ModelSim® DE and ^Questa® Core/Prime/Ultra.

Learn more about assertion-based verification here 

(2) Automatic generation of constrained random testbench

A testbench is required to perform assertion-based verification (1) using logic simulation. Circuit designers often create testbenches to verify that the design functions as specified rather than to detect bugs, meaning bugs caused by unintended behavior go unnoticed. The "Constrained Random Testbench Automatic Generation" feature automatically and randomly generates and verifies testbenches that the designer did not anticipate, making it effective at detecting corner bugs. It also eliminates the need to create expected values for output pins. Since completely random patterns would result in false errors, constrained test patterns can be generated. Siemens EDA's Questa Prime/Ultra tools support this feature.

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

This function checks how many times the parts with defined assertion constraints were executed during simulation and checks the rate of functional achievement. It checks the extent to which assertions are covered using a random test bench and serves as a guide for when verification should end. Siemens EDA's Questa Prime/Ultra supports this function coverage, but even if the coverage rate is 100%, it can be problematic if points that should be verified are missed. Therefore, it has a convenient function for creating verification scenarios that determine what should be verified and what should be excluded from verification.

(4) Static assertion-based verification

Dynamic assertion-based verification uses logic simulation, so it is necessary to create a test bench and run logic simulations. Static assertion-based verification (formal verification) analyzes combinations of input signals that cause errors based on RTL logic and assertion constraints, so it does not require creating a test bench or running logic simulations. Questa CDC from Siemens EDA is a tool that 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.

Among the tools that support this feature are Siemens EDA's Questa Prime/Ultra.

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)