9/28/2023 EE400/590 - Fall 2004 1
SystemVerilog
Fall 2004
University of Washington
EE400/590
Dean Wen Chen
9/28/2023 EE400/590 - Fall 2004 2
Outline
 Introduction
 SystemVerilog enhancements overview
 Conclusion
9/28/2023 EE400/590 - Fall 2004 3
Introduction
 What is Verilog HDL?
 Verilog HDL is a Hardware Description Language
that can be used to model a digital system at
various levels of abstraction.
 What is SystemVerilog?
 SystemVerilog is an extensive set of
enhancements to the IEEE 1364 Verilog-2001
standard.
9/28/2023 EE400/590 - Fall 2004 4
A problem that needed solving
 As design sizes have increased, several
things increased as well:
 Number of lines of RTL design code size
 Verification code size
 Simulation time
9/28/2023 EE400/590 - Fall 2004 5
Alternatives to the problem
 SystemC:
 modeling full systems at a much higher level of
abstraction.
 Hardware Verification Languages (HVLs)
 Such as Verisity's e and Synopsys' Vera
 More concisely describe complex verification
routines
 Require to work with multiple languages
 Increased simulation time.
9/28/2023 EE400/590 - Fall 2004 6
SystemVerilog's roots
 Instead of re-invent the wheel, Accellera
relied on donations of technology from a
number of companies.
 High-level modeling constructs : Superlog
language developed by Co-Design
 Testbench constructs : Open Vera language
and VCS DirectC interface technology by Synopsys
 Assertions : OVA from Verplex, ForSpec from
Intel, Sugar (renamed PSL) from IBM, and OVA
from Synopsys
9/28/2023 EE400/590 - Fall 2004 7
Compatibility with Verilog-2001
 fully compatible with the IEEE 1364-
2001 Verilog standard.
 There is one caveat to this backward
compatibility. SystemVerilog adds
several new keywords to the Verilog
language. Identifier maybe used in an
existing model. Compatibility switches
can be used to deal with this problem.
9/28/2023 EE400/590 - Fall 2004 8
Assertions
 Special language constructs to verify
design behavior.
 Example:
9/28/2023 EE400/590 - Fall 2004 9
Assertions (Cont..)
 Assertions can be defined outside of
Verilog modules, and then bind them to
a specific module or module instance.
This allows verification engineers to add
assertions to existing Verilog models,
without having to change the model in
any way
9/28/2023 EE400/590 - Fall 2004 10
Interfaces
 High level of abstraction for module
connections.
 Modules can use an interface the same as if it
were a single port.
 Can be considered a bundle of wires.
Interfaces go far beyond just representing
bundles of interconnecting signals, however.
An interface
 Can also include functionality and built-in
protocol checking.
9/28/2023 EE400/590 - Fall 2004 11
Interface Example
interface simple_bus; // Define the interface
logic req, gnt;
logic [7:0] addr, data;
logic [1:0] mode;
logic start, rdy;
endinterface: simple_bus
module memMod(simple_bus a, // Use the
simple_bus interface
input bit clk);
logic avail;
// a.req is the req signal in the ’simple_bus’
interface
always @(posedge clk) a.gnt <= a.req & avail;
endmodule
module cpuMod(simple_bus b,
input bit clk);
...
endmodule
module top;
logic clk = 0;
simple_bus sb_intf; // Instantiate
the interface
memMod mem(sb_intf, clk);
cpuMod cpu(.b(sb_intf), .clk(clk));
endmodule
9/28/2023 EE400/590 - Fall 2004 12
Global declarations
 Allows global variables, type definitions,
functions and other information to be
declared, that are shared by all levels of
hierarchy in the design.
9/28/2023 EE400/590 - Fall 2004 13
Relaxed data type rules
 Allow variable types to be used in
almost any context and make it much
easier to write hardware models
without concern about which data type
class to use
 Net data types (such as wire, wand,
wor)
 Variables (such as reg, integer)
9/28/2023 EE400/590 - Fall 2004 14
Data Types
 Adds several new data types, which allow hardware to be modeled at
more abstract levels, using data types more intuitive to C
programmers
 class — an object-oriented dynamic data type, similar to C++ and Java.
 byte — a 2-state signed variable, that is defined to be exactly 8 bits.
 shortint — a 2-state signed variable, that is defined to be exactly 16 bits.
 int — a 2-state signed variable, similar to the "int" data type in C, but defined to be
exactly 32 bits.
 longint — a 2-state signed variable, that is defined to be exactly 64 bits.
 bit — a 2-state unsigned data type of any vector width.
 logic — a 4-state unsigned data type of any vector width, equivalent to the Verilog
"reg" data type.
 shortreal — a 2-state single-precision floating-point variable, the same as the "float"
type in C.
 void — represents no value, and can be specified as the return value of a function.
 User defined types
 Typedef unsigned int uint;
uint a, b;
9/28/2023 EE400/590 - Fall 2004 15
Data Types (Cont..)
 Enumerated types
 enum {red, green, blue} RGB;
 Built in methods to work with
 Structures and unions
Struct {
bit[15:0 ]opcode;
Logic[23:0] address
} IR;
IR.opcode = 1 or IR = {5, 200};
9/28/2023 EE400/590 - Fall 2004 16
Casting
 SystemVerilog adds the ability to change the type,
vector size or "signedness" of a value using a cast
operation. To remain backward compatible with the
existing Verilog language, casting in SystemVerilog
uses a different syntax than C.
9/28/2023 EE400/590 - Fall 2004 17
Arrays
 dynamic arrays
 one-dimensional arrays where the size of the array
can be changed dynamically
 associative arrays
 one-dimensional sparse arrays that can be indexed
using values such as enumerated type names.
 exists(), first(), last(), next(), prev() and delete().
9/28/2023 EE400/590 - Fall 2004 18
Classes
 Can contain data declarations (referred to as "properties")
 Can contain functions for operating on the data (referred to as
"methods").
 Can have inheritance and public or private protection, as in C++.
 Allow objects to be dynamically created, deleted and assigned values.
 Objects can be accessed via handles, which provide a safe form of
pointers.
 Memory allocation, de-allocation and garbage collection are
automatically handled, preventing the possibility of memory leaks.
 Classes are dynamic by nature, instead of static. They are ideal for
test-bench modeling. Therefore, they are not considered synthesizable
constructs.
 Intended for verification routines and highly abstract system-level
modeling.
9/28/2023 EE400/590 - Fall 2004 19
Class example:
9/28/2023 EE400/590 - Fall 2004 20
String data type
 Defined as a built-in class.
 The string data type contains a variable length array
of ASCII characters. Each time a value is assigned to
the string, the length of the array is automatically
adjusted.
 Operations:
 Standard Verilog operators: =, ==, !=, <, <=, >, >=, {,},
{{}}.
 Methods: len(), putc(), getc(), toupper(), tolower(),
compare(), icompare(), substr(), atoi(), atohex(), atooct(),
atobin(), atoreal(), itoa(), hextoa(), octtoa(), bintoa() and
realtoa().
9/28/2023 EE400/590 - Fall 2004 21
Operators
 ++ and -- increment and decrement
operators
 +=, -=, *=, /=, %=, &=, ^=, |=, <<=,
>>=, <<<= and >>>= assignment
operators
9/28/2023 EE400/590 - Fall 2004 22
Unique and priority decision statements
 Adds the ability to explicitly specify when each
branch of a decision statement is unique or
requires priority evaluation.
 using the keywords "unique" and "priority."
These keywords affect simulators, synthesis
compilers, formal verifiers and other tools,
ensuring that all tools interpret the model the
same way.
9/28/2023 EE400/590 - Fall 2004 23
Enhanced for loops
 Allow the loop control variable to be declared as part of the for loop,
and allows the loop to contain multiple initial and step assignments.
for (int i=1, shortint count=0; i*count < 125; i++, count+=3)
 Bottom testing loops
 adds a do-while loop, which tests the loop condition at the end of executing
code in the loop.
 Jump statements
 adds "break" and "continue" keywords, which do not require the use of
block names, and a "return" keyword, which can be used to exit a task or
function at any point.
 Final blocks
 Execute at the very end of simulation, just before simulation exits. Final
blocks can be used in verification to print simulation results, such as code
coverage reports.
9/28/2023 EE400/590 - Fall 2004 24
Hardware-specific procedures
 adds three new procedures to explicitly
indicate the intent of the logic:
 always_ff — the procedure is intended to
represent sequential logic
 always_comb —: the procedure is
intended to represent combinational logic
 always_latch — the procedure is intended
to represent latched logic.
9/28/2023 EE400/590 - Fall 2004 25
Task and function enhancements
 Function return values can have a "void" return type. Void
functions can be called the same as a Verilog task.
 Functions can have any number of inputs, outputs and inouts,
including none.
 Values can be passed to a task or function in any order, using
the task/function argument names. The syntax is the same as
named module port connections.
 Task and function input arguments can be assigned a default
value as part of the task/function declaration. This allows the
task or function to be called without passing a value to each
argument.
 Task or function arguments can be passed by reference, instead
of copying the values in or out of the task or function. To use
pass by reference, the argument direction is declared as a "ref,"
instead of input, output or inout.
9/28/2023 EE400/590 - Fall 2004 26
Enhanced fork-join
 Adds fork-join_none, and fork-join_any blocks.
 join_none — statements that follow the fork-join_none
are not blocked from execution while the parallel threads
are executing. Each parallel thread is an independent,
dynamic process.
 join_any — statements which follow a fork-join_any are
blocked from execution until the first of any of the
threads has completed execution.
9/28/2023 EE400/590 - Fall 2004 27
Inter-process synchronization
 semaphore :
 Serve as a bucket with a fixed number of "keys."
 Built-in methods for working with semaphores: new(), get(), put() and
try_get().
 mailbox
 Allows messages to be exchanged between processes. A message can be
added to the mailbox at anytime by one process, and retrieved anytime
later by another process.
 Mailboxes behave like FIFOs (First-In, First-Out).
 built-in methods: new(), put(), tryput(), get(), peek(), try_get() and
try_peek().
 Event
 The Verilog "event" type is a momentary flag that has no logic value and no
duration.
 SystemVerilog enhances the event data type by allowing events to have
persistence throughout the current simulation time step. This allows the
event to be checked after it is triggered.
9/28/2023 EE400/590 - Fall 2004 28
Constrained random values
 adds two random number classes,
"rand" and "randc,"
9/28/2023 EE400/590 - Fall 2004 29
Testbench program block
 Contains a single initial block.
 Executes events in a "reactive phase" of the
current simulation time, appropriately
synchronized to hardware simulation events.
 Can use a special "$exit" system task that will
wait to exit simulation until after all
concurrent program blocks have completed
execution (unlike "$finish," which exits
simulation immediately).
9/28/2023 EE400/590 - Fall 2004 30
Clocking domains
 Clocking domains allow the testbench to be
defined using a cycle-based methodology,
rather than the traditional event-based
methodology of defining specific transition
times for each test signal.
 A clocking domain can define detailed skew
information
 Greatly simplify defining a testbench that
does not have race conditions with the design
being tested.
9/28/2023 EE400/590 - Fall 2004 31
Clocking domains (Cont..)
9/28/2023 EE400/590 - Fall 2004 32
Direct Programming Interface (DPI)
 To directly call functions written C, C++ or SystemC,
without having to use the complex Verilog
Programming Language Interface (PLI).
 Values can be passed directly to the foreign language
function, and values can be received from the
function.
 The foreign language function can also call Verilog
tasks and functions, which gives the foreign language
functions access to simulation events and simulation
time.
 The SystemVerilog DPI provides a bridge between
high-level system design using C, C++ or SystemC
and lower-level RTL and gate-level hardware design.
9/28/2023 EE400/590 - Fall 2004 33
Conclusion
 SystemVerilog provides a major set of extensions to the Verilog-2001
standard. These extensions allow modeling and verifying very large
designs more easily and with less coding.
 SystemVerilog extends the modeling aspects of Verilog, and adds a
Direct Programming Interface which allows C, C++, SystemC and
Verilog code to work together without the overhead of the Verilog PLI.
 SystemVerilog bridges the gap between hardware design engineers and
system design engineers. SystemVerilog also significantly extends the
verification aspects of Verilog by incorporating the capabilities of Vera
and powerful assertion constructs.
 Adding these SystemVerilog extensions to Verilog creates a whole new
type of engineering language, an HDVL, or Hardware Description and
Verification Language. This unified language will greatly increase the
ability to model huge designs, and verify that these designs are
functionally correct.
9/28/2023 EE400/590 - Fall 2004 34
References
 An overview of SystemVerilog 3.1
By Stuart Sutherland, EEdesign
May 21, 2003 (4:09 PM)
 System Verilog by Narges Baniasadi,
University of Tehran Spring 2004

SystemVerilog-20041201165354.ppt

  • 1.
    9/28/2023 EE400/590 -Fall 2004 1 SystemVerilog Fall 2004 University of Washington EE400/590 Dean Wen Chen
  • 2.
    9/28/2023 EE400/590 -Fall 2004 2 Outline  Introduction  SystemVerilog enhancements overview  Conclusion
  • 3.
    9/28/2023 EE400/590 -Fall 2004 3 Introduction  What is Verilog HDL?  Verilog HDL is a Hardware Description Language that can be used to model a digital system at various levels of abstraction.  What is SystemVerilog?  SystemVerilog is an extensive set of enhancements to the IEEE 1364 Verilog-2001 standard.
  • 4.
    9/28/2023 EE400/590 -Fall 2004 4 A problem that needed solving  As design sizes have increased, several things increased as well:  Number of lines of RTL design code size  Verification code size  Simulation time
  • 5.
    9/28/2023 EE400/590 -Fall 2004 5 Alternatives to the problem  SystemC:  modeling full systems at a much higher level of abstraction.  Hardware Verification Languages (HVLs)  Such as Verisity's e and Synopsys' Vera  More concisely describe complex verification routines  Require to work with multiple languages  Increased simulation time.
  • 6.
    9/28/2023 EE400/590 -Fall 2004 6 SystemVerilog's roots  Instead of re-invent the wheel, Accellera relied on donations of technology from a number of companies.  High-level modeling constructs : Superlog language developed by Co-Design  Testbench constructs : Open Vera language and VCS DirectC interface technology by Synopsys  Assertions : OVA from Verplex, ForSpec from Intel, Sugar (renamed PSL) from IBM, and OVA from Synopsys
  • 7.
    9/28/2023 EE400/590 -Fall 2004 7 Compatibility with Verilog-2001  fully compatible with the IEEE 1364- 2001 Verilog standard.  There is one caveat to this backward compatibility. SystemVerilog adds several new keywords to the Verilog language. Identifier maybe used in an existing model. Compatibility switches can be used to deal with this problem.
  • 8.
    9/28/2023 EE400/590 -Fall 2004 8 Assertions  Special language constructs to verify design behavior.  Example:
  • 9.
    9/28/2023 EE400/590 -Fall 2004 9 Assertions (Cont..)  Assertions can be defined outside of Verilog modules, and then bind them to a specific module or module instance. This allows verification engineers to add assertions to existing Verilog models, without having to change the model in any way
  • 10.
    9/28/2023 EE400/590 -Fall 2004 10 Interfaces  High level of abstraction for module connections.  Modules can use an interface the same as if it were a single port.  Can be considered a bundle of wires. Interfaces go far beyond just representing bundles of interconnecting signals, however. An interface  Can also include functionality and built-in protocol checking.
  • 11.
    9/28/2023 EE400/590 -Fall 2004 11 Interface Example interface simple_bus; // Define the interface logic req, gnt; logic [7:0] addr, data; logic [1:0] mode; logic start, rdy; endinterface: simple_bus module memMod(simple_bus a, // Use the simple_bus interface input bit clk); logic avail; // a.req is the req signal in the ’simple_bus’ interface always @(posedge clk) a.gnt <= a.req & avail; endmodule module cpuMod(simple_bus b, input bit clk); ... endmodule module top; logic clk = 0; simple_bus sb_intf; // Instantiate the interface memMod mem(sb_intf, clk); cpuMod cpu(.b(sb_intf), .clk(clk)); endmodule
  • 12.
    9/28/2023 EE400/590 -Fall 2004 12 Global declarations  Allows global variables, type definitions, functions and other information to be declared, that are shared by all levels of hierarchy in the design.
  • 13.
    9/28/2023 EE400/590 -Fall 2004 13 Relaxed data type rules  Allow variable types to be used in almost any context and make it much easier to write hardware models without concern about which data type class to use  Net data types (such as wire, wand, wor)  Variables (such as reg, integer)
  • 14.
    9/28/2023 EE400/590 -Fall 2004 14 Data Types  Adds several new data types, which allow hardware to be modeled at more abstract levels, using data types more intuitive to C programmers  class — an object-oriented dynamic data type, similar to C++ and Java.  byte — a 2-state signed variable, that is defined to be exactly 8 bits.  shortint — a 2-state signed variable, that is defined to be exactly 16 bits.  int — a 2-state signed variable, similar to the "int" data type in C, but defined to be exactly 32 bits.  longint — a 2-state signed variable, that is defined to be exactly 64 bits.  bit — a 2-state unsigned data type of any vector width.  logic — a 4-state unsigned data type of any vector width, equivalent to the Verilog "reg" data type.  shortreal — a 2-state single-precision floating-point variable, the same as the "float" type in C.  void — represents no value, and can be specified as the return value of a function.  User defined types  Typedef unsigned int uint; uint a, b;
  • 15.
    9/28/2023 EE400/590 -Fall 2004 15 Data Types (Cont..)  Enumerated types  enum {red, green, blue} RGB;  Built in methods to work with  Structures and unions Struct { bit[15:0 ]opcode; Logic[23:0] address } IR; IR.opcode = 1 or IR = {5, 200};
  • 16.
    9/28/2023 EE400/590 -Fall 2004 16 Casting  SystemVerilog adds the ability to change the type, vector size or "signedness" of a value using a cast operation. To remain backward compatible with the existing Verilog language, casting in SystemVerilog uses a different syntax than C.
  • 17.
    9/28/2023 EE400/590 -Fall 2004 17 Arrays  dynamic arrays  one-dimensional arrays where the size of the array can be changed dynamically  associative arrays  one-dimensional sparse arrays that can be indexed using values such as enumerated type names.  exists(), first(), last(), next(), prev() and delete().
  • 18.
    9/28/2023 EE400/590 -Fall 2004 18 Classes  Can contain data declarations (referred to as "properties")  Can contain functions for operating on the data (referred to as "methods").  Can have inheritance and public or private protection, as in C++.  Allow objects to be dynamically created, deleted and assigned values.  Objects can be accessed via handles, which provide a safe form of pointers.  Memory allocation, de-allocation and garbage collection are automatically handled, preventing the possibility of memory leaks.  Classes are dynamic by nature, instead of static. They are ideal for test-bench modeling. Therefore, they are not considered synthesizable constructs.  Intended for verification routines and highly abstract system-level modeling.
  • 19.
    9/28/2023 EE400/590 -Fall 2004 19 Class example:
  • 20.
    9/28/2023 EE400/590 -Fall 2004 20 String data type  Defined as a built-in class.  The string data type contains a variable length array of ASCII characters. Each time a value is assigned to the string, the length of the array is automatically adjusted.  Operations:  Standard Verilog operators: =, ==, !=, <, <=, >, >=, {,}, {{}}.  Methods: len(), putc(), getc(), toupper(), tolower(), compare(), icompare(), substr(), atoi(), atohex(), atooct(), atobin(), atoreal(), itoa(), hextoa(), octtoa(), bintoa() and realtoa().
  • 21.
    9/28/2023 EE400/590 -Fall 2004 21 Operators  ++ and -- increment and decrement operators  +=, -=, *=, /=, %=, &=, ^=, |=, <<=, >>=, <<<= and >>>= assignment operators
  • 22.
    9/28/2023 EE400/590 -Fall 2004 22 Unique and priority decision statements  Adds the ability to explicitly specify when each branch of a decision statement is unique or requires priority evaluation.  using the keywords "unique" and "priority." These keywords affect simulators, synthesis compilers, formal verifiers and other tools, ensuring that all tools interpret the model the same way.
  • 23.
    9/28/2023 EE400/590 -Fall 2004 23 Enhanced for loops  Allow the loop control variable to be declared as part of the for loop, and allows the loop to contain multiple initial and step assignments. for (int i=1, shortint count=0; i*count < 125; i++, count+=3)  Bottom testing loops  adds a do-while loop, which tests the loop condition at the end of executing code in the loop.  Jump statements  adds "break" and "continue" keywords, which do not require the use of block names, and a "return" keyword, which can be used to exit a task or function at any point.  Final blocks  Execute at the very end of simulation, just before simulation exits. Final blocks can be used in verification to print simulation results, such as code coverage reports.
  • 24.
    9/28/2023 EE400/590 -Fall 2004 24 Hardware-specific procedures  adds three new procedures to explicitly indicate the intent of the logic:  always_ff — the procedure is intended to represent sequential logic  always_comb —: the procedure is intended to represent combinational logic  always_latch — the procedure is intended to represent latched logic.
  • 25.
    9/28/2023 EE400/590 -Fall 2004 25 Task and function enhancements  Function return values can have a "void" return type. Void functions can be called the same as a Verilog task.  Functions can have any number of inputs, outputs and inouts, including none.  Values can be passed to a task or function in any order, using the task/function argument names. The syntax is the same as named module port connections.  Task and function input arguments can be assigned a default value as part of the task/function declaration. This allows the task or function to be called without passing a value to each argument.  Task or function arguments can be passed by reference, instead of copying the values in or out of the task or function. To use pass by reference, the argument direction is declared as a "ref," instead of input, output or inout.
  • 26.
    9/28/2023 EE400/590 -Fall 2004 26 Enhanced fork-join  Adds fork-join_none, and fork-join_any blocks.  join_none — statements that follow the fork-join_none are not blocked from execution while the parallel threads are executing. Each parallel thread is an independent, dynamic process.  join_any — statements which follow a fork-join_any are blocked from execution until the first of any of the threads has completed execution.
  • 27.
    9/28/2023 EE400/590 -Fall 2004 27 Inter-process synchronization  semaphore :  Serve as a bucket with a fixed number of "keys."  Built-in methods for working with semaphores: new(), get(), put() and try_get().  mailbox  Allows messages to be exchanged between processes. A message can be added to the mailbox at anytime by one process, and retrieved anytime later by another process.  Mailboxes behave like FIFOs (First-In, First-Out).  built-in methods: new(), put(), tryput(), get(), peek(), try_get() and try_peek().  Event  The Verilog "event" type is a momentary flag that has no logic value and no duration.  SystemVerilog enhances the event data type by allowing events to have persistence throughout the current simulation time step. This allows the event to be checked after it is triggered.
  • 28.
    9/28/2023 EE400/590 -Fall 2004 28 Constrained random values  adds two random number classes, "rand" and "randc,"
  • 29.
    9/28/2023 EE400/590 -Fall 2004 29 Testbench program block  Contains a single initial block.  Executes events in a "reactive phase" of the current simulation time, appropriately synchronized to hardware simulation events.  Can use a special "$exit" system task that will wait to exit simulation until after all concurrent program blocks have completed execution (unlike "$finish," which exits simulation immediately).
  • 30.
    9/28/2023 EE400/590 -Fall 2004 30 Clocking domains  Clocking domains allow the testbench to be defined using a cycle-based methodology, rather than the traditional event-based methodology of defining specific transition times for each test signal.  A clocking domain can define detailed skew information  Greatly simplify defining a testbench that does not have race conditions with the design being tested.
  • 31.
    9/28/2023 EE400/590 -Fall 2004 31 Clocking domains (Cont..)
  • 32.
    9/28/2023 EE400/590 -Fall 2004 32 Direct Programming Interface (DPI)  To directly call functions written C, C++ or SystemC, without having to use the complex Verilog Programming Language Interface (PLI).  Values can be passed directly to the foreign language function, and values can be received from the function.  The foreign language function can also call Verilog tasks and functions, which gives the foreign language functions access to simulation events and simulation time.  The SystemVerilog DPI provides a bridge between high-level system design using C, C++ or SystemC and lower-level RTL and gate-level hardware design.
  • 33.
    9/28/2023 EE400/590 -Fall 2004 33 Conclusion  SystemVerilog provides a major set of extensions to the Verilog-2001 standard. These extensions allow modeling and verifying very large designs more easily and with less coding.  SystemVerilog extends the modeling aspects of Verilog, and adds a Direct Programming Interface which allows C, C++, SystemC and Verilog code to work together without the overhead of the Verilog PLI.  SystemVerilog bridges the gap between hardware design engineers and system design engineers. SystemVerilog also significantly extends the verification aspects of Verilog by incorporating the capabilities of Vera and powerful assertion constructs.  Adding these SystemVerilog extensions to Verilog creates a whole new type of engineering language, an HDVL, or Hardware Description and Verification Language. This unified language will greatly increase the ability to model huge designs, and verify that these designs are functionally correct.
  • 34.
    9/28/2023 EE400/590 -Fall 2004 34 References  An overview of SystemVerilog 3.1 By Stuart Sutherland, EEdesign May 21, 2003 (4:09 PM)  System Verilog by Narges Baniasadi, University of Tehran Spring 2004