Daisy-Chained vs Polling vs Independent Requesting Bus Arbitration: Reliability Under Hardware Failures

In shared buses, bus arbitration resolves contention when multiple masters/devices want to initiate transfers. Three common arbitration patterns are daisy chaining , polling , and independent requesting.

At a high level, arbitration affects (1) who wins arbitration, (2) how fast a request is serviced, and—crucially for this section—(3) what breaks when hardware fails. The key reliability distinction is whether the arbitration network includes serial dependencies (like daisy chaining) versus fan-in to a central arbiter (like polling/independent requesting).

Below, we explain daisy chaining in detail, then compare daisy chaining, polling, and independent requesting specifically for communication reliability under hardware failures, such as stuck-at faults, broken wires, disabled devices, and clock/reset problems.

Note: If your environment contains a specific bus standard (e.g., PCI, VME, proprietary backplane), the exact signal names and fault behaviors may differ, but the reliability principles remain the same.

Core daisy chaining mechanism (priority cascade)

In daisy chaining arbitration, devices are connected in a fixed priority order using request/grant (or enable/pass-through) signals. A typical concept is:

• A device can request bus access (via its request input).
• The arbitration grant (or “enable to arbitrate”) is propagated through the chain.
• When the grant reaches a requesting device, that device claims the bus and may stop further grant propagation (or change the behavior of downstream devices depending on implementation).

This is functionally similar to a priority encoder, but implemented physically with serial wiring rather than logic that samples all requesters in parallel.

Key reliability property

Daisy chaining creates serial dependencies: a fault in an upstream element can prevent the grant/enable signal from reaching downstream devices, even if they are healthy and requesting.

communication reliability depends not only on whether a requester can win, but also on whether the arbitration network can still function to avoid deadlocks and long stalls.

Daisy chaining vs polling vs independent requesting: what happens under failures?

To analyze reliability for each method, we focus on representative fault modes:

• stuck-at request: a device continuously requests.
• stuck-at grant/enable pass: breaks serial propagation.
• open/short in arbitration wiring.
• reset/clock domain mismatch.

Conceptual failure impact

• Daisy chaining: serial propagation means upstream failures can block downstream arbitration.
• Polling: arbiter queries devices sequentially; a failed device can slow the loop or cause the arbiter to misinterpret status, but the arbiter can still continue other devices depending on design.
• Independent requesting: request lines are sampled by a central arbiter; a failed requester can create persistent requests (starvation) or be ignored if protocol supports masking/resetting, but it does not physically block the arbiter’s visibility of other requesters.

Comparison analysis: communication reliability under hardware failures

1) Daisy chaining

Where reliability is strong

• Simple hardware: serial grant/enable reduces wiring/logic complexity.
• Priority is inherent: devices earlier in the chain naturally dominate arbitration.

Where reliability is weak under failures

• Serial dependency hazard: if an upstream device (or its pass-through path) fails in a way that blocks propagation, downstream requesters may never receive an opportunity to claim the bus—hurting communication reliability.
• Stuck-at behavior risk: a device that keeps claiming (e.g., request stuck asserted) can starve downstream devices. Depending on implementation, the chain may repeatedly grant to the stuck device.

Failure scenario examples

• Upstream device hardware open/short breaks the chain → grant/enable cannot reach lower priority devices.
• Upstream device fails to pass enable (stuck-at-block) → downstream never arbitrates.
• A requester becomes stuck asserted → arbitration always selects it when its grant arrives, starving others.

[warning]{type="warning"}: In daisy chaining, “one bad link” is a common systems concern because the arbitration path is effectively a series circuit.

---

2) Polling

Polling uses an arbiter (or bus controller) that queries devices in a known order, often repeatedly, looking for active requests/status.

Where reliability is strong

• Central visibility: the arbiter owns the decision loop, so arbitration path faults are typically localized to a device’s status/response rather than blocking signal propagation through a chain.
• Graceful degradation (if designed): an unresponsive device can be skipped after timeouts or by status checks, allowing other devices to continue arbitration.

Where reliability is weak under failures

• Loop latency / timeout complexity: if a device fails to respond, the arbiter may spend time waiting, increasing latency and reducing throughput.
• Stale status: if status lines are left in a bad state after reset, the arbiter may misread request conditions and either repeatedly service a nonexistent request (starvation) or skip a valid one.

Failure scenario examples

• A device’s “request” flag stuck high → arbiter repeatedly selects it per polling order.
• A device’s response path is broken → arbiter timeouts, potentially delaying others but still progressing.

[tip]{type="tip"}: Polling can be made more reliable by adding explicit timeouts and “fault masking” so a broken device can be excluded without halting arbitration.

---

3) Independent requesting

Independent requesting has each device assert its own request (often via a request line), and a central arbiter resolves conflicts (by priority encoder, rotating priority, or similar logic).

Where reliability is strong

• No serial arbitration path: a wiring fault in one device’s request line does not prevent the arbiter from seeing other requesters (unless the wiring fault affects the arbiter’s sampling infrastructure globally).
• Centralized fault handling: arbiter can mask, ignore, or deprioritize a device after repeated failed attempts or after a reset/disable sequence.

Where reliability is weak under failures

• Stuck request causes starvation: if one device’s request line is stuck asserted, the arbiter may repeatedly choose it. Reliability depends on whether the arbitration protocol includes:
  • bounded service/turn-taking,
  • request clearing rules,
  • detection/masking mechanisms.
• Arbiter saturation: if many request lines are asserted due to faults, the arbiter may spend excessive cycles arbitrating without making progress (depends on implementation).

Failure scenario examples

• Device request line stuck high → arbiter may always grant it; others starve unless the protocol can detect non-progress and mask.
• One request line shorted → that single requester is affected; others remain request-visible.

[warning]{type="warning"}: Independent requesting still needs “stuck request” mitigation—otherwise one faulty requester can monopolize the bus.