View source for SystemVerilog

{{Short description|Hardware description and hardware verification language}}
{{Use American English|date=April 2019}}
{{Infobox programming language
| name = SystemVerilog
| logo =
| logo size = 240px
| screenshot = 
| screenshot caption = 
| file ext = .sv, [[header file|.svh]]
| paradigms = [[Structured programming|Structured]] (design)<br/>[[Object-oriented programming|Object-oriented]] (verification)
| released = {{Start date and age|2002}}
| designer = [[Synopsys]], later [[Institute of Electrical and Electronics Engineers|IEEE]]
| developer = 
| latest release version = IEEE 1800-2023
| latest release date = {{Start date and age|2023|12|16}}
| latest preview version = 
| latest preview date = <!-- {{Start date and age|yyyy|mm|dd}} -->
| typing = [[Type system|Static]], [[Strong and weak typing|weak]]
| programming language = 
| platform = 
| operating system = 
| license = 
| File format = 
| website = 
| wikibooks = 
| implementations = 
| dialects = 
| influenced by = [[Verilog]], [[VHDL]], [[C++]] (design)<br/>OpenVera, [[Java (programming language)|Java]] (verification)
| influenced = 
}}

'''SystemVerilog''', [[technical standard|standardized]] as '''IEEE 1800''' by the [[Institute of Electrical and Electronics Engineers]] (IEEE), is a [[Hardware description language|hardware description]] and [[hardware verification language]] commonly used to model, [[Hardware design|design]], [[Test bench|simulate]], [[Functional verification|test]] and [[Logic synthesis|implement]] electronic systems in the [[semiconductor]] and [[Electronics|electronic]] design industry. SystemVerilog is an extension of [[Verilog]].

==History==
SystemVerilog started with the donation of the [[Superlog HDL|Superlog]] language to [[Accellera]] in 2002 by the startup company Co-Design Automation.<ref>Rich, D. “The evolution of SystemVerilog” IEEE Design and Test of Computers, July/August 2003</ref> 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.<ref>[http://www.eetimes.com/news/design/showArticle.jhtml;?articleID=173601060 IEEE approves SystemVerilog, revision of Verilog]</ref> 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,<ref>[https://standards.ieee.org/ieee/1800/4934/ IEEE 1800-2012], [[IEEE]], 2012</ref> 2017,<ref>[https://standards.ieee.org/ieee/1800/6700/ IEEE 1800-2017], [[IEEE]], 2017</ref> and most recently in December 2023.<ref name="IEEE2023">[https://standards.ieee.org/ieee/1800/7743/ IEEE 1800-2023, IEEE Standard for SystemVerilog--Unified Hardware Design, Specification, and Verification Language], [[IEEE]], 2023</ref>

==Design features==

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

# SystemVerilog for [[register-transfer level]] (RTL) design is an extension of [[Verilog|Verilog-2005]]; all 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 (programming language)|Java]] than Verilog. These constructs are generally not synthesizable.

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

===Data lifetime===
There are two types of data lifetime specified in SystemVerilog: [[Static variable|static]] and [[Local variable|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 "<code>static</code>" [[Keyword (programming)|keyword]] in the declaration before the type, e.g., "<code>static int x;</code>".  The "<code>automatic</code>" keyword is used in the same way.

===New data types===
'''Enhanced variable types''' add new capability to Verilog's "reg" type:
<syntaxhighlight lang="systemverilog">
logic [31:0] my_var;
</syntaxhighlight>

Verilog-1995 and -2001 limit reg variables to behavioral statements such as [[Register-transfer level|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 array|Multidimensional]] [[packed array]]s''' unify and extend Verilog's notion of "registers" and "memories":
<syntaxhighlight lang="systemverilog">
logic [1:0][2:0] my_pack[32];
</syntaxhighlight>

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 <code>my_pack</code> 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|Verilog-2001]], any number of unpacked dimensions is permitted.

'''[[Enumerated type|Enumerated data types]]''' (<code>enums</code>) 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 [[Type conversion|casting]].  This is not true of parameters, which were the preferred implementation technique for enumerated quantities in Verilog-2005:

<syntaxhighlight lang="systemverilog">
typedef enum logic [2:0] {
   RED, GREEN, BLUE, CYAN, MAGENTA, YELLOW
} color_t;

color_t   my_color = GREEN;
initial $display("The color is %s", my_color.name());
</syntaxhighlight>

As shown above, the designer can specify an underlying arithmetic type (<code>logic [2:0]</code> 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 <code>name()</code> returns an ASCII string for the current enumerated value, which is useful in validation and testing.

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

''[[Struct]]ures'' and ''[[Union type|unions]]'' work much like they do in the [[C (programming language)|C language]].  SystemVerilog enhancements include the ''packed'' attribute and the ''tagged'' attribute. The <code>tagged</code> attribute allows runtime tracking of which member(s) of a union are currently in use. The <code>packed</code> attribute causes the structure or union to be mapped 1:1 onto a packed array of bits. The contents of <code>struct</code> data types occupy a continuous block of memory with no gaps, similar to [[bit field]]s in C and C++:

<syntaxhighlight lang="systemverilog">
typedef struct packed {
    bit [10:0]  expo;
    bit         sign;
    bit [51:0]  mant;
} FP;

FP     zero = 64'b0;
</syntaxhighlight>As shown in this example, SystemVerilog also supports [[typedef]]s, as in C and C++.

===Procedural blocks===
SystemVerilog introduces three new procedural blocks intended to model [[Electronic hardware|hardware]]: <code>always_comb</code> (to model [[combinational logic]]), <code>always_ff</code> (for [[Flip-flop (electronics)|flip-flops]]), and <code>always_latch</code> (for [[Latch (electronic)|latches]]).  Whereas Verilog used a single, general-purpose <code>always</code> 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 <code>always_comb</code> block models [[combinational logic]].  The simulator infers the sensitivity list to be all variables from the contained statements:

<syntaxhighlight lang="systemverilog">
always_comb begin
    tmp = b * b - 4 * a * c;
    no_root = (tmp < 0);
end
</syntaxhighlight>

An <code>always_latch</code> block models [[Flip-flop (electronics)#Gated D latch|level-sensitive]] latches.  Again, the sensitivity list is inferred from the code:

<syntaxhighlight lang="systemverilog">
always_latch
    if (en) q <= d;
</syntaxhighlight>

An <code>always_ff</code> block models [[synchronous logic]] (especially [[Edge-triggered flip-flop|edge-sensitive]] [[sequential logic]]):

<syntaxhighlight lang="systemverilog">
always_ff @(posedge clk)
    count <= count + 1;
</syntaxhighlight>

[[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 <code>always</code> 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 [[Interface (computing)|interfaces]] to both reduce the redundancy of [[Hardware interface|port-name declarations]] between connected modules, as well as group and [[Abstract type|abstract]] related signals into a user-declared bundle. An additional concept is ''modport'', which shows the direction of logic connections.

Example:

<syntaxhighlight lang="systemverilog">
interface intf;
  logic a;
  logic b;
  modport in (input a, output b);
  modport out (input b, output a); 
endinterface

module top;
  intf i ();
  u_a m1 (.i1(i.in));
  u_b m2 (.i2(i.out));
endmodule

module u_a (intf.in i1);
endmodule

module u_b (intf.out i2);
endmodule
</syntaxhighlight>

==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 bench]]es.

===New data types===
The <code>string</code> data type represents a variable-length text [[String (computer science)|string]]. For example:
<syntaxhighlight lang="systemverilog">
string s1 = "Hello";
string s2 = "world";
string p = ".?!";
string s3 = {s1, ", ", s2, p[2]}; // string concatenation
$display("[%d] %s", s3.len(), s3); // simulation will print: "[13] Hello, world!"
</syntaxhighlight>

In addition to the static array used in design, SystemVerilog offers [[dynamic array]]s, [[associative arrays]] and [[Queue (abstract data type)|queues]]:

<syntaxhighlight lang="systemverilog">
int cmdline_elements; // # elements for dynamic array
int da[];             // dynamic array
int ai[int];          // associative array, indexed by int
int as[string];       // associative array, indexed by string
int qa[$];            // queue, indexed as an array, or by built-in methods

initial begin
    cmdline_elements = 16;
    da = new[ cmdline_elements ]; // Allocate array with 16 elements
end
</syntaxhighlight>

A dynamic array works much like an unpacked array, but offers the advantage of being [[Dynamically-allocated memory|dynamically allocated]] at [[Run time (program lifecycle phase)|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 [[Generic programming|user-specified]] [[Attribute–value pair|key type and data type]].  The key implies an [[Strict weak order|ordering]]; the elements of an associative array can be read out in lexicographic order.  Finally, a queue provides much of the functionality of the [[Standard Template Library|C++ STL]] [[Double-ended queue|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|single-inheritance]] model, but may implement functionality similar to multiple-inheritance through the use of so-called "interface classes" (identical in concept to the <code>interface</code> feature of Java). Classes [[Generic programming|can be parameterized by type]], providing the basic function of [[Template (C++)|C++ templates]]. However, [[template specialization]] and [[function template]]s are not supported.

SystemVerilog's [[Polymorphism (computer science)|polymorphism]] features are similar to those of C++: the programmer may specifically write a <code>virtual</code> function to have a derived class gain control of the function. See [[virtual function]] for further information.

[[Encapsulation (computer programming)|Encapsulation]] and [[Information hiding|data hiding]] is accomplished using the <code>local</code> and <code>protected</code> keywords, which must be applied to any item that is to be hidden.  By default, all class properties are [[Public member|public]].

Class instances are dynamically created with the <code>new</code> keyword.  A [[Constructor (object-oriented programming)|constructor]] denoted by <code>function new</code> can be defined. SystemVerilog has automatic [[Garbage collection (computer science)|garbage collection]], so there is no language facility to explicitly destroy instances created by the [[Operator new|new operator]].

Example:

<syntaxhighlight lang="systemverilog">
virtual class Memory;
    virtual function bit [31:0] read(bit [31:0] addr); endfunction
    virtual function void write(bit [31:0] addr, bit [31:0] data); endfunction
endclass

class SRAM #(parameter AWIDTH=10) extends Memory;
    bit [31:0] mem [1<<AWIDTH];

    virtual function bit [31:0] read(bit [31:0] addr);
        return mem[addr];
    endfunction

    virtual function void write(bit [31:0] addr, bit [31:0] data);
        mem[addr] = data;
    endfunction
endclass
</syntaxhighlight>

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

Within class definitions, the <code>rand</code> and <code>randc</code> modifiers signal variables that are to undergo randomization.  <code>randc</code> 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.

<syntaxhighlight lang="systemverilog">
class eth_frame;
    rand bit [47:0] dest;
    rand bit [47:0] src;
    rand bit [15:0] f_type;
    rand byte       payload[];
    bit [31:0]      fcs;
    rand bit [31:0] fcs_corrupt;

    constraint basic {
        payload.size inside {[46:1500]};
    }

    constraint good_fr {
        fcs_corrupt == 0;
    }
endclass
</syntaxhighlight>

In this example, the <code>fcs</code> field is not randomized; in practice it will be computed with a CRC generator, and the <code>fcs_corrupt</code> field used to corrupt it to inject FCS errors.  The two constraints shown are applicable to conforming [[Ethernet frame]]s.  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 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.
<syntaxhighlight lang="systemverilog">
class eth_frame;
    rand bit [47:0] dest;
    rand bit [47:0] src;
    rand bit [15:0] f_type;
    rand byte       payload[];
    bit [31:0]      fcs;
    rand bit        corrupted_frame;

    constraint basic {
        payload.size inside {[46:1500]};
    }
    
    function void post_randomize()
      this.calculate_fcs(); // update the fcs field according to the randomized frame
      if (corrupted_frame)  // if this frame should be corrupted 
        this.corrupt_fcs(); // corrupt the fcs
    endfunction
endclass
</syntaxhighlight>

==== 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]]: 
<syntaxhighlight lang="systemverilog">
class eth_frame;
    rand bit [47:0] dest;
    rand bit [47:0] src;
    rand bit [15:0] f_type;
    rand byte       payload[];
    bit [31:0]      fcs;
    rand bit        corrupted_frame;

    constraint basic {
        payload.size inside {[46:1500]};
    }
   
    constraint one_src_cst {
        src == 48'h1f00
    }

    constraint dist_to_fcs {
        fcs dist {0:/30,[1:2500]:/50};  // 30, and 50 are the weights (30/80 or  50/80, in this example) 
    }

endclass
.
.
.
eth_frame my_frame;

my_frame.one_src_cst.constraint_mode(0); // the constraint one_src_cst will not be taken into account
my_frame.f_type.random_mode(0);        // the f_type variable will not be randomized for this frame instance.
my_frame.randomize();
</syntaxhighlight>

===Assertions===
[[Assertion (software development)|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.<ref>[http://www.project-veripage.com/sva_1.php SystemVerilog Assertion: Introduction]</ref>

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 [[Synchronous logic|temporal operators]].  The simplest temporal operator is the <code>##</code> operator which performs a concatenation:{{Clarify|reason=What is this concatenation?|date=September 2018}}

<syntaxhighlight lang="systemverilog">
sequence S1;
    @(posedge clk) req ##1 gnt;
endsequence
</syntaxhighlight>

This sequence matches if the <code>gnt</code> signal goes high one clock cycle after <code>req</code> 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 <code>req</code> is low.  To accurately express the requirement that <code>gnt</code> follow <code>req</code> a property is required:

<syntaxhighlight lang="systemverilog">
property req_gnt;
    @(posedge clk) req |=> gnt;
endproperty

assert_req_gnt: assert property (req_gnt) else $error("req not followed by gnt.");
</syntaxhighlight>

This example shows an '''[[Material implication (logical connective)|implication]]''' operator <code>|=></code>.  The clause to the left of the implication is called the '''[[antecedent (logic)|antecedent]]''' and the clause to the right is called the '''[[consequent]]'''.  [[Interpretation (logic)|Evaluation]] of an implication starts through repeated attempts to evaluate the antecedent.  [[Material implication (rule of inference)|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 <code>req</code> goes high, after which the property will fail if <code>gnt</code> is not high on the following clock.

In addition to assertions, SystemVerilog supports [[Presupposition|assumptions]] and coverage of properties.  An assumption establishes a condition that a [[formal logic]] [[Automated theorem proving|proving tool]] [[Axiom|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===
'''[[Test 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 case|corner]] and [[edge case]]s in the [[design space verification|design space]] have been [[design space exploration|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 (statistics)|sampling]] event controls when a sample is taken.  The [[Sampling (signal processing)|sampling]] event can be a Verilog event, the entry or exit of a block of code, or a call to the <code>sample</code> method of the coverage group.  Care is required to ensure that data are sampled only when meaningful.

For example:
<syntaxhighlight lang="systemverilog">
class eth_frame;
   // Definitions as above
   covergroup cov;
      coverpoint dest {
          bins bcast[1] = {48'hFFFFFFFFFFFF};
          bins ucast[1] = default;
      }
      coverpoint f_type {
          bins length[16] = { [0:1535] };
          bins typed[16] = { [1536:32767] };
          bins other[1] = default;
      }
      psize: coverpoint payload.size {
          bins size[] = { 46, [47:63], 64, [65:511], [512:1023], [1024:1499], 1500 };
      }

      sz_x_t: cross f_type, psize;
   endgroup
endclass
</syntaxhighlight>

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 (computing)|event]]' primitive allowed different blocks of procedural statements to trigger each other, but enforcing thread [[Synchronization (computer science)|synchronization]] was up to the programmer's (clever) usage. SystemVerilog offers two [[Synchronization primitive|primitives]] specifically for interthread synchronization: ''[[Mailbox (computing)|mailbox]]'' and ''[[Semaphore (programming)|semaphore]]''.  The mailbox is modeled as a [[FIFO (computing and electronics)|FIFO]] message queue.  Optionally, the FIFO can be [[TypeParameter|type-parameterized]] so that [[Strong typing|only objects of the specified type]] may be passed through it.  Typically, objects are [[Instance (computer science)|class instances]] representing ''[[Transaction processing system|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 operator]]s (<=, =) can now operate [[Array programming|directly on arrays]].
*Port (inout, input, output) definitions are now expanded to support a wider variety of [[data type]]s: [[struct]], [[Enumerated type|enum]], [[Real computation|real]], and multi-dimensional types are supported.
*The [[for loop]] construct now allows [[Local variable|automatic variable declaration]] inside the for statement.  Loop [[Control flow|flow control]] is improved by the [[Control flow|''continue'' and ''break'' statements]].
*SystemVerilog adds a [[Do while loop|''do''/while loop]] to the [[While loop|''<u>while</u>'' loop]] construct.
*[[Constant (computer programming)|Constant variables]], i.e. those designated as non-changing during runtime, can be designated by use of ''[[Const (computer programming)|const]]''.
*[[Initialization (programming)|Variable initialization]] can now operate on arrays.
*[[Increment and decrement operators]] (<code>x++</code>, <code>++x</code>, <code>x--</code>, <code>--x</code>) are supported in SystemVerilog, as are other [[Augmented assignment|compound assignment]] operators (<code>x += a</code>, <code>x -= a</code>, <code>x *= a</code>, <code>x /= a</code>, <code>x %= a</code>, <code>x <<= a</code>, <code>x >>= a</code>, <code>x &= a</code>, <code>x ^= a</code>, <code>x |= a</code>) as in [[List of C-family programming languages|C and descendants]].
*The preprocessor has improved [[Define directive|`define]] [[Preprocessor directive|macro]]-substitution capabilities, specifically substitution within literal-strings (""), as well as [[Stringification|concatenation of multiple macro-tokens into a single word]].
*The [[Fork–join model|fork/join]] construct has been expanded with ''join_none'' and ''join_any''.
*Additions to the `timescale directive allow simulation timescale to be controlled more predictably in a large simulation environment, with each [[source file]] using a local timescale.
*Task ports can now be declared ''ref''.  A reference gives the task body direct access to the source arguments in the caller's scope, known as "[[pass by reference]]" in computer programming.  Since it is operating on the original variable itself, rather than a copy of the argument's value, the task/function can modify variables (but not nets) in the caller's scope in [[Real-time computing|real time]].  The inout/output port declarations pass variables [[Pass by value|by value]], and defer updating the caller-scope variable until the moment the task exits.
*Functions can now be declared ''[[Void type|void]]'', which means it [[Return value|returns]] no value.
*[[Parameter (computer programming)|Parameters]] can be declared any type, including user-defined [[Typedef|''typedef''s]].

Besides this, SystemVerilog allows convenient [[Language interoperability|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 simulator]]s.  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|date=September 2018}}  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 [[Logic synthesis|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 ([[Lint (software)|linters]], [[formal verification]] and [[Automatic test pattern generation|automated test structure generators]]) support a common language subset.{{Update inline|date=September 2018|reason=What's the state in 2018?|?=yes}}

==See also==
*[[List of HDL simulators]] (Search for SV2005)
*[[Verilog-AMS]]
*[[e (verification language)]]
*[[SpecC]]
*[[Accellera]]
*[[SystemC]]
*[[SystemRDL]]

==References==
{{Reflist}}
* {{Cite book| doi = 10.1109/IEEESTD.2005.97972| year = 2005| isbn = 978-0-7381-4810-6| title = IEEE Standard for SystemVerilog: Unified Hardware Design, Specification and Verification Language}}
* {{Cite book| doi = 10.1109/IEEESTD.2009.5354441| year = 2009| isbn = 978-0-7381-6130-3| title = IEEE Standard for SystemVerilog--Unified Hardware Design, Specification, and Verification Language}}
* {{Cite book| doi = 10.1109/IEEESTD.2013.6469140| year = 2013| isbn = 978-0-7381-8110-3| title = IEEE Standard for SystemVerilog--Unified Hardware Design, Specification, and Verification Language}}
* {{Cite book| doi = 10.1109/IEEESTD.2018.8299595| year = 2017| isbn = 978-1-5044-4509-2| title = IEEE Standard for SystemVerilog--Unified Hardware Design, Specification, and Verification Language}}
* {{cite news |last=McGrath |first=Dylan |url=http://www.eetimes.com/news/design/showArticle.jhtml;?articleID=173601060 |title=IEEE approves SystemVerilog, revision of Verilog |publisher=EE Times |date=2005-11-09 |access-date=2007-01-31}}
* {{cite news |last=Puneet Kumar |url=http://asicguru.com/System-Verilog-Tutorial/1/3 |title=System Verilog Tutorial | date=2005-11-09 }}
* {{cite news |last=Gopi Krishna |url=http://www.testbench.in |title=SystemVerilog, SVA, SV DPI Tutorials |date=2005-11-09 }}
* {{cite news |last= HDVL |url=http://hdvl.wordpress.com/category/systemverilog/ |title=More SystemVerilog Weblinks }}
* Spear, Chris, [https://www.amazon.com/SystemVerilog-Verification-Learning-Testbench-Language/dp/0387765298/ref=sr_1_1?ie=UTF8&s=books&qid=1247578512&sr=8-1 "SystemVerilog for Verification"]  Springer, New York City, NY. {{ISBN|0-387-76529-8}}
* Stuart Sutherland, Simon Davidmann, Peter Flake, [https://www.amazon.com/SystemVerilog-Design-Second-Hardware-Modeling/dp/0387333991/ref=sr_1_4?ie=UTF8&s=books&qid=1247578512&sr=8-4 "SystemVerilog for Design Second Edition: A Guide to Using SystemVerilog for Hardware Design and Modeling"]  Springer, New York City, NY. {{ISBN|0-387-33399-1}}
* Ben Cohen, Srinivasan Venkataramanan, Ajeetha Kumari and Lisa Piper [http://SystemVerilog.us] SystemVerilog Assertions Handbook, 4th Edition, 2016- http://SystemVerilog.us
* Ben Cohen Srinivasan Venkataramanan and Ajeetha Kumari [http://SystemVerilog.us] A Pragmatic Approach to VMM Adoption, - http://SystemVerilog.us
* Erik Seligman and Tom Schubert [https://www.amazon.com/Formal-Verification-Essential-Toolkit-Modern-ebook/dp/B012VX1MW8/ref=sr_1_1?ie=UTF8&qid=1451183481&sr=8-1&keywords=erik+seligman+formal+verification] Formal Verification: An Essential Toolkit for Modern VLSI Design, Jul 24, 2015,

==External links==

;IEEE Standard Reference
* [https://ieeexplore.ieee.org/document/8299595 1800-2017 - IEEE Standard for SystemVerilog--Unified Hardware Design, Specification, and Verification Language]. The 2017 version is available at no cost via the IEEE GET Program.<ref>[https://ieeexplore.ieee.org/browse/standards/get-program/page/series?id=80 IEEE GET Program], [[IEEE]]</ref>

;Tutorials
* [http://www.asic-world.com/systemverilog/tutorial.html SystemVerilog Tutorial]
* [http://www.project-veripage.com/sv_front.php SystemVerilog Tutorial for Beginners]

;Standards Development
* [http://www.eda.org/sv-ieee1800/ IEEE P1800] – Working group for SystemVerilog
* Sites used before IEEE 1800-2005
** [http://www.systemverilog.org/ SystemVerilog official website]
** [http://www.vhdl.org/sv/ SystemVerilog Technical Committees]

;Language Extensions
* [http://www.veripool.org/verilog-mode Verilog AUTOs] – An open source meta-comment system to simplify maintaining Verilog code

;Online Tools
* [http://www.edaplayground.com EDA Playground] – Run SystemVerilog from a web browser (free online IDE)
* [http://www.svericl.com/sverule sverule] – A SystemVerilog BNF Navigator (current to IEEE 1800-2012)

;Other Tools
* [http://sourceforge.net/projects/svunit/ SVUnit] – unit test framework for developers writing code in SystemVerilog. Verify SystemVerilog modules, classes and interfaces in isolation.
* [https://github.com/zachjs/sv2v/ sv2v] - open-source converter from SystemVerilog to Verilog

{{IEEE standards}}
{{Programmable logic}}
{{Authority control}}

{{DEFAULTSORT:Systemverilog}}
[[Category:Hardware description languages]]
[[Category:Hardware verification languages]]
[[Category:System description languages]]
[[Category:Programming languages created in 2002]]
<!-- Hidden categories below -->
[[Category:Articles with example code]]