INTRODUCTION
VERIFICATION
The behavioral coding features of Verilog (HDL), plus a few extras such as display statements and file I/O, gave Verilog-based hardware design engineers all they needed to both model hardware and to define a test bench to verify the model. As design sizes have increased, however, the amount of verification required has escalated dramatically. While writing the test bench and verification routines in pure Verilog HDL is still possible, the amount of coding far exceeds what can be accomplished in a reasonable amount of time. So along came proprietary Hardware Verification Languages (HVLs) such as VERA to the rescue. These languages specialized in giving verification engineers powerful constructs to describe stimulus and verify functionality in a much more concise manner. These proprietary languages solve a need, but at the costs of requiring engineers to learn and work with multiple languages, and often at the expense of simulation performance. Having different languages for the hardware modeling and the hardware verification has also become a barrier between those engineers doing the design work and those doing the verification. They don’t speak the same language.
The goal of hardware design is to create a device that performs a particular task, such as a DVD player, network router, or radar signal processor, based on a design specification. The purpose of a verification engineer is to make sure the device can accomplish that task successfully — that is, the design is an accurate representation of the specification.
The process of verification parallels the design creation process. A designer reads the hardware specification for a block, interprets the human language description, and creates the corresponding logic in a machine-readable form, usually RTL code.
A verification engineer, also reads the hardware specification, create the verification plan, and then follow it to build tests showing the RTL code correctly implements the features.
WHY SYSTEM VERILOG?
The SystemVerilog standard is currently being defined by Accellera, to provide Verilog designers with greater capability, at a faster pace. SystemVerilog is an extension to the Verilog language, which enables the modelling and verification of systems at a high level of abstraction. It adds a significant set of language enhancements on top of the Verilog 2001 standard, including features for high-level, abstract system modelling, testbench automation, and the integration of Verilog with the C programming language.SystemVerilog was created by the donation of the Superlog language to Accellera in 2002. The bulk of the verification functionality is based on the Openvera language donated by Synopsys. In 2005, SystemVerilog was adopted as IEEE Standard 1800-2005 .
The SystemVerilog standard is being released in multiple phases:
• SystemVerilog 3.0 standard, released in June 2002, added a large number of extensions to the Verilog-2001 HDL. These extensions primarily addressed the needs of hardware modeling for large, system-level designs and IP designs.
• SystemVerilog 3.1 primarily targets the needs of verification engineers, with another large set of extensions to the Verilog-2001 HDL. This release is planned for June 2003.
• SystemVerilog 3.2 will continue to extend Verilog modeling and verification capabilities, based on the evolving needs of design and verification engineers.
The combination of the Verilog-2001 standard and the SystemVerilog extensions creates a new breed of hardware language—an HDVL, or Hardware Description and Verification Language. Combining HDL and HVL capabilities into one language results in even greater capabilities than just the merging of the individual languages.
Types of Bugs
- At the block level
- At boundaries between blocks
- At the highest level (i.e the entire design)
