Literals in SystemVerilog
Literal Values
SystemVerilog extends built-in data types and literal values available in Verilog. Literals can be integer, real, time, arrays or string.
- Integer and logical literals (useful for Designers)
In Verilog, semantics exist to scale assigned values of "0", "x" and "z" to a vector. However, no option exists to expand a value of "1" if needed.
-
wire [2:0] count = 0; // assigns count as 3'b000
-
wire [2:0] count = 'bz; // assigns count as 3'bzzz
-
wire [2:0] count = 'bx; // assigns count as 3'bxxx
-
wire [2:0] count = 3'b111; // one way to assign 1's to all bits
SystemVerilog allows the ability to specify unsized literal values without base specifiers (like binary, hex or octal) and scale a value of '1' in unsized vectors.
'1 // set all bits on LHS to 1
'0 // set all bits on LHS to 0
'x or 'X // set all bits on LHS to x
'z or 'Z // set all bits on LHS to z
This feature is very useful when using parameterized variables since you only need to change the parameter size instead of the entire code. (see example below)
-
parameter SIZE = 4;
-
wire [SIZE-1:0] enable;
-
enable = '0; // No need to change this if vector size changes.
- Time literals
Time can be represented as integer or real without any space between the unit (fs ps us ms s step) and the number. For example, 0.2ms or 100ns. In Verilog, the first `timescale directive remains in effect for all modules until a new ` timescale is encountered - this creates a dependency on the order in which files are read in. If a verilog source file without ` timescale is read before or after the second `timescale directive, different units will be in effect. By specifying the unit as part of the declaration, any ambiguity to the timescale is resolved.
Further, SystemVerilog supports timeunit and timeprecision keywords that can be used to locally bind a module or interface to the time units. These units must be declared immediately following the module port list definition without any declarations or assignments in between. For example,
-
module counter (clk, reset, load, incr);
-
timeunit 1ns;
-
timeprecision 10ps;
-
---
-
endmodule
- Real Literals
Any floating or exponential numbers are represented as real literals. For example, 2.5 and 4e11
- String Literals
A string literal is enclosed in quotes and has it's own data type. For example, byte C1 = "B"; In addition, SystemVerilog also defines a string datatype to which a string literal can be assigned.
- Array Literals
Array literals are similar to C but replicators {{ }} are allowed and can be nested. For example,
int array_a [1:0] [2:0] = {2{{3{1,2}}}} ; // same as { {1,2,1,2,1,2}, {1,2,1,2,1,2} }
- Structure Literals
Similar to C syntax, an example is below. We will look at these in detail in later posts.
-
typedef struct {int size; int addr;} packet_s;
-
packet_s pkt_a;
-
pkt_a = {0, 0};
Statistical Static Timing Analysis
Various type of timing variations make accurate modeling of interconnect and circuits very hard as we move to nanometer processes. In traditional static timing analysis, based on process parameter files we characterize the cells, calculate the cell delays and crosstalk effects and run timing analysis. This however hides the silicon process variations from the designer.
These variations are broadly classified into Process variations (due to fabrication such as oxide thickness, transistor width, effective channel length etc.) and Environmental variations (temperature and voltage variations).
Process variations is further classified into Inter-die variations that vary from die to die and affect all the chips on the die in an exact similar way and Intra-die variations that may cause variations within a single chip or between chips on the same die.
To account for the inter-die variations, timing analysis at multiple different corners are run on the chip. But as we move towards nanometer processes, intra-die variations are significant and very complex to be captured in traditional STA as each region within a chip can use different process corner.
To overcome this limitation, an alternative approach known as Statistical Static Timing Analysis is proposed where the delays are not represented as fixed numbers but as probability density functions (pdf) taking the statistical distribution of variations into account.
In traditional timing analysis, the delay at the gate outputs are computed using "sum" of gate delay and delay at the gate input. Once all the component delays have been determined, a "max" operation gives the maximum arrival time at the output. SSTA is similar to STA except that the interconnect delays and cell delays are probability density functions (pdf like Gaussian Model) instead of numbers.
SSTA can again be broadly classified into path-based methods (find pdf on a path-by-path basis and then perform statistical add operation to find the delay distribution) and block-based methods (perform critical path analysis, processing each gate once but much faster than path-based methods if the number of paths are relatively large).
Monte-Carlo simulations is the most simple method for SSTA where given an arbitrary distribution, the tool generates sample points and runs analysis at each sample point and aggregates the results to find the delay distribution. The major disadvantage is the larger runtimes required.
Another complication in SSTA is to account for spatial corelations within a single chip - partition the chip into x by y grids, each grid modeled using corelated variables.
Several SSTA techniques have been proposed and it is still at a nascent stage - IBM recently announced a set of statistical timing analysis tools for 45 nm and below.
Sphere: Related ContentSystem Verilog - Overview
Need for SystemVerilog
As ASIC designs get complex and grow larger in size, the modeling of these designs using register transfer level languages like Verilog
also scale accordingly. In addition to verify these designs, use of Hardware Verification
Languages (HVL) like 'e' to with new semantics/concepts pose a steep learning curve. To overcome these limitations, a unified language for both design and verification based on existing Verilog standard (and backward compatible to Verilog) was conceived.
SystemVerilog (Standard IEEE 1800-2005) is based on Verilog-2005 standard and includes new, effective and useful constructs for both design and verification. It integrates high-level hardware modeling extensions to Verilog with Hardware verification language (HVL like OpenVERA, 'e') constructs to create a unified design and verification language - Hardware Description and Verification Language (HDVL).
Key SystemVerilog Enhancements for Design
- New hierarchical structure (interface - endinterface) for modeling at higher levels of abstraction. It encapsulates communication and protocol checking within the design eliminating any conection errors.
- Datatype extensions - SystemVerilog supports the four state (0,1,x,z) Verilog datatypes and extends it to four/two state logic, bit, int, longint datatypes. Usage of two state (0,1) datatypes like bit, int make the simulations run faster. User defined datatypes using typedef, enumerateddatatypes using enum are also supported.
- Supports static variables that are initialized at time 0, global variables that are accessible from any scope (for example, const is a global constant), local variables that are available locally (for example, localparam).
- Supports packages for sharing across different modules using package - endpackage, derived from VHDL
- Supports structures and unions similar to C to confine multiple bus signals within one structure. Also add object-oriented features from C++ like classes. Classes can be public or private and are used to define methods and properties of the object.
- Verilog task and function enhancements such as arguments can be passed by reference, functions can be void etc.
- C features like for and do loops, continue, break etc. Unpacked arrays where all or part elements of an array can copied to another array unlike Verilog that allows only one element of array to be accessible at a time.
Key SystemVerilog Enhancements for Verification
- Supports built-in class objects (semaphore and mailbox) for synchronizing parallel activities in a testbench. semaphore is arbitration of shared resources (keys) among different processes - if no key is available to a process, it can wait until required number of keys are returned to the bucket. mailbox helps in exchanging messages between processes. The message queue behaves like a FIFO
.
- Supports dynamic arrays that can be restricted to a particular size during runtime and associative arrays that can be referenced using enum types as values.
- Two random number classes rand and randc that aid in constraining the random values generated for verification.
- Supports assertions conforming to Property Specification Language (PSL) standard.