Hardware Verification Language - Introduction
A Hardware Verification Language (HVL) is a programming language used to verify electronic circuit designs written in a Hardware Description Language (HDL). HVLs typically include features of high-level programming languages such as C++ or Java, as well as easy bit-level manipulation similar to that found in HDLs. Many HVLs will provide constrained random stimulus generation and functional coverage constructs to assist with complex hardware verification. If HDL means design, then HVL means verifying those HDL codes.
Now the question arises, why do we need HVL? This is related to the field of software. As software became more complex, people moved from assembly language to procedural languages like BASIC and C. However, writing and maintaining large programs was still difficult. This is when people developed the object-oriented programming paradigm. OOP was undoubtedly a revolutionary development that enabled computer programs to abstract real-world problems at an unprecedented level. It made writing programs more efficient and also allowed maintaining and extending it.
In common practice, we write HDL code for our designs and use testbenches (also written in HDL) to verify our designs. Our gate counts are increasing every day, so their verification becomes a serious challenge. In the past, verification was done using design languages. We created "testbenches" that applied predetermined inputs to our design models and compared the generated outputs with the expected outputs provided by the designers. This is possible because digital circuits follow Boolean logic and their outputs can be predicted. A computer program can be written to do this, and this is exactly what happens in simulation.
In those days, almost every programming language you can think of was used to implement verification environments - C, Pascal, Verilog, scripting languages, ... What could you do with these languages? For example, you could write a long file with inputs (i.e. a list of CPU instructions) and inject them one by one into the device under test (DUT). Designs were much smaller then than they are today, so most engineers were satisfied with these test benches.
A few years passed, designs became larger and more complex, testbenches written using HDLs primarily used for design would not help verify circuits with higher gate density, and the EDA industry realized that the old directed test approach could not scale and extend. To create a more complex verification environment, a special language was needed. That’s why in today’s ASIC world, they use different languages to verify your design. These are called Hardware Verification Languages (HVL).
Although some HDLs have a built-in HVL. For example, VHDL has many language constructs that are not intended for hardware synthesis but can be used in testbenches to stimulate or analyze other code in simulation. However, HDLs like VHDL or Verilog are primarily targeted at RTL design and behavioral modeling. They are not really designed with functional verification requirements in mind.
In 1996, Specman was introduced to the public at DAC 1996 in Las Vegas. This introduction was more than just a new tool - it was the introduction of a new concept. Specman included e, and thus, with this introduction, the first hardware verification language was born. In 2002, a new standard, SystemVerilog, was also created.
There are different verification languages available, among which e, SystemVerilog, SystemC and OpenVera are the most commonly used HVLs. Basically, they make use of object-oriented programming (and other less important things) to write test benches at a high level of abstraction, making the verification process more robust and faster.
HVL is somewhat of a hybrid of HDL and a scripting language. HDL is designed to be synthesizable into circuits, while HVL is designed to run as software to provide stimulus to real hardware or simulated hardware (from the HDL) to verify the correct functionality of the hardware.
With HVL, we apply OOP techniques to the world of hardware verification. We do this by making it possible to verify designs at a higher level of abstraction. At the same time, they contain features that are particularly suitable for verification, rather than writing synthesizable code.
Using standards-based verification languages such as SystemC and Sugar/PSL, designers can access key analysis capabilities such as transactions and assertions, enabling verification of complex functional behavior.
So, what should the HVL language contain?
There are 2 important features that an HVL should be able to provide. These are concurrent assertions and constrained random testing. Just as assertions check if an expression is true at a given time, concurrent assertions check to ensure that the order in which signals toggle is correct. Instead of having to write every single stimulus that must be applied to the design being verified, constrained random testing overtime applies all possible stimuli that meet the constraints given by the verification engineer. This saves a lot of time in writing the stimulus.
For interaction with the RTL design, the HVL should have a notion of timing and some means of connecting to the device under test. (In the early days of e, "tick access" was used; ports were added a few years later.)
To create interesting scenarios while minimizing manual work, HVL should have randomization capabilities so that 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 relationships between fields, including fields of different structures.
Using a constraint solver to generate the environment can save a lot of time when creating tests. It also reduces the maintenance burden (add one constraint instead of changing hundreds of tests) and produces a more robust verification environment. Have you ever seen 10-year-old directed tests that no one dared to modify because no one remembered what their original purpose was?
But more importantly, the build environment was part of a new (new in the 1990s) verification methodology - Coverage Driven Verification. According to CDV, you let the tools do the work for you. You define the protocol rules and verification goals and run random tests. Every once in a while, you analyze the coverage report and decide what constraints need to be added to extend the build to the uncovered areas.
Below we briefly introduce some key features of the main HVLs.
SystemVerilog (1985 Gateway Design Automation / Cadence / Co-Design Automation / Synopsys / 2002 Accellera / IEEE)
HILO-2/Occam parallel processing language -> Verilog / (1985) ->Superlog(1998) -> SystemVerilog(2002)
SystemVerilog, standardized as IEEE 1800, is a hardware description and hardware verification language used for modeling, design, simulation, testing, and implementation of electronic systems. SystemVerilog is based on Verilog with some extensions, and Verilog is now part of the same IEEE standard since 2008. As an evolution of Verilog, it is commonly used in the semiconductor and electronic design industries.
SystemVerilog began in 2002 when startup Co-Design Automation donated the Superlog language to Accellera. Much 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 to create 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 for register-transfer level (RTL) design is an extension of Verilog-2005; all the features of that language are available in SystemVerilog. Therefore, Verilog is a subset of SystemVerilog.
SystemVerilog for verification uses extensive object-oriented programming techniques and is more closely related to Java than to Verilog. These constructs are generally not synthesizable.
SystemVerilog language is a combination of several language concepts. SystemVerilog language components are,
Concepts of Verilog HDL
Vera-based test bench construction
OpenVera Assertions
Synopsys' VCS DirectC simulation interface for C and C++
Coverage API that provides links to coverage metrics
e Hardware Verification Language (1996, Verisity/Cadence)
Developer: Yoav Hollander of Verisity (an Israeli company later acquired by Cadence Design Systems)
Year of publication: In 1996 Design Automation Conference.
feature
Random and constrained random stimulus generation
Functional coverage metrics definition and collection
A temporal language that can be used to write assertions
Aspect-oriented programming language with reflection capabilities
Language is DUT neutral, because you can use a single e testbench to verify SystemC/C++ models, RTL models, gate-level models, and even DUTs residing in hardware acceleration boxes (using the UVM Acceleration for e approach)
Highly reusable code can be created, especially when the test bench is written according to the Universal Verification Methodology (UVM)
Specman is provided as a tool/compiler/debugger for working with the E language.
OpenVera (2001, Sun Micro Systems / Synopsys)
Replaced by SystemVerilog
Vera -> OpenVera -> SystemVerilog
OpenVera's predecessor was Vera.
The Vera language was originally developed at Sun Micro Systems for internal ASIC verification projects. The VERA language with the VERA compiler was later marketed by System Science. System Science later sold Vera to Synopsys. Synopsys released the closed Vera language as OpenVera in 2001, and later implemented it in VCS as NTB. Currently, OpenVera is supported by the @hdl Simulator and VCS Compiler.
Later, Synopsys donated part of the Vera language to Verilog to give Verilog unified design and verification capabilities. This new language is called SystemVerilog.
OpenVera is a hardware verification language designed to improve the efficiency of modeling and testing complex systems. It is part of an open source initiative led by Synopsys and will benefit many industries where time to market is a critical factor.
OpenVera is an interoperable, open hardware verification language for creating testbenches. The OpenVera language is used as the basis for advanced verification capabilities in the IEEE Std. 1800 SystemVerilog standard, benefiting the entire verification community, including companies in the semiconductor, system, IP, and EDA industries, as well as verification services.
SystemC (2000, Accellera/IEEE)
SystemC is a set of C++ classes and macros that provide an event-driven simulation interface (see also discrete-event simulation). These tools enable designers to simulate concurrent processes, each described using simple C++ syntax. SystemC processes can communicate in the simulated real-time environment, using signals of all the data types provided by C++, some additional signals provided by the SystemC library, and user-defined signals. In some respects, SystemC is deliberately modeled after the hardware description languages VHDL and Verilog, but is more properly described as a system-level modeling language.
SystemC is used for 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 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 - SystemC Language Reference Manual (LRM). The LRM provides an unambiguous statement of the semantics of SystemC. OSCI also provides an open source proof-of-concept simulator (sometimes incorrectly referred to as the reference simulator) that can be downloaded from the OSCI website. Although OSCI's intention is that commercial vendors and academia can create native software that complies with IEEE 1666, in practice most SystemC implementations are based at least in part on the OSCI proof-of-concept simulator.
SystemC has semantic similarities to VHDL and Verilog, but arguably has a syntactic overhead compared to these when used as a hardware description language. On the other hand, it provides a greater range of expressiveness, similar to object-oriented design partitioning and template classes. Although strictly a C++ class library, SystemC is sometimes considered a separate language. Source code can be compiled with the SystemC library (including simulation kernels) to provide an executable. When used for register transfer level simulation, the performance of the OSCI open source implementation is generally not as optimal as commercial VHDL/Verilog simulators.
Property Specification Language (PSL/Sugar) (2004, Accellera / IEEE)
Property Specification Language (PSL) is a temporal logic that extends linear temporal logic with a series of operators for ease of expression and increased expressiveness. PSL makes extensive use of regular expressions and syntax sugaring. It is widely used in the hardware design and verification industry, where formal verification tools (e.g., model checking) and/or logic simulation tools are used to prove or disprove that a given PSL formula is applicable to a given design.
PSL was originally developed by Accellera to specify properties or assertions about hardware designs. The IEEE 1850 working group has been standardizing the language since September 2004. In September 2005, the IEEE 1850 Property Specification Language Standard (PSL) was published.
The Property Specification Language can be used with a variety of electronic system design languages (HDLs), such as:
VHDL (IEEE 1076)
Verilog (IEEE 1364)
SystemVerilog (IEEE 1800)
SystemC (IEEE 1666) from the Open SystemC Initiative (OSCI).
When PSL is used in conjunction with one of the above HDLs, its Boolean layer uses the operators of the corresponding HDL.
提升卡
变色卡
千斤顶
京公网安备 11010802033920号
