Address processing system, method, chip and electronic device

Abstract

This application relates to an address processing system, method, chip, and electronic device. The request sending end is configured to: upon receiving a latest request operation, query whether the target address in the latest request operation matches in the sending end's address cache; if a match is found, compress the address bits of the latest request operation using a preset compression method to obtain a request to be sent; generate first metadata corresponding to the address compression; and encapsulate the request to be sent and the first metadata data packet into a first flow control unit (Flit). The request receiving end is configured to: decode the first flow control unit (Flit); based on the first indication information in the decoded first metadata, determine that the request to be sent is a request obtained after address compression; based on the second indication information obtained after decoding, retrieve the compressed address bits from the receiving end's address cache; and reconstruct the real address based on the address bits in the decoded request to be sent and the compressed address bits. This improves link resource utilization.

Description

Technical Field

[0001] This application relates to the field of chip technology, and in particular to an address processing system, method, chip, and electronic device. Background Technology

[0002] For memory-centric computing chips, such as Graphics Processing Units (GPUs), the Flow Control Unit (Flit) format better meets their requirements for high-speed interconnects. The Flit design simplifies GPU integration complexity to the greatest extent, allowing for almost seamless integration with buses such as the Advanced eXtensible Interface (AXI). Furthermore, performing flow control, error correction, data management, and encoding / decoding at the Flit level achieves better bandwidth efficiency and latency. The Transaction Layer (TL) Flit format is a commonly used format for data transmission at the transaction layer in high-speed interconnect protocols. The TL layer's control information flow control units (Control Flits) can flexibly mix and package different types of control messages, including read / write requests, read / write responses, and flow control information. They can also mix and package control information destined for different nodes, improving the protocol's flexibility and efficiency.

[0003] However, the number of requests that can be transmitted per unit bandwidth is reduced, resulting in low link resource utilization. Summary of the Invention

[0004] Therefore, it is necessary to provide an address processing system, method, chip, and electronic device that can improve the utilization of link resources to address the above-mentioned technical problems.

[0005] In a first aspect, this application provides an address processing system, including: a request sender and a request receiver;

[0006] The request sending end is used to: after receiving the latest request operation, query whether the target address in the latest request operation is matched in the sending end address cache, the sending end address cache is used to store addresses in historical request operations; if matched, compress the address bits of the latest request operation using a preset compression method to obtain the request to be sent;

[0007] Generate first metadata corresponding to address compression, the first metadata including: first indication information indicating that the request to be sent is a request obtained by address compression, and second indication information indicating that the target address is located in the cache line of the sender's address cache;

[0008] The request to be sent and the first metadata packet are encapsulated into a first flow control unit Flit, and the first flow control unit Flit is sent to the request receiving end;

[0009] The request receiving end is configured to: decode the first flow control unit Flit; determine, based on the first indication information in the first metadata obtained by decoding, that the request to be sent is a request obtained after address compression; and then obtain the compressed address bits from the receiving end address cache based on the second indication information obtained by decoding. The receiving end address cache and the sending end address cache have the same structure. The compressed address bits are obtained by the request receiving end compressing the target address using the preset compression method after the request sending end first receives the request operation of the target address and stores the target address in the sending end address cache, and then storing the compressed address bits in the cache line of the receiving end address cache that is the same as the target address.

[0010] The real address is reconstructed based on the compressed address bits in the decoded request to be sent and the compressed address bits.

[0011] Secondly, this application provides an address processing method applied to a request sending end, the method comprising:

[0012] Upon receiving the latest request operation, check whether the target address in the latest request operation is matched in the sender address cache, which is used to store addresses in historical request operations;

[0013] If a match is found, the address bits of the latest request operation are compressed using a preset compression method to obtain the request to be sent.

[0014] Generate first metadata corresponding to address compression, the first metadata including: first indication information indicating that the request to be sent is a request obtained by address compression, and second indication information indicating that the target address is located in the cache line of the sender's address cache;

[0015] The request to be sent and the first metadata packet are encapsulated into a first flow control unit (Flit). The first flow control unit (Flit) is sent to the request receiving end to instruct the request receiving end to decode the first flow control unit (Flit). Based on the first indication information in the decoded first metadata, it is determined that the request to be sent is a request obtained after address compression. Based on the second indication information obtained after decoding, the compressed address bits are obtained from the receiving end address cache. The receiving end address cache and the sending end address cache have the same structure. The compressed address bits are obtained after the request sending end first receives the request operation of the target address and stores the target address in the sending end address cache. The receiving end then compresses the target address using the preset compression method to obtain the compressed address bits, and stores them in the same cache line as the target address in the receiving end address cache. Finally, the real address is reconstructed based on the compressed address bits in the decoded request to be sent and the compressed address bits.

[0016] Thirdly, this application provides an address processing method applied to a request receiving end, the method comprising:

[0017] The system receives a first flow control unit Flit from the request sender. The first flow control unit Flit is obtained by encapsulating the request to be sent and the first metadata data corresponding to address compression. The first metadata includes: first indication information indicating that the request to be sent is a request obtained through address compression, and second indication information indicating that the target address is located in the cache line of the sender's address cache. The request to be sent is obtained by compressing the address bits of the latest request operation. The address compression is performed after receiving the latest request operation and finding that the target address in the latest request operation is hit in the sender's address cache.

[0018] The first flow control unit Flit is decoded. Based on the first indication information in the first metadata obtained by decoding, it is determined that the request to be sent is a request obtained after address compression. Based on the second indication information obtained by decoding, the compressed address bits are obtained from the receiving end address cache. The receiving end address cache and the sending end address cache have the same structure. The compressed address bits are obtained by the receiving end compressing the target address using the preset compression method after the request sending end first receives the request operation of the target address and stores the target address in the sending end address cache. The compressed address bits are then stored in the cache line of the receiving end address cache that is the same as the target address.

[0019] The real address is reconstructed based on the compressed address bits in the decoded request to be sent and the compressed address bits.

[0020] Fourthly, this application also provides a chip including the above-described address processing system.

[0021] Fifthly, this application also provides an electronic device including the aforementioned chip.

[0022] The aforementioned address processing system, method, chip, and electronic device include: a request sending end and a request receiving end; the request sending end is configured to: upon receiving a latest request operation, query whether the target address in the latest request operation is matched in the sending end address cache, the sending end address cache being used to store addresses in historical request operations; if matched, compress the address bits of the latest request operation using a preset compression method to obtain a request to be sent; generate first metadata corresponding to the address compression, the first metadata including: first indication information indicating that the request to be sent is a request obtained through address compression, and second indication information indicating the cache line where the target address is located in the sending end address cache; encapsulate the request to be sent and the first metadata data packet into a first flow control unit Flit, and send the first flow control unit Flit to the request receiving end; The request receiving end is configured to: decode the first flow control unit Flit; determine, based on the first indication information in the decoded first metadata, that the request to be sent is a request obtained through address compression; then, based on the decoded second indication information, retrieve the compressed address bits from the receiving end address cache. The receiving end address cache and the sending end address cache have the same structure. The compressed address bits are obtained after the request sending end first receives the request operation for the target address and stores the target address in the sending end address cache, and then the request receiving end compresses the target address using the preset compression method, storing the compressed address bits in the same cache line as the target address in the receiving end address cache; and reconstruct the real address based on the compressed address bits in the decoded request to be sent and the compressed address bits. Address compression can reduce redundant information during data transmission, enabling more effective data to be carried in the same transmission unit, thus improving link resource utilization. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a schematic diagram of the address processing system in one embodiment;

[0025] Figure 2 Here is a schematic diagram of the address cache structure in one embodiment. Figure 1 ;

[0026] Figure 3 Here is a schematic diagram of the address cache structure in one embodiment. Figure 2 ;

[0027] Figure 4 This is a flowchart illustrating the address processing method of the request sending end in one embodiment. Figure 1 ;

[0028] Figure 5 This is a module structure diagram of a request sending end in one embodiment;

[0029] Figure 6 This is a schematic diagram of the address processing method of the request sending end in one embodiment;

[0030] Figure 7 This is a flowchart illustrating the address processing method of the request sending end in one embodiment. Figure 2 ;

[0031] Figure 8 This is a flowchart illustrating the method for requesting the address processing of the receiving end in one embodiment. Figure 1 ;

[0032] Figure 9 This is a module structure diagram of a request receiving end in one embodiment;

[0033] Figure 10 This is a schematic diagram of a method for requesting the address of the receiving end in one embodiment;

[0034] Figure 11 This is a flowchart illustrating the method for requesting the address processing of the receiving end in one embodiment. Figure 2 . Detailed Implementation

[0035] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0036] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0037] In some embodiments, an address processing system is provided, see [link to relevant documentation]. Figure 1 As shown, the address processing system includes a request sender and a request receiver.

[0038] The request sending end is configured to: upon receiving a latest request operation, query whether the target address in the latest request operation is matched in the sending end address cache, which is used to store addresses in historical request operations; if matched, compress the address bits of the latest request operation using a preset compression method to obtain a request to be sent; generate first metadata corresponding to the address compression, the first metadata including: first indication information indicating that the request to be sent is a request obtained through address compression, and second indication information indicating the cache line where the target address is located in the sending end address cache; encapsulate the request to be sent and the first metadata data packet into a first flow control unit Flit, and send the first flow control unit Flit to the request receiving end;

[0039] The request receiving end is configured to: decode the first flow control unit Flit; determine, based on the first indication information in the decoded first metadata, that the request to be sent is a request obtained through address compression; then, based on the second indication information obtained through decoding, obtain the compressed address bits from the receiving end address cache. The receiving end address cache and the sending end address cache have the same structure. The compressed address bits are obtained by the request receiving end compressing the target address using the preset compression method after the request sending end first receives the request operation of the target address and stores the target address in the sending end address cache, and then storing the compressed address bits in the cache line of the receiving end address cache that is the same as the target address; and reconstruct the real address based on the compressed address bits in the decoded request to be sent and the compressed address bits.

[0040] Optionally, the request sender can receive request operations from the transaction layer input interface, and can use the most recently received request operation as the latest request operation.

[0041] Optionally, the request operation can be a memory-semantic request. For example, the request operation can be a transaction layer request (TLreq).

[0042] Optionally, the requested operation can be a memory read operation or a memory write operation.

[0043] Optionally, the request operation may include the device identifier of the destination device, the device identifier of the source device, and the specific address. For ease of explanation, in this embodiment, the device identifier of the destination device carried in the latest request operation is represented by dst_id, the device identifier of the source device is represented by src_id, and the specific address is referred to as the target address.

[0044] Optionally, after receiving the latest request operation, the request sender obtains the target address from the latest request operation and checks whether the target address is hit in the sender's address cache.

[0045] Optionally, the sender address cache stores the addresses of all previously received request operations.

[0046] Optionally, the sender's address cache and the receiver's address cache have the same structure and storage method. For an address stored in a cache line of the sender's address cache, the receiver's address cache stores the corresponding compressed address bits in that cache line. The compressed address bits are obtained by the receiver compressing the address using the aforementioned preset compression method after the requesting sender first receives the request operation for that address and stores it in the sender's address cache, and then storing the compressed address bits in the same cache line as that address in the receiver's address cache.

[0047] Optionally, the target address can be matched with each address stored in the sender's address cache. If the target address matches any of the addresses, then the target address is determined to have been hit in the sender's address cache.

[0048] Optionally, if the target address is the same as any other address, it can be determined that the target address and that address are a successful match.

[0049] Optionally, if it is determined that the target address is hit in the sender's address cache, the address bits of the latest request operation are compressed using a preset compression method to obtain the request to be sent. For example: before compression, req_addr[56:2] is a double-word aligned address; after compression, req_addr[19:6] is used to support 64-byte aligned blocks for addressing within a 1MB area. In this case, before compression, the width of req_addr is 57 bits, and the lowest 2 bits are fixed at 0 (because it is double-word aligned); after compression, the width of req_addr is 20 bits, and the lowest 6 bits are fixed at 0 (because it is a 64-byte aligned block).

[0050] Optionally, if it is determined that the target address is hit in the sender's address cache, first metadata corresponding to address compression is generated. The first metadata includes: first indication information indicating that the request to be sent is a request obtained by address compression, and second indication information indicating that the target address is located in the cache line of the sender's address cache.

[0051] As described above, the sender's address cache and the receiver's address cache have the same structure and storage method. For an address stored in a cache line of the sender's address cache, the corresponding compressed address bits are stored in the same cache line of the receiver's address cache. If it is determined that the target address is hit in the sender's address cache, the cache line containing the target address in the sender's address cache and the cache line containing the compressed address bits in the receiver's address cache are the same.

[0052] Optionally, embodiments of this application provide the following parameters: req_type, req_addr_load, and req_addr_way.

[0053] The value of `req_type` indicates whether the address bits of the latest request operation have been compressed. For example, a value of `req_type` of a first preset value indicates that the address bits of the latest request operation have been compressed (i.e., the request to be sent is a request obtained after address compression), and a value of `req_type` of a second preset value indicates that the address bits of the latest request operation have not been compressed.

[0054] The value of `req_addr_load` indicates whether the request receiver needs to store the compressed address bits in the corresponding cache line. For example, when `req_addr_load` is set to the third preset value, the request receiver needs to store the compressed address bits in the corresponding cache line; when `req_addr_load` is set to the fourth preset value, the request receiver does not need to store the compressed address bits in the corresponding cache line. The third preset value can be 1, and the fourth preset value can be 0.

[0055] The value of req_addr_way is the cache line where the target address is located in the sender's address cache.

[0056] Since the address bits of the latest request operation have been compressed, it indicates that the target address is already stored in the sender's address cache, and the receiver's address cache already stores the compressed address bits corresponding to the target address. Therefore, there's no need to store the compressed address bits again. In other words, if `req_type` has the first preset value, then `req_addr_load` has the fourth preset value. Similarly, if the address bits of the latest request operation haven't been compressed, it means that neither the sender's address cache nor the receiver's address cache stores the compressed address bits corresponding to the target address. In this case, it's necessary to request the receiver to store the compressed address bits. Therefore, if `req_type` has the second preset value, then `req_addr_load` has the third preset value. It's clear that there's a certain correlation between the values ​​of `req_type` and `req_addr_load`.

[0057] Optionally, the first metadata includes req_type and req_addr_way, where the value of req_type is a first preset value and the value of req_addr_way is the cache line where the target address is located in the sender's address cache.

[0058] Optionally, the first metadata includes req_addr_load and req_addr_way, where the value of req_addr_load is a fourth preset value, and the value of req_addr_way is the cache line where the target address is located in the sender's address cache.

[0059] Optionally, the first metadata includes req_type, req_addr_load, and req_addr_way, where the value of req_type is a first preset value, the value of req_addr_load is a fourth preset value, and the value of req_addr_way is the cache line where the target address is located in the sender's address cache.

[0060] Optionally, the request sending end encapsulates the request to be sent and the first metadata packet into a first flow control unit Flit, and transmits the first flow control unit Flit downstream, and then to the request receiving end.

[0061] Optionally, the receiving end decodes the received first flow control unit Flit to obtain first metadata and the aforementioned request to be sent. As described above, the first metadata includes first indication information and second indication information. Based on the first indication information, the receiving end can determine that the request to be sent is a request obtained through address compression and requires address reconstruction. Therefore, the receiving end further obtains the compressed address bits from the receiving end address cache based on the second indication information; and reconstructs the real address according to the address bits in the decoded request to be sent and the compressed address bits. The compressed address bits are obtained by the receiving end after the sending end first receives the request operation for the target address and stores the target address in the sending end address cache, and then compresses the target address using the aforementioned preset compression method and stores it in the same cache line as the target address in the receiving end address cache. This process is similar to the execution process of the sending end and the receiving end when the target address is not found in the sending end address cache in the following embodiments, which can be found in the detailed description of the following embodiments.

[0062] For example, the first metadata includes `req_type`, `req_addr_load`, and `req_addr_way`. The value of `req_type` is a first preset value, the value of `req_addr_load` is a fourth preset value, and the value of `req_addr_way` is the cache line where the target address is located in the sending end's address cache. The receiving end can determine that the request to be sent is a request obtained after address compression based on the value of `req_type`, and can determine that there is no need to store the compressed address bits based on the value of `req_addr_load`, since the sending end's address cache and the receiving end's address cache have the same structure and storage method. For an address stored in a certain cache line of the sending end's address cache, the receiving end's address cache stores the corresponding compressed address bits in that cache line. Therefore, the compressed address bits can be obtained from the corresponding cache line of the receiving end's address cache based on the value of `req_addr_way`; the real address can be reconstructed based on the address bits in the decoded request to be sent and the compressed address bits.

[0063] Optionally, after obtaining the real address, the receiving end can transmit the real address and the request to be sent together to the next-level module.

[0064] In the above embodiments, an address processing system is provided, including: a request sending end and a request receiving end; the request sending end is configured to: after receiving a latest request operation, query whether the target address in the latest request operation is matched in the sending end address cache, the sending end address cache being used to store addresses in historical request operations; if matched, compress the address bits of the latest request operation using a preset compression method to obtain a request to be sent; generate first metadata corresponding to the address compression, the first metadata including: first indication information indicating that the request to be sent is a request obtained through address compression, and second indication information indicating the cache line where the target address is located in the sending end address cache; encapsulate the request to be sent and the first metadata data packet into a first flow control unit Flit, and send the first flow control unit Flit to the request receiving end; the request... The receiving end is configured to: decode the first flow control unit Flit; determine, based on the first indication information in the decoded first metadata, that the request to be sent is a request obtained through address compression; then, based on the decoded second indication information, retrieve the compressed address bits from the receiving end address cache. The receiving end address cache and the sending end address cache have the same structure. The compressed address bits are obtained after the sending end first receives the request operation for the target address and stores the target address in the sending end address cache, and then the receiving end compresses the target address using the preset compression method to obtain the compressed address bits, which are then stored in the same cache line as the target address in the receiving end address cache; and reconstruct the real address based on the compressed address bits in the decoded request to be sent and the compressed address bits. Address compression can reduce redundant information during data transmission, enabling more effective data to be carried in the same transmission unit, thus improving link resource utilization.

[0065] In some embodiments, the sender address cache includes a preset number of cache groups, each cache group corresponds to a device identifier of a destination device, each cache group includes at least one cache line, and each cache line is used to store addresses.

[0066] The request sending end is configured to: use the device identifier of the destination device in the latest request operation as an index to find the corresponding first cache group in the sending end address cache; match the addresses stored in each cache line in the first cache group with the target address respectively; if the address stored in any cache line matches the target address successfully, determine that the target address has been hit in the sending end address cache, and generate the second indication information based on the successfully matched cache line.

[0067] The request receiving end is configured to: use the device identifier of the destination device in the request to be sent as an index to find the corresponding second cache group in the receiving end address cache; and obtain the compressed address bits from the cache line indicated by the second indication information in the second cache group.

[0068] Optionally, for application scenarios with small network scale, the sender address cache can be set to include a preset number of cache groups, each cache group corresponds to the device identifier of a destination device, each cache group includes at least one cache line, and each cache line is used to store the address.

[0069] Optionally, the number of cache sets depends on the number of destination devices supported (i.e., the number of dst_ids supported). Each cache set corresponds to a device identifier for a destination device.

[0070] Optionally, a cache line is used to store the address in the request operation.

[0071] Optionally, an offset (Way_offset) can be used to distinguish which cache line (Cache_line) the address is stored in. The value of req_addr_way above can be the offset (Way_offset) corresponding to the target address.

[0072] Optionally, after receiving the latest request operation, the request sending end obtains the device identifier of the destination device from the latest request operation. Using the device identifier of the destination device as an index, it searches for the corresponding cache group in the sending end address cache. For ease of explanation, this cache group is referred to as the first cache group. Then, the addresses stored in each cache line in the first cache group are matched with the target address. If the address stored in any cache line is the same as the target address, it is determined that the address stored in that cache line matches the target address successfully. Therefore, it is determined that the target address has been hit in the sending end address cache, and the second indication information is generated based on that cache line.

[0073] Optionally, the offset (Way_offset) corresponding to the successfully matched cache line can be obtained, and this offset (Way_offset) can be used as the value of req_addr_way. The values ​​of req_addr_way and req_addr_way can be used as the second indication information.

[0074] As described above, the sending-end address cache and the receiving-end address cache have the same structure and storage method. That is, the receiving-end address cache also includes a preset number of cache groups, each cache group corresponding to a device identifier of a destination device, and each cache group includes at least one cache line. For an address stored in a cache line of the sending-end address cache, the receiving-end address cache stores the corresponding compressed address bits in that cache line. After receiving the first flow control unit Flit, the request receiving end decodes the first flow control unit Flit to obtain the first metadata and the aforementioned request to be sent. It obtains the device identifier of the destination device from the request to be sent and uses the device identifier of the destination device as an index to find the corresponding cache group in the receiving-end address cache. For ease of explanation, this cache group is referred to as the second cache group. Since the second indication information indicates the cache line where the target address is located in the sending-end address cache, and the cache line where the target address is located in the sending-end address cache and the cache line where the compressed address bits are located in the receiving-end address cache are the same, the request receiving end can obtain the compressed address bits from the cache line indicated by the second indication information in the second cache group.

[0075] Optionally, the above description uses the device identifier of the destination device in the latest request operation as the index, but the device identifier of the source device in the latest request operation can also be used as the index.

[0076] In some embodiments, see Figure 2 The diagram illustrates the structure of a sender address cache and a receiver address cache for a small to medium-sized network (less than 16k). The address cache comprises several cache sets, each containing four cache lines, using a 4-way storage format. Upon receiving the latest request operation, the sending end retrieves the destination device identifier (dst_id) / source device identifier (src_id) from the latest request operation. A linear lookup table can be used, with dst_id (assuming 1k) / src_id as the index, to find the corresponding first cache set in the sender address cache. Each cache line in the sender address cache stores a complete address. If the address stored in any cache line of the first cache set is the same as the target address, it is determined whether the target address is already stored in the sender address cache (i.e., a hit). If the addresses stored in all cache lines of the first cache set are different from the target address, it is determined that the target address is not stored in the sender address cache (i.e., a miss).

[0077] The above embodiments provide a structural setting for sending-end address caching and receiving-end address caching in application scenarios with small network scale. This setting can improve address lookup efficiency and increase the response speed of request operations.

[0078] In some embodiments, the sender address cache includes a preset number of cache groups, each cache group corresponds to the hash value of the device identifier of a destination device, each cache group includes at least one cache line, and each cache line is used to store the address and the device identifier of the destination device corresponding to the cache group.

[0079] The request sending end is configured to: obtain the target hash value of the device identifier of the destination device in the latest request operation; use the target hash value as an index to find the corresponding third cache group in the sending end address cache; match the addresses stored in each cache line of the third cache group with the target address, match the device identifier stored in each cache line of the third cache group with the device identifier in the latest request operation, and if the address and device identifier stored in any cache line are successfully matched, then it is determined that the target address is hit in the sending end address cache, and the second indication information is generated according to the successfully matched cache line.

[0080] The request receiving end is configured to: obtain the target hash value of the device identifier of the destination device in the request to be sent; use the target hash value as an index to find the corresponding fourth cache group in the sender address cache; and obtain the compressed address bits from the cache line indicated by the second indication information in the fourth cache group.

[0081] Optionally, for large-scale network applications (greater than 16K), the sender address cache can be configured to include a preset number of cache groups, each cache group corresponding to the hash value of the device identifier of a destination device, each cache group including at least one cache line, and each cache line used to store the address and the device identifier of the destination device corresponding to the cache group.

[0082] Optionally, the number of cache sets depends on the number of destination devices supported (i.e., the number of dst_ids supported). Each cache set corresponds to a device identifier for a destination device.

[0083] Optionally, a cache line is used to store the address in the request operation and the device identifier of the destination device corresponding to the cache group.

[0084] Optionally, an offset (Way_offset) can be used to distinguish which cache line (Cache_line) the address is stored in. The value of req_addr_way above can be the offset (Way_offset) corresponding to the target address.

[0085] Optionally, after receiving the latest request operation, the request sending end obtains the device identifier of the destination device from the latest request operation and obtains the hash value of the device identifier of the destination device. For ease of explanation, this is referred to as the target hash value in this embodiment.

[0086] Optionally, the device identifier dst_id of the destination device is 64 bits. Using dst_id as input, a hash function (CRC32) is queried to obtain a 14-bit key value, which can be used as the target hash value.

[0087] Optionally, the hash function uses the CRC32 polynomial:

[0088] F= x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11 + x^10 + x^8 + x^7+ x^5 + x^4 + x^2 + x^1 + 1.

[0089] Optionally, after obtaining the target hash value, the corresponding cache group is searched in the sender address cache using the target hash value as an index. For ease of explanation, this cache group is referred to as the third cache group. Then, the addresses stored in each cache line of the third cache group are matched with the target address, and the device identifier of the destination device stored in each cache line of the third cache group is matched with the device identifier of the destination device in the latest request operation. If the address stored in any cache line is the same as the target address, and the stored device identifier is the same as the device identifier in the latest request operation, it is determined that the address stored in the cache line matches the target address and the device identifier stored in the cache line matches the device identifier in the latest request operation. Then, it is determined that the target address has been hit in the sender address cache, and the second indication information is generated based on the cache line.

[0090] Optionally, the offset (Way_offset) corresponding to the successfully matched cache line can be obtained, and this offset (Way_offset) can be used as the value of req_addr_way. The values ​​of req_addr_way and req_addr_way can be used as the second indication information.

[0091] As described above, the sender address cache and receiver address cache have the same structure and storage method. That is, the receiver address cache also includes a preset number of cache groups, each cache group corresponding to the hash value of the device identifier of a destination device, and each cache group includes at least one cache line. For an address stored in a cache line of the sender address cache, the corresponding compressed address bits are stored in that cache line of the receiver address cache. After the request receiver receives the first flow control unit Flit, it decodes the first flow control unit Flit to obtain the first metadata and the aforementioned request to be sent. The device identifier of the destination device is obtained from the request to be sent, and the hash value of the device identifier of the destination device (i.e., the target hash value) is obtained using the same method as the request sender. Using the target hash value as an index, the corresponding cache group is found in the receiver address. For ease of explanation, this cache group is referred to as the fourth cache group. Since the second indication information indicates the cache line where the target address is located in the sending end address cache, and the cache line where the target address is located in the sending end address cache is the same as the cache line where the compressed address bit is located in the receiving end address cache, the requesting receiving end can obtain the compressed address bit from the cache line indicated by the second indication information in the fourth cache group.

[0092] In some embodiments, see Figure 3 The diagram illustrates the structure of sender and receiver address caches in a large-scale network (greater than 16K). It can be implemented using hash tables and SRAM entries. The address cache consists of several cache sets, each containing 8 cache lines, i.e., using an 8-way storage format. After receiving the latest request operation, the sending end obtains the device identifier dst_id of the destination device and the device identifier src_id of the source device from the latest request operation. It then inputs dst_id / src_id into a hash function to obtain the target hash value. Using the target hash value as an index, it searches for the corresponding third cache group in the sending end address cache. Each cache line in the sending end address cache stores the complete address and the device identifier of the destination device corresponding to its cache group. If the address stored in any cache line in the third cache group is the same as the target address, and the stored device identifier is the same as the device identifier in the latest request operation, it is determined whether the target address has been stored in the sending end address cache (i.e., a hit). If no such cache line exists, it is determined that the target address has not been stored in the sending end address cache (i.e., a miss).

[0093] The above embodiments provide a structural setting for sending-end address caching and receiving-end address caching in application scenarios with large-scale networking. This setting can improve the accuracy of address lookup.

[0094] In some embodiments, the request sending end is configured to: if the target address in the latest request operation is not found in the sending end address cache, store the target address in the sending end address cache; generate second metadata corresponding to uncompressed address, the second metadata including: third indication information that the latest request operation has not been address compressed, and fourth indication information of the cache line where the target address is located in the sending end address cache; encapsulate the latest request operation and the second metadata into a second flow control unit Flit, and send the second flow control unit Flit to the request receiving end; the request receiving end is configured to: decode the second flow control unit Flit, and determine that the latest request operation has not been compressed based on the third indication information in the decoded second metadata; compress the target address in the latest request operation using the preset compression method, and store the compressed address bits in the receiving end address cache based on the decoded fourth indication information.

[0095] Optionally, after receiving the latest request operation, the request sending end obtains the target address from the latest request operation and checks whether the target address is matched in the sending end's address cache. If it is not matched, the target address is stored in the sending end's address cache, and the address bits of the latest request operation are not compressed. The latest request operation and the second-level data packet are directly encapsulated into a second flow control unit Flit and sent to the request receiving end.

[0096] Optionally, if the target address in the latest request operation is not found in the sender's address cache, a second metadata corresponding to the uncompressed address is generated. The second metadata includes: a third indication that the latest request operation has not been address compressed, and a fourth indication that the target address is located in the cache line of the sender's address cache.

[0097] As described above, the embodiments of this application provide the following parameters: req_type, req_addr_load, and req_addr_way.

[0098] Optionally, the second metadata includes req_type and req_addr_way, where the value of req_type is a second preset value and the value of req_addr_way is the cache line where the target address is located in the sender's address cache.

[0099] Optionally, the second metadata includes req_addr_load and req_addr_way, where the value of req_addr_load is a third preset value and the value of req_addr_way is the cache line where the target address is located in the sender's address cache.

[0100] Optionally, the second metadata includes req_type, req_addr_load, and req_addr_way, where the value of req_type is a second preset value, the value of req_addr_load is a third preset value, and the value of req_addr_way is the cache line where the target address is located in the sender's address cache.

[0101] Optionally, the request sender encapsulates the latest request operation and the second metadata into a second flow control unit Flit, and transmits the second flow control unit Flit downstream, and then to the request receiver.

[0102] Optionally, the receiving end decodes the received second flow control unit Flit to obtain second metadata and the latest request operation. As described above, the second metadata includes third indication information and fourth indication information. Based on the third indication information, the receiving end can determine that the latest request operation has not been compressed, and uses a preset compression method to compress the target address in the latest request operation, storing the compressed address bits in the cache line indicated by the fourth indication information in the receiving end's address cache. This achieves the aforementioned goal that for any address stored in any cache line of the sending end's address cache, the receiving end's address cache stores the corresponding compressed address bits in that cache line, enabling address reconstruction when a request operation with the same address arrives again.

[0103] For example, the second metadata includes req_type, req_addr_load, and req_addr_way, where the value of req_type is a second preset value, the value of req_addr_load is a third preset value, and the value of req_addr_way is the cache line where the target address is located in the sender's address cache. Based on the value of req_type, the request receiver can determine that the latest request operation has not been compressed, and based on the value of req_addr_load, it can determine the address bits that need to be compressed. Therefore, the request receiver uses a preset compression method to compress the target address in the latest request operation and stores the compressed address bits in the cache line indicated by the fourth indication information in the receiver's address cache.

[0104] It should be noted that the compression method used by the receiving end is the same as the compression method used by the sending end.

[0105] Optionally, the request receiver may transmit the latest request operation to the next-level module.

[0106] In the above embodiments, the request sending end is configured to: if the target address in the latest request operation is not found in the sending end address cache, store the target address in the sending end address cache; generate second metadata corresponding to uncompressed addresses, the second metadata including: third indication information that the latest request operation has not been address compressed, and fourth indication information of the cache line where the target address is located in the sending end address cache; encapsulate the latest request operation and the second metadata into a second flow control unit Flit, and send the second flow control unit Flit to the request receiving end; the request receiving end is configured to: decode the second flow control unit Flit, and determine that the latest request operation has not been compressed based on the third indication information in the decoded second metadata; compress the target address in the latest request operation, and store the compressed address bits in the receiving end address cache based on the decoded fourth indication information. Address compression is supported.

[0107] In some embodiments, the sender address cache includes a preset number of cache groups, each cache group corresponds to a device identifier of a destination device, each cache group includes at least one cache line, and each cache line is used to store addresses.

[0108] The request sending end is configured to: use the device identifier of the destination device in the latest request operation as an index to find the corresponding fifth cache group in the sending end address cache; store the target address in the cache line in the fifth cache group that is in an idle state; and generate the fourth indication information based on the cache line that stores the target address.

[0109] The request receiving end is used to: use the device identifier of the destination device in the latest request operation as an index to find the corresponding sixth cache group in the receiving end address cache; and store the compressed address bits in the cache line indicated by the fourth indication information in the sixth cache group.

[0110] Optionally, for applications with small-scale networks, as described above, the sender address cache can be configured to include a preset number of cache groups. Each cache group corresponds to a device identifier of a destination device, and each cache group includes at least one cache line, with each cache line used to store addresses. The sender address cache and receiver address cache have the same structure and storage method. See above for details, which will not be repeated here.

[0111] Optionally, after receiving the latest request operation, the requesting end retrieves the target address from the latest request operation and checks whether the target address is already stored in the sender's address cache. If the target address is not stored in the sender's address cache (miss), the device identifier of the destination device is retrieved from the latest request operation. Using the device identifier of the destination device as an index, the corresponding cache group is found in the sender's address cache. For ease of explanation, this cache group is referred to as the fifth cache group. The target address is stored in the idle cache line of the fifth cache group, and the fourth indication information is generated based on the cache line storing the target address.

[0112] Optionally, the offset (Way_offset) corresponding to the cache line storing the target address can be obtained, and the offset (Way_offset) can be used as the value of req_addr_way. The values ​​of req_addr_way and req_addr_way can be used as the fourth indication information.

[0113] The receiving end requests that the received second flow control unit Flit be decoded to obtain the second metadata and the latest request operation. The device identifier of the destination device is obtained from the latest request operation. Using the device identifier as an index, the corresponding cache group is found in the receiving end's address cache. For ease of explanation, this cache group is referred to as the sixth cache group. Since the fourth indication information indicates the cache line where the target address is located in the sending end's address cache, in order to ensure that the cache line where the target address is located in the sending end's address cache is consistent with the cache line where the compressed address bits are located in the receiving end's address cache, the receiving end uses a preset compression method to compress the target address in the latest request operation and stores the compressed address bits in the cache line indicated by the fourth indication information in the receiving end's address cache.

[0114] The above embodiments provide solutions for storing the target address in the sender's address cache and storing the compressed address bits in the requester's address cache in application scenarios with small network scale. This setting can improve address lookup efficiency and increase the response speed of request operations.

[0115] In some embodiments, the sender address cache includes a preset number of cache groups, each cache group corresponds to the hash value of the device identifier of a destination device, each cache group includes at least one cache line, and each cache line is used to store the address and the device identifier of the destination device corresponding to the cache group.

[0116] The request sending end is configured to: obtain the target hash value of the device identifier of the destination device in the latest request operation; use the target hash value as an index to find the corresponding seventh cache group in the sending end address cache; store the target address and the device identifier of the destination device in the latest request operation in the cache line in the seventh cache group that is in an idle state, and generate the fourth indication information based on the cache line that stores the target address.

[0117] The request receiving end is configured to: obtain the target hash value of the device identifier of the destination device in the request to be sent; use the target hash value as an index to find the corresponding eighth cache group in the address cache of the sending end; and store the compressed address bits in the cache line indicated by the fourth indication information in the eighth cache group.

[0118] Optionally, for large-scale network applications, as described above, the sender address cache can be configured to include a preset number of cache groups. Each cache group corresponds to the hash value of the destination device's identifier. Each cache group includes at least one cache line, and each cache line stores the address and the device identifier of the destination device corresponding to its cache group. The sender address cache and the receiver address cache have the same structure and storage method. See the above for details, which will not be repeated here.

[0119] Optionally, after receiving the latest request operation, the requesting end retrieves the target address from the latest request operation and checks whether the target address is already stored in the sender's address cache. If the target address is not stored in the sender's address cache (miss), the device identifier of the destination device is retrieved from the latest request operation, and the hash value of the device identifier (i.e., the target hash value) is obtained. Using the target hash value as an index, the corresponding cache group is found in the sender's address cache. For ease of explanation, this cache group is referred to as the seventh cache group. The target address and the device identifier of the destination device in the latest request operation are stored in the cache line that is in an idle state in the seventh cache group, and the fourth indication information is generated based on the cache line that stores the target address.

[0120] Optionally, the offset (Way_offset) corresponding to the cache line storing the target address can be obtained, and the offset (Way_offset) can be used as the value of req_addr_way. The values ​​of req_addr_way and req_addr_way can be used as the fourth indication information.

[0121] The receiving end decodes the received second flow control unit Flit to obtain the second metadata and the latest request operation. It retrieves the device identifier of the destination device from the latest request operation and obtains the hash value (i.e., the target hash value) of the device identifier using the same method as the sending end. Using this target hash value as an index, it searches for the corresponding cache group in the receiving end's address cache. For ease of explanation, this cache group is referred to as the eighth cache group. Since the fourth indication information indicates the cache line where the target address is located in the sending end's address cache, to ensure that the cache line where the target address is located in the sending end's address cache and the cache line where the compressed address bits are located in the receiving end's address cache are consistent, the receiving end compresses the target address in the latest request operation using a preset compression method and stores the compressed address bits in the cache line indicated by the fourth indication information in the eighth cache group.

[0122] The above embodiments provide solutions for storing the target address in the sender's address cache and storing the compressed address bits in the requester's address cache in large-scale network application scenarios. This setting can improve address lookup efficiency and increase the response speed of request operations.

[0123] In some embodiments, an address processing method is provided, applied to the request sending end, see [link to relevant documentation]. Figure 4 As shown, the method includes the following steps:

[0124] Step 401: After receiving the latest request operation, check whether the target address in the latest request operation is matched in the sender address cache. The sender address cache is used to store addresses in historical request operations. If matched, compress the address bits of the latest request operation using a preset compression method to obtain the request to be sent.

[0125] Step 402: Generate first metadata corresponding to address compression. The first metadata includes: first indication information indicating that the request to be sent is a request obtained through address compression, and second indication information indicating that the target address is located in the cache line of the sender's address cache.

[0126] Step 403: Encapsulate the request to be sent and the first metadata into a first flow control unit Flit, and send the first flow control unit Flit to the request receiving end to instruct the request receiving end to decode the first flow control unit Flit. Based on the first indication information in the decoded first metadata, determine that the request to be sent is a request obtained after address compression. Based on the second indication information obtained after decoding, obtain the compressed address bits from the receiving end address cache. The receiving end address cache and the sending end address cache have the same structure. The compressed address bits are obtained after the request sending end first receives the request operation of the target address and stores the target address in the sending end address cache. Then, the request receiving end compresses the target address using the preset compression method to obtain the compressed address bits, and stores them in the cache line of the receiving end address cache that is the same as the target address. Finally, reconstruct the real address based on the compressed address bits in the decoded request to be sent and the compressed address bits.

[0127] In some embodiments, the sending address cache includes a preset number of cache groups, each cache group corresponding to a device identifier of a destination device, each cache group including at least one cache line, and each cache line used to store addresses; the step of querying whether the target address in the latest request operation is matched in the sending address cache includes:

[0128] Using the device identifier of the destination device in the latest request operation as an index, the corresponding first cache group is found in the sender address cache;

[0129] The addresses stored in each cache line of the first cache group are matched with the target address. If the address stored in any cache line matches the target address, it is determined that the target address has been hit in the sender address cache, and the second indication information is generated based on the successfully matched cache line.

[0130] In some embodiments, the sending address cache includes a preset number of cache groups, each cache group corresponding to a hash value of the device identifier of a destination device, each cache group including at least one cache line, and each cache line storing an address and the device identifier of the destination device corresponding to its cache group; the step of querying whether the target address in the latest request operation is matched in the sending address cache includes:

[0131] Obtain the target hash value of the device identifier of the destination device in the latest request operation; use the target hash value as an index to find the corresponding third cache group in the sender address cache;

[0132] The addresses stored in each cache line of the third cache group are matched with the target address, and the device identifiers stored in each cache line of the third cache group are matched with the device identifiers in the latest request operation. If the address and device identifier stored in any cache line are matched successfully, it is determined that the target address has been hit in the sender address cache, and the second indication information is generated based on the successfully matched cache lines.

[0133] In some embodiments, the above method further includes:

[0134] If the target address in the latest request operation is not found in the sender address cache, the target address is stored in the sender address cache;

[0135] Generate second metadata corresponding to the uncompressed address, the second metadata including: third indication information that the latest request operation has not been address compressed, and fourth indication information that the target address is located in the cache line of the sender's address cache;

[0136] The latest request operation and the second metadata are encapsulated into a second traffic control unit Flit, and the second traffic control unit Flit is sent to the request receiving end.

[0137] In some embodiments, the sending address cache includes a preset number of cache groups, each cache group corresponding to a device identifier of a destination device, each cache group including at least one cache line, and each cache line used to store an address; the step of storing the target address in the sending address cache includes:

[0138] Using the device identifier of the destination device in the latest request operation as an index, the corresponding fifth cache group is found in the sender address cache; the target address is stored in the cache line in the fifth cache group that is in an idle state, and the fourth indication information is generated based on the cache line that stores the target address.

[0139] In some embodiments, the sending address cache includes a preset number of cache groups, each cache group corresponding to a hash value of a destination device identifier, each cache group including at least one cache line, and each cache line storing an address and the device identifier of the destination device corresponding to its cache group; the step of storing the target address in the sending address cache includes:

[0140] Obtain the target hash value of the device identifier of the destination device in the latest request operation; use the target hash value as an index to find the corresponding seventh cache group in the sender address cache; store the target address and the device identifier of the destination device in the latest request operation in the cache line in the seventh cache group that is in an idle state, and generate the fourth indication information based on the cache line that stores the target address.

[0141] The specific implementation details of each of the above steps are described above and will not be repeated here.

[0142] In some embodiments, see Figure 5 The diagram illustrates a module structure for a request sender, which includes a request queue, a sender address cache, and an encapsulation module. Based on this module configuration, the address processing methods executed by the request sender include: Figure 6 The steps shown are as follows:

[0143] 1. Receive the latest request operation (Req) from the transaction layer input interface and put the latest request operation into the request queue.

[0144] 2. Retrieve the latest request operation from the request queue and query whether the target address in the latest request operation has been stored in the sender's address cache (query whether it is a hit).

[0145] 3. If it is already stored in the sender address cache (if a hit occurs), compress the address bits of the latest request operation to obtain the request to be sent; generate the first metadata corresponding to the address compression, the first metadata including: a first indication information indicating that the request to be sent is a request obtained through address compression, and a second indication information of the cache line where the target address is located in the sender address cache; the packet encapsulation module encapsulates the request to be sent and the first metadata data packet into a first flow control unit Flit.

[0146] If the target address is not stored in the sender address cache (miss), the target address is stored in the sender address cache; second metadata corresponding to uncompressed address is generated, the second metadata including: third indication information that the latest request operation has not been address compressed, and fourth indication information of the cache line where the target address is located in the sender address cache; the encapsulation module encapsulates the latest request operation and the second metadata into a second flow control unit Flit.

[0147] 4. Transmit the first flow control unit Flit / second flow control unit Flit downstream, and then to the requesting receiving end. Both the first flow control unit Flit and the second flow control unit Flit belong to TL flit.

[0148] In some embodiments, see Figure 7 As shown, an address processing method is provided, executed by the request sending end. After receiving a TL request, the request sending end puts the TL request into a request (req) queue. The TL request is retrieved from the request (req) queue, and it is checked whether the target address in the TL request is already stored in the sending end's address cache. That is, it is checked whether the target address in the TL request is matched in the sending end's address cache. If so, the address bits of the TL request are compressed, and a request with a compressed address (i.e., a request to be sent) is output. Furthermore, the request with the compressed address and the first metadata (including: first indication information indicating that the request to be sent is a request obtained through address compression, and second indication information indicating the cache line where the target address is located in the sending end's address cache) are encapsulated into a first flow control unit Flit output. If not, the target address is stored in the sender address cache, and second metadata is generated (including: third indication information that the TL req is not compressed, and fourth indication information that the target address is located in the cache line of the sender address cache), and the request for the uncompressed address (i.e. the above TL req) is output. The TL req and the second metadata are further encapsulated into the output of the second flow control unit Flit.

[0149] In some embodiments, an address processing method is provided, applied to a request receiving end, see [link to relevant documentation]. Figure 8 As shown, the method includes the following steps:

[0150] Step 801: Receive the first flow control unit Flit from the request sending end. The first flow control unit Flit is obtained by encapsulating the request to be sent and the first metadata data corresponding to address compression. The first metadata includes: first indication information indicating that the request to be sent is a request obtained through address compression, and second indication information indicating that the target address is located in the cache line of the sender's address cache. The request to be sent is obtained by compressing the address bits of the latest request operation. The address compression is performed after receiving the latest request operation and querying that the target address in the latest request operation is hit in the sender's address cache.

[0151] Step 802: Decode the first flow control unit Flit. Based on the first indication information in the decoded first metadata, determine that the request to be sent is a request obtained after address compression. Based on the second indication information obtained after decoding, obtain the compressed address bits from the receiving end address cache. The receiving end address cache and the sending end address cache have the same structure. The compressed address bits are obtained by the receiving end compressing the target address using the preset compression method after the request sending end first receives the request operation of the target address and stores the target address in the sending end address cache. The compressed address bits are then stored in the same cache line as the target address in the receiving end address cache. Reconstruct the real address based on the compressed address bits in the decoded request to be sent and the compressed address bits.

[0152] In some embodiments, the sending-end address cache includes a preset number of cache groups, each cache group corresponding to a device identifier of a destination device, each cache group including at least one cache line, and each cache line used to store addresses; the step of obtaining the compressed address bits from the receiving-end address cache based on the decoded second indication information includes:

[0153] Using the device identifier of the destination device in the request to be sent as an index, the corresponding second cache group is found in the address cache of the receiving end; the compressed address bits are obtained from the cache line indicated by the second indication information in the second cache group.

[0154] In some embodiments, the sending-end address cache includes a preset number of cache groups, each cache group corresponding to a hash value of a destination device identifier, each cache group including at least one cache line, and each cache line storing an address and the device identifier of the destination device corresponding to its cache group; the step of obtaining the compressed address bits from the receiving-end address cache based on the decoded second indication information includes:

[0155] Obtain the target hash value of the device identifier of the destination device in the request to be sent; use the target hash value as an index to find the corresponding fourth cache group in the sender address cache; obtain the compressed address bits from the cache line indicated by the second indication information in the fourth cache group.

[0156] In some embodiments, the method further includes:

[0157] The second flow control unit Flit is decoded, and based on the third indication information in the decoded second metadata, it is determined that the latest request operation has not been compressed; the target address in the latest request operation is compressed, and based on the fourth indication information obtained from decoding, the compressed address bits are stored in the receiving end address cache.

[0158] In some embodiments, the sending-end address cache includes a preset number of cache groups, each cache group corresponding to a device identifier of a destination device, each cache group including at least one cache line, and each cache line used to store addresses; the step of storing the compressed address bits in the receiving-end address cache includes:

[0159] Using the device identifier of the destination device in the latest request operation as an index, the corresponding sixth cache group is found in the receiving end address cache; the compressed address bits are stored in the cache line indicated by the fourth indication information in the sixth cache group.

[0160] In some embodiments, the sending-end address cache includes a preset number of cache groups, each cache group corresponding to a hash value of a destination device identifier, each cache group including at least one cache line, and each cache line storing an address and the device identifier of the destination device corresponding to its cache group; the step of storing the compressed address bits in the receiving-end address cache includes:

[0161] Obtain the target hash value of the device identifier of the destination device in the request to be sent; use the target hash value as an index to find the corresponding eighth cache group in the sender address cache; store the compressed address bits in the cache line indicated by the fourth indication information in the eighth cache group.

[0162] The specific implementation details of each of the above steps are described above and will not be repeated here.

[0163] In some embodiments, see Figure 9 The diagram illustrates a module structure for a request receiver, which includes a decoding module, a receiver address cache, and a request queue. Based on this module configuration, the address processing methods executed by the request receiver include... Figure 10 The steps shown are as follows:

[0164] 1. After receiving the Transaction Layer Flow Control Unit (TL Flit) from the request sender, decode the TL Flit.

[0165] 2. The decoded request enters the request queue. For requests in the queue, it can be determined whether the request has undergone address compression based on the corresponding metadata. If address compression has been performed, the compressed address bits are retrieved based on the corresponding metadata and used to reconstruct and restore the actual address of the request. If address compression has not been performed, the address in the request is compressed, and the compressed address bits are stored in the corresponding cache line in the receiver's address cache.

[0166] 3. If address compression has been performed, the actual address and request information from the request are transmitted to the next-level module. If address compression has not been performed, the latest request operation is transmitted to the next-level module.

[0167] In some embodiments, see Figure 11 As shown, an address processing method is provided, executed by the request receiving end. After receiving the Transaction Layer Flow Control Unit (TL Flit), the request receiving end decodes the TL Flit to obtain metadata. It then determines the value of `Req_type` in the metadata. If the value of `Req_type` is a first preset value, it indicates that address compression has been performed on the current request operation. The compressed address bits are retrieved from the receiving end's address cache, and the real address is reconstructed based on the address bits in the decoded request and the compressed address bits. If the value of `Req_type` is a second preset value, it indicates that address compression has not been performed on the request operation. The target address in the request operation is compressed, and the compressed address bits are stored in the receiving end's address cache. Finally, the corresponding request and the complete address are output to the interface.

[0168] In some embodiments, a scenario is provided where the Flit format is 64 bytes long, and memory read and write operations are performed to access data in memory. Read and write operations, as well as the data, are encapsulated in Flit format for transmission. Uncompressed read and write operations are 16 bytes long, while compressed read and write requests are 8 bytes long. Multiple requests can be encapsulated into a single 64-byte Flit for transmission. The read and write requests are the requests to be sent as described in the above embodiments.

[0169] The address processing method proposed in this application improves protocol efficiency through compressed addressing and direct memory operations at the transaction layer. Compressed caching reduces redundant information during data transmission; for example, a 16-byte request header and footer before compression reduces to 8 bytes after compression, allowing more effective data to be carried within the same transmission unit, thus improving overall protocol efficiency. Low latency is a critical requirement for AI and HPC workloads. Compressed addresses reduce the amount of data transmitted, thereby lowering latency during transmission and meeting the stringent low-latency requirements of AI training and inference. Simultaneously, higher protocol efficiency means more data can be transmitted per unit time, improving bandwidth utilization and optimizing cross-accelerator memory access performance. Compressed address technology reduces the actual amount of data to be transmitted, which correspondingly reduces network bandwidth requirements. In large-scale AI computing clusters with massive data transmission volumes, compressed addresses can improve system data processing capabilities and reduce hardware and operational costs without increasing hardware bandwidth.

[0170] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0171] In some embodiments, a chip is provided, including the address processing system, request sender, or request receiver as described in the foregoing embodiments.

[0172] In some embodiments, an electronic device is provided, including the chip described in the foregoing embodiments.

[0173] In some embodiments, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the address processing method in any of the above embodiments.

[0174] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the address processing method of any of the above embodiments.

[0175] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the address processing method of any of the above embodiments.

[0176] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0177] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0178] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. An address processing system, characterized in that, include: Request sender and request receiver; The request sending end is used to: after receiving the latest request operation, query whether the target address in the latest request operation is matched in the sending end address cache, the sending end address cache is used to store addresses in historical request operations; if matched, compress the address bits of the latest request operation using a preset compression method to obtain the request to be sent; Generate first metadata corresponding to address compression, the first metadata including: first indication information indicating that the request to be sent is a request obtained by address compression, and second indication information indicating that the target address is located in the cache line of the sender's address cache; The request to be sent and the first metadata packet are encapsulated into a first flow control unit Flit, and the first flow control unit Flit is sent to the request receiving end; The request receiving end is configured to: decode the first flow control unit Flit; determine, based on the first indication information in the first metadata obtained by decoding, that the request to be sent is a request obtained after address compression; and then obtain the compressed address bits from the receiving end address cache based on the second indication information obtained by decoding. The receiving end address cache and the sending end address cache have the same structure. The compressed address bits are obtained by the request receiving end compressing the target address using the preset compression method after the request sending end first receives the request operation of the target address and stores the target address in the sending end address cache, and then storing the compressed address bits in the cache line of the receiving end address cache that is the same as the target address. The real address is reconstructed based on the compressed address bits in the decoded request to be sent and the compressed address bits.

2. The system according to claim 1, characterized in that, The sender address cache includes a preset number of cache groups, each cache group corresponds to a device identifier of a destination device, each cache group includes at least one cache line, and each cache line is used to store the address. The request sending end is used to: use the device identifier of the destination device in the latest request operation as an index to find the corresponding first cache group in the sending end address cache; The addresses stored in each cache line of the first cache group are matched with the target address. If the address stored in any cache line matches the target address, it is determined that the target address is hit in the sender address cache, and the second indication information is generated based on the successfully matched cache line. The request receiving end is used to: use the device identifier of the destination device in the request to be sent as an index to find the corresponding second cache group in the receiving end address cache; Obtain the compressed address bits from the cache line indicated by the second indication information in the second cache group.

3. The system according to claim 1, characterized in that, The sender address cache includes a preset number of cache groups, each cache group corresponds to the hash value of the device identifier of a destination device, each cache group includes at least one cache line, and each cache line is used to store the address and the device identifier of the destination device corresponding to the cache group; The request sending end is used to: obtain the target hash value of the device identifier of the destination device in the latest request operation; Using the target hash value as an index, the corresponding third cache group is found in the sender address cache; The addresses stored in each cache line of the third cache group are matched with the target address, and the device identifiers stored in each cache line of the third cache group are matched with the device identifiers in the latest request operation. If the address and device identifier stored in any cache line are matched successfully, it is determined that the target address is hit in the sending address cache, and the second indication information is generated based on the successfully matched cache lines. The request receiving end is used to: obtain the target hash value of the device identifier of the destination device in the request to be sent; Using the target hash value as an index, the corresponding fourth cache group is found in the sender address cache; Obtain the compressed address bits from the cache line indicated by the second indication information in the fourth cache group.

4. The system according to claim 1, characterized in that, The request sending end is configured to: if the target address in the latest request operation is not found in the sending end address cache, store the target address in the sending end address cache; Generate second metadata corresponding to the uncompressed address, the second metadata including: third indication information that the latest request operation has not been address compressed, and fourth indication information that the target address is located in the cache line of the sender's address cache; The latest request operation and the second metadata are encapsulated into a second traffic control unit Flit, and the second traffic control unit Flit is sent to the request receiving end; The request receiving end is configured to: decode the second flow control unit Flit, determine that the latest request operation has not been compressed based on the third indication information in the decoded second metadata; compress the target address in the latest request operation using the preset compression method, and store the compressed address bits in the receiving end address cache based on the fourth indication information obtained from the decoding.

5. The system according to claim 4, characterized in that, The sender address cache includes a preset number of cache groups, each cache group corresponds to a device identifier of a destination device, each cache group includes at least one cache line, and each cache line is used to store the address. The request sending end is used to: use the device identifier of the destination device in the latest request operation as an index to find the corresponding fifth cache group in the sending end address cache; The target address is stored in an idle cache line in the fifth cache group, and the fourth indication information is generated based on the cache line containing the target address. The request receiving end is used to: use the device identifier of the destination device in the latest request operation as an index to find the corresponding sixth cache group in the receiving end address cache; and store the compressed address bits in the cache line indicated by the fourth indication information in the sixth cache group.

6. The system according to claim 4, characterized in that, The sender address cache includes a preset number of cache groups, each cache group corresponds to the hash value of the device identifier of a destination device, each cache group includes at least one cache line, and each cache line is used to store the address and the device identifier of the destination device corresponding to the cache group it belongs to; The request sending end is used to: obtain the target hash value of the device identifier of the destination device in the latest request operation; Using the target hash value as an index, the corresponding seventh cache group is found in the sender address cache; The target address and the device identifier of the destination device in the latest request operation are stored in the idle cache line in the seventh cache group, and the fourth indication information is generated based on the cache line storing the target address; The request receiving end is used to: obtain the target hash value of the device identifier of the destination device in the latest request operation; Using the target hash value as an index, the corresponding eighth cache group is found in the sender address cache; The compressed address bits are stored in the cache line indicated by the fourth indication information in the eighth cache group.

7. An address processing method, characterized in that, Applied to the request sending end, the method includes: Upon receiving the latest request operation, check whether the target address in the latest request operation is matched in the sender address cache, which is used to store addresses in historical request operations; If a match is found, the address bits of the latest request operation are compressed using a preset compression method to obtain the request to be sent. Generate first metadata corresponding to address compression, the first metadata including: first indication information indicating that the request to be sent is a request obtained by address compression, and second indication information indicating that the target address is located in the cache line of the sender's address cache; The request to be sent and the first metadata packet are encapsulated into a first flow control unit (Flit). The first flow control unit (Flit) is sent to the request receiving end to instruct the request receiving end to decode the first flow control unit (Flit). Based on the first indication information in the decoded first metadata, it is determined that the request to be sent is a request obtained after address compression. Based on the second indication information obtained after decoding, the compressed address bits are obtained from the receiving end address cache. The receiving end address cache and the sending end address cache have the same structure. The compressed address bits are obtained after the request sending end first receives the request operation of the target address and stores the target address in the sending end address cache. The receiving end then compresses the target address using the preset compression method to obtain the compressed address bits, and stores them in the same cache line as the target address in the receiving end address cache. Finally, the real address is reconstructed based on the compressed address bits in the decoded request to be sent and the compressed address bits.

8. An address processing method, characterized in that, Applied to the request receiving end, the method includes: The system receives a first flow control unit Flit from the request sender. The first flow control unit Flit is obtained by encapsulating the request to be sent and the first metadata data corresponding to address compression. The first metadata includes: first indication information indicating that the request to be sent is a request obtained through address compression, and second indication information indicating the cache line where the target address is located in the sender's address cache. The request to be sent is obtained by compressing the address bits of the latest request operation. The address compression is performed after receiving the latest request operation and finding that the target address in the latest request operation is hit in the sender's address cache. The first flow control unit Flit is decoded. Based on the first indication information in the first metadata obtained by decoding, it is determined that the request to be sent is a request obtained after address compression. Based on the second indication information obtained by decoding, the compressed address bits are obtained from the receiving end address cache. The receiving end address cache and the sending end address cache have the same structure. The compressed address bits are obtained by the receiving end compressing the target address using a preset compression method after the request sending end first receives the request operation of the target address and stores the target address in the sending end address cache. The compressed address bits are then stored in the cache line of the receiving end address cache that is the same as the target address. The real address is reconstructed based on the compressed address bits in the decoded request to be sent and the compressed address bits.

9. A chip, characterized in that, Includes the address processing system according to any one of claims 1 to 6.

10. An electronic device, characterized in that, Includes the chip as described in claim 9.

Images