Hardware Verification Language – an Introduction |
|
A hardware verification language, or HVL, is a programming language used to verify the designs of electronic circuits written in a hardware description language (HDL). HVLs typically include features of a high-level programming language like C++ or Java as well as features for easy bit-level manipulation similar to those found in HDLs. Many HVLs will provide constrained random stimulus generation, and functional coverage constructs to assist with complex hardware verification. If HDLs meant for designing, then HVLs meant to verify those HDL codes. Now to the question, why do we need HVLs? This is related to the software domain. As software became more and more complex, people moved from assembly to procedural languages like BASIC and C among others. However, writing and maintaining huge programs was still difficult. This was when people developed the object oriented programming paradigm. OOP is certainly a revolutionary development that has made it possible for computer programs to abstract a real world problem at unprecedented levels. It makes writing a program more efficient and also maintaining and expanding it. In normal practice we write HDL codes for our design and use Test Benches (also written in HDLs) to verify our designs. We have gate counts increasing every day, thus the challenge to verify them. In the past the verification was done with languages which were meant for designing. We created "testbenches" that applied predetermined stimuli to models of our designs and the generated outputs were compared with the expected outputs provided by the designers. This was possible since the digital circuits follow Boolean logic, their outputs can be predicted. It is possible to write a computer program which does this and this is exactly what happens in simulation. At those days verification environments were implemented in almost every programming language you can think of — C, Pascal, Verilog, scripts…. What could you do with these languages? You could, for example, write a long file with input (i.e. a list of CPU instructions) and inject them one by one into the device under test (DUT). The designs then were much smaller than they are today, so most engineers were happy with these testbenches. Years went by, designs got bigger and more complex, writing test benches with HDLs which are primarily meant for designing will not help in verifying your circuits with higher gate density, and the EDA industry realized that the old methodology of directed tests did not scale and that, for creating more sophisticated verification environments, a special language was needed. That’s why in today’s ASIC world they use different languages to verify your designs. Those are called HARDWARE VERIFICATION LANGUAGES (HVLs). Although some HDLs have a sort of HVL built-in. For example, VHDL has a number of language constructs that are not intended to be used in synthesis of hardware but can be used in a testbench to stimulate or analyze other code in simulation. However, HDLs like VHDL or Verilog were primarily targeted towards the RTL design and behavioral modeling. They were not really designed with the functional verification requirements in mind. In 1996, Specman was introduced to the public— at DAC 1996 in Las Vegas. This introduction was not simply of a new tool — it was the introduction of a new concept. Specman included e, and thus, with that introduction, the first Hardware Verification Language was born. In 2005, a new standard, SystemVerilog was created too. And now there are different verification languages available, among them, e, SystemVerilog, SystemC and OpenVera are the most commonly used HVLs. Basically they make use of object oriented programming (among other less important things) to write testbenches at a high level of abstraction thus making the verification process more robust and quicker. HVLs tend to be somewhat of a hybrid between HDL and scripting languages. Whereas HDLs are intended to be synthesizeable into a circuit, HVL is intended to be run as software, providing stimulus either to actual hardware or simulated hardware (from HDL) in order to verify correct functionality of the Hardware. With HVLs we apply the OOP technique into the domain of hardware verification. We do so by making it possible to verify a design at a higher level of abstraction. At the same time, they contain features that are especially adapter for verification, rather than to write synthesizable code. The use of standards based verification languages, such as SystemC and Sugar/PSL, provides designers access to key analytical functions such as transactions and assertions, which enable the validation of complex functional behavior. So, what should an HVL language contain? HVLs shall be able to provide 2 important features. These are concurrent assertions and constrained-random testing. Like assertion checks that an expression is true at a given time, a concurrent assertion checks to make sure that a sequence in which signal toggles is correct. Rather than having to write every single piece of stimulus that must be applied to a design under verification, constrained-random testing applies all possible stimulus that fits constraint given by the verification engineer, overtime. This saves a lot of time in writing stimulus. For interaction with RTL designs, HVLs should have a notion of time and some means to connect to the device under test. (In the early days of e, “tick access” was used; ports were added a few years later.) For creating interesting scenarios while minimizing manual work, the HVLs should have randomization capabilities, so that the long, directed input files can be replaced with short tests containing a small number of constraints. Engineers need more than a simple “randomize a value between 0 and 100.” Verification environments need to be able to define complex relations between fields, including fields of different structs. Generating the environment with a constraint solver saves lots of time when you are creating the tests. It also reduces the maintenance burden (adding one constraint, rather than changing hundreds of tests) and results in a more robust verification environment. Have you seen directed tests that are 10 years old, and nobody dares to modify them because nobody remembers what their purpose was at first place? But more than that, generating the environment was a part of a new (it was new in the 1990s) verification methodology – Coverage Driven Verification. According to CDV, you let the tools work for you. You define the protocol rules and the verification goals and run random tests. Every once in a while, you analyze the coverage reports and decide which constraints need be added to extend the generation to uncovered areas. Here below we briefly present some of the key features of the mainjor HVLs. SystemVerilog (1985 Gateway Design Automation / Cadence / Co-Design Automation / Synopsys / 2002 Accellera / IEEE) SystemVerilog, standardized as IEEE 1800, is a hardware description and hardware verification language used to model, design, simulate, test and implement electronic systems. SystemVerilog is based on Verilog and some extensions, and since 2008 Verilog is now part of the same IEEE standard. It is commonly used in the semiconductor and electronic design industry as an evolution of Verilog. SystemVerilog started with the donation of the Superlog language to Accellera in 2002 by the startup company Co-Design Automation. 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. In 2009, the standard was merged with the base Verilog (IEEE 1364-2005) standard, creating IEEE Standard 1800-2009. The current version is IEEE standard 1800-2017. The feature-set of SystemVerilog can be divided into two distinct roles: SystemVerilog language is a combination of concepts of multiple languages. SystemVerilog language components are,
e Hardware Verification Language (1996, Verisity / Cadence) Features Specman is provided as the tool/compiler/debugger to work with E language.
OpenVera (2001, Sun Micro Systems / Synopsys) Vera language was originally developed in Sun Micro Systems for internal ASIC verification projects. Later VERA language with VERA compiler was marketed by System Science. System Science later sold Vera to Synopsys. Synopsys released closed Vera language as OpenVera in 2001, which was later implemented in VCS as NTB. Currently OpenVera is supported by @hdl Simulator, and VCS Compiler. Later Synopsys donated parts of Vera language to Verilog to give Verilog unified design and Verification feature. This new language is called SystemVerilog. OpenVera is a hardware verification language intended to make modeling and testing of complex systems more efficient. It is part of an open source initiative, headed by Synopsys, that will benefit many industries where time to market is a critical factor. OpenVera is an interoperable, open hardware verification language for testbench creation. The OpenVera language was used as the basis for the advanced verification features in the IEEE Std. 1800 SystemVerilog standard, for the benefit of the entire verification community including companies in the semiconductor, systems, IP and EDA industries along with verification services.
SystemC (2000, Accellera/IEEE) SystemC is a set of C++ classes and macros which provide an event-driven simulation interface (see also discrete event simulation). These facilities enable a designer to simulate concurrent processes, each described using plain C++ syntax. SystemC processes can communicate in a simulated real-time environment, using signals of all the datatypes offered by C++, some additional ones offered by the SystemC library, as well as user defined. In certain respects, SystemC deliberately mimics the hardware description languages VHDL and Verilog, but is more aptly described as a system-level modeling language. SystemC is applied to system-level modeling, architectural exploration, performance modeling, software development, functional verification, and high-level synthesis. SystemC is often associated with electronic system-level (ESL) design, and with transaction-level modeling (TLM). SystemC is defined and promoted by the Open SystemC Initiative (OSCI — now Accellera), and has been approved by the IEEE Standards Association as IEEE 1666-2011 - the SystemC Language Reference Manual (LRM). The LRM provides the definitive statement of the semantics of SystemC. OSCI also provide an open-source proof-of-concept simulator (sometimes incorrectly referred to as the reference simulator), which can be downloaded from the OSCI website. Although it was the intent of OSCI that commercial vendors and academia could create original software compliant to IEEE 1666, in practice most SystemC implementations have been at least partly based on the OSCI proof-of-concept simulator. SystemC has semantic similarities to VHDL and Verilog, but may be said to have a syntactical overhead compared to these when used as a hardware description language. On the other hand, it offers a greater range of expression, similar to object-oriented design partitioning and template classes. Although strictly a C++ class library, SystemC is sometimes viewed as being a language in its own right. Source code can be compiled with the SystemC library (which includes a simulation kernel) to give an executable. The performance of the OSCI open-source implementation is typically less optimal than commercial VHDL/Verilog simulators when used for register transfer level simulation.
Property Specification Language (PSL/Sugar) (2004, Accellera / IEEE) Property Specification Language (PSL) is a temporal logic extending linear temporal logic with a range of operators for both ease of expression and enhancement of expressive power. PSL makes an extensive use of regular expressions and syntactic sugaring. It is widely used in the hardware design and verification industry, where formal verification tools (such as model checking) and/or logic simulation tools are used to prove or refute that a given PSL formula holds on a given design. PSL was initially developed by Accellera for specifying properties or assertions about hardware designs. Since September 2004 the standardization on the language has been done in IEEE 1850 working group. In September 2005, the IEEE 1850 Standard for Property Specification Language (PSL) was announced. Property Specification Language can be used with multiple electronic system design languages (HDLs) such as: VHDL (IEEE 1076) When PSL is used in conjunction with one of the above HDLs, its Boolean layer uses the operators of the respective HDL.
|
|
|
|