Bridge Logic for PCIe to IOSF Protocol Conversion in SoC Integration
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
As computing systems become more complex, existing interconnect architectures face challenges in balancing high performance with power efficiency, particularly in integrating non-PCIe devices with PCIe root complexes while supporting Single Root Input/Output Virtualization (SRIOV) and accommodating diverse market demands.
Innovation Solution
The implementation of bridge logic that interfaces PCIe transaction layers with on-die interconnect protocols like IOSF, enabling protocol and interface conversion, credit handling, and idle state management to support SRIOV for integrated IP blocks within a System on Chip (SoC) or processor, allowing non-PCIe devices to couple with PCIe root ports via an on-die secondary interconnect.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If non-PCIe devices are integrated with PCIe root complexes to support diverse market demands, then adaptability and device versatility are improved, but device complexity and interconnect architecture complexity increase
Solution Approach 1:
A bridge device is introduced as an intermediary component between PCIe root ports and non-PCIe devices (such as IOSF devices). This bridge performs protocol conversion, translating PCIe transaction layer packets into IOSF protocol format and vice versa. By placing this intermediary layer, the system achieves support for multiple device types without requiring the PCIe root complex itself to become more complex, thus resolving the contradiction between versatility and complexity.
Solution Approach 2:
The system architecture is segmented into distinct functional layers: the PCIe root complex handles PCIe protocol operations, the bridge device handles protocol conversion between PCIe and IOSF, and the integrated devices handle specific device functions. This segmentation allows each component to be optimized independently, enabling diverse device support while maintaining manageable complexity in each segment.
2Adaptability or versatility
If protocol conversion and credit handling are implemented to support SRIOV for integrated IP blocks, then adaptability and virtualization capability are improved, but device complexity increases
Solution Approach 1:
The bridge device is designed with multi-functionality to handle multiple tasks simultaneously: protocol conversion between PCIe and IOSF, credit management for flow control, SRIOV virtualization support, and idle state coordination. By consolidating these diverse functions into a single bridge component rather than distributing them across multiple separate components, the system achieves high virtualization capability while containing overall system complexity.
3Use of energy by moving object
If idle state management and clock domain optimization are implemented, then energy efficiency is improved, but device complexity increases
Solution Approach 1:
The bridge device implements dynamic idle state management that adapts to actual traffic conditions. When no transactions are pending, the bridge transitions to idle states and coordinates clock gating to reduce power consumption. When traffic arrives, the system dynamically activates the appropriate clock domains and exits idle states. This dynamic adaptation enables energy efficiency improvements without requiring permanently complex power management circuitry, as the complexity is only activated when needed.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
In an embodiment, an apparatus comprises: a semiconductor die including but not limited to: at least one core to execute instructions; an agent to perform at least one function; a root complex including a first root port to interface to a first device to be coupled to the apparatus via a first interconnect and a second root port to interface to the agent via a bridge logic; and the bridge logic to interface the second root port to the agent, convert a first transaction from the first root port having a first format to a second format and communicate the first transaction having the second format to the agent. Other embodiments are described and claimed.