interrupt controller

**Interrupt controller collects interrupt events, prioritizes them and routes them to eligible processor cores or execution contexts.** It lets CPUs respond efficiently to timers, storage, networks, GPUs and peripherals without continuously polling every device. Legacy PICs provide limited lines; x86 APIC families support local and I/O routing; ARM GIC distributes shared/private interrupts with priority and security; MSI/MSI-X encodes interrupts as memory writes. A production specification names the hardware and software boundary, clock and reset domains, address map, data widths, endianness, ordering and coherency, interrupt and error behavior, power states, security domains, performance targets, configuration discovery, lifecycle owner, and verification evidence. Marketing names and nominal link rates are insufficient without exact revision, mode, topology, payload, and environmental conditions. Specify source type, trigger/polarity, ID/vector, priority, target affinity, masking, preemption, security/virtualization, acknowledgment/end-of-interrupt, wake and latency. **Architecture, protocol behavior, and system integration.** Peripheral line or MSI reaches distributor/remapper, pending/active state and priority are tracked, a target CPU interface signals the core, software saves context and runs ISR, clears device cause and signals completion. Controller arbitrates eligible pending events, respects masks and priority, routes by affinity, supports nesting/preemption, and may virtualize interrupts for guests. Drivers must clear source and observe ordering before EOI. PIC, APIC/IOAPIC, GIC, platform interrupt controller, MSI/MSI-X and interrupt remapping differ in scale and platform. A modern embedded system spans processor and accelerator IP, memory hierarchy, on-chip interconnect, peripheral controllers, analog and RF interfaces, clock/reset/power management, boot and firmware, board devices, operating-system discovery and drivers, diagnostics, update infrastructure, and application policy. Data, control, timing, trust, and power paths cross several abstraction levels. Evaluation combines functional correctness with bandwidth and payload efficiency, p50 and tail latency, jitter, outstanding depth, utilization, arbitration fairness, interrupt rate, CPU overhead, memory traffic, error and retry rate, power, thermal behavior, area, firmware footprint, startup time, recovery, interoperability, reliability, security, and total cost. Measurements state workload, clocks, voltages, formats, traffic mix, software, and instrumentation. **Implementation, physical design, and failure modes.** Define clean synchronization, avoid lost edge events, implement priority/affinity, rate moderation, secure groups, virtualization and diagnostics; drivers use short top halves and deferred work. Wire delay, synchronization, distributor fan-in, core count, clock/power domains and message fabric set latency and scalability. Interrupt storm, lost edge, level never cleared, wrong polarity/vector, affinity imbalance, priority inversion, EOI ordering, shared-line ambiguity and wake races cause hangs or CPU saturation. Implementation uses versioned interface specifications, register descriptions, generated headers where appropriate, typed driver APIs, clear ownership, bounded waits, idempotent initialization, capability discovery, defensive parsing, timeouts, error injection, telemetry, and safe fallback. Hardware and firmware agree on reset values, write side effects, ordering, cache maintenance, DMA ownership, interrupt acknowledgment, and power transitions. Physical results depend on standard-cell and memory libraries, analog/RF macros, PHYs, clock trees, voltage islands, level shifters, package pins, signal and power integrity, board routing, external components, thermal limits, process variation and test coverage. A protocol block that passes RTL simulation can still fail timing, CDC, analog compliance, EMI, or system integration. Common failures include reset races, clock-domain crossings, metastability, stale descriptors, dropped interrupts, cache incoherence, address aliasing, ordering violations, bus deadlock, DMA use-after-free, malformed firmware data, incompatible revisions, power-state loss, timeout storms, partial updates, security rollback and observability gaps. A working nominal demo does not establish corner correctness. **Verification, security, and lifecycle controls.** Inject lines/messages, simultaneous priorities, mask/unmask, affinity changes, nested events, power states, virtualization, storms, malformed MSI and latency under load. Event-to-ISR latency/jitter, service rate, CPU overhead, lost/spurious count, priority fairness, wake latency and storm recovery matter. Interrupt remapping limits malicious DMA devices; secure interrupts, hypervisor ownership and debug controls protect privilege boundaries. Verification combines lint, CDC/RDC, assertions, formal properties, protocol VIP, constrained-random simulation, emulation or FPGA prototypes, firmware unit and integration tests, compliance suites, interoperability matrices, performance and power measurement, fault injection, security review, silicon bring-up, characterization, production test, update/rollback drills, and long-duration stress. Requirements, IP and license versions, RTL, register maps, firmware, boot artifacts, device descriptions, drivers, compiler and OS, validation vectors, timing and power signoff, package/board revisions, fuse policy, manufacturing test, errata, field telemetry, update keys, approvals, incidents and deprecation remain linked. Compatibility rules span hardware generations that cannot be patched physically. Owners define root of trust, secure and measured boot, debug authorization, key and fuse handling, signed updates, anti-rollback, least privilege, DMA isolation, memory protection, data classification, radio and safety compliance, vulnerability response, support lifetime, supplier provenance, export/regional obligations, and auditable release authority. | Type | Signal model | Scalability | Key feature | Typical use | |---|---|---|---|---| | PIC | Physical lines | Low | Simple priority/mask | Legacy/small systems | | APIC/IOAPIC | Local plus routed vectors | Multicore x86 | Core-local and I/O routing | PC/server | | ARM GIC | Distributed/private/shared IDs | Many-core ARM | Priority/security/virtualization | Mobile/server/embedded | | MSI | Memory-write message | Moderate | No shared physical line | PCIe devices | | MSI-X | Many independent messages | High | Per-queue vectors/affinity | NVMe/NIC/GPU | ```svg Interrupt controller: collect, prioritize and deliver to a coreDevices raise IRQs as wired lines or MSI writes; the controller masks, ranks by priority and affinity, then delivers.Sources & routingPrioritize & maskDeliver & nestTimerIRQ 30NICMSI 0x21NVMeMSI-XGPIOIRQ 8solid = wired linepurple = MSI memory writeDistributorGIC / APICpending · enable · prioCPU 0CPU 1CPU 2affinity → CPU 1pending AND enable, then rankpending101101enable101011active111ANDPriority arbiter (lower = higher)IRQ2p1winner →IRQ0p3IRQ5p6IRQ2 → running priorityonly if above the core’s current levelCPU priority level over time (lower band = higher prio)time →highlowidleIRQ lowIRQ highEOI hiEOI lonestedHandshake per IRQassert → CPU acknowledges (IACK)read vector → jump to ISRwrite EOI → line deasserts, level dropsWired lines vs MSIOld designs pull a dedicated wire per device;MSI/MSI-X instead posts a memory write,freeing pins and letting one device raise manydistinct vectors.Priority and affinityOnly pending interrupts that are enabledcompete. The controller picks the highestpriority and, via affinity, steers it to achosen core.Nesting and EOIA higher-priority IRQ can preempt a runningISR. Each handler writes End-Of-Interrupt sothe core drops back to the level it came from. ``` **Selection and practical application.** Use GIC for ARM multicore, APIC for x86, MSI-X for scalable PCIe devices and simple controllers for small MCUs. Timers, NVMe, network, USB, GPU, sensors, DMA completion, interprocessor signaling and real-time systems use interrupts. Interrupt behavior spans peripheral status, controller, CPU architecture, OS scheduler, driver, DMA/cache ordering and power management. The useful design boundary is the complete hardware-software system. Optimizing an IP block, bus, driver, codec, radio, controller or firmware stage can move the bottleneck or weaken correctness, timing, power, safety, security, recoverability and manufacturability elsewhere, so qualification is end to end. A production specification names the hardware and software boundary, clock and reset domains, address map, data widths, endianness, ordering and coherency, interrupt and error behavior, power states, security domains, performance targets, configuration discovery, lifecycle owner, and verification evidence. Marketing names and nominal link rates are insufficient without exact revision, mode, topology, payload, and environmental conditions. Evaluation combines functional correctness with bandwidth and payload efficiency, p50 and tail latency, jitter, outstanding depth, utilization, arbitration fairness, interrupt rate, CPU overhead, memory traffic, error and retry rate, power, thermal behavior, area, firmware footprint, startup time, recovery, interoperability, reliability, security, and total cost. Measurements state workload, clocks, voltages, formats, traffic mix, software, and instrumentation. CFS connects this topic to semiconductor architecture, implementation, verification, manufacturing, packaging, test, and deployed AI-system tradeoffs across the platform.

Go deeper with CFSGPT

Get AI-powered deep-dives, save terms, and run advanced simulations — free account.

Create Free Account