Embedding Interrupts in Bus Response Packets
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing bus interface designs require additional dedicated interrupt lines, which can be costly and impractical, especially when device size or I/O pin limitations are a concern, and they struggle to balance interrupt latency, throughput, and processor utilization.
Innovation Solution
A master-slave system configuration that embeds interrupt handling within standard bus operations by 'piggybacking' interrupt information onto response packets, eliminating the need for separate interrupt lines, and using a link-level protocol for periodic polling during idle bus periods.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If additional dedicated interrupt lines are used, then interrupt handling capability is improved, but device size and I/O pin requirements increase
Solution Approach 1:
The patent combines interrupt signaling with existing bidirectional bus operations by embedding interrupt indicators within standard data packets. Instead of using separate interrupt lines, the system merges interrupt information into the same communication channel used for regular data transactions, thereby eliminating the need for additional dedicated interrupt lines and reducing device size requirements
Solution Approach 2:
The existing bidirectional bus is made multi-functional by enabling it to carry both regular data transactions and interrupt signals simultaneously. The bus interface is designed to recognize special packet formats that indicate interrupt conditions, allowing the same physical infrastructure to serve multiple purposes and eliminating the need for separate interrupt dedicated lines
2Reliability
If additional dedicated interrupt lines are used, then interrupt handling capability is improved, but I/O pin requirements increase
Solution Approach 1:
The patent combines interrupt signaling with existing bidirectional bus operations by embedding interrupt indicators within standard data packets. Instead of using separate interrupt lines, the system merges interrupt information into the same communication channel used for regular data transactions, thereby eliminating the need for additional dedicated interrupt lines and reducing device size requirements
Solution Approach 2:
The existing bidirectional bus is made multi-functional by enabling it to carry both regular data transactions and interrupt signals simultaneously. The bus interface is designed to recognize special packet formats that indicate interrupt conditions, allowing the same physical infrastructure to serve multiple purposes and eliminating the need for separate interrupt dedicated lines
3Loss of time
If interrupt information is embedded in response packets, then interrupt latency is reduced, but bus throughput may be affected
Solution Approach 1:
The system employs periodic polling during idle bus periods to check for interrupt conditions. Instead of continuously monitoring dedicated interrupt lines, the master device periodically sends polling requests during naturally occurring idle periods in the bus schedule, thereby detecting interrupts without creating continuous monitoring overhead that would reduce throughput
Solution Approach 2:
The slave device automatically embeds interrupt indicators in its response packets without requiring separate interrupt signaling mechanisms. When the slave detects an interrupt condition, it self-service by setting appropriate bits in the data packets it already transmits during normal operations, eliminating the need for additional interrupt handling infrastructure
4Reliability
If the master device polls for interrupts, then interrupt detection is reliable, but processor utilization decreases
Solution Approach 1:
The system employs periodic polling during idle bus periods to check for interrupt conditions. Instead of continuously monitoring dedicated interrupt lines, the master device periodically sends polling requests during naturally occurring idle periods in the bus schedule, thereby detecting interrupts without creating continuous monitoring overhead that would reduce throughput
Solution Approach 2:
The polling mechanism is made dynamic by adapting its execution to the natural idle periods in bus traffic patterns. Rather than using fixed periodic polling that would consume processor resources continuously, the system dynamically inserts polling operations only when the bus is naturally idle, thereby maintaining reliable interrupt detection while minimizing impact on processor utilization
Data Source
AI summary
A computer system, more generally a master-slave system, may be configured with interrupt handling capability without additional dedicated interrupt lines. An interrupt condition may be bound with its relevant cause information and transmitted by a slave device during a typical response to any operation that a master device may have issued, such as a read or a write. In addition, a link level protocol may be configured in the bus interface of the master device to continually poll specified addresses, or to issue a unique command targeted at interrupts. The master device may be unaware of the unique requests, as the bus may remain idle as seen by the master device. The response to the unique requests may be similar to the interrupt message information transmitted as part of a response to a standard request that may be made by the master device. A master device may thus also receive interrupts without having to configure a slave device with the ability to make requests, or without the master device having to poll for interrupts.