SystemVerilog 3.1 adds assertions and testbench automation

The complexity of SoCs and large ASICs has resulted in two major problems - enormous test space, and full chip testbench performance. The functional test space in SoCs is so large that it is impossible to cover it all in one testbench. It is even difficult to identify all test cases up front. Debug and reachability into all block level test cases is also very poor from a single full-chip testbench.

The simulation speed of full-chip testbenches for SoCs is now comparable to that of system level testbenches of a few years ago. With larger ASICs, performance is expected to get m uch worse. As a result, most SoC teams will shift, or have already shifted, to unit (block) level verification. With unit level verification a single ASIC can have 15-20 testbenches, one for each block in the ASIC, as well as full-chip and multi-chip testbenches. This can result in a testbench explosion.

To manage verification resources and reduce the impact of large number of testbenches, most SoC teams will need to have engineers do both verification and RTL design. An engineer designs a particular block and then verifies a different block. This allows an ASIC to be done without requiring an army of verification people. However, the schedule pressure has not changed, while the ASIC design and verification cycles have been greatly compressed.

The compression in the verification cycle has emphasized the need for testbench automation, which in turn has helped the emergence of verification specific languages such as Vera and e. While improving the verification flow and productivity for large ASICs, bot h approaches have added a burden for the ASIC engineer. Now an ASIC engineer has to know Verilog, Vera, Perl and C or a subset, or additional languages, and do it faster than ever before.

Stimulus generation has been automated somewhat but checkers and test grading still require a considerable amount of effort. In fact, result checkers are over 50 percent of the development work for random test oriented testbenches.

Assertion based design
The introduction of assertions into SystemVerilog allows designers to define design properties more concisely. These assertions can be used (in some cases) to verify smaller modules or sub-blocks, thus reducing some of the load on unit level testbenches.

Figure 2 shows the assertion based design flow. The designers derive safety properties (invariants) or liveness properties for sub-blocks or leaf modules from the micro-architecture and the specification. For example, a property might state that FIFO occupancy must never go beyond a certain threshol d. As these modules are instantiated, further properties are defined especially for interactions amongst the various sub-blocks.

Figure 2 - Assertion-based design flow

Let's take the example of an Ethernet MAC. Figure 3 shows the RTL and assertions hierarchy for an Ethernet MAC. There are assertions for the chip level interfaces as well unit level interfaces. SystemVerilog includes an interface construct, which allows you to incorporate the interface related assertions directly in the port definition itself. This promotes reuse and separates the interface assertions from the design block (which may have its own assertions).

There are also sub-unit interface level assertions as well as assertions within each of the sub-units. For example, in the RXC unit which implements the receive state machine, assertions can be used to make sure the FSM does not go into any invalid states.

Figure 3 - RTL and assertions hierarchy for an Ethernet MAC

These assertions can be used by static model checkers to verify sub-block level functionality, or used during simulation to identify errors. For model checkers they can be used to constrain the scope, to help alleviate the capacity problem, as well as to specify specific invariants that must hold true at all times.

Assertions and testbenches
SystemVerilog adds powerful data structures, classes, inter-process communication and randomization capabilities to Verilog. All these features facilitate development of automated testbenches. The additional data structures and classes allow testbenches to raise their level of abstraction and be transaction level accurate, rather than cycle accurate, which again greatly improves the productivity of the verification engineer.

The randomization capabilities allow implementation of random stimulus generators. Classes can be used to build powerful test specific constraint solvers to generate random stimulus. Inter-process communications and data structures facilitate implementation of sophisticated automated checkers especially for modeling the expected responses.

Assertions can be used in testbenches as monitors or for coverage analysis. It is especially useful for corner case analysis and test grading. In grading tests, you need to analyze the random stimulus generated and events that were triggered in the design under test (DUT).

In random testbenches, automatic result checkers form a significant portion of the development work. Assertions can replace cycle-accurate monitors on control logic or control interfaces. For data path logic, utilizing procedural checkers with assertions is the most effective. In general, assertions are most useful for verifying cycle accurate behavior in white box environments. Testbenches are more useful at higher levels of abstraction in a block box environments. But assertions and testbenches can be u sed together to verify designs.

Figure 4 shows a design and verification environment based on SystemVerilog for the Ethernet MAC.

Figure 4 - A SystemVerilog environment for Ethernet MAC

The assertions are shown in blue and can be used to identify specific conditions that are of interest. The testbench components are in green and are used to drive stimulus or check data path operation.

As figure 4 shows, the RTL, testbench and assertions are all written in System Verilog. Now both design and verification can be implemented with a single language. This will help with third party tools, especially when debugging an error. A single language with RTL, testbench and assertion capabilities will allow the design or verification roles to be merged into a single ASIC design and verification role. The complexity of today's ASICs is already forcing that, and with System Verilog this trend will accelerate.

In summary, SystemVerilog 3 .1 will provide significant enhancements to the Verilog language. These enhancements, when combined with good methodology, will significantly improve design and verification productivity. These capabilities, along with the expected shift in focus towards unit level verification, will enable the convergence of design and verification. Although the design and verification positions will not completely disappear, most of the demand will shift towards engineers who can do both verification and design.

Faisal Haque has over 18 years of design experience. He is currently at Cisco Systems involved in the design and verification of complex systems. He is the co-author of the best selling book "The Art of Verification with Vera" and is also the chair of Accellera's SystemVerilog Assertions Committee.