GetWiki

{{Short description|Hardware description and hardware verification language}}{{Use American English|date = April 2019}}

factoids

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.

History

SystemVerilog started with the donation of the Superlog language to Accellera in 2002 by the startup company Co-Design Automation.Rich, D. “The evolution of SystemVerilog” IEEE Design and Test of Computers, July/August 2003 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.IEEE approves SystemVerilog, revision of Verilog 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,IEEE 1800-2012, IEEE, 2012 2017,IEEE 1800-2017, IEEE, 2017 and most recently in December 2023.IEEE 1800-2023, IEEE Standard for SystemVerilog--Unified Hardware Design, Specification, and Verification Language, IEEE, 2023

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:typedef enum logic [2:0] { } color_t;color_t my_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++:typedef struct packed { } FP;FP zero = 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_comb begin < 0);endAn always_latch block models level-sensitive latches. Again, the sensitivity list is inferred from the code:always_latch endpropertyassert_req_gnt: assert property (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|date=September 2018}}

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:class eth_frame;

endclassIn 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:

• The procedural assignment operators (