SystemVerilog

Last updated

SystemVerilog
Paradigm Structured (design)
Object-oriented (verification)
Designed by Synopsys, later IEEE
First appeared2002;22 years ago (2002)
Stable release
IEEE 1800-2023 / December 16, 2023;5 months ago (2023-12-16)
Typing discipline Static, weak
Filename extensions .sv, .svh
Influenced by
Design: Verilog, VHDL, C++, Verification: OpenVera, Java

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.

Contents

History

SystemVerilog started with the donation of the Superlog language to Accellera in 2002 by the startup company Co-Design Automation. [1] 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. [2] In 2009, the standard was merged with the base Verilog (IEEE 1364-2005) standard, creating IEEE Standard 1800-2009.

The SystemVerilog standard was subsequently updated in 2012, [3] 2017, [4] and most recently in December 2023. [5]

Design features

The feature-set of SystemVerilog can be divided into two distinct roles:

  1. SystemVerilog for register-transfer level (RTL) design is an extension of Verilog-2005; all features of that language are available in SystemVerilog. Therefore, Verilog is a subset of SystemVerilog.
  2. SystemVerilog for verification uses extensive object-oriented programming techniques and is more closely related to Java than Verilog. These constructs are generally not synthesizable.

The remainder of this article discusses the features of SystemVerilog not present in Verilog-2005.

Data lifetime

There are two types of data lifetime specified in SystemVerilog: static and automatic. Automatic variables are created the moment program execution comes to the scope of the variable. Static variables are created at the start of the program's execution and keep the same value during the entire program's lifespan, unless assigned a new value during execution.

Any variable that is declared inside a task or function without specifying type will be considered automatic. To specify that a variable is static place the "static" keyword in the declaration before the type, e.g., "static int x;". The "automatic" keyword is used in the same way.

New data types

Enhanced variable types add new capability to Verilog's "reg" type:

logic[31:0]my_var;

Verilog-1995 and -2001 limit reg variables to behavioral statements such as RTL code. SystemVerilog extends the reg type so it can be driven by a single driver such as gate or module. SystemVerilog names this type "logic" to remind users that it has this extra capability and is not a hardware register. The names "logic" and "reg" are interchangeable. A signal with more than one driver (such as a tri-state buffer for general-purpose input/output) needs to be declared a net type such as "wire" so SystemVerilog can resolve the final value.

Multidimensional packed arrays unify and extend Verilog's notion of "registers" and "memories":

logic[1:0][2:0]my_pack[32];

Classical Verilog permitted only one dimension to be declared to the left of the variable name. SystemVerilog permits any number of such "packed" dimensions. A variable of packed array type maps 1:1 onto an integer arithmetic quantity. In the example above, each element of my_pack may be used in expressions as a six-bit integer. The dimensions to the right of the name (32 in this case) are referred to as "unpacked" dimensions. As in Verilog-2001, any number of unpacked dimensions is permitted.

Enumerated data types (enums) allow numeric quantities to be assigned meaningful names. Variables declared to be of enumerated type cannot be assigned to variables of a different enumerated type without casting. This is not true of parameters, which were the preferred implementation technique for enumerated quantities in Verilog-2005:

typedefenumlogic[2:0]{RED,GREEN,BLUE,CYAN,MAGENTA,YELLOW}color_t;color_tmy_color=GREEN;initial$display("The color is %s",my_color.name());

As shown above, the designer can specify an underlying arithmetic type (logic [2:0] in this case) which is used to represent the enumeration value. The meta-values X and Z can be used here, possibly to represent illegal states. The built-in function name() returns an ASCII string for the current enumerated value, which is useful in validation and testing.

New integer types: SystemVerilog defines byte, shortint, int and longint as two-state signed integral types having 8, 16, 32, and 64 bits respectively. A bit type is a variable-width two-state type that works much like logic. Two-state types lack the X and Z metavalues of classical Verilog; working with these types may result in faster simulation.

Structures and unions work much like they do in the C programming language. SystemVerilog enhancements include the packed attribute and the tagged attribute. The tagged attribute allows runtime tracking of which member(s) of a union are currently in use. The packed attribute causes the structure or union to be mapped 1:1 onto a packed array of bits. The contents of struct data types occupy a continuous block of memory with no gaps, similar to bitfields in C and C++:

typedefstructpacked{bit[10:0]expo;bitsign;bit[51:0]mant;}FP;FPzero=64'b0;

As shown in this example, SystemVerilog also supports typedefs, as in C and C++.

Procedural blocks

SystemVerilog introduces three new procedural blocks intended to model hardware: always_comb (to model combinational logic), always_ff (for flip-flops), and always_latch (for latches). Whereas Verilog used a single, general-purpose always block to model different types of hardware structures, each of SystemVerilog's new blocks is intended to model a specific type of hardware, by imposing semantic restrictions to ensure that hardware described by the blocks matches the intended usage of the model. An HDL compiler or verification program can take extra steps to ensure that only the intended type of behavior occurs.

An always_comb block models combinational logic. The simulator infers the sensitivity list to be all variables from the contained statements:

always_combbegintmp=b*b-4*a*c;no_root=(tmp<0);end

An always_latch block models level-sensitive latches. Again, the sensitivity list is inferred from the code:

always_latchif(en)q<=d;

An always_ff block models synchronous logic (especially edge-sensitive sequential logic):

always_ff@(posedgeclk)count<=count+1;

Electronic design automation (EDA) tools can verify the design's intent by checking that the hardware model does not violate any block usage semantics. For example, the new blocks restrict assignment to a variable by allowing only one source, whereas Verilog's always block permitted assignment from multiple procedural sources.

Interfaces

For small designs, the Verilog port compactly describes a module's connectivity with the surrounding environment. But major blocks within a large design hierarchy typically possess port counts in the thousands. SystemVerilog introduces concept of interfaces to both reduce the redundancy of port-name declarations between connected modules, as well as group and abstract related signals into a user-declared bundle. An additional concept is modport, which shows the direction of logic connections.

Example:

interfaceintf;logica;logicb;modportin(inputa,outputb);modportout(inputb,outputa);endinterfacemoduletop;intfi();u_am1(.i1(i.in));u_bm2(.i2(i.out));endmodulemoduleu_a(intf.ini1);endmodulemoduleu_b(intf.outi2);endmodule

Verification features

The following verification features are typically not synthesizable, meaning they cannot be implemented in hardware based on HDL code. Instead, they assist in the creation of extensible, flexible test benches.

New data types

The string data type represents a variable-length text string. For example:

strings1="Hello";strings2="world";stringp=".?!";strings3={s1,", ",s2,p[2]};// string concatenation$display("[%d] %s",s3.len(),s3);// simulation will print: "[13] Hello, world!"

In addition to the static array used in design, SystemVerilog offers dynamic arrays, associative arrays and queues:

intcmdline_elements;// # elements for dynamic arrayintda[];// dynamic arrayintai[int];// associative array, indexed by intintas[string];// associative array, indexed by stringintqa[$];// queue, indexed as an array, or by built-in methodsinitialbegincmdline_elements=16;da=new[cmdline_elements];// Allocate array with 16 elementsend

A dynamic array works much like an unpacked array, but offers the advantage of being dynamically allocated at runtime (as shown above.) Whereas a packed array's size must be known at compile time (from a constant or expression of constants), the dynamic array size can be initialized from another runtime variable, allowing the array to be sized and resize arbitrarily as needed.

An associative array can be thought of as a binary search tree with a user-specified key type and data type. The key implies an ordering; the elements of an associative array can be read out in lexicographic order. Finally, a queue provides much of the functionality of the C++ STL deque type: elements can be added and removed from either end efficiently. These primitives allow the creation of complex data structures required for scoreboarding a large design.

Classes

SystemVerilog provides an object-oriented programming model.

In SystemVerilog, classes support a single-inheritance model, but may implement functionality similar to multiple-inheritance through the use of so-called "interface classes" (identical in concept to the interface feature of Java). Classes can be parameterized by type, providing the basic function of C++ templates. However, template specialization and function templates are not supported.

SystemVerilog's polymorphism features are similar to those of C++: the programmer may specifically write a virtual function to have a derived class gain control of the function. See virtual function for further information.

Encapsulation and data hiding is accomplished using the local and protected keywords, which must be applied to any item that is to be hidden. By default, all class properties are public.

Class instances are dynamically created with the new keyword. A constructor denoted by function new can be defined. SystemVerilog has automatic garbage collection, so there is no language facility to explicitly destroy instances created by the new operator.

Example:

virtualclassMemory;virtualfunctionbit[31:0]read(bit[31:0]addr);endfunctionvirtualfunctionvoidwrite(bit[31:0]addr,bit[31:0]data);endfunctionendclassclassSRAM#(parameterAWIDTH=10)extendsMemory;bit[31:0]mem[1<<AWIDTH];virtualfunctionbit[31:0]read(bit[31:0]addr);returnmem[addr];endfunctionvirtualfunctionvoidwrite(bit[31:0]addr,bit[31:0]data);mem[addr]=data;endfunctionendclass

Constrained random generation

Integer quantities, defined either in a class definition or as stand-alone variables in some lexical scope, can be assigned random values based on a set of constraints. This feature is useful for creating randomized scenarios for verification.

Within class definitions, the rand and randc modifiers signal variables that are to undergo randomization. randc specifies permutation-based randomization, where a variable will take on all possible values once before any value is repeated. Variables without modifiers are not randomized.

classeth_frame;randbit[47:0]dest;randbit[47:0]src;randbit[15:0]f_type;randbytepayload[];bit[31:0]fcs;randbit[31:0]fcs_corrupt;constraintbasic{payload.sizeinside{[46:1500]};}constraintgood_fr{fcs_corrupt==0;}endclass

In this example, the fcs field is not randomized; in practice it will be computed with a CRC generator, and the fcs_corrupt field used to corrupt it to inject FCS errors. The two constraints shown are applicable to conforming Ethernet frames. Constraints may be selectively enabled; this feature would be required in the example above to generate corrupt frames. Constraints may be arbitrarily complex, involving interrelationships among variables, implications, and iteration. The SystemVerilog constraint solver is required to find a solution if one exists, but makes no guarantees as to the time it will require to do so as this is in general an NP-hard problem (boolean satisfiability).

Randomization methods

In each SystemVerilog class there are 3 predefined methods for randomization: pre_randomize, randomize and post_randomize. The randomize method is called by the user for randomization of the class variables. The pre_randomize method is called by the randomize method before the randomization and the post_randomize method is called by the randomize method after randomization.

classeth_frame;randbit[47:0]dest;randbit[47:0]src;randbit[15:0]f_type;randbytepayload[];bit[31:0]fcs;randbitcorrupted_frame;constraintbasic{payload.sizeinside{[46:1500]};}functionvoidpost_randomize()this.calculate_fcs();// update the fcs field according to the randomized frameif(corrupted_frame)// if this frame should be corrupted this.corrupt_fcs();// corrupt the fcsendfunctionendclass

Controlling constraints

The constraint_mode() and the random_mode() methods are used to control the randomization. constraint_mode() is used to turn a specific constraint on and off and the random_mode is used to turn a randomization of a specific variable on or off. The below code describes and procedurally tests an Ethernet frame:

classeth_frame;randbit[47:0]dest;randbit[47:0]src;randbit[15:0]f_type;randbytepayload[];bit[31:0]fcs;randbitcorrupted_frame;constraintbasic{payload.sizeinside{[46:1500]};}constraintone_src_cst{src==48'h1f00}constraintdist_to_fcs{fcsdist{0:/30,[1:2500]:/50};// 30, and 50 are the weights (30/80 or  50/80, in this example) }endclass...eth_framemy_frame;my_frame.one_src_cst.constraint_mode(0);// the constraint one_src_cst will not be taken into accountmy_frame.f_type.random_mode(0);// the f_type variable will not be randomized for this frame instance.my_frame.randomize();

Assertions

Assertions are useful for verifying properties of a design that manifest themselves after a specific condition or state is reached. SystemVerilog has its own assertion specification language, similar to Property Specification Language. The subset of SystemVerilog language constructs that serves assertion is commonly called SystemVerilog Assertion or SVA. [6]

SystemVerilog assertions are built from sequences and properties. Properties are a superset of sequences; any sequence may be used as if it were a property, although this is not typically useful.

Sequences consist of boolean expressions augmented with temporal operators. The simplest temporal operator is the ## operator which performs a concatenation:[ clarification needed ]

sequenceS1;@(posedgeclk)req##1gnt;endsequence

This sequence matches if the gnt signal goes high one clock cycle after req goes high. Note that all sequence operations are synchronous to a clock.

Other sequential operators include repetition operators, as well as various conjunctions. These operators allow the designer to express complex relationships among design components.

An assertion works by continually attempting to evaluate a sequence or property. An assertion fails if the property fails. The sequence above will fail whenever req is low. To accurately express the requirement that gnt follow req a property is required:

propertyreq_gnt;@(posedgeclk)req|=>gnt;endpropertyassert_req_gnt:assertproperty(req_gnt)else$error("req not followed by gnt.");

This example shows an implication operator |=>. The clause to the left of the implication is called the antecedent and the clause to the right is called the consequent . Evaluation of an implication starts through repeated attempts to evaluate the antecedent. When the antecedent succeeds, the consequent is attempted, and the success of the assertion depends on the success of the consequent. In this example, the consequent won't be attempted until req goes high, after which the property will fail if gnt is not high on the following clock.

In addition to assertions, SystemVerilog supports assumptions and coverage of properties. An assumption establishes a condition that a formal logic proving tool must assume to be true. An assertion specifies a property that must be proven true. In simulation, both assertions and assumptions are verified against test stimuli. Property coverage allows the verification engineer to verify that assertions are accurately monitoring the design.[ vague ]

Coverage

Coverage as applied to hardware verification languages refers to the collection of statistics based on sampling events within the simulation. Coverage is used to determine when the device under test (DUT) has been exposed to a sufficient variety of stimuli that there is a high confidence that the DUT is functioning correctly. Note that this differs from code coverage which instruments the design code to ensure that all lines of code in the design have been executed. Functional coverage ensures that all desired corner and edge cases in the design space have been explored.

A SystemVerilog coverage group creates a database of "bins" that store a histogram of values of an associated variable. Cross-coverage can also be defined, which creates a histogram representing the Cartesian product of multiple variables.

A sampling event controls when a sample is taken. The sampling event can be a Verilog event, the entry or exit of a block of code, or a call to the sample method of the coverage group. Care is required to ensure that data are sampled only when meaningful.

For example:

classeth_frame;// Definitions as abovecovergroupcov;coverpointdest{binsbcast[1]={48'hFFFFFFFFFFFF};binsucast[1]=default;}coverpointf_type{binslength[16]={[0:1535]};binstyped[16]={[1536:32767]};binsother[1]=default;}psize:coverpointpayload.size{binssize[]={46,[47:63],64,[65:511],[512:1023],[1024:1499],1500};}sz_x_t:crossf_type,psize;endgroupendclass

In this example, the verification engineer is interested in the distribution of broadcast and unicast frames, the size/f_type field and the payload size. The ranges in the payload size coverpoint reflect the interesting corner cases, including minimum and maximum size frames.

Synchronization

A complex test environment consists of reusable verification components that must communicate with one another. Verilog's 'event' primitive allowed different blocks of procedural statements to trigger each other, but enforcing thread synchronization was up to the programmer's (clever) usage. SystemVerilog offers two primitives specifically for interthread synchronization: mailbox and semaphore . The mailbox is modeled as a FIFO message queue. Optionally, the FIFO can be type-parameterized so that only objects of the specified type may be passed through it. Typically, objects are class instances representing transactions : elementary operations (for example, sending a frame) that are executed by the verification components. The semaphore is modeled as a counting semaphore.

General improvements to classical Verilog

In addition to the new features above, SystemVerilog enhances the usability of Verilog's existing language features. The following are some of these enhancements:

Besides this, SystemVerilog allows convenient interface to foreign languages (like C/C++), by SystemVerilog DPI (Direct Programming Interface).

Verification and synthesis software

In the design verification role, SystemVerilog is widely used in the chip-design industry. The three largest EDA vendors (Cadence Design Systems, Mentor Graphics, Synopsys) have incorporated SystemVerilog into their mixed-language HDL simulators. Although no simulator can yet claim support for the entire SystemVerilog Language Reference Manual, making testbench interoperability a challenge, efforts to promote cross-vendor compatibility are underway.[ when? ] In 2008, Cadence and Mentor released the Open Verification Methodology, an open-source class-library and usage-framework to facilitate the development of re-usable testbenches and canned verification-IP. Synopsys, which had been the first to publish a SystemVerilog class-library (VMM), subsequently responded by opening its proprietary VMM to the general public. Many third-party providers have announced or already released SystemVerilog verification IP.

In the design synthesis role (transformation of a hardware-design description into a gate-netlist), SystemVerilog adoption has been slow. Many design teams use design flows which involve multiple tools from different vendors. Most design teams cannot migrate to SystemVerilog RTL-design until their entire front-end tool suite (linters, formal verification and automated test structure generators) support a common language subset.[ needs update? ]

See also

Related Research Articles

<span class="mw-page-title-main">VHDL</span> Hardware description language

VHDL is a hardware description language that can model the behavior and structure of digital systems at multiple levels of abstraction, ranging from the system level down to that of logic gates, for design entry, documentation, and verification purposes. The language was developed for the US military VHSIC program in the 1980s, and has been standardized by the Institute of Electrical and Electronics Engineers (IEEE) as IEEE Std 1076; the latest version of which is IEEE Std 1076-2019. To model analog and mixed-signal systems, an IEEE-standardized HDL based on VHDL called VHDL-AMS has been developed.

Verilog, standardized as IEEE 1364, is a hardware description language (HDL) used to model electronic systems. It is most commonly used in the design and verification of digital circuits at the register-transfer level of abstraction. It is also used in the verification of analog circuits and mixed-signal circuits, as well as in the design of genetic circuits. In 2009, the Verilog standard was merged into the SystemVerilog standard, creating IEEE Standard 1800-2009. Since then, Verilog has been officially part of the SystemVerilog language. The current version is IEEE standard 1800-2023.

In computer engineering, a hardware description language (HDL) is a specialized computer language used to describe the structure and behavior of electronic circuits, most commonly to design ASICs and program FPGAs.

In the context of hardware and software systems, formal verification is the act of proving or disproving the correctness of a system with respect to a certain formal specification or property, using formal methods of mathematics. Formal verification is a key incentive for formal specification of systems, and is at the core of formal methods. It represents an important dimension of analysis and verification in electronic design automation and is one approach to software verification. The use of formal verification enables the highest Evaluation Assurance Level (EAL7) in the framework of common criteria for computer security certification.

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 and/or logic simulation tools are used to prove or refute that a given PSL formula holds on a given design.

SystemC is a set of C++ classes and macros which provide an event-driven simulation interface. 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.

A bit array is an array data structure that compactly stores bits. It can be used to implement a simple set data structure. A bit array is effective at exploiting bit-level parallelism in hardware to perform operations quickly. A typical bit array stores kw bits, where w is the number of bits in the unit of storage, such as a byte or word, and k is some nonnegative integer. If w does not divide the number of bits to be stored, some space is wasted due to internal fragmentation.

<span class="mw-page-title-main">Hardware acceleration</span> Specialized computer hardware

Hardware acceleration is the use of computer hardware designed to perform specific functions more efficiently when compared to software running on a general-purpose central processing unit (CPU). Any transformation of data that can be calculated in software running on a generic CPU can also be calculated in custom-made hardware, or in some mix of both.

Logic simulation is the use of simulation software to predict the behavior of digital circuits and hardware description languages. Simulation can be performed at varying degrees of physical abstraction, such as at the transistor level, gate level, register-transfer level (RTL), electronic system-level (ESL), or behavioral level.

Altera Hardware Description Language (AHDL) is a proprietary hardware description language (HDL) developed by Altera Corporation. AHDL is used for digital logic design entry for Altera's complex programmable logic devices (CPLDs) and field-programmable gate arrays (FPGAs). It is supported by Altera's MAX-PLUS and Quartus series of design software. AHDL has an Ada-like syntax and its feature set is comparable to the synthesizable portions of the Verilog and VHDL hardware description languages. In contrast to HDLs such as Verilog and VHDL, AHDL is a design-entry language only; all of its language constructs are synthesizable. By default, Altera software expects AHDL source files to have a .tdf extension.

In computer science and mathematical logic, satisfiability modulo theories (SMT) is the problem of determining whether a mathematical formula is satisfiable. It generalizes the Boolean satisfiability problem (SAT) to more complex formulas involving real numbers, integers, and/or various data structures such as lists, arrays, bit vectors, and strings. The name is derived from the fact that these expressions are interpreted within ("modulo") a certain formal theory in first-order logic with equality. SMT solvers are tools that aim to solve the SMT problem for a practical subset of inputs. SMT solvers such as Z3 and cvc5 have been used as a building block for a wide range of applications across computer science, including in automated theorem proving, program analysis, program verification, and software testing.

Verilog-AMS is a derivative of the Verilog hardware description language that includes Analog and Mixed-Signal extensions (AMS) in order to define the behavior of analog and mixed-signal systems. It extends the event-based simulator loops of Verilog/SystemVerilog/VHDL, by a continuous-time simulator, which solves the differential equations in analog-domain. Both domains are coupled: analog events can trigger digital actions and vice versa.

The following outline is provided as an overview of and topical guide to computer programming:

e is a hardware verification language (HVL) which is tailored to implementing highly flexible and reusable verification testbenches.

Aldec, Inc. is a privately owned electronic design automation company based in Henderson, Nevada that provides software and hardware used in creation and verification of digital designs targeting FPGA and ASIC technologies.

MyHDL is a Python-based hardware description language (HDL).

High-level synthesis (HLS), sometimes referred to as C synthesis, electronic system-level (ESL) synthesis, algorithmic synthesis, or behavioral synthesis, is an automated design process that takes an abstract behavioral specification of a digital system and finds a register-transfer level structure that realizes the given behavior.

Intelligent Verification, including intelligent testbench automation, is a form of functional verification of electronic hardware designs used to verify that a design conforms to specification before device fabrication. Intelligent verification uses information derived from the design and specification(s) to expose bugs in and between hardware IPs. Intelligent verification tools require considerably less engineering effort and user guidance to achieve verification results that meet or exceed the standard approach of writing a testbench program.

High-level verification (HLV), or electronic system-level (ESL) verification, is the task to verify ESL designs at high abstraction level, i.e., it is the task to verify a model that represents hardware above register-transfer level (RTL) abstract level. For high-level synthesis, HLV is to HLS as functional verification is to logic synthesis.

This is a list of the individual topics in Electronics, Mathematics, and Integrated Circuits that together make up the Computer Engineering field. The organization is by topic to create an effective Study Guide for this field. The contents match the full body of topics and detail information expected of a person identifying themselves as a Computer Engineering expert as laid out by the National Council of Examiners for Engineering and Surveying. It is a comprehensive list and superset of the computer engineering topics generally dealt with at any one time.

References

IEEE Standard Reference
Tutorials
Standards Development
Language Extensions
Online Tools
Other Tools