CHIP-TO-CHIP BANDWIDTH OPTIMIZATION

Abstract

A transceiver is used to send and receive data packets over a communication channel. The transceiver receives an initial request packet containing several information fields, including a first type of operation to be performed on a memory device and a first address. The transceiver stores the first operation type and the first address in memory associated with the transceiver and sends the first request packet with the first address to a destination device. The transceiver then receives a second request packet containing a second address in the memory device and, based on the first operation type, the first address, and the second address, determines that the second request packet is part of a sequence of request packets to the destination device.The transceiver then eliminates part of the second address in a header of the second request packet to form a third request packet and sends the third request packet to the destination device.

Description

TECHNICAL FIELD

[0001] Embodiments of the disclosure relate generally to processors, and more particularly to systems and methods for communication between two or more devices in a processor. BACKGROUND

[0002] Modern processing units such as GPUs and CPUs use various communication protocols and interfaces to transfer data between different chips or components within the processing unit. Examples of such protocols include PCIe (Peripheral Component Interconnect Express) and NVLink®. These communication protocols often use packets or frames with specific data fields containing information such as headers, addresses, control bits, and payloads.

[0003] CHI (Coherent Hub Interface) is a communication protocol that is part of AMBA (Advanced Microcontroller Bus Architecture), which is used for communication between two devices or SoCs (System-on-Chips) in a GPU. AMBA is an open standard for connecting and managing functional blocks in an SoC. It is used for developing multiprocessor designs with a large number of controllers and peripherals. CHI can be used in a wide range of applications where coherence is required (for example, to ensure that all processors or bus masters in a system have the same view of memory), such as in the mobile, networking, and automotive industries, as well as in data centers. AMBA CHI was developed to maintain performance in systems with a growing number of components and data traffic.These systems utilize multiple components, from processor clusters, graphics processors, and memory controllers to I / O bridges, PCIe (Peripheral Component Interconnect Express) subsystems, and the interconnect itself. In a multi-chip system such as a GPU system, communication between chips occurs via C2C (chip-to-chip) IO (input / output) links. However, these IO links consume significant space and power. SUMMARY

[0004] The invention is defined by the claims. To illustrate the invention, aspects and embodiments are described herein, which may or may not fall within the scope of the claims.

[0005] A transceiver for transmitting and receiving data packets over a communication channel is described. The transceiver receives a first request packet containing a plurality of information fields including a first type of operation to be performed on a memory device and a first address. The transceiver stores the first operation type and the first address in memory associated with the transceiver and transmits the first request packet containing the first address to a destination device. The transceiver then receives a second request packet containing a second address in the memory device and, based on the first operation type, the first address, and the second address, determines that the second request packet is part of a sequence of request packets to the destination device.The transceiver then eliminates part of the second address in a header of the second request packet to form a third request packet and sends the third request packet to the destination device.

[0006] Any feature of one aspect or embodiment may be applied to other aspects or embodiments in any suitable combination. In particular, any feature of a method aspect or embodiment may be applied to a device aspect or embodiment, and vice versa. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The disclosure will be more fully understood from the following detailed description and the accompanying drawings of various embodiments of the disclosure. However, the drawings are not intended to limit the disclosure to the specific embodiments, but are for purposes of explanation and understanding only. Fig. 1 illustrates an example of a multi-chip system according to some embodiments of the present disclosure; Fig. 2 illustrates an example of a multi-chip system with optimized C2C IO linking according to some embodiments of the present disclosure; Fig. 3 illustrates an example of a multi-chip system with optimized C2C IO linking according to some embodiments of the present disclosure; Fig. 4 illustrates example operations in a method for optimizing bandwidth on a C2C IO link according to some embodiments of the present disclosure. Fig. 5 illustrates example operations in a method for optimizing bandwidth on a C2C IO link according to some embodiments of the present disclosure. Fig. 6 illustrates an example of a computer system having a multi-tile system according to some embodiments of the present disclosure. DETAILED DESCRIPTION

[0008] Aspects of the present disclosure may address the above-mentioned deficiencies and other challenges by providing a multi-chip system including two or more system-on-chips (SoCs) connected via an optimized-bandwidth IO link. The multi-chip system may be a processor (e.g., CPU, GPU, or DPU). In some embodiments, a source device, or sender, receives a request packet to be transmitted to a destination device, or receiver. The request packet may include one or more information fields, including, but not limited to, one or more types of operations to be performed on a memory device, one or more addresses, a size of an operation, one or more ordering requirements, one or more cacheability attributes, etc.Upon receiving the request packet, the source device may determine, based on a type of operation, an address of a destination device, and / or an operation size, that the request packet is part of a series of packets to be transmitted to the destination device. In one example, the sender may receive a request to read data from a memory associated with a receiver. Upon receiving such a request, the sender may determine that the request packet contains a read operation request and that each time data may be read from a memory to perform and complete the read operation. The sender may then store at least some information fields (e.g., address and size) in a memory associated with the sender (e.g.,CAM (Content Addressable Memory)), and when a second request packet related to the same operation is received, the sender can eliminate part or all of the address and transmit only part of the address to the receiver, or not transmit the address at all. Similarly, after receiving a first request packet, the receiver can store at least some information fields (e.g., address and size) in a cache memory associated with the receiver, and upon receiving a second request packet related to the same operation, the receiver can determine that only part of the address is being transmitted because the remaining part of the address can be used by a previous or preceding request packet. In this way, the redundant or low-value fields can be eliminated, and the bandwidth of the IO link can be saved for other communications.

[0009] In some embodiments, the sender may be able to predict the next address to be used based on an operation type and / or size, thus eliminating the address field and / or the size field entirely. For example, if the sender receives a request for a 64 KB write operation, and the write operation is performed in 8 KB portions, the sender may predict the address of the next memory location where the next write operation will be performed. Such information may be redundant because, based on an initial request packet, the sender and receiver already know what operation is being performed, the size of the operation, a starting address, and a possible ending address for the operation. In such a case, the sender may be redundant, including the size of the operation and / or the next address of the memory location.Accordingly, in some embodiments, the sender may completely eliminate the address and / or size and send the remaining request packet to the receiver. The receiver, which has already stored information from a previous request packet in a cache memory, may determine from the information in the previous or preceding request packet that a missing address field and / or a missing size field is a request for the receiver to populate the missing field.

[0010] Advantages of the disclosed embodiments include data packet compression for efficient data transmission and reduced power consumption. Redundant or low-entropy fields can be compressed to reduce the overall data transmission size, resulting in more efficient data transmission and potentially lower power consumption. Other advantages include bandwidth optimization. By identifying and reducing the size of low-entropy fields, more bandwidth can be effectively used to transmit useful information, which can lead to improved performance of the overall GPU. Other advantages include lower latency. Smaller data packets resulting from compressing low-entropy fields can lead to lower communication latency, improving the overall responsiveness of the SoC and the overall GPU.The communication protocols disclosed herein may be used in any processing unit (e.g., GPU, DPU, or CPU), including but not limited to Hopper, Grace data center / server CPU, and / or NVSwitch for Hopper, and may support link rates of approximately 212.5 GT / s per lane or greater and data transfer rates of 1 TB / s or greater.

[0011] Fig. 1 illustrates a block diagram of a processor (e.g., GPU, DPU, or CPU) with one or more source devices or transmitters 110 and one or more destination devices or receivers 112. Each transmitter 110 and receiver 112 may include a SoC (System-on-Chip) or functional element referred to as a "core." The transmitter 110 and receiver 112 are generally represented as system 600, which may be Fig. 6. The transmitter 110 may communicate with the receiver 112 via one or more communication layers, including, but not limited to, a protocol layer 114 and a data link layer 116. Similarly, the receiver 112 may communicate with the transmitter 110 via one or more communication layers, including, but not limited to, a data link layer 126 and a protocol layer 124. The transmitter 110 and the receiver 112 may communicate via one or more communication protocols, including, but not limited to, PCIE and NVlink®.The transmitter 110 and the receiver 112 may be coupled using one or more communication protocols, either directly or indirectly via an ultra-high-speed data communication interface such as a C2C IO link 120, over which one or more messages may be sent by the transmitter 110 and received by one or more receivers 112. The messages may be sent in the form of "packets," which are described in more detail below. In some protocols (e.g., the AMBA-CHI protocol), the transmitter 110 and the receiver 112 may send and receive multiple types of messages, including, but not limited to, a request message, a response message, and a data message. A request message may contain a request to perform a specific type of operation.A response message may contain an acknowledgment and / or a response with a further request addressed to the sender. A data message may contain a payload such as one or more data bits. When a sender 110 receives a request packet with 80 bits, the sender 110 serializes and transmits 8 bits over 10 consecutive cycles via a single 8-bit IO link 120, so that a total of 80 bits are transmitted. In some implementations, the sender may include identification information, for example, to identify the packet type. In such cases, the 80-bit request may, for example, comprise a total of 82 bits (e.g., 80 bits of the request and 2 bits to identify the type of packet sent).

[0012] Although only two devices are shown for illustrative purposes, GPU 100 may include any number of devices that may be connected via the NVlink® interface. NVLink® is a wired, short-range semiconductor communication protocol developed by Nvidia that can be used to transfer data and control code in processor systems between CPUs and GPUs, as well as between GPUs alone. There are multiple NVlink® protocol layers through which a source device, or transmitter, 110 and a destination device, or receiver, 112 can communicate. PHY is the physical, electrical layer responsible for, among other things, driving and receiving analog signals from a device. PL is a physical, logic layer (not shown) that includes, among other things, digital logic that bridges the PHY and data link layers.DL is a data link layer 116, 126, which is responsible for, among other things, packetization, link reliability, and link configuration. TL is a transaction layer 114, 124, which is responsible for bridging protocols and arbitration, providing flow control mechanisms such as distributing traffic across multiple links, maintaining order, and other functions.

[0013] Generally, a packet sent over a C2C IO link is wider than the IO link itself. Therefore, the packet is sent in multiple parts over the IO link. For example, if the source device or sender 110 is to send an 80-bit packet over an 8-bit link 120, the packet is split into 10 equal parts, and the parts are sent in 10 consecutive cycles. The receiver 112 reassembles the 10 parts to form the original packet. Each packet contains several information fields 130-140, including, but not limited to, packet type, transaction identification (ID), source device ID, destination device ID, payload, header CRC (Cyclic Redundancy Check), data CRC, and flow control. A packet type identifies the type of packet being sent, such as data packets, control packets, or acknowledgment packets.In some implementations, the packet type may be separate from the original packet, and identifying the packet type can add a few extra bits to the transaction. A transaction ID is used to identify and track different transactions between a sender (or source device) and a receiver (or destination device). A source device ID and a destination device ID specify the source and destination of the packet. In NVLink®, each GPU or component on the interconnect is assigned a unique ID to facilitate communication. The payload field contains the actual data transferred between the devices. Depending on the purpose of the communication, it can contain graphics data, compute data, or other information. A header CRC in the packet header ensures data integrity during transmission.With CRC, the receiver can check for errors and verify that the packet arrived without corruption. A data CRC field for the payload provides an additional layer of data integrity verification. In addition, flow control mechanisms can be used to control the flow of data between sender and receiver, ensuring that data is transmitted at an appropriate rate to avoid data loss or buffer overflow. Some of these information fields are redundant and therefore of low value and are commonly referred to as "low-entropy" fields. A source device, or sender 110, may, in some cases, modify or remove such low-entropy fields, and the destination device, or receiver 112, may insert a known default value in place of the missing field.

[0014] Fig. 2 illustrates an example of a multi-chip system 200 (e.g., a processor such as a GPU, DPU, or CPU) according to some embodiments of the present disclosure. The multi-chip system 200 may include one or more transmitters 210 and one or more receivers 212. Each of the transmitters 210 and receivers 212 may include a system-on-chip (SoC) or a functional element such as one or more cores. The transmitter 210 and the receiver 212 may communicate using one or more communication protocols, including, but not limited to, PCIE and NVlink®. The transmitter 210 and the receiver 212 may be coupled either directly or indirectly via an ultra-high-speed data communication interface such as a C2C IO link 220, over which one or more messages may be sent from the transmitter 210 and received by one or more receivers 212.Similarly, in some cases, the receiver 212 may be the transmitter, with the receiver 212 sending one or more messages to the transmitter 210. Although only two devices are shown for illustrative purposes, the processor 200 may include any number of devices connected via the C2C IO link 220, such as an NVlink® interface. Although referred to as an IO link, the communication channel between the transceiver 210 and the receiver 212 may include one or more of a bus, a switch, a network, a crossbar, a daisy chain, or an interconnect fabric.

[0015] In some protocols (e.g., the AMBA-CHI protocol), inter-chip transactions between the sender 210 and the receiver 212 may involve the use of request packets, response packets, and data messages sent over the IO link 220 to complete a sequence of a protocol. Some transactions may begin with a request message 230, which may contain many attributes of that request, including, but not limited to, operation type, address, size, ordering requirements, cacheability attributes, etc. In some embodiments, the source device or sender 210 may avoid sending low-entropy fields by storing caches of recent requests in the sending and receiving agents. If the sender 210 detects that a new request uses the same values ​​for these attributes as a recently sent (and therefore cached) request, sending those attributes is avoided.Instead, it sends a field that tells the receiver 212 the index of the cache entry containing this request. Since the receiver's cache contains the same messages recently sent by the sender 210, the eliminated fields can be retrieved from the cache. This allows more messages to be sent, as fewer bytes of information are sent over the link 220 per request.

[0016] Again to Fig. 2, the transmitter 210 may include one or more multiplexers 228, 232, and one or more filters 226. The transmitter 210 may receive a request packet 230 as part of an IO operation by an IO device (not shown). The request packet 230 may include one or more information fields, including, but not limited to, a type of operation to be performed on a memory device and an address within the memory device. When the transceiver or transmitter 210 receives such a request packet, the transceiver or transmitter 210 may store at least the type of operation and / or the address in a memory (e.g., CAM (Content Addressable Memory)) associated with the transceiver or transmitter 210. The operation type may include, for example, a read operation, a write operation, and / or a scan operation.In some embodiments, the processing logic of the sender 210 may index the operation type and / or address in the data structure using a unique process identification (ID). In some embodiments, the processing logic of the sender 210 may store such a request packet as previous_pkt 222. The sender 210 may then transmit the request packet 230, including the operation type and / or address, to a destination device or receiver 212. The receiver 212 may include one or more demultiplexers 238 and one or more filters 236. Upon receiving the request packet 230 with the pkttype information field, the receiver 212 may store the request packet 230 (e.g., in a cache of the receiver) and the information fields contained therein as previous_pkt 234.In some embodiments, the memory operation may involve indexing the operation type and / or address in a data structure using a unique process identification (ID).

[0017] The transmitter 210 may then receive a second request packet 230 from the IO device. The processing logic of the transmitter 210 may then compare the information fields of the second request packet 230 with the information fields of previous_pkt 222, and if there is a match 224 for either the operation type or part of the address, the processing logic may change the packet type (pkttype) from unoptimized (UNOPT) to optimized (OPT). If the request packet is designated as an optimized packet, the filter 226 may eliminate part of the address, and the multiplexer 228 may generate a new request packet (e.g., link_pkt) containing only part of the address, which is then sent to the receiver 212 via the C2C IO link 220.

[0018] In some embodiments, the IO device may access large, sequential regions of memory. For example, reading a 4-kB region may require 64 read operations, each for 64 B. The first 64-B read access to a new 4-kB region would not be found in the cache of the source device or sender 210, so the source device or sender 210 would then send an unoptimized request with the full address. The upper part of the address is then stored in both the sender and receiver caches. On subsequent accesses that match the upper part of the address, the sender does not send the full address, but only the lower part. For example, if the first packet has the address 0x12345000, the full address is sent, and the upper part of the address (e.g., 0x12345) is stored in the cache memory of both the sender 210 and the receiver 212.If a subsequent packet has an address of 0x12345040, the source device or sender 210 eliminates the upper part of the address and sends an optimized packet with only 0x040, indicating to the receiver that anything before 040 can be populated with the stored default value (e.g., 0x12345). This method can be implemented in any transaction involving a fixed memory size, and generally, most read and write operations involve a fixed-size operation, as described above.

[0019] After receiving the optimized packet, the processing logic of the receiver 212 may determine that the optimized packet contains a shortened address, which can be reset to its original value using a default value stored in the previous packet 234. The receiver processing logic would then combine 236 the two parts of the address (e.g., a part from the optimized packet and a part from the previous packet 234) to generate a response packet 250 (e.g., pkt_out). The response packet 250 may contain an acknowledgment of receipt of the request packet 230 and / or an additional request for the sender 210. After receiving the response packet 250, the sender 210 may match the response packet to the corresponding request packet based on a tag field in the response packet.

[0020] Fig. 3 illustrates an example of a multi-chip system 300 with an optimized C2C IO link 320 according to some embodiments of the present disclosure. The multi-chip system 300 may include one or more transmitters 310 and one or more receivers 312. Each of the transmitters 310 and receivers 312 may include a system-on-chip (SoC) or a functional element such as one or more cores. The transmitter 310 and the receiver 312 may communicate using one or more communication protocols, including, but not limited to, PCIE and NVlink®. The transmitter 310 and the receiver 312 may be coupled either directly or indirectly via an ultra-high-speed data communication interface such as a C2C IO link 320, over which one or more messages may be sent from the transmitter 310 and received by one or more receivers 312.Similarly, in some cases, the receiver 312 may be the transmitter, with the receiver 312 sending one or more messages to the transmitter 310. Although only two devices are shown for illustrative purposes, the processor 300 may include any number of devices connected via the C2C IO link 320, such as an Nvlink® interface. Although referred to as an IO link, the communication channel between the transceiver 310 and the receiver 312 may include one or more of a bus, a switch, a network, a crossbar, a daisy chain, or an interconnect fabric.

[0021] A request message 330 may contain many attributes of that request, including, but not limited to, operation type, address, size, ordering requirements, cacheability attributes, etc. In some embodiments, the source device or sender 310 may avoid sending low-entropy fields by storing caches of recent requests in the sending and receiving agents. If the sender 310 detects that a new request uses the same values ​​for these attributes as a recently sent (and therefore cached) request, it avoids sending these attributes. Instead, it sends a field indicating to the receiver 312 the index of the cache entry containing this request. Since the receiver's cache has the same recently sent messages from the sender 310, the eliminated fields can be retrieved from the cache.This allows more messages to be sent because fewer bytes of information are sent via link 320 per request.

[0022] In some embodiments, the transmitter 310 may include one or more multiplexers 328, 332 and one or more filters 326. The transmitter 310 may receive a request packet 330 as part of an IO operation by an IO device (not shown). The request packet 330 may include one or more information fields, including, but not limited to, a type of operation to be performed on a memory device and an address within the memory device. When the transceiver or transmitter 310 receives such a request packet, the transceiver or transmitter 310 may store at least the operation type and / or the address in a memory 322 (e.g., CAM (Content Addressable Memory)) associated with the transceiver or transmitter 310. The operation type may include, for example, a read operation, a write operation, and / or a scan operation.In some embodiments, the processing logic of the sender 310 may index the operation type and / or address in the data structure using a unique process identification (ID). The sender 310 may then send the request packet 330, including the operation type and / or address, to a destination device or receiver 312. The receiver 312 may include one or more demultiplexers 338 and one or more filters 336. Upon receiving the request packet 330 with the pkttype information field, the receiver 312 may store the request packet 330 (e.g., in a cache memory 334 of the receiver) and the information fields contained therein. In some embodiments, the store operation may involve indexing the operation type and / or address in a data structure using a unique process identification (ID).

[0023] The transmitter 310 may then receive a second request packet 330 from the IO device. The processing logic of the transmitter 310 may then compare the information fields of the second request packet 330 with the information fields of previous_pkt, and if there is a match for either the operation type or part of the address, the processing logic may change the packet type (pkttype) from unoptimized (UNOPT) to optimized (OPT) and insert a header index (e.g., hdridx). If the request packet is designated as an optimized packet, the filter 326 may eliminate part of the address, and the multiplexer 328 may generate a new request packet (e.g., link_pkt) containing only part of the address, which is then sent to the receiver 312 via the C2C IO link 220.

[0024] After receiving the optimized packet, the receiver processing logic 312 may determine that the optimized packet contains a truncated address, which can be restored to its original value using the header index. The receiver processing logic would then merge 336 the two parts of the address (e.g., a part from the optimized packet and a part from the previous packet) to generate a packet 350 (e.g., pkt_out) with the same value as the transmitted packet, but with the eliminated fields restored. After receiving the response packet 350, the sender 310 may match the response packet to the corresponding request packet based on a tag field in the response packet.

[0025] In some embodiments, the transmitter 310 may determine that a request packet is part of a sequence of packets. For example, if the operation being performed is a read operation, the transmitter 310 knows that the read operation is performed in a series of operations of a predetermined size (e.g., portions of a fixed size). Accordingly, the transmitter 310 may determine the next address based on a previous address in a previous packet and store such an expected address in the CAM 322 of the transmitter 310. Similarly, the receiver 312 may also determine that a request packet is part of a sequence of packets. For example, if the operation being performed is a read operation, the receiver 312 may know that the read operation is performed in a series of operations of a predetermined size (e.g., portions of a fixed size).Accordingly, the receiver 312 can determine the next address based on a previous address in a previous packet and store this expected address in the cache of the receiver 312. When the sender 310 receives a request packet 330 with an expected address, the request packet 330 is transmitted without the expected address, and the stored expected address is updated to a new expected address on both the sender and receiver sides. Consequently, when the receiver 312 receives a request packet without an address field or a size field, it compares the address field with the expected address and updates the expected address to a new expected address.

[0026] For example, instead of storing the upper address in the cache, the full address, adjusted for size, is stored in the cache. The cached address is based on the current address plus the size, with the expectation that the IO device will access this cached address next. For example, if the first packet has the address 0x12345000, the full address is sent to the receiver, and both the receiver and sender store the full address plus the size (e.g., 0x12345040) in the cache. If a subsequent packet has an address of 0x12345040, the entire address field is eliminated, and the packet is sent without either the address or size field. The cache on both the transceiver and receiver sides is updated to store a new address plus the size (e.g., 0x12345080 (previous address + size)).Consequently, if the next packet has an address of 0x12345080, neither the address nor the size of the transaction are sent to the receiver, and the receiver can decode that the new address is 0x12345080 based on the cached address and size. This method can be implemented in any transaction involving a fixed memory size, and in general, most read and write operations involve a fixed-size operation, as described above. The advantages of the described embodiments are that for sequential addresses (which is likely for IO accesses), the entire address field can be eliminated. This saves several bytes for each transmitted packet. Compared to current optimization methods, sending more redundant information over the C2C link is avoided.This allows devices to send more messages using the same bandwidth. A non-optimized request would consume an estimated 17 bytes, while the current optimization method reduces this request to 7 bytes, resulting in a bandwidth saving of approximately 60%.

[0027] Fig. 4 illustrates example operations in a method 400 for optimizing C2C IO linking in a multi-chip system, according to some embodiments of the present disclosure. The method 400 may be performed by processing logic, which may include hardware (e.g., processing device, circuits, dedicated logic, programmable logic, microcode, device hardware, integrated circuit, etc.), software (e.g., instructions executed on a processing device), or a combination thereof. Unless otherwise noted, even though the processes are illustrated in a particular sequence or order, the order of the processes may be changed. Therefore, the illustrated embodiments are only examples, and the illustrated processes may be executed in a different order, and some processes may be executed in parallel.Furthermore, one or more processes may be omitted in various embodiments. Therefore, not all processes are required in every embodiment. Other process sequences are possible.

[0028] Aspects of the present disclosure may be applied to a multi-chip system including an array of functional units (referred to as "tiles" or "cores") connected via a C2C IO link. A first functional unit (e.g., a source device) in the array of functional units includes a memory device and a processing device operatively coupled to the memory device to perform a series of operations. At operation 410, the source device may receive a request packet as part of an IO operation from an IO device. The request packet may include one or more information fields, including, but not limited to, a type of operation to be performed on a memory device and an address within the memory device.At operation 420, the source device may store at least the operation type and / or the address in memory (e.g., CAM (Content Addressable Memory)) associated with the source device. The operation type may include, for example, a read operation, a write operation, and / or a scan operation. In some embodiments, the processing logic of the source device may index the operation type and / or the address in the data structure using a unique process identification (ID).

[0029] At operation 430, the processing logic of the source device may send the request packet, including the operation type and / or address, to a destination device. After receiving the request packet with the pkttype information field, the destination device may store the request packet (e.g., in a cache of the receiver) and the information fields contained therein. In some embodiments, the storage operation may include indexing the operation type and / or address in a data structure using a unique process identification (ID).

[0030] At operation 440, the source device may receive a second request packet from the IO device. At operation 450, the source device's processing logic may then compare the information fields of the second request packet with the information fields of the previous_pkt, and if there is a match for either the operation type or part of the address, the processing logic may change the packet type (pkttype) from unoptimized (UNOPT) to optimized (OPT).

[0031] If the request packet is designated as an optimized packet, at operation 460 the source device may eliminate a portion of the address, and the source device may generate a new request packet (e.g., link_pkt) containing only a portion of the address, which is then sent to the destination device via the C2C IO link.

[0032] In some embodiments, the IO device may access large, sequential regions of memory. For example, reading a 4-kB region may require 64 read operations, each for 64 B. The first 64 B read to a new 4-kB region would not be found in the source device's cache, so the source device would send an unoptimized request with the full address. The upper part of the address is then stored in both the sender's and receiver's caches. On subsequent accesses that match the upper part of the address, the sender does not send the full address, but only the lower part. For example, if the first packet has the address 0x12345000, the full address is sent, and the upper part of the address (e.g., 0x12345) is stored in the cache memory of both the source device and the destination device.If a subsequent packet has an address of 0x12345040, the source device eliminates the upper part of the address and sends an optimized packet with only 0x040, indicating to the receiver that everything before 040 can be populated with the stored default value (e.g. 0x12345).

[0033] After receiving the optimized packet, the processing logic of the destination device may determine that the optimized packet contains a truncated address, which can be reset to its original value using a default value stored in the previous packet. The processing logic of the receiver would then combine the two parts of the address (e.g., a part from the optimized packet and a part from the previous packet) to generate a response packet (e.g., pkt_out). The response packet may contain an acknowledgment of receipt of the request packet and / or an additional request for the sender. After receiving the response packet, the source device may match the response packet to the corresponding request packet based on a tag field in the response packet.

[0034] Fig. 5 illustrates example operations in a method 500 for optimizing C2C IO linking in a multi-chip system, according to some embodiments of the present disclosure. The method 500 may be performed by processing logic, which may include hardware (e.g., processing device, circuits, dedicated logic, programmable logic, microcode, device hardware, integrated circuit, etc.), software (e.g., instructions executed on a processing device), or a combination thereof. Unless otherwise noted, even if illustrated in a particular sequence or order, the order of the processes may be changed. Therefore, the illustrated embodiments are only examples, and the illustrated processes may be executed in a different order, and some processes may be executed in parallel.Furthermore, one or more processes may be omitted in various embodiments. Therefore, not all processes are required in every embodiment. Other process sequences are possible.

[0035] At operation 510, the source device may receive a request packet as part of an IO operation by an IO device. The request packet may include one or more information fields, including, but not limited to, a type of operation to be performed on a memory device and an address within the memory device. When the source device receives such a request packet, the source device may store at least the operation type and / or the address in memory associated with the source device (e.g., a CAM (Content Addressable Memory)). The operation type may include, for example, a read operation, a write operation, and / or a scan operation. In some embodiments, the processing logic of the source device may index the operation type and / or the address in the data structure using a unique process identifier (ID).The source device may then send the request packet, including the operation type and / or address, to a destination device. After receiving the request packet with the pkttype information field, the destination device may store the request packet (e.g., in a cache memory of the receiver) and the information fields contained therein. In some embodiments, the storage operation may include indexing the operation type and / or address in a data structure using a unique process identification (ID).

[0036] The source device can then receive a second request packet from the IO device. The sender's processing logic can then compare the information fields of the second request packet with the information fields of previous_pkt. If there is a match for either the operation type or part of the address, the processing logic can change the packet type (pkttype) from unoptimized (UNOPT) to optimized (OPT) and insert a header index (e.g., hdridx). If the request packet is designated as an optimized packet, the source device can eliminate part of the address and generate a new request packet (e.g., link_pkt) containing only part of the address, which is then sent to the destination device via the C2C IO link.After receiving the optimized packet, the processing logic of the destination device may determine that the optimized packet contains a truncated address, which can be restored to its original value using the header index. The processing logic of the receiver would then combine the two parts of the address (e.g., a part from the optimized packet and a part from the previous packet) to generate a response packet (e.g., pkt_out). The response packet may contain an acknowledgment of receipt of the request packet and / or an additional request for the sender. After receiving the response packet, the source device may match the response packet to the corresponding request packet based on a tag field in the response packet.

[0037] At operation 520, the source device may determine that a request packet is part of a sequence of packets. For example, if the operation being performed is a read operation, the source device may know that the read operation is being performed in a series of operations of a predetermined size (e.g., fixed-size portions). Accordingly, the source device may determine the next address based on a previous address in a previous packet and store such an expected address in the source device's CAM. Similarly, the destination device may also determine that a request packet is part of a sequence of packets. For example, if the operation being performed is a read operation, the destination device may know that the read operation is being performed in a series of operations of a predetermined size (e.g., fixed-size portions).Accordingly, the target device may determine the next address based on a previous address in a previous packet and store such expected address in the target device's cache.

[0038] At operation 530, the source device may receive a request packet with an expected address. At operation 540, the request packet is transmitted without the expected address, and the stored expected address is updated to a new expected address on both the sender and receiver sides. Consequently, at operation 550, if the destination device receives a request packet without an address field or a size field, the destination device compares the address field with the expected address and updates the expected address to a new expected address.

[0039] For example, instead of storing the upper address in the cache, the entire address, adjusted for size, is stored in the cache. The cached address is based on the current address plus the size, with the expectation that the IO device will access this cached address next. For example, if the first packet has the address 0x12345000, the full address is sent to the receiver, and both the receiver and sender store the full address plus the size (e.g., 0x12345040) in the cache. If a subsequent packet has an address of 0x12345040, the entire address field is eliminated, and the packet is sent without either the address or size field. The cache on both the transceiver and receiver sides is updated to store a new address plus the size (e.g., 0x12345080 (previous address + size)).Consequently, if the next packet has an address of 0x12345080, neither the address nor the size of the transaction is sent to the receiver, and the receiver can decode that the new address is 0x12345080 based on the cached address and size.

[0040] Advantages of the disclosed embodiments include data packet compression for efficient data transmission and lower power consumption. Redundant or low-entropy fields can be compressed to reduce the overall data transmission size, resulting in more efficient data transmission and potentially lower power consumption. Other advantages include bandwidth optimization. By identifying and shrinking low-entropy fields, more bandwidth can be effectively used to transmit useful information, which can lead to improved overall GPU performance. Other advantages include lower latency. Smaller data packets resulting from compressing low-entropy fields can lead to lower communication latency, improving the overall responsiveness of the SoC and the overall GPU.The communication protocols disclosed herein can be used in any GPU design, including but not limited to Hopper, Grace Datacenter / Server CPU, and / or NVSwitch for Hopper, and can support link rates of approximately 212.5 GT / s per lane or greater and data transfer rates of 1 TB / s or greater.

[0041] Fig. 6 illustrates a computer system 600 having a multi-chip system according to at least one embodiment. In at least one embodiment, the computer system 600 may be a system of interconnected devices and components, a SOC, or a combination thereof. In at least one embodiment, the computer system 600 is equipped with a processor 602, which may include execution units for executing an instruction. In at least one embodiment, the computer system 600 may include, without limitation, a component such as the processor 602 to employ execution units including logic for performing algorithms for processing data.In at least one embodiment, computer system 600 may include processors such as the PENTIUM® processor family, Xeon®, Itanium®, XScale® and / or StrongARM®, Intel® Core™, or Intel® Nervana™ microprocessors available from Intel Corporation of Santa Clara, California, although other systems (including PCs with other microprocessors, technical workstations, set-top boxes, and the like) may be used. In at least one embodiment, computer system 600 may run a version of the Windows® operating system from Microsoft Corporation of Redmond, WA, although other operating systems (e.g., UNIX and Linux), embedded software, and / or graphical user interfaces may also be used.

[0042] In at least one embodiment, computer system 600 may be used in other devices, such as handheld devices and embedded applications. Some examples of handheld devices include cellular phones, Internet Protocol devices, digital cameras, personal digital assistants (PDAs), and handheld PCs. In at least one embodiment, embedded applications may include a microcontroller, a digital signal processor (DSP), an SoC, network computers (NetPCs), set-top boxes, network hubs, wide-area network (WAN) switches, or any other system capable of executing one or more instructions. In one embodiment, computer system 600 may be used in devices such as GPUs (Graphics Processing Units), network adapters, central processing units, and network devices such as switches (e.g., a direct high-speed GPU-to-GPU interconnect such as the NVIDIA GH100 NVLINK or the NVIDIA Quantum 2 64-Port InfiniBand NDR Switch).

[0043] In at least one embodiment, computer system 600 may include, without limitation, a processor 602, which may include, without limitation, one or more execution units 607 that may be configured to execute a CUDA (Compute Unified Device Architecture) program (CUDA® is developed by NVIDIA Corporation of Santa Clara, CA). In at least one embodiment, a CUDA program is at least a portion of a software application written in a CUDA programming language. In at least one embodiment, computer system 600 is a single-processor desktop or server system. In at least one embodiment, computer system 600 may be a multiprocessor system.In at least one embodiment, processor 602 may be, without limitation, a CISC microprocessor, a RISC microprocessor, a VLIW microprocessor, a processor implementing a combination of instruction sets, or any other processor device, such as a digital signal processor. In at least one embodiment, processor 602 may be coupled to a processor bus 610 that may transmit data signals between processor 602 and other components in computer system 600.

[0044] In at least one embodiment, processor 602 may include, without limitation, an internal "L1" (Level 1) cache ("cache") 604. In at least one embodiment, processor 602 may have a single internal cache or multiple levels of internal cache. In at least one embodiment, the cache may be external to processor 602. In at least one embodiment, processor 602 may also include a combination of internal and external caches. In at least one embodiment, a register file 606 may store different data types in various registers, including, without limitation, integer registers, floating-point registers, status registers, and instruction pointer registers.

[0045] In at least one embodiment, a processor 602 also includes an execution unit 607, which includes, without limitation, logic for performing integer and floating-point operations. The processor 602 may also include a "ROM" (read-only memory) for "ucode" (microcode) that stores microcode for certain macroinstructions. In at least one embodiment, the execution unit 607 may include logic for processing a packed instruction set 609. In at least one embodiment, by including a packed instruction set 609 in an instruction set of a general-purpose processor 602, along with associated instruction execution circuitry, operations used by many multimedia applications may be performed on packed data in a general-purpose processor 602.In at least one embodiment, many multimedia applications can be accelerated and run more efficiently by utilizing the full width of a processor's data bus to perform operations on packed data, eliminating the need to transfer smaller units of data across the processor's data bus to perform one or more operations on one piece of data at a time.

[0046] In at least one embodiment, an execution unit may also be used in microcontrollers, embedded processors, graphics devices, DSPs, and other types of logic circuits. In at least one embodiment, computer system 600 may include, without limitation, memory 620. In at least one embodiment, memory 620 may be implemented as a DRAM device, an SRAM device, a flash memory device, or other memory devices. Memory 620 may store instructions 619 and / or data 621 represented by data signals that may be executed by processor 602.

[0047] In at least one embodiment, a system logic chip may be coupled to a processor bus 610 and a memory 620. In at least one embodiment, the system logic chip may include, without limitation, a memory controller hub (MCH) 616, and the processor 602 may communicate with the MCH 616 via the processor bus 610. In at least one embodiment, the MCH 616 may provide a high-bandwidth memory path 618 to a memory 620 for instruction and data storage and for storing graphics instructions, data, and textures. In at least one embodiment, an MCH 616 may route data signals between a processor 602, a memory 620, and other components in the computer system 600, and may bridge data signals between a processor bus 610, a memory 620, and a system I / O 622.In at least one embodiment, a system logic chip may provide a graphics port for coupling to a graphics controller. In at least one embodiment, the MCH 616 may be coupled to memory 620 via a high-bandwidth memory path 618, and a graphics / video card 612 may be coupled to the MCH 616 via an AGP (Accelerated Graphics Port) interconnect 614.

[0048] In at least one embodiment, computer system 600 may use a system I / O 622 as a proprietary hub interface bus to couple an MCH 616 to an "ICH" (I / O Controller Hub) 630. In at least one embodiment, an ICH 630 may provide direct connections to some I / O devices via a local I / O bus. In at least one embodiment, a local I / O bus may include, without limitation, a high-speed I / O bus for connecting peripherals to a memory 620, a chipset, and a processor 602. Examples include, without limitation, an audio controller 629, a firmware hub (“flash BIOS”) 628, a transceiver 626, a data storage 624, a legacy I / O controller 623 with a user input interface 625 and a keyboard interface, a serial expansion port 627, such as a USB, and a network controller 634.Data storage 624 may include a hard disk drive, a floppy disk drive, a CD-ROM device, a flash memory device, or other mass storage devices. In one embodiment, transceiver 626 includes a restricted FFE 608.

[0049] In at least one embodiment, Fig. 6 a system including interconnected hardware devices or “chips” in the transceiver 626 - e.g., the transceiver 626 includes a chip-to-chip interconnect comprising the source device or transmitter 110, 210, 310 and the destination device or receiver 112, 212, 312, as described with reference to Fig. 1-3. In at least one embodiment, Fig. 6 illustrate an exemplary SoC. In at least one embodiment, the Fig. 6 may be interconnected with proprietary interconnects, standardized interconnects (e.g., PCIe), NVlink®, or a combination thereof. In at least one embodiment, one or more components of system 600 are interconnected via CXL (Compute Express Link) interconnects. In one embodiment, transceiver 626 may include processing circuitry as described with reference to Fig. 1-3. In such embodiments, the processing circuitry may facilitate a method of providing a multi-chip system as described herein.

[0050] Other variations are within the spirit of the present disclosure. Thus, while various modifications and alternative designs are possible for the disclosed techniques, certain illustrated embodiments have been shown in the drawings and described in detail above. It is to be understood, however, that the disclosure is not intended to be limited to any particular form(s), but on the contrary, the intention is to cover all modifications, alternative designs, and equivalents falling within the spirit and scope of the disclosure as defined by the appended claims.

[0051] The use of the terms "a" and "the" and similar designations in the context of describing disclosed embodiments (particularly in the context of the following claims) is to be construed to include both the singular and the plural, unless otherwise stated herein or clearly contradicted by context, and not as a definition of any term. The terms "comprising," "with," "including," and "containing" are to be construed as open-ended terms (i.e., "including, but not limited to") unless otherwise stated. The term "connected," when unaltered and referring to physical connections, is to be construed as partially or wholly contained, affixed, or joined thereto, even if something in between.Specifications of ranges of values ​​are intended merely as a shorthand method for individually referring to each value falling within the range, unless otherwise noted herein, and each value is included in the specification as if individually listed herein. In at least one embodiment, use of the term "set" (e.g., "a set of items") or "subset" is to be understood as a non-empty collection comprising one or more elements, unless otherwise noted or contradicted by context. Further, unless otherwise noted or contradicted by context, the term "subset" of a corresponding set does not necessarily denote a proper subset of the corresponding set; rather, the subset and the corresponding set may be the same.

[0052] Linking expressions, such as clauses of the form "at least one of A, B, and C" or "at least one of A, B, and C," unless expressly stated otherwise or otherwise clearly contradicted by the context, are understood with the context as they are generally used to represent that an item, term, etc., can be either A or B or C, or any non-empty subset of the set of A and B and C. For example, in an illustrative example of a three-element sentence, the linking expressions "at least one of A, B, and C" and "at least one of A, B, and C" refer to one of the following sentences: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Thus, such linking expressions are not intended to generally imply that at least one of A, at least one of B, and at least one of C must be present in certain embodiments.Unless otherwise noted or contradicted by context, the term "plural" indicates a state of plurality (e.g., "a plurality of items" refers to multiple items). In at least one embodiment, the number of items in a plurality is at least two, but may be higher if indicated either explicitly or by context. Furthermore, unless otherwise noted or apparent from context, the phrase "based on" means "at least partially based on" and not "solely based on."

[0053] Operations of processes described herein may be performed in any suitable order unless otherwise specified herein or clearly contradicted by context. In at least one embodiment, a process such as the processes described herein (or variations and / or combinations thereof) is performed under the control of one or more computer systems configured with executable instructions and implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that execute collectively on one or more processors, by hardware, or combinations thereof. In at least one embodiment, code is stored on a computer-readable storage medium, e.g., in the form of a computer program comprising a plurality of instructions executable by one or more processors.In at least one embodiment, a computer-readable storage medium is a non-transitory computer-readable storage medium that excludes transient signals (e.g., a propagating transient electrical or electromagnetic transmission) but includes non-transitory data storage circuitry (e.g., buffers, cache, and queues) within transceivers for transient signals. In at least one embodiment, code (e.g., executable code or source code) is stored on a set of one or more non-transitory computer-readable storage media on which executable instructions (or other memory for storing executable instructions) are stored that, when executed (i.e., as a result of execution) by one or more processors of a computer system, cause a computer system to perform operations described herein.In at least one embodiment, a set of non-transitory computer-readable storage media comprises a plurality of non-transitory computer-readable storage media, and one or more individual non-transitory storage media of a plurality of non-transitory computer-readable storage media lack all code, while a plurality of non-transitory computer-readable storage media collectively store all code. In at least one embodiment, executable instructions are executed such that different instructions are executed by different processors.

[0054] Accordingly, in at least one embodiment, computer systems are configured to implement one or more services that individually or collectively perform operations of processes described herein, and such computer systems are configured with suitable hardware and / or software that enable operations to be performed. Further, a computer system implementing at least one embodiment of the present disclosure is a single device, and in another embodiment, a distributed computer system includes multiple devices that operate differently, such that the distributed computer system performs operations described herein and a single device does not perform all operations.

[0055] The use of any and all examples or exemplary terms (e.g., "such as") provided herein is intended only to better illustrate embodiments of the disclosure and is not intended to limit the scope of the disclosure unless otherwise claimed. No language in the specification should be construed to identify any unclaimed element as essential to the practice of the disclosure.

[0056] All references cited herein, including publications, patent applications, and patents, are hereby incorporated by reference to the same extent as if each reference were individually and expressly indicated to be incorporated by reference and reproduced herein in its entirety.

[0057] The terms "coupled" and "connected," and their derivatives, may be used in the description and claims. It should be understood that these terms are not intended to be synonymous. Rather, in certain examples, "connected" or "coupled" may be used to indicate that two or more elements are in direct or indirect physical or electrical contact with each other. "Coupled" can also mean that two or more elements are not in direct contact with each other, but nevertheless cooperate or interact with each other.

[0058] Unless explicitly stated otherwise, terms such as "receiving", "providing", "obtaining", "using" or similar terms used throughout the specification refer to actions and / or processes of a computer or computing system or similar electronic computing device that manipulates data represented as physical, e.g., electronic, quantities in the registers and / or memory of the computing system and / or converts it into other data similarly represented as physical quantities in the memory, registers, or other such information storage, transmission, or display devices.

[0059] Similarly, the term "processor" may refer to a device or part of a device that processes electronic data from registers and / or memory and transforms that electronic data into other electronic data that can be stored in registers and / or memory. A "computing platform" may include one or more processors. As used herein, the term "software" processes may include, for example, software and / or hardware units that perform work over time, such as tasks, threads, and intelligent agents. Each process may also refer to multiple processes to execute instructions sequentially or in parallel, continuously or intermittently. In at least one embodiment, the terms "system" and "method" are used interchangeably herein, as a system may include one or more methods, and methods may be considered a system.

[0060] This document may contain references to obtaining, acquiring, receiving, or inputting analog or digital data to a subsystem, computer system, or computer-implemented machine. In at least one embodiment, obtaining, acquiring, receiving, or inputting analog and digital data may be performed in various ways, such as by receiving data as a parameter of a function call or a call to an application programming interface. In at least one embodiment, processes of obtaining, acquiring, receiving, or inputting analog or digital data may be performed by transmitting data over a serial or parallel interface. In at least one embodiment, processes of obtaining, acquiring, receiving, or inputting analog or digital data may be performed by transmitting data over a computer network from the providing entity to the acquiring entity.In at least one embodiment, reference may also be made to providing, outputting, transmitting, sending, or presenting analog or digital data. In various examples, processes of providing, outputting, transmitting, sending, or presenting analog or digital data may be performed by transmitting data as an input or output parameter of a function call, a parameter of an application programming interface, or an interprocess communication mechanism.

[0061] While the descriptions contained herein represent exemplary embodiments of described techniques, other architectures may be used to implement described functionality, which are intended to be within the scope of the present disclosure. Furthermore, although specific distributions of responsibilities are defined above for descriptive purposes, various functions and responsibilities may be distributed and allocated in different ways depending on the circumstances.

[0062] Furthermore, while the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that subject matter claimed in the appended claims is not necessarily limited to the specific features or acts described. Rather, specific features and acts are disclosed as exemplary forms of implementing the claims.

[0063] It will be understood that the aspects and embodiments described above are exemplary only and that changes in detail are possible within the scope of the claims.

[0064] Each device, method, and feature disclosed in the description and (where applicable) in the claims and drawings may be provided independently or in any suitable combination.

[0065] Reference numbers used in the claims are for illustrative purposes only and do not limit the scope of the claims.

[0066] The disclosure of the present application also includes the following numbered clauses: Clause 1. A transceiver for transmitting and receiving data packets on a communications channel, the transceiver being intended to perform operations including: Receiving a first request packet comprising a plurality of information fields, the plurality of information fields comprising a first type of operation to be performed on a memory device and a first address in the memory device; Storing the first operation type and the first address in a memory associated with the transceiver; Sending the first request packet having the first address to a destination device; Receiving a second request packet having a second address in the memory device; determining, based at least in part on the first operation type, the first address, and the second address, that the second request packet is part of a sequence of request packets to the target device; Eliminating a portion of the second address in a header of the second request packet to form a third request packet; and Send the third request packet to the target device. Clause 2. The transceiver of Clause 1, wherein determining further comprises: Comparing the first operation type of the first request packet with a second operation type of the second request packet, wherein the first request packet precedes the second request packet; and Determining a match between the first operation type of the first request packet and the second operation type of the second request packet. Clause 3. The transceiver of Clause 1, wherein determining further comprises: Comparing the first address in the first request packet with the second address in the second request packet, wherein the first request packet precedes the second request packet; and Determine that the first address and the second address are in a sequence of addresses. Clause 4. The transceiver of Clause 1, the operations further comprising: Determining, based on the first address and the second address, a size of the operation of the first operation type; Determining, based on the size of the operation, a third address for the first operation type and storing the third address in the memory associated with the transceiver; Receiving a fourth request packet containing the third address; Eliminating the third address in a header of the fourth request packet to form a fifth request packet; and Send the fifth request packet to the target device. Clause 5. The transceiver of Clause 1, wherein the communication channel comprises at least one of a bus, a switch, a network, a crossbar, a daisy chain, and an interconnect fabric. Clause 6. The transceiver of Clause 1, the operations further comprising: Receiving a response packet in response to the third request packet; and Matching the response packet with the third request packet based on a tag field in the response packet. Clause 7. The transceiver of Clause 1, wherein the first operation type comprises at least one of a read operation, a write operation, and a scan operation. Clause 8. The transceiver of clause 1, wherein storing further comprises storing the first operation type and the first address in a data structure in a CAM (Content Addressable Memory) associated with the transceiver. Clause 9. The transceiver of Clause 8, the operations further comprising: Indexing the first operation type in the data structure using a unique process identification (ID). Clause 10. A procedure which includes: Receiving, by a source device, a first request packet comprising a plurality of information fields, the plurality of information fields comprising a first type of operation to be performed on a memory device and a first address in the memory device; Storing the first operation type and the first address in a memory associated with the source device; Sending the first request packet having the first address to a destination device; Receiving a second request packet having a second address in the memory device; determining, based at least in part on the first operation type, the first address, and the second address, that the second request packet is part of a sequence of request packets to the target device; Eliminating a portion of the second address in a header of the second request packet to form a third request packet; and Sending, by the source device, the third request packet to the destination device. Clause 11. The procedure of Clause 10, wherein determining further comprises: Comparing the first operation type of the first request packet with a second operation type of the second request packet, wherein the first request packet precedes the second request packet; and Determining a match between the first operation type of the first request packet and the second operation type of the second request packet. Clause 12. The procedure of Clause 10, wherein determining further comprises: Comparing the first address in the first request packet with the second address in the second request packet, wherein the first request packet precedes the second request packet; and Determine that the first address and the second address are in a sequence of addresses. Clause 13. The procedure of Clause 10, which further includes: Determining, based on the first address and the second address, a size of the operation of the first operation type; Determining, based on the size of the operation, a third address for the first operation type and storing the third address in the memory associated with the source device; Receiving a fourth request packet containing the third address; Eliminating the third address in a header of the fourth request packet to form a fifth request packet; and Send the fifth request packet to the target device. Clause 14. The procedure of Clause 10, which further includes: Receiving a response packet in response to the third request packet; and Matching the response packet with the third request packet based on a tag field in the response packet. Clause 15. The method of Clause 10, wherein the first operation type comprises at least one of a read operation, a write operation, and a scan operation. Clause 16. The method of clause 10, wherein storing further comprises storing the first operation type and the first address in a data structure in a CAM (content addressable memory) associated with the source device. Clause 17. The procedure of Clause 16, which further includes: Indexing the first operation type in the data structure using a unique process identification (ID). Clause 18. A transceiver for transmitting and receiving data on a communications channel, the transceiver being configured to: Receiving a first request packet comprising a plurality of information fields, the plurality of information fields comprising a first type of operation to be performed on a memory device and a first address in the memory device; Storing the first operation type and the first address in a memory associated with the transceiver; Receiving a second request packet containing a first part of a second address; and Determining a second part of the second address based on the first operation type and the first part of the second address. Clause 19. The transceiver of Clause 18, the operations further comprising: Determining, based on the first address and the second address, a size of the operation of the first operation type; Determining, based on the size of the operation, a third address for the first operation type and storing the third address in the memory associated with the transceiver; Receiving a third request packet without the third address; and adding the third address in a header of the third request packet to form a fourth request packet. Clause 20. The transceiver of Clause 18, wherein the communication channel comprises at least one of a bus, a switch, a network, a crossbar, a daisy chain, and an interconnect fabric. Clause 21. The transceiver of Clause 18, the operations further comprising: generating a response packet in response to the second request packet and based on a tag field in the second request packet; and Sending the response packet to a source device. Clause 22. The transceiver of Clause 18, wherein the first operation type comprises at least one of a read operation, a write operation, and a scan operation. Clause 23. The transceiver of Clause 18, wherein storing further comprises storing the first operation type and the first address in a data structure in a cache memory associated with the transceiver. Clause 24. The transceiver of Clause 23, the operations further comprising: Indexing the first operation type in the data structure using a unique process identification (ID).

Claims

[1] Transceiver for transmitting and receiving data packets on a communication channel, the transceiver being intended to perform operations including: Receiving a first request packet comprising a plurality of information fields, the plurality of information fields comprising a first type of operation to be performed on a memory device and a first address in the memory device; Storing the first operation type and the first address in a memory associated with the transceiver; Sending the first request packet having the first address to a destination device; Receiving a second request packet having a second address in the memory device; determining, based at least in part on the first operation type, the first address, and the second address, that the second request packet is part of a sequence of request packets to the target device; Eliminating a portion of the second address in a header of the second request packet to form a third request packet; and Send the third request packet to the target device. [2] The transceiver of claim 1, wherein determining further comprises: Comparing the first operation type of the first request packet with a second operation type of the second request packet, wherein the first request packet precedes the second request packet; and Determining a match between the first operation type of the first request packet and the second operation type of the second request packet. [3] The transceiver of claim 1, wherein determining further comprises: Comparing the first address in the first request packet with the second address in the second request packet, wherein the first request packet precedes the second request packet; and Determine that the first address and the second address are in a sequence of addresses. [4] A transceiver according to any preceding claim, wherein the operations further comprise: Determining, based on the first address and the second address, a size of the operation of the first operation type; Determining, based on the size of the operation, a third address for the first operation type and storing the third address in the memory associated with the transceiver; Receiving a fourth request packet containing the third address; Eliminating the third address in a header of the fourth request packet to form a fifth request packet; and Send the fifth request packet to the target device. [5] A transceiver according to any preceding claim, wherein the communication channel comprises at least one of a bus, a switch, a network, a crossbar, a daisy chain, and an interconnect fabric. [6] A transceiver according to any preceding claim, wherein the operations further comprise: Receiving a response packet in response to the third request packet; and Matching the response packet with the third request packet based on a tag field in the response packet. [7] A transceiver according to any preceding claim, wherein the first operation type comprises at least one of a read operation, a write operation, and a scan operation. [8] The transceiver of any preceding claim, wherein storing further comprises storing the first operation type and the first address in a data structure in a CAM (Content Addressable Memory) associated with the transceiver. [9] The transceiver of claim 8, wherein the operations further comprise: Indexing the first operation type in the data structure using a unique process identification (ID). [10] Procedure comprising: Receiving, by a source device, a first request packet comprising a plurality of information fields, the plurality of information fields comprising a first type of operation to be performed on a memory device and a first address in the memory device; Storing the first operation type and the first address in a memory associated with the source device; Sending the first request packet having the first address to a destination device; Receiving a second request packet having a second address in the memory device; determining, based at least in part on the first operation type, the first address, and the second address, that the second request packet is part of a sequence of request packets to the target device; Eliminating a portion of the second address in a header of the second request packet to form a third request packet; and Sending, by the source device, the third request packet to the destination device. [11] The method of claim 10, wherein determining further comprises: Comparing the first operation type of the first request packet with a second operation type of the second request packet, wherein the first request packet precedes the second request packet; and Determining a match between the first operation type of the first request packet and the second operation type of the second request packet. [12] The method of claim 10, wherein determining further comprises: Comparing the first address in the first request packet with the second address in the second request packet, wherein the first request packet precedes the second request packet; and Determine that the first address and the second address are in a sequence of addresses. [13] A method according to any one of claims 10 to 12, further comprising: Determining, based on the first address and the second address, a size of the operation of the first operation type; Determining, based on the size of the operation, a third address for the first operation type and storing the third address in the memory associated with the source device; Receiving a fourth request packet containing the third address; Eliminating the third address in a header of the fourth request packet to form a fifth request packet; and Send the fifth request packet to the target device. [14] A method according to any one of claims 10 to 13, further comprising: Receiving a response packet in response to the third request packet; and Matching the response packet with the third request packet based on a tag field in the response packet. [15] The method of any one of claims 10 to 14, wherein the first operation type comprises at least one of a read operation, a write operation, and a scan operation. [16] The method of any of claims 10 to 15, wherein storing further comprises storing the first operation type and the first address in a data structure in a CAM (Content Addressable Memory) associated with the source device. [17] The method of claim 16, further comprising: Indexing the first operation type in the data structure using a unique process identification (ID). [18] Transceiver for transmitting and receiving data on a communication channel, the transceiver being configured to: Receiving a first request packet comprising a plurality of information fields, the plurality of information fields comprising a first type of operation to be performed on a memory device and a first address in the memory device; Storing the first operation type and the first address in a memory associated with the transceiver; Receiving a second request packet containing a first part of a second address, and Determining a second part of the second address based on the first operation type and the first part of the second address. [19] The transceiver of claim 18, wherein the operations further comprise: Determining, based on the first address and the second address, a size of the operation of the first operation type; Determining, based on the size of the operation, a third address for the first operation type and storing the third address in the memory associated with the transceiver; Receiving a third request packet without the third address; and Adding the third address in a header of the third request packet to form a fourth request packet. [20] The transceiver of claim 18 or 19, wherein the communication channel comprises at least one of a bus, a switch, a network, a crossbar, a daisy chain, and an interconnect fabric. [21] The transceiver of claim 18, 19 or 20, wherein the operations further comprise: generating a response packet in response to the second request packet and based on a tag field in the second request packet; and Sending the response packet to a source device. [22] The transceiver of any one of claims 18 to 21, wherein the first operation type comprises at least one of a read operation, a write operation, and a scan operation. [23] The transceiver of any one of claims 18 to 22, wherein storing further comprises storing the first operation type and the first address in a data structure in a cache memory associated with the transceiver. [24] The transceiver of claim 23, wherein the operations further comprise: Indexing the first operation type in the data structure using a unique process identification (ID).

Images