Streaming Fabric Interface Protocol Conversion
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional interconnect architectures in computing systems face challenges in scaling to meet increasing bandwidth demands and power efficiency, particularly as data rates rise, due to complexities in receiver decoding, latency, and the need for proprietary interfaces that hinder standardization and interoperability.
Innovation Solution
An improved scalable streaming interface is introduced, which bifurcates header and data packets into independent channels, reduces the number of logical write ports, and standardizes the interface to enable better pin count versus receiver decoding complexity, supporting high-bandwidth and low-latency data transfer across multiple protocols like PCIe and CXL.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If traditional interconnect architectures are used to handle electrical communications, then existing infrastructure can be maintained, but bandwidth demands and power efficiency cannot be met as data rates rise
Solution Approach 1:
The interface is segmented into independent header channel and data channel, allowing separate optimization of control signaling and data transfer paths. This segmentation enables the data channel to operate at high speeds for bandwidth while the header channel manages flow control independently, improving overall power efficiency by avoiding full receiver decoding of high-speed data streams.
2Productivity
If receiver decoding complexity is increased to handle higher data rates, then bandwidth demands can be met, but pin count versus receiver decoding complexity balance is disrupted
Solution Approach 1:
The header information is extracted and transmitted separately on the header channel before the data payload. This allows the receiver to decode and process headers at lower speeds independently of the high-speed data channel, reducing receiver decoding complexity while maintaining high bandwidth capability on the data channel.
Solution Approach 2:
Headers are transmitted and decoded in advance before the corresponding data payloads arrive. This preliminary action allows the receiver to prepare buffer spaces and routing information beforehand, simplifying the decoding of subsequent high-speed data streams and reducing overall receiver complexity.
3Productivity
If proprietary interfaces are used to support multiple protocols, then protocol-specific optimization can be achieved, but standardization and interoperability are hindered
Solution Approach 1:
The streaming fabric interface is designed as a universal protocol-agnostic layer that can carry multiple protocol types (PCIe, CXL, etc.) over the same physical interface. The header channel carries protocol-specific information while the data channel handles payload, allowing a single interface design to support multiple protocols and improve interoperability without sacrificing protocol optimization.
4Device complexity
If the number of logical write ports is reduced to simplify the interface, then standardization improves, but data transfer capability may be limited
Solution Approach 1:
The interface adds a temporal dimension by separating header and data transmission in time and space. Instead of using multiple simultaneous write ports, the system uses a single simplified write port that first receives headers (which contain addressing and control information) and then receives data payloads, achieving high data transfer capability through sequential processing rather than parallel port multiplication.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
An interface for coupling an agent to a fabric supports a load/store interconnect protocol, where the I/O interconnect protocol includes a flit mode and a non-flit mode. A set of flit mode header formats are used when in the flit mode and a set of non-flit mode header formats are used when in the non-flit mode, the set of non-flit mode header formats including one or more non-flit mode fields. Interface logic determines that a link is trained to the non-flit mode and generates a header according to the set of flit mode header formats, where the header includes a field to indicate that a corresponding packet originated as a non-flit mode packet. One or more fields of the set of flit mode header formats are repurposed in the header to carry the one or more non-flit mode fields before sending the modified header over the interface.