<h2><img class="alignnone size-medium wp-image-18272" src="https://www.maven-silicon.com/blog/wp-content/uploads/2025/08/Blog-Banners-New-Rectangle-12-1024x576.jpg" alt="Pce" width="1024" height="576" />Introduction</h2>
PCI Express (PCIe) serves as the industry-standard interface for high-speed component connections within modern computing systems. Whether it's graphics cards or SSDs, PCIe facilitates efficient and low-latency data transfers. With each new generation, PCIe continues to evolve, delivering enhanced bandwidth and improved performance to meet the demands of cutting-edge technology.
<h2>Evolution of PCIe</h2>
Since its inception, PCIe has undergone multiple iterations:
<ul>
 	<li style="font-weight: 400;" aria-level="1">PCIe 1.0 (2003) – 2.5 GT/s per lane</li>
 	<li style="font-weight: 400;" aria-level="1">PCIe 2.0 (2007) – 5 GT/s per lane</li>
 	<li style="font-weight: 400;" aria-level="1">PCIe 3.0 (2010) – 8 GT/s per lane</li>
 	<li style="font-weight: 400;" aria-level="1">PCIe 4.0 (2017) – 16 GT/s per lane</li>
 	<li style="font-weight: 400;" aria-level="1">PCIe 5.0 (2019) – 32 GT/s per lane</li>
 	<li style="font-weight: 400;" aria-level="1">PCIe 6.0 (2022) – 64 GT/s per lane</li>
 	<li style="font-weight: 400;" aria-level="1">PCIe 7.0 (Expected 2025) – 128 GT/s per lane</li>
</ul>
In PCI Express (PCIe), GT/s stands for Gigatransfers per second, which measures the raw data transfer rate of a PCIe link. Unlike Gbps (Gigabits per second), GT/s refers to the number of data transfers occurring per second, rather than the actual data throughput.Each generation doubles the bandwidth of its predecessor, ensuring faster data transfer for demanding applications.
<h2>PCIe Architecture and Lane Configuration</h2>
PCIe operates on a point-to-point topology, meaning each device has a dedicated connection to the host. The number of lanes determines the bandwidth:
<ul>
 	<li style="font-weight: 400;" aria-level="1">x1 – Single Lane, suitable for low-bandwidth peripherals.</li>
 	<li style="font-weight: 400;" aria-level="1">x4 – Common for SSDs and network adapters.</li>
 	<li style="font-weight: 400;" aria-level="1">x8 – Used in high-performance storage and networking.</li>
 	<li style="font-weight: 400;" aria-level="1">x16 – Standard for GPUs and high-speed accelerators.</li>
</ul>
Each lane consists of two differential pairs (one for transmitting, one for receiving), ensuring full-duplex communication.
<h4>In PCI Express (PCIe), lanes and links are fundamental concepts that define how data is transmitted between components.</h4>
<ul>
 	<li style="font-weight: 400;" aria-level="1">Lane: A PCIe lane consists of two pairs of wires—one for transmitting data and one for receiving. Each lane operates as a full-duplex connection, meaning data can flow in both directions simultaneously. PCIe devices can use different lane configurations, such as x1, x4, x8, x16, where the number represents the total lanes available for communication.</li>
 	<li style="font-weight: 400;" aria-level="1">Link: A PCIe link is the connection between two PCIe devices, such as a CPU and a GPU or an SSD. A link can consist of one or more lanes, depending on the bandwidth requirements of the connected devices. During PCIe initialization, devices negotiate the number of lanes they will use.</li>
</ul>
<h2><img src="https://chat.google.com/u/0/api/get_attachment_url?url_type=FIFE_URL&amp;content_type=image%2Fpng&amp;attachment_token=AOo0EEVP1KZo9Qd8lmxfkamArK1ApA62vinUJUCq0boJ%2BcYAveuTHmKZ8N9wTnCkA36OmcZ8fLBmLSfKLNILrfUvP5Sz6Xu%2BhgSLxRGCOav6Dlenu8IMMcnPvwcuYUSL%2FVsRpWZpj8D8V7hWAh2RUQIyWGa8Krs9q6G7oTUI6g%2F9%2Fh1VORDcy%2BrymrlPntFYB5x%2B%2FYZRtSmmyfnPQUSM94yPTCg4SB5CQnMMNQV2dsTwoT2gpy4OoSBCcDAot12jbPkupbuSNvJV%2B%2FEhxDktm5sbcOb1vtoXAU5SYwhhc2PDHhQszux%2FJG1tsY3a2P0ctb0KkjnC%2FDLJlaTl%2FkCF5sife8IfH%2Bt%2B0sQbB4emdRvBFanq7K2fQG6ggFisUEJijdm%2Frr2PYEEWtjtTLtv3WTOkVqeknUJwFoU%2FsFmoYyU%2FmIt0B8XM5RHI0sGBI68pqOXdOIzo5oyVik3DR1vz6GmWG7uIDECTF%2BtEgCjs2UKDJIREqchAkl4lDnGwlTo1PBswL4RnhkgOn6LZ70IY6n2N1nXlKAqsh9gEpdu5t2n%2FGBBqVxowmwtMcsTQNFxlNRhY&amp;allow_caching=true&amp;sz=w1365-h598" alt="Displaying image.png" />
Applications of PCIe</h2>
PCIe is widely used in:
<ul>
 	<li style="font-weight: 400;" aria-level="1">Graphics Processing Units (GPUs): High-performance gaming and AI workloads.</li>
 	<li style="font-weight: 400;" aria-level="1">Solid-State Drives (SSDs): NVMe SSDs leverage PCIe for ultra-fast storage.</li>
 	<li style="font-weight: 400;" aria-level="1">Networking: High-speed Ethernet and wireless adapters.</li>
 	<li style="font-weight: 400;" aria-level="1">Data Centers: AI accelerators and FPGA-based computing.</li>
</ul>
<h2>PCIe vs Other Interfaces</h2>
PCIe competes with other high-speed interfaces like Thunderbolt, USB, and SATA. While USB and Thunderbolt offer external connectivity, PCIe remains the dominant choice for internal expansion due to its superior bandwidth and efficiency.
<h2>Challenges in PCIe Implementation</h2>
Despite its advantages, PCIe faces challenges:
<ul>
 	<li style="font-weight: 400;" aria-level="1">Signal Integrity: Higher speeds require advanced PCB design and shielding.</li>
 	<li style="font-weight: 400;" aria-level="1">Power Consumption: Managing power efficiency at higher bandwidths is crucial.</li>
 	<li style="font-weight: 400;" aria-level="1">Compatibility Issues: Ensuring seamless integration across different PCIe generations.</li>
</ul>
<h2>Future of PCIe</h2>
With PCIe 7.0 on the horizon, the industry is preparing for 128 GT/s raw bit rate, enabling 512 GB/s over x16 lanes. This will be crucial for AI workloads, high-performance computing, and<a href="https://www.maven-silicon.com/blog/essential-role-of-formal-verification-in-hardware-design/"> next-gen storage solutions.</a>
<h2>Conclusion</h2>
PCIe remains the backbone of modern computing, driving innovation across industries. As new generations emerge, we can expect even faster, more efficient data transfer, shaping the future of technology.

PCIe Explained: The Silent Powerhouse Driving Modern Tech

<a href="https://elearn.maven-silicon.com/"><img class="alignnone size-medium wp-image-18195" src="https://www.maven-silicon.com/blog/wp-content/uploads/2025/07/RTL-Design-Explained-Like-Online-Delivery-1-1024x576.jpg" alt="hardware design" width="1024" height="576" /></a>In today’s hardware and software design, ensuring systems work correctly is more important than ever. Formal verification is a method that uses mathematics and logic to prove a system behaves as expected. Unlike simulation, which checks specific cases, formal verification checks all possible inputs and paths to ensure full correctness.
<h3>What is Formal Verification?</h3>
Formal verification uses mathematical models to check if a system meets its design rules or specifications. It includes techniques like:
<ul>
 	<li style="font-weight: 400;" aria-level="1">Model Checking – Looks at every possible state the system can be in to see if the design rules are always followed.</li>
 	<li style="font-weight: 400;" aria-level="1">Theorem Proving – Uses logical steps to prove the system works correctly.</li>
 	<li style="font-weight: 400;" aria-level="1">Equivalence Checking – Confirms that two versions of a design (for example, RTL and gate-level netlist) behave in the same way.</li>
</ul>
<h3>Why Use Formal Verification?</h3>
Simulation checks only some test cases. Formal verification checks everything, which makes it highly valuable for finding hidden bugs.
Benefits include:
<ul>
 	<li style="font-weight: 400;" aria-level="1">Exhaustive checking: Verifies all inputs, states, and paths.</li>
 	<li style="font-weight: 400;" aria-level="1">Early bug detection: Catches issues before implementation.</li>
 	<li style="font-weight: 400;" aria-level="1">Better security and reliability: Used in safety-critical systems like aerospace, automotive, and cryptography.</li>
 	<li style="font-weight: 400;" aria-level="1">Cost savings: Fixing bugs earlier reduces rework and time delays.</li>
</ul>
<h3>How Does Formal Verification Work in Practice?</h3>
<ul>
 	<li style="font-weight: 400;" aria-level="1">Engineers write properties (rules the design must follow) using languages like SystemVerilog Assertions (SVA).</li>
 	<li style="font-weight: 400;" aria-level="1">Tools try to prove these properties or show how the design can break them (a counterexample).</li>
 	<li style="font-weight: 400;" aria-level="1">If a property fails, the tool gives a waveform trace to help debug the issue quickly.</li>
</ul>
<h3>Formal and Simulation: Better Together</h3>
While simulation is widely used, it has blind spots. Formal fills those gaps.

&nbsp;
<table>
<tbody>
<tr>
<td>
<h5>Aspect</h5>
</td>
<td>
<h5>Simulation</h5>
</td>
<td>
<h5>Formal Verification</h5>
</td>
</tr>
<tr>
<td>Scope</td>
<td>Tests specific scenarios</td>
<td>Checks all possible scenarios</td>
</tr>
<tr>
<td>Method</td>
<td>Needs testbenches and vectors</td>
<td>Needs properties/assertions</td>
</tr>
<tr>
<td>Strength</td>
<td>Good for data-path</td>
<td>Great for control-path and corner cases</td>
</tr>
<tr>
<td>Weakness</td>
<td>Can miss rare bugs</td>
<td>Catches rare, hard-to-reach bugs</td>
</tr>
</tbody>
</table>
<h3>Types of Properties Checked</h3>
Some common properties formal tools can verify:
<ul>
 	<li style="font-weight: 400;" aria-level="1">Safety: “Bad things never happen” (e.g., FIFO overflow must never happen).</li>
 	<li style="font-weight: 400;" aria-level="1">Liveness: “Good things eventually happen” (e.g., requests are always granted).</li>
 	<li style="font-weight: 400;" aria-level="1">Deadlock freedom: The design never gets stuck.</li>
 	<li style="font-weight: 400;" aria-level="1">Protocol compliance: Ensures standards like AXI or AHB are followed correctly.</li>
</ul>
<h3>When and Where to Use Formal Verification</h3>
Formal verification is best suited for:
<ul>
 	<li style="font-weight: 400;" aria-level="1">Small/medium-sized blocks (e.g., FIFO, arbiter, ALU).</li>
 	<li style="font-weight: 400;" aria-level="1">Control-heavy logic (e.g., state machines).</li>
 	<li style="font-weight: 400;" aria-level="1">Safety/security checks in crypto or secure designs.</li>
 	<li style="font-weight: 400;" aria-level="1">Protocol and bus interface checks.</li>
</ul>
It’s also used during sign-off to prove critical properties and in regressions for catching regressions quickly.
<h3>Challenges and Future Trends</h3>
Formal verification is very effective but can be:
<ul>
 	<li style="font-weight: 400;" aria-level="1">Hard to learn – It needs special knowledge.</li>
 	<li style="font-weight: 400;" aria-level="1">Computationally heavy – Checking every case can take time and resources.</li>
</ul>
But the future looks bright. New tools and AI techniques are making formal methods easier to use and faster. As systems become more complex, formal verification will become even more important to make sure everything works correctly.
<h3>What are Some Popular Tools Used for Formal Verification?</h3>
Industry-standard tools include:
<ul>
 	<li style="font-weight: 400;" aria-level="1">Cadence JasperGold</li>
 	<li style="font-weight: 400;" aria-level="1">Synopsys VC Formal</li>
 	<li style="font-weight: 400;" aria-level="1">Mentor Questa Formal</li>
</ul>
<h3>Summary</h3>
<a href="https://www.maven-silicon.com/blog/what-are-the-techniques-of-asic-verification/">Formal verification</a> is a must-have method in modern hardware design. It helps find bugs early, improves design clarity, and ensures safety in critical systems. While there is a learning curve, modern tools and methodologies are making formal verification more accessible and scalable. Using formal verification alongside simulation gives complete confidence in your design’s correctness.

Essential Role of Formal Verification in Hardware Design

<img class="wp-image-15856 size-medium" src="https://www.maven-silicon.com/blog/wp-content/uploads/2023/06/Blog-Banners-Rectangle-1-1-1024x576.png" alt="What is UVM Factory?" width="1024" height="576" />

In this article, we will discuss what is UVM Factory, the necessity of a UVM factory, and how to use a UVM Factory.
<h2>What is UVM Factory?</h2>
The factory is a centralized location to create the instance of the uvm component and object classes in UVM.
<h2>The necessity of UVM Factory</h2>
Consider the following DUT (Router) as an example to understand the necessity of using the factory in UVM.

<img class="wp-image-15828 size-medium" title="Router" src="https://www.maven-silicon.com/blog/wp-content/uploads/2023/06/Router-1024x576.png" alt="Router" width="1024" height="576" />
Fig 1: Router
A Router is a networking device that routes the incoming packet from a source network to one of the destination networks among the three, based on the address available in the packet.

There will be three destination FIFOs inside the router. When a data packet comes in, from the source, the ROUTER reads the HEADER information in the packet to determine its ultimate destination network and routes the packet to the particular network by writing the data into the corresponding FIFO. The destination network should read the data within 30 cycles once the data is available in the FIFO else the soft reset will get enabled &amp; clears the FIFO.

The UVM TB architecture to verify the router is shown below. The TB consists of one source agent and three destination agents.

<img class="wp-image-15829 size-medium" title="Testbench Architecture" src="https://www.maven-silicon.com/blog/wp-content/uploads/2023/06/Test-1024x576.png" alt="Testbench Architecture" width="1024" height="576" />
Fig 2: Testbench Architecture
In the test cases, to read the different types of input packets driven from the source driver, the destination agent should drive read enable within 30 cycles once the valid out goes high. In a test case to verify the soft reset scenario, the destination driver should drive the read enable after 30 cycles of valid out. For this particular test case, we need to override the existing drivers inside the destination agents. We will now discuss, by using UVM Factory, how we can override the parent driver with the child driver from the test case.

Also read: <a href="https://www.maven-silicon.com/blog/uvm-soc-testbench/" target="_blank" rel="noopener">UVM SoC Testbench</a>
<h2>How to use UVM Factory</h2>
The usage of Factory involves three steps.

The first step is to use macros to register all the class types with the factory. In order to use the factory, to create or override an object/component, all the object and component classes must be registered with the factory. The classes used to create the testbench structure are registered using the macro `uvm_component_utils and the classes used for stimulus generation are registered using the macro `uvm_object_utils. The above macros get to expand into the following steps.
<ul>
 	<li>Declares typedef wrapper type named type_id for registry class</li>
 	<li>Defines the function get_type which will return the type_id</li>
 	<li>Defines the function get_type_name which will return the class name</li>
</ul>
Example:

<img class="aligncenter size-full wp-image-15830" src="https://www.maven-silicon.com/blog/wp-content/uploads/2023/06/Class-destination.png" alt="Class destination" width="603" height="383" />

The second step is creating the instance of the class using the factory method create. Before we see how to use create method, we will discuss the constructor defaults for component and object classes.

UVM components follow a tree-like hierarchy to build the testbench structure, where each component builds all of the components that are one level lower in the hierarchy, so each component names (and builds) its children, and passes a pointer to itself (this pointer) to each child component, so they know where they are located in the hierarchy (who is the parent device for each constructed component).

Also read: <a href="https://www.maven-silicon.com/blog/verification-ip-vs-testbench/" target="_blank" rel="noopener">Verification IP Vs Testbench</a>

For components, the typical constructor is shown below,

<img class="aligncenter wp-image-15831" src="https://www.maven-silicon.com/blog/wp-content/uploads/2023/06/UVM-component-parent.png" alt="UVM component parent" width="796" height="83" />
For transactions (data objects), each object is a unit of data with multiple fields, and transactions do not have a parent. For transactions, the typical constructor is shown below,
<img class="aligncenter wp-image-15832" src="https://www.maven-silicon.com/blog/wp-content/uploads/2023/06/Class-name.png" alt="Class name" width="787" height="82" />

Example:

<img class="aligncenter size-medium wp-image-15863" src="https://www.maven-silicon.com/blog/wp-content/uploads/2023/06/String-name-1-1024x320.png" alt="String name" width="1024" height="320" />

In UVM to create the instance of component classes and object classes it is not recommended to use directly the class constructor. The recommended method in UVM for creating testbench components or transaction objects is to use the built-in method ::type_id::create command.

Create is a static method defined inside the registry class. The scope resolution operator is used to access this static method, create, using the wrapper of the registry class which is type_id.

For example, to construct the driver inside the agent the create method has to be called in the build phase of the agent using the type_id of the driver as shown below.

<img class="aligncenter size-medium wp-image-15864" src="https://www.maven-silicon.com/blog/wp-content/uploads/2023/06/UVM-phase-1-1024x324.png" alt="UVM phase" width="1024" height="324" />

The create method in turn calls the class constructor based on the type_id using which the create method is called. In the above example, the create method will call the constructor of destination_driver class which will create its instance and returns the reference of the object to the handle drive.

The third step is Overriding Components and Objects using the factory overriding methods. There are two types of overriding methods.
<ul>
 	<li>Global override - set_type_override_by_type</li>
</ul>
<img class="aligncenter wp-image-15836" src="https://www.maven-silicon.com/blog/wp-content/uploads/2023/06/Get-type-1-1-1024x101.png" alt="Get type 1" width="805" height="79" />
<ul>
 	<li>Instance override - set_inst_override_by_type</li>
</ul>
<img class="aligncenter wp-image-15837" src="https://www.maven-silicon.com/blog/wp-content/uploads/2023/06/Get-type-2-1024x101.png" alt="Get type 2" width="805" height="79" />

These override methods will override the original type type_id with the substitute type.

As discussed above, in one of the test cases if we want to replace the destination_driver class with child_driver to verify the soft reset scenario, we have to override the type of driver created inside the agent from the top-level component i.e., from the test class by using the above override methods.

Note: The build phase executes in the top-down approach

Also read: <a href="https://www.maven-silicon.com/blog/best-resources-to-learn-systemverilog-and-uvm/" target="_blank" rel="noopener">Best Resources to Learn SystemVerilog and UVM</a>

The global override method instructs the factory to override the type_id of destination_driver with the type_id of child_driver inside the destination_driver present in all three destination agents. Now, as the type_id is overridden, the type_id::create method in all the destination agent’s build phase is called with the type_id of child_driver, hence the create method calls the constructor of child_driver which will create the instance of child_driver inside all the three destination agents.

<img class="aligncenter size-medium wp-image-15862" src="https://www.maven-silicon.com/blog/wp-content/uploads/2023/06/UVM-phase-2-1-1024x219.png" alt="UVM phase 2" width="1024" height="219" />

The instance override method instructs the factory to override the type_id of destination_driver  with the type_id of the child_driver inside the driver present in a particular destination agent. In the below example, the destination_driver type_id is overridden with child_driver in the agent0, hence the type_id::create method inside agent0 is called with the type_id of child_driver, so the create method in the agent0 build_phase calls the constructor of child_driver which will create the instance of  child_driver. agent1 and agent2 will still  have the instance of  destination_driver class only.

<img class="aligncenter size-medium wp-image-15860" src="https://www.maven-silicon.com/blog/wp-content/uploads/2023/06/UVM-phase-3-1-1024x244.png" alt="UVM phase 3" width="1024" height="244" />

In this way, the UVM factory provides the user with the flexibility to change the type of component or object created inside the testbench environment from the test class without editing the source code inside the testbench environment.

Want to know more about UVM and start your career in VLSI? Explore our <a href="https://elearn.maven-silicon.com/course/UniversalVerificationMethodology-72" target="_blank" rel="noopener">Universal Verification Methodology Course</a> designed and delivered by the top industry experts.

What is UVM Factory?

<h2><img class="aligncenter size-medium wp-image-15784" src="https://www.maven-silicon.com/blog/wp-content/uploads/2023/05/System-Verilog-Tutorial-for-Beginners-1024x576.png" alt="System Verilog Tutorial for Beginners" width="1024" height="576" /></h2>
<h2>Introduction to SystemVerilog</h2>
SystemVerilog is a hardware description and verification language that is widely used in the electronic design automation (EDA) industry. It is a powerful and versatile language that combines the capabilities of hardware description languages (HDLs) such as VHDL and Verilog with the features of programming languages such as C and C++.

SystemVerilog is used to design, verify, and document electronic systems, including digital, analog, and mixed-signal systems. It is particularly useful for modeling complex digital logic and for verifying the correctness of hardware designs through simulation and formal verification. 
<h2>Features of SystemVerilog</h2>
<ol>
 	<li style="font-weight: 400;" aria-level="1">Build a Resusable testbench with the help of the OOP concept</li>
 	<li style="font-weight: 400;" aria-level="1">Supports Functional coverage</li>
 	<li style="font-weight: 400;" aria-level="1">The random stimulus can be generated based on constraints</li>
 	<li style="font-weight: 400;" aria-level="1">Supports <a href="https://www.maven-silicon.com/blog/systemverilog-assertion/" target="_blank" rel="noopener">assertion-based verification</a></li>
</ol>
<h2>Basic Syntax and Structure</h2>
<a href="https://www.maven-silicon.com/blog/systemverilog-event-scheduler/" target="_blank" rel="noopener">SystemVerilog</a> has a syntax that is similar to C and C++, with some additional features for hardware modeling. Here are some basic rules for writing SystemVerilog code:
<ul>
 	<li style="font-weight: 400;" aria-level="1">SystemVerilog is case-sensitive, so be careful to use the correct capitalization for keywords and variables.</li>
 	<li style="font-weight: 400;" aria-level="1">Statements are terminated with a semicolon (;)</li>
 	<li style="font-weight: 400;" aria-level="1">RTL Code is written inside the module block </li>
 	<li style="font-weight: 400;" aria-level="1">Comments can be written with either a double-slash (//) for single-line comments, or a slash and an asterisk (/*) for multi-line comments.</li>
</ul>
Here is an example of a simple SystemVerilog module:

module adder (input a, b, output sum);

assign sum = a + b;

endmodule

This module has two input ports (a, b) and one output port (sum). The assign statement is used to specify the function of the module, which is to add the inputs and output the result.

Also read: <a href="https://www.maven-silicon.com/blog/how-do-i-start-learning-systemverilog-as-a-fresher-2/" target="_blank" rel="noopener">How do I start learning SystemVerilog as a fresher?</a>
<h2>Data Types and Variables</h2>
SystemVerilog has a variety of data types that can be used to model different kinds of hardware signals. The most basic data types are integers and real numbers, which can be signed or unsigned. For example:

int a; // signed 32-bit integer

int b; // signed 32-bit integer

int c; // signed 32-bit integer

real d; // double-precision floating-point number

real e; // double-precision floating-point number

Other data types include bit vectors, arrays, and enumerated types. Bit vectors are used to represent signals with a specific width, such as a 4-bit bus or a 1-bit flag. Arrays are used to store multiple values of the same type, and enumerated types are used to define a set of named constants.

Here is an example of a bit vector and an array:

bit [7:0] data; // 8-bit vector

bit [31:0] addr; // 32-bit vector

int array1 [7:0] ; // 8-element array of signed integers

int array2 [31:0] ; // 32-element array of signed integers

enum {RED, GREEN, BLUE} color; // enumerated type with three values
<h2>Structures and Unions</h2>
SystemVerilog also supports structures and unions, which are composite data types that can be used to group multiple variables together. Structures are similar to records in other languages, and allow you to define a data type with multiple fields. Unions are similar to C unions, and allow you to define a data type that can hold multiple variables of different types, with only one variable being active at a time.

Here is an example of a structure and a union:

struct {

int a;

real b;

} s; // define a structure with two fields

union {

int a;

real b;

} u; // define a union with two fields

To access the fields of a structure or union, you can use the dot operator (.) followed by the field name. For example:

s.a = 10; // assign a value to field a of structure s

s.b = 3.14; // assign a value to field b of structure s

u.a = 10; // assign a value to field a of union u

u.b = 3.14; // assign a value to field b of union u
<h2>Class</h2>
Class datatypes are used to develop the reusable testbench. Class encloses the variables of different data types(properties) and various tasks and functions (methods).

module test;

class transaction;

int addr;

int data;

function void display();

$display(“The value of addr = %d, data =%d”);

endfunction

endclass

transaction t;

initial 

  begin

    t = new();// creates an instance for transaction class

    t.addr = 200;//accessing class property addr

    t.data = 500;//accessing class property dat

    t.display();//calling the class method display

end

endmodule

To access the class properties and methods first an instance of class should be created by calling the class constructor new().

Also read: <a href="https://www.maven-silicon.com/blog/how-do-i-learn-systemverilog-in-a-week/" target="_blank" rel="noopener">How do I learn SystemVerilog in a week?</a>
<h2>Control Statements and Loops</h2>
SystemVerilog supports a variety of control statements for managing the flow of your code. These include if-else statements, case statements, and loops.

Here is an example of an if-else statement:

if (a &gt; b) begin

c = a;

end else begin

c = b;

end

This statement compares the values of variables a and b, and assigns the larger value to c.

Here is an example of a case statement:

case (color)

RED: // do something

GREEN: // do something else

BLUE: // do something else

endcase

This statement checks the value of the enumerated type color, and executes the corresponding block of code.

Here is an example of a loop:

for (int i = 0; i &lt; 10; i = i + 1) begin

// do something

end

This loop iterates 10 times, with the variable i taking on the values 0 through 9.
<h2>Modules and Functions</h2>
SystemVerilog allows you to define modules and functions as reusable blocks of code. Modules are used to describe the behavior and interconnections of hardware components, and functions are used to define reusable pieces of code that can be called from multiple places in your design.

Here is an example of a module:

module adder (input a, b, output sum);

assign sum = a + b;

endmodule

This module has two input ports (a, b) and one output port (sum). The assign statement is used to specify the function of the module, which is to add the inputs and output the result.

Here is an example of a function:

function int add(int a, int b);

return a + b;

endfunction

This function takes two integer arguments and returns the sum of those arguments.
<h2>Simulation and Verification</h2>
One of the main benefits of SystemVerilog is its ability to simulate and verify hardware designs. SystemVerilog includes a number of built-in constructs for writing testbenches and checking the correctness of your design.

Here is an example of a simple testbench:

module tb_adder;

// Declare signals

bit [7:0] a;

bit [7:0] b;

bit [7:0] sum;

bit [7:0] expected_sum;

// Instantiate the module under test

adder dut (a, b, sum);

initial begin

// Test 1

a = 8'h01;

b = 8'h02;

expected_sum = 8'h03;

#10; // wait for 10 time units

assert (sum == expected_sum) else $display("Test 1 failed");

// Test 2

a = 8'hff;

b = 8'h01;

expected_sum = 8'h00;

#10; // wait for 10 time units

assert (sum == expected_sum) else $display("Test 2 failed");

end

endmodule

This testbench instantiates the adder module and tests it with two different input cases. The initial block contains the test cases, and the assert statement checks the output of the module against the expected result. If the assert statement fails, it will print an error message.

Also read: <a href="https://www.maven-silicon.com/blog/verilog-interview-questions-and-answers/" target="_blank" rel="noopener">Verilog Interview Questions and Answers</a>
<h2>Conclusion</h2>
SystemVerilog is a powerful and widely-used language for hardware design and verification. It combines the capabilities of hardware description languages with the features of programming languages, making it a versatile tool for modeling complex digital logic and verifying the correctness of hardware designs. Whether you are new to hardware design or an experienced designer, learning SystemVerilog can help you design and verify high-quality electronic systems.

Want to know more about System Verilog? Explore our <a href="https://elearn.maven-silicon.com/systemverilog-vlsi-verification" target="_blank" rel="noopener">SystemVerilog for Verification course</a> designed and delivered by the top industry Verification expert and the best VLSI training institute.

SystemVerilog Tutorial for Beginners

<img class="size-medium wp-image-14674" src="https://www.maven-silicon.com/blog/wp-content/uploads/2023/02/Blog-Banners-14-1-1024x576.png" alt="SystemVerilog Assertions" width="1024" height="576" />
<h2>What are SystemVerilog Assertions?</h2>
With a lot of increase in design complexity, the effort required to verify these designs is also increasing at a faster rate. To improve the verification quality we use various methods, techniques and SystemVerilog Assertions are one important feature we use to verify the design.

But do you know what are SystemVerilog Assertions?
SystemVerilog Assertions are a piece of verification code, which checks the design in adherence to the specification which will validate the specific behavior of a design and displays a message. If the specified behavior is not exhibited by the design then the assertion fails, indicating an error in the design’s behavior.
Assertions can be checked dynamically by simulation, or statically by formal <a href="https://www.maven-silicon.com/blog/systemverilog-testbench-verification-environment-architecture/" target="_blank" rel="noopener noreferrer">verification</a> EDA tool that proves whether the design meets its specification requirement or not. These tools require specifications about the design’s behavior.

Assertions can provide two major information about the design,
<ul>
 	<li>Is the design working correctly?</li>
 	<li>How good the test case is?</li>
</ul>
SystemVerilog Assertions can also provide coverage information which makes sure a certain design specification is covered in the verification. The concept/methodology of using assertions to verify a design is called Assertion based Verification – ABV.

<img class="aligncenter wp-image-14677 size-full" src="https://www.maven-silicon.com/blog/wp-content/uploads/2023/02/Asset-8-2-1-660x322-1.png" alt="Testbench" width="660" height="322" />

Also read: <a href="https://www.maven-silicon.com/blog/systemverilog-event-scheduler/" target="_blank" rel="noopener noreferrer">SystemVerilog Event Scheduler</a>
<h2>Advantages of using SystemVerilog Assertions</h2>
<ol>
 	<li>Assertions improve the observability and controllability of the design.</li>
</ol>
<ul>
 	<li>Observability - the ability to observe the effects of a specific, internal state, data path within the design.</li>
 	<li>Controllability - the ability to activate, stimulate, or sensitize a specific point within the design.</li>
</ul>
<ol start="2">
 	<li>Assertions improve debugging of the design.</li>
</ol>
<ul>
 	<li>It helps to capture the bugs which do not propagate to the output.</li>
</ul>
<ol start="3">
 	<li>Assertions can find the source of the bug faster and more accurately.</li>
</ol>
<ul>
 	<li>It helps to capture the improper functionality of the design at or near the source of the problem thereby reducing the debug time.</li>
</ul>
<ol start="4">
 	<li>Assertions give white box visibility to the design by providing internal test points in the design.</li>
 	<li>Simplifying the diagnosis and detection of bugs by localizing the occurrence of a suspected bug to an assertion monitor, which is then checked.</li>
 	<li>Assertions check design specifications and report errors or warnings in case of failure.</li>
 	<li>Assertions can be re-used across a design at various levels of verification.</li>
 	<li>Assertions can be parameterized so they could be reused.</li>
 	<li>Assertions can be turned on/off based on the requirement.</li>
 	<li>Ability to interact with C and Verilog functions.</li>
</ol>
<h2>Who writes SystemVerilog Assertions?</h2>
SystemVerilog Assertions can be written in the design as well as in the verification environment.

Design Engineers - White box verification
<ul>
 	<li>For the Signals at the Micro Architecture level (for the signals which are not visible to Verification Engineers)</li>
</ul>
Verification Engineers - Black box verification
<ul>
 	<li>For the I/O signals of IP or SoC.</li>
</ul>
<h2>What are the challenges with SystemVerilog Assertions?</h2>
<ol>
 	<li>The quality of the test stimulus is still critical.
<ul>
 	<li>Assertions are only useful if exercised by the test stimulus.</li>
</ul>
</li>
 	<li>Assertions must be defined carefully.
<ul>
 	<li>Incorrect assertions can give misleading results.</li>
 	<li>Debugging an assertion can be difficult.</li>
 	<li>How do we know when enough assertions have been written?</li>
</ul>
</li>
 	<li>Simulation overhead.</li>
</ol>
Also read: <a href="https://www.maven-silicon.com/blog/what-is-the-use-of-systemverilog-assertion/" target="_blank" rel="noopener noreferrer">What is the use of SystemVerilog assertion?</a>
<h2>Types of  SystemVerilog Assertions</h2>
<ol>
 	<li>Immediate assertions</li>
 	<li>Concurrent assertions</li>
</ol>
<h3>Immediate Assertions</h3>
An assertion that checks a condition at the current simulation time is called an immediate assertion. Immediate assertions are procedural statements that can check only a combinational condition are evaluated immediately and they cannot involve any temporal operators.
<table width="100%">
<tbody>
<tr>
<td>Syntax: assert (condition_to_be_checked);</td>
</tr>
</tbody>
</table>
Example: Immediate Assertion

<img class="aligncenter size-medium wp-image-15969" src="https://www.maven-silicon.com/blog/wp-content/uploads/2023/02/Immediate-assertions-1024x320.jpg" alt="Immediate assertions" width="1024" height="320" />

As immediate assertions are instantaneously checked, they may report false failures due to multiple input changes at the same time. These unexpected multiple executions need to be avoided.

An extension to the immediate assertion is deferred immediate assertion and is used to avoid the multiple outputs or errors created due to the unexpected glitching activity on inputs in the immediate assertions.
<h3>Concurrent assertions</h3>
Concurrent assertions periodically sample the test signals and are based on clock edges. Concurrent assertion is the most valuable assertion style that can be used in design and verification environments. The concurrent assertions are executed in a three-step process, i.e  sampling the values, evaluating the test condition and executing the report in the below regions,
<ul>
 	<li>Preponed region – In this region, the values for the assertion variables are sampled. In this region, a net or variable cannot change its state. This allows the sampling of the most stable value at the beginning of the time slot.</li>
 	<li>Observed region- All the property expressions are evaluated in this region.</li>
 	<li>Reactive region- The pass/fail code (Action blocks) from the evaluation of the properties are scheduled in this region.</li>
</ul>
<img class="aligncenter wp-image-14678 size-full" src="https://www.maven-silicon.com/blog/wp-content/uploads/2023/02/syntax-660x37-1.png" alt="" width="660" height="37" />

 Example: concurrent assertion

<img class="aligncenter size-medium wp-image-15970" src="https://www.maven-silicon.com/blog/wp-content/uploads/2023/02/Concurrent-assertion-1024x330.jpg" alt="Concurrent assertion" width="1024" height="330" />
<h2> Case Study: AHB</h2>
Let us see some example assertions on AHB protocol.
<ul>
 	<li>Assertion to check write data and address during busy transfer.</li>
</ul>
<img class="aligncenter size-medium wp-image-15971" src="https://www.maven-silicon.com/blog/wp-content/uploads/2023/02/Assertion-to-check-write-data-and-address-during-busy-transfer-1024x260.jpg" alt="Assertion to check write data and address during busy transfer" width="1024" height="260" />
<ul>
 	<li>Assertion to check address for burst transfer wrap4 with halfword.</li>
</ul>
<img class="aligncenter size-medium wp-image-15972" src="https://www.maven-silicon.com/blog/wp-content/uploads/2023/02/Assertion-to-check-address-for-burst-transfer-wrap4-with-halfword-1024x261.jpg" alt="Assertion to check address for burst transfer wrap4 with halfword" width="1024" height="261" />
<ul>
 	<li>Assertion to check the boundary alignment for Word</li>
</ul>
<img class="aligncenter size-medium wp-image-15973" src="https://www.maven-silicon.com/blog/wp-content/uploads/2023/02/Assertion-to-check-the-boundary-alignment-for-Word-1024x364.jpg" alt="Assertion to check the boundary alignment for Word" width="1024" height="364" />
<ul>
 	<li>Assertion to check address for incremental burst.</li>
</ul>
<img class="aligncenter size-medium wp-image-15974" src="https://www.maven-silicon.com/blog/wp-content/uploads/2023/02/Assertion-to-check-address-for-incremental-burst.jpg--1024x249.jpg" alt="Assertion to check address for incremental burst" width="1024" height="249" />

Also read: <a href="https://www.maven-silicon.com/blog/how-do-i-learn-systemverilog-in-a-week/" target="_blank" rel="noopener noreferrer">How do I learn SystemVerilog in a week?</a>
<h2>Summary</h2>
In assertion-based verification, the assertions are used to capture design intent in a verifiable form providing a mechanism to check for correct behavior. During simulation, assertions improve controllability and observability, making the source of an error evident and the simulation debug time is also greatly reduced.

Assertion-based verification is a multi-faceted approach to verifying a collection of partial specifications more efficiently. SystemVerilog Assertions enable capabilities for both simulation and formal verification and directly address the limitations of today's verification flows.

Hope you have enjoyed this introduction and you can look forward to the next article which will discuss the use of implication in assertions and its importance in assertions.

To learn SystemVerilog in detail, explore our <a href="https://www.maven-silicon.com/asic-verification" target="_blank" rel="noopener noreferrer">Advanced ASIC Verification Course.</a>

SystemVerilog Assertions

<img class="alignnone size-medium wp-image-2756" src="https://www.maven-silicon.com/blog/wp-content/uploads/2023/02/Blog-Banners-18-1024x576.png" alt="SystemVerilog Assertions" width="1024" height="576" />

The elements that make up the SystemVerilog language can be used to describe electronic hardware's behavior at varying levels of abstraction. SystemVerilog is a parallel programming language and the SystemVerilog Event Scheduler plays a vital role in it. The execution of certain language constructs is defined by the parallel execution of blocks or processes. It is important to understand what execution order is guaranteed to the user and what execution order is indeterminate. Although SystemVerilog is used for more than simulation, the semantics of the language is defined for simulation, and everything else is abstracted from.
<h2>Event Driven Simulation</h2>
The SystemVerilog language is defined in terms of a discrete event execution model. A SystemVerilog description consists of connected threads of execution or processes. Processes are objects that can be evaluated, have a state, and respond to changes in their inputs to produce outputs. Processes are concurrently scheduled elements, such as initial procedures. Examples of processes include, but are not limited to, primitives; initial, always, always_comb, always_latch, and always_ff procedures; continuous assignments; asynchronous tasks; and procedural assignment statements.

Every change in the state of a net or variable in the system description being simulated is considered an update event. Processes are sensitive to update events. When an update event is executed, all the processes that are sensitive to that event are considered for evaluation in an arbitrary order. The evaluation of a process is also an event, known as an evaluation event.

In addition to events, another key aspect of a simulator is time. The term simulation time is used to refer to the time value maintained by the simulator to model the actual time it would take for the system description to be simulated. The term time is used interchangeably with simulation time.

<img class="size-medium wp-image-2713 aligncenter" src="https://www.maven-silicon.com/blog/wp-content/uploads/2023/01/image-1-660x197.png" alt="Event for sequential and combinational circuit" width="660" height="197" />

To fully support clear and predictable interactions, a single time slot is divided into multiple regions where events can be scheduled to order a particular type of execution. This allows properties and checkers to sample data when the design under test is in a stable state. Property expressions can be safely evaluated, and testbenches can react to both properties and checkers with zero delay, all in a predictable manner. This same mechanism also allows for nonzero delays in the design, clock propagation, and/or stimulus and response code to be mixed freely and consistently with cycle-accurate descriptions.
<h2>Stratified Event Scheduler</h2>
A compliant SystemVerilog simulator shall maintain some form of data structure, such as the SystemVerilog Event Scheduler, that allows events to be dynamically scheduled, executed, and removed as the simulator advances through time. The data structure is normally implemented as a time-ordered set of linked lists, which are divided and subdivided in a well-defined manner. The first division is by time. Every event has one and only one simulation execution time, which at any given point during the simulation can be the current time or some future time. All scheduled events at a specific time define a time slot. Simulation proceeds by executing and removing all events in the current simulation time slot before moving on to the next nonempty time slot, in time order. This procedure guarantees that the simulator never goes backward in time.

A time slot is divided into a set of ordered regions, as follows:
<ol>
 	<li>Preponed</li>
 	<li>Pre-Active</li>
 	<li>Active</li>
 	<li>Inactive</li>
 	<li>Pre-NBA</li>
 	<li>NBA</li>
 	<li>Post-NBA</li>
 	<li>Pre-Observed</li>
 	<li>Observed</li>
 	<li>Post-Observed</li>
 	<li>Reactive</li>
 	<li>Re-Inactive</li>
 	<li>Pre-Re-NBA</li>
 	<li>Re-NBA</li>
 	<li>Post-Re-NBA</li>
 	<li>Pre-Postponed</li>
 	<li>Postponed</li>
</ol>
There are two important groupings of event regions that are used to help define the scheduling of <a href="https://www.maven-silicon.com/blog/is-it-worth-learning-systemverilog-in-college-itself/">SystemVerilog</a> activity, the active region set, and the reactive region set. Events scheduled in the Active, Inactive, Pre-NBA, NBA, and Post-NBA regions are active region set events. Events scheduled in the Reactive, Re-Inactive, Pre- Re-NBA, Re-NBA, and Post-Re-NBA regions are reactive region set events.

The simulation regions of a time slot are the Preponed, Active, Inactive, NBA, Observed, Reactive, Re-Inactive, Re-NBA, and Postponed regions.

In addition to the simulation regions, where PLI callbacks can be scheduled, there are additional PLI-specific regions. The PLI regions of a time slot are the Preponed, Pre-Active, Pre-NBA, Post-NBA, Pre-Observed, Post-Observed, Pre-Re-NBA, Post-Re-NBA, and Pre-Postponed regions.

In this paper, we will discuss Simulation regions. To make sure there is no race between testbench &amp; RTL, they both will work in different regions.

<img class="size-medium wp-image-2714 aligncenter" src="https://www.maven-silicon.com/blog/wp-content/uploads/2023/01/image-2-549x365.png" alt="Simulation regions" width="549" height="365" />
<h3>Regions that are designed to implement correct RTL functionality: </h3>
Active regions (Active, Inactive, and NBA regions - but avoid Inactive region events).
<h3>Regions that are designed to implement correct verification execution:</h3>
Preponed, Reactive regions (Reactive, Re-Inactive, Re-NBA), and Postponed regions.
<h3>Regions that are designed to implement concurrent assertion checking: </h3>
Preponed, Observed, and Reactive regions.
<h3>Region that should be avoided: </h3>
Inactive region.

Also read: <a href="https://www.maven-silicon.com/blog/systemverilog-class-based-verification-environment/" target="_blank" rel="noopener noreferrer">SystemVerilog  Class-based Verification environment</a>

Preponed Region: Preponed region is for the verification environment. The assertion signals and the clocking block inputs with #1step delay are sampled in this region. Sampling in the Preponed region is equivalent to sampling in the previously postponed region.

Active Region: The Active region holds the current active region set events being evaluated and can be processed in any order. The events are,
<ul>
 	<li>All the blocking assignments in the module block.</li>
 	<li>Evaluate the Right-Hand-Side (RHS) of all nonblocking assignments in the module block and schedule updates into the NBA region.</li>
 	<li>All module continuous assignments in the module block.</li>
 	<li>Evaluate inputs and update outputs of Verilog primitives.</li>
 	<li>Execute the $display and $finish commands.</li>
</ul>
Inactive Region: This region is where #0 blocking assignments in the module block are scheduled. It is not recommended to make #0 assignments in RTL.

NBA Region: In this region, the Left- Hand-side variables of non-blocking assignment statements in the module block get updated.

Observed Region: The concurrent assertions are evaluated in this region. Also, clocking block inputs with explicit #0 step delay are sampled in the Observed region.

Reactive Region: The following events take place in this region,
<ul>
 	<li>Action blocks of the concurrent assertions.</li>
 	<li>Blocking assignments in the program block.</li>
 	<li>Evaluate the Right-Hand-Side (RHS) of all program nonblocking assignments in the program block and schedule updates into the Re-NBA region.</li>
 	<li>All continuous assignments in the program block.</li>
 	<li>Execute the $exit and implicit $exit commands.</li>
</ul>
Re-Inactive Region: #0 delays in the program block are executed in this region.

Re-NBA Region: In this region, the Left- Hand-side variables of non-blocking assignment statements in the program block get updated. Also, clocking block outputs with explicit #0 skew shall be driven at the same time as their specified clocking event, in the Re-NBA region.

Postponed Region: $monitor and $strobe are scheduled in the Postponed region.

Also read: <a href="https://www.maven-silicon.com/blog/how-do-i-learn-systemverilog-in-a-week/" target="_blank" rel="noopener noreferrer">How do I learn SystemVerilog in a week?</a>
<h2>Conclusion</h2>
Due to the concurrent nature of Verilog and SystemVerilog language, multiple processes will be working at the same time. This may result in race conditions. The design and verification code should work in different regions to avoid race operation between the DUT &amp; TB. Also, the SystemVerilog assertions should sample DUT data when the design is in a stable state so that the assertions can be safely evaluated. The SystemVerilog event scheduler will make sure there is proper interaction between different processes within the RTL, between the RTL &amp; TB, and between RTL &amp; assertions.

To learn SystemVerilog in detail, please explore our <a href="https://www.maven-silicon.com/asic-verification" target="_blank" rel="noopener noreferrer">Advanced ASIC Verification Course</a>

All Posts

PCIe Explained: The Silent Powerhouse Driving Modern Tech

Essential Role of Formal Verification in Hardware Design

What is UVM Factory?

SystemVerilog Tutorial for Beginners

SystemVerilog Assertions

SystemVerilog Event Scheduler

SUBSCRIBERS

Subscribe to our Blog

Maven Learning App

Get trained online as a VLSI Professional

40%^OFF

SUBSCRIBERS

Subscribe to our Blog

Have Doubts?
Read Our FAQs

All Posts

PCIe Explained: The Silent Powerhouse Driving Modern Tech

Essential Role of Formal Verification in Hardware Design

What is UVM Factory?

SystemVerilog Tutorial for Beginners

SystemVerilog Assertions

SystemVerilog Event Scheduler

SUBSCRIBERS

Subscribe to our Blog

Maven Learning App

Get trained online as a VLSI Professional

40%OFF

SUBSCRIBERS

Subscribe to our Blog

Have Doubts?Read Our FAQs

40%^OFF

Have Doubts?
Read Our FAQs