Skip to main content

SoC Verification: Interrupt Verification & Interrupt Handling

Image
By

 

SoC Verification: Interrupt Verification & Interrupt Handling – A Complete Guide

Modern System-on-Chip (SoC) designs integrate dozens or even hundreds of peripherals such as timers, UARTs, GPIOs, DMA engines, USB controllers, PCIe controllers, and AI accelerators. Since the processor cannot continuously poll every peripheral, interrupt mechanisms are used to notify the CPU whenever an event requires immediate attention.

Interrupt verification is therefore one of the most important parts of SoC verification. A single bug in interrupt handling can lead to missed events, system hangs, incorrect priority handling, or data corruption.

This article explains interrupt concepts, interrupt handling flow, architecture, verification methodology, common bugs, and coverage strategies used by ASIC verification engineers.


What is an Interrupt?

An interrupt is a signal generated by hardware or software that temporarily stops the normal execution of the processor and requests immediate servicing.

Instead of continuously checking every peripheral (polling), the processor responds only when an interrupt occurs.

Typical interrupt sources include:

  • Timer expiration
  • UART receive complete
  • GPIO edge detection
  • DMA transfer completion
  • Watchdog timeout
  • Hardware faults
  • Software-generated interrupts

The processor pauses the current program, executes a special routine called the Interrupt Service Routine (ISR), and then resumes execution from the point where it was interrupted.

Why Interrupts are Important

Interrupts provide several advantages:

  • Faster response to external events
  • Better CPU utilization
  • Reduced software overhead
  • Lower power consumption
  • Real-time responsiveness

Without interrupts, processors would waste cycles continuously polling peripherals.

Interrupt Handling Flow

A typical interrupt sequence follows these steps:



The interrupt controller acts as the bridge between peripherals and the processor by collecting interrupt requests, assigning priorities, and forwarding the appropriate interrupt to the CPU.




Types of Interrupts

Interrupts can be classified in multiple ways.

1. Based on Source

External Interrupts

Generated by hardware peripherals such as:

  • GPIO
  • UART
  • Timer
  • Ethernet
  • USB
  • PCIe

Internal Interrupts

Generated inside the processor due to:

  • Divide-by-zero
  • Illegal instruction
  • Memory fault
  • Software interrupt
  • Debug events

2. Based on Masking

Maskable Interrupts

These interrupts can be enabled or disabled by software.

Examples:

  • UART interrupt
  • Timer interrupt
  • GPIO interrupt

Non-Maskable Interrupts (NMI)

These cannot be disabled because they represent critical events.

Examples:

  • Hardware failure
  • Power failure
  • Watchdog reset

3. Based on Triggering

Level-Triggered Interrupt

The interrupt remains active as long as the signal remains asserted.

Example:

IRQ

██████████

Edge-Triggered Interrupt

Generated only during signal transitions.

Examples:

  • Rising edge
  • Falling edge
  • Both edges 
IRQ

____/‾‾‾‾

Typical Interrupt Architecture

A simplified interrupt architecture looks like:



The interrupt controller performs:

  • Interrupt collection
  • Priority resolution
  • Interrupt masking
  • Pending status management
  • Routing interrupts to CPU cores



CPU Interrupt Handling Steps

When an interrupt occurs, the processor typically performs the following sequence:

Step 1: Interrupt Request

A peripheral asserts the interrupt request signal.

INT_REQ = 1

Step 2: Finish Current Instruction

Modern processors generally complete the current instruction before servicing the interrupt.

Step 3: Interrupt Acknowledge

The CPU acknowledges the interrupt request.

IRQ_ACK = 1

Step 4: Save Processor Context

The CPU saves:

  • Program Counter (PC)
  • Processor Status Register (PSR)
  • General-purpose registers
  • Stack Pointer (if required)

Step 5: Fetch ISR Address

The processor obtains the ISR address from the interrupt vector table.

Step 6: Execute ISR

The Interrupt Service Routine:

  • Clears interrupt source
  • Services peripheral
  • Processes data
  • Updates registers

Step 7: End of Interrupt (EOI)

The CPU informs the interrupt controller that servicing has completed.

Step 8: Restore Context

Previously saved registers are restored.

Step 9: Resume Execution

Execution continues exactly where it was interrupted.

Key Interrupt Signals

A typical interrupt interface includes:

SignalPurpose
INT_REQInterrupt request from peripheral
IRQInterrupt line to CPU
IRQ_ACKCPU acknowledges interrupt
ENABLEEnables interrupt
MASKMasks interrupt
PENDIndicates pending interrupt
PRIORITYInterrupt priority level
EOIEnd of interrupt
INT_VECInterrupt vector number
NMINon-maskable interrupt

Interrupt Verification Checklist

An interrupt verification plan should ensure that every stage of interrupt handling functions correctly.

Key verification points include:

  • Interrupt generation from every source
  • Delivery to interrupt controller
  • Delivery to CPU
  • Priority resolution
  • Interrupt masking and unmasking
  • Interrupt acknowledgment
  • ISR execution
  • Context save and restore
  • End-of-Interrupt signaling
  • Return to previous program
  • Prevention of interrupt loss
  • Prevention of duplicate interrupts
  • Correct interrupt re-triggering after de-assertion

Important Verification Scenarios

Interrupt logic must be verified under both normal and corner-case conditions.

Normal Scenarios

  • Single interrupt
  • Multiple interrupt sources
  • Different priority levels
  • Mask and unmask operations
  • ISR execution
  • Correct EOI sequence

Corner Cases

  • Back-to-back interrupts
  • Simultaneous interrupts
  • Interrupt during reset
  • Interrupt during sleep or idle mode
  • Nested interrupts
  • Interrupt while another ISR is executing
  • Spurious interrupts
  • Interrupt flood or stress testing
  • Mask/unmask during active interrupts
  • Priority inversion scenarios

These scenarios help ensure robust interrupt behavior under real-world conditions.

Common Interrupt Bugs

Interrupt-related issues are common during SoC verification. Typical bugs include:

  • Missed interrupt due to synchronization issues
  • Incorrect priority arbitration
  • Interrupt not cleared after ISR execution
  • Re-triggering caused by incorrect EOI handling
  • Corrupted CPU context after ISR
  • Interrupt delivered while masked
  • Wrong interrupt vector address
  • False or spurious interrupt detection
  • Duplicate interrupt delivery
  • Lost interrupt under heavy traffic

Identifying these bugs early prevents expensive silicon re-spins.

Interrupt Verification Environment

A UVM-based interrupt verification environment typically consists of:

The environment generally includes:

  • Random and directed test sequences
  • Interrupt generators
  • Register access sequences
  • Monitors and protocol checkers
  • Assertions for timing and protocol
  • Scoreboards for end-to-end validation
  • Functional coverage collection


Coverage Points

High functional coverage ensures confidence that all interrupt functionality has been exercised.

Typical coverage points include:

  • Interrupt source coverage
  • Interrupt type (level/edge) coverage
  • Priority level coverage
  • Mask and unmask coverage
  • ISR entry and exit coverage
  • EOI and acknowledgment coverage
  • Spurious interrupt coverage
  • Error handling coverage
  • Cross coverage of source × priority × trigger type

A well-designed coverage model helps identify untested scenarios before tape-out.

Best Practices for Interrupt Verification

To improve verification quality:

  • Develop both directed and constrained-random tests.
  • Verify the complete interrupt flow from generation to ISR completion.
  • Include assertions for protocol and timing checks.
  • Stress-test the interrupt controller with high interrupt rates.
  • Validate nested and simultaneous interrupt handling.
  • Ensure proper context save and restore during ISR execution.
  • Collect comprehensive functional coverage and close all coverage gaps.
  • Test across different power modes, reset conditions, and CPU states.

Conclusion

Interrupt handling is fundamental to reliable SoC operation, enabling processors to respond quickly and efficiently to hardware and software events. Because interrupts influence system responsiveness, reliability, and real-time performance, verifying them thoroughly is essential.

A robust interrupt verification strategy should validate the entire flow—from interrupt generation and prioritization to delivery, acknowledgment, ISR execution, and return—while also stressing corner cases such as nested, simultaneous, and spurious interrupts. Combining comprehensive UVM testbenches, protocol assertions, scoreboards, and functional coverage ensures high confidence in the design before silicon tape-out.

Whether you're verifying an interrupt controller, CPU subsystem, or a complete SoC, meticulous interrupt verification is key to building reliable, deterministic, and bug-free systems.

Labels:

Comments

Post a Comment

Popular posts from this blog

Module 1 — SystemVerilog Basics

By
VLSI Verification  •  SystemVerilog Series Module 1 — SystemVerilog Basics A complete, example-driven walkthrough of SystemVerilog fundamentals: data types, variables vs nets, arrays of every flavor, strings, enums, structs, unions, and typedef — the building blocks every verification engineer needs before UVM. 🧩 Beginner → Intermediate ⏱ ~25 min read 💻 Code Examples Included 📑 Table of Contents Introduction to SystemVerilog Verilog vs SystemVerilog Data Types: 2-State vs 4-State Logic Variables and Nets Arrays: Packed vs Unpacked Dynamic Arrays Queues Associative Arrays Strings Enumerations Structures Unions Typedef 1 Introduction to SystemVerilog SystemVerilog (IEEE 1800) is a unified hardware description and verification language (HDVL). It extends Verilog (IEEE 1364) with powerful constructs for design (interfaces, always_comb/always_ff, enhanced d...
Post a Comment
Read more

GPU Memory System & Interconnect: How Data Travels Inside a Modern GPU

By
GPU Memory System & Interconnect: How Data Travels Inside a Modern GPU Modern GPUs deliver incredible computing power by processing thousands of operations simultaneously. While compute cores often receive the spotlight, the real performance of a GPU depends heavily on how efficiently data moves between memory and compute units. A GPU memory system is designed to provide extremely high bandwidth while keeping latency as low as possible. This is achieved through a collection of specialized hardware components working together, including the Memory Controller, HBM/GDDR memory, Crossbar, Network-on-Chip (NoC), DMA Engine, PCIe Interface, and NVLink. In this article, we'll explore each component in detail and understand how they collectively enable high-performance parallel computing. Why Does GPU Memory Matter? Every GPU application—from gaming and graphics rendering to AI model training and scientific simulations—requires continuous movement of enormous amounts of data. For examp...
Post a Comment
Read more

Clock Domain Crossing (CDC): A Complete Beginner's Guide to Metastability, Synchronizers & Safe Data Transfer

By
Clock Domain Crossing (CDC): A Complete Beginner's Guide to Metastability, Synchronizers & Safe Data Transfer Modern System-on-Chip (SoC) designs rarely operate with a single clock. Instead, different modules such as CPUs, GPUs, memory controllers, communication interfaces, and peripherals often run at different clock frequencies or even use completely independent clock sources . When data moves from one clock domain to another, timing uncertainty can cause serious problems such as metastability , data corruption , and unpredictable system behaviour . This challenge is known as Clock Domain Crossing (CDC) . CDC is one of the most important topics in ASIC Design , RTL Design , ASIC Verification , FPGA Design , and SoC Architecture . Every modern chip—from smartphones to automotive processors—uses CDC techniques to ensure reliable communication between multiple clock domains. In this article, we'll explore CDC fundamentals, metastability, synchronization techniques, asynchro...
Post a Comment
Read more

AXI Verification Interview Questions and Real-World Debugging

By
AMBA Protocol Series · Part 10 of 10 AXI Verification Interview Questions and Real-World Debugging Common protocol violations, how to read them off a waveform, and a curated set of interview questions with concise, correct answers — the capstone of the core 10-day series. AMBA Protocol Series: From APB & AHB to AXI — A Complete Guide for VLSI Engineers This wraps up the core 10-day series. Everything here draws directly on Days 1–9 — if any answer below feels unfamiliar, that's a good signal for which earlier post to revisit. (If you want to go further, see the 20-day extended list at the end of this post.) In This Article Common Protocol Violations Debugging From a Waveform Interview Questions and Answers Series Recap Extending the Series 1. Common Protocol Violations VALID deasserted before handshake — a source drops VALID before READY ever went high (violates the Day 8 stabi...
Post a Comment
Read more

Cache Basics and Cache Mapping Techniques

By
  Cache Basics and Cache Mapping Techniques  Modern processors execute billions of instructions every second. However, processor speed has increased much faster than main memory (RAM) speed. This difference, known as the memory wall , creates a performance bottleneck because the CPU often has to wait for data from slower memory. To solve this problem, computer systems use cache memory —a small, high-speed memory located between the CPU and the main memory. In this article, we will understand the fundamentals of cache memory, the principle of locality, cache organization, and the three major cache mapping techniques. What is Cache Memory? Cache memory is a small, high-speed memory that stores copies of frequently accessed data from the main memory. Since accessing cache is much faster than accessing RAM, the CPU first checks whether the required data is available in the cache. If the data is found in the cache, it is called a cache hit . Otherwise, the CPU fetches the dat...
Post a Comment
Read more

Timing Basics in Static Timing Analysis (STA): Delay Models, Sequential Timing, and Wire Delays

By
Timing Basics in Static Timing Analysis (STA) Static Timing Analysis (STA) is one of the most important verification techniques used in modern VLSI design. Before a chip is manufactured, engineers must verify that every signal reaches its destination within the required clock period. Even if a design passes functional simulation, it may still fail after fabrication because of timing violations. Unlike simulation, Static Timing Analysis mathematically analyzes every timing path without applying input test vectors. This makes STA significantly faster and capable of analyzing millions of timing paths efficiently. Table of Contents What is Static Timing Analysis? Why STA is Required Propagation Delay Contamination Delay Cell Delay Models Combinational Gate Delay Sequential Timing Setup Time Hold Time Wire Delay RC Delay Model PVT Corners Worked Examples Interview Questions Key Takeaways What is Static Timing Analysis? Static Ti...
Post a Comment
Read more

Computer Architecture Interview Question Part 1

By
Skip to content Computer Architecture Interview Series Part 1 · CPU Basics · RISC vs CISC · ISA 50 Most Asked Computer Architecture Interview Questions (Part 1) The foundational round every VLSI, ASIC, and CPU design interview opens with: instruction set architecture, RISC vs CISC trade-offs, Von Neumann vs Harvard design, registers, endianness, and the fetch-decode-execute cycle — explained the way interviewers actually expect you to answer.  40 Questions (Q1–Q40) ⌛ 22 min read  VLSI & Computer Architecture Interviews On this page Foundations of Computer Architecture RISC vs CISC — Core Differences Von Neumann, Harvard & the Semantic Gap Architecture Styles, Endianness & Registers ILP, VLIW, Superscalar & Amdahl's Law Register Files, Microcontrollers & the Fetch Cycle Tip...
Post a Comment
Read more