Shanthi heads front-end verification training for academic engagements and corporate internships. Her articles reverberate her extensive experience in the semiconductor industry and add value to our VLSI aspirants' careers.

Shanthi V A

<img class="alignnone size-medium wp-image-18506" src="https://www.maven-blog-admin.maven-silicon.com/wp-content/uploads/2025/12/20-11-25-1-1024x576.png" alt="" width="1024" height="576" />Ever wondered how your phone’s apps can run safely without crashing the entire operating
system, or how sensitive data like fingerprint scans remains isolated from everyday
applications? The answer lies deep within the processor's architecture, specifically in
something called “privilege levels.”
This blog dives deep into ARM’s privilege model, explaining the different levels, how they
interact, and why they’re essential in secure, multitasking environments.
<h3>What are Privilege Levels?</h3>
Privilege levels define how much control a program has over system resources like memory,
interrupts, and device registers. Programs running at higher privilege levels can:
• Control hardware directly.
• Access all memory and I/O.
• Manage other programs.
Programs at lower privilege levels have restricted access and rely on higher levels (like the
OS) to mediate interactions.
<h3>Why Privilege Levels Matter?</h3>
Security
<ul>
 	<li> Prevents user applications from accessing sensitive system resources.</li>
 	<li> Isolates secure operations (e.g., cryptography, key storage) in higher privilege levels.</li>
</ul>
Stability
<ul>
 	<li> Ensures that only trusted code can modify system configurations.</li>
 	<li>Reduces the risk of crashes due to rogue or buggy applications.</li>
</ul>
Performance
<ul>
 	<li> Enables efficient context switching between user and kernel space.</li>
 	<li> Supports virtualization and secure execution environments.</li>
</ul>
<h3>Privilege Levels in ARM v7</h3>
In ARMv7-A, there are two primary privilege levels:
• User Mode (PL0)
<ul>
 	<li>Least privileged. For application code.</li>
 	<li>Cannot access hardware directly.</li>
 	<li>Restricted from executing privileged instructions.</li>
</ul>
• Privileged Modes (PL1)
Includes:
<ul>
 	<li> Supervisor (SVC) – OS kernel mode.
</li>
 	<li>IRQ/FIQ – For interrupt handling.</li>
 	<li> Abort/Undefined/System – For exceptions and advanced debugging.</li>
</ul>
<h3>Privilege Levels or Exception Levels in ARM v8</h3>
Starting with ARMv8-A, ARM processors use four Exception Levels (ELs):

<img class=" wp-image-18507 aligncenter" src="https://www.maven-blog-admin.maven-silicon.com/wp-content/uploads/2025/12/unnamed-16.png" alt="" width="659" height="215" />

Each level has its own set of system registers and operates in either Secure or Non-secure world  (with TrustZone). 
<table>
<tbody>
<tr>
<td>Exception Level </td>
<td>Role </td>
<td>Typical Software</td>
</tr>
<tr>
<td>EL3 </td>
<td>Secure Monitor </td>
<td>TrustZone Monitor (TF-A)</td>
</tr>
<tr>
<td>EL2 </td>
<td>Hypervisor </td>
<td>KVM, Xen, VMware</td>
</tr>
<tr>
<td>EL1 </td>
<td>Operating System Kernel </td>
<td>Linux, RTOS, Windows</td>
</tr>
<tr>
<td>EL0 </td>
<td>User Applications </td>
<td>Apps, processes</td>
</tr>
</tbody>
</table>
It's important to note that each Exception Level (EL0, EL1, EL2, EL3) can conceptually exist  in both the Secure and Non-secure worlds, with EL3 acting as the gatekeeper to switch between  these two global states. For instance, an EL1 operating system can run in the Non-Secure  World, while a trusted application's EL1 component could be running in the Secure World. 
<h3>EL0 – User Mode (Least Privileged) </h3>
Purpose:
• Runs user applications.
• Has the least access to hardware.
• Can’t access memory directly or use privileged instructions.
Restrictions:
• Cannot configure memory or peripherals.
• Needs to use system calls to request services from the OS.

Example Applications
• Running apps like:
<ul>
 	<li>Instagram</li>
 	<li>WhatsApp</li>
 	<li>A game on your phone</li>
</ul>
• A user-space program on Linux like nano, ls, or your C/C++ application.
<h3>EL1 – Kernel Mode (Privileged Mode)</h3>
Purpose:
• Runs the Operating System kernel.
• Manages:
<ul>
 	<li>Memory</li>
 	<li>Interrupts</li>
 	<li>Drivers</li>
 	<li>System calls</li>
</ul>
Capabilities:
• Can access hardware registers.
• Can manage virtual memory and page tables.
• Can handle interrupts and exceptions.

Example Applications:
• Linux kernel
• RTOS kernel (like FreeRTOS, Zephyr, or RTX on Cortex-A)
• ThreadX or VxWorks in embedded systems
• On Raspberry Pi running Linux, EL1 handles:
▪ File systems
▪ Process scheduling
▪ Device control

<h3>EL2 – Hypervisor Mode (Virtualization Layer)</h3>
Purpose:
<ul>
 	<li> Allows one physical machine to run multiple virtual machines (VMs).</li>
 	<li> Each VM runs its own OS as if it were on its own hardware.</li>
</ul>
Capabilities:
<ul>
 	<li> Controls and isolates guest operating systems.</li>
 	<li>Can intercept privileged instructions from guest kernels.</li>
</ul>
Example Applications:
<ul>
 	<li> KVM (Kernel-based Virtual Machine) on Linux</li>
 	<li>Xen Hypervisor on ARM servers</li>
 	<li> Android’s Virtualization Framework for secure containers</li>
 	<li> Samsung Knox, which uses EL2 for secure workspace separation</li>
</ul>
<h3>EL3 – Secure Monitor Mode (TrustZone Controller)</h3>
Purpose:
<ul>
 	<li> Manages TrustZone, separating:</li>
</ul>
▪ Secure World (for sensitive operations)
▪ Non-Secure World (normal OS/apps)

<ul>
 	<li> Acts as a gateway between these two worlds.</li>
</ul>
Capabilities:
<ul>
 	<li> Can switch between Secure and Non-Secure modes.</li>
 	<li> Can run trusted firmware and secure bootloaders.</li>
</ul>
Example Applications:
<ul>
 	<li>ARM Trusted Firmware (ATF)</li>
 	<li>Secure Boot mechanisms</li>
 	<li> Digital Rights Management (DRM)</li>
 	<li> Mobile Payment Security (e.g., Samsung Pay, Apple Secure Enclave uses a similar
idea)</li>
</ul>
<h3>ARM TrustZone and Secure World</h3>
TrustZone extends the privilege model with secure vs non-secure states. This allows the
processor to operate in:
<ul>
 	<li> Secure World (for crypto, secure storage, DRM)</li>
 	<li>Non-secure World (normal OS and apps)</li>
</ul>
Combined with ELs, this adds even more security flexibility. For instance, EL3 typically runs  the Secure Monitor, managing context switches between secure and non-secure worlds. 

Let’s take an Android phone as an example: 
<table style="height: 281px;" width="618">
<tbody>
<tr>
<td>Function </td>
<td>Privilege Level</td>
</tr>
<tr>
<td>Instagram app </td>
<td>EL0</td>
</tr>
<tr>
<td>Android OS (Linux Kernel) </td>
<td>EL1</td>
</tr>
<tr>
<td>Virtual Machine for secure apps </td>
<td>EL2</td>
</tr>
<tr>
<td>Secure Boot / Fingerprint unlock </td>
<td>EL3</td>
</tr>
</tbody>
</table>
<h3>How does the transition happen between different ARM Privilege Levels? </h3>
In ARM architecture (especially ARMv8-A), privilege levels (EL0–EL3) aren’t just static  modes. Code and the system actively switch between them during execution — this is what  enables multitasking, system calls, virtualization, and secure operations. 

Let’s walk through how and why transitions happen, with examples. 

Overview: Who Can Switch Where? 
<ul>
 	<li>Transitions typically happen from a lower level to a higher level (e.g., EL0 → EL1) via  exceptions or traps. </li>
 	<li>Returning back (e.g., EL1 → EL0) is done using return-from-exception instructions (ERET).</li>
</ul>
<h3>EL0 → EL1: System Call or Exception </h3>
When it happens:
<ul>
 	<li>A user app (EL0) needs a service from the OS kernel (EL1), like:</li>
</ul>
▪ Reading a file
▪ Allocating memory
▪ Printing to console
How it happens:
<ul>
 	<li>The app executes a system call instruction:</li>
</ul>
▪ ARMv8: SVC #imm (Supervisor Call)

<ul>
 	<li>This generates an exception, which causes the CPU to:
</li>
</ul>
▪ Save the current state.
▪ Jump to the EL1 exception handler (in the OS kernel). 
Example

<img class="alignnone wp-image-18508" src="https://www.maven-blog-admin.maven-silicon.com/wp-content/uploads/2025/12/unnamed-17.png" alt="" width="732" height="123" />This traps into EL1, where the kernel performs the write() system call.
<h3>EL1 → EL0: Return to User Space</h3>
When it happens: 
<ul>
 	<li>The OS finishes the system call and gives control back to the user app.</li>
</ul>
How it happens: 
<ul>
 	<li>Kernel executes the ERET instruction (Exception Return)</li>
 	<li>CPU: </li>
</ul>
▪ Restores saved state of EL0
▪ Switches back to user mode 
Tip:
The OS must validate everything before returning to EL0 to avoid security issues (e.g., buffer  overflows). 
<h3>EL1 → EL2: Hypervisor Trap </h3>
When it happens: 
<ul>
 	<li>The OS tries to execute a virtualization-sensitive instruction that’s restricted in  virtualized environments. </li>
 	<li>Or, the hypervisor wants to boot a guest OS. </li>
</ul>
How it happens: 
<ul>
 	<li>The instruction causes a trap to EL2. </li>
 	<li>EL2 hypervisor takes over, handles the trap, and may emulate or allow the instruction.</li>
</ul>
Example: 
<ul>
 	<li>The Linux kernel running as a guest in KVM tries to access a device, → trap to EL2. </li>
</ul>
<h3>EL2 → EL1: Return to Guest OS </h3>
When it happens: 
<ul>
 	<li>Hypervisor has finished handling a trap or has scheduled a guest OS to run.</li>
</ul>
How it happens:
<ul>
 	<li> EL2 restores the guest OS context and executes ERET.</li>
</ul>
<h3>EL1 or EL2 → EL3: Secure Monitor Call (SMC) </h3>
When it happens: 
<ul>
 	<li>A request is made to the Secure World, like: </li>
</ul>
▪ Accessing a secure key
▪ Verifying a fingerprint
▪ Handling secure boot
How it happens: 
<ul>
 	<li>Code executes an SMC (Secure Monitor Call) instruction. </li>
 	<li>CPU traps into EL3. </li>
</ul>
Example: 
<ul>
 	<li>Android device requesting cryptographic services from TrustZone. </li>
</ul>
<h3>EL3 → EL1 or EL2: Return from Secure Monitor</h3>
When it happens:
<ul>
 	<li> EL3 has completed the secure operation.</li>
</ul>
How it happens:
<ul>
 	<li> EL3 uses ERET to return control back to EL1 or EL2.</li>
 	<li>Also restores non-secure world context.</li>
</ul>
<table>
<tbody>
<tr>
<td>From → To </td>
<td>Trigger </td>
<td>Instruction </td>
<td>Example Scenario</td>
</tr>
<tr>
<td>EL0 → EL1 </td>
<td>System call or fault </td>
<td>SVC </td>
<td>App asks OS to open a file</td>
</tr>
<tr>
<td>EL1 → EL0 </td>
<td>Return from system  call</td>
<td>ERET </td>
<td>OS finishes task and returns to app</td>
</tr>
<tr>
<td>EL1 → EL2 </td>
<td>Trap from guest OS </td>
<td>Auto trap </td>
<td>Virtualized OS accesses restricted  feature</td>
</tr>
<tr>
<td>EL2 → EL1 </td>
<td>Resume guest OS </td>
<td>ERET </td>
<td>Hypervisor schedules next VM</td>
</tr>
<tr>
<td>EL1/2 → EL3 </td>
<td>Secure Monitor Call </td>
<td>SMC </td>
<td>Fingerprint scan, secure transaction</td>
</tr>
<tr>
<td>EL3 → EL1/2 </td>
<td>Return to  normal/non-secure</td>
<td>ERET </td>
<td>TrustZone returns control to  normal world</td>
</tr>
</tbody>
</table>
Key Takeaways 
<ul>
 	<li>ARM uses ELs for security and stability </li>
 	<li>EL0 is for running user apps </li>
 	<li>EL1 is where the OS runs </li>
 	<li>EL2 is for hypervisors, &amp; EL3 is for secure monitor </li>
 	<li>Transitions between lower EL to higher EL happen via exceptions like SVC or SMC  and return to lower EL with ERET command </li>
</ul>
Understanding privilege levels in ARM is crucial for developers working on secure and  efficient systems. Whether you're building an operating system, a secure IoT device, or a  virtualized environment, leveraging ARM's privilege model helps you design with security and  reliability in mind.

Privilege Levels in ARM Architecture

<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?

<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>

SystemVerilog Event Scheduler

&nbsp;

<img class="aligncenter size-medium wp-image-16559" src="https://www.maven-silicon.com/blog/wp-content/uploads/2022/08/Clock-Domain-Crossing-1024x576.png" alt="Clock Domain Crossing" width="1024" height="576" />

What is CDC?

Today’s device needs multiple clocks with increasing system integration, peripherals &amp; external interfaces, and power management. In a design with multiple clocks, clock domain crossing occurs whenever data is transferred from a flip-flop driven by one clock to a flip-flop driven by another clock. When the signal is sampled in another clock domain and if there is any setup and hold time violation, the receiving register may become metastable and the output settles to some random value after an unknown amount of time.

<img class="size-full wp-image-2597 aligncenter" src="https://www.maven-silicon.com/blog/wp-content/uploads/2022/08/Capture-1.png" alt="CDC-1" width="553" height="141" />

Effects of Metastability

Since the CDC signal can fluctuate for some period of time, the input logic in the receiving clock domain might recognize the logic level of the fluctuating signal to be different values and hence propagate erroneous signals into the receiving clock domain. If the unstable data is fed to several other places in the design, it may also lead to a high current flow and even chip burnout in the worst case.

In a multi-clock design, metastability cannot be avoided but the detrimental effects of metastability can be neutralized by adding synchronizers. Today’s SOC can have &gt;104 CDC signals on a single chip. Mean time before failure (MTBF) tells us how frequently the storage element can become metastable. Larger MTBF indicates longer time periods between failures, while smaller MTBF indicates that metastability can happen frequently.

<img class="alignnone wp-image-2612 size-full" src="https://www.maven-silicon.com/blog/wp-content/uploads/2022/08/Capture-9.png" alt="MTBF Formula" width="207" height="175" />

Different Types of Synchronizers

The synchronizer avoids sampling metastable signals at the destination. Different types of synchronization structures are available, and each structure has strict rules for implementation that should be verified. In this paper, the most commonly used synchronizers are discussed.

Multi-flop Synchronizer

The most used synchronizer is the multi-flop synchronizer shown in the below diagram

<img class="size-full wp-image-2599 aligncenter" src="https://www.maven-silicon.com/blog/wp-content/uploads/2022/08/Capture-3.png" alt="CDC-3" width="567" height="162" />

By adding synchronizer Flip flop in the destination domain, it allows sufficient time for the oscillations to settle down and ensure that a stable output is obtained in the destination domain by preventing the sampling of metastable signal. These multi-flop synchronizers can be used in the path of single-bit control signals.

Protocol to be taken care of for Multi-Flop Synchronizer

The glitch-free output should be driven from the transmitting clock domain to receiving clock domain, i.e., always the registered output from the transmitting clock domain should be driven to receiving clock domain and no combinational logic should be added between sending &amp; receiving flipflops to avoid glitches. Do not place any combinational logic between synchronizer flip-flops to reduce the probability of metastability effect by reducing propagation delay between synchronizer flip-flops

Toggle Synchronizer

If the control signal changes too fast then the multi-flop synchronizer cannot avoid the sampling of a metastable signal at the receiving clock domain. In this case, we can use Toggle synchronizer as shown in the below diagram. The basic function of a pulse synchronizer is to take a single clock wide pulse from one clock domain and create a single clock wide pulse in the new domain.

<img class="size-full wp-image-2600 aligncenter" src="https://www.maven-silicon.com/blog/wp-content/uploads/2022/08/Capture-4.png" alt="CDC-4" width="562" height="187" />

Protocol to be taken care of for Toggle Synchronizer

One restriction of a pulse synchronizer is that input pulses must have a minimum spacing between pulses equal to two synchronizer clock periods. If the input pulses are closer, the output pulses in the new clock domain are adjacent to each other, resulting in an output pulse that is wider than one clock cycle.

Gray Encoding

Consider a case as shown in the example where the input to the FSM is driven through synchronizers. The change in multiple bits at the same time may cause misalignment in the bus due to unpredictable delays in CDC paths, and the bus may go to illegal values and the state machine may hang. To prevent this issue we can use gray coding logic to the bus &amp; this will prevent illegal values to occur. Now when the multiple bit changes at same time, the illegal value will not happen, but it will add unexpected delay.

<img class="size-full wp-image-2601 aligncenter" src="https://www.maven-silicon.com/blog/wp-content/uploads/2022/08/Capture-5.png" alt="CDC-5" width="548" height="122" />

Mux Synchronizer

Suppose we have data of 16 bits to transfer from one clock domain to another clock domain, we cannot add synchronizers in the data path for all the 16 bits as it increases the size of the chip. In this case we can add synchronizers in the control path.

Transmitter domain is responsible to keep data stable on the bus when captured by the receiving domain (when sel of mux signal is asserted)

<img class="size-full wp-image-2602 aligncenter" src="https://www.maven-silicon.com/blog/wp-content/uploads/2022/08/Capture-6.png" alt="CDC - 6" width="533" height="160" />

Handshaking Data between Clock Domains

The transmitter working on the C1 clock domain places data onto a data bus and then synchronizes a "req" signal (request) to the receiving clock (c2) domain. The "req" signal is recognized in the destination clock domain, the receiver clocks the data into a register (the data should have been stable for at least two/three sampling clock edges in the destination clock domain) and then passes an "ack" signal (acknowledgement) through a synchronizer to the sender. When the sender recognizes the synchronized "ack" signal, the sender can de-assert the “req” signal, then the receiver also de-asserts the “ack” signal to inform the sender that it is ready to accept another data. The sender can again start the handshaking process

With this technique, it is required that the receiving clock domain have logic in place to capture the data when the pulse is detected, because the pulse will only be valid for one receiving clock cycle per multi-cycle data word.

<img class="size-full wp-image-2603 aligncenter" src="https://www.maven-silicon.com/blog/wp-content/uploads/2022/08/Capture-7.png" alt="CDC-7" width="570" height="159" />

FIFOS

Asynchronous FIFO can be used to transmit data between two clock domains. Write operation to FIFO will happen in the clock C1 domain. Read operation from FIFO will happen in clock C2 domain. FIFO depth should be taken care based on frequency of the clocks C1 and C2

<img class="size-full wp-image-2604 aligncenter" src="https://www.maven-silicon.com/blog/wp-content/uploads/2022/08/Capture-8.png" alt="CDC-8" width="551" height="211" />CDC Analysis

Even after adding all the synchronization techniques, still, there will be some errors. Traditional methods like simulation and static timing analysis alone are not sufficient to verify that the data is transferred consistently and reliably across clock domains. They are found late in the development cycle, usually only in silicon. Silicon Failures are intermittent, difficult to reproduce the same error.

Types of CDC errors

Synchronization errors – The errors caused by improper or missing synchronizers

CDC Transfer Protocol errors – The errors caused by violation of protocols of the synchronization structure

CDC reconvergence errors - The errors caused by non – deterministic delays of CDC signals to settle to a stable value

CDC Analysis Flow

Structural Analysis: Structural analysis must identify Different clock domains, CDC signals, and Synchronizers. It reports incorrect or missing synchronizers.

CDC Protocol Verification: During structural analysis only limited amount of protocol checking will happen. For unproven protocols assertions are created in the existing verification environment. The assertions can be verified with simulation or formal verification

Reconvergence Verification: It involves modelling dynamic delays caused by metastability. Behavioural model will model silicon accurate metastability with behaviour in simulation. By modelling this delay designers can identify reconvergence logic that is incorrect in that the logic is not tolerant to the metastability delays

Why CDC for your VLSI Career?

The semiconductor industry needs dedicated VLSI engineers who specialize in CDC verification, in addition to the regular verification engineers, as most of the current chips and SoCs are complex enough to have CDC by default with multiple clock domains. The CDC verification demands different verification methodologies like rule checking, simulation, STA, formal verification, etc. So learning CDC verification techniques along with RTL design and verification methodologies will help the electronics engineers to enter the Semiconductor Industry quickly, projecting their CDC verification skills as an added advantage. Are you the next CDC Expert we have been searching for?

If you're aspiring to become a Verification Engineer, <a href="https://www.maven-silicon.com/asic-verification" target="_blank" rel="noopener noreferrer">explore our Advanced ASIC Verification Course</a> to learn different verification methodologies like rule checking, simulation, STA, formal verification, etc. along with Clock Domain Crossing.

Shanthi V A

Technical Lead

All Posts

Privilege Levels in ARM Architecture

What is UVM Factory?

SystemVerilog Event Scheduler

Clock Domain Crossing

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

Shanthi V A

Technical Lead

All Posts

Privilege Levels in ARM Architecture

What is UVM Factory?

SystemVerilog Event Scheduler

Clock Domain Crossing

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