System Verilog And Its Features And Datatypes

Q1) What is system Verilog and tell its features ?

 System Verilog is basically an extension to Verilog , Verilog was mainly for RTL design , but it
had limitations when it came to testbenches and complex verification. Hence system Verilog
was introduced to fix this , it had features like new data types were introduced , it used
object oriented programming , constrained randomization to generate wide varity of input
scenarios , functional coverage and interfaces, these features make it powerfull for both rtl
design and functional verification

Q2) why are we going for sv? What are the limitations of Verilog

 "Uh, so in Verilog we could only do RTL design, like modeling hardware. But when it came to
verification, Verilog was very limited — no OOP, no randomization, no coverage, no
assertions. So, debugging big SoCs was really hard. That’s why SystemVerilog came, it adds
verification features like classes, random stimulus, coverage, assertions… so both design and
verification can be done in one language."

Q3) What are the different data types in SV?

 "Uh, so in Verilog we basically had only 4-state datatypes… like reg, wire, integer, time, and
real. All of them could take 0, 1, X, Z. The issue was that they were a bit restrictive — for
example wire was used only for continuous assignments and connecting modules, while reg
was used only inside procedural blocks like always or initial. So if I wanted to use the same
signal both ways, it was kind of confusing."
 "SystemVerilog introduced logic, which is also a 4-state datatype, but it removed that
restriction. With logic I can use it in both continuous assignments and procedural blocks. So
basically it unified reg and wire and made coding simpler."
 "Apart from that, SystemVerilog added more types —

 2-state datatypes → like bit, byte, shortint, int, longint. These only store 0 and 1, so no X/Z.
That helps in faster simulation because we don’t track unknowns.

 User-defined datatypes → like typedef (to create our own names for types), enum
(enumerations for state machines → makes code more readable), struct and union (to group
signals together, just like in C).

 Strings → Verilog didn’t have proper string handling, but in SV we can directly declare string
s; and use it for printing, comparisons, etc.

 Packages → these are used to store common definitions like typedefs, parameters, enums, so
that we can reuse them across multiple files or testbenches. It makes the code modular and
clean."**

Arrays, queues, collection types and methods

Q1) What is a packed array?

 Uh… packed array means the elements are stored bit by bit continuously, just like vectors in
Verilog. Because of that, we can use them in arithmetic operations directly. For example, bit
[7:0] data; is a packed 8-bit array

Q2) What is a multidimensional array?

 “In SystemVerilog, we can declare arrays with more than one dimension, like rows and
columns. For example, int matrix [3][4]; is 3 rows and 4 columns. It’s useful to store data in
table form, like memories.”

Q3) What is the difference between dynamic arrays and queues?

 Dynamic Array:
It’s like a normal array but with a size that we can change at runtime. Initially, we declare it
without a size, like int arr[];. Then we allocate memory using new[], for example arr =
new[10];. If I want a bigger size, I again do arr = new[20];. But the catch is — if I resize, the
old data may be lost unless I copy it manually. So resizing is kind of explicit and fixed.
 Queue:
A queue is like a list that grows and shrinks automatically. I don’t need to call new[]. I can just
push_back to add elements, and pop_front to remove elements. It’s very flexible, especially
when I don’t know how many elements I’ll get, like a stream of transactions.
 So basically — dynamic arrays are resizable but only when I explicitly call new[], while
queues are self-adjusting — they resize automatically when I insert or remove data.”

Q4) Associative array ?

 Associative arrays in SystemVerilog are arrays that don’t use only numbers as indexes, they
can use other things like integers, strings, or enums as keys. The size is not fixed — it grows
whenever you add new elements. For example, instead of writing marks[0] = 90;, you can
write marks["Rahul"] = 90;. This makes it easy when you want to store data with names or
IDs. SystemVerilog also gives some built-in functions like .exists(key) to check if a key is there,
.delete(key) to remove, and .num() to know how many elements are stored.

tasks, functions

Q1) What are Task and functions with respect to both Verilog and in SV enhancements?

In Verilog:

 Function → Executes in zero simulation time, no delays or event controls, returns only one
value.

 Task → Can have delays, event controls, call other tasks/functions, but cannot return a value
directly (only via output/inout arguments).
In SystemVerilog (Enhancements):

 Both tasks and functions are automatic by default (re-entrant → safe to call in parallel).

 Functions can return any data type (struct, array, class object, etc.), not just single values.

 Tasks can now return values using return.

 Both can use input, output, inout, and ref arguments.

 Both can be defined inside classes (important for OOP testbenches).

Q2) Void function and return statement ?

Void Function in SystemVerilog

 A void function is a function that does not return any value.

 It’s mostly used when you just want to perform some operation (like printing, updating
variables, logging info) but you don’t need a return.

Return Statement

 The return statement is used in a function to give back a value to the caller.

 In Verilog, only functions could return a single value. Tasks couldn’t return directly.

 In SystemVerilog, both tasks and functions can use return.

Q3) Passing Arugements and automatic functions/tasks

 In Verilog

 We can pass arguments into tasks and functions using:

1. input → values go into the task/function.

2. output → values come out of the task/function.

3. inout → values can go both in and out.

 In SystemVerilog (enhanced)

 Same as Verilog → input, output, inout.

 But SV also gives extra ways to pass:

1. ref → pass by reference → no copy, directly points to the original variable.

 So if we change inside the task, the change is reflected outside.

2. const ref → same as ref, but read-only.

 We can read it but cannot modify inside the task/function.

Automatic tasks and functions

  In Verilog, when we write a task or function, by default it is static. That means → if the
task/function is called multiple times (maybe from parallel processes), all those calls will
share the same variables inside. So one call can overwrite the values of another.
 But when we use the keyword automatic, each time the task/function is called, it creates a
new copy of its variables. So every call works independently without disturbing others.
 Verilog, you had to explicitly write automatic for both tasks and functions.
 In SystemVerilog, functions are automatic by default

Q4) Passing arguments by name , by value and default ?

1. Passing by name → In Verilog, when we pass arguments, it was only by order… so if we mess
up the order, whole simulation goes wrong. In SystemVerilog, they fixed this by passing by
name where we just match with names like .a(5), .b(10). So no confusion.
2. Default arguments → In Verilog, every time we had to give all arguments while calling the
function/task. If we forgot one, it was error. SystemVerilog introduced default arguments, so
we can assign a default value inside the function itself. If user doesn’t pass it, that default is
used. Much easier.
3. Passing by value → In Verilog, arguments were mostly treated like wires and always passed
by reference kinda behavior, so changes inside could affect outside. In SystemVerilog, we can
specify pass by value, meaning only a copy is given, so the original variable outside won’t be
touched

Interfaces and mod ports clocking blocks

1q) System Verilog interface

So in Verilog, whenever we had to connect DUT (Design Under Test) with the testbench, we had to
pass so many signals one by one like clk, reset, addr, data, valid, etc. This became messy because for
every module instantiation, we had to list out all the ports, and if we missed one or mismatched
direction, debugging was painful.

To fix this, SystemVerilog introduced interface.

• An interface is basically like a bundle where we group related signals together.

Instead of connecting 10–15 signals separately, we just pass a single interface handle.

• Inside the interface, we can also write logic like tasks, functions, assertions, clocking
blocks, even modports to control access (like driver can only drive, monitor can only sample).

• This makes the design more modular, readable, and less error-prone.

• So in testbenches, we don’t manually connect each wire; we just connect the

interface, and everything inside is available.

Q2) Modports
So in Verilog, when we connected signals, there was no strict rule on who can drive and who can only
read. For example, the driver and monitor could both accidentally drive the same signal, which
creates conflicts. Debugging such bugs was painful.

To fix this, SystemVerilog added modports inside an interface.

• A modport is like a “view” or a “role” that defines how different components can use
the signals of the interface.

• For example:

• The driver should only drive signals (so signals will be output for driver).

• The monitor should only read signals (so signals will be input for monitor).

• Using modports, we make sure that driver doesn’t accidentally read-only signals and
monitor doesn’t accidentally drive them.

Q3) SV event scheduler

In Verilog, the event scheduling was sometimes confusing because all things (blocking, non-blocking,
continuous assignments, delays) were thrown into one big simulation cycle. This caused race
conditions — like whether a = b; happens before or after b = a; in different processes.

To fix this, SystemVerilog defined a clear event scheduler with 4 regions:

1. Active region – where blocking assignments (=) and immediate statements execute.

2. Inactive region – handles #0 delays and events that should not clash with active
region.

3. NBA (Non-blocking assignment) region – where all <= updates are done at the end of
the timestep, avoiding race conditions.

4. Observed/Reactive region – for assertions, monitors, and checking behavior after

DUT signals are updated.

Q4) Clocking block

In Verilog, when writing testbenches, sampling and driving signals with respect to a clock caused race
conditions. For example, TB might drive signals at the same time DUT is sampling them → wrong
results.

To fix this, SystemVerilog introduced clocking blocks.

• A clocking block groups signals and aligns their sampling/driving with a particular
clock edge.
 • Inside the clocking block, you can say:

• Inputs → sampled slightly before the clock edge (so we read stable values).

• Outputs → driven slightly after the clock edge (so DUT gets clean data).

• This avoids race conditions between DUT and testbench.

Q5) Input output skew

Problem in Verilog – TB and DUT could drive/sample signals at the same clock edge, causing race
conditions and unstable values.

2. SystemVerilog Fix – In clocking blocks we use input skew (when TB samples inputs)
and output skew (when TB drives outputs) relative to the clock.

3. Benefit – This ensures no races, stable sampling, and clean timing handshake
between DUT and testbench.