SystemVerilog is changing everything

Considering how complexity has grown over the last 20 years, it is amazing how few dramatic shifts in the design and verification methodology have occurred. When they do happen — mylar to layout tools, gates to RTL, hand-crafted test vectors to testbench automation — they make our work as engineers easier and enable us to tackle more challenging projects.

Today, we are undergoing another such dramatic shift, one enabled by the SystemVerilog language. It was developed through Accellera’s standardization process and is rapidly approaching ratification by the IEEE as the P1800 standard.

SystemVerilog is changing everything — design, verification, architectural modeling, the EDA industry, even the way standards are developed — and for the better.

Overview

SystemVerilog is the first hardware design and verification language (HDVL). It includes all the functionality of the design languages Verilog and VHDL, adding many additional features that make RTL code easier to write, understand and verify.

But SystemVerilog also subsumes verification languages such as OpenVera and e, supporting advanced techniques such as constrained- random stimulus generation, coverage-driven verification, and assertion-based verification (ABV).

Its assertion capabilities are especially impressive, providing much more than the simple VHDL assertion construct and eliminating the need for proprietary Verilog solutions.

It is important to stress that SystemVerilog was not developed in a vacuum. Every aspect of SystemVerilog was built upon proven features of existing languages (Figure 1).

• The language is based squarely on the time-proven features of Verilog and VHDL. The new design features were based primarily on SUPERLOG, a Verilog extension.
• The testbench features for verification were influenced strongly by OpenVera.
• The assertion constructs benefited from vast experience in formal property analysis and ABV using OpenVera Assertions and the ForSpec, Sugar and CBV property languages.

Figure 1. SystemVerilog sources and influences

Another point about SystemVerilog is that it is a standard. It was approved by Accellera, the standards body responsible for Verilog and VHDL, nearly a year ago. Accellera handed off the specification to the IEEE Standards Association, using the institute’s Corporate Standards Program, which aims to cut the time to ratify a standard from three or more years to a little over one year. Under the current schedule, SystemVerilog will have moved from Accellera to IEEE standard in only 15 months.

No standard becomes an industry’s first choice without a full supporting ‘ecosystem’. The news here about SystemVerilog is very positive. Several books have been published, and more than 50 vendors have pledged support for the language in their EDA tools, design and verification intellectual property, training courses, and consulting services. Language support is already available in tools used for simulation, synthesis, design analysis and formal verification.

SystemVerilog for design

Today’s designers must take more responsibility for the verification of RTL code, and the most important thing they can do is adopt a design-for-verification (DFV) methodology. Using assertions to document design intent is one well-established form of DFV.

SystemVerilog offers designers other types of help for DFV as well. One way to make code inherently more verifiable is through more advanced language features. This enables a faster and more concise design specification. Conciseness of expression is achieved through the addition of coding shortcuts from C, the simplification of port expressions, and the collation of related data.

Studies have shown that the number of bugs in a piece of software directly correlates to the number of lines of code. This also applies to hardware designed with RTL. Using constructs that reduce the number of lines necessary to describe functionality can reduce or eliminate pre- and post-tapeout problems.

Collating objects and their functionality in the form of object-oriented programming has been one of the biggest recent advances in software design. SystemVerilog makes this unification available for hardware, improving the specification process for a design by allowing related functionality to be described as a single object.

SystemVerilog also rectifies one of the biggest bugbears for Verilog designers — simulation-synthesis mismatches due to poorly specified case statements. The addition of unique and priority keywords, such as always_comb, always_latch, and always_ff, allows tools to verify that the designer’s assumptions and intent align with the synthesized design, reducing the likelihood of problems occurring in final simulations.

SystemVerilog for verification

Virtually every modern chip project requires more time and resources for verification than design, and the trend is toward verification consuming an even greater percentage of the development cycle.

Advanced techniques are required to prevent massive bottlenecks occurring. SystemVerilog has built-in support for three powerful options: constrained-random stimulus generation, assertion-based verification, and coverage-driven verification.

The need for random-based testing is clear: it is impractical to write enough directed (manual) tests for a large design. In addition to the unacceptable amount of time and people required, it is just too hard to think of all the possible corner cases.

Constrained-random stimulus generation is a powerful way of producing large volumes of legal tests for a design. The randomness exercises all areas of the design and can stimulate corner cases that would have been hard to hit with directed tests. The constraints ensure that the stimulus exercises a wide range of input values while keeping the design in legal state space during simulation.

Figure 2. Comparison of approaches to verification

As shown in Figure 2, the constrained-random approach delivers verification much faster and more predictably than directed tests. It does require a more sophisticated testbench setup, involving some verification coding prior to running the first test. From there, though, it is easy to vary parameters to generate more and more automatic constrained-random tests to exercise all areas of the design.

SystemVerilog provides numerous constructs, including rand, randc, randomize(), and randsequence (), to identify and control random values. A constraint can be defined in many ways, including simple Boolean expressions, iterations, and weighted distributions. The result is a very flexible set of techniques for generating and controlling random-based stimulus.

Even the most sophisticated constrained-random environment benefits from assertions running alongside in simulation. Especially in a large chip, assertions are very valuable for finding bugs at the source. Accurately identifying which design block is the source of a test failure saves a great deal of time in debugging the problem and turning it over to the correct designer for resolution.

SystemVerilog’s assert property construct makes it easy to specify arbitrarily complex assertions directly within the RTL code (typically by designers) or in separate files (typically by verification engineers). The ‘action block’ allows full flexibility for handling failing assertions. It is easy to alert the testbench so that an assertion failure results in a test failure, or even to stop the simulation entirely.

SystemVerilog assertions are ideal in formal property analysis as well as simulation. Formal analysis can target each assertion, trying to either prove it correct or find a ‘counter-example’ showing how it can fail, thereby revealing a corner-case design bug. The combination of assertion specification, assertions in simulation, and formal analysis enables a powerful and effective ABV approach.

Finally, coverage is at the root of verification. Some coverage metrics are always needed to assess verification progress, decide what to do next, and determine when the design is ready for tapeout. Their systematic use to guide every stage of the verification progress is often called coverage-driven verification, and this approach is very well supported by SystemVerilog.

The covergroup and coverpoint constructs allow easy definition of interesting design or testbench behavior that must be exercised for full verification. Cross-coverage (combinations of coverage points) can be defined with cross, and one can leverage the rich assertion syntax with the cover property statement.

SystemVerilog and SystemC

Some observers are under the impression that SystemVerilog and SystemC are in conflict.While there is certainly some overlap in terms of capabilities, in practice the two languages interact and co-exist well. The SystemVerilog Direct Programming Interface allows either language to call functions written in the other.

SystemC is most commonly used to write relatively high-level models for architectural exploration and electronic system-level modeling. It is easy to mix and match transaction-level or cycle-accurate SystemC models with more detailed SystemVerilog counterparts. This can enable the use of a single testbench from the architectural phase through RTL simulation and even gate-level simulation as well.

Conclusion

SystemVerilog is here, now. Standardization is in place, vendor support is stronger every day, and many chip development teams have already committed to the language.We no longer need to learn a new language for every step of design and verification; SystemVerilog provides a single solution that will serve our needs for many years to come.