Chip-to-chip bandwidth optimization

Abstract

The invention provides chip-to-chip bandwidth optimization. A transceiver for transmitting and receiving data packets over a communication channel is provided. The transceiver receives a first request packet including a plurality of information fields having a first type of operation to be performed on the memory device and a first address. The transceiver stores the first type of operation and the first address in a memory associated with the transceiver and sends a first request packet having the first address to a target device. The transceiver then receives a second request packet, the second request packet including a second address in the memory device, and determines that the second request packet is part of a sequence of request packets to the target device based on the first type of operation, the first address, and the second address. The transceiver then deletes a portion 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 target device.

Description

Technical Field

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

[0002] In modern processing units (such as GPUs and CPUs), there are various communication protocols and interfaces used to transfer data between different chips or components within the processing unit. Examples of such protocols include Peripheral Component Interconnect Express (PCIe) and Etc. These communication protocols typically involve the use of packets or frames with specific data fields that carry information, such as headers, addresses, control bits, and payload data.

[0003] The Coherent Bus Interface (CHI) is a communication protocol that is part of the Advanced Microcontroller Bus Architecture (AMBA) used for communication between two devices in a GPU or system on chip (SoC). AMBA is an open standard for the connection and management of functional blocks in an SoC. It is used to develop multi-processor designs with a large number of controllers and peripherals. CHI can be used in a wide range of applications that require consistency (for example, ensuring that all processors or bus masters in a system see the same view of memory), including mobile, networking, automotive, and data centers. AMBA CHI is designed to maintain performance in systems with growing component counts and traffic. These systems use multiple components, from processor clusters, graphics processors, and storage controllers to I / O bridges, peripheral component interconnect express (PCIe) subsystems, and the interconnect itself. In multi-chip systems (such as GPU systems), inter-chip communication is carried out through chip-to-chip (C2C) input / output (IO) links. However, these IO links take up a lot of space and power. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The present disclosure will be more fully understood through the detailed description given below and the accompanying drawings of various embodiments of the present disclosure. However, the accompanying drawings should not be considered to limit the present disclosure to specific embodiments, but are only for explanation and understanding.

[0005] Figure 1 An example multi-chip system according to some embodiments of the present disclosure is shown;

[0006] Figure 2 An example multi-chip system including an optimized C2C IO link according to some embodiments of the present disclosure is shown;

[0007] Figure 3 An example multi-chip system including an optimized C2C IO link according to some embodiments of the present disclosure is shown;

[0008] Figure 4 illustrates example operations in a method for optimizing bandwidth on a C2C IO link according to some embodiments of the present disclosure;

[0009] Figure 5 illustrates example operations in a method for optimizing bandwidth on a C2C IO link according to some embodiments of the present disclosure;

[0010] Figure 6 An example computer system including a multi-tile system according to some embodiments of the present disclosure is shown. DETAILED DESCRIPTION

[0011] Various aspects of the present disclosure can solve the above-mentioned defects and other challenges by providing a multi-chip system, which includes two or more systems on chip (SoC) connected by an IO link with optimized bandwidth. The multi-chip system can be a processor (e.g., CPU, GPU or DPU). In some embodiments, a source device or a transmitter receives a request packet to be sent to a target device or a 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, the size of the operation, one or more sorting requirements, one or more cacheable attributes, etc. After receiving the request packet, the source device can identify that the request packet is a part of a series of packets to be sent to the target device based on the type of operation, the address of the target device and / or the size of the operation. In one example, a transmitter can receive a request to read some data from a memory associated with a receiver. After receiving such a request, the transmitter can identify that the request packet includes a read operation request, and data can be read from the memory to perform and complete the read operation each time. The sender may then store at least some of the information fields (e.g., address and size) in a memory associated with the sender (e.g., a content addressable memory (CAM)), and when a second request packet associated with the same operation is received, the sender may eliminate a portion of the address or the entire address and send only a portion of the address to the receiver or not send the address at all. Similarly, when a first request packet is received, the receiver may store at least some of the information fields (e.g., address and size) in a cache memory associated with the receiver, and when a second request packet associated with the same operation is received, the receiver may determine to send only a portion of the address because the remainder of the address may be used by a previous or prior request packet. In this way, redundant or low-value fields may be eliminated and bandwidth of the IO link may be saved for other communications.

[0012] In some embodiments, the sender may be able to predict the next address to be used based on the type of operation and / or the size of the operation, thereby completely removing the address field and / or the size field. For example, if the sender receives a request for a write operation of 64kB, and the write operation is to be performed in tranches of 8kB, then the sender may be able to predict the address of the next memory unit to which the next write operation will be performed. Such information may be redundant because the sender and receiver already know what operation is being performed, what the operation size is, what the starting address is, and what the end address of the operation may be based on the first request packet. In this case, the sender (which includes the operation size and / or the next address of the memory unit) may be redundant. Therefore, in some embodiments, the sender may completely remove the address and / or size and send the remaining request packets to the receiver. The receiver (which has stored information from the previous request packet in a cache memory) may be able to determine based on information in the previous or previous request packet that the missing address field and / or the missing size field is a request for the receiver to fill in the missing field.

[0013] The advantages of the embodiments in the present disclosure include compressing data packets to achieve efficient data communication and lower power consumption. Redundant fields or low entropy fields can be compressed to reduce the overall data transmission size, thereby achieving more efficient data transmission and potentially reducing power consumption. Other advantages also include bandwidth optimization. By identifying and reducing the size of low entropy fields, more bandwidth can be effectively utilized to transmit useful information, thereby improving the performance of the entire GPU. Other advantages also include reducing latency. The smaller data packets generated by compressing low entropy fields can reduce communication latency, thereby improving the overall responsiveness of the SoC and the entire GPU. The communication protocol disclosed herein can be used for 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 can support link rates of approximately 212.5GT / s or higher per channel and data transfer rates of 1TB / s or higher.

[0014] Figure 1 1 is a block diagram of a processor (e.g., a GPU, a DPU, or a CPU) that includes 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 system on a chip (SoC) or a functional element referred to as a "core". The transmitter 110 and receiver 112 are generally shown as a system 600, which will be referred to as Figure 6The transmitter 110 may communicate with the receiver 112 via one or more communication layers, including but not limited to the protocol layer 114 and the 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 the data link layer 126 and the protocol layer 124. The transmitter 110 and the receiver 112 may communicate using one or more communication protocols, including but not limited to PCIE and The transmitter 110 and the receiver 112 may be coupled directly or indirectly via an ultra-high-speed data communication interface (such as a C2C IO link 120), through which one or more messages may be sent by the transmitter 110 and received by one or more receivers 112. These messages may be sent in the form of "packets", which will be described in further detail below. Under some protocols (e.g., AMBA-CHI protocols), the transmitter 110 and the receiver 112 may send and receive multiple types of messages, including but not limited to request messages, response messages, and data messages. The request message may include a request to perform a specific type of operation. The response message may include an acknowledgment and / or a response to another request sent to the transmitter. The data message may include a payload, such as one or more data bits. When the transmitter 110 receives a request packet including 80 bits, the transmitter 110 serializes and sends 8 bits in 10 consecutive cycles on a single 8-bit IO link 120, thereby sending a total of 80 bits. For example, in some embodiments, the transmitter may include identification information for identifying the type of packet. In this case, for example, an 80-bit request may require 82 bits total (eg, 80 bits for the request and 2 bits to identify the type of packet being sent).

[0015] Although only two devices are shown for illustrative purposes, GPU 100 may include any number of devices that may be used Interface connection. It is a wired communication protocol developed by Nvidia for short-range semiconductor communication, which can be used for data and control code transmission between CPU and GPU in a processor system and between GPUs only. Protocol layers by which a source device or transmitter 110 and a destination device or receiver 112 can communicate with each other. PHY is the physical, electrical layer responsible for driving and receiving analog signals from devices, as well as other functions. PL is the physical, logical layer (not shown), which includes digital logic that bridges the PHY and data link layers, as well as other functions. DL is the data link layer 116, 126, which is responsible for packetization, link reliability, and link configuration, as well as other functions. TL is the transaction layer 114, 124, which is responsible for protocol bridging and arbitration, providing flow control mechanisms such as spreading traffic over multiple links, maintaining ordering, and other functions.

[0016] Typically, the packet sent over the C2C IO link is wider than the IO link itself. Therefore, the packet is sent over the IO link in multiple parts. For example, if the source device or transmitter 110 is to send an 80-bit packet over an 8-bit link 120, then the packet is divided into 10 equal parts, which are sent in 10 consecutive cycles. The receiver 112 reassembles these 10 parts to form the original packet. Each packet includes multiple information fields 130-140, which include but are not limited to packet type, transaction identification (ID), source device ID, target device ID, payload, header cyclic redundancy check (CRC), data CRC, and flow control. The packet type identifies the type of packet being sent, such as a data packet, a control packet, or an acknowledgment packet. In some implementations, the packet type may be separated from the original packet, and the identification of the packet type may add some additional bits to the transaction. The transaction ID is used to identify and track different transactions between a transmitter (or source device) and a receiver (or target device). The source device ID and the target device ID specify the source and destination of the packet. In In the , each GPU or component on the interconnect is assigned a unique ID to facilitate communication. The payload field carries the actual data being transmitted between devices. Depending on the purpose of the communication, it may include graphics data, compute data, or other information. The header CRC in the packet header ensures data integrity during transmission. The CRC allows the receiver to check for errors and verify that the packet arrives undamaged. The data CRC field of the payload data provides an additional layer of data integrity verification. In addition, flow control mechanisms can be used to manage the flow of data between the sender and the receiver to ensure that data is transmitted at an appropriate rate to prevent data loss or buffer overflow. Some of these information fields are redundant and therefore have low values, and are often referred to as "low entropy" fields. In some cases, the source device or sender 110 can modify or delete such low entropy fields, and the target device or receiver 112 can insert known default values ​​in place of the missing fields.

[0017] Figure 2An example of an example multi-chip system 200 (e.g., a processor such as a GPU, DPU, or CPU) according to some embodiments of the present disclosure is shown. The multi-chip system 200 may include one or more transmitters 210 and one or more receivers 212. Each of the transmitter 210 and the receiver 212 may include a system on chip (SoC) or functional elements, 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 The transmitter 210 and the receiver 212 may be coupled directly or indirectly via a very high-speed data communication interface, such as a C2C IO link 220, through which one or more messages may be sent by the transmitter 210 and received by one or more receivers 212. Similarly, in some cases where the receiver 212 sends one or more messages to the transmitter 210, the receiver 212 may be the transmitter. Although only two devices are shown for purposes of illustration, the processor 200 may include any number of devices that may be coupled via a C2C IO link 220 (e.g., 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, and an interconnect structure.

[0018] Under some protocols (e.g., AMBA-CHI protocol), chip-to-chip transactions between transmitter 210 and receiver 212 may involve completing a protocol sequence using request packets, response packets, and data messages sent through IO link 220. Some transactions may start with a request message 230, which may include many attributes of the request, including but not limited to the type, address, size, ordering requirements, cacheability attributes, etc. of the operation. In some embodiments, the source device or transmitter 210 can delete the sending of low entropy fields by saving a cache of recent requests in the sending and receiving agents. If the transmitter 210 identifies that the values ​​of these attributes used by the new request are the same as the recently sent request (and therefore cached), it deletes sending these attributes. Instead, it sends a field specifying the index of the cache entry that holds the request to the receiver 212. Since the receiver's cache has the same recent message sent by the transmitter 210, the deleted fields can be restored from the cache. Therefore, more messages can be sent by sending fewer bytes of information per request via link 220.

[0019] Go to again Figure 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 of an IO device (not shown). The request packet 230 may include one or more information fields, including but not limited to the type of operation to be performed on the memory device and the address in the memory device. When the transceiver or transmitter 210 receives such a request packet, the transceiver or transmitter 210 may store at least the operation type and / or address in a memory (e.g., a content addressable memory (CAM)) 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 transmitter 210 may index the operation type and / or address in the data structure using a unique process identifier (ID). In some embodiments, the processing logic of the transmitter 210 may store a request packet such as previous_pkt (previous packet) 222. The sender 210 may then send a request packet 230 including the operation type and / or address to a target 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 information field pkttype, the receiver 212 may store the request packet 230 and the information field therein (e.g., in a cache memory of the receiver) as previous_pkt 234. 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).

[0020] The sender 210 may then receive a second request packet 230 from the IO device. The processing logic of the sender 210 may then compare the information field of the second request packet 230 with the information field of the previous_pkt 222, and if there is a match 224 in the operation type or a portion of the address, the processing logic may modify the packet type (pkttype) from unoptimized (UNOPT) to optimized (OPT). When the request packet is designated as an optimized packet, the filter 226 may remove a portion of the address, and the multiplexer 228 may generate a new request packet (e.g., link_pkt) that includes only a portion of the address, and then send it to the receiver 212 via the C2C IO link 220.

[0021] In some embodiments, the IO device can access large sequential areas of memory. For example, reading a 4kB area may require 64 reads, each time reading 64B. In the cache of the source device or transmitter 210, the first 64B read of the new 4kB area cannot be found, so the source device or transmitter 210 will send a non-optimized request with a complete address. In response, the upper part of the address is stored in the cache of the transmitter and the receiver. For subsequent accesses that match the upper part of the address, the transmitter does not send the full address but only sends the lower part of the address. For example, if the address of the first packet is 0x12345000, the full address is sent, and the upper part of the address (e.g., 0x12345) is stored in the cache memory of the transmitter 210 and the receiver 212. When the address of the subsequent packet is 0x12345040, the source device or transmitter 210 removes the upper portion of the address and sends an optimized packet with only 0x040, which indicates to the receiver that everything before the 040 can be filled with a default storage value (e.g., 0x12345). This method can be implemented in any transaction involving fixed-size memory, and typically most read and write operations include fixed-size operations, as described above.

[0022] After receiving the optimized packet, the processing logic of the receiver 212 can determine that the optimized packet includes an abbreviated address that can be restored to its original value using the default value stored in the previous packet 234. The processing logic of the receiver will then merge 236 the two parts of the address (e.g., one part from the optimized packet and one part from the previous packet 234) to generate a response packet 250 (e.g., pkt_out). The response packet 250 may include an acknowledgment of receiving the request packet 230, and / or may include additional requests to the sender 210. After receiving the response packet 250, the sender 210 may match the response packet with a corresponding request packet based on the tag field in the response packet.

[0023] Figure 3 An example multi-chip system 300 including an optimized C2C IO link 320 according to some embodiments of the present disclosure is shown. The multi-chip system 300 may include one or more transmitters 310 and one or more receivers 312. Each of the transmitter 310 and the receiver 312 may include a system on chip (SoC) or functional elements, 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 The transmitter 310 and the receiver 312 may be coupled directly or indirectly via a very high-speed data communication interface, such as a C2C IO link 320, through which one or more messages may be sent by the transmitter 310 and received by one or more receivers 312. Similarly, in some cases where the receiver 312 sends one or more messages to the transmitter 310, the receiver 312 may be the transmitter. Although only two devices are shown for purposes of illustration, the processor 300 may include any number of devices that may communicate via the C2C IO link 320 (e.g., 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 switch, a daisy chain, and an interconnect structure.

[0024] Request message 330 may include many attributes of the request, including but not limited to the type, address, size, ordering requirements, cacheability attributes, etc. of the operation. In some embodiments, the source device or transmitter 310 can delete the sending of low entropy fields by storing the cache of the most recent request in the sending and receiving agent. If the transmitter 310 identifies that the values ​​of these attributes used by the new request are the same as the most recently sent request (therefore cached), it deletes and sends these attributes. On the contrary, it sends a field specifying the index of the cache entry that stores the request to the receiver 312. Since the receiver's cache has the same recent message sent by the transmitter 310, the deleted field can be restored from the cache. Therefore, by sending less bytes of information per request via link 320, more messages can be sent.

[0025] 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 of an IO device (not shown). The request packet 330 may include one or more information fields, including but not limited to the type of operation to be performed on the memory device and the address in the memory device. When the transceiver or transmitter 310 receives such a request packet, the transceiver or transmitter 310 may at least store the operation type and / or address in a memory 322 (e.g., a content addressable memory (CAM)) 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 transmitter 310 may index the operation type and / or address in the data structure using a unique process identifier (ID). The transmitter 310 may then send the request packet 330 including the operation type and / or address to the target device or receiver 312. The receiver 312 may include one or more demultiplexers 338 and one or more filters 336. After receiving the request packet 330 with the information field pkttype, the receiver 312 may store the request packet 330 and the information field therein (e.g., in a cache memory 334 of the receiver). In some embodiments, the storage operation may include indexing the operation type and / or address in the data structure using a unique process identification (ID).

[0026] 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 field of the second request packet 330 with the information field of the previous_pkt, and if there is a match in the operation type or a portion of the address, the processing logic may modify the packet type (pkttype) from unoptimized (UNOPT) to optimized (OPT) and insert a header index (e.g., hdridx). When the request packet is designated as an optimized packet, the filter 326 may delete a portion of the address, and the multiplexer 328 may generate a new request packet (e.g., link_pkt) that includes only a portion of the address, and then send it to the receiver 312 via the C2C IO link 220.

[0027] Upon receiving the optimized packet, the processing logic of the receiver 312 may determine that the optimized packet includes an abbreviated address that may be restored to its original value using the header index. The processing logic of the receiver may then merge 336 the two portions of the address (e.g., one portion from the optimized packet and one portion from the previous packet) to generate a packet 350 (e.g., pkt_out) having the same values ​​as the packet sent, but with the deleted fields restored. Upon receiving the response packet 350, the transmitter 310 may match the response packet to the corresponding request packet based on the tag field in the response packet.

[0028] In some embodiments, the transmitter 310 may determine that the 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., a fixed-size share). Therefore, the transmitter 310 may determine the next address based on the previous address in the previous packet, and store such an expected address in the CAM 322 of the transmitter 310. Similarly, the receiver 312 may also determine that the 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., a fixed-size share). Therefore, the receiver 312 may determine the next address based on the previous address in the previous packet, and store such an expected address in the cache of the receiver 312. When the transmitter 310 receives a request packet 330 with an expected address, the request packet 330 without the expected address is sent, and the stored expected address is updated to the new expected address on both the transmitter side and the receiver side. Therefore, when the receiver 312 receives a request packet without an address field or a size field, the receiver 312 matches the address field with the expected address and updates the expected address to a new expected address.

[0029] For example, instead of storing the above partial address in the cache, the full address adjusted by the size is stored in the cache. The cached address is based on the current address plus the size, and the IO device is expected to access the cached address the next time. For example, if the address of the initial packet is 0x12345000, the full address is sent to the receiver, and both the receiver and the transmitter store the full address plus the size (e.g., 0x12345040) in the cache. When the address of the subsequent packet is 0x12345040, the entire address field is deleted, and the packet is sent without the address or size field, and the caches on the transceiver side and the receiver side are updated to store the new address plus the size (e.g., 0x12345080 (previous address + size)). Therefore, when the address of the next packet is 0x12345080, the address and size of the transaction are not sent to the receiver, and the receiver can decode the new address based on the cached address and size to be 0x12345080. This approach can be implemented in any transaction involving fixed-size memory, and typically most read and write operations involve fixed-size operations, as described above. An advantage of the disclosed embodiment is that the entire address field can be removed when the addresses are consecutive (which may be for IO access). This saves several bytes for each packet sent. Compared to current optimization methods, redundant information is removed from being sent over the C2C link. This enables devices to send more messages using the same bandwidth. It is estimated that an unoptimized request would use 17 bytes, while the current optimization method reduces this request to 7 bytes, saving approximately 60% of the bandwidth.

[0030] Figure 4 Example operations in method 400 for optimizing C2CIO links in a multi-chip system according to some embodiments of the present disclosure are shown. Method 400 may be performed by processing logic, which may include hardware (e.g., a processing device, a circuit, dedicated logic, programmable logic, microcode, hardware of a device, an integrated circuit, etc.), software (e.g., instructions running or executed on a processing device), or a combination thereof. Although shown in a specific sequence or order, the order of these processes may be modified unless otherwise stated. Therefore, the illustrated embodiments should be understood only as examples, and the illustrated processes may be performed in different orders, and some processes may be performed in parallel. In addition, one or more processes may be omitted in various embodiments. Therefore, not all processes are required for each embodiment. Other process flows are also possible.

[0031] Various aspects of the present disclosure may be applied to a multi-chip system that includes an array of functional units (referred to as "tiles" or "cores") connected by C2CIO links. A first functional unit (e.g., a source device) in the array of functional units includes a memory device and a processing device operably 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 performed by an IO device. The request packet may include one or more information fields, including but not limited to the type of operation to be performed on the memory device and the address in the memory device. At operation 420, the source device may store at least the operation type and / or address in a memory (e.g., a content addressable memory (CAM)) 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 address in a data structure using a unique process identifier (ID).

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

[0033] At operation 440, the source device may receive a second request packet from the IO device. At operation 450, the processing logic of the source device may then compare the information field of the second request packet with the information field of previous_pkt, and if there is a match in the operation type or a portion of the address, the processing logic may modify the packet type (pkttype) from unoptimized (UNOPT) to optimized (OPT).

[0034] At operation 460, when the request packet is designated as an optimized packet, the source device may delete a portion of the address, and the source device may generate a new request packet (eg, link_pkt) including only a portion of the address and then send it to the target device through the C2C IO link.

[0035] In some embodiments, the IO device may access a large sequential area of ​​memory. For example, reading a 4kB area may require 64 reads, each reading 64B. The first 64B read of the new 4kB area cannot be found in the source device's cache, so the source device will send a non-optimized request with a full address. In response, the upper portion of the address is saved in the cache of both the sender and the receiver. For subsequent accesses that match the upper portion of the address, the sender does not send the full address but only the lower portion. For example, if the address of the first packet is 0x12345000, the full address is sent, and the upper portion of the address (e.g., 0x12345) is saved in the cache of both the source device and the target device. When the address of the subsequent packet is 0x12345040, the source device deletes the upper portion of the address and sends an optimized packet with only 0x040, which indicates to the receiver that all content before the 040 can be filled with a default storage value (e.g., 0x12345).

[0036] After receiving the optimized packet, the processing logic of the target device can determine that the optimized packet includes an abbreviated address that can be restored to its original value using the default value stored in the previous packet. The processing logic of the receiver will then merge the two parts of the address (e.g., one part from the optimized packet and one part from the previous packet) to generate a response packet (e.g., pkt_out). The response packet can include an acknowledgment of the receipt of the request packet, and / or can include additional requests to the sender. After receiving the response packet, the source device can match the response packet with the corresponding request packet based on the tag field in the response packet.

[0037] Figure 5 Example operations in a method 500 for optimizing a C2CIO link in a multi-chip system according to some embodiments of the present invention are shown. Method 500 may be performed by processing logic, which may include hardware (e.g., a processing device, a circuit, dedicated logic, programmable logic, microcode, hardware of a device, an integrated circuit, etc.), software (e.g., instructions running or executed on a processing device), or a combination thereof. Although shown in a particular sequence or order, the order of these processes may be modified unless otherwise stated. Therefore, the illustrated embodiments should be understood only as examples, and the illustrated processes may be performed in different orders, and some processes may be performed in parallel. In addition, one or more processes may be omitted in various embodiments. Therefore, not all processes are required for each embodiment. Other process flows are also possible.

[0038] At operation 510, the source device may receive a request packet as part of an IO operation performed by an IO device. The request packet may include one or more information fields, including but not limited to the type of operation to be performed on the memory device and the address in the memory device. When the source device receives such a request packet, the source device may at least store the operation type and / or address in a memory (e.g., a content addressable memory (CAM)) 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 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 the target device. After receiving a request packet with an information field pkttype, the target device may store the request packet (e.g., stored in a cache memory of a receiver) and the information fields therein. In some embodiments, the storage operation may include indexing the operation type and / or address in the data structure using a unique process identifier (ID).

[0039] The source device may then receive a second request packet from the IO device. The processing logic of the transmitter may then compare the information field of the second request packet with the information field of previous_pkt, and if there is a match in the operation type or a portion of the address, the processing logic may modify the packet type (pkttype) from unoptimized (UNOPT) to optimized (OPT) and insert a header index (e.g., hdridx). When the request packet is designated as an optimized packet, the source device may delete a portion of the address, and the source device may generate a new request packet (e.g., link_pkt) that includes only a portion of the address, and then send it to the target device via the C2C IO link. Upon receiving the optimized packet, the processing logic of the target device may determine that the optimized packet includes an abbreviated address that may be restored to its original value using the header index. The processing logic of the receiver may then merge the two portions of the address (e.g., one portion from the optimized packet and one portion from the previous packet) to generate a response packet (e.g., pkt_out). The response packet may include an acknowledgment of the receipt of the request packet, and / or may include an additional request to the transmitter. After receiving the response packet, the source device may match the response packet with the corresponding request packet based on the tag field in the response packet.

[0040] At operation 520, the source device may determine that the 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 performed in a series of operations of a predetermined size (e.g., a fixed-size share). Therefore, the source device may determine the next address based on the previous address in the previous packet, and store such an expected address in the CAM of the source device. Similarly, the target device may also determine that the request packet is part of a sequence of packets. For example, if the operation being performed is a read operation, the target device may know that the read operation is performed in a series of operations of a predetermined size (e.g., a fixed-size share). Therefore, the target device may determine the next address based on the previous address in the previous packet, and store such an expected address in the cache of the target device.

[0041] At operation 530, the source device may receive a request packet with an expected address, and at operation 540, send a request packet without the expected address, and update the stored expected address to a new expected address at both the sender side and the receiver side. Therefore, at operation 550, when the target device receives a request packet without an address field or a size field, the target device matches the address field with the expected address and updates the expected address to a new expected address.

[0042] For example, instead of storing the above partial address in the cache, the full address adjusted by the size is stored in the cache. The cached address is based on the current address plus the size, and it is expected that the IO device will access the cached address next time. For example, if the address of the initial packet is 0x12345000, the full address is sent to the receiver, and the receiver and the transmitter both store the full address plus the size (e.g., 0x12345040) in the cache. When the address of the subsequent packet is 0x12345040, the entire address field is deleted, and the packet is sent without the address or size field, and the caches of both the transceiver side and the receiver side are updated to save the new address plus the size (e.g., 0x12345080 (previous address + size)). Therefore, when the address of the next packet is 0x12345080, the address and size of the transaction are not sent to the receiver, and the receiver can decode the new address based on the address and size of the cache to be 0x12345080.

[0043] Advantages of the embodiments in the present disclosure include compressing data packets to achieve efficient data communication and lower power consumption. Redundant or low entropy fields can be compressed to reduce the overall data transmission size, thereby achieving more efficient data transmission and potentially reducing power consumption. Other advantages also include bandwidth optimization. By identifying low entropy fields and reducing the size of low entropy fields, more bandwidth can be effectively utilized to transmit useful information, thereby improving the performance of the entire GPU. Other advantages also include reducing latency. The smaller data packets generated by compressing low entropy fields can reduce communication latency, thereby enhancing the overall responsiveness of the SoC and the entire GPU. The communication protocol disclosed herein can be used in any GPU design, including but not limited to Hopper, Grace data center / server CPU and / or NVSwitch for Hopper, and can support link rates of approximately 212.5GT / s or higher per channel and data transfer rates of 1TB / s or higher.

[0044] Figure 6 A computer system 600 including a multi-chip system according to at least one embodiment is shown. In at least one embodiment, the computer system 600 may be a system with interconnected devices and components, a SOC, or some combination. In at least one embodiment, the computer system 600 is formed by a processor 602, which may include an execution unit for executing instructions. In at least one embodiment, the computer system 600 may include, but is not limited to, components such as the processor 602 for executing algorithms using execution units including logic for processing data. In at least one embodiment, the computer system 600 may include a processor such as Processor series, and / or Core TM or Nervana TM microprocessors available from Intel Corporation of Santa Clara, California, but other systems (including personal computers, engineering workstations, set-top boxes, etc.) with other microprocessors may also be used. In at least one embodiment, the computer system 600 may execute the Microsoft Windows 1000 available from Microsoft Corporation of Redmond, Washington. operating system, but other operating systems (e.g., UNIX and Linux), embedded software, and / or graphical user interfaces may also be used.

[0045] In at least one embodiment, computer system 600 can be used for other devices, such as handheld devices and embedded applications. Some examples of handheld devices include cell phones, Internet protocol devices, digital cameras, personal digital assistants ("PDAs"), and handheld PCs. In at least one embodiment, embedded applications can include microcontrollers, digital signal processors (DSPs), SoCs, network computers ("NetPCs"), set-top boxes, network hubs, wide area network ("WAN") switches, or any other system that can execute one or more instructions. In one embodiment, computer system 600 can be used for various devices, such as graphics processing units (GPUs), network adapters, central processing units, and network devices such as switches (e.g., high-speed direct GPU to GPU interconnects, such as NVIDIA GH100 NVLINK or NVIDIA Quantum 2 64-port InfiniBand NDR switches).

[0046] In at least one embodiment, computer system 600 may include, but is not limited to, processor 602, which may include, but is not limited to, one or more execution units 607, which may be configured to execute Compute Unified Device Architecture ("CUDA") ( Developed by NVIDIA Corporation of Santa Clara, California) program. In at least one embodiment, a CUDA program is at least a portion of a software application program written in the CUDA programming language. In at least one embodiment, the computer system 600 is a single processor desktop or server system. In at least one embodiment, the computer system 600 can be a multi-processor system. In at least one embodiment, the processor 602 can include, but is not limited to, a CISC microprocessor, a RISC microprocessor, a VLIW microprocessor, a processor that implements an instruction set combination, or any other processor device, such as a digital signal processor. In at least one embodiment, the processor 602 can be coupled to a processor bus 610, which can transmit data signals between the processor 602 and other components in the computer system 600.

[0047] In at least one embodiment, processor 602 may include, but is not limited to, a level 1 ("L1") internal cache memory ("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, cache memory may reside 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, register file 606 may store different types of data in various registers, including but not limited to integer registers, floating point registers, status registers, and instruction pointer registers.

[0048] In at least one embodiment, execution unit 607 includes, but is not limited to, logic for performing integer operations and floating point operations, which also resides in processor 602. Processor 602 may also include a microcode ("ucode") read-only memory ("ROM") that stores microcode for certain macroinstructions. In at least one embodiment, execution unit 607 may include logic for processing packed instruction set 609. In at least one embodiment, by including packed instruction set 609 in the instruction set of general purpose processor 602 and associated circuitry for executing the instructions, packed data may be used in general purpose processor 602 to perform operations used by many multimedia applications. In at least one embodiment, many multimedia applications may be accelerated and executed more efficiently by using the full width of the processor's data bus to perform operations on packed data, which may eliminate the need to transfer smaller units of data on the processor's data bus to perform one or more operations one data element at a time.

[0049] In at least one embodiment, the execution unit may also be used in a microcontroller, an embedded processor, a graphics device, a DSP, and other types of logic circuits. In at least one embodiment, the computer system 600 may include, but is not limited to, a memory 620. In at least one embodiment, the memory 620 may be implemented as a DRAM device, an SRAM device, a flash memory device, or other memory device. The memory 620 may store instructions 619 and / or data 621 represented by data signals executed by the processor 602.

[0050] In at least one embodiment, the system logic chip can be coupled to the processor bus 610 and the memory 620. In at least one embodiment, the system logic chip can include, but is not limited to, a memory controller hub ("MCH") 616, and the processor 602 can communicate with the MCH 616 via the processor bus 610. In at least one embodiment, the MCH 616 can provide a high-bandwidth memory path 618 to the memory 620 for instruction and data storage and storage of graphics commands, data, and textures. In at least one embodiment, the MCH 616 can direct data signals between the processor 602, the memory 620, and other components in the computer system 600, and bridge data signals between the processor bus 610, the memory 620, and the system I / O 622. In at least one embodiment, the system logic chip can provide a graphics port for coupling to a graphics controller. In at least one embodiment, the MCH 616 can be coupled to the memory 620 via a high-bandwidth memory path 618, and the graphics / video card 612 can be coupled to the MCH 616 via an accelerated graphics port ("AGP") interconnect 614.

[0051] In at least one embodiment, the computer system 600 may use a system I / O 622, which is a proprietary hub interface bus for coupling the MCH 616 to an I / O controller hub ("ICH") 630. In at least one embodiment, the ICH 630 may provide a direct connection to some I / O devices via a local I / O bus. In at least one embodiment, the local I / O bus may include, but is not limited to, a high-speed I / O bus for connecting peripheral devices to the memory 620, the chipset, and the processor 602. Examples may include, but are not limited to, an audio controller 629, a firmware hub ("flash BIOS") 628, a transceiver 626, a data store 624, a traditional I / O controller 623 including a user input interface 625 and a keyboard interface, a serial expansion port 627 (such as USB), and a network controller 634. The data store 624 may include a hard drive, a floppy disk drive, a CD-ROM device, a flash memory device, or other mass storage device. In one embodiment, the transceiver 626 includes a constrained FFE 608.

[0052] In at least one embodiment, Figure 6 A system is shown including interconnected hardware devices or "chips" in a transceiver 626 - for example, the transceiver 626 includes a chip-to-chip interconnect that includes a source device or transmitter 110, 210, 310 and a destination device or receiver 112, 212, 312, as described in reference Figure 1-Figure 3 In at least one embodiment, Figure 6 An exemplary SoC may be shown. In at least one embodiment, Figure 6 The devices shown may be connected via proprietary interconnects, standardized interconnects (e.g., PCIe), or some combination thereof. In at least one embodiment, one or more components of system 600 are interconnected using a Compute Express Link ("CXL") interconnect. In one embodiment, transceiver 626 may include a Figure 1-Figure 3 In such an embodiment, the processing circuit may facilitate the method of providing a multi-chip system as described herein.

[0053] Other variations are within the spirit of the present disclosure. Thus, while the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described in detail above. However, it should be understood that there is no intention to limit the disclosure to one or more specific forms disclosed, but on the contrary, it is intended to cover all modifications, alternative constructions, and equivalents that fall within the spirit and scope of the present disclosure as defined by the appended claims.

[0054] Unless otherwise noted or clearly contradictory to the context, in the context of describing the disclosed embodiments (particularly in the context of the appended claims), the use of the terms "one" and "an" and "the" and similar referents should be interpreted as covering the singular and plural, rather than as a definition of the term. Unless otherwise noted, the terms "include", "have", "include" and "contain" should be interpreted as open terms (meaning "including but not limited to") unless otherwise noted. The term "connection" (which refers to a physical connection when unmodified) should be interpreted as being partially or completely contained, attached to or connected together, even if there are some intervening objects. Unless otherwise noted herein, references to numerical ranges herein are intended only to be used as a shorthand method of referring to each individual value falling within the range, respectively, and each individual value is incorporated into the specification as if it were individually narrated herein. In at least one embodiment, unless otherwise noted or contradictory to the context, the use of the term "set" (e.g., "item set") or "subset" should be interpreted as a non-empty set including one or more members. Furthermore, unless otherwise indicated or contradicted by context, the term "subset" of a corresponding set does not necessarily mean a proper subset of the corresponding set, but rather a subset and a corresponding set may be equivalent.

[0055] Unless expressly indicated otherwise or clearly contradicted by context, conjunctions such as phrases of the form "at least one of A, B, and C" or "at least one of A, B and C" are understood in context to be generally used to refer to an item, term, or the like, which may be A or B or C, or any non-empty subset of the set of A and B and C. For example, in the illustrative example of a set having three members, the conjunction phrases "at least one of A, B, and C" and "at least one of A, B and C" refer to any of the following sets: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Thus, such conjunction language is generally not intended to imply that certain embodiments require the presence of each of at least one of A, at least one of B, and at least one of C. Additionally, unless otherwise indicated or contradicted by context, the term "plurality" indicates a plural state (e.g., "plurality of items" indicates a plurality of items). In at least one embodiment, the number of items in the plurality of items is at least two, but may be more if expressly indicated or indicated by context. Further, the phrase "based on" means "based at least in part on" rather than "based solely on" unless otherwise specified or clear from context.

[0056] Unless otherwise indicated herein or clearly contradictory to the context, the operations of the processes described herein may be performed in any suitable order. In at least one embodiment, processes such as those described herein (or variations and / or combinations thereof) are performed under the control of one or more computer systems configured with executable instructions and are implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that are jointly executed by hardware or a combination thereof on one or more processors. In at least one embodiment, the code is stored on a computer-readable storage medium in the form of, for example, a computer program that includes a plurality of instructions that can be executed by one or more processors. In at least one embodiment, the computer-readable storage medium is a non-transitory computer-readable storage medium that excludes transient signals (e.g., propagated transient electrical or electromagnetic transmissions), but includes non-transitory data storage circuits (e.g., buffers, caches, and queues) within a transceiver 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 (or other memory for storing executable instructions) on which executable instructions are stored, which, when executed by one or more processors of a computer system (i.e., as a result of being executed), causes the computer system to perform the operations described herein. In at least one embodiment, a set of non-transitory computer-readable storage media includes a plurality of non-transitory computer-readable storage media, and one or more of the non-transitory storage media in the plurality of non-transitory computer-readable storage media lacks all of the code, but rather the plurality of non-transitory computer-readable storage media stores all of the code together. In at least one embodiment, the executable instructions are executed so that different instructions are executed by different processors.

[0057] Thus, in at least one embodiment, a computer system is configured to implement one or more services that individually or collectively perform the operations of the processes described herein, and such a computer system is configured with applicable hardware and / or software that enables the operations to be performed. In addition, a computer system that implements at least one embodiment of the present disclosure is a single device, and in another embodiment is a distributed computer system that includes multiple devices that operate differently, such that the distributed computer system performs the operations described herein, and such that a single device does not perform all operations.

[0058] The use of any and all examples or exemplary language (e.g., "such as") provided herein is intended only to better illustrate embodiments of the present disclosure and does not impose a limitation on the scope of the disclosure unless otherwise required. No language in the specification should be construed as indicating any non-claimed element is essential to practicing the disclosure.

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

[0060] In the specification and claims, the terms "coupled" and "connected," as well as their derivatives, may be used. It should be understood that these terms may not be intended as synonyms for each other. On the contrary, in specific 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" may also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other.

[0061] Unless explicitly stated otherwise, it is understood that throughout the specification, terms such as “receive,” “provide,” “obtain,” “use,” and the like refer to the actions and / or processes of a computer or computing system or similar electronic computing device that manipulates and / or converts data represented as physical quantities (e.g., electronic quantities) in registers and / or memories of the computing system into other data similarly represented as physical quantities in the computing system's memories, registers, or other such information storage, transmission, or display devices.

[0062] In a similar manner, the term "processor" may refer to any device or part of a device that processes electronic data from registers and / or memory and converts the 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, a "software" process may include, for example, software and / or hardware entities that perform work over time, such as tasks, threads, and intelligent agents. Similarly, each process may refer to multiple processes to execute instructions sequentially or in parallel, continuously or intermittently. In at least one embodiment, the terms "system" and "method" may be used interchangeably herein, as long as a system may embody one or more methods, and a method may be considered a system.

[0063] In this document, reference may be made to obtaining, acquiring, receiving, or inputting analog or digital data into a subsystem, a computer system, or a computer-implemented machine. In at least one embodiment, the process of obtaining, acquiring, receiving, or inputting analog and digital data may be accomplished 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, the process of obtaining, acquiring, receiving, or inputting analog or digital data may be accomplished by transmitting data via a serial or parallel interface. In at least one embodiment, the process of obtaining, acquiring, receiving, or inputting analog or digital data may be accomplished by transmitting data from a providing entity to an acquiring entity via a computer network. In at least one embodiment, reference may also be made to providing, outputting, transmitting, sending, or presenting analog or digital data. In various examples, the process of providing, outputting, transmitting, sending, or presenting analog or digital data may be accomplished 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.

[0064] Although the description herein sets forth example embodiments of the described technology, other architectures may be used to implement the described functionality and are intended to fall within the scope of the present disclosure. In addition, although specific responsibilities are defined above for descriptive purposes, various functions and responsibilities may be allocated and divided in different ways, depending on the circumstances.

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

Claims

1. A transceiver for sending and receiving data packets over a communication channel, the transceiver being configured to perform operations comprising: receiving a first request packet including a plurality of information fields including a first type of operation to be performed on a memory device and a first address in the memory device; storing the first type of operation and the first address in a memory associated with the transceiver; sending the first request packet having the first address to a target device; receiving a second request packet including a second address in the memory device; determining, based at least in part on the first type of operation, the first address, and the second address, that the second request packet is part of a sequence of request packets to the target device; deleting a portion of the second address in a header of the second request packet to form a third request packet; as well as The third request packet is sent to the target device.

2. The transceiver of claim 1 , wherein the determining further comprises: comparing the first type of operation in the first request packet with the second type of operation in the second request packet, wherein the first request packet precedes the second request packet; as well as A match is determined between the first type of operation in the first request packet and the second type of operation in the second request packet.

3. The transceiver of claim 1 , wherein the 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; as well as It is determined that the first address and the second address are in a sequence of addresses.

4. The transceiver of claim 1, wherein the operations further comprise: Determining an operation size of the first type of operation based on the first address and the second address; determining a third address for the first type of operation based on the operation size and storing the third address in the memory associated with the transceiver; receiving a fourth request packet including the third address; deleting the third address in a header of the fourth request packet to form a fifth request packet; as well as The fifth request packet is sent to the target device.

5. The transceiver of claim 1, wherein the communication channel comprises at least one of a bus, a switch, a network, a crossbar, a daisy chain, or an interconnect structure.

6. The transceiver of claim 1, wherein the operations further comprise: receiving a response packet in response to the third request packet; as well as The response packet is matched with the third request packet based on the tag field in the response packet.

7. The transceiver of claim 1, wherein the first type of operation comprises at least one of a read operation, a write operation, or a scan operation.

8. The transceiver of claim 1, wherein the storing further comprises: The first type of operation and the first address are stored in a data structure in a content addressable memory CAM associated with the transceiver.

9. The transceiver of claim 8, wherein the operations further comprise: The first type of operation in the data structure is indexed using a unique process identification ID.

10. A method comprising: receiving, by a source device, a first request packet including a plurality of information fields including a first type of operation to be performed on a memory device and a first address in the memory device; storing the first type of operation and the first address in a memory associated with the source device; sending the first request packet having the first address to a target device; receiving a second request packet including a second address in the memory device; determining, based at least in part on the first type of operation, the first address, and the second address, that the second request packet is part of a sequence of request packets to the target device; deleting a portion of the second address in a header of the second request packet to form a third request packet; as well as The third request packet is sent by the source device to the target device.

11. The method of claim 10, wherein the determining further comprises: comparing the first type of operation in the first request packet with the second type of operation in the second request packet, wherein the first request packet precedes the second request packet; as well as A match is determined between the first type of operation in the first request packet and the second type of operation in the second request packet.

12. The method of claim 10, wherein the 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; as well as It is determined that the first address and the second address are in a sequence of addresses.

13. The method of claim 10, further comprising: Determining an operation size of the first type of operation based on the first address and the second address; determining, based on the operation size, a third address for the first type of operation and storing the third address in the memory associated with the source device; receiving a fourth request packet including the third address; deleting the third address in a header of the fourth request packet to form a fifth request packet; as well as The fifth request packet is sent to the target device.

14. The method of claim 10, further comprising: receiving a response packet in response to the third request packet; as well as The response packet is matched with the third request packet based on the tag field in the response packet.

15. The method of claim 10, wherein the first type of operation comprises at least one of a read operation, a write operation, or a scan operation.

16. The method of claim 10, wherein the storing further comprises: The first type of operation and the first address are stored in a data structure in a content addressable memory CAM associated with the source device.

17. The method of claim 16, further comprising: The first type of operation in the data structure is indexed using a unique process identification ID.

18. A transceiver for sending and receiving data over a communication channel, the transceiver being configured to: receiving a first request packet including a plurality of information fields including a first type of operation to be performed on a memory device and a first address in the memory device; storing the first type of operation and the first address in a memory associated with the transceiver; receiving a second request packet including a first portion of a second address; as well as Based on the first type of operation and the first portion of the second address, a second portion of the second address is determined.

19. The transceiver of claim 18, wherein the operations further comprise: Determining an operation size of the first type of operation based on the first address and the second address; determining a third address for the first type of operation based on the operation size and storing the third address in the memory associated with the transceiver; receiving a third request packet without the third address; and The third address is added to a header of the third request packet to form a fourth request packet.

20. The transceiver of claim 18, wherein the communication channel comprises at least one of a bus, a switch, a network, a crossbar, a daisy chain, or an interconnect structure.

21. The transceiver of claim 18, 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; as well as The response packet is sent to the source device.

22. The transceiver of claim 18, wherein the first type of operation comprises at least one of a read operation, a write operation, or a scan operation.

23. The transceiver of claim 18, wherein the storing further comprises: The first type of operation and the first address are stored in a data structure in a cache memory associated with the transceiver.

24. The transceiver of claim 23, wherein the operations further comprise: The first type of operation in the data structure is indexed using a unique process identification ID.

Images