STREAMING PROTOCOL FLOW CONTROL FOR DIE-TO-DIE INTERFACES

Provided are systems, methods, and apparatuses for streaming protocol flow control for die-to-die interfaces. In some examples, the systems, devices, and methods include allowing a first packet to be transmitted from a source to a destination based on a credit count; decrementing the credit count based on transmitting a flit of the first packet to the destination; and incrementing the credit count based on receiving a first return credit from the destination. In some examples, the systems, devices, and methods include receiving, at a destination from a source, a first return credit in a header flit of a first packet; incrementing a credit count based on receiving the first return credit from the source; allowing a second packet to be transmitted to the source based on the credit count; and decrementing the credit count based on transmitting a flit of the second packet to the source.

TECHNICAL FIELD

The disclosure relates generally to memory systems, and more particularly to streaming protocol flow control for die-to-die (D2D) interfaces.

BACKGROUND

The present background section is intended to provide context only, and the disclosure of any concept in this section does not constitute an admission that said concept is prior art.

Data communication includes the electronic transmission of information (e.g., encoded information) to, from, and/or between computing devices. A flow control mechanism can be implemented to avoid a sender overwhelming a receiver with data that the receiver is not ready to accept. Each outgoing segment can include an indication of the size of the available buffer space, and the sender may be configured to not send more data than the receiver can accommodate. However, in such systems, a receiver can be overwhelmed based on issues with system latency, etc., potentially resulting in data being dropped, which can decrease system performance. Accordingly, a need remains for systems and methods that improve network communication reliability.

SUMMARY

In various embodiments, the systems and methods described herein include systems, methods, and apparatuses for streaming protocol flow control for die-to-die interfaces. In some aspects, the systems and methods described herein relate to a . . . .

In some aspects, the techniques described herein relate to a method of die-to-die (D2D) credit-based flow control, the method including: allowing a first packet to be transmitted from a source to a destination based on a credit count; decrementing the credit count based on transmitting a flit of the first packet to the destination; and incrementing the credit count based on receiving a first return credit from the destination.

In some aspects, the techniques described herein relate to a method, further including transmitting, to the destination, a second return credit in a header flit of the first packet based on data being removed from a stack of a buffer at the source. In some aspects, the techniques described herein relate to a method, wherein: the first return credit includes an address read credit, an address write credit, or a write credit, and the second return credit includes a read credit or a write response credit.

In some aspects, the techniques described herein relate to a method, wherein a size of the buffer is based on a round-trip delay between the source and the destination. In some aspects, the techniques described herein relate to a method, wherein a size of the buffer is based on a bandwidth of the source, a bandwidth of the destination, or a bandwidth between the source and the destination.

In some aspects, the techniques described herein relate to a method, wherein the first return credit is received in a header flit of a second packet that the source receives from the destination. In some aspects, the techniques described herein relate to a method, wherein the first return credit is piggybacked on the second packet based on the second packet including at least one payload flit.

In some aspects, the techniques described herein relate to a method, wherein the second packet is received as a standalone message from the destination based on the second packet being configured without payload flits. In some aspects, the techniques described herein relate to a method, wherein transmission of return credits is synchronized to a clock cycle.

In some aspects, the techniques described herein relate to a method, wherein allowing the packet to be transmitted from the source to the destination is based on the credit count being non-zero.

In some aspects, the techniques described herein relate to a method, pausing transmission for at least one clock cycle based on a determination that the credit count is zero.

In some aspects, the techniques described herein relate to a method, wherein the credit count is maintained on a protocol layer of a die-to-die interconnect of the source.

In some aspects, the techniques described herein relate to a method, wherein the first packet includes a header flit, one or more payload flits, and a tail flit. In some aspects, the techniques described herein relate to a method, wherein the source includes a first D2D physical layer (PHY) that is communicatively linked to a second D2D PHY of the destination. In some aspects, the techniques described herein relate to a method, wherein the source includes a compute die and the destination includes a buffer die.

In some aspects, the techniques described herein relate to a method of die-to-die (D2D) credit-based flow control, the method including: receiving, at a destination from a source, a first return credit in a header flit of a first packet; incrementing a credit count based on receiving the first return credit from the source; allowing a second packet to be transmitted to the source based on the credit count; and decrementing the credit count based on transmitting a flit of the second packet to the source.

In some aspects, the techniques described herein relate to a method, further including transmitting, to the source, a second return credit in a header flit of the second packet based on data being removed from a stack of a buffer at the destination. In some aspects, the techniques described herein relate to a method, wherein: the first return credit includes a read credit or a write response credit, and the second return credit includes an address read credit, an address write credit, or a write credit.

In some aspects, the techniques described herein relate to a method, wherein the destination includes a buffer die and the source includes a compute die. In some aspects, the techniques described herein relate to a non-transitory computer-readable medium storing code that includes instructions executable by a processor of a die-to-die (D2D) credit-based flow control device to: allow a first packet to be transmitted from a source to a destination based on a credit count; decrement the credit count based on transmitting a flit of the first packet to the destination; and increment the credit count based on receiving a first return credit from the destination.

A computer-readable medium is disclosed. The computer-readable medium can store instructions that, when executed by a computer, cause the computer to perform substantially the same or similar operations as described herein are further disclosed. Similarly, non-transitory computer-readable media, devices, and systems for performing substantially the same or similar operations as described herein are further disclosed.

The systems and methods may be implemented in high-performance computing (HPC), artificial intelligence (AI) hardware systems, AI systems with high-bandwidth memory (HBM), memory systems with D2D interfaces (e.g., 3D HBM, 2.5D HBM). The systems and methods of streaming protocol flow control for die-to-die interfaces described herein include multiple advantages and benefits. For example, the systems and methods reduce the latency in cases where a source may be stalled waiting for response from a destination. Additionally, the systems and methods remove the need for error prone design at the destination after the destination has signaled not ready, where in the error prone design the destination is required to continue absorbing data from the source to prevent data drop.

While the present systems and methods are susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described. The drawings may not be to scale. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the present systems and methods to the particular form disclosed, but to the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present systems and methods as defined by the appended claims.

DETAILED DESCRIPTION OF VARIOUS EMBODIMENTS

The details of one or more embodiments of the subject matter described herein are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims.

The following description is presented to enable one of ordinary skill in the art to make and use the subject matter disclosed herein and to incorporate it in the context of particular applications. While the following is directed to specific examples, other and further examples may be devised without departing from the basic scope thereof.

In the description provided, numerous specific details are set forth in order to provide a more thorough understanding of the subject matter disclosed herein. It will, however, be apparent to one skilled in the art that the subject matter disclosed herein may be practiced without necessarily being limited to these specific details. In other instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the subject matter disclosed herein.

Various features are described herein with reference to the figures. It should be noted that the figures are only intended to facilitate the description of the features. The various features described are not intended as an exhaustive description of the subject matter disclosed herein or as a limitation on the scope of the subject matter disclosed herein. Additionally, an illustrated example need not have all the aspects or advantages shown. An aspect or an advantage described in conjunction with a particular example is not necessarily limited to that example and can be practiced in any other examples even if not so illustrated, or if not so explicitly described.

It is noted that, if used, the labels left, right, front, back, top, bottom, forward, reverse, clockwise and counterclockwise have been used for convenience purposes only and are not intended to imply any particular fixed direction. Instead, the labels are used to reflect relative locations and/or directions between various portions of an object.

Any data processing may include data buffering, aligning incoming data from multiple communication lanes, forward error correction (“FEC”), and/or others. For example, data may be first received by an analog front end (AFE), which prepares the incoming for digital processing. The digital portion (e.g., DSPs) of the transceivers may provide skew management, equalization, reflection cancellation, and/or other functions. It is to be appreciated that the process described herein can provide many benefits, including saving both power and cost.

Unless explicitly stated otherwise, each numerical value and range may be interpreted as being approximate, as if the word “about” or “approximately” preceded the value of the value or range. Signals and corresponding nodes or ports might be referred to by the same name and are interchangeable for purposes here.

While embodiments may have been described with respect to circuit functions, the embodiments of the subject matter disclosed herein are not limited. Possible implementations may be embodied in a single integrated circuit, a multi-chip module, a single card, system-on-a-chip, or a multi-card circuit pack. As would be apparent to one skilled in the art, the various embodiments might also be implemented as part of a larger system. Such embodiments may be employed in conjunction with, for example, a digital signal processor, microcontroller, field-programmable gate array, application-specific integrated circuit, or general-purpose computer.

As would be apparent to one skilled in the art, various functions of circuit elements may also be implemented as processing blocks in a software program. Such software may be employed in, for example, a digital signal processor, microcontroller, or general-purpose computer. Such software may be embodied in the form of program code embodied in tangible media, such as magnetic recording media, optical recording media, solid-state memory, floppy diskettes, CD-ROMs, hard drives, or any other non-transitory machine-readable storage medium, that when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the subject matter disclosed herein. When implemented on a general-purpose processor, the program code segments combine with the processor to provide a unique device that operates analogously to specific logic circuits. Described embodiments may also be manifest in the form of a bit stream or other sequence of signal values electrically or optically transmitted through a medium, stored magnetic-field variations in a magnetic recording medium, etc., generated using a method and/or an apparatus as described herein.

A die-to-die (D2D) interface can include a functional block that connects two silicon dies within the same package, allowing data transfer between the connected dies. D2D interfaces can be used in applications such as artificial intelligence (AI), networking, high-performance computing (HPC), hyperscale data centers, and the like. D2D interfaces can provide improved bandwidth and power efficiency over other chip-to-chip interfaces. D2D interfaces can include a controller block and a physical layer (PHY), where the PHY can include the first and lowest layer of the seven-layer Open Systems Interconnection (OSI) model of computer networking. D2D interfaces can implement various architectures, such as high-density parallel architectures or a high-speed Serializer/Deserializer (SerDes). The D2D Controller may be a link layer of the protocol stack, and may have the least latency and area overhead compared to other protocols. D2D interfaces can include Advanced Interface Bus (AIB), Universal Chiplet Interconnect Express (UCIe), and 112G Extra Short Reach (XSR), Advanced extensible Interface (AXI), etc. AXI can include a high-performance, point-to-point, master-slave parallel bus that connects on-chip peripheral circuits to processor cores. The AXI protocol can include five channels. In some cases, an AXI channel (e.g., each channel) may include its own prefix and associated VALID and READY signals. The AXI channels may include Address Read (AR) channel from master to slave; Read Data (R) channel from slave to master; Address Write (AW) channel from master to slave; Write Data (W) channel from master to slave; and Write Response (B) channel from slave to master. In some cases, the Write Response channel may be referred to as B, BRSP, or BRESP.

The AW channel can be independent from the W channel. This can mean that AW transactions can begin before anything exists on the W channel. The W channel can include write strobe (WSTRB) information. Each channel can include a source and a destination, where the source puts data on the channel and the destination receives it. The source can assert the VALID signal when sending data, and the destination can assert READY to accept the data. In some cases, READY can be asserted independently from VALID. A successful transfer of information can occur when both VALID and READY are on (e.g., at binary 1, valid=true, ready=true). The B channel can signal response information for write transactions (e.g., acknowledge receipt of a final portion of a packet, acknowledge all portions of a packet are correctly received). The B channel can be signaled after the final data transfer of a write transaction. For write transactions, AXI can provide one write response on the B channel for an entire burst (e.g., not for each data transfer or each flit within the burst).

In computer networking, flow control unit or flow control digit (flit) can include a link-level atomic element that forms a network packet or stream. Flits can be the smallest unit on which flow control is performed and may be delivered in a pipeline fashion. In some cases, the first flit of a packet may be referred to as a header flit. The header flit may include information about the packet's route (e.g., destination address) and set up the routing behavior for all subsequent flits associated with that packet. The header flit may be followed by zero or more body flits, containing the payload of data. In some cases, a standalone message may include a header flit and a tail flit without a payload, (e.g., without payload flits, without payload of data). The final flit may be referred to as the tail flit. The tail flit may perform some book keeping to close the connection between the two nodes. An example of a packet being transmitted via flits can include a packet transmitted between source A and destination B. A packet may be split into flits W, X, Y and Z (e.g., payload flits W, X, Y, and Z transmitted before a header flit and after a tail flit). The transmit buffer in A may load the first flit Z and send it to B. After B receive Z, B may move the Z flit out of the buffer (e.g., to memory). The transmit buffer in A may then load the next flit Y and send it to B. After B receives Y, B may move the Y flit out of the buffer (e.g., to memory). The same procedure may be performed for flits X and W. Once B receives flits W, X, Y, and Z, B may then put together all the flits to form the whole packet (e.g., and send a write response indicating reception of all flits). In some cases, the term “push” may refer to inserting data in a stack data structure, while “pop” may refer to removing data from the stack data structure. A stack data structure can include a First In First Out (FIFO) buffer, First In Last Out (FILO) buffer, Last In First Out (LIFO) buffer, or Last In Last Out (LILO) buffer. The systems and methods described herein may implement at least one type of stack data structure (e.g., TX FIFO, RX FIFO, etc.).

A packet may be decomposed into one or more flits, which include a header flit, body flits, and, in some cases, a tail flit. The header flit may hold information about the packet's route and may set up the routing behavior for subsequent flits associated with the packet. The other flits may include the data elements. Flit-reservation flow control can include a technique where control flits traverse the network in advance of data flits, reserving buffers. Flit-reservation flow control can reduce data latency and increases saturation throughput for a fixed amount of buffer space.

In some examples, a streaming protocol for a D2D interface (e.g., AXI) can employ a “valid-ready” handshake for data transfer. The “valid” signal may be originated from the source and embedded in the transmit (TX) flit. The “valid” signal, via the TX flit, may travel through relatively long pipelines to reach the destination, which may be located at the other end of the D2D link. Similarly, the “ready” signal may originate from the destination and may be embedded in the receive (RX) flit. The “ready” signal, via the RX flit, may travel through the relatively long pipelines to reach the source. The relatively long travel times of the TX flit and RX flit results in undesirable latency, as the source is stalled waiting for the “ready” signal to arrive. Moreover, the destination may continue absorbing data from the source after the destination indicates it is not ready (e.g., “ready” signal indicates destination is not ready). If the destination does not continue absorbing data from the source, data drop can result, potentially causing further delay and latency (e.g., decreased system performance).

The systems and methods described herein may provide a credit-based flow control. For example, the systems and methods may provide a credit-based flow control based on converting a streaming protocol to flit. In some examples, credit (e.g., a maximum credit) in the credit-based flow control may be based on a storage buffer size at the destination (e.g., size of a FIFO buffer at the destination). In some cases, a buffer size may be selected based on a round-trip delay or a bandwidth (e.g., D2D bandwidth). For example, a buffer size may be selected based on a product of the round-trip delay between source and destination and a bandwidth of the source and/or destination. Accordingly, a maximum credit may be based on a buffer size, where the buffer size is based on a product of the round-trip delay between source and destination (e.g., in seconds) and a bandwidth of the source and/or destination (e.g., in bits per second), where the product provides a bit size of the buffer. Additionally, or alternatively, a maximum credit may be selected based on a default value. Additionally, or alternatively, the source and/or the destination may select a maximum credit based on one or more messages communicated between the source and the destination. In some cases, the source and/or destination (e.g., host of the source and/or host of the destination) may determine or assign credit (e.g., maximum credit) at initialization.

In some cases, the source may monitor or track the credit count. In some aspects, the source may decrement a credit count when a flit is sent. The source may stop transmitting when the source determines that the credit count reaches zero. In some cases, the destination may return credit via a flit header when a buffer is freed (e.g., when an entry in buffer is empty, when buffer is empty). In some cases, return credit may be returned via a flit header over a main data path. In some examples, the source may increment the credit count when a credit is received (e.g., received from the destination). In some cases, a buffer size may be configured to be greater than (e.g., greater than or equal to) the round-trip delay between the source and destination. In some cases, credit return for a TX flit (e.g., AW, AR, W) may be encoded in an RX flit (e.g., R, BRSP). In some cases, credit return for an RX flit (e.g., R, BRSP) may be encoded in a TX flit (e.g., AW, AR, W). In some cases, credit return can be piggyback with a payload (e.g., a packet with payload flits), or in a standalone message when there is no payload to transfer (e.g., a packet without payload flits).

FIG. 1 illustrates an example system 100 in accordance with one or more implementations as described herein. In FIG. 1, machine 105, which may be termed a host, a system, or a server, is shown. While FIG. 1 depicts machine 105 as a tower computer, embodiments of the disclosure may extend to any form factor or type of machine. For example, machine 105 may be a rack server, a blade server, a desktop computer, a tower computer, a mini tower computer, a desktop server, a laptop computer, a notebook computer, a tablet computer, etc.

Machine 105 may include processor 110, memory 115, and storage device 120. Processor 110 may be any variety of processor. It is noted that processor 110, along with the other components discussed below, are shown outside the machine for ease of illustration: embodiments of the disclosure may include these components within the machine. While FIG. 1 shows a single processor 110, machine 105 may include any number of processors, each of which may be single core or multi-core processors, each of which may implement a Reduced Instruction Set Computer (RISC) architecture or a Complex Instruction Set Computer (CISC) architecture (among other possibilities), and may be mixed in any desired combination.

Processor 110 may be coupled to memory 115. Memory 115 may be any variety of memory, such as flash memory, Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Persistent Random Access Memory, Ferroelectric Random Access Memory (FRAM), or Non-Volatile Random Access Memory (NVRAM), such as Magnetoresistive Random Access Memory (MRAM), Phase Change Memory (PCM), or Resistive Random-Access Memory (ReRAM). Memory 115 may include volatile and/or non-volatile memory. Memory 115 may use any desired form factor: for example, Single In-Line Memory Module (SIMM), Dual In-Line Memory Module (DIMM), Non-Volatile DIMM (NVDIMM), etc. Memory 115 may be any desired combination of different memory types, and may be managed by memory controller 125. Memory 115 may be used to store data that may be termed “short-term”: that is, data not expected to be stored for extended periods of time. Examples of short-term data may include temporary files, data being used locally by applications (which may have been copied from other storage locations), and the like.

Processor 110 and memory 115 may support an operating system under which various applications may be running. These applications may issue requests (which may be termed commands) to read data from or write data to either memory 115 or storage device 120. When storage device 120 is used to support applications reading or writing data via some sort of file system, storage device 120 may be accessed using device driver 130. While FIG. 1 shows one storage device 120, there may be any number (one or more) of storage devices in machine 105. Storage device 120 may support any desired protocol or protocols, including, for example, the Non-Volatile Memory Express (NVMe) protocol, a Serial Attached Small Computer System Interface (SCSI) (SAS) protocol, or a Serial AT Attachment (SATA) protocol. Storage device 120 may include any desired interface, including, for example, a Peripheral Component Interconnect Express (PCIe) interface, or a Compute Express Link (CXL) interface. Storage device 120 may take any desired form factor, including, for example, a U.2 form factor, a U.3 form factor, a M.2 form factor, Enterprise and Data Center Standard Form Factor (EDSFF) (including all of its varieties, such as E1 short, E1 long, and the E3 varieties), or an Add-In Card (AIC).

While FIG. 1 uses the term “storage device,” embodiments of the disclosure may include any storage device formats that may benefit from the use of computational storage units, examples of which may include hard disk drives, Solid State Drives (SSDs), or persistent memory devices, such as PCM, ReRAM, or MRAM. Any reference to “storage device” “SSD” below should be understood to include such other embodiments of the disclosure and other varieties of storage devices. In some cases, the term “storage unit” may encompass storage device 120 and memory 115.

Machine 105 may include power supply 135. Power supply 135 may provide power to machine 105 and its components. Machine 105 may include transmitter 145 and receiver 150. Transmitter 145 or receiver 150 may be respectively used to transmit or receive data (e.g., flits, credit increments, credit returns, etc.). In some cases, transmitter 145 and/or receiver 150 may be used to communicate with memory 115 and/or storage device 120. Transmitter 145 may include write circuit 160, which may be used to write data into storage, such as a register, in memory 115 and/or storage device 120. In a similar manner, receiver 150 may include read circuit 165, which may be used to read data from storage, such as a register, from memory 115 and/or storage device 120. In the illustrated example, machine 105 may include timer 155 (e.g., time keeper, sync signal, measure delay, indicate communication time outs, etc.).

Machine 105 may be configured as (e.g., as a host of) one or more of a server such as a compute server, a storage server, storage node, a network server, a supercomputer, data center system, and/or the like, or any combination thereof. Additionally, or alternatively, machine 105 may be configured as (e.g., as a host of) one or more of a computer such as a workstation, a personal computer, a tablet, a smartphone, and/or the like, or any combination thereof. Machine 105 may be implemented with any type of apparatus that may be configured as a device including, for example, an accelerator device, a storage device, a network device, a memory expansion and/or buffer device, a central processing unit (CPU), a graphics processing unit (GPU), a neural processing unit (NPU), a tensor processing unit (TPU), optical processing units (OPU), and/or the like, or any combination thereof.

Any communication between devices including machine 105 (e.g., host, computational storage device, and/or any intermediary device) can occur over an interface that may be implemented with any type of wired and/or wireless communication medium, interface, protocol, and/or the like including PCIe, NVMe, Ethernet, NVMe-oF, Compute Express Link (CXL), and/or a coherent protocol such as CXL.mem, CXL.cache, CXL.IO and/or the like, Gen-Z, Open Coherent Accelerator Processor Interface (OpenCAPI), Cache Coherent Interconnect for Accelerators (CCIX), Advanced extensible Interface (AXI) and/or the like, or any combination thereof, Transmission Control Protocol/Internet Protocol (TCP/IP), FibreChannel, InfiniBand, Serial AT Attachment (SATA), Small Computer Systems Interface (SCSI), Serial Attached SCSI (SAS), iWARP, any generation of wireless network including 2G, 3G, 4G, 5G, and/or the like, any generation of Wi-Fi, Bluetooth, near-field communication (NFC), and/or the like, or any combination thereof. In some embodiments, the communication interfaces may include a communication fabric including one or more links, buses, switches, hubs, nodes, routers, translators, repeaters, and/or the like. In some embodiments, system 100 may include one or more additional apparatus having one or more additional communication interfaces.

Any of the functionality described herein, including any of the host functionality, device functionally, flow controller 140 functionality, and/or the like, may be implemented with hardware, software, firmware, or any combination thereof including, for example, hardware and/or software combinational logic, sequential logic, timers, counters, registers, state machines, volatile memories such as at least one of or any combination of the following: dynamic random access memory (DRAM) and/or static random access memory (SRAM), nonvolatile memory including flash memory, persistent memory such as cross-gridded nonvolatile memory, memory with bulk resistance change, phase change memory (PCM), and/or the like and/or any combination thereof, complex programmable logic devices (CPLDs), field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs) CPUs including complex instruction set computer (CISC) processors such as x86 processors and/or reduced instruction set computer (RISC) processors such as RISC-V and/or ARM processors), GPUs, NPUs, TPUs, OPUs, and/or the like, executing instructions stored in any type of memory. In some embodiments, one or more components of flow controller 140 may be implemented as an SoC.

In some examples, flow controller 140 may include any one or combination of logic (e.g., logical circuit), hardware (e.g., processing unit, memory, storage), software, firmware, and the like. In some cases, flow controller 140 may perform one or more functions in conjunction with processor 110. In some cases, at least a portion of flow controller 140 may be implemented in or by processor 110 and/or memory 115. The one or more logic circuits of flow controller 140 may include any one or combination of multiplexers, registers, logic gates, arithmetic logic units (ALUs), cache, computer memory, microprocessors, processing units (CPUs, GPUs, NPUs, and/or TPUs), FPGAs, ASICs, etc., that enable flow controller 140 to provide streaming protocol flow control for die-to-die interfaces.

In one or more examples, flow controller 140 may provide a credit-based flow control. For example, flow controller 140 may provide a credit-based flow control based on converting a streaming protocol to flit. In some examples, credit (e.g., a maximum credit) at a source may be based on a storage buffer size at the destination. In some cases, the source and/or destination (e.g., host of the source and/or host of the destination) may determine or assign credit (e.g., maximum credit) at initialization. In some cases, a maximum credit may be selected based on a default value. Additionally, or alternatively, the source and/or the destination may select a maximum credit based on one or more messages communicated between the source and the destination. In some cases, the source may monitor or track the credit count. In some aspects, the source may decrement a credit count when a flit is sent. The source may stop transmitting when the source determines that the credit count reaches zero. In some cases, the destination may return credit via a flit header when a buffer is freed (e.g., when an entry in buffer is empty, when buffer is empty). In some examples, the source may increment the credit count when a credit is received (e.g., received from the destination). In some cases, a buffer size may be configured to be greater than (e.g., greater than or equal to) the round-trip delay between the source and destination.

FIG. 2 illustrates details of machine 105 of FIG. 1, according to examples described herein. In the illustrated example, machine 105 may include one or more processors 110, which may include memory controllers 125 and clocks 205, which may be used to coordinate the operations of the components of the machine. Processors 110 may be coupled to memories 115, which may include random access memory (RAM), read-only memory (ROM), or other state preserving media, as examples. Processors 110 may be coupled to storage devices 120, and to network connector 210, which may be, for example, an Ethernet connector or a wireless connector. Processors 110 may be connected to buses 215, to which may be attached user interfaces 220 and Input/Output (I/O) interface ports that may be managed using I/O engines 225, among other components. As shown, processors 110 may be coupled to flow controller 230, which may be an example of flow controller 140 of FIG. 1. Additionally, or alternatively, processors 110 may be connected to buses 215, to which may be attached flow controller 230.

FIG. 3 illustrates an example system 300 in accordance with one or more implementations as described herein. In the illustrated example, system 300 may include compute die 305 and buffer die 310. As shown, compute die 305 may include streaming protocol layer 315 and die to die adapter physical layer (D2D PHY) 320. In some cases, compute die 305 may include a UCIe die and/or buffer die 310 may include a UCIe die.

In the illustrated example, streaming protocol layer 315 may include transmit (TX) pack 325 and receive (RX) unpack 330. As shown, RX unpack 330 includes RX FIFO 335. TX pack 325 includes flow control 340, TX credit count 345 (e.g., credit counter on protocol layer of UCIe die), and logic 350. As shown, buffer die 310 may include streaming protocol layer 355 and D2D PHY 360 communicatively coupled to D2D PHY 320. In some cases, D2D PHY 320 may include a UCIe PHY and/or D2D PHY 360 may include a UCIe PHY. In the illustrated example, streaming protocol layer 355 may include RX pack 365 and TX unpack 370. As shown, TX unpack 370 includes TX FIFO 375. RX pack 365 includes flow control 380, RX credit count 385 (e.g., credit counter on protocol layer of UCIe die), and logic 390.

TX pack 325 and/or RX pack 365 may include packing logic (e.g., hardware, firmware, software, IC logical circuitry) and/or a packing controller (e.g., microcontroller, FPGA, processing unit) to perform one or more operations described herein. RX unpack 330 and/or TX unpack 370 may include unpacking logic (e.g., hardware, firmware, software, IC logical circuitry) and/or an unpacking controller (e.g., microcontroller, FPGA, processing unit) to perform one or more operations described herein. In some cases, TX pack 325, RX unpack 330, RX pack 365, and/or TX unpack 370 may incorporate and/or operate in conjunction with at least a portion of flow controller 140 and/or flow controller 230.

In some examples, logic 350 and/or logic 390 may include user control logic. For example, logic 350 and/or logic 390 may include logic that enables a user to configure one or more aspects associated with streaming protocol flow control for die-to-die interfaces. For example, logic 350 and/or logic 390 may include logic that enables a user to configure flow control, configure aspects of packets (e.g., packet size, packet format, packet fields, buffer size, flit size, flits per packet, maximum credit counts, etc.). In some examples, logic 350 and/or logic 390 may include a user interface that enables a user to view one or more aspects of the systems and methods described herein (e.g., view packet flow rate, bandwidth, latency, round trip delay, errors, error rate, etc.). In some cases, logic 350 and/or logic 390 may incorporate and/or operate in conjunction with at least a portion of flow controller 140 and/or flow controller 230.

In some examples, credit (e.g., a maximum credit) at a source may be based on a storage buffer size at the destination. When compute die 305 transmits a packet or flit to buffer die 310, then compute die 305 may be the source and buffer die 310 may be the destination. When compute die 305 receives a packet or flit from buffer die 310, then compute die 305 may be the destination and buffer die 310 may be the source. In some cases, a buffer size at compute die 305 may be similar in size (e.g., the same) compared to a buffer size at buffer die 310. Alternatively, a buffer size at compute die 305 may be different in size (e.g., less than, greater than) compared to a buffer size at buffer die 310.

In some examples, the buffer size of RX FIFO 335 and/or TX FIFO 375 may be based on a round-trip delay between compute die 305 and buffer die 310. In some cases, the buffer size of RX FIFO 335 and/or TX FIFO 375 may be based on a bandwidth (e.g., D2D bandwidth) of compute die 305, a bandwidth of buffer die 310, and/or a bandwidth between compute die 305 and buffer die 310. In some cases, the bandwidth of compute die 305, the bandwidth of buffer die 310, and/or the bandwidth between compute die 305 and buffer die 310 may be measured in a unit of data per unit of time (e.g., bits per second), while the round-trip delay between compute die 305 and buffer die 310 may be measured in a unit of time (e.g., seconds). Thus, in some examples, the buffer size of RX FIFO 335 and/or TX FIFO 375 may be based on a product of round-trip delay and bandwidth (e.g., greater than the product of round-trip delay*bandwidth).

System 300 illustrates an example system in accordance with one or more implementations as described herein. As shown, system 300 may include a system of streaming protocol flow control for die-to-die interfaces. In the illustrated example, compute die 305 may transmit TX flits to buffer die 310 and/or buffer die 310 may transmit RX flits to compute die 305. As shown, streaming protocol layer 315 may transmit a TX flit to buffer die 310. As shown, flow control 340 may determine a TX credit count based on TX credit count 345. In some cases, flow control 340 may include a TX flit gate configured to check TX credit count 345. In some cases, flow control 380 may include an RX flit gate configured to check RX credit count 385.

In some cases, TX flit gate of flow control 340 may determine whether TX credit count 345 is zero or non-zero. When flow control 340 (e.g., TX flit gate of flow control 340) and/or logic 350 determines that TX credit count 345 is zero for a given clock cycle, flow control 340 (e.g., TX flit gate of flow control 340) and/or logic 350 may prohibit transmission of a TX flit for at least that clock cycle. When flow control 340 (e.g., TX flit gate of flow control 340) and/or logic 350 determines that TX credit count 345 is non-zero for a given clock cycle, flow control 340 (e.g., TX flit gate of flow control 340) and/or logic 350 may allow transmission of a TX flit for that clock cycle. In some cases, a TX flit from compute die 305 may include an RX credit for buffer die 310. In some cases, buffer die 310 may identify the RX credit in a received TX flit and apply the RX credit to streaming protocol layer 355 (e.g., increment RX credit count 385 in flow control of buffer die 310). In some cases, TX unpack 370 may receive the TX flit and unpack the TX flit. When the TX unpack 370 determines the TX flit includes a payload (e.g., data), TX unpack 370 may push (e.g., add) the data to a stack of TX FIFO 375. In some cases, TX unpack 370 may pop (e.g., remove) a different data entry from TX FIFO 375 and send the popped data to logic 390. In some cases, the popped data may be sent to memory controller 125 of FIG. 1. The popped data may be signaled to logic 390 (e.g., to generate a TX credit return to compute die 305). When TX unpack 370 determines that the unpacked TX flit includes an RX credit, TX unpack 370 may route the credit to RX credit counter 385, incrementing the RX credit count.

As shown, streaming protocol layer 355 may transmit an RX flit to compute die 305. As with TX flits, flow control 380 (e.g., RX flit gate of flow control 380) and/or logic 390 may allow transmission of RX flits when RX credit count 385 is non-zero and prohibit transmission of RX flits when RX credit count 385 is zero. In some cases, an RX flit transmitted by buffer die 310 may include a TX credit. In some cases, RX unpack 330 may receive the RX flit and unpack the RX flit. When the RX unpack 330 determines the RX flit includes a payload (e.g., data), RX unpack 330 may push (e.g., add) the data to a stack of RX FIFO 335. In some cases, RX unpack 330 may pop (e.g., remove) a different data entry from RX FIFO 335 and send the popped data to logic 350. In some cases, the popped data may be sent to host processor 110 of FIG. 1. The popped data may be signaled to logic 350 (e.g., to generate an RX credit return to buffer die 310). When RX unpack 330 determines that the unpacked RX flit includes a TX credit, RX unpack 330 may route the credit to TX credit counter 345, incrementing the TX credit count. The compute die may identify the TX credit and apply it to the streaming protocol layer of the compute die (e.g., increment TX credit count in flow control of the compute die). It is noted that D2D PHY 320 and/or D2D PHY 360 may be configured to transmit the physical signals of TX flits and/or RX flits between compute die 305 and buffer die 310.

FIG. 4 illustrates an example system 400 in accordance with one or more implementations as described herein. In the illustrated example, system 400 may include compute die 405 and buffer die 410. In some cases, compute die 405 may include a UCIe die and/or buffer die 410 may include a UCIe die. As shown, compute die 405 may include D2D protocol layer 415 and die to die adapter physical layer (D2D PHY) 420. In the illustrated example, D2D protocol layer 415 may include transmit (TX) pack 425 and receive (RX) unpack 430. As shown, RX unpack 430 includes one or more FIFOs (e.g., read (R) FIFO 435a and write response (BRSP) FIFO 435b). TX pack 425 includes flow control 440, one or more credit counters (e.g., address write (AW) credit count 445a, address read (AR) credit count 445b, write (W) credit counter 445c on protocol layer of UCIe die), and logic 450. As shown, buffer die 410 may include D2D protocol layer 455 and D2D PHY 460 communicatively coupled to D2D PHY 420. In some examples, compute die 405 and/or buffer die 410 may include a flit-aware die-to-die interface (FDI), which may include and/or be implemented in conjunction with D2D protocol layer 415, D2D PHY 420, D2D protocol layer 455, and/or D2D PHY 460. In some cases, D2D PHY 420 may include a UCIe PHY and/or D2D PHY 460 may include a UCIe PHY.

In some cases, D2D protocol layer 415 may include an AXI D2D protocol layer (e.g., D2D protocol layer configured with an AXI interface). Additionally, or alternatively, D2D protocol layer 455 may include an AXI D2D protocol layer (e.g., D2D protocol layer configured with an AXI interface). In the illustrated example, D2D protocol layer 455 may include RX pack 465 and TX unpack 470. As shown, TX unpack 470 includes one or more FIFOs (e.g., address write (AW) FIFO 475a, address read (AR) FIFO 475b, write (W) FIFO 475c). RX pack 465 includes flow control 480, one or more credit counters (e.g., read (R) credit count 485a and write response (BRSP) credit count 485b on protocol layer of UCIe die), and logic 490.

TX pack 425 and/or RX pack 465 may include packing logic (e.g., hardware, firmware, software, IC logical circuitry) and/or a packing controller (e.g., microcontroller, FPGA, processing unit) to perform one or more operations described herein. RX unpack 430 and/or TX unpack 470 may include unpacking logic (e.g., hardware, firmware, software, IC logical circuitry) and/or an unpacking controller (e.g., microcontroller, FPGA, processing unit) to perform one or more operations described herein. In some cases, TX pack 425, RX unpack 430, RX pack 465, and/or TX unpack 470 may incorporate and/or operate in conjunction with at least a portion of flow controller 140 and/or flow controller 230.

In some examples, logic 450 and/or logic 490 may include user control logic. For example, logic 450 and/or logic 490 may include logic that enables a user to configure one or more aspects associated with streaming protocol flow control for die-to-die interfaces. For example, logic 450 and/or logic 490 may include logic that enables a user to configure flow control, configure aspects of packets (e.g., packet size, packet format, packet fields, buffer size, flit size, flits per packet, maximum credit counts, etc.). In some examples, logic 450 and/or logic 490 may include a user interface that enables a user to view one or more aspects of the systems and methods described herein (e.g., view packet flow rate, bandwidth, latency, round trip delay, errors, error rate, etc.). In some cases, logic 450 and/or logic 490 may incorporate and/or operate in conjunction with at least a portion of flow controller 140 and/or flow controller 230.

In some examples, credit (e.g., a maximum credit) at a source may be based on a storage buffer size at the destination. When compute die 405 transmits a packet or flit to buffer die 410, then compute die 405 may be the source and buffer die 410 may be the destination. When compute die 405 receives a packet or flit from buffer die 410, then compute die 405 may be the destination and buffer die 410 may be the source. In some cases, a buffer size at compute die 405 may be similar in size (e.g., the same) compared to a buffer size at buffer die 410. Alternatively, a buffer size at compute die 405 may be different in size (e.g., less than, greater than) compared to a buffer size at buffer die 410. In some cases, R FIFO 435a may be similar in size (e.g., the same) or different in size (e.g., less than, greater than) compared to W FIFO 475c. In some cases, AW FIFO 475a may be similar or different in size compared to AR FIFO 475b and/or BRSP FIFO 435b; AR FIFO 475b may be similar or different in size compared to AW FIFO 475a and/or BRSP FIFO 435b; W FIFO 475c may be similar or different in size compared to R FIFO 435a.

In some examples, the buffer size of a buffer of compute die 405 (e.g., R FIFO 435a, BRSP FIFO 435b) and/or the buffer size of a buffer of buffer die 410 (e.g., AW FIFO 475a, AR FIFO 475b, and/or W FIFO 475c) may be based on a round-trip delay between compute die 405 and buffer die 410. In some cases, the buffer size of a buffer of compute die 405 and/or the buffer size of a buffer of buffer die 410 may be based on a bandwidth (e.g., D2D bandwidth) of compute die 405, a bandwidth of buffer die 410, and/or a bandwidth between compute die 405 and buffer die 410. A bandwidth of compute die 405 may be based on a bandwidth of D2D PHY 420. A bandwidth of buffer die 410 may be based on a bandwidth of D2D PHY 460. A bandwidth between compute die 405 and buffer die 410 may be based on a bandwidth between D2D PHY 420 and D2D PHY 460.

In some cases, the bandwidth of compute die 405, the bandwidth of buffer die 410, and/or the bandwidth between compute die 405 and buffer die 410 may be measured in a unit of data per unit of time (e.g., bits per second), while the round-trip delay between compute die 405 and buffer die 410 may be measured in a unit of time (e.g., seconds). Thus, in some examples, the buffer size of a buffer of compute die 405 and/or the buffer size of a buffer of buffer die 410 may be based on a product of round-trip delay and bandwidth (e.g., greater than the product of round-trip delay*bandwidth). As shown, D2D protocol layer 415 in conjunction with D2D PHY 420 may transmit one or more flits (e.g., AW flit, AR flit, and/or W flit) to D2D protocol layer 455 via D2D PHY 460. In some cases, D2D protocol layer 455 in conjunction with D2D PHY 460 may transmit one or more flits (e.g., R flit, BRSP flit) to D2D protocol layer 415 via D2D PHY 420.

A data flow from compute die 405 (e.g., source) to buffer die 410 (e.g., destination) may include one or more types of data flow. In some cases, the data flow may include a write command (e.g., via AW AXI channel), a read command (e.g., via AR AXI channel), and/or write data flow (e.g., via AXI W channel). In some cases, compute die 405 may maintain, monitor, and/or track a credit count (e.g., maximum credit count, total credit count, available credit count) for transmitting flits to buffer die 410. In some cases, compute die 405 may maintain, monitor, and/or track at least one of a first credit count for the AW AXI channel via AW credit count 445a, a second credit count for the AR AXI channel via AR credit count 445b, and/or a third credit count for the W AXI channel via W credit count 445c. In some cases, compute die 405 may maintain a total credit count via the depicted credit counts of flow control 440. In some cases, compute die 405 may initialize a maximum credit upon powering up and/or upon reset. For example, compute die 405 may initialize AW credit count 445a to its maximum credit amount upon reset, initialize AR credit count 445b to its maximum credit amount upon reset, and so on. In some cases, the maximum credit count is the same for each counter, or may vary among counters. Compute die 405 may decrement a credit count of a given AXI channel by 1 when one flit is sent on that AXI channel. Compute die 405 may increment a credit count of a given AXI channel by 1 when a credit is returned from buffer die 410 for that AXI channel. For example, compute die 405 may decrement a credit count of W credit count 445c when a W flit is sent on the W AXI channel, or may increment a credit counter of AR credit count 445b when an AR credit is returned by buffer die 410. In some cases, compute die 405 gates (e.g., pauses, blocks, holds) an outgoing flit of a given AXI channel when a credit count for that AXI channel is zero. In some examples, buffer die 410 may return a credit (e.g., in conjunction with logic 490) to compute die 405 for a given AXI channel when a flit of that of that AXI channel is popped out of a FIFO corresponding to that AXI channel. For example, when logic 490 determines that an AR flit is popped out of AR FIFO 475b, logic 490 may return an AR credit to compute die 405, which may be routed to AR credit count 445b. In some cases, credit may be returned via a BRSP flit or an R flit from buffer die 410.

A data flow from buffer die 410 (e.g., source) to compute die 405 (e.g., destination) may include one or more types of data flow. In some cases, the data flow may include a read data flow (e.g., via AXI R channel) and/or a write completion (e.g., via AXI BRSP channel). In some cases, buffer die 410 may maintain, monitor, and/or track a credit count (e.g., maximum credit count, total credit count, available credit count) for transmitting flits to compute die 405. In some cases, buffer die 410 may maintain, monitor, and/or track at least one of a first credit count for the R AXI channel via R credit count 485a and/or a second credit count for the BRSP AXI channel via BRSP credit count 485b. In some cases, buffer die 410 may maintain a total credit count via the depicted credit counts of flow control 480. In some cases, buffer die 410 may initialize a maximum credit upon powering up and/or upon reset. For example, buffer die 410 may initialize R credit count 485a to its maximum credit amount upon reset, initialize BRSP credit count 485b to its maximum credit amount upon reset, and so on. In some cases, the maximum credit count is the same for each counter, or may vary among counters. Buffer die 410 may decrement a credit count of a given AXI channel by 1 when one flit is sent on that AXI channel. Buffer die 410 may increment a credit count of a given AXI channel by 1 when a credit is returned from compute die 405 for that AXI channel. For example, buffer die 410 may decrement a credit count of BRSP credit count 485b when a BRSP flit is sent on the BRSP AXI channel, or may increment a credit counter of R credit count 485a when an R credit is returned by compute die 405. In some cases, buffer die 410 gates (e.g., pauses, blocks, holds) an outgoing flit of a given AXI channel when a credit count for that AXI channel is zero. In some examples, compute die 405 may return a credit (e.g., in conjunction with logic 450) to buffer die 410 for a given AXI channel when a flit of that AXI channel is popped out of a FIFO corresponding to that AXI channel. For example, when logic 450 determines that a BRSP flit is popped out of BRSP FIFO 435b, logic 450 may return a BRSP credit to buffer die 410, which may be routed to BRSP credit count 485b. In some cases, credit may be returned via an AW flit, AR flit, and/or W flit from compute die 405.

FIG. 5 illustrates an example data structure (e.g., flit format 500) and flit format 505 in accordance with one or more implementations as described herein. In the illustrated example, flit format 500 includes fields of a write response (B) flit, which includes a write response valid (BVALID) field, a write response (BRESP) field, a credit return field (e.g., 3-bit field for AW credit, AR credit, and W credit return), a write response user (BUSER) field, and a write response ID (BID) field. In some cases, buffer die 410 may transmit a write response flit based on flit format 500. In some cases, the depicted credit return field is part of a header of a write response flit. In some cases, credits may be returned one credit at a time (e.g., per AXI channel). A credit may be sent piggyback (e.g., BVALID set high), or in a standalone message (e.g., without payload flits).

As shown, flit format 505 includes fields of a read (R) flit, which includes a read valid (RVALID) field, a read last (RLAST) field, a read response (RRESP) field, a credit return field (e.g., 3-bit field for AW credit, AR credit, and W credit return), and a read ID field (RID). In some cases, buffer die 410 may transmit a read flit based on flit format 505. In some cases, the depicted credit return field is part of a header of a read flit. In some cases, credits may be returned one credit at a time (e.g., per AXI channel). A credit may be sent piggyback (e.g., RVALID set high), or in a standalone message (e.g., without payload flits).

FIG. 6 illustrates an example data structure (e.g., flit format 600) and flit format 605 in accordance with one or more implementations as described herein. In the illustrated example, flit format 600 includes fields of a command flit (e.g., AW command flit, AR command flit), which includes an address valid (AVALID) field (e.g., AW valid, AR valid), an access permission (APROT) field (e.g., AW access permission, AR access permission), an address cache (ACACHE) field (e.g., AW cache field, AR cache), an address burst (ABURST) field (e.g., AW burst, AR burst), an address size (ASIZE) field (e.g., AW size, AR size), and a credit return field (e.g., 2-bit field for R credit, and BRSP credit return). In some cases, compute die 405 may transmit an address write command flit or address read command flit based on flit format 600. In some cases, the depicted credit return field is part of a header of an address write command flit or address read command flit. In some cases, credits may be returned one credit at a time (e.g., one per AXI channel). A credit may be sent piggyback (e.g., AVALID set high), or in a standalone message (e.g., without payload flits).

As shown, flit format 605 includes fields of a write (W) flit, which includes a write valid (WVALID) field, a write last (WLAST) field, a write strobe activation field (WSTRB On/Off), a credit return field (e.g., 2-bit field for R credit and BRSP credit return), and a write strobe field (WSTRB). In some cases, compute die 405 may transmit a write flit based on flit format 605. In some cases, the depicted credit return field is part of a header of a write flit. In some cases, credits may be returned one credit at a time (e.g., per AXI channel). A credit may be sent piggyback (e.g., WVALID set high), or in a standalone message (e.g., without payload flits).

FIG. 7 illustrates an example timing diagram 700 in accordance with one or more implementations as described herein. In the illustrated example, timing diagram 700 depicts an address clock (ACLK) signal (e.g. AXI bus clock signal), an address write (AW) credit count state, an AW command flit valid state, an AW credit return state, an AW command flit gate state, and clock cycles of the period of time depicted.

In some cases, ACLK may synchronize AXI signals. In some cases, AXI signals may be sampled on the rising edge of ACLK, and output signal changes may occur after that edge. As shown, AW credit count depicts that the credit count is 2 (e.g., 2 credits) during the first and second clock cycles. As shown, the AW command flit gate is not asserted (e.g., remains at 0) based on the credit count being non-zero (e.g., credit count of 1 or more credits).

As shown, AW command flit valid is asserted (e.g., switched from 0 to 1) at the start of the second clock cycle and unasserted at the end of the third clock cycle. At the rising edge of the second clock cycle, AW command flit valid is asserted and a first flit (e.g., first AW command flit) is transmitted. Accordingly, AW credit count is reduced to 1. At the rising edge of the third clock cycle, AW command flit valid is asserted and a second flit (e.g., second AW command flit) is transmitted. Accordingly, AW credit count is reduced to 0.

At the rising edge of the fourth clock cycle, the AW command flit gate is asserted (e.g., switched from 0 to 1) based on the credit count being zero. Asserting the AW command flit gate may gate (e.g., pause, hold, block, prohibit) an AW command flit from being transmitted while the credit count is zero.

As shown, the AW credit return is asserted (e.g., switched from 0 to 1) at the rising edge of the fifth clock cycle, indicating that an AW credit is returned or received. Based on the AW credit return being asserted, the AW credit count is increased to 1.

FIG. 8 depicts a flow diagram illustrating an example method 800 associated with the disclosed systems, in accordance with example implementations described herein. In some configurations, method 800 may be implemented by flow controller 140 of FIG. 1 and/or flow controller 230 of FIG. 2. In some configurations, method 800 may be implemented in conjunction with machine 105, components of machine 105, or any combination thereof. The depicted method 800 is just one implementation and one or more operations of method 800 may be rearranged, reordered, omitted, and/or otherwise modified such that other implementations are possible and contemplated.

At 805, method 800 may include allowing a first packet to be transmitted from a source to a destination based on a credit count. For example, compute die 405 may allow a first packet to be transmitted from to buffer die 410 based on a credit count.

At 810, method 800 may include decrementing the credit count based on transmitting a flit of the first packet to the destination. For example, compute die 405 may decrement the credit count based on transmitting a flit of the first packet to buffer die 410.

At 815, method 800 may include incrementing the credit count based on receiving a first return credit from the destination. For example, compute die 405 may increment the credit count based on receiving a first return credit from buffer die 410.

FIG. 9 depicts a flow diagram illustrating an example method 900 associated with the disclosed systems, in accordance with example implementations described herein. In some configurations, method 900 may be implemented by flow controller 140 of FIG. 1 and/or flow controller 230 of FIG. 2. In some configurations, method 900 may be implemented in conjunction with machine 105, components of machine 105, or any combination thereof. The depicted method 900 is just one implementation and one or more operations of method 900 may be rearranged, reordered, omitted, and/or otherwise modified such that other implementations are possible and contemplated.

At 905, method 900 may include receiving, at a destination from a source, a first return credit in a header flit of a first packet. For example, buffer die 410 may receive a first return credit in a header flit of a first packet from compute die 405.

At 910, method 900 may include incrementing a credit count based on receiving the first return credit from the source. For example, buffer die 410 may increment a credit count based on receiving the first return credit from compute die 405.

At 915, method 900 may include allowing a second packet to be transmitted to the source based on the credit count. For example, buffer die 410 may allowing a second packet to be transmitted to compute die 405 based on the credit count.

At 920, method 900 may include decrementing the credit count based on transmitting a flit of the second packet to the source. For example, buffer die 410 may decrement the credit count based on transmitting a flit of the second packet to compute die 405.

In the examples described herein, the configurations and operations are example configurations and operations, and may involve various additional configurations and operations not explicitly illustrated. In some examples, one or more aspects of the illustrated configurations and/or operations may be omitted. In some embodiments, one or more of the operations may be performed by components other than those illustrated herein. Additionally, or alternatively, the sequential and/or temporal order of the operations may be varied.

As used within this document, the term “communicate” is intended to include transmitting, or receiving, or both transmitting and receiving. This may be particularly useful in claims when describing the organization of data that is being transmitted by one device and received by another, but only the functionality of one of those devices is required to infringe the claim. Similarly, the bidirectional exchange of data between two devices (both devices transmit and receive during the exchange) may be described as ‘communicating’, when only the functionality of one of those devices is being claimed. The term “communicating” as used herein with respect to a wireless communication signal includes transmitting the wireless communication signal and/or receiving the wireless communication signal. For example, a wireless communication unit, which is capable of communicating a wireless communication signal, may include a wireless transmitter to transmit the wireless communication signal to at least one other wireless communication unit, and/or a wireless communication receiver to receive the wireless communication signal from at least one other wireless communication unit.

Embodiments of the subject matter described herein can be implemented in a computing system that includes a back-end component, for example as an information/data server, or that includes a middleware component, for example an application server, or that includes a front-end component, for example a client computer having a graphical user interface or a web browser through which a user can interact with an embodiment of the subject matter described herein, or any combination of one or more such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital information/data communication, for example a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), an inter-network (for example the Internet), and peer-to-peer networks (for example ad hoc peer-to-peer networks).

The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In some embodiments, a server transmits information/data (for example an HTML page) to a client device (for example for purposes of displaying information/data to and receiving user input from a user interacting with the client device). Information/data generated at the client device (for example a result of the user interaction) can be received from the client device at the server.