In the semiconductor

Semiconductor

A semiconductor is a material with electrical conductivity due to electron flow intermediate in magnitude between that of a conductor and an insulator. This means a conductivity roughly in the range of 103 to 10−8 siemens per centimeter...

 and electronic design industry, SystemVerilog is a combined Hardware Description Language

Hardware description language

In electronics, a hardware description language or HDL is any language from a class of computer languages, specification languages, or modeling languages for formal description and design of electronic circuits, and most-commonly, digital logic...

 and Hardware Verification Language

Hardware verification language

A Hardware Verification Language, or HVL, is a programming language used to verify the designs of electronic circuits written in a hardware description language. HVLs typically include features of a high-level programming language like C++ or Java as well as features for easy bit-level...

 based on extensions to Verilog

Verilog

In the semiconductor and electronic design industry, Verilog is a hardware description language used to model electronic systems. Verilog HDL, not to be confused with VHDL , is most commonly used in the design, verification, and implementation of digital logic chips at the register-transfer level...

.

History

SystemVerilog started with the donation of the Superlog language to Accellera in 2002. The bulk of the verification functionality is based on the OpenVera

OpenVera

OpenVera is a dead Hardware Verification Language developed, and managed by Synopsys.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...

 language donated by Synopsys

Synopsys

Synopsys, Inc. is one of the largest companies in the Electronic Design Automation industry. Synopsys' first and best-known product is Design Compiler, a logic-synthesis tool. Synopsys offers a wide range of other products used in the design of an application-specific integrated circuit...

. 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.

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

1. SystemVerilog for RTL design is an extension of Verilog-2005
   Verilog
   In the semiconductor and electronic design industry, Verilog is a hardware description language used to model electronic systems. Verilog HDL, not to be confused with VHDL , is most commonly used in the design, verification, and implementation of digital logic chips at the register-transfer level...
   
   ; all features of that language are available in SystemVerilog.
2. SystemVerilog for verification uses extensive object-oriented programming
   Object-oriented programming
   Object-oriented programming is a programming paradigm using "objects" – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs. Programming techniques may include features such as data abstraction,...
   
    techniques and is more closely related to Java
   Java (programming language)
   Java is a programming language originally developed by James Gosling at Sun Microsystems and released in 1995 as a core component of Sun Microsystems' Java platform. The language derives much of its syntax from C and C++ but has a simpler object model and fewer low-level facilities...
   
    than Verilog.

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

Verilog

In the semiconductor and electronic design industry, Verilog is a hardware description language used to model electronic systems. Verilog HDL, not to be confused with VHDL , is most commonly used in the design, verification, and implementation of digital logic chips at the register-transfer level...

.

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 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 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] {

   RED, GREEN, BLUE, CYAN, MAGENTA, YELLOW

} 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.

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

C (programming language)

C is a general-purpose computer programming language developed between 1969 and 1973 by Dennis Ritchie at the Bell Telephone Laboratories for use with the Unix operating system....

. 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 it occupy a continuous block of memory (with no gaps):

typedef struct packed {

    bit [10:0]  expo;

    bit         sign;

    bit [51:0]  mant;

} FP;



FP     zero = 64'b0;

Unique/priority if/case

These attributes enable a designer to specify certain restrictions on the evaluation of the case/if constructs. This is useful for hardware design as the size/speed of mapped hardware depends on whether the decision-logic tree must obey a particular precedence (priority), or if it can simply execute as an N-way multiplexor (parallel). The unique attribute on a cascaded if or case statement indicates that exactly one branch or case item must execute; otherwise it is an error. The priority attribute on an if or case statement indicates that the choices must be evaluated in order, and that one branch must execute. Verilog designers often used proprietary pragmas (the de-facto // synopsys full_case parallel_case) in the specification of logic state-machines. However, as the pragma is not a formal part of the language, it has meaning only to synthesis-tools—Careless use of pragmas can easily lead to unexpected functional mismatches between simulation-modeling and synthesized-hardware.

Procedural blocks

SystemVerilog introduces three new procedural blocks intended to model hardware: always_comb, always_ff, and always_latch. 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 always_comb block models combinational logic. The simulator infers the sensitivity list to be all variables from the contained statements:

always_comb begin

    tmp = b * b - 4 * a * c;

    no_root = (tmp < 0);

end

An always_ff block is meant to infer synchronous logic:

always_ff @(posedge clk)

    count <= count + 1;

An always_latch block is meant to infer a level-sensitive latch. Again, the sensitivity list is inferred from the code:

always_latch

    if (en) q <= d;

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 the interface concept, to both reduce the redundancy of portname declarations between connected-modules, as well as group and abstract related signals into a user-declared bundle. Additional concept is modport, that shows direction of logic connections.
example:

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));

  u_b m2 (.i2(i));

endmodule



module u_a (intf.in i1);

endmodule



module u_b (intf.out i2);

endmodule

Verification features

The following verification features are typically not synthesizable. Instead, they assist in the creation of extensible, flexible test benches.

New data types

The string data type represents a variable-length text string.

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

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



initial begin

    cmdline_elements = 16;

    da = new[ cmdline_elements ]; // Allocate array with 16 elements

end

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

Object-oriented programming

Object-oriented programming is a programming paradigm using "objects" – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs. Programming techniques may include features such as data abstraction,...

 model.

In SystemVerilog, classes support a single-inheritance model. There is no facility that permits conformance of a class to multiple functional interfaces, such as 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.

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. Garbage collection is automatic, so there is no language facility to explicitly destroy instances created by the new operator.

Example:

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<


    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

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.

class eth_frame;

    rand bit [47:0] dest;

    rand bit [47:0] src;

    rand bit [15:0] 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

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.

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.

class eth_frame;

    rand bit [47:0] dest;

    rand bit [47:0] src;

    rand bit [15:0] 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

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

class eth_frame;

    rand bit [47:0] dest;

    rand bit [47:0] src;

    rand bit [15:0] 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

    }

 

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.type.random_mode(0);        // the type variable will not be randomized for this frame instance.

my_frame.randomize;

Assertions

SystemVerilog has its own assertion specification language, similar to Property Specification Language

Property Specification Language

Property Specification Language is a language developed by Accellera for specifying properties or assertions about hardware designs. The properties can then be simulated or formally verified. Since September 2004 the standardization on the language has been done in IEEE 1850 working group...

. Assertions are useful for verifying properties of a design that manifest themselves over time.

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:

sequence S1;

    @(posedge clk) req ##1 gnt;

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:

property req_gnt;

    @(posedge clk) req |=> gnt;

endproperty



assert_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 stimulus. Property coverage allows the verification engineer to verify that assertions are accurately monitoring the design.

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

Device under test

Device under test , also known as unit under test , is a term commonly used to refer to a manufactured product undergoing testing.-In semiconductor testing:...

 (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

Code coverage

Code coverage is a measure used in software testing. It describes the degree to which the source code of a program has been tested. It is a form of testing that inspects the code directly and is therefore a form of white box testing....

 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 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 cross-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.

e.g.:

class eth_frame;

   // Definitions as above

   covergroup cov;

      coverpoint dest {

          bins bcast[1] = {48'hFFFFFFFFFFFF};

          bins ucast[1] = default;

      }

      coverpoint 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 type, psize;

   endgroup

endclass

In this example, the verification engineer is interested in the distribution of broadcast and unicast frames, the size/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. 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 (e.g. 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 directly on arrays.
• Port (inout, input, output) definitions are now expanded to support a wider variety of datatypes: struct, enum, real, and multi-dimensional types are supported.
• The for-loop construct now allows automatic variable declaration inside the for statement. And loop-control is improved by the continue and break statements.
• SystemVerilog adds a do/while to the while construct.
• Constant variables, i.e. those designated as non-changing during runtime, can be designated by use of const.
• Variable initialization can now operate on arrays.
• The preprocessor has improved `define macro-substitution capabilities, specifically substitution within literal-strings (""), as well as concatenation of multiple macro-tokens into a single word.
• The 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. 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 realtime. The inout/output port-declarations pass variables by value, and defer updating the caller-scope variable until the moment the task exits.
• Functions can now be declared void, which means it returns no value.
• Parameters can be declared any type, including user-defined typedefs.

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

SystemVerilog DPI

SystemVerilog DPI is an interface which can be used to interface SystemVerilog with foreign languages. These Foreign languages can be a C, C++, System C as well as others. DPI's consists of two layers: A SystemVerilog Layer and a Foreign language layer. Both the layers are isolated from each other...

 (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, Mentor, Synopsys) have incorporated SystemVerilog into their mixed-language HDL-simulators. Although no simulator can yet claim support for the entire SystemVerilog LRM, making testbench interoperability a challenge, efforts to promote cross-vendor compatibility are underway. 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, i.e. transformation of a hardware-design description into a gate-netlist, SystemVerilog adoption has been slow. Many design-teams have 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, automated test structure generators) support a common language subset.

See also

• List of SystemVerilog Simulators (Search for SV2005)
• e (verification language)
  E (verification language)
  e is a hardware verification language which is tailored to implementing highly flexible and reusable verification testbenches.- History :...
  
  

IEEE Standard Reference

• 1800-2009 IEEE Standard for System Verilog-Unified Hardware Design, Specification, and Verification Language
• SystemVerilog 3.1a Language Reference Manual - 2004 draft version, which is before IEEE 1800-2005 standard.

Standards Development

• IEEE P1800 – Working group for SystemVerilog
• Sites used before IEEE 1800-2005
  • SystemVerilog official website
  • SystemVerilog Technical Committees

Language Extensions

• Verilog AUTOs - An open-source meta-comment system to simplify maintaining Verilog code.