Streaming Fabric Interface

Abstract

To provide an interface for coupling an agent to a fabric.SOLUTION: An interface 205 for coupling an agent to a fabric supports a load / store interconnect protocol and includes a header channel implemented on a first subset of a plurality of physical lanes. A Header (HDR) channel embodies a set of signals 505, 515, 520 that are a first set of multiple lanes of the interface for use in sending header data for the packet. The interface additionally includes a data channel implemented on a separate second subset of the plurality of physical lanes. The Data (DATA) channel embodies another set of signals 510, 525, 530 that are mapped to an additional set of multiple lanes of the interface and are for use in sending payload data for the message.SELECTED DRAWING: Figure 5

Description

[Technical field]

[0001] [Related Technology] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 944,207, filed December 5, 2019, the disclosure of which is considered part of the disclosure of this application and is incorporated by reference in its entirety herein.

[0002] This disclosure relates to computing systems, and particularly (but not exclusively) to point-to-point interconnects. [Background technology]

[0003] Advances in semiconductor processing and logic design have allowed for an increase in the amount of logic that can reside on an integrated circuit device. As a natural consequence, computer system configurations have evolved from a single or multiple integrated circuits in a system to multiple cores, multiple hardware threads, and multiple logical processors residing on individual integrated circuits, as well as other interfaces integrated within such processors. A processor or integrated circuit typically has a single physical processor die, which may include any number of cores, hardware threads, logical processors, interfaces, memory controller hubs, etc.

[0004] Smaller computing devices are growing in popularity as a result of their greater ability to fit more processing power in smaller packages. Smartphones, tablets, ultra-thin laptops, and other user equipment are growing exponentially. However, these small devices rely on servers for both data storage and complex processing that exceeds their form factor. As a result, the demand for high performance computing market (i.e., server space) is also increasing. For example, in modern servers, there is typically not only a single processor with multiple cores, but multiple physical processors (also called multi-sockets) to increase computing power. However, as processing power increases with the number of devices in a computing system, communication between the sockets and other devices becomes more important.

[0005] Indeed, interconnects have grown from traditional multi-drop buses that primarily handled telecommunications to full-blown interconnect architectures that facilitate high-speed communications. Unfortunately, as the demands on future processors consume at ever-increasing rates, corresponding demands are placed on the capabilities of existing interconnect architectures. [Brief description of the drawings]

[0006] [Figure 1] FIG. 1 is a simplified block diagram illustrating an example embodiment of a system-on-chip (SoC) device. [Diagram 2] FIG. 2 is a simplified block diagram of a Streaming Fabric interface. [Diagram 3] FIG. 1 is a simplified block diagram of another example streaming fabric interface. [Figure 4] FIG. 1 is a simplified block diagram illustrating an example Compute Express Link (CXL) topology. [Diagram 5] FIG. 2 is a simplified block diagram of a channel of an example Streaming Fabric interface. [Figure 6] FIG. 2 is a simplified block diagram of an exemplary receiver buffer. [Figure 7] 13 is a representation of exemplary fields of metadata for a header channel of a Streaming Fabric interface. [Figure 8] FIG. 2 is a timing diagram illustrating an example data flow on a header channel of an example streaming fabric interface. [Figure 9] FIG. 2 is a timing diagram illustrating an example data flow on a data channel of an example streaming fabric interface. [Figure 10] FIG. 2 illustrates an example initialization state machine for an example flexible on-die fabric interface. [Figure 11] FIG. 1 is a timing diagram illustrating an example flexible on-die fabric interface initialization. [Figure 12] FIG. 1 is a timing diagram illustrating a first example of a disconnect flow in an exemplary flexible on-die fabric interface. [Figure 13] FIG. 11 is a timing diagram illustrating a second example of a disconnect flow in an exemplary flexible on-die fabric interface. [Figure 14A] FIG. 11 is a flow diagram illustrating an example technique of signaling using an example Streaming Fabric interface for load / store protocols. [Figure 14B] FIG. 11 is a flow diagram illustrating an example technique of signaling using an example Streaming Fabric interface for load / store protocols. [Figure 15] 1 illustrates one embodiment of a block diagram of a computing system including a multi-core processor. [Figure 16] 1 illustrates another embodiment of a block diagram of a computing system including a multi-core processor. [Figure 17] 1 illustrates one embodiment of a block diagram of a processor. [Figure 18] 2 illustrates another embodiment of a block diagram of a computing system including a processor. [Figure 19] 1 illustrates one embodiment of blocks of a computing system including multiple processors. [Figure 20] An example of a system implemented as a system on a chip (SoC) is shown. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0007] In the following description, numerous specific details are described, such as examples of specific types of processors and system configurations, specific hardware structures, specific architectural and microarchitectural details, specific register configurations, specific instruction types, specific system components, specific dimensions / heights, specific processor pipeline stages and operations, etc., to provide a thorough understanding of the present disclosure. However, it will be apparent to those skilled in the art that these specific details need not be used to practice the embodiments of the present disclosure. In other examples, well-known components or methods such as specific and alternative processor architectures, specific logic circuits / code for described algorithms, specific firmware code, specific interconnect operations, specific logic configurations, specific manufacturing techniques and materials, specific compiler implementations, specific expressions of algorithms in code, specific power-down and gating techniques / logic, and other specific operational details of computer systems have not been described in detail to avoid unnecessarily obscuring the present disclosure.

[0008] The following embodiments may be described with reference to efficient high-speed data transmission and configurability in a particular integrated circuit, such as a computing platform or microprocessor, although other embodiments are applicable to other types of integrated circuits and logic devices. Similar techniques and teachings of the embodiments described herein may also be applied to other types of circuits or semiconductor devices that may also benefit from better energy efficiency and energy conservation. For example, the disclosed embodiments may be applied to computing systems embodied as servers, blades, desktop computer systems, system-on-chip (SoC) devices, handheld devices, tablets, set-top boxes, in-vehicle computing systems, computer vision systems, gaming systems, machine learning systems, and embedded applications. As will be readily apparent from the following description, the method, apparatus, and system embodiments described herein (whether relating to hardware, firmware, software, or a combination thereof) are beneficial for the development of high-performance computer interconnects and their respective systems.

[0009] As computing systems advance, the components therein are becoming more complex. As a result, the interconnect architectures for coupling and communicating between components are also becoming more complex to ensure that bandwidth requirements for optimal component operation are met. Furthermore, different market segments require different aspects of the interconnect architecture to fit the market needs. For example, servers require higher performance, while the mobile ecosystem can sometimes sacrifice overall performance for power savings. However, providing the best possible performance with maximum power savings is the sole objective of most fabrics. Below, several interconnects are discussed that would potentially benefit from aspects of the solutions described herein.

[0010] As an example, interconnect fabric architectures include the Peripheral Component Interconnect (PCI) Express (PCIe) architecture. The primary purpose of PCIe is to allow components and devices from different vendors to interoperate in an open architecture across multiple market segments, clients (desktop and mobile), servers (standard and enterprise), embedded devices, and communications devices. PCI Express is a high-performance, general-purpose I / O interconnect defined for a wide range of future computing and communications platforms. Several PCI attributes, such as the usage model, load-store architecture, and software interface, have been maintained through its revisions, but the previous parallel bus implementation has been replaced with a highly scalable fully serial interface. More recent versions of PCI Express take advantage of advances in point-to-point interconnects, switch-based technology, and packetized protocols to provide new levels of performance and functionality. Power management, quality of service (QoS), hot-plug / hot-swap support, data integrity, and error handling are some of the advanced features supported by PCI Express.

[0011] Traditional streaming interfaces for coupling fabrics to protocol agents generally include proprietary interfaces (e.g., Intel™ On-Chip System Fabric (IOSF™)), interfaces developed for coherent or out-of-order protocols, and other interfaces that are poorly adapted to scale to handle evolving data rates in modern protocols and architectures. For example, proprietary interfaces have custom or use-case specific information or functionality that may prevent standardization of the interface or may not scale to next generation bandwidths. Other traditional interfaces may be defined in a more general manner, for example, as a data bus for carrying packets. However, traditional bus definitions and interfaces may introduce receiver decode complexities, especially as data rates increase, allowing more packets to be processed per clock cycle, especially when multiple flow control classes or virtual channels exist. As an example, if four (or more) packets of any channel or flow control may arrive on a given clock cycle and these are accessing a shared buffer, a corresponding four (or more) logical write ports would need to be provided at the receiver, resulting in excessive surface area dedicated to providing such logic (and buffers). In some instances, conventional interfaces handle use cases with multiple packets per cycle (of different flow control classes) by simply stamping multiple copies of the interface (e.g., one for each flow control class), resulting in high pin counts. Additionally, conventional streaming interfaces have headers and data packets that follow each other on the same physical wire, limiting the potential for latency optimization. Some conventional interfaces fail to provide an effective and flexible mechanism for crediting flows, among other example shortcomings.

[0012] In some implementations, an improved scalable streaming interface may be defined between agent logic on a device and the fabric, such as between a protocol layer and other devices coupled to the fabric (e.g., CPUs, endpoint devices, switches, etc.). The streaming interface may support load / store protocols such as PCIe, Compute Express Link (CXL) (e.g., CXL.io), among other load / store protocols. The improved streaming interface may define interface rules and interface channels to enable chip area and latency benefits during implementation while providing power-efficient bandwidth scaling benefits that become more important as protocols approach higher speeds, such as moving to 32.0GT / s in PCIe Gen5, or even 64.0GT / s, and beyond starting with PCIe Gen6 and CXL3.0, among other examples. Such an interface may optimize the best balance of pin count versus receiver decode complexity. In some implementations, the improved streaming interface discussed herein may allow for a modest number of logical write ports on a receiver buffer where the receiver buffer is shared among multiple virtual channels and flow control classes. Additionally, the improved streaming interface bifurcates the header and data of a packet into independent physical channels (e.g., a header channel and a data channel), thereby allowing the receiver to begin processing the header while the data is still streaming, thereby helping to reduce overall latency and buffer sizing and complexity. Additionally, the improved streaming interface discussed herein may be standardized to allow the ecosystem of IP blocks to adopt and develop scalable, standardized interfaces rather than traditional proprietary interfaces, allowing for more interoperability options, among other example features and advantages as discussed herein.

[0013] Referring to the simplified block diagram 100 of FIG. 1, a simplified example of a system-on-chip (SoC) device 105 is shown. The SoC map is implemented as an integrated circuit incorporating multiple components of a computer, or computing blocks (or intellectual property (IP) blocks). Such blocks (e.g., 110, 115, 120, 125, 130, 135, 140, 145) may include components such as one or more CPU components 110, 115, 120, 125 (e.g., microprocessors or microcontrollers), special purpose processors 130, 135 (e.g., graphics processing units (GPUs), image signal processors (ISPs), tensor processing units, accelerator devices, etc.), memory components, input / output (I / O) ports, secondary storage blocks, and other computational blocks on a single die or substrate, such as a silicon die.

[0014] The computational blocks (e.g., 110, 115, 120, 125, 130, 135, 140, 145) of the exemplary SoC 105 may be interconnected by a SoC fabric (e.g., 150). The fabric 150 may itself be implemented using a set of one or more IP blocks that facilitate communication between the computational blocks (e.g., 110, 115, 120, 125, 130, 135, 140, 145). In some implementations, the fabric 150 may be implemented as a network-on-chip (NOC), such as one or more circuit blocks implemented in the NOC.

[0015] Communications by the various blocks (e.g., 110, 115, 120, 125, 130, 135, 140, 145) may be facilitated via protocol agents (e.g., 160a-h) provided on the blocks (e.g., 110, 115, 120, 125, 130, 135, 140, 145). Each agent (e.g., 160a-h) may include logic (e.g., implemented in hardware circuits, firmware, and / or software) for implementing all or a subset of layers of one or more interconnect protocols (e.g., PCIe, Compute Express Link (CXL), Gen-Z, OpenCAPI, In-Die Interface, Cache Coherent Interconnect for Accelerators (CCIX), Ultra Path Interconnect (UPI), etc.) through which the corresponding compute block communicates with other compute blocks in the system. As described herein, the agents may couple to the fabric 150 via their respective interfaces. While such agents are traditionally coupled to the fabric via proprietary wire interfaces, one or more agents (e.g., 160a-h) may utilize respective instances of a configurable flexible on-die wire interface, which may be deployed to support multiple different protocols of multiple different agents of the SoC 105. In other examples, interfaces between the agents (e.g., 160a-h) may be adapted to support non-coherent and / or load / store streaming protocols, and corresponding streaming fabric interfaces may be defined and implemented on the blocks (e.g., 110, 115, 120, 125, 130, 135, 140, 145) and fabric 150, among other examples.

[0016] As described above, an improved Streaming Fabric Interface Architecture (SFI) may be provided within components of the system (e.g., IP blocks and components implementing the system's fabric) to map load / store protocols (e.g., PCIe, CXL.io) between agents and the fabric. The SFI interface may provide a scalable streaming interface capable of sustaining the high bandwidth demands of load / store protocols, including emerging next generation rates for such protocols. The SFI interface may facilitate implementation on both the sender and receiver sides when transmitting such high data rates. In addition, logic implementing the SFI interface may embody, realize, and enforce rules for communication on the interface (e.g., beyond those defined in the protocol supported by the interface) to significantly simplify storage overhead in the context of read / write ports on the receiver, among other exemplary advantages.

[0017] The SFI interface may be used both in the context of a host CPU (e.g., through a root complex) or in the context of a device endpoint. In either case, the SFI serves to carry protocol layer (transaction layer) specific information between different processing entities. As an example, on the device side, the SFI may be used to interface between a PCIe controller and an application layer (e.g., a fabric or gasket layer between the controller and the fabric). Similarly, on the host side, the SFI may be used to interface between a PCIe root port and a CPU fabric. Configurable parameters are defined in the SFI interface, and may allow an instance of the interface to be parameterized broadly enough to carry multiple packets in a single transfer according to the supported protocol and system use case(s). On a given SFI interface, data transfers may be unidirectional. Thus, in some implementations, a pair of SFI interface instances (one in each direction) may be provided to facilitate implementations that utilize bidirectional data transfers between communication blocks. Thus, many examples herein discuss a transmitter (TX) and receiver (RX) pair for a single instance of an SFI interface.

[0018] Different configurations can be enabled using the SFI as an intermediate interface. For example, the SFI interface may not make assumptions about protocol or application-specific responsibilities of the interface's transmitter and receiver. Rather, the SFI interface may simply provide mechanisms and rules for high-bandwidth packet transfer. For example, FIG. 2 is a simplified block diagram 200 illustrating an example implementation coupling a controller 210 (e.g., of an agent) to an application layer 215 (e.g., implemented via a fabric) via two SFI interface instances 205a, 205b. The controller 210 may include protocol circuitry or other logic to establish a link 220 according to a particular interconnection protocol (e.g., PCIe) and participate in initialization, training, and communication over the link 220. The example of FIG. 2 may illustrate the use of the SFI in a PCIe application. The SFI instance 205a may treat the PCIe controller 210 as a transmitter and the application layer element 215 as a receiver. Thus, application layer elements 215 may include receive buffers for SFI interface 205a for use in maintaining flow control credits (including shared credits for the channels of SFI interface 205a). Similarly, SFI interface 205b may view application layer elements 215 as a transmitter and PCIe controller 210 as a receiver (controller 210 may include corresponding receiver queues or buffers 225 for use with interface 205b).

[0019] Some implementations of the SFI may utilize the semantics and header formats of PCIe-based protocols, but the SFI is not limited to the PCIe-based protocols that are supported. Furthermore, the SFI does not include new protocol definitions. The SFI semantics can be used to support a variety of different protocols, provided that the protocols can be mapped or adapted to the flow control (FC) and virtual channel (VC) semantics that the SFI provides, among other example features. For example, the SFI supports advertisement of zero or more shared credit pools for receive queues (described in more detail below).

[0020] Referring to FIG. 3, a simplified block diagram 300 is shown illustrating a root composite stack utilizing a conventional SFI interface. For example, the SFI interfaces 205a, 205b may be used to couple the protocol stack logic (e.g., 305, 310) to a non-coherent to coherent protocol converter 315 (e.g., may be located between the protocol stack logic and the system's interconnect fabric 215). For example, the protocol stack logic may be embodied as an agent or controller for a particular non-coherent load / store interconnect protocol (e.g., PCIe, CXL.io, etc.) and may include lower layer logic 305 (e.g., implemented in a circuit) including physical layer logic and link layer logic. Also, transaction layer logic 310 may be provided and may be a layer that interfaces with the converter 315 via the SFI interfaces (e.g., 205a, 205b). Buffers 225 (e.g., I / O / Queue (I / OQ) buffers) may be provided and used to hide physical link latency between the device and the host. The depth of such buffers 225 is typically shallow, and the number of logical write ports required is the number of simultaneous packets available from the link in one clock cycle. For example, in one example, at PCIe Gen5 speeds (32GT / s), up to four packets can arrive in one 1 GHz cycle, so four logical ports are required in such an example to handle these packets simultaneously, given that the packets may be of different flow control classes and / or virtual channels. On the other hand, fabric-side buffers 230 (e.g., ProcQ buffers) may be implemented as deep buffers used to hide CPU fabric latencies (e.g., for inbound writes, translating the latency of getting ownership requests and committing data to the coherence domain). These may use one or multiple write ports. In a split-queue implementation, SFI semantics may enable further optimizations (e.g., performing "batching" of transactions on the ProcQ side).Indeed, the SFI semantics are directed to improving buffer implementations in various system configurations, among other example advantages, providing a balance between receiver complexity and bandwidth scaling capabilities.

[0021] Among the illustrative features employed in the examples, the improved SFI interface, receiver decoding may be simplified with interface scaling to support a wide range of data payloads (e.g., from as little as 4B to as much as 4KB (or more)). The improved streaming interface allows multiple packets to be delivered in the same cycle, allowing for a scalable interface across a variety of payload sizes while maintaining a common set of semantics and ordering (e.g., PCIe-based, etc.). Configurable parameters may include the number of logical write ports at the receiver (e.g., 1 or 2), which may be supported by defining rules for the interface that limit the number of different packets or headers transmitted in a clock cycle to use a corresponding number of flow control classes and / or virtual channels. Reducing the number of logical write ports at the receiver may save significant area and complexity. In addition, as discussed above, the improved streaming interface may allow header processing (e.g., processing of headers received via a dedicated header channel) to begin at the receiver so that data can begin while streaming to improve latency (e.g., in the case of a CPU host, to help overlap the latency of the incoming data stream and ownership requests).

[0022] Compute Express Link (CXL) is a low-latency, high-bandwidth discrete or on-package link that supports dynamic protocol multiplexing (or muxing) of coherence protocols (CXL.cache), memory access protocols (CXL.mem), and I / O protocols (CXL.io). CXL.cache is an agent coherent protocol that supports device caching of host memory, CXL.mem is a memory access protocol that supports device-attached memory, and CXL.io is a PCIe-based non-coherent I / O protocol that enhances accelerator support. CXL thereby intends to provide a rich set of protocols to support a wide range of devices, such as accelerator devices. Depending on the particular accelerator usage model, all CXL protocols (CXL.io, CXL.mem, CXL.cache) or only a subset may be available to provide a low-latency, high-bandwidth path for the corresponding compute block or device (e.g., accelerator) to access the system.

[0023] As mentioned above, in some implementations, an agent utilized to implement the CXL.io protocol may couple to a system fabric utilizing an SFI interface, as described herein. For example, referring to FIG. 4, a simplified block diagram 400 is shown illustrating an example CXL agent and its coupling to a fabric. FIG. 4 illustrates an example system topology for a port supporting a CXL link 415. For example, the CXL link 415 may couple a CPU host device 405 to another device 410 (e.g., a memory device or an accelerator device). Each agent (on devices 405, 410) may include link layer logic (e.g., 420a-b, 425a-b) to support each of the CXL sub-protocols (e.g., CXL.io, CXL.mem, CXL.cache). For CXL.mem and CXL.cache, a common controller (e.g., 425a-b) may be used. For CXL.io, separate controllers 420a-b may be provided for the coherent CXL.mem and CXL.cache protocols. Protocol multiplexing may be facilitated via CXL arbitration / multiplexing logic (e.g., 425a-b implemented in hardware circuitry) that interfaces with a Flex Bus™ physical layer (e.g., 430a-b). The Flex Bus may be implemented as a flexible high-speed port that is statically configured to support either PCIe or CXL. The Flex Bus allows either PCIe or CXL protocols to be transmitted over a high-bandwidth off-package link. Protocol selection in the Flex Bus PHYs 430a-b may be done at boot time via auto-negotiation based on the application.

[0024] Continuing with the example of FIG. 4, the first interface type 450a, 450b is used for coherent protocols such as CXL.cache and CXL.mem, while other different wire interface definitions (e.g., 205′, 205″) (e.g., SFI interfaces) are used for load / store protocols such as PCIe and CXL.io. In one example, the SFI 205′, 205″ serves as an intermediate interface that makes no assumptions regarding the protocol or application specific responsibilities between the transmitter and receiver and provides a scalable streaming interface that can sustain the high bandwidth requirements of load / store protocols (e.g., PCIe, CXL.io, etc.). The SFI does not include a standalone protocol definition, SFI semantics provided to support different protocols that can be mapped to flow control, virtual channel semantics provided by the SFI definition, among other examples and interface implementations.

[0025] As shown in Figure 4, the system may use exemplary interfaces 450a, 450b to achieve wire efficiency around the fabric and agents by allowing wires to be shared in the fabric and allowing different coherent protocols to share common wires. For example, the channels of the various protocols emanating from the agents may be carefully mapped to a minimal set of physical and virtual channels so that the bandwidth and channel separation requirements of the agents and protocols are met with a minimum number of total wires. The interfaces 450a, 450b may, among other exemplary implementations, bring these multiple protocols onto a common set of channels and use common flow control and virtualization functions on these channels.

[0026] In some implementations, a streaming interface modified to support load / store protocols based at least in part on PCIe or PCIe semantics (e.g., PCIe or CXL.io) may be implemented. For example, the supported protocols may utilize packet formats based on PCIe-defined formats. Additionally, flow control / virtual channel concepts may be extended from the PCIe definition. It should be understood that other additional protocols (e.g., non-PCIe or CXL protocols) may also be supported by such an SFI interface. Indeed, while many of the examples discussed herein refer to PCIe- or CXL.io-based protocols and implementations, it should be understood that the principles, features, and solutions discussed herein may be applied more generally to, for example, various other streaming or load / store protocols, among other example systems.

[0027] In some implementations, the SFI interface may have separate header (HDR) and data buses or channels, each capable of carrying multiple packet headers or payloads simultaneously. Additionally, formal rules may be established and adopted in the agent's logic to govern how packets are packed / unpacked on the header and data interfaces. For example, an additional metadata channel or bus may be provided on the modified interface to carry metadata to allow the receiver to identify how to unpack the header / data sent on the separate header and payload data channels, respectively. Through separate parallel header and data channels, the system (e.g., the CPU host root complex) may enjoy latency benefits, for example, by potentially receiving multiple headers before the corresponding payloads are received. The resulting lead time may be used by the system to begin processing headers and taking ownership of cache lines for multiple header requests while the data for the multiple header requests is still being streamed. This helps with latency overlap and reduces buffer residency, among other example benefits.

[0028] Referring to FIG. 5, a simplified block diagram 500 is shown illustrating an example implementation of an SFI interface. For example, in each instance of an SFI interface, a set of physical lanes (e.g., wires or other conductors) may be provided and assigned to various channels that embody a logical set of signals defined for the interface and assigned to each physical lane of the interface. Each device may have pins and corresponding SFI logic (implemented in hardware circuitry and / or software) that may be coupled to the physical lanes that implement its end (transmitter or receiver) or instance of the interface and embody the connections between the transmitter and receiver on the interface. The SFI interface instance may further define two channels for the transmission of packets or other data transfer messages from the transmitter to the receiver. Specifically, in some implementations, the SFI interface 205 may include a header (HDR) channel that embodies a set of signals (e.g., 505, 515, 520), each of which is a first set of signals of the interface's multiple lanes for use in transmitting header data of packets. The SFI interface further includes a data (DATA) channel that embodies another set of signals (e.g., 510, 525, 530) that are mapped to an additional set of lanes of the interface 205 and are used in transmitting payload data of messages. The signals of the HDR channel may include a main HDR signal 505 for carrying the header itself, a header metadata signal 515, and a header credit return signal 520 (directed from the receiver to the transmitter). Similarly, the DATA channel may include a main DATA signal 510 for carrying the payload data, a data metadata signal 525, and a data credit return signal 530 (also directed from the receiver to the transmitter), among other example signals. In some implementations, the SFI interface 205 may additionally include a global channel or layer (e.g., 550) that includes bidirectional control signals that apply across all physical channels (e.g., HDR and DATA) of the interface.For example, the global channel may carry a set of global control signals that may be used to perform initialization or shutdown of the interface and to communicate control or parameters for the interface, among other features.

[0029] The HDR and DATA channels can carry multiple packets in the same transfer cycle. Because most load / store protocols rely on ordering semantics, the SFI assumes an implicit ordering when multiple packets are sent in the same cycle. Packets may be ordered, for example, from the least significant position to the most significant position. For example, if TLP 0 starts at byte 0 of the header signal 505 and TLP 1 starts at byte 16 of the header signal 505, the receiver will consider TLP 1 to be ordered after TLP 0 when such ordering rules are applied. For transfers across different clock cycles, the ordering rules of the associated protocol are followed (e.g., when used for PCIe, the SFI inherits all PCIe ordering rules). In case of link subdivision (e.g., splitting an entire lane of a link into two or more narrower width links (e.g., associated with respective root ports)), different ports from the controller's perspective are mapped to different virtual channels on the SFI. For example, in such cases, an implementation may support multiple port configurations within the same physical block (e.g., implemented as an agent or controller). In these cases, the same physical channel of the SFI may be used to forward packets for different ports, with each port being mapped to its own set of virtual channels (e.g., one or more virtual channels per port), among other example implementations.

[0030] A set of parameters may be defined for an instance of an SFI interface to configure aspects of the instance. For example, metadata signals for HDR and DATA channels may be based on one or more of the configurable parameters. For example, the parameters may identify how the metadata signals carry metadata to carry information about the location of different packets within a single transfer, among other example information. For example, in SFI, a packet header with data associated with it is transmitted on the HDR channel and the associated data is transmitted separately on the DATA channel. The timing relationship between the DATA and HDR channel transfers may not be guaranteed. The receiver is assumed to track the associated data length for each received header and process only the associated data size. The data size may be transmitted along with the packet header information (e.g., a PCIe implementation using the PCIe packet header format identifies the amount of data in the length field of the PCIe TLP header to indicate how many 4-byte chunks of data are associated with that header). Information in the metadata transmitted via the metadata signal can be used by the receiver to determine which headers map to which data (e.g., via a combination of flow control and virtual channel ID), parity information, information regarding the header format (e.g., header size), among other example information.

[0031] A global layer or channel of signals (e.g., 550) may carry signals that apply across all physical channels of interface 205, such as control signals, vendor-defined signals, and other signals that enable other example functionality. For example, global channel 550 may carry signals that are also used to initialize and shut down the interface (e.g., in the examples described below). Table 1 shows an example implementation of the signals of the global channel of an example SFI interface.

[0032] [Table 1]

[0033] The HDR channel carries the header of a request message from a sender to a receiver. Various information may be encapsulated in the (protocol-specific) fields of the header transmitted using the HDR channel, including addresses and other protocol-level command information. Table 2 shows an example implementation of the signals of the HDR channel of an example SFI interface.

[0034] [Table 2]

[0035] The header size may be a predefined parameter based on the system's expected or required peak sustained bandwidth. The SFI interface (and corresponding logic) may enforce the rules of the HDR channel, such as starting and ending a packet header in the same transfer cycle. Nevertheless, multiple packet headers may be sent in the same cycle by sending one of the packet headers on a first subset of the header signal lanes and the other packet headers on another subset of the header signal lanes. However, the interface may define that the first packet on a valid header transfer starts on the lane of the header signal corresponding to byte 0 of the header field (logically represented by the header signal lanes).

[0036] A header valid signal (hdr_valid) may be asserted to indicate a corresponding valid value on a lane of the header signal. In some implementations, the number of lanes of the header signal may be logically divided into byte-wise subsets (e.g., 16 or 32 bytes of lane width in each subset) corresponding to the size of one of the protocol headers carried on the header signal. Furthermore, each header valid lane may be mapped to one of the subsets to indicate that valid header data is being transmitted on a corresponding one of the subsets of lanes of the header signal. Additionally, a header metadata signal (hdr_info_bytes) may carry metadata (e.g., aligned with one of the headers carried on the header signal) to describe key attributes that may be used by a receiver to decode the corresponding header.

[0037] The DATA physical channel of the SFI interface may be used to carry payload data for all requests that have data associated with it. In an SFI, there may be no explicit timing relationship or requirement between the HDR channel and the associated data carried on the DATA channel. However, the transmitter may include logic to check both the HDR and DATA channel credits before scheduling either the header data on the HDR channel or the payload data on the DATA channel. Table 3 shows an example implementation of the signals of the DATA channel of an example SFI interface.

[0038] [Table 3]

[0039] In an implementation of the SFI interface, payload data may be transmitted on the data signals of the DATA channel according to a multi-byte granularity (e.g., 4-byte granularity). Thus, any payload data may be identified as ending at a particular "chunk" of data (e.g., a particular 4-byte chunk). As an example, if the width of the data signal D is 64 bytes, then the number of possible data termination locations is DE=64 / 4=16, where data_end[0] corresponds to data_bytes[3:0], data_end[1] corresponds to data_bytes[7:4], data_end[DE-1] corresponds to data_bytes[D-1:D-4], etc. The start of the data signal (data_start) may utilize the same or different granularity as the end of the data signal. An instance of the SFI interface may be parameterized to support a maximum number of starts DS in a clock cycle (and limit the number of payload starts accordingly). As an example, if the width of the data signal bus D is 64 bytes, and an instance of the SFI interface is configured to limit the number of starts in one cycle to 2, DS=2, then the data bus is effectively split into two 32-byte chunks in which new payloads may be transmitted. For example, when D=62 and DS=2, among other examples (including lower or higher granularity in the start of data and the end of data chunks (e.g., DS>2), smaller or larger data bus sizes, etc.), data_start[0] corresponds to the chunk of data starting at data byte[0], and data_start[1] corresponds to the chunk of data starting at data byte

[32] .

[0040] In one exemplary implementation of the DATA channel of the SFI interface, the width of the data start signal may be equal to DS, and the signal may effectively act as a mask to identify each chunk of corresponding data on the data signal that corresponds to the start of each payload (e.g., aligned within the same clock cycle). Additionally, each data start bit may have a data_info_byte signal transmitted with it indicating metadata for the corresponding payload. In some implementations, the data_info_byte is transmitted only once for a given payload (e.g., along with the corresponding data start chunk and data_start_bit), while in other examples, the metadata may be transmitted (e.g., repeated) to correspond to all chunks of data within the same payload, among other example implementations. In one implementation, the data_info_byte signal may indicate the FC ID and VC ID of each of the corresponding packets carrying an FC ID (e.g., with 4 bits of data_info_byte[3:0]) and the other 4 bits carrying a VC ID (e.g., data_info_byte[7:4]), among other example information for use by the receiver in processing data payloads transmitted over the data signal bus.

[0041] Unlike HDR channels, in some implementations of the DATA channel, data chunks from the same packet can be transferred over multiple cycles. For example, the raw data bus width can be implemented as 64B per cycle, allowing a 128B data packet to be transferred over two clock cycles. In some implementations, once a payload begins transmission, the transmitter can ensure that all relevant data chunks in the payload are transferred consecutively from LSB to MSB and over consecutive clocks (e.g., without gaps or bubbles). In some implementations, only one packet of a particular FC ID / VC ID combination can be transmitted on the interface at a time (an FC ID / VC ID combination is reused only after the previous packet using the combination has finished transmitting). In some implementations, packets with different FC ID / VC ID combinations can be interleaved on the SFI interface (e.g., a packet of one FC ID / VC ID combination is interrupted to transmit at least a portion of a packet with another FC ID / VC ID combination), among other examples.

[0042] The granularity of credits on the data channel may also be configurable (e.g., at design compile time) and may correspond to a multiple of N bytes. For example, in one example, the granularity may be required to be a multiple of 4 bytes. If the credit granularity is selected to be 16 bytes, even a transferred 4-byte data packet uses one 16-byte worth of credit in an exemplary implementation.

[0043] FIG. 6 is a simplified block diagram 600 illustrating an example implementation of a receive buffer for use with an example SFI interface. In one example, the receive buffer may be implemented as a linked list with a single write port and shared between two virtual channels (e.g., VC0 and VC1) of one flow control class (FC0). In this example, four headers per cycle may be received on the corresponding SFI interface. The linked list is managed in blocks (e.g., 630a-c) of four header positions at a time. Although the linked list may appear to be in logically contiguous memory, the physical blocks may be implemented to be non-contiguous or even in separate storage elements. In one example, all positions in a given block (e.g., 630a) will be filled before moving to the next block (e.g., 630b). The buffer is allocated by the receiver one block at a time, and thus the corresponding shared credits may also be at block granularity. In an implementation, if the set of four headers (e.g., 605a-d) in a block (e.g., 630a) are actually made of separate storage structures, each of these storage columns may well be implemented with only a single write port. For example, each of the columns shown in the linked list buffer of FIG. 6 may be physically implemented as a separate buffer / storage element with its own single write port. Furthermore, since the next block pointer only needs to be retrieved once among the four headers (in the example of FIG. 6), timing relief and pipelining possibilities may be unlocked by using a "block" management of the linked list pointers (e.g., 615, 620, 625). In some streaming protocols, the receiver may be designed with and equipped with multiple write ports since in the general case, it is not possible to assume only one FC / VC combination per cycle (e.g., because tails of different FC / VCs may collide in the same storage column).

[0044] As mentioned above, the SFI interface (and the corresponding logic and buffers / trackers utilized to implement that half of the interface by the transmitter and / or receiver) may enable the pipelining of header processing while data is streaming. In fact, the latency savings realized through it translates directly from a header processing perspective into preserved buffers in the receiver. In the context of a load / store protocol, the headers are heavily consumed by the control path, while most of the data is sequestered to the data path, so it is assumed that the receiver will internally separate the headers and data anyway. By splitting the header and data channels on the exemplary SFI interface, the headers of subsequent requests may even bypass the data of previous requests, which may enable the receiver to start processing the headers while the data transfer is completing. In the context of a host CPU processing inbound (device-to-host) writes, this may translate to a head start in gaining ownership of the associated cache line, among other exemplary use cases and benefits. In fact, fetching ownership is one of the most important drivers of latency when a process writes, so overlapping it while data streams helps reduce overall latency and buffering in the CPU. Deadlock is avoided by making sure that the sender checks both header and data credits before sending either the header or the data.

[0045] In some implementations, each VC and FC defined for the SFI interface uses credits to send messages and collects credits back from the receiver. The source may consume all credits required for a message to complete. The transmitter checks the credits for both the HDR and DATA channels before sending the corresponding message on the respective channel to the receiver. The granularity of the credits for the HDR and DATA channels is pre-determined between the TX and RX. For example, the granularity of the credits on the data channel may be set (e.g., at design compile time) to be only multiples of N bytes. For example, in one example, the granularity may be required to be multiples of 4 bytes. If the credit unit is selected to be 16 bytes, even a 4-byte data packet transferred uses one 16-byte worth of credits, among other example implementations. In one example, the FC ID may be based on PCIe semantics (e.g., 4'h0=posted, 4'h1=not posted, 4'h2=completed), among other example implementations. Additionally, each of the physical channels (e.g., DATA and HDR) may be equipped with a dedicated credit return wire (unlike the remaining channels, which flow from the receiver to the transmitter). For example, during operation, the receiver returns credits whenever it processes a message (or guarantees a buffer position for the next transaction).

[0046] In some implementations, the SFI allows two schemes to support buffer sharing between different FC and VC IDs. In both schemes, the receiver advertises the minimum number of dedicated resources required for a forward progress guarantee. For large packet transfers, this means that the maximum payload size is based on the dedicated credit advertisement. If shared credits are used, the sender and receiver decide in advance which credit type or scheme should be used. This decision may be made at design time in some implementations. In other implementations, the credit scheme may be dynamically determined (e.g., based on parameters written to corresponding configuration registers), among other examples.

[0047] The first of the two schemes for credit sharing can be transmitter management. In this scheme, the transmitter is responsible for managing the shared buffer in the receiver. One or more shared credit pools are advertised or consumed with spare VC ID / FC ID encoding. When the transmitter consumes a shared credit pool credit, it transmits the packet using the corresponding VC ID / FC ID encoding. When the receiver deallocates a transaction that used the shared credit, it performs a credit return for the corresponding VC / FC ID combination. In some implementations, a bit may be provided in the header (along with a corresponding signal on the HDR channel) to indicate whether the credit is a shared credit or not. Thus, the receiver may have to further decode the header packet to explicitly determine the actual VC ID or FC ID of the packet, among other examples.

[0048] In one example implementation of transmitter-managed credit sharing, an example shared credit pool mapping advertised by a receiver (e.g., in a PCIe-based implementation) may support two VCs on a link and employ the following example mapping shown in Table 4:

[0049] [Table 4]

[0050] The other of the two credit sharing schemes may be receiver managed. In the receiver managed scheme, the receiver is responsible for managing the shared buffer. Only dedicated credits are advertised to the sender. Typically, the advertised dedicated credits cover the point-to-point credit loop across the SFI, and the shared credits are used to cover larger credit loops (e.g., CPU fabric or application layer latency). After a particular FC / VC ID transaction is received and shared credits become available, credits can be returned for that FC / VC ID combination (e.g., without waiting for the transaction to be released from the receiver queue). This implicitly gives a shared buffer spot for that FC / VC ID. Internally, the receiver tracks credits returned to the sender on an FC / VC basis and further tracks credits currently consumed by the sender. This tracking allows the receiver to guarantee the maximum number of buffers used per FC / VC. The receiver may guarantee the dedicated resources required for forward progress guarantees, among other example implementations.

[0051] Error handling in case of illegal flow control can result in undefined behavior. Thus, the SFI interface logic on the agent and fabric can check for illegal cases to trigger assertions in the RTL and also log / signal fatal errors to enable post-silicon debugging. For example, the SFI can maintain consistency between the HDR and DATA streams, meaning that the transmitter sends data payloads in the same order as it sends the corresponding headers and vice versa. In some implementations, the receiver logic can include functionality to detect and flag non-compliant fatal errors, among other error handling capabilities. In some implementations, the SFI provides for data corruption to be sent at the end of the data transfer. In case of occasional errors, the ownership request can be discarded / written back without modification, or the host can choose to pollute the associated cache line and write the updated data, among other examples.

[0052] Referring to FIG. 7, a representation of an example metadata format 700 is shown, which may be carried on a lane of a header metadata signal. The least significant byte and least significant bit are shown on the right. P (705) is the parity bit of the corresponding header. In some implementations, support for parity bits may be optional (e.g., the parity bit 705 is treated as an additional reserved bit). If supported, parity may be supported, for example, by XOR-ing at least all of the bits of the packet header. In some implementations, both the bits of the associated metadata 700 and the non-parity bits may be XOR-ed to determine parity, among other examples. Bit D (710) indicates whether the header has corresponding payload data associated with it. All reserved bits (e.g., 715) may be ignored by the receiver or may be required to be driven to 0 by the transmitter. In some implementations, the witch / fabric router may be required to propagate the reserved bits 715 as is without any modification. In some implementations, the reserved bits 715 may be used for vendor-defined encoding or future information, among other examples. The header size (HDR size) 725 in the example metadata 700 may specify the size of the header (e.g., in 4-byte units). When calculating the header size, the length of the header metadata (700) may be ignored (and is not considered part of the header).

[0053] In an SFI interface implementation, the maximum number of packet headers that can be transmitted in one cycle on the interface may be predetermined (e.g., recorded in a configurable parameter of the interface). The maximum packet headers per cycle may be determined by the width (or number of lanes) of the header signal (H) and the maximum packet header size. The SFI interface may be implemented (and designed) such that the header width (H) allows for a common case usage to sustain maximum throughput. As an example, assuming a common application header size is 16 bytes (e.g., mapping to four D-word headers for PCIe) and the interface sustains two headers per cycle, H=2*(16)=32 bytes. Corresponding enable signals (and lanes) may be included in the HDR channel to correspond to the desired number of headers per cycle. As an example, if it is desired for an interface to support up to two headers per cycle, a corresponding number of valid lanes of M=2 may be defined to support one valid signal for each of the two potential headers in a cycle (e.g., hdr_valid[0] corresponds to a header beginning at byte 0 of the header signal, hdr_valid[1] corresponds to a header beginning at byte 16 of the header signal, etc.). In some cases, one or more of the header formats of the supported protocols may be too large to be transmitted on only one of the subset of lanes defined in the header signal (and assigned to each of the valid signal lanes), and such headers may utilize two or more of the subset of lanes of the header signal for transmission (and only the first (lowest) one of the two or more associated valid signals may be asserted). In such a case, if a larger header format is transmitted for a header signal when the maximum headers per cycle is set to two, only one header may be transferred in that cycle and hdr_valid[1] is not asserted, among other examples.

[0054] Continuing with the example of FIG. 7, the header metadata may additionally include information for use in flow control of the header (and associated packets). For example, the metadata may include a virtual channel (VC) identifier (ID) 720 for the header and a flow control class (FC) ID 730 for the header. In some cases, packet ordering may follow the VC ID and FC ID (e.g., a combination of VC ID and FC ID) of the packet. In some implementations, parameters of the SFI interface may be configured to set a predetermined number of maximum FC and VC ID combinations for the interface that are allowed to be used in any given transmission cycle (e.g., clock cycle) of the interface. This maximum number of FC-VC combinations may be advertised or otherwise set (e.g., at design compile time) in both the transmitter and receiver interface logic. This maximum may be set to help minimize write ports in the receiver storage, for example, when receiver buffers are shared among supported FCs and / or VCs. As an example, an interface may be parameterized to accept a maximum of two different FC-VC combinations in a cycle, so that in any given cycle, all packet headers forwarded will belong to a maximum of two different FCs within the same VC, the same FC but two different VCs, or the same FC-VC combination.

[0055] The transmitter may utilize credits associated with an FC, VC, or FC-VC combination to determine whether a packet is to be transmitted over a channel. For example, if a packet header has data associated with it, the packet header is transmitted on the HDR channel and the associated data is transmitted on the DATA channel. Before transmitting the header or payload data, the transmitter may check (e.g., tracking records in local memory) the available credits for both the header and payload data (and corresponding HDR and DATA channels) before scheduling the header or payload data transfer. In some implementations, the credit granularity of the header channel may be set to the maximum supported header size. For example, if the maximum supported header size is 20 bytes, one credit on the header channel may correspond to 20 bytes worth of storage at the receiver. In some examples, even if only a 16-byte header is transmitted, one full credit corresponding to the full 20 bytes is consumed, among other examples and similar alternative flow control and credit implementations.

[0056] Referring to FIG. 8, a simplified timing diagram 800 is shown to illustrate an example of a header transfer using a header channel of an exemplary SFI interface. The header channel may include a clock lane, one or more lanes dedicated to header valid signals (e.g., 810, 825), lanes dedicated to header metadata communication (e.g., 815, 830), and lanes dedicated to implementing multiple bytes of the header bus (e.g., 820, 835). In the example of FIG. 8, multiple valid signals are provided to control the transmission of valid header data on corresponding subsections of the header bus. For example, the header lane 810 may carry a valid signal corresponding to the lane (e.g., 820) implementing bytes 0-15 of the header bus, and the header lane 825 may carry a valid signal corresponding to the lane (e.g., 835) implementing bytes 16-31 of the header bus. Thus, valid signal 810 may be asserted as long as valid data is transmitted in bytes 0-15 of the header bus (e.g., as in clock cycles 1, 2, and 4), and similarly, valid signal 825 may be asserted to correspond to valid data transmitted in bytes 16-31. In one example, as in FIG. 8, corresponding header data may be transmitted in line (e.g., the same clock cycle) as a corresponding asserted valid signal, although in alternative implementations a delay may be defined between assertion of the valid signal and transmission of the header data, among other example features and implementations.

[0057] Continuing with the example of FIG. 8, subsections of lanes implementing the header bus may also be associated with respective header metadata (or hdr_info) signals (e.g., 815, 830). For example, header bytes 0-15 (e.g., 820) may be associated with a first header metadata signal 815, and header bytes 16-31 may be associated with a second header metadata signal 830. A header metadata signal may carry data (e.g., 8 bytes) per cycle that describes attributes of the header carried on the corresponding header bus lane. In some cases, both subsections of the header bus may be utilized to carry larger headers, resulting in less than the maximum number of headers per cycle transmitted in a given cycle (e.g., clock cycle 4). When two or more subsections of the header bus are used to transmit a single header, in some implementations, only one of the corresponding metadata signals (e.g., the signal corresponding to the least significant byte of the header) may carry data, while the remaining metadata signals do not carry any metadata at all. In this manner, the receiver may identify that two or more subsets of the header bus lanes are being used to transmit a single header, among other examples (e.g., assertion of one or both of the valid signals (e.g., 810, 825) corresponding to the subsection of the header bus used to communicate the header).

[0058] In particular, the simplified example of Figure 8 shows five transaction layer packet (TLP) headers being transmitted over the exemplary SFI header channel. For example, the header bus subsections 820, 835 may each carry the headers of two separate TLPs in clock cycles 1 and 2 (e.g., the headers of TLP0 (840) and TLP1 (845) in cycle 1, and the headers of TLP2 (850) and TLP3 (855) in cycle 2). This may be possible based on the header size of the respective packets. Additionally, corresponding header metadata (e.g., 865, 870, 875, 880) may be transmitted on corresponding header metadata signals 815, 830 in cycles 1 and 2. The valid signals 810, 825 may be deasserted in cycle 3, such that no additional header data is transmitted during this cycle.

[0059] In cycle 4, a header for another TLP, TLP4, is transmitted. In this example, the size of the TLP4 header requires transfers on both header bus subsections 820, 835 to communicate the header on the HDR channel in a single clock cycle. For example, the TLP0-3 headers (e.g., 840, 845, 850, 855) may be of size HDR_SIZE=4, while the size of the TLP4 header may be HDR_SIZE=5. Thus, in this example, bytes of the TLP4 header (860a-b) are transmitted on lanes of both header bus subsections 820 and 835. In this example, only the valid signal 810 corresponding to the subsection (or byte) of the header bus carrying the first (or least significant byte) of the header is asserted high (at 890), while the other valid signal 825 remains deasserted in clock cycle 4. Similarly, only one of the header metadata signals (e.g., 815) may be used to carry metadata information for the TLP4 header, with the metadata signal (e.g., 830) corresponding to the most significant byte of the header carrying a null or other signal. In one example, the headers of TLP0-4 may follow a PCIe-based protocol. In such a case, the TLP HDR byte follows the format described in the PCI Express Base Specification. In this example, among other example implementations, HDR_start[0] is associated with the header byte[0], and hdr_start[1] is always associated with the header byte

[16] .

[0060] In some implementations, the SFI interface is implemented as a synchronous interface, with both sides of the interface running on the same clock. Nevertheless, the transmitter and receiver may not be required to coordinate resets at each device. Instead, in some implementations, the initialization flow defined for the interface may define a separate handshake to ensure that the transmitter and receiver exchange information regarding interface reset and flow control before traffic begins on the interface.

[0061] Referring to FIG. 9, a simplified timing diagram 900 is shown to illustrate an example of data transfer using a data channel of an exemplary SFI interface. In this example, the DATA channel includes a clock 905, a single valid signal 910 (e.g., on a single lane of the channel), and a set of lanes (e.g., 915, 920) that implement one or more subsections of a data bus. In the particular illustrative example of FIG. 9, an X-1 subsection is shown. When the valid signal 910 is asserted (e.g., at 945), data appearing on the data bus (and supporting signals (e.g., 925, 930, 935, 940)) is considered valid. When the valid 910 is deasserted (e.g., at 966), the transmission of data on the data bus is paused or stopped until the valid is reasserted.

[0062] In some implementations of the SFI DATA channel, a start of data (or data_start) signal may be provided that is implemented in a set of lanes to implement a corresponding number of bits of the data_start signal. For example, the data_start signal may be implemented as a bit vector with a corresponding data_start lane (e.g., 925, 926, 928, etc.) mapped to a respective byte or span in the data bus. For example, each data_start lane (e.g., 925, 926, 928, etc.) may map to a corresponding one of the X+1 subsections of the data bus. For example, if there are eight subsections of the data bus, the start of data signal may be comprised of eight bits or lanes with each bit mapped to one of the subsections. When the first byte of the payload (e.g., as measured from least significant byte to most significant byte) is communicated on a particular clock cycle, the corresponding start of data signal (e.g., 925) may be asserted to identify the subsection (or chunk) of the data bus in which that first payload byte can be found (e.g., at 954). This allows the receiver to identify the boundary between two payloads communicated on the channel.

[0063] As with the HDR channel example, the SFI DATA channel may also carry metadata on a dedicated metadata (data_info) signal lane (e.g., 930, 935) to describe the corresponding payload data being transmitted on the data bus. In some implementations, the metadata for a payload may be communicated on the DATA channel relative to the start of the payload (e.g., aligned with the first byte of the payload and the corresponding data_start signal). Indeed, multiple metadata signals may be defined and carried on the DATA channel, one corresponding to each of a corresponding number of subsections (e.g., 915, 920) of the data bus. The subsections or chunks may, in some implementations, correspond to the same logical chunks utilized in the data_start signal (and / or data_end signal 940). For example, if a particular chunk carries the first byte of a new payload, then the corresponding one of the metadata signals (e.g., 930, 935) is responsible for carrying the corresponding metadata for that payload. 9, at clock cycle 1, the start of the payload of TLP0 (950) may begin on the first subsection (e.g., 915) of the data bus. Thus, the data_start signal 925 may indicate (at 954) that the subsection (e.g., corresponding to byte 0 of the data bus) carries the start of a new payload. The other subsection (e.g., 920) of the data bus may be used to communicate additional other chunks (e.g., 952) of the same payload. Additionally, one of the metadata signals (e.g., 930) corresponding to the first subsection (e.g., 915) of the data bus may be encoded with the metadata (e.g., 956) of the TLP0 payload.

[0064] Continuing with the example of FIG. 9, the payload data of TLP0 (e.g., 950, 952, 960) may continue to be transmitted over multiple clock cycles on the data bus until it is all transmitted. The data (or data_end) signal 940 may operate in a manner similar to a start of data signal with several lanes (e.g., 940, 942) mapped to identify the subsection of the data bus where the final chunk of payload data was sent in the corresponding clock cycle. The granularity of the subsection or chunk referenced by the data_end signal may be higher, lower, or the same as the granularity used in the data_start and metadata signals. In one example, the subsection or chunk referenced by the data_end signal 940 may be 4 bytes, among other examples. In the particular example of FIG. 9, the last byte / bit of the payload of TLP0 is transmitted in subsection "N" of data bus bytes and lanes as measured according to the granularity configured for the data_end signal. Thus, a lane of the data_end signal mapped to subsection N (e.g., 940) may be asserted to identify that subsection N carries the end of the payload. In some implementations, the granularity of the data bus subsections and chunks used by the start of data, end of data, and metadata signals may be set through a corresponding parameter set for the SFI interface, among other examples.

[0065] Continuing with the example of FIG. 9, the second payload of the second packet (e.g., TLP1) can be transmitted on the data bus (e.g., the start of the second packet is transmitted in data chunk / subsection "Y"). In some implementations, the payloads of multiple packets can be transmitted simultaneously on the data bus (e.g., using each subsection of the data bus). In this example, the payload of TLP0 ends and the payload of TLP1 starts in clock cycle 2. Thus, both the data end signal (e.g., 970) and the data start signal (e.g., 964) are transmitted in the same cycle, and the data start signal 964 indicates the subsection or chunk of the data bus where the start of the payload appears (e.g., subsection "Y", where 0 < Y < X). In the example of FIG. 9, the start of the data signal can be at the granularity of 1 byte, specifically identifying the byte within the data bus where the payload starts (e.g., byte 0 for the payload of TLP0, byte Y for the payload of TLP1, etc.). Thus, the widths of the data start signal and the data end signal can be based on the respective granularities used. Further, in the example of FIG. 9, the payload of TLP1 starts being transmitted in clock cycle 2, but the transmission can be temporarily interrupted via deassertion (966) of the valid signal 910, and the remaining bytes (e.g., 972, 974) are transmitted when valid 910 is reasserted. In other examples, within other exemplary implementations, it can be required that valid remains asserted until all bytes of the payload being transferred are sent. It should be understood that the examples of FIGS. 8 and 9 are simplified non-limiting examples provided to illustrate more general principles (and alternative implementations) that can be implemented in exemplary SFIHDR channels and DATA channels among other examples.

[0066] In some implementations, state machines or other logic may be provided on the agent and fabric devices to participate in the defined connect and disconnect flows for the SFI interface. For example, such flows may be invoked when entering a low power mode during boot / reset and among other example states or events. In some implementations, the SFI defines an initialization phase in which information regarding receiver (RX) credit availability is communicated to the transmitter (TX) after a connection is established. In some cases, resets may be independently deasserted between the agent and fabric sides of the SFI. For independent resets, the initialization signal may be driven to a disconnected state (e.g., on the global channel) upon reset and no traffic is sent until the initialization reaches a connected state. A disconnect flow may additionally be supported by the agent, for example, to reconfigure credits and achieve power savings. Without this flow, all SFI credits may be set to their final values ​​before the first connection proceeds.

[0067] At initialization, the sender and receiver sides of the SFI interface (e.g., the agent and fabric sides) may be taken out of reset either adjacently or simultaneously. One end of the interface (e.g., after coming out of reset) may have no implicit requirements on when the other end should come out of reset. In some implementations, the SFI defines an explicit handshake during initialization between the agent and fabric to ensure that both endpoints (and all pipeline stages between them) are out of reset before credits or transactions are sent on the UFI interface. Thus, after reset, the receiver may begin sending credits for use by the sender.

[0068] 10 is a diagram 1000 illustrating an example state machine of initialization states in an example implementation of an SFI interface. The states may include a disconnected state 1010 (which may be entered based on reset 1005), a connecting state 1015, a connected state (1020, 1035), a disconnecting state 1025, and a rejecting state 1030. A combination of values ​​of the txcon_req, rxcon_ack, and rxdiscon_nack signals may indicate the respective initialization states. As an example, in the disconnecting state 1025, the txcon_req signal may be LOW, the rxcon ack signal may be HIGH, and the rxdiscon_nack may be LOW. Changing a particular one of the signal values ​​may cause a transition from one initialization state to another initialization state. For example, as illustrated in the example state machine of Figure 10, among other examples, in the Disconnecting state 1025, changing the rxcon_ack signal from HIGH to LOW may cause a transition to the Disconnected state 1010, while changing the rxdiscon_nack signal from LOW to HIGH may cause a transition to the Rejected state 1030. In the UFI interface, each initialization state is used to determine the actions to be taken by the receiver and transmitter, such as the example actions described in Table 5 below.

[0069] [Table 5]

[0070] Signaling rules may be defined for a global initialization signal set. In one example, a txcon_req signal may be defined such that a transition from 0 to 1 reflects a connection request and a transition from 1 to 0 reflects a disconnection request. Credit return signals may be provided, for example, with a credit valid (crd_valid) signal and a credit shared (crd_shared) signal. In one example, crd_valid=1 may be defined to mean release dedicated message credits for a protocol ID and virtual channel ID, while crd_shared=1 means release shared credits (which may occur in parallel with the dedicated message credit return). In some implementations, credit return operates the same as during the runtime return of credits as it does during the first initialization of credits. The rx_empy signal indicates all channel credits returned from the receiver and all receiver queues are empty (however, this may not account for messages in flight or intermediate buffers such as clock crossing queues, among other example issues). In some implementations, the transmitter may check rx_empty before initiating a disconnection. Checking increases the probability that the disconnection will be accepted immediately (e.g., if there are no possible in-flight requests not yet registered at the receiver). In some implementations, to further increase the probability of disconnection acceptance, the sender may implement a timer delay after the last valid message sent so that the receiver pipeline has time to drain into the receiver queue, among other example features. In some implementations, during initialization, the sender sends messages as soon as any credit becomes available and is not dependent on rx_empty assertion. Alternatively, the sender may stop sending packets after initialization until rx_empty is asserted, and the sender can use the received credit as an indication of the total credit advertised by the receiver. In an example implementation of the SFI interface, the sender may send packets when it receives sufficient credit from the receiver.The transmitter may identify that a packet is to be transmitted and may determine that there are sufficient HDR and Data credits, respectively, for the packet before transmission begins.

[0071] As a further example of signaling rules that may be defined in a UFI implementation, a connection ACK may be defined to always follow a connection request. As mentioned above, a connection request may be signaled by a txcon_req transitioning from 0 → 1. This transition serves as an indication that the transmitter Tx is ready to receive credits and is in normal operation. An ACK may be signaled by an rxcon_ack transitioning from 0 to 1. An ACK may be suspended for any amount of time until the receiver is ready to complete. Similarly, a disconnection ACK or NACK may be defined to follow a disconnection request. A disconnection request may be signaled by a txcon_req transitioning from 1 to 0. A disconnection ACK may be signaled by an rxcon_ack transitioning from 1 to 0. A disconnection NACK may be signaled by an rxdiscon_nack transitioning from 0 to 1. Rules may be defined to require the receiver to respond with either an ACK or a NACK for each disconnection request it receives, among other example policies and implementations.

[0072] With reference to FIG. 11, an exemplary timing diagram 1100 is shown for initialization of an SFI interface from a reset to a connected state. In the particular example shown in FIG. 11, an exemplary initialization flow is shown utilizing initialization signals in a global channel of the SFI interface. As shown in FIG. 11, the initialization signal set may include a receiver disconnect NACK signal 1110, a receiver connect ACK signal 1115, and a transmitter connect request signal 1120. Additional signals are shown to illustrate certain features including a receiver reset signal 1130 (causing the agent to enter a reset condition), a transmitter reset signal 1135 (causing the fabric to enter a reset condition). Also shown is a representation of at least one of a set of credit return signals 1125 of the SFI channels (e.g., a credit signal set for one or more of the HDR channel and the DATA channel).

[0073] To enter the connection state, once the transmitter is not reset, the transmitter may assert the txcon_req signal 1120 to identify a request to the receiver. Similarly, when the receiver is not reset, the receiver waits for a connection request on the txcon_req signal 1120. The assertion of the connection request may be any number of cycles after a reset (e.g., 1130) is asserted. The txcon_req signal 1120 remains asserted until the connection is complete, and is only deasserted as part of a disconnect flow. Upon receiving a connection request on the txcon_req signal 1120, the receiver may assert the rxcon_ack signal 1115 to acknowledge the request. The rxcon_ack signal 1115 may be asserted after a receiver and transmitter reset and the assertion of the txcon_req signal 1120. The rxcon_ack signal 1115 remains asserted, and is only initially deasserted in a disconnect flow.

[0074] This sequence may allow the initialization link state 1105 to progress from disconnected to connected. Upon entering the connected state (and sending the rxcon_ack signal), the receiver may immediately start returning credits (e.g., on the credit return wire 1125). In fact, the receiver may start returning credits simultaneously with the assertion of the rxcon_ack signal 1115. Thus, the transmitter (e.g., agent) is willing to accept the credit return when it asserts the txcon_req signal 1120 (e.g., at clock cycle x4) since the credit return may be observed before the observation of the A2F_rxcon_ack, e.g., due to intermediate buffering or clock crossings. After receiving the minimum credits and transmitting a packet, the transmitter may start transmitting packets or messages over the channel. The reconnect flow may be implemented similarly to the connection from reset flow described herein, but to start a new credit initialization, the receiver first resets its credit counter to a reset value and the transmitter resets its credit available counter to zero, among other examples.

[0075] Referring to FIG. 12, an example timing diagram 1200 illustrates an example disconnection and reconnection flow for an example SFI interface. In this example, the transmitter may deassert the txcon_req signal 1120 to facilitate the disconnection at time x3. In some implementations, to allow the disconnection to proceed, the rxdiscon_nack signal 1110 is deasserted before the txcon_req signal 1120 is deasserted. When the disconnection is requested, the transmitter no longer transmits messages on any channel (e.g., as indicated by the CHAN_is_valid bit assertion). Based on the initiation of the disconnection flow by the transmitter, the receiver decides whether to acknowledge (ACK) or negatively acknowledge (NACK or reject) the disconnection. To acknowledge the disconnection, the receiver may deassert the rxcon_ack signal 1115 after ensuring that all pipelines are empty (e.g., at clock cycle x4), which marks the entry into the disconnected state (as reflected by the link state indicator 1105). In some cases, the receiver may also guarantee that all credits have been returned.

[0076] While the diagram 1200 of FIG. 12 illustrates an instance where the disconnect request is positively acknowledged by the receiver, FIG. 13 illustrates the opposite example where the receiver responds with a negative acknowledgement (or NACK). For example, to send a negative acknowledgement, the receiver may instead assert the rxdiscon_nack signal 1110 negative acknowledgement (e.g., clock cycle x4). For example, a negative acknowledgement may be selected if the receiver determines, among other example reasons, that it cannot drain its pipeline without risking deadlock. After the NACK, the transmitter reasserts the txcon_req signal 1120 (e.g., at clock cycle x6). Following this valid acknowledgement by the transmitter of the receiver's NACK, the rxdiscon_nack signal 1110 may be deasserted (e.g., as shown in clock cycle x6 of the example of FIG. 13).

[0077] In some implementations, connection and disconnection flows are expected to complete within a few microseconds after initiation. In some implementations, a timeout may be explicitly or implicitly defined. For example, a receiver may be configured to respond with an ACK or NACK within a defined or recommended time frame. For example, an agent, fabric, or system (e.g., SoC) may define a timeout or time window to enforce this expectation.

[0078] In some cases, an agent or fabric element may be reset while the SFI interface is in the Connected state, resulting in an abrupt reset. For example, a defined or recommended flow may be to enter Disconnect before Reset. As an example, the rxcon_ack signal may make a transition 1→0 due to an abrupt reset on the receiver side of the link while the transmitter's txcon_req signal has a value of 1. In such a case, the transmitter may force itself to the Disconnected state and restart initialization. If this occurs when the transmitter is in an Idle state, it may be able to recover without losing messages. As another example of an abrupt reset, a standard Disconnect flow may be followed if the txcon_req signal transitions 1→0 due to an abrupt reset on the transmitter side of the link while rxcon_ack is 1. If this occurs when the receiver is in an Idle state, the Disconnect should receive an Ack and reach the Disconnected state cleanly if the transmitter remains reset. However, if the Disconnect is NACKed by the receiver, a fatal or illegal link state (e.g., an unrecoverable error) may result. In the case of a sudden reset, if traffic is active (eg, not idle), loss of protocol messages may occur, which may be fatal to continuing normal operation.

[0079] As discussed above, the SFI interfaces in a system may be configurable according to various parameters. For example, a set of parameters may be specifically defined according to the use cases, characteristics, protocols, and topology of a given system, such as a particular SoC design. Such parameters may define, for example, a maximum number of headers that can be transmitted in one cycle, a maximum header size, a maximum number of different packet payloads that can be transmitted in one cycle, among other example parameters. Values ​​of the parameters may be defined and stored, for example, in configuration registers or other data structures for use and reference by agents and fabric components connected via the interface. Table 6 shows an example of configurable parameters for an example SFI interface.

[0080] [Table 6]

[0081] 14A-14B, simplified flowcharts 1400a-b are shown illustrating an example technique for using an SFI interface as described in the example implementations herein. For example, in the example of FIG. 14A, the SFI interface may be comprised of lanes assigned to each signal in a set of signals for sending messages to a receiver in a particular one of the interface's channels (e.g., global, HDR, and DATA), as well as lanes assigned to signals received from the receiver of the message (e.g., credit return signals). The global channel appears to include multiple lanes for sending and receiving respective signals to control aspects of the interface, including initialization of the interface. Indeed, an initialization signal may be communicated over the interface 1405 to initialize 1410 the interface for sending messages to the interface's channels (e.g., HDR and DATA). Among other examples, packets prepared by a protocol layer of an agent or other logic on the device (e.g., IP block, fabric block, gasket device, or other device) according to a particular streaming or load / store protocol, such as PCIe or CXL.io, may be identified 1415. The header and payload of a packet may be transmitted separately on dedicated header (HDR) and payload (DATA) channels of the interface. For example, a header may be sent 1420 on a header bus lane of the header channel with the header metadata sent 1425 on a lane of the HDR channel dedicated to the header metadata signal. Similarly, the DATA channel may be used to transmit 1430 payload data on the data bus lane of the DATA channel, and the corresponding payload metadata may be sent on another lane of the DATA channel implementing one or more metadata signals for the DATA channel. In some implementations, a valid signal may be sent on a dedicated set of one or more lanes of the corresponding channel to transmit the header or payload on the HDR or DATA channel, respectively.In some implementations, the credit return may be received by the sender of packets corresponding to the respective credits used in each of the HDR and DATA channels, which may be implemented in the HDR and DATA channels as discussed in the examples above, among other example information and signals.

[0082] In the example of FIG. 14B, the technique is shown associated with a receiver on an SFI interface. In some implementations, a single device may implement a transmitter for a first instance of an SFI interface and a receiver for a complementary second instance of an SFI interface, among other example configurations. In one example, a global channel may be provided at the receiver to communicate an initialization signal to initialize the interface 1435. After initialization, packet data may be received over the interface including the header and payload data of the packet. For example, the header of the packet may be received on a lane of the header channel 1450 and header metadata is received for the header on a separate metadata lane of the header channel 1455. The payload data of the packet may be received on a separate data channel lane 1460. Payload metadata may be received on an additional metadata lane of the data channel 1465 to describe attributes of the payload (e.g., flow control information). The receiver may process the packet 1470 (e.g., buffer, associate the header with its packet, decode the header, identify the boundaries of the payload transmitted on the data lanes, etc.) based on the header and payload metadata transmitted on the respective metadata lanes of the header and data channels. The receiver may also transmit credit returns on additional dedicated lanes of the header and data channels, among other example functionality provided by logic at the receiver.

[0083] It should be noted that the above-mentioned apparatus, methods, and systems may be implemented in any electronic device or system as described above. As a specific illustration, the following figures provide exemplary systems (e.g., SoCs, computing blocks, fabric blocks, etc.) for utilizing the solutions described herein. Although the following systems are described in more detail, numerous different interconnects, use cases, topologies, and applications are disclosed, described, and re-explained from the above discussion. And, as is readily apparent, the above-mentioned advances may be applied to any of those interconnects, fabrics, or architectures, and their composite components.

[0084] Referring to Figure 15, one embodiment of a block diagram of a computing system including a multi-core processor is depicted. Processor 1500 includes any processor or processing device, such as a microprocessor, embedded processor, digital signal processor (DSP), network processor, handheld processor, application processor, co-processor, system on chip (SoC), or other device that executes code. Processor 1500 includes at least two core-cores 1501 and 1502, which in one embodiment appear to include asymmetric or symmetric cores (the illustrated embodiment). However, processor 1500 may include any number of processing elements, which may be symmetric or asymmetric.

[0085] In one embodiment, a processing element refers to hardware or logic for supporting a software thread. Examples of hardware processing elements include: thread units, thread slots, threads, process units, contexts, context units, logical processors, hardware threads, cores, and / or any other element that can hold state for a processor, such as an execution state or architectural state. In other words, in one embodiment, a processing element refers to any hardware that can be independently associated with code, such as a software thread, an operating system, an application, or other code. A physical processor (or processor socket) typically refers to an integrated circuit that potentially contains any number of other processing elements, such as cores or hardware threads.

[0086] A core often refers to logic located on an integrated circuit that can maintain independent architectural states, where each independently maintained architectural state is associated with at least some dedicated execution resources. In contrast to a core, a hardware thread typically refers to any logic located on an integrated circuit that can maintain independent architectural states, where the independently maintained architectural states share access to the execution resources. As can be seen from the figure, the lines between the names of hardware threads and cores overlap when certain resources are shared and other resources are dedicated to architectural states. However, often the cores and hardware threads are viewed by the operating system as individual logical processors, where the operating system can schedule operations on each logical processor individually.

[0087] The physical processor 1500 includes two cores--cores 1501 and 1502, as shown in FIG. 15. Here, the cores 1501 and 1502 are considered to be symmetric cores, i.e., cores having the same configuration, functional units, and / or logic. In another embodiment, the core 1501 includes an out-of-order processor core, and the core 1502 includes an in-order processor core. However, the cores 1501 and 1502 may be individually selected from any type of core, such as native cores, software-managed cores, cores adapted to execute a native instruction set architecture (ISA), cores adapted to execute a transformed instruction set architecture (ISA), co-designed cores, or other known cores. In a heterogeneous core environment (i.e., asymmetric cores), some form of translation, such as binary translation, may be utilized to schedule or execute code on one or both cores. However, for further explanation, the functional units shown in the core 1501 are described in more detail below, and the units of the core 1502 operate in a similar manner in the illustrated embodiment.

[0088] As shown, core 1501 includes two hardware threads 1501a and 1501b, which are also referred to as hardware thread slots 1501a and 1501b. Thus, in one embodiment, a software entity, such as an operating system, potentially views processor 1500 as four separate processors, i.e., four logical processors or processing elements capable of simultaneously executing four software threads. As described above, a first thread may be associated with architecture state register 1501a, a second thread may be associated with architecture state register 1501b, a third thread may be associated with architecture state register 1502a, and a fourth thread may be associated with architecture state register 1502b. Here, each architecture state register (1301a, 1501b, 1502a, and 1502b) may be referred to as a processing element, thread slot, or thread unit, as described above. As shown, architecture state registers 1501a are duplicated in architecture state registers 1501b so that individual architecture state / context can be stored for logical processor 1501a and logical processor 1501b. In core 1501, other smaller resources such as instruction pointers and renaming logic in allocator and renamer block 1530 may also be duplicated for threads 1501a and 1501b. Some resources such as reorder / retirement unit 1535, ILTB 1520, load / store buffers, and reorder buffers in queues may be shared by partitioning. Other resources such as general-purpose internal registers, page table base register(s), low-level data cache and data TLB 1515, execution unit(s) 1540, and parts of out-of-order unit 1535 are potentially fully shared.

[0089] Processor 1500 often includes other resources, which may be fully shared, shared by partitioning, or dedicated by / to processing elements. In FIG. 15, one embodiment of a purely exemplary processor is shown with exemplary logical units / resources of the processor. Note that the processor may include or omit any of these functional units, and may also include any other known functional units, logic, or firmware not shown. As shown, core 1501 includes a simplified representative out-of-order (OOO) processor core. However, in different embodiments, an in-order processor may be utilized. The OOO core includes a branch target buffer 1520 for predicting branches that will be executed / taken, and an instruction-to-translation buffer 1520 for storing address translation entries for instructions.

[0090] The core 1501 further includes a decode module 1525 coupled to the fetch unit 1520 to decode the fetched elements. In one embodiment, the fetch logic includes individual sequencers associated with the thread slots 1501a, 1501b, respectively. Typically, the core 1501 is associated with a first ISA that defines / specifies instructions executable on the processor 1500. Machine code instructions that are part of the first ISA often include a portion of the instruction (called an opcode) that references / specifies the instruction or operation to be performed. The decode logic 1525 includes circuitry that recognizes these instructions from their opcodes and passes the decoded instructions into the pipeline for processing defined by the first ISA. For example, as described in more detail below, in one embodiment, it includes logic designed or adapted to recognize certain instructions, such as transactional instructions. As a result of recognition by the decoder 1525, the architecture or core 1501 takes a specific predefined action to perform a task associated with the appropriate instruction. It is important to note that any of the tasks, blocks, operations, and methods described herein may be executed in response to a single or multiple instructions, some of which may be new or legacy. Note that the decoder 1526, in one embodiment, recognizes the same ISA (or a subset thereof). Alternatively, in a heterogeneous core environment, the decoder 1526 recognizes a second ISA (either a subset of the first ISA or a separate ISA).

[0091] In one example, allocator and renamer block 1530 includes an allocator to reserve resources such as a register file for storing instruction processing results. However, threads 1501a and 1501b are potentially capable of out-of-order execution if allocator and renamer block 1530 also reserves other resources such as a reorder buffer for tracking instruction results. Unit 1530 may also include a register renamer that renames program / instruction reference registers to other registers internal to processor 1500. Reorder / retirement unit 1535 includes components such as the reorder buffer, load buffer, and store buffer described above to support out-of-order execution and later in-order retirement of out-of-order executed instructions.

[0092] The scheduler and execution unit(s) block 1540, in one embodiment, includes a scheduler unit that schedules instructions / operations on the execution units. For example, floating point instructions are scheduled on ports of execution units that have an available floating point execution unit. Also included are register files associated with the execution units to store information instruction processing results. Exemplary execution units include floating point execution units, integer execution units, jump execution units, load execution units, store execution units, and other known execution units.

[0093] A lower level data cache and data translation buffer (D-TLB) 1550 is coupled to the execution unit(s) 1540. The data cache stores recently used / operated on elements such as data operands that may be held in a memory coherency state. The D-TLB stores recent virtual / linear / physical address translations. As a particular example, the processor may include a page table structure that divides physical memory into multiple virtual pages.

[0094] Here, the cores 1501 and 1502 share access to a higher or longer level cache, such as a second level cache associated with the on-chip interface 1510. Higher level or further out refers to increasing cache levels or further away from the execution unit(s). In one embodiment, the higher level cache is a last level data cache in the memory hierarchy on the processor 1500 - the last cache, e.g., a second or third level data cache. However, the higher level cache is not so limited, as it may be associated with or include an instruction cache. A trace cache - a type of instruction cache - may instead be coupled after the decoder 1525 to store recently decoded traces. Here, instructions potentially refer to macro-instructions (i.e., general instructions recognized by the decoder), which may decode into several micro-instructions (micro-operations).

[0095] In the illustrated configuration, the processor 1500 also includes an on-chip interface module 1510. Historically, a memory controller, described in more detail below, has been included in a computing system external to the processor 1500. In this scenario, the on-chip interface 1510 communicates with devices external to the processor 1500, such as a system memory 1575, a chipset (which often includes a memory controller hub for connecting to the memory 1575 and an I / O controller hub for connecting peripheral devices), a memory controller hub, a northbridge, or other integrated circuits. Also, in this scenario, the bus 1505 may include any known interconnect, such as a multi-drop bus, a point-to-point interconnect, a serial interconnect, a parallel bus, a coherent (e.g., cache coherent) bus, a layered protocol architecture, a differential bus, and a GTL bus.

[0096] Memory 1575 may be dedicated to processor 1500 or may be shared with other devices in the system. Common examples of types of memory 1575 include DRAM, SRAM, non-volatile memory, and other known storage devices. It should be noted that devices 1580 may include a graphics accelerator, a processor or card coupled to a memory controller hub, data storage coupled to an I / O controller hub, a wireless transceiver, a flash device, an audio controller, a network controller, or other known devices.

[0097] However, as more logic and devices are now integrated on a single die, such as a SOC, each of these devices may be incorporated on the processor 1500. For example, in one embodiment, a memory controller hub is on the same package and / or die as the processor 1500. Here, a portion of the core (on-core portion) 1510 includes one or more controllers for interfacing with other devices, such as memory 1575 or a graphics device 1580. A configuration including interconnects and controllers for interfacing with such devices is often referred to as on-core (or un-core configuration). As an example, the on-chip interface 1510 includes a ring interconnect for on-chip communication and a high-speed serial point-to-point link 1505 for off-chip communication. However, in a SOC environment, many more devices, such as a network interface, a co-processor, memory 1575, a graphics processor 1580, and any other known computing device / interface, may be integrated on a single die or integrated circuit to provide a small form factor with high functionality and low power consumption.

[0098] In one embodiment, the processor 1500 may execute compiler, optimization, and / or translator code 1577 to compile, translate, and / or optimize application code 1576 to support or interface with the apparatus and methods described herein. A compiler often includes a program or set of programs for converting source text / code into target text / code. Typically, compiler compilation of program / application code occurs in multiple phases and passes to convert high-level programming language code into low-level machine or assembly language code. However, single-pass compilers may still be utilized for simple compilation. The compiler may utilize any known compiler techniques to perform any known compiler operations such as lexical analysis, preprocessing, syntax analysis, semantic analysis, code generation, code transformation, and code optimization.

[0099] Large compilers often include multiple phases, but in most cases these phases are included in two general phases: (1) a front-end where syntactic processing, semantic processing, and certain transformations / optimizations generally occur, and (2) a back-end where parsing, transformation, optimization, and code generation generally occur. Some compilers refer to a middle, which illustrates the blurring of the lines between the compiler's front-end and back-end. As a result, references to compiler insertion, association, generation, or other operations may occur in any of the phases or passes mentioned above, as well as other known phases or passes of the compiler. As an illustrative example, a compiler potentially inserts operations, calls, functions, etc. in one or more phases of compilation, such as the insertion of a call / operation in the front-end phase of compilation, and then the transformation of the call / operation into lower level code during the transformation phase. Note that during dynamic compilation, the compiler code or dynamic optimization code may insert such operations / calls as well as optimize the code for execution during runtime. As a specific example, binary code (already compiled code) may be dynamically optimized during runtime. Here, the program code may include dynamic optimization code, binary code, or a combination thereof.

[0100] Similar to compilers, translators, such as binary translators, translate code statically or dynamically, and optimize and / or translate code. Thus, a reference to execution of code, application code, program code, or other software environment may refer to (1) the dynamic or static execution of a compiler program(s), optimization code optimizer, or translator to compile program code, maintain software structure, perform other operations, optimize code, or translate code, (2) the execution of main program code, including operations / calls such as optimized / compiled application code, (3) the execution of other program code, such as libraries, associated with the main program code to maintain software structure, perform other software-related operations, or optimize code, or (4) a combination thereof.

[0101] Referring now to Figure 16, a block diagram of one embodiment of a multi-core processor is shown. As shown in the embodiment of Figure 16, a processor 1600 includes multiple domains. Specifically, a core domain 1630 includes multiple cores 1630A-1630N, a graphics domain 1660 includes one or more graphics engines having a media engine 1665, and a system agent domain 1610.

[0102] In various embodiments, the system agent domain 1610 handles power control events and power management such that the individual units (e.g., cores and / or graphics engines) of the domains 1630 and 1660 are independently controllable to dynamically operate in appropriate power modes / levels (e.g., active, turbo, sleep, hibernate, deep sleep, or other advanced configuration power interface-like states) in light of the activity (or inactivity) occurring in a given unit. Each of the domains 1630 and 1660 may operate at different voltages and / or powers, and further, the individual units within a domain each potentially operate at independent frequencies and voltages. While only three domains are shown, it should be noted that the scope of the disclosure is not limited in this respect and additional domains may be present in other embodiments.

[0103] As shown, each core 1630 further includes a lower level cache in addition to various execution units and additional processing elements, where the various cores are coupled to each other and to a shared cache memory formed from multiple units or slices of last level caches (LLCs) 1640A-1640N, which often include storage and cache controller functions and are shared between the cores, and potentially also between the graphics engines.

[0104] As shown, a ring interconnect 1650 couples the cores to one another and provides interconnection between the core domain 1630, the graphics domain 1660, and the system agent circuitry 1610 via multiple ring stops 1652A-N at the couplings between the cores and the LLC slices, respectively. As seen in FIG. 16, the interconnect 1650 is used to carry various information including address information, data information, acknowledgement information, and snoop / invalidation information. Although a ring interconnect is shown, any known on-die interconnect or fabric may be utilized. As illustrative examples, some of the fabrics described above (e.g., another on-die interconnect, an on-chip system fabric (OSF), an Advanced Microcontroller Bus Architecture (AMBA) interconnect, a multi-dimensional mesh fabric, or other known interconnect architectures) may be utilized in a similar manner.

[0105] As further shown, the system agent domain 1610 includes a display engine 1612 that provides control and interface to an associated display. The system agent domain 1610 may include an integrated memory controller 1620 that provides an interface to system memory (e.g., DRAM with multiple DIMMs implemented, coherence logic 1622 for performing memory coherence operations). There may be multiple interfaces to allow interconnection between the processor and other circuits. For example, in one embodiment, at least one Direct Media Interface (DMI) 1616 interface is provided along with one or more PCIe™ interfaces 1614. The display engine and these interfaces are typically coupled to the memory via a PCIe™ bridge 1618. Additionally, one or more other interfaces may be provided to provide communication between other agents, such as additional processors or other circuits.

[0106] Referring now to Figure 17, a block diagram of a representative core is shown, specifically the back-end logical blocks of a core such as core 1630 of Figure 16. In general, the structure shown in Figure 17 includes an out-of-order processor having a front-end unit 1770 that is used to take incoming instructions, perform various processing (e.g., caching, decoding, branch prediction, etc.), and pass the instructions / operations along to an out-of-order (OOO) engine 1780. The OOO engine 1780 performs further processing on the decoded instructions.

[0107] Specifically, in the embodiment of FIG. 17, the out-of-order engine 1780 includes an allocation unit 1782 for receiving decoded instructions, which may be in the form of one or more microinstructions or uops, from the front-end unit 1770 and allocating them to appropriate resources, such as registers, etc. The instructions are then provided to a reservation station 1784, which reserves resources and schedules them for execution in one of a number of execution units 1786A-1786N. There may be various types of execution units, such as, for example, an arithmetic logic unit (ALU), a load and store unit, a vector processing unit (VPU), a floating point execution unit, etc. Results from these different execution units are provided to a reorder buffer 1788, which receives the out-of-order results and returns them to the correct program order.

[0108] Still referring to FIG. 17, it should be noted that both the front-end unit 1770 and the out-of-order engine 1780 are coupled to different levels of the memory hierarchy. Specifically shown is an instruction level cache 1772, which in turn couples to a mid-level cache 1776 that couples to a last-level cache 1795. In one embodiment, the last-level cache 1795 is implemented in an on-chip (sometimes called an uncore) unit 1790. By way of example, the unit 1790 is similar to the system agent 1710 of FIG. 17. As discussed above, the uncore 1790 communicates with a system memory 1799, which in the illustrated embodiment is implemented by ED RAM. It should also be noted that the various execution units 1786 within the out-of-order engine 1780 communicate with a first-level cache 1774, which also communicates with the mid-level cache 1776. It should also be noted that additional cores 1730N-2 through 1730N can be coupled to the LLC 1795. Although shown at this high level in the embodiment of FIG. 17, it should be understood that various modifications and additional components may be present.

[0109] Referring to FIG. 18, a block diagram of an exemplary computer system formed with a processor including an execution unit for executing instructions, one or more of the interconnects implementing one or more features according to an embodiment of the present disclosure is shown. The system 1800 includes components such as a processor 1802 to use an execution unit including logic for executing algorithms for processing data according to the present disclosure, as in the embodiments described herein. In one embodiment, the sample system 1800 runs a version of an operating system and included software, and may also provide a corresponding graphical user interface. However, embodiments of the present disclosure are not limited to any particular combination of hardware circuitry and software.

[0110] The embodiments are not limited to computer systems. Alternative embodiments of the present disclosure can be used in other devices, such as handheld devices and embedded applications. Some examples of handheld devices include mobile phones, Internet Protocol devices, digital cameras, personal digital assistants (PDAs), and handheld PCs. Embedded applications can include microcontrollers, digital signal processors (DSPs), systems on chips, network computers (NetPCs), set-top boxes, network hubs, wide area network (WAN) switches, or any other system capable of executing one or more instructions according to at least one embodiment.

[0111] In this illustrated embodiment, the processor 1802 includes one or more execution units 1808 to implement an algorithm that executes at least one instruction. Although one embodiment may be described in the context of a single processor desktop or server system, alternative embodiments may be included in a multiprocessor system. The system 1800 is an example of a "hub" system architecture. The computer system 1800 includes a processor 1802 for processing data signals. The processor 1802 includes, by way of example, a complex instruction set computer (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a processor implementing a combination of instruction sets, or any other processor device, such as, for example, a digital signal processor. The processor 1802 is coupled to a processor bus 1810 that transmits data signals between the processor 1802 and other components in the system 1800. The elements of system 1800 (e.g., graphics accelerator 1812, memory controller hub 1816, memory 1820, I / O controller hub 1825, wireless transceiver 1826, flash BIOS 1828, network controller 1834, audio controller 1836, serial expansion port 1838, I / O controller 1840, etc.) perform conventional functions well known to those skilled in the art.

[0112] In one embodiment, the processor 1802 includes a level 1 (L1) internal cache memory 1804. Depending on the architecture, the processor 1802 may have a single internal cache or multiple levels of internal cache. Other embodiments include a combination of both internal and external caches, depending on the particular implementation and needs. The register file 1806 stores different types of data in various registers, including integer registers, floating point registers, vector registers, bank registers, shadow registers, checkpoint registers, status registers, and an instruction pointer register.

[0113] Execution units 1808, including logic to perform integer and floating point operations, are also present within the processor 1802. In one embodiment, the processor 1802 includes a microcode (ucode) ROM that stores microcode that, when executed, performs algorithms of specific macro instructions or processes complex scenarios, where the microcode is potentially updatable to handle logic bugs / fixes in the processor 1802. In one embodiment, the execution units 1808 include logic to process a packed instruction set 1809. By including the packed instruction set 1809 in the instruction set of the general purpose processor 1802, along with associated circuitry to execute the instructions, operations used by many multimedia applications may be performed using packed data within the general purpose processor 1802. Thus, many multimedia applications are accelerated and run more efficiently by using the full width of the processor's data bus to perform operations on the packed data. This potentially eliminates the need to transfer smaller units of data over the processor's data bus to perform one or more operations, i.e., one data element at a time.

[0114] Alternative embodiments of the execution unit 1808 may also be used in microcontrollers, embedded processors, graphics devices, DSPs, and other types of logic circuits. The system 1800 includes a memory 1820. The memory 1820 may include dynamic random access memory (DRAM) devices, static random access memory (SRAM) devices, flash memory devices, or other memory devices. The memory 1820 stores instructions and / or data represented by data signals to be executed by the processor 1802.

[0115] It should be noted that any of the above-mentioned features or aspects and solutions of the present disclosure may be utilized on one or more of the interconnects shown in Figure 18. For example, an on-die interconnect (ODI), not shown, for coupling internal units of the processor 1802 implements one or more aspects of the above-mentioned embodiments. Or, the embodiments may be associated with a processor bus 1810 (e.g., other known high-performance computing interconnects), a high-bandwidth memory path 1818 to memory 1820, a point-to-point link (e.g., Peripheral Component Interconnect Express (PCIe) compliant fabric) to a graphics accelerator 1812, a controller hub interconnect 1822, an I / O or other interconnect (e.g., USB, PCI, PCIe) for coupling other illustrated components. Some examples of such components include an audio controller 1836, a firmware hub (flash BIOS) 1828, a wireless transceiver 1826, data storage 1824, a legacy I / O controller 1840 including a user input and keyboard interface 1842, a serial expansion port 1838 such as a universal serial bus (USB), and a network controller 1834. The data storage 1824 may include a hard disk drive, a floppy disk drive, a CD-ROM drive, a flash memory device, or other mass storage device.

[0116] Referring now to Figure 19, a block diagram of a second system 1900 according to an embodiment of the present disclosure is shown. As shown in Figure 19, the multiprocessor system 1900 is a point-to-point interconnect system and includes a first processor 1970 and a second processor 1980 coupled via a point-to-point interconnect 1950. Each of the processors 1970 and 1980 may be some version of a processor. In one embodiment, 1952 and 1954 are part of a serial, point-to-point coherent interconnect fabric, such as a high performance architecture.

[0117] Although shown with only two processors 1970, 1980, it should be understood that the scope of the present disclosure is not so limited. In other embodiments, one or more additional processors may be present within a given processor.

[0118] Processors 1970 and 1980 are shown including integrated memory controller units 1972 and 1982, respectively. Processor 1970 also includes point-to-point (PP) interfaces 1976 and 1978 as part of its bus controller unit, and similarly, second processor 1980 includes PP interfaces 1986 and 1988. Processors 1970, 1980 may exchange information over point-to-point interface 1950 using PP interface circuits 1978, 1988. As shown in FIG. 19, IMCs 1972 and 1982 couple the processors to respective memories, i.e., memory 1932 and memory 1934, which may be part of a main memory locally attached to the respective processors.

[0119] The processors 1970, 1980 each exchange information with a chipset 1990 via respective PP interfaces 1952, 1954 using point-to-point interface circuits 1976, 1994, 1986, 1998. The chipset 1990 also exchanges information with a high performance graphics circuit 1938 via an interface circuit 1992 along a high performance graphics interconnect 1939.

[0120] A shared cache (not shown) may be included either external to the processor or to both processors, but connected to the processors via the PP interconnect, and local cache information of either or both processors may be stored in the shared cache when the processors are placed in a low power mode.

[0121] Chipset 1990 may be coupled to a first bus 1916 via an interface 1996. In one embodiment, first bus 1916 may be a bus such as a Peripheral Component Interconnect (PCI) bus, or a PCI Express bus or other third generation I / O interconnect bus, although the scope of the disclosure is not limited thereto.

[0122] As shown in FIG. 19, various I / O devices 1914 are coupled to a first bus 1916 along with a bus bridge 1918 that couples the first bus 1916 to a second bus 1920. In one embodiment, the second bus 1920 includes a low pin count (LPC) bus. For example, in one embodiment, various devices are coupled to the second bus 1920 including a keyboard and / or mouse 1922, a communication device 1927, and a storage unit 1928 such as a disk drive or other mass storage device that often contains instructions / code and data 1930. Additionally, audio I / O 1924 is shown coupled to the second bus 1920. It should be noted that other architectures are possible and the included components and interconnection architectures vary. For example, instead of the point-to-point architecture of FIG. 19, a system may implement a multi-drop bus or other such architectures.

[0123] Referring now to Figure 20, one embodiment of a system on chip (SOC) design according to the above disclosure is shown. As a specific example, the SOC 2000 is included in a user equipment (UE). In one embodiment, the UE refers to any device used by an end user to communicate, such as a handheld phone, a smart phone, a tablet, an ultra-thin notebook, a notebook with a broadband adapter, or other similar communication device. The UE often connects to a base station or node, which may essentially correspond to a mobile station (MS) in a GSM network.

[0124] Here, SOC 2000 includes two cores, 2006 and 2007. Similar to the above description, cores 2006 and 2007 may conform to an instruction set architecture such as an Intel® Architecture Core™ based processor, an Advanced Micro Devices, Inc. (AMD) processor, a MIPS based processor, an ARM based processor design, or customers thereof, as well as their licensees or adapters. Cores 2006 and 2007 are coupled to a bus interface unit 2009 and a cache control 2008 associated with an L2 cache 2011 for communicating with other parts of system 2000. Interconnect 2010 includes an on-chip interconnect, such as an IOSF, AMBA, or other interconnect as described above, potentially implementing one or more aspects described herein.

[0125] The interface 2010 provides communication channels to other components such as a subscriber identity module (SIM) 2030 for interfacing with a SIM card, a boot ROM 2035 that holds boot code for execution by the cores 2006 and 2007 to initialize and boot the SOC 2000, an SDRAM controller 2040 for interfacing with external memory (e.g., DRAM 2060), a flash controller 2045 for interfacing with non-volatile memory (e.g., flash 2065), a peripheral controller 2050 (e.g., a serial peripheral interface) for interfacing with peripherals, a video codec 2020 and video interface 2025 for displaying and receiving input (e.g., touch-enabled input), a GPU 2015 for performing graphics-related calculations, etc. Any of these interfaces may incorporate aspects of the embodiments described herein.

[0126] Additionally, the system shows peripherals for communication such as a Bluetooth module 2070, a 3G modem 2075, a GPS 2085, and a WiFi 2085. Note that, as noted above, the UE includes radios for communication. As a result, not all of these peripheral communication modules are required. However, in the UE, some form of radio for external communication will be included.

[0127] While the present disclosure has been described with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom, and it is intended that the appended claims cover all such modifications and variations that fall within the true spirit and scope of the present disclosure.

[0128] A design may go through various stages from creation to simulation to fabrication. Data representing the design may represent the design in multiple ways. First, the hardware may be represented using a hardware description language or other functional description language, as is useful in simulation. Additionally, a circuit level model with logic and / or transistor gates may be generated at some stages of the design process. Additionally, most designs reach at some stage a level of data representing the physical placement of various devices in the hardware model. If conventional semiconductor fabrication techniques are used, the data representing the hardware model may be data specifying the presence or absence of various features on different mask layers for the masks used to fabricate the integrated circuit. In any representation of a design, the data may be stored in any form of machine-readable medium. Magnetic or optical storage devices such as memory or disks may be machine-readable media that store information transmitted via light waves or electric waves modulated or generated to transmit such information. When an electrical carrier wave representing or carrying a code or design is transmitted, a new copy is made depending on the extent to which copying, buffering, or retransmission of the electrical signal is performed. Thus, a communications provider or network provider may store, at least temporarily, an article, such as information encoded in a carrier wave, embodying the techniques of embodiments of the present disclosure on a tangible, machine-readable medium.

[0129] A module, as used herein, refers to any combination of hardware, software, and / or firmware. As an example, a module includes hardware, such as a microcontroller, associated with a non-transitory medium for storing code adapted to be executed by the microcontroller. Thus, in one embodiment, reference to a module refers to hardware that is specifically configured to recognize and / or execute code to be held on the non-transitory medium. Furthermore, in another embodiment, use of a module refers to a non-transitory medium containing code, which is specifically adapted to be executed by a microcontroller to perform a predetermined operation. Also, as can be inferred, in yet another embodiment, the term module (in this example) may refer to a combination of a microcontroller and a non-transitory medium. Module boundaries, often depicted as separate, typically vary and may overlap. For example, a first and second module may share hardware, software, firmware, or a combination thereof, while potentially holding some independent hardware, software, or firmware. In one embodiment, use of the term logic includes hardware such as transistors, registers, or other hardware such as programmable logic devices.

[0130] In one embodiment, use of the phrase "configured" refers to arranging, assembling, manufacturing, offering for sale, importing, and / or designing an apparatus, hardware, logic, or element to perform a specified or determined task. In this example, an inoperative apparatus or element thereof is "configured" to perform a specified task when it is designed, coupled, and / or interconnected to perform the specified task. As a purely illustrative example, a logic gate may provide a 0 or a 1 during operation. However, a logic gate "configured" to provide an enable signal to a clock does not include all potential logic gates that may provide a 1 or a 0. Instead, the logic gate is one that is coupled in some manner such that a 1 or 0 output enables a clock during operation. Again, use of the term "configured" does not require operation, but instead focuses on the latent state of the apparatus, hardware, and / or element, in which the apparatus, hardware, and / or element is designed to perform a particular task when the apparatus, hardware, and / or element is operational.

[0131] Furthermore, in one embodiment, the use of the phrases "to," "can," and / or "operable to" refers to some apparatus, logic, hardware, and / or elements that are designed to enable use of the apparatus, logic, hardware, and / or elements in a particular manner. As noted above, in one embodiment, the use of can, can, or operable to refers to the latent state of the apparatus, logic, hardware, and / or elements, where the apparatus, logic, hardware, and / or elements are not operating but are designed in such a way as to enable use of the apparatus in a particular manner.

[0132] Value, as used herein, includes any known representation of a number, state, logical state, or binary logical state. Often the use of logic levels, logic values, or logical values, also referred to as 1 and 0, simply represents a binary logical state. For example, a 1 indicates a high logic level and a 0 indicates a low logic level. In one embodiment, a storage cell, such as a transistor or flash cell, can hold a single logical value or multiple logical values. However, other representations of values ​​in computer systems have been used. For example, the decimal number 10 may be represented as a binary value of 1010 and the letter A in hexadecimal. Thus, a value includes a representation of information that can be held in a computer system.

[0133] Additionally, a state may be represented by a value or a portion of a value. As an example, a first value, such as a logical one, may represent a default or initial state, and a second value, such as a logical zero, may represent a non-default state. Additionally, the terms reset and set, in one embodiment, refer to default and updated values ​​or states, respectively. For example, a default value potentially includes a high logical value, i.e., reset, while an updated value potentially includes a low logical value, i.e., set. It should be noted that any combination of values ​​may be used to represent any number of states.

[0134] The above method, hardware, software, firmware or code embodiments may be implemented by instructions or codes stored on a machine-accessible, machine-readable, computer-accessible or computer-readable medium executable by a processing element. A non-transitory machine-accessible / readable medium includes any mechanism that provides (i.e., stores and / or transmits) information in a form readable by a machine, such as a computer or electronic system. For example, a non-transitory machine-accessible medium includes random access memory such as static RAM (SRAM) or dynamic RAM (DRAM), ROM, magnetic or optical storage media, flash memory devices, electrical storage devices, optical storage devices, acoustic storage devices, other forms of storage devices for holding information received from a transitory (propagating) signal (e.g., carrier wave, infrared signal, digital signal), and the like, which should be distinguished from a non-transitory medium from which information can be received.

[0135] The instructions used to program the logic to execute the embodiments of the present disclosure may be stored in a memory in the system, such as a DRAM, cache, flash memory, or other storage. Additionally, the instructions may be distributed over a network or over other computer-readable media. Thus, a machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer), including, but not limited to, a floppy diskette, an optical disk, a compact disk, a read-only memory (CD-ROM), and a magneto-optical disk, a read-only memory (ROM), a random access memory (RAM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic or optical card, a flash memory, or a tangible machine-readable storage used in transmitting information over the Internet via an electrical, optical, acoustic, or other form of propagated signal (e.g., carrier wave, infrared signal, digital signal, etc.). Thus, a computer-readable medium includes any type of tangible machine-readable medium suitable for storing or transmitting electronic instructions or information in a form readable by a machine (e.g., a computer).

[0136] The following examples relate to embodiments according to the present specification. Example 1 is an apparatus including a protocol circuit that implements a load / store interconnect protocol and an interface circuit that implements an interface for coupling to a fabric, the interface including a header channel implemented on a first subset of a plurality of physical lanes, the first subset of lanes including a first lane for carrying a header of a packet based on the interconnect protocol and a second lane for carrying metadata of the header, and a data channel implemented on another second subset of the plurality of physical lanes, the second subset of lanes including a third lane for carrying a payload of the packet and a fourth lane for carrying metadata of the payload.

[0137] Example 2 includes the subject matter of Example 1, where the header is transmitted over the header channel in a single clock cycle and the payload can be transmitted over multiple clock cycles.

[0138] Example 3 includes the subject matter of example 2, wherein the first subset of lanes further includes a fifth lane for carrying another header of another packet on the header channel and a sixth lane for carrying metadata for the another header, wherein the header and the another channel are transmitted together in a single clock cycle on the header channel.

[0139] Example 4 includes the subject matter of Example 3, except that in a subsequent clock cycle, both the first and fifth lanes are used to carry a third header of a third packet, the size of the third header being larger than the first header and the other headers.

[0140] Example 5 includes the subject matter of any one of Examples 1-4, wherein the header channel further includes a header valid signal in one of the first subset of lanes to identify valid header data for the first lane, and the data channel further includes a data valid signal in one of the second subset of lanes to identify valid payload data for the third lane.

[0141] Example 6 includes the subject matter of example 5, wherein the header valid signal further identifies valid metadata on the second lane and the data valid signal further identifies valid metadata on a fourth lane.

[0142] Example 7 includes the subject matter of any one of Examples 1-6, wherein the second subset of lanes further includes a fifth lane carrying a start of data signal to indicate a start of payload on the data channel, the start of data signal being asserted at a particular clock cycle to identify a first portion of the third lane used at that particular clock cycle to carry a start of payload bytes.

[0143] Example 8 includes the subject matter of Example 7, wherein the second subset of lanes further includes a sixth lane carrying an end of data signal to indicate a final byte of the payload on the data channel, the end of data signal being asserted in a subsequent clock cycle to identify a second portion of the third lane used in the subsequent clock cycle to carry the final byte of the payload.

[0144] Example 9 includes the subject matter of any one of Examples 1-8, wherein the first subset of lanes further includes a fifth lane for carrying a credit return of the header channel, and the second subset of lanes further includes a sixth lane for carrying a credit return of the data channel.

[0145] Example 10 includes the subject matter of example 9, wherein one of the header channel credits and the data channel credits comprises a shared credit.

[0146] Example 11 includes the subject matter of any one of Examples 1-10, wherein the header metadata and the payload metadata each identify flow control information for the packet.

[0147] Example 12 includes the subject matter of example 11, wherein the flow control information is inherent to a packet on the interface during transmission of the payload and headers on the interface.

[0148] Example 13 includes the subject matter of example 12, wherein the flow control information includes a combination of a virtual channel identifier and a flow control class identifier for the packet.

[0149] Example 14 includes the subject matter of example 13, wherein the interface defines a maximum number of different flow control class identifier-virtual channel identifier combinations for packets transmitted on the interface during a given clock cycle.

[0150] Example 15 includes the subject matter of any one of Examples 11-14, wherein the metadata of the header further includes parity information, header size information, and indicates whether payload data is associated with the header.

[0151] Example 16 includes the subject matter of any of Examples 1-15, wherein the interface further includes a global channel implemented on a third subset of the plurality of physical lanes, the global channel carrying control signals for the interface.

[0152] Example 17 includes the subject matter of example 16, wherein the control signals include a set of initialization signals for use in interface connection and disconnection flows.

[0153] Example 18 includes the subject matter of example 17, where the connect and disconnect flow follows an initialization state machine, and transitions between states defined in the initialization state machine are triggered by set values ​​of an initialization signal.

[0154] Example 19 includes the subject matter of any one of examples 1-18, wherein multiple headers are conveyed on the header channel before completing transmission of the payload.

[0155] Example 20 includes the subject matter of any one of Examples 1-19, wherein the interface includes a first instance of an interface for transmitting packets to the fabric, and the device further includes a second instance of an interface for receiving packets from the fabric, the second instance of the interface including a second header channel and a second data channel.

[0156] Example 21 includes the subject matter of example 20, further including a memory for implementing a receiver buffer for the second instance of the interface, the receiver buffer supporting credit sharing between flow control classes or virtual channels.

[0157] Example 22 includes the subject matter of any one of Examples 1-21, wherein the load / store interconnect protocol includes a Peripheral Component Interconnect Express (PCIe) protocol.

[0158] Example 23 includes the subject matter of example 22, wherein the PCIe protocol includes PCIe Generation 6.

[0159] Example 24 includes the subject matter of any one of Examples 1-23, wherein the load / store interconnect protocol includes a Compute Express Link (CXL) protocol, and the CXL protocol includes CXL.io.

[0160] Example 25 includes the subject matter of any one of Examples 1-24, wherein the fabric includes an interconnect fabric of a system-on-chip (SoC) device, the apparatus further including computational circuitry implementing a block of the SoC.

[0161] Example 26 is an apparatus including a fabric circuit that implements at least a portion of an interconnect fabric of a system and an interface circuit that implements an interface for coupling to a computing device, the interface including: a header channel implemented on a first subset of a plurality of physical lanes, the first subset of lanes including a first lane that carries a header of a packet based on an interconnect protocol and a second lane that carries metadata for the header; and a data channel implemented on another second subset of the plurality of physical lanes, the second subset of lanes including a third lane that carries a payload of a packet based on an interconnect protocol and a fourth lane that carries metadata for the payload.

[0162] Example 27 includes the subject matter of example 26, wherein the header is transmitted over the header channel in a single clock cycle and the payload can be transmitted over multiple clock cycles.

[0163] Example 28 includes the subject matter of Example 27, wherein the first subset of lanes further includes a fifth lane for carrying another header of another packet on the header channel and a sixth lane for carrying metadata for the other header, wherein the header and the other channel are transmitted together in a single clock cycle on the header channel.

[0164] Example 29 includes the subject matter of Example 28, except that in a subsequent clock cycle, both the first and fifth lanes are used to carry a third header of a third packet, the size of the third header being larger than the header and the other headers.

[0165] Example 30 includes the subject matter of any one of Examples 26-29, wherein the header channel further includes a header valid signal on one of the first subset of lanes to identify valid header data for the first lane, and the data channel further includes a data valid signal on one of the second subset of lanes to identify valid payload data for the third lane.

[0166] Example 31 includes the subject matter of example 30, wherein the header valid signal further identifies valid metadata on the second lane and the data valid signal further identifies valid metadata on the fourth lane.

[0167] Example 32 includes the subject matter of any one of Examples 26-31, wherein the second subset of lanes further includes a fifth lane carrying a start of data signal to indicate a start of payload on the data channel, the start of data signal being asserted at a particular clock cycle to identify a first portion of a third lane used at that clock cycle to carry a start of a payload byte.

[0168] Example 33 includes the subject matter of Example 32, wherein the second subset of lanes further includes a sixth lane carrying an end of data signal to indicate a final byte of the payload on the data channel, the end of data signal being asserted in a subsequent clock cycle to identify a second portion of the third lane used in the subsequent clock cycle to carry the final byte of the payload.

[0169] Example 34 includes the subject matter of any one of Examples 26-33, wherein the first subset of lanes further includes a fifth lane for carrying a credit return of the header channel, and the second subset of lanes further includes a sixth lane for carrying a credit return of the data channel.

[0170] Example 35 includes the subject matter of example 34, wherein one of the header channel credits and the data channel credits comprises a shared credit.

[0171] Example 36 includes the subject matter of any one of Examples 26-35, wherein the header metadata and the payload metadata each identify flow control information for the packet.

[0172] Example 37 includes the subject matter of example 36, wherein the flow control information is specific to a packet on the interface during transmission of the payload and headers on the interface.

[0173] Example 38 includes the subject matter of example 37, wherein the flow control information includes a combination of a virtual channel identifier and a flow control class identifier for the packet.

[0174] Example 39 includes the subject matter of example 38, wherein the interface defines a maximum number of different flow control class identifier-virtual channel identifier combinations for packets transmitted on the interface during a given clock cycle.

[0175] Example 40 includes the subject matter of any one of Examples 36-39, wherein the metadata of the header further includes parity information, header size information, and indicates whether payload data is associated with the header.

[0176] Example 41 includes the subject matter of any one of Examples 26-40, wherein the interface further includes a global channel implemented on a third subset of the plurality of physical lanes, the global channel carrying control signals for the interface.

[0177] Example 42 includes the subject matter of example 41, wherein the control signals include a set of initialization signals for use in interface connection and disconnection flows.

[0178] Example 43 includes the subject matter of example 42, where the connect and disconnect flow follows an initialization state machine, and transitions between states defined in the initialization state machine are triggered by set values ​​of an initialization signal.

[0179] Example 44 includes the subject matter of any one of Examples 26-43, wherein multiple headers are conveyed on the header channel before completing transmission of the payload.

[0180] Example 45 includes the subject matter of any one of Examples 26-44, wherein the interface includes a first instance of an interface for transmitting packets to the fabric, and the device further includes a second instance of an interface for receiving packets from the fabric, the second instance of the interface including a second header channel and a second data channel.

[0181] Example 46 includes the subject matter of Example 45, further including a memory for implementing a receiver buffer for the second instance of the interface, the receiver buffer supporting credit sharing between flow control classes or virtual channels.

[0182] Example 47 includes the subject matter of any one of Examples 26-46, wherein the load / store interconnect protocol includes a Peripheral Component Interconnect Express (PCIe) protocol.

[0183] Example 48 includes the subject matter of example 47, wherein the PCIe protocol includes PCIe Generation 6.

[0184] Example 49 includes the subject matter of any one of Examples 26-48, wherein the load / store interconnect protocol includes a Compute Express Link (CXL) protocol, and the CXL protocol includes CXL.io.

[0185] Example 50 includes the subject matter of any one of Examples 26-49, wherein the system includes a system-on-chip (SoC) device and the computing device includes a block of the SoC device.

[0186] Example 51 is a method including: receiving a header of a packet from a device via an interface, the interface including a header channel implemented on a first plurality of physical lanes and a data channel implemented on another second plurality of physical lanes, the header being received on a first subset of the first plurality of lanes; receiving header metadata for the header on a second subset of the first plurality of lanes of the header channel; receiving payload data of the packet from the device on a data channel of the interface, the payload data being received on the first subset of the second plurality of lanes; receiving payload metadata for the payload data on the second subset of the second plurality of lanes; and determining that the payload data is associated with the header based on the header metadata and the payload metadata.

[0187] Example 52 includes the subject matter of Example 51, further including decoding the header based on the header metadata.

[0188] Example 53 includes the subject matter of any one of Examples 51-52, and further includes the steps of: transmitting a header credit return to the device on a third subset of the first plurality of lanes, where the header credit return includes a header channel credit return; and transmitting a data credit return to the device on a third subset of the second plurality of lanes, where the data credit return includes a data channel credit return.

[0189] Example 54 includes the subject matter of example 53, wherein one of the header credit return or the data credit return includes a shared credit.

[0190] Example 55 includes the subject matter of any one of Examples 51-54, wherein the header includes a first header of a first packet, the first header being received from the device over the data channel at the particular clock cycle, and the method further includes receiving a second header of a second packet over the first plurality of lanes at the particular clock cycle.

[0191] Example 56 includes the subject matter of Example 55, and further includes receiving header metadata for a second packet on a third subset of the first plurality of lanes, where the header metadata for the first and second headers are both received at a particular clock cycle.

[0192] Example 57 includes the subject matter of Example 55, and further includes receiving, in a subsequent clock cycle, a third header for a third packet, the third header being carried on the lanes used to carry the first header and on a portion of the lanes used to carry the second header.

[0193] Example 58 includes the subject matter of any one of Examples 51-57, and further includes identifying an assertion of a header valid signal on a valid signal lane of the first plurality of lanes, where the header valid signal identifies that valid header data is sent on a first subset of the first plurality of lanes; and identifying an assertion of a data valid signal on a valid signal lane of the second plurality of lanes, where the data valid signal identifies that valid payload data is sent on the first subset of the second plurality of lanes.

[0194] Example 59 includes the subject matter of Example 58, wherein the header valid signal further identifies valid metadata on a second subset of the first plurality of lanes and the data valid signal further identifies valid metadata on a second subset of the second plurality of lanes.

[0195] Example 60 includes the subject matter of any one of Examples 51-59, further including receiving a start of data signal on a third subset of the second plurality of lanes implementing the data channel, the start of data signal indicating a start of payload on the data channel, the start of data signal being asserted at a particular clock cycle to identify a first portion of a first subset of the second plurality of lanes used at that particular clock cycle to carry a start of payload bytes.

[0196] Example 61 includes the subject matter of Example 60, and further includes receiving a termination of the data signal on a fourth subset of the second plurality of lanes implementing the data channel, the termination of the data signal being asserted in a subsequent clock cycle to identify a corresponding portion of the first subset of the second plurality of lanes used in the subsequent clock cycle to carry a final byte of the payload.

[0197] Example 62 includes the subject matter of any one of Examples 51-61, wherein each of the header metadata and the data metadata identifies flow control information for the packet.

[0198] Example 63 includes the subject matter of example 62, wherein the flow control information is specific to a packet on the interface during transmission of the payload and headers on the interface.

[0199] Example 64 includes the subject matter of example 63, wherein the flow control information includes a combination of a virtual channel identifier and a flow control class identifier for the packet.

[0200] Example 65 includes the subject matter of example 64, wherein the interface defines a maximum number of different flow control class identifier-virtual channel identifier combinations for packets transmitted on the interface during a given clock cycle.

[0201] Example 66 includes the subject matter of any one of Examples 62-64, wherein the metadata of the header further includes parity information, header size information, and indicates whether payload data is associated with the header.

[0202] Example 67 includes the subject matter of any one of Examples 51-66, wherein the interface further includes a global channel implemented using a third plurality of physical lanes, and the method further includes communicating with the device over the global channel to perform an initialization or disconnection flow of the interface.

[0203] Example 68 includes the subject matter of Example 67 and defines a set of control signals in which the global channel is mapped to a third plurality of physical lanes.

[0204] Example 69 includes the subject matter of Example 68, wherein the set of control signals includes a set of initialization signals for use in initialization and shutdown flows in accordance with an initialization state machine, and transitions between states defined in the initialization state machine are triggered by values ​​of the set of initialization signals.

[0205] Example 70 includes the subject matter of any one of Examples 51-69, further including processing the header before receipt of the payload is completed on the data channel.

[0206] Example 71 includes the subject matter of any one of Examples 51-70, further including maintaining a receiver buffer for credits used on the interface.

[0207] Example 72 includes the subject matter of any one of Examples 51-71, wherein the packets are based on a Peripheral Component Interconnect Express (PCIe) protocol.

[0208] Example 73 includes the subject matter of example 72, wherein the PCIe protocol includes PCIe Generation 6.

[0209] Example 74 includes the subject matter of any one of Examples 51-73, wherein the packets are based on a Compute Express Link (CXL) protocol, and the CXL protocol includes CXL.io.

[0210] Example 75 includes the subject matter of any one of Examples 51-74, wherein the device implements at least a portion of an interconnect fabric of a system-on-chip (SoC) device, and the interface couples the agent to the interconnect fabric of the SoC device.

[0211] Example 76 includes the subject matter of any one of Examples 51-75, wherein the device implements a computational block of a SoC device, and the interface couples the computational block to a fabric of the SoC device.

[0212] Example 77 is a system including a means for performing the method of any one of Examples 51 to 76.

[0213] Example 78 includes the subject matter of example 77, wherein the means includes a hardware circuit.

[0214] Example 79 includes the subject matter of any one of Examples 77-78, wherein the means includes a non-transitory machine-readable storage medium having instructions stored thereon, the instructions being executable by a processor to cause the processor to perform at least a portion of the method of any one of Examples 51-76.

[0215] Example 80 is a method including: identifying a packet to be transmitted to a device over an interface; transmitting a header of the packet to the device over a header channel of the interface, the header channel being implemented using a first plurality of physical lanes, the header being transmitted on a first subset of the first plurality of physical lanes; transmitting header metadata of the header to the device on a second subset of the first plurality of lanes of the header channel; transmitting payload data of the packet to the device on a data channel of the interface, the data channel being implemented using another second plurality of physical lanes, the payload data being received on the first subset of the second plurality of lanes; and transmitting payload metadata of the payload data to the device on the second subset of the second plurality of lanes.

[0216] Example 81 includes the subject matter of Example 80, and further includes: receiving a header credit return from the device on a third subset of the first plurality of lanes, where the header credit return includes a header channel credit return; and receiving a data credit return from the device on a third subset of the second plurality of lanes, where the data credit return includes a data channel credit return.

[0217] Example 82 includes the subject matter of example 81, wherein one of the header credit return or the data credit return includes a shared credit.

[0218] Example 83 includes the subject matter of any one of Examples 80-82, wherein the header includes a first header of a first packet, the first header being transmitted at a particular clock cycle, and the method further includes transmitting a second header of a second packet on the first plurality of lanes at the particular clock cycle.

[0219] Example 84 includes the subject matter of Example 83, and further includes transmitting header metadata for a second packet on a third subset of the first plurality of lanes, where the header metadata for the first and second headers are both transmitted in a particular clock cycle.

[0220] Example 85 includes the subject matter of Example 83, and further includes, in a subsequent clock cycle, transmitting a third header of a third packet to the device over the data channel, the third header being carried on a portion of the lanes used to carry the first header and the lanes used to carry the second header.

[0221] Example 86 includes the subject matter of any one of Examples 80-85, and further includes the steps of: asserting a header valid signal on a valid signal lane of the first plurality of lanes, where the header valid signal identifies that valid header data is transmitted on a first subset of the first plurality of lanes; and asserting a data valid signal on a valid signal lane of the second plurality of lanes, where the data valid signal identifies that valid payload data is transmitted on the first subset of the second plurality of lanes.

[0222] Example 87 includes the subject matter of Example 86, wherein the header valid signal further identifies valid metadata on a second subset of the first plurality of lanes and the data valid signal further identifies valid metadata on a second subset of the second plurality of lanes.

[0223] Example 88 includes the subject matter of any one of Examples 80-87, further including transmitting a start of data signal on a third subset of the second plurality of lanes implementing the data channel, the start of data signal indicating a start of payload on the data channel, the start of data signal being transmitted at the particular clock cycle to identify a first portion of a first subset of the second plurality of lanes used at the particular clock cycle to carry a start of payload bytes.

[0224] Example 89 includes the subject matter of Example 88, and further includes transmitting a termination of the data signal on a fourth subset of the second plurality of lanes implementing the data channel, the termination of the data signal being transmitted in a subsequent clock cycle to identify a corresponding portion of the first subset of the second plurality of lanes that is used in the subsequent clock cycle to carry a final byte of the payload.

[0225] Example 90 includes the subject matter of any one of Examples 80-89, wherein each of the header metadata and the data metadata identifies flow control information for the packet.

[0226] Example 91 includes the subject matter of example 90, wherein the flow control information is specific to a packet on the interface during transmission of the payload and headers on the interface.

[0227] Example 92 includes the subject matter of example 91, wherein the flow control information includes a combination of a virtual channel identifier and a flow control class identifier for the packet.

[0228] Example 93 includes the subject matter of example 92, wherein the interface defines a maximum number of different flow control class identifier-virtual channel identifier combinations for packets transmitted on the interface during a given clock cycle.

[0229] Example 94 includes the subject matter of any one of Examples 90-93, wherein the metadata of the header further includes parity information, header size information, and indicates whether payload data is associated with the header.

[0230] Example 95 includes the subject matter of any one of Examples 80-94, wherein the interface further includes a global channel implemented using a third plurality of physical lanes, and the method further includes communicating with the device over the global channel to perform an initialization or disconnection flow of the interface.

[0231] Example 96 includes the subject matter of example 95, wherein the global channel defines a set of control signals that are mapped to a third plurality of physical lanes.

[0232] Example 97 includes the subject matter of Example 96, wherein the set of control signals includes a set of initialization signals for use in initialization and shutdown flows in accordance with an initialization state machine, and transitions between states defined in the initialization state machine are triggered by values ​​of the set of initialization signals.

[0233] Example 98 includes the subject matter of any one of Examples 80-97, wherein the packets are based on a Peripheral Component Interconnect Express (PCIe) protocol.

[0234] Example 99 includes the subject matter of example 98, wherein the PCIe protocol includes PCIe Generation 6.

[0235] Example 100 includes the subject matter of any one of Examples 80-99, wherein the packets are based on a Compute Express Link (CXL) protocol, and the CXL protocol includes CXL.io.

[0236] Example 101 includes the subject matter of any one of Examples 80-100, wherein the device implements at least a portion of an interconnect fabric of a system-on-chip (SoC) device, and the interface couples the agent to the interconnect fabric of the SoC device.

[0237] Example 102 includes the subject matter of any one of Examples 80-101, where the device implements a computational block of a SoC device and the interface couples the computational block to a fabric of the SoC device.

[0238] Example 103 is a system including means for performing the method of any one of Examples 80-102.

[0239] Example 104 includes the subject matter of example 103, wherein the means includes a hardware circuit.

[0240] Example 105 includes the subject matter of any one of Examples 103-104, and a means includes a non-transitory machine-readable storage medium having instructions stored thereon, the instructions being executable by a processor to cause the processor to perform at least a portion of the method of any one of Examples 80-102.

[0241] Example 106 is a system including: a fabric; and a plurality of compute blocks communicatively coupled via the fabric, wherein a particular compute block within the plurality of compute blocks includes: an agent circuit supporting a load / store interconnect protocol; and an interface circuit implementing an interface for coupling to the fabric, the interface including: a header channel implemented on a first subset of a plurality of physical lanes, the first subset of lanes including a first lane that carries a packet header based on the interconnect protocol and a second lane that carries metadata for the header; and a data channel implemented on another second subset of the plurality of physical lanes, the second subset of lanes including a third lane that carries a packet payload and a fourth lane that carries metadata for the payload.

[0242] Example 107 includes the subject matter of example 106, where the header is transmitted over the header channel in a single clock cycle and the payload can be transmitted over multiple clock cycles.

[0243] Example 108 includes the subject matter of Example 107, wherein the first subset of lanes further includes a fifth lane carrying another header of another packet on the header channel and a sixth lane carrying metadata of the other header, wherein the header and the other channel are transmitted together in a single clock cycle on the header channel.

[0244] Example 109 includes the subject matter of example 108, except that in a subsequent clock cycle, both the first and fifth lanes are used to carry a third header of a third packet, the size of the third header being larger than the header and the other headers.

[0245] Example 110 includes the subject matter of any one of Examples 106-109, wherein the header channel further includes a header valid signal on one of the first subset of lanes to identify valid header data for the first lane, and the data channel further includes a data valid signal on one of the second subset of lanes to identify valid payload data for the third lane.

[0246] Example 111 includes the subject matter of example 110, where the header valid signal further identifies valid metadata on the second lane and the data valid signal further identifies valid metadata on the fourth lane.

[0247] Example 112 includes the subject matter of any one of Examples 106-111, wherein the second subset of lanes further includes a fifth lane carrying a start of data signal indicating a start of payload on the data channel, the start of data signal being asserted at a particular clock cycle to identify a first portion of a third lane used at that particular clock cycle to carry a start of payload bytes.

[0248] Example 113 includes the subject matter of Example 112, wherein the second subset of lanes further includes a sixth lane carrying an end of data signal to indicate a final byte of the payload on the data channel, the end of data signal being asserted in a subsequent clock cycle to identify a second portion of the third lane used in the subsequent clock cycle to carry the final byte of the payload.

[0249] Example 114 includes the subject matter of any one of Examples 106-112, wherein the first subset of lanes further includes a fifth lane for carrying a credit return of the header channel, and the second subset of lanes further includes a sixth lane for carrying a credit return of the data channel.

[0250] Example 115 includes the subject matter of example 114, wherein one of the header channel credits and the data channel credits comprises a shared credit.

[0251] Example 116 includes the subject matter of any one of Examples 106-115, wherein the header metadata and the payload metadata each identify flow control information for the packet.

[0252] Example 117 includes the subject matter of example 116, where the flow control information is inherent to a packet on the interface during transmission of the payload and headers on the interface.

[0253] Example 118 includes the subject matter of example 117, wherein the flow control information includes a combination of a virtual channel identifier and a flow control class identifier for the packet.

[0254] Example 119 includes the subject matter of example 118, wherein the interface defines a maximum number of different flow control class identifier-virtual channel identifier combinations for packets transmitted on the interface during a given clock cycle.

[0255] Example 120 includes the subject matter of any one of Examples 116-119, wherein the metadata of the header further includes parity information, header size information, and indicates whether payload data is associated with the header.

[0256] Example 121 includes the subject matter of any one of Examples 106-120, wherein the interface further includes a global channel implemented on a third subset of the plurality of physical lanes, the global channel carrying control signals for the interface.

[0257] Example 122 includes the subject matter of example 121, wherein the control signals include a set of initialization signals for use in interface connection and disconnection flows.

[0258] Example 123 includes the subject matter of example 122, where the connect and disconnect flow follows an initialization state machine, and transitions between states defined in the initialization state machine are triggered by set values ​​of an initialization signal.

[0259] Example 124 includes the subject matter of any one of Examples 106-123, wherein multiple headers are maintained on the header channel before completing transmission of the payload.

[0260] Example 125 includes the subject matter of any one of Examples 106-124, wherein the interface includes a first instance of an interface for transmitting packets to the fabric, and the system further includes a second instance of an interface for receiving packets from the fabric, the second instance of the interface including a second header channel and a second data channel.

[0261] Example 126 includes the subject matter of Example 125, and further includes a memory for implementing a receiver buffer for the second instance of the interface, the receiver buffer supporting credit sharing between flow control classes or virtual channels.

[0262] Example 127 includes the subject matter of any one of Examples 106-126, wherein the load / store interconnect protocol includes a Peripheral Component Interconnect Express (PCIe) protocol.

[0263] Example 128 includes the subject matter of example 127, wherein the PCIe protocol includes PCIe Generation 6.

[0264] Example 129 includes the subject matter of any one of Examples 106 to 128, wherein the load / store interconnect protocol includes a Compute Express Link (CXL) protocol, and the CXL protocol includes CXL.io.

[0265] Example 130 includes the subject matter of any one of Examples 106-129, and further includes a system-on-chip (SoC) device, the SoC device including a fabric and a plurality of computational blocks.

[0266] Example 131 includes the subject matter of any one of Examples 106-130 and further includes a server.

[0267] References herein to "one embodiment" or "an embodiment" mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout the specification do not necessarily refer to the same embodiment. Furthermore, particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0268] In the foregoing specification, a detailed description has been given with reference to certain exemplary embodiments. However, it will be apparent that various modifications and changes can be made without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are therefore to be regarded in an illustrative rather than a restrictive sense. Moreover, the foregoing use of embodiment and other exemplary language does not necessarily refer to the same embodiment or identical example, but may refer to different separate and potentially identical embodiments.

Claims

1. a first circuit block having a streaming interface for mapping load / store protocols between the first circuit block and a second circuit block; The streaming interface: a header channel for transmitting a header of a packet of the load / store protocol, the header channel having a first lane for carrying the header, a second lane for carrying a first valid signal associated with the header channel, and a third lane for carrying credit return information of the header channel; a data channel for transmitting request data of the packet, the data channel having a fourth lane for carrying the request data, a fifth lane for carrying a second valid signal associated with the data channel, and a sixth lane for carrying credit return information for the data channel; a first circuit block; Device.

2. the first valid signal indicates the start of a new header of a new packet to be transmitted on the first lane, and the second valid signal indicates that requested data corresponding to at least one packet has been transmitted on the fourth lane.

2. The apparatus of claim 1.

3. a credit return for the header channel is made to a first credit pool including dedicated credits and shared credits for the header channel, and a credit return for the data channel is made to a first credit pool including dedicated credits and shared credits for the data channel.

2. The apparatus of claim 1.

4. the streaming interface further comprising a seventh lane for carrying header metadata for the header, the header metadata including header size, flow control, virtual channel, and parity information.

2. The apparatus of claim 1.

5. the streaming interface further comprising a global channel implemented in a seventh lane for carrying signals for use in initializing and shutting down the streaming interface.

2. The apparatus of claim 1.

6. one header is transmitted on the first lane in a single clock cycle; 2. The apparatus of claim 1.

7. a plurality of headers are transmitted on the first lane within a single clock cycle, the plurality of headers including the one header; 7. The apparatus of claim 6.

8. the streaming interface has a first streaming interface instance that transmits packets from the first circuit block to the second circuit block, and the device has a second streaming interface instance in the first circuit block that receives packets from the second circuit block, the second streaming interface instance including an instance of the header channel and the data channel; 2. The apparatus of claim 1.

9. The load / store protocol is based on a Peripheral Component Interconnect Express (PCIe) based protocol; 2. The apparatus of claim 1.

10. The load / store protocol is based on the Compute Express Link Input / Output (CXL.io) protocol; 2. The apparatus of claim 1.

11. identifying a set of packets to transmit on the interconnect; Transmitting the set of packets from an application layer block to a controller block over a streaming interface, the streaming interface having a header channel including a first set of lanes and a data channel including a second set of lanes, the step of transmitting the set of packets from the application layer block to the controller block comprising: transmitting a header valid signal on a header valid lane in the first set of lanes; transmitting a header of the set of packets on a header lane in the first set of lanes; transmitting header information on a header information lane in the first set of lanes; transmitting a data valid signal on a data valid lane in the second set of lanes; transmitting the requested data in the set of packets on data lanes in the second set of lanes. Steps and receiving credit return information associated with the header channel on a header credit return lane in the first set of lanes; receiving credit return information associated with the data channel on a data credit return lane in the second set of lanes; A method comprising:

12. the set of packets includes a plurality of packets, and a plurality of headers associated with the plurality of packets are transmitted on the header lane in a single clock cycle. The method of claim 11.

13. a first valid lane in the header valid lanes for indicating a first header of the plurality of headers, and a second valid lane in the header valid lanes for indicating a second header of the plurality of headers. The method of claim 12.

14. the set of packets includes transaction layer packets (TLPs) of a load / store protocol; The method of claim 11.

15. Fabric and; A computation block comprising: A protocol circuit supporting a load / store protocol; and an interface coupled to the fabric; A calculation block; The interface: a header channel for transmitting a header of a packet of the load / store protocol, the header channel having a first lane for carrying the header, a second lane for carrying a first valid signal associated with the header channel, and a third lane for carrying credit return information of the header channel; a data channel for transmitting request data of the packet, the data channel having a fourth lane for carrying the request data, a fifth lane for carrying a second valid signal associated with the data channel, and a sixth lane for carrying credit return information for the data channel; system.

16. a plurality of computing blocks, the fabric interconnecting the plurality of computing blocks within the system; The system of claim 15.

17. the system includes a system on chip (SoC), the SoC including the fabric and the plurality of computational blocks; 17. The system of claim 16.

18. The system includes a server.

17. The system of claim 16.

19. the interface has a first interface for transmitting data from the computation block to the fabric, the computation block further having a second interface for receiving data from the fabric, the second interface having respective header and data channels for packets transmitted from the fabric to the computation block; The system of claim 15.

20. The load / store protocol includes one of PCIe or CXL.io; The system of claim 15.

21. the interface having a global channel implemented in a seventh lane for carrying signals for use in initializing and shutting down the interface. The system of claim 15.

Images