🔬 Chapter 1 — Verification Guidelines

📌 1.1.2 The Verification Plan

A Verification Plan defines what needs to be verified, how it will be verified, and how we will determine whether the design is sufficiently tested.

🧪 Main Verification Techniques

🔹 Directed Testing Specific test scenarios are created to verify known and important behaviors.

🔹 Random Testing Inputs are generated randomly to explore a wider range of possible scenarios and uncover unexpected bugs.

🔹 Assertions Assertions continuously check whether specific design properties or rules are satisfied during simulation.

💡 Simple Examples

Example 1 — Directed Test: For a FIFO, explicitly write data until it becomes FULL, then verify that another write is rejected.

Example 2 — Random Test: Generate random read/write operations and compare the DUT output against a reference model.

🎯 A good verification plan combines multiple techniques rather than relying on only one.

---

📚 1.2 The Verification Methodology Manual (VMM)

The Verification Methodology Manual (VMM) introduced a structured approach to developing reusable and scalable verification environments.

🔹 VMM techniques were originally developed for use with the OpenVera language.

🔹 In 2005, these techniques were extended for SystemVerilog.

🔹 VMM was preceded by the Reference Verification Methodology (RVM) for Vera.

🔗 Key Point

VMM helped establish systematic verification practices such as:

• 🧩 Reusable verification components
• 🧪 Constrained-random testing
• 📊 Functional coverage
• 🔍 Structured test environments
• 🎯 Scalable verification methodologies

💡 Why Methodologies Matter

Without a methodology, a large verification environment can become difficult to maintain and reuse.

Example 1: A reusable bus verification component can be used across multiple projects.

Example 2: A standardized test structure makes it easier for multiple verification engineers to work on the same project.

🚀 Next: Understanding how verification methodologies evolved toward modern SystemVerilog/UVM-based verification.

🔬 1.3 Basic Testbench Functionality

The primary purpose of a testbench is to determine the correctness of the Design Under Test (DUT).

A testbench accomplishes this through the following steps:

🧪 Basic Testbench Steps

1️⃣ Generate Stimulus Create input transactions that exercise the DUT.

2️⃣ Apply Stimulus to the DUT Drive the generated inputs into the DUT.

3️⃣ Capture the Response Observe and collect the DUT's outputs.

4️⃣ Check for Correctness Compare the actual response with the expected response and identify errors.

5️⃣ Measure Progress Against Verification Goals Determine how much of the design functionality has been exercised and whether the verification objectives are being achieved.

---

⚙️ Automatic vs Manual Tasks

Not every verification activity is performed automatically.

🔹 Some steps can be automated by the testbench, such as stimulus generation, monitoring, and checking.

🔹 Other decisions are manually determined by the verification engineer, such as defining scenarios, expected behavior, and verification goals.

📌 The verification methodology you choose determines how these activities are structured and carried out.

---

💡 Example 1 — ALU

Generate → Apply → Capture → Check

For an ALU, the testbench may:

• 🎯 Generate random operands and operations
• 📥 Apply them to the ALU
• 📤 Capture the result
• 🔍 Compare it with a reference model
• 📊 Track which operations have been verified

💡 Example 2 — FIFO

For a FIFO, the testbench may:

• 📝 Generate read/write transactions
• 📥 Apply them to the FIFO
• 👀 Monitor output data and status flags
• 🔍 Compare read data against expected data
• 📊 Track coverage of FULL, EMPTY, READ, and WRITE scenarios

📌 Key Takeaway

Generate → Apply → Capture → Check → Measure

---

📌 1.4 Directed Testing

Directed testing is a verification approach where you study the hardware specification and create a verification plan containing a list of specific tests.

Each test focuses on a particular set of related features of the DUT.

🎯 Basic Approach

Specification → Verification Plan → Test Cases → DUT → Check Results

🔹 Identify the features from the specification. 🔹 Create specific test cases for those features. 🔹 Apply the required stimulus. 🔹 Check whether the DUT behaves correctly.

💡 Example 1 — UART

Suppose the UART specification has:

Start-bit detection 8-bit data transmission Parity Stop-bit detection

You could create separate directed tests:

🧪 Test 1 → Verify start-bit detection 🧪 Test 2 → Verify different data patterns 🧪 Test 3 → Verify parity 🧪 Test 4 → Verify stop-bit detection 💡 Example 2 — FIFO

For a FIFO, directed tests could target:

🧪 Write until FULL 🧪 Read until EMPTY 🧪 Attempt write when FULL 🧪 Attempt read when EMPTY 📊 Directed vs Random Testing

In the first image, the dashed line represents random testing and the solid line represents directed testing.

The important idea is that random testing can reach different coverage points quickly, while directed testing progresses through explicitly planned scenarios.

📌 Key Point: Directed testing is predictable and targeted, but writing enough directed tests for a complex design can become time-consuming.

1.4.1 Constrained-Random Stimulus: Although you want the simulator to generate the stimulus, you don’t want totally random values. You use the SystemVerilog language to describe the format of the stimulus (“address is 32-bits; opcode is ADD, SUB or STORE; length < 32 bytes”), and the simulator picks values that meet the constraints.

---

📌 1.5 Methodology Basics

🔹 1. Constrained-Random Stimulus 🎲

🔹 2. Functional Coverage 📊

🔹 3. Layered Testbench Using Transactors 🧩

🔹 4. Common Testbench for All Tests ♻️

🔹 5. Keep Test-Specific Code Separate 🧩

📌 Key Takeaway:

A good verification methodology is not just about finding bugs. It is about creating a reusable and measurable process for demonstrating that the DUT meets its specification.

---

📌 1.6 What Should You Randomize?

🔹 1. Device Configuration ⚙️

🔹 2. Environment Configuration 🌐

🔹 3. Input Data 📥

🔹 4. Protocol Exceptions ⚠️

🔹 5. Errors and Violations 🚨

🔹 6. Delays ⏱️

📌 Key Takeaway

Don't simply randomize everything.

The useful strategy is:

🎲 Randomize → 🔒 Constrain → 🧪 Stimulate → 🔍 Check → 📊 Measure Coverage

---

🔬 1.7 The Testbench — Design Environment

The testbench wraps around the Design Under Test (DUT), similar to how a hardware tester connects to a physical chip. 🧪 TESTBENCH

🎯 Basic Testbench Function

The testbench performs two main activities:

📥 Provide Stimulus → Sends inputs to the DUT 📤 Capture Responses → Observes and checks DUT outputs

---

📌 1.8 Testbench Components — Bus Functional Models (BFMs)

A testbench can contain multiple Bus Functional Models (BFMs). For example, 🔵 AMBA 🟢 USB 🟠 PCI 🟣 SPI

📌 Key Takeaway

Testbench = More than just stimulus

A well-structured testbench can contain:

🎯 Tests → 📦 Transactions → 🔄 Transactors/BFMs → 🔌 DUT Interface → 🔍 Monitors → 📊 Checkers

---

💡 A Flat Testbench : When you fi rst learned Verilog and started writing tests, they probably looked like the low-level code inSample 1.1 , which does a simplifi ed APB (AMBA Peripheral Bus) Write. (VHDL users may have written similar code).

🧪 Sample 1.1 — Driving the APB Pins

This example demonstrates a basic low-level Verilog testbench that directly drives APB signals, performs a write operation, and checks the result.

module test(PAddr, PWrite, PSel, PWData, PEnable, Rst, clk);

// Port declarations omitted...

initial begin

    // 🔄 Drive reset
    Rst <= 0;
    #100 Rst <= 1'b1;

    // 🎯 Drive the APB control bus
    @(posedge clk);
    PAddr  <= 16'h50;
    PWData <= 32'h50;
    PWrite <= 1'b1;
    PSel   <= 1'b1;

    // ⏱️ Enable APB access
    @(posedge clk);
    PEnable <= 1'b1;

    @(posedge clk);
    PEnable <= 1'b0;

    // 🔍 Check the result
    if (top.mem.memory[16'h50] == 32'h50)
        $display("Success");
    else
        $display("Error, wrong value in memory");

    $finish;
end

endmodule 📌 Description 🔄 Reset: Initializes the DUT into a known state. 🎯 APB Control Bus: Drives address, data, write, and select signals. ⏱️ PEnable: Enables the APB access for one clock cycle. 🔍 Result Check: Verifies that 32'h50 was correctly written to address 16'h50. 🛑 $finish: Ends the simulation.

👉 Key Point: This is pin-level testing, where the testbench directly controls the DUT's interface signals.

---

🧪 Sample 1.2 — Task to Drive APB Pins

A task is used to make APB write operations reusable.

task write(reg [15:0] addr, reg [31:0] data); @(posedge clk); PAddr <= addr; PWData <= data; PWrite <= 1'b1; PSel <= 1'b1;

@(posedge clk);
PEnable <= 1'b1;

@(posedge clk);
PEnable <= 1'b0;

endtask

📌 Key Point: Instead of driving APB pins repeatedly, simply call:

write(16'h50, 32'hABCD);

👉 Task = Reusable APB write operation.

---

🧪 Sample 1.3 — Low-Level Verilog Test

This example shows a simple Verilog test using the tasks from Sample 1.2.

🔹 Test Flow Reset → Write Data → Check Result → Finish 🔄 reset() → Resets the DUT. ✍️ write(16'h50, 32'h50) → Writes data into memory. 🔍 Checks whether memory location 16'h50 contains 32'h50. ✅ Match → Success ❌ Mismatch → Error 🛑 $finish → Ends simulation.

📌 Key Point: Sample 1.3 is called a low-level Verilog test because the test still directly depends on Verilog tasks and DUT-level details.

👉 Sample 1.1: Directly drives APB pins 👉 Sample 1.2: Encapsulates pin driving into a task 👉 Sample 1.3: Uses the task to create a complete test case

🔌 The Signal and Command Layers

📌 1. Signal Layer

📌 2. Command Layer

🚗 Driver → Converts commands into DUT input signals. 👀 Monitor → Observes DUT output signals and groups them into commands. 🎯 Assertions → Check individual signals and behavior across complete commands.

🔬 Figure 1.10 — Testbench with Functional Layer The Functional Layer is added above the Command and Signal layers to work with high-level functionality.

📌 Functional Layer Components ⚙️ Agent → Connects the functional layer with the command layer. 📊 Scoreboard → Compares expected results with actual results. 🔍 Checker → Determines whether the DUT behavior is correct.

🎯 The Scenario Layer The Scenario Layer is the highest layer of the testbench. It is driven by the Generator and defines complete, realistic operations that the DUT should perform.

📌 What is a Scenario?

A scenario is a sequence of operations that represents a particular use case or task.

For example, in a music player:

🎵 Play music from storage 📥 Download a new song 🔊 Adjust volume ⏩ Change tracks

🔬 Fig. 1.12 — Full Testbench with All Layers

This figure shows a complete layered testbench, including the Scenario, Functional, Command, and Signal layers.

📌 Main Components 🧪 Test → Starts and controls the verification scenario. 🎯 Generator → Generates scenarios/transactions. ⚙️ Agent → Connects the generator to the lower-level components. 🚗 Driver → Converts transactions into DUT signals. 🔍 Assertions → Check signal-level and protocol behavior. 👀 Monitor → Observes DUT signals and collects responses. 📊 Scoreboard → Compares expected and actual results. ✅ Checker → Determines whether the DUT behavior is correct. 📈 Functional Coverage → Measures which required functionality has been exercised.

🧪 Exercise 1 — ALU Verification Plan 📌 DUT Specifications 🔄 Reset: Asynchronous, active HIGH ⏱️ Clock: Input clock 📥 A: 4-bit signed input 📥 B: 4-bit signed input 📤 C: 5-bit signed registered output ⚙️ C updates: Positive edge of clock 🔢 Opcodes: 4 operations

solution: module alu ( input logic clk, input logic reset, input logic signed [3:0] A, input logic signed [3:0] B, input logic [1:0] opcode, output logic signed [4:0] C );

always_ff @(posedge clk or posedge reset) begin
    if (reset)
        C <= 5'sd0;
    else begin
        case (opcode)
            2'b00: C <= A + B;
            2'b01: C <= A - B;
            2'b10: C <= ~A;
            2'b11: C <= |B;
        endcase
    end
end

endmodule

module alu_tb;

logic clk;
logic reset;
logic signed [3:0] A, B;
logic [1:0] opcode;
logic signed [4:0] C;

// Opcode definitions
localparam ADD    = 2'b00;
localparam SUB    = 2'b01;
localparam INV    = 2'b10;
localparam RED_OR = 2'b11;

// DUT
alu dut (
    .clk    (clk),
    .reset  (reset),
    .A      (A),
    .B      (B),
    .opcode (opcode),
    .C      (C)
);

// Clock generation
always #5 clk = ~clk;

initial begin
    clk   = 0;
    reset = 0;
    A     = 0;
    B     = 0;
    opcode = ADD;

    // Asynchronous active-high reset
    #2 reset = 1;
    #2 reset = 0;

    // ADD
    A = 4'sd5;
    B = 4'sd3;
    opcode = ADD;
    @(posedge clk);
    #1 $display("ADD: A=%0d B=%0d C=%0d", A, B, C);

    // SUB
    A = 4'sd7;
    B = 4'sd3;
    opcode = SUB;
    @(posedge clk);
    #1 $display("SUB: A=%0d B=%0d C=%0d", A, B, C);

    // INVERT A
    A = 4'b1010;
    opcode = INV;
    @(posedge clk);
    #1 $display("INV: A=%b C=%b", A, C);

    // REDUCTION OR B
    B = 4'b0001;
    opcode = RED_OR;
    @(posedge clk);
    #1 $display("RED_OR: B=%b C=%b", B, C);

    $finish;
end

endmodule

---

📘 Chapter 2 — SystemVerilog Data Types

SystemVerilog provides improved data types and data structures for better performance, less memory, and easier verification.

🔹 Key Features ⚡ Two-State Types → bit, int → better performance & less memory 📦 Queues → Variable-size storage with built-in push/pop 📊 Dynamic Arrays → Size decided at runtime 🔑 Associative Arrays → Key-based storage & searching 🏗️ Classes & Structures → Organize complex data 🔄 Unions & Packed Structures → Multiple views of same data 📝 Strings → Built-in text handling 🔢 Enumerated Types → Readable and meaningful values 🎯 Main Benefit

SystemVerilog = Flexible + Efficient + Verification-friendly data structures 🚀

---

📘 2.1 — Built-In Data Types

SystemVerilog provides several built-in data types for storing different kinds of data.

🔹 Main Categories 🔢 Integer Types → bit, logic, reg, int, integer 🔤 String Type → string 🔢 Enumerated Type → enum 📦 Structure Type → struct 🔄 Union Type → union ⭐ Important Classification

2-State: bit, byte, shortint, int, longint

➡️ Stores only 0 and 1 ⚡

4-State: logic, reg, integer, time

➡️ Stores 0, 1, X, Z 🔬

🎯 Remember

2-state → 0, 1 4-state → 0, 1, X, Z

int i; // 32-bit, 2-state, signed int unsigned ui; // 32-bit, 2-state, unsigned

byte b8; // 8-bit signed shortint s; // 16-bit signed longint l; // 64-bit signed

integer i4; // 32-bit, 4-state signed time t; // 64-bit, 4-state unsigned real r; // floating-point

Type	States	Size	Signed?
bit	2-state	1 bit	❌ Unsigned
bit [31:0]	2-state	32 bit	❌ Unsigned
int unsigned	2-state	32 bit	❌ Unsigned
int	2-state	32 bit	✅ Signed
byte	2-state	8 bit	✅ Signed
shortint	2-state	16 bit	✅ Signed
longint	2-state	64 bit	✅ Signed
integer	4-state	32 bit	✅ Signed
time	4-state	64 bit	❌ Unsigned
real	2-state	64-bit floating point	—

🧠 Easy Memory Trick 2-state: 0, 1 ⚡ 4-state: 0, 1, X, Z 🔬 Signed: Can represent ➕ positive and ➖ negative numbers.

📘 2.2 Fixed-Size Arrays Fixed-size array = Array whose size is known at compile time and cannot change during simulation. 📦

SystemVerilog has the $clog2() function that calculates the ceiling of log base 2,

📘 2.2.2 — Array Literal

An array literal is a way to initialize an array with values directly using '{' and '}'. 🧩

📘 2.2.3 — Basic Array Operations: for & foreach Both for and foreach are used to access array elements. 🔢

📘 Basic Array Operations — Copy & Compare

📘 Bit and Array Subscripts — Together at Last

SystemVerilog allows you to combine bit/part-selects with array indexes. 🔢

Verilog-2001 Improvement — Double Comma in $display

This is a small but useful improvement in Verilog-2001. 🛠️

🔹 Double Comma ,,

In a $display statement, using two commas inserts a space in the output.

Example 1️⃣ $display("Hello",,"World");

Output:

Hello World Example 2️⃣ int a = 10; int b = 20;

$display("a =",a,,"b =",b);

📘 2.2.6 — Packed Arrays

A packed array is a collection of bits stored continuously next to each other in memory. 🔢

With a single subscript, you get a word of data, barray[0] .With two subscripts, you get a byte of data, barray[0][3] . With three subscripts, you can access a single bit, barray[0][1][6] . Because one dimension is specifi ed after the name, barray[5] , that dimension is unpacked, so you must always give at least one subscript.

📘 2.2.8 — Choosing Between Packed and Unpacked Arrays

The choice depends on what you want the array to represent. 🔢

🔹 Waiting for Array Changes

The @ operator can be used with scalar values and packed arrays.

For example:

logic [7:0] barray[4];

@(barray[0]); // ✅ Legal

But:

@(barray); // ❌ Not legal

because barray is an unpacked array.

To wait for any element of the unpacked array to change:

@(barray[0] or barray[1] or barray[2] or barray[3]); 🧠 Remember 🔢 Packed array → useful for scalar conversion and @ event control. 📦 Unpacked array → useful for storing separate elements/memory. ⏳ @ works with scalars and packed arrays, not an entire unpacked array.

📘 2.3 — Dynamic Arrays

A dynamic array is an array whose size can be decided and changed at runtime. 🔄

A dynamic array is declared with empty word subscripts [] . This means that you do not specify the array size at compile time; instead, give it at run time. The array is initially empty, so you must call the new[] constructor to allocate space, passing in the number of entries in the square brackets. If you pass an array name to the new[] constructor,

📘 2.4 — Queues

A queue is a variable-size array that stores elements in a specific order. 📦A queue is declared with word subscripts containing a dollar sign: [$] . The elements of a queue are numbered from 0 to $

if you put a $ on the left side of a range, such as [$:2] , the $ stands for the minimum value, [0:2] . A $ on the right side, as in [1:$] , stands for the maximum value, [1:2]

📘 Chapter 2.5 — Associative Arrays in SystemVerilog 🔬 🧠 1. What is an Associative Array?

An Associative Array is an unpacked array where elements are accessed using a key/index instead of a fixed size. 🔑

It is useful when:

📌 You don't know the number of elements in advance. 🔑 You want to access data using meaningful keys. 💾 You want to avoid allocating unused memory. ✍️ Syntax data_type array_name [index_type];

📘 Chapter 2.6 — Array Methods in SystemVerilog 🔬 SystemVerilog provides built-in array methods to search, sort, locate, count, and manipulate array elements. 🛠️

🧩 1. Types of Array Methods

Array methods can be broadly divided into:

Category Methods 🔍 Searching find(), find_index(), find_first(), find_last() 🔢 Counting sum(), count() 📊 Sorting sort(), rsort() 🔀 Ordering reverse(), shuffle() 🧮 Reduction sum(), product(), and(), or(), xor() 📦 Size/Manipulation size(), delete()

📘 2.6.3 — Array Sorting and Ordering 🔢

SystemVerilog provides built-in methods to sort, reverse, and randomly rearrange array elements. These methods are very useful in verification for organizing transactions and test data. 🧪

The main methods are:

Method Purpose sort() ⬆️ Ascending order rsort() ⬇️ Descending order reverse() 🔄 Reverse existing order shuffle() 🎲 Randomly rearrange

#SYSTEMVERILOG ASSIGNMENT

Answers:

a. Byte in systemVerilog is 8-bit signed by default -128 to +127

b. my_integer = 32’b0000_1111_xxxx_zzzz; my_int = my_integer; binary = 0000_0000_0000_0000_0000_1111_0000_0000 hex = 00000f00

c. my_bit =16’h8000; 16'h8000 = 1000 0000 0000 0000 2^15 = 32768

d.my_short_int1 = my_bit; binary = 0000_1000_0000_0000 = decimal 2048

c. my_short_int2 = my_short_int1 - 1; binary in 2’complement form = 0111_1111_1111_1111 decimal = 32767