1 Introduction to SystemVerilog

1.1 SystemVerilog origins

1. SystemVerilog is a standard set of extensions to the IEEE 1364- 2005 Verilog Standard.

2. The specification of the SystemVerilog enhancements to Verilog began with a standards

group under the auspices of the Accellera Standards Organization.

1.2 Key SystemVerilog enhancements for hardware design

1. C like data types, such as int.

2. User-defined types, using typedef.

3. Enumerated types.

4. Type casting.

5. Structures and unions.

6. Packages for definitions shared by multiple design blocks.

7. External compilation-unit scope declarations.

8. ++, –, += and other assignment operators.

9. Explicit procedural blocks.

10. Priority and unique decision modifiers.

11. Programming statement enhancements.

12. Pass by reference to tasks, functions and modules.

1.3 Summary
SystemVerilog unifies several proven hardware design and verification languages, in the form of
extensions to the Verilog HDL. These extensions provide powerful new capabilities for modeling
hardware at the RTL, system and architectural levels, along with a rich set of features for
verifying model functionality.

2 SystemVerilog Declaration Spaces

Verilog only has limited places in which designers can declare variables and other design infor-
mation. SystemVerilog extends Verilog’s declaration spaces in several ways.

1
2.1 Packages
1. SystemVerilog packages are defined between the keywords package and endpackage.

2. The synthesizable constructs that a packages can contain are: parameter, localparameter,
const typedef, automatic task and funtion, other import packages, Operator overload.

3. In Verilog, a parameter constant can be redefined for each instance of a module, whereas
a localparam cannot be directly redefined.

4. In a package, parameter and localparam are synonymous.

5. Modules and interfaces can reference the definitions and declarations in a package four
ways:

(a) Direct reference using a scope resolution operator

(b) Import specific package items into the module or interface
(c) Wildcard import package items into the module or interface
(d) Import package items into the $unit declaration space

6. To be synthesizable, tasks and functions defined in a package must be declared as auto-

matic, and cannot contain static variables.

7. For similar reasons, synthesis does not support variables declarations in packages. In
simulation, a package variable will be shared by all modules that import the variable.

2.2 $unit compilation-unit declarations

1. SystemVerilog adds a concept called a compilation unit to Verilog. A compilation unit is
all source files that are compiled at the same time.

2. These external declarations are in a compilation-unit scope, and are visible to all modules
that are compiled at the same time.

3. A declaration in the compilation-unit scope is not the same as a global declaration. A true
global declaration, such as a global variable or function, would be shared by all modules
that make up a design, regardless of whether or not source files are compiled separately
or at the same time.

4. Coding guidelines:

(a) Do not make any declarations in the $unit space! All declarations should be made
in named packages.
(b) When necessary, packages can be imported into $unit. This is useful when a module
or interface contains multiple ports that are of user-defined types, and the type
definitions are in a package.

5. An alternative style is to import a package into the $unit compilation- unit scope, prior
to the module declaration. This makes the user-defined type definitions visible in the
SystemVerilog search order.

6. A package can also be imported into the $unit space using a wildcard import. Keep in
mind that a wildcard import does not actually import all package items. It simply adds
the package to the System- Verilog source path.

2
 7. The same care must be observed when importing packages into the $unit space as with
making declarations and definitions in the $unit space. When using $unit, file order
dependencies can be an issue, and multiple $units can be an issue.
8. A solution to both of these problems with importing package items into the $unit compilation-
unit space is to place the import statements in every file, before the module or interface
definition.
9. A common C programming trick can be used to make it possible to import package items
into the $unit space with both single file compilation and multiple file compilation. The
trick is to use conditional compilation to include the import statements the first time the
statements are compiled into $unit, and not include the statements if they are encountered
again in the same compilation.

2.3 Simulation time units and precision

1. Verilog specifies time units as a command to the software tool, using a ‘timescale compiler
directive. This directive has two components: the time units, and the time precision to
be used.
2. The ‘timescale directive can be defined in none, one or more Verilog source files.
3. SystemVerilog extends the Verilog language by allowing time units to be specified as part
of the time value.
4. In SystemVerilog, the specification of time units is further enhanced with the keywords
timeunit and timeprecision. These keywords are used to specify the time unit and preci-
sion information within a module, as part of the module definition.
5. The timeunit and timeprecision keywords allow binding the unit and precision infor-
mation directly to a a module.
6. The timeunit and timeprecision statements must be specified immediately after the mod-
ule, interface, or program declaration, before any other declarations or statements.

2.4 Summary
1. This chapter has introduced SystemVerilog packages and the $unit declaration space.
Packages provide a well-defined declaration space where user-defined types, tasks, func-
tions and constants can be defined. The definitions in a package can be imported into
any number of design blocks. Specific package items can be imported, or the package
definitions can be added to a design block’s search path using a wildcard import.
2. The $unit declaration space provides a quasi global declaration space. Any definitions
not contained within a design block, testbench block or package falls into the $unit
compilation-unit space. Care must be taken when using $unit to avoid file order depen-
dencies and differences between separate file compilation and multifile compilation. This
chapter provided coding guidelines for the proper usage of the $unit compilation-unit
space.
3. SystemVerilog also allows local variables to be defined in unnamed begin...end blocks.
This simplifies declaring local variables, and also hides the local variable from outside the
block. Local variables in unnamed blocks are protected from being read or modified from
code that is not part of the block.

3
 4. SystemVerilog also enhances how simulation time units and precision are specified. These
enhancements eliminate the file order dependencies of Verilog’s ‘timescale directive.

3 SystemVerilog Literal Values and Built-in Data Types

3.1 Enhanced literal value assignments
SystemVerilog enhances assignments of a literal value in two ways. First, a simpler syntax is
added, that allows specifying the fill value without having to specify a radix of binary, octal or
hexadecimal. Secondly, the fill value can also be a logic 1

1. '0 fills all bits on the left-hand side with 0.

2. '1 fills all bits on the left-hand side with 1.

3. 'z or 'Z fills all bits on the left-hand side with z.

4. 'x or 'X fills all bits on the left-hand side with x.

The enhancement also makes it possible to code models that automatically scale to new vector
sizes without having to modify the logic of the model.

3.2 Object types and data types

Verilog does not clearly distinguish between signal types, and the value set the signals can store
or transfer. The SystemVerilog standard defines that signals in a design have both a type and
a data type.

1. Type indicates if the signal is a net or variable.

2. Data type indicates the value system of the net or variable, which is 0 or 1 for 2-state
data types, and 0, 1, Z or X for 4-state data types.

3. The logic keyword is a data type.

(a) var logic [63 : 0] addr; // a 64-bit wide variable

(b) wire logic [63 : 0] data; // a 64-bit wide net

4. Semantically, a variable of the logic data type is identical to the Verilog reg type.

5. SystemVerilog adds several new 2-state types.

(a) bit — a 1-bit 2-state integer

(b) byte — an 8-bit 2-state integer, similar to a C char
(c) shortint — a 16-bit 2-state integer, similar to a C short
(d) int — a 32-bit 2-state integer, similar to a C int
(e) longint — a 64-bit 2-state integer, similar to a C longlong

6. Synthesis guidelines

4
 (a) The 4-state logic type and the 2-state bit, byte, shortint, int, and longint types are
synthesizable. Synthesis compilers treat 2- state and 4-state types the same way.
The use of 2-state types primarily affects simulation.
(b) 2-state types begin simulation with a default value of logic value of 0. Synthesis
ignores this default initial value.

3.3 Relaxation of type rules

1. In Verilog, there are strict semantic restrictions regarding where variable types such as
reg can be used, and where net types such as wire can be used. The general rule of thumb
is that a variable must be used when modeling using initial and always procedural blocks,
and a net must be used when modeling using continuous assignments, module instances
or primitive instances.

2. SystemVerilog greatly simplifies determining the proper type to use in a model, by relaxing
the rules of where variables can be used.

3. SystemVerilog makes it an error to have multiple output ports or multiple continuous

assignments write to the same variable, or to combine procedural assignments with con-
tinuous assignments or output drivers on the same variable.

4. Use variables for single-driver logic, and use nets for multidriver logic.

5. Only nets can have multiple sources, such as multiple continuous assignments and/or
connections to multiple output ports of module or primitive instances.

3.4 Signed and unsigned modifiers

1. The enhancement that affects types is the ability to declare any type as signed. This
modifier overrides the default definition of unsigned types in Verilog.

3.5 Static and automatic variables

1. The Verilog-2001 standard added the ability to define variables in a task or function as
automatic, meaning that the variable storage is dynamically allocated by the software
tool when required, and deallocated when no longer needed.

2. SystemVerilog adds a static keyword, and allows any variable to be explicitly declared as
either static or automatic.

3. Static variable initialization is not synthesizable. Automatic variable initialization is

synthesizable.

4. SystemVerilog in-line variable initialization does not cause a simulation event.

3.6 Type casting

1. SystemVerilog adds the ability to cast a value to a different type. Type casting is different
than converting a value during an assignment.

2. SystemVerilog adds a cast operator to the Verilog language.

5
 3. a new system function, $cast, that performs dynamic, runtime checking on the value to
be cast.

4. The static, compile-time cast operator is synthesizable. The dynamic $cast system func-
tion might not be supported by synthesis compilers.

3.7 Constants
1. parameter is a constant for which the value can be redefined during elaboration using
defparam or in-line parameter redefinition.

2. specparam is a constant that can be redefined at elaboration time from SDF files.

3. localparam is an elaboration-time constant that cannot be directly redefined, but for

which the value can be based on other constants.

3.8 Summary
1. This chapter introduced and discussed the powerful compilationunit declaration scope.
The proper use of compilation-unit scope declarations can make it easier to model func-
tionality in a more concise manner. A primary usage of compilation-unit scope declara-
tions is to define new types using typedef.

2. SystemVerilog enhances the ability to specify logic values, making it easier to assign values
that easily scale to any vector size. Enhancements to the ‘define text substitution provide
new capabilities to macros within Verilog models and testbenches.

3. SystemVerilog also adds a number of new 2-state variables to the Verilog language: bit,
byte, shortint, int, and longint. These variable types enable modeling designs at a higher
level of abstraction, using 2-state values. The semantic rules for 2-state values are well
defined, so that all software tools will interpret and execute Verilog models using 2-state
logic in the same way. A new const can be used in automatic tasks and functions
shortreal type and a logic type are also added. The initialization of variables is enhanced,
so as to reduce ambiguities that exist in the Verilog standard. This also helps ensure
that all types of software tools will interpret SystemVerilog models in the same way.
SystemVerilog also enhances the ability to declare variables that are static or automatic
(dynamic) in various levels of design hierarchy. These enhancements include the ability
to declare constants in begin...end blocks and in automatic tasks and functions.

4. The next chapter continues the topic on SystemVerilog types, covering user-defined types
and enumerated types.