Daisy-Chain Priority Interrupts: Detailed Mechanism, Timing, and Design Trade-offs

A daisy-chain priority interrupt is an interrupt arbitration method where several devices are connected in series (“daisy chained”). When interrupts occur, the interrupt-request propagation and the interrupt-acknowledge (or equivalent servicing) flow through the chain so that only the highest-priority pending device (as defined by physical/connection order) is allowed to respond.

This contrasts with schemes that use centralized prioritization tables or fixed hardware vectors per device. Daisy-chaining is often discussed in contexts such as cascaded interrupt controllers (e.g., older designs where controllers are linked to expand interrupt capacity), and also in direct daisy-chaining between devices where the acknowledge mechanism is passed along.

A key idea is that daisy-chain priority is not “dynamic” priority by software alone; it is typically defined by the chain position (or controller cascade relationship) and may be configurable only in limited ways, depending on the specific controller/device.

A typical chain consists of signals analogous to:

• IRQ line: request asserted by a device
• INTA/acknowledge: an acknowledge pulse/handshake to let the requesting device provide the service response
• cascade input/output: internal chain endpoints that connect devices/controllers in order

Important: Exact signal names and cycle-level behavior vary by architecture and controller family, but the arbitration principle (first pending in chain wins, others suppress response) is consistent.

Key terms you’ll use throughout

• interrupt controller: often implements daisy-chain/cascade logic
• pending interrupt: may wait until it becomes highest in chain
• acknowledge handshake: prevents multiple devices from responding simultaneously
• masking: affects which device can actually be serviced

Visualizing the arbitration outcome

Assume a chain order: $D_1$ (highest) → $D_2$ → $D_3$ (lowest). If $D_2$ and $D_3$ are requesting at the same time, the chain logic ensures $D_2$ wins because it appears earlier in the chain.

What “priority” means in a daisy-chain

In daisy-chain priority, “priority” is typically encoded by physical/circuit ordering:

• Devices/interrupt-controller stages earlier in the chain have higher priority
• Later stages are lower priority
• If multiple interrupts are pending, only the earliest pending stage is acknowledged/serviced first

This is effectively a hardware implementation of:

“Select the first pending requester encountered when scanning from head of chain to tail.”

EOI/clearing: why it’s essential

Most interrupt controllers (and many devices in daisy-chain arrangements) require an explicit completion mechanism:

• EOI signals completion
• Without correct clearing, the controller/device may remain in a pending interrupt state
• That can block lower-priority stages indefinitely because the chain continues to see an earlier pending requester

Cascaded controllers vs direct daisy-chaining between devices

You’ll often see daisy-chain priority described in at least two common patterns:

1. Direct device daisy-chaining
   Devices are linked so that acknowledge propagates through them. Priority becomes “first device in chain that is requesting.”

2. Cascaded interrupt controllers
   Multiple interrupt controllers can be linked in a cascade. The “cascade” controller behaves like a stage in a larger chain:

• requests from downstream controllers compete with upstream controller requests
• EOI and acknowledge semantics may be mediated through cascade endpoints

A cascaded controller still implements a chain-order priority selection; it’s just the arbitration logic packaged inside controller chips rather than distributed solely across devices.

Practical design implications

• Pros
  • Simple hardware conceptually: chain + acknowledge propagation
  • Clear deterministic priority: defined by chain topology
• Cons
  • Scalability/latency: long chains can increase worst-case interrupt acknowledge propagation
  • Rigid priority: reordering chain changes priority (unless controller provides programmable priority)
  • Debug complexity: a stuck pending/EOI bug in a higher stage can starve lower stages