User defined Types in SystemVerilog
Verilog
typedef int unsigned uint;
uint i; // unsigned integer
A user defined type can be used before it is created provided it is first defined using empty typedef.
typedef flag_t;
flag_t = '0;
typedef logic [3:0] flag_t ;
type definitions can be declared either externally or in packages or locally.
SV Enumerated Types provide a way to declare abstract variables that can have listed set of values. Syntax is
enum (enum_base_type) { enum_name_declarations } enum_name
-
enum {ADD, SUB, DIVI, MUL} opcode; // ADD is assigned value 1, SUB 2, DIVI 3 and MUL 4
-
enum {ADD=4, SUB, DIVI=10, MUL} opcode; // ADD is 4, SUB is 5, DIVI is 10, MUL is 11
Verilog does not support enumerated types but supports parameter and 'define macros to make the code easier to read - for example, FSM states can be defined as parameters while `define would be used to define a error condition. The disadvantage is that the state and nextstate variables can be declared using only predefined datatypes and the list of values they can take cannot be limited.
-
enum logic [3:0] {IDLE = 4'b001,
-
XMT_ADDR = 4'b0010,
-
XMT_DATA = 4'b0100,
-
WAIT_FOR_ACK = 4'b1000} State, NextState;
SV enum types limit the state variables to the enum values maintaining consistency for synthesis and simulation.
Enumerated types can also be declared as user defined type using typedef.
typedef enum {TRUE, FALSE} boolean;
boolean flag, result;
Enumerated types are strongly typed and cannot be assigned a value outside it's legal list. As a result, arithmetical operations such as state++ are illegal as it can go out of bounds. Static and Dynamic casting to an enumerated type is allowed.
-
typedef enum {IDLE, XMT, WAIT, DONE} states_t;
-
states_t state, next_state;
-
-
next_state = states_t'(state++); // Legal, casting can cause out-of-bounds !!
-
$cast(next_state, state + 1); // Legal, will report error if out of bounds
SV includes a set of specialized methods to enable iterations over values of the enumerated types.
| Enumerated Type Methods | Description |
|
<enum_var>.first
|
returns first enum value in the list of enumerated types |
|
<enum_var>.last
|
returns last enum value in the list |
|
<enum_var>.next(N) |
return next value in the list. If a number is added to next, it returns the Nth next value from the current value in the list. If the Nth next value is not legal, it returns the first value in the list. |
|
<enum_var>.prev(N) |
return previous value in the list. Similar to next, except if Nth previous value is not legal, returns last value in the list. |
|
<enum_var>.name |
returns string representation of the label given to enum value. If label is absent, returns empty string. Can be used to display current value of enum_variable using $display. |
Type casting in SystemVerilog
SystemVerilog adds a cast operator ( ' , forward tick) that supports the ability to cast a value to a different type. The expression to be cast should be enclosed in parentheses or within concatenation or replication braces and is self-determined. The syntax is
<casting_type> '(<expression>)
shortint'(2 * 4) // cast result of 2 *4 to shortint
In addition to this, SV also offers support to cast a unsigned value to signed (or vice versa) and to cast a vector to a different size.
<size>'(<expression>)
logic [7:0] x;
x = 8'(5) // cast literal value 5 to 8-bits wide
<sign>'(<expression>)
y = signed'(x)
Static casting does not include run-time checking i.e. if the cast results in a illegal value during run time, SV does not report any error. For more robust checking, SV offers a dynamic cast function $cast that performs dynamic run time checking. The syntax of $cast is
$cast (dest_var, source_exp) where
dest_var is the variable to which assignment is made and
source_exp is expression that is assigned
-
int x, y;
-
always @(posedge clk)
-
$cast(y, 2.5 * x);
$cast can also be defined as a task and reports a error if the cast value is illegal during runtime. An example would be assigning a cast value to an enumerated type that is not in the set. When called as a function, $cast returns a '1' if the cast was successful or a '0' if it fails. When called as a function, $cast does not report any runtime error and leaves the destination variable unchanged.
-
typedef enum { ADD, MUL, DIVI, SUB, MOD } Opcode;
-
Opcode operat_e;
-
$cast( operat_e, 2 + 1 ); // Dynamic cast : assigns 3 => DIVI to operat_e
-
operat_e = Opcode'(2+1) // Static cast
Type casting can also applied to unpacked arrays and structs known as bit-stream casting. We will visit this when we cover arrays and structs.
Sphere: Related Content
Inertial and Transport Delays & the Event Queue in Verilog
Simulation cycle consists of two phases - a signal update phase where the simulation time is moved to the earliest scheduled transaction and values in all transactions scheduled for this time are applied to their corresponding signals and a process evaluation phase where signal assignments trigger events and all processes responding to these events are executed.
Scheduling and assigning signal values largely depends on the delay mechanism used. Transport Delay models are ideal and any change in the input is propagated to the output, no matter how small the duration of the change. Any pending transactions on a driver that are scheduled for a time late than or equal to the new transaction are deleted.
Transport Delay Illustration
Inertial Delay models depict real hardware and any change in input value is propagated to the output only if the change is stable for a duration greater than the propagation delay of the model. An inertially delayed signal assignment involves looking at pending transactions when adding a new transaction.
All transactions scheduled for a time equal to or later than the current transaction (t1) are deleted as in transport delay model. If the pulse rejection time is tr, any pending transactions between t1-tr and tr driving the current transaction value are retained and all other transactions are removed.
Inertial Delay Illustration
Verilog
The Verilog event queue is logically segmented into five different regions. Events are added to any of the five regions but are only removed from the active region.
- Events that occur at the current simulation time and can be processed in any order. These are the active events. Blocking assignments, evaluation of RHS of nonblocking assignments, conitnuous assignments, $display commads are executed in this queue.
- Events that occur at the current simulation time, but that shall be processed after all the active events are processed. These are the inactive events. Blocking assignments with #0 delays fall in this category, they are not recommended as they add unnecessary events in the queue and make simulations run slower. For more details, please refer to Cliff Cummings paper on NonBlocking Assignments.
- Events that have been evaluated during some previous simulation time, but that shall be assigned at this simulation time after all the active and inactive events are processed. These are the non blocking assign LHS update events.
- Events that shall be processed after all the active, inactive, and non blocking assign update events are processed. These are the monitor events. $monitor and $strobe are executed in this queue.
- Events that occur at some future simulation time. These are the future events. Future events are divided into future inactive events, and future non blocking assignment update events.
The processing of all the active events is called a simulation cycle.
Sphere: Related Content