Request merging method and system, chip, device, equipment, medium and product

Abstract

The invention provides a request merging method, a request merging system, a chip, a request merging device, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: determining the unit data volume of write data processed in each beat based on the maximum value of the connection line width of the write data between an upstream module and a memory merging module and the cache line size; based on the request length and the unit data volume of the original requests, determining the request number of the original requests merged in each beat; wherein the total data amount of the original request combined in each beat is smaller than or equal to the unit data amount; and merging the plurality of original requests according to the request quantity to obtain at least one merged request, and mapping data of each original request corresponding to the merged request based on the unit data volume to obtain merged data of the merged request.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a request merging method and system, chip, request merging device, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] In the design of modern parallel computing chips such as Graphics Processing Units (GPUs) and Artificial Intelligence (AI) chips, memory access efficiency plays a crucial role in overall system performance. To reduce the number of accesses to downstream storage modules, memory merging techniques can be used in GPUs / AI to merge multiple original requests at the cache line granularity, generating cache requests adapted to the parallel processing capabilities of the cache modules. The cache requests need to be processed by a cache hash module to determine the target memory or target group, thereby reducing conflicts and improving performance.

[0003] In related technologies, requests are merged according to a fixed number. This merging method is not adapted to the interface data bit width and cache line granularity, resulting in wasted interface data throughput and failing to efficiently merge cached requests in high-performance scenarios. For original requests carrying write data, all write data from the original requests must be collected before the write data is mapped to the corresponding cache line position based on the merging logic. When the maximum value of the number of original requests multiplied by the length of the original requests exceeds the granularity of the cache line, this write data processing method requires an additional data cache area of ​​at least the number of requests multiplied by the maximum request length in bytes to cache the data. Furthermore, it suffers from significant layout and routing issues and timing problems in hardware implementation. Summary of the Invention

[0004] In view of the above, embodiments of this application provide at least one request merging method, request merging system, chip, request merging device, computer equipment, computer-readable storage medium, and computer program product.

[0005] The technical solution of this application embodiment is implemented as follows: On one hand, embodiments of this application provide a request merging method, including: The unit data volume of write data processed per cycle is determined based on the maximum value between the connection width of write data between the upstream module and the memory merging module and the cache line size. Based on the request length and unit data volume of the original request, determine the number of original requests to be merged in each batch; wherein, the total data volume of the original requests merged in each batch is less than or equal to the unit data volume. Multiple original requests are merged according to the number of requests to obtain at least one merged request. The data of each original request corresponding to the merged request is mapped based on the unit data volume to obtain the merged data of the merged request.

[0006] On the other hand, embodiments of this application provide a request merging system, including: The write data merging module is used to determine the unit data volume of write data processed per cycle based on the maximum value between the connection width of write data between the upstream module and the memory merging module and the cache line size. The write data merging module is also used to determine the number of original requests to be merged in each batch based on the request length and unit data volume of the original request; wherein the total amount of data in the original requests merged in each batch is less than or equal to the unit data volume. The request merging module is used to merge multiple original requests according to the number of requests, so as to obtain at least one merged request; The data merging module is also used to map the data of each original request corresponding to the merging request based on the unit data volume, so as to obtain the merged data of the merging request.

[0007] In another aspect, embodiments of this application provide a chip that includes the aforementioned request merging system.

[0008] In another aspect, embodiments of this application provide a computer device, including a memory and a processor. The memory stores a computer program that can run on the processor, and the processor executes the program to implement some or all of the steps in the above-described method.

[0009] In another aspect, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements some or all of the steps in the above-described method.

[0010] In another aspect, embodiments of this application provide a computer program including computer-readable code. When the computer-readable code is run in a computer device, a processor in the computer device executes some or all of the steps for implementing the above-described method.

[0011] In another aspect, embodiments of this application provide a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-described method.

[0012] In this embodiment, the unit data volume of write data processed per cycle is determined based on the maximum value of the connection width and cache line size. The data of each original request corresponding to the merge request is mapped based on this unit data volume. By fixing the amount of write data processed per cycle, the interface's data width can be fully utilized, reducing interface data throughput waste. When M original requests are multiple data access requests with consecutive addresses, and the data volume of the M original requests matches the connection bandwidth, these M original requests can be directly merged into a single merge request without increasing the number of merge requests. When the connection width and cache line size are equal, a relatively good functional performance area (PowerPerformance) is achieved. The balance point of the Area (PPA) is determined by the number of original requests merged per cycle based on the request length and unit data volume of the original request. The total data volume of the original requests merged per cycle is less than or equal to the unit data volume. This adaptive adjustment of the number of original requests merged per cycle based on the request length and unit data volume reduces resource waste or performance degradation caused by different request lengths. As a result, efficient request merging is achieved, which can effectively reduce the number of accesses to downstream memory modules and maintain a high merging effect under different request lengths and address distributions, significantly improving the system's memory access efficiency and resource utilization.

[0013] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of this application. Attached Figure Description

[0014] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application.

[0015] Figure 1 A schematic diagram illustrating the implementation flow of a request merging method provided in an embodiment of this application; Figure 2 This is a schematic diagram illustrating the splitting of original data in a request merging method provided in an embodiment of this application; Figure 3 This is a schematic diagram illustrating the left shift and output of the original data in a request merging method provided in an embodiment of this application; Figure 4 This application provides a schematic diagram of the composition structure of a request merging system. Figure 5 A schematic diagram of the composition structure of a data crossbar switch in a request merging system provided in this application embodiment; Figure 6This application provides a schematic diagram of the composition of a request merging device. Figure 7 This is a schematic diagram of the hardware entity of a computer device provided in an embodiment of this application. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application are further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0017] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0018] If the application documents contain similar descriptions such as "first / second", the following explanation shall be added: the terms "first / second / third" are used only to distinguish similar objects and do not represent a specific order of objects. It is understood that "first / second / third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0019] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terminology used herein is for descriptive purposes only and is not intended to be limiting of this application.

[0020] This application provides a request merging method, which can be executed by the processor of a computer device. The computer device refers to a device with data processing capabilities, such as a server, laptop, tablet, desktop computer, smart TV, set-top box, or mobile device (e.g., mobile phone, portable video player, personal digital assistant, dedicated messaging device, portable gaming device). Figure 1 As shown, the method includes the following steps 101 to 103: Step 101: Determine the unit data volume of write data processed per cycle based on the maximum value between the connection width of the write data between the upstream module and the memory merging module and the cache line size.

[0021] The upstream module refers to the module that issues the original request; it is the request supplier. For example, the upstream module can be a computing unit, a controller, etc. The memory merging module is located between the upstream module and the memory module. It is used to merge the scattered read and write requests sent by the upstream module, combining multiple requests that meet the conditions into a single cache request, which is then sent to the backend storage. Finally, the processing result is returned to the upstream module. The memory merging module can also be called a memory merging system, memory merging device, memory merging unit, request merging system, request merging device, request merging unit, etc.

[0022] In some implementations, the upstream module and the memory merging module can transmit data via a physical connection. Due to wiring resources and timing constraints, a connection width can be defined. The connection width refers to the width of the data bus used for transmitting write data between the upstream module and the memory merging module in the hardware design, measured in bytes. The connection width can be W bytes per cycle, where W is a power of 2. For example, if the upstream module and the memory merging module communicate via a 128-byte data channel, then the write data connection width is 128 bytes. The write data connection width determines the maximum amount of write data that can be transmitted per cycle, thus affecting the interface's throughput.

[0023] It should be noted that the write data connection between the upstream module and the memory merging module is limited, and in actual design, the write data connection can be time-division multiplexed with the request address connection, thereby saving wiring resources and reducing hardware complexity. For example, when the write data connection width is set to 128 bytes / cycle, a maximum of 128 bytes of write data can be transmitted per cycle.

[0024] Cache line size refers to the amount of data contained in a cache line, and can be expressed as cacheline size. Cache line size is an important parameter in request merging system design, determining the basic granularity of memory accesses; that is, each read or write operation can be processed according to the cache line size. Cache line size is closely related to factors such as processor architecture and memory controller design. Cache line size can be expressed in R bytes. For example, the cache line size can be 64 bytes, 128 bytes, etc. For instance, in a system with a cache line size of 64 bytes, each memory access can involve 64 bytes of data.

[0025] Coalesce data granularity refers to the amount of data written per clock cycle, that is, the amount of data that hardware (such as cache, memory modules, memory controllers, and buses) can write within one clock cycle (i.e., one CPU clock cycle). Coalesce data granularity can be determined by the width of the hardware interface. The amount of data written per clock cycle can be expressed as coalesce_data_granularity. For example, coalesce data granularity can be Q bytes, such as 4 bytes.

[0026] In some implementations, if the write data connection width is 128 bytes and the cache line size is also 128 bytes, then the unit data size is 128 bytes; if the write data connection width is 64 bytes and the cache line size is 128 bytes, then the unit data size is still 128 bytes, to ensure that each cache line can be processed completely.

[0027] It should be noted that by comparing the connection width for writing data with the cache line size, the larger of the two is taken as the unit data volume for writing data processed per cycle. This allows for flexible adaptation to changes in interface bandwidth and cache structure under different hardware configurations, thereby maximizing the system's parallel processing capability and overall performance. It ensures that while meeting the interface bandwidth utilization requirements, it also avoids performance degradation caused by cache line boundary limitations.

[0028] Step 102: Based on the request length and unit data volume of the original request, determine the number of original requests to be merged in each batch; wherein, the total data volume of the original requests merged in each batch is less than or equal to the unit data volume.

[0029] An original request refers to a request sent by an upstream module to the request merging system; it can also be called a data access request, an unmerged request, a memory access request, etc. In some implementations, an original request may include read requests and write requests. The attributes of an original request include, but are not limited to: request identifier, initiator identifier, request length, request type, specific data carried in the request, and data shelving of the specific data. The request length indicates the length of data to be read or written in the original request, reflecting the size of the data to be accessed. The request length can be a power of 2.

[0030] The request count refers to the number of original requests merged in each clock cycle, indicating how many original requests can be merged within one clock cycle. The request count depends on the unit data size and the original requests. For example, if the unit data size for write data processed per clock cycle is 128 bytes, and the original request length is 1 byte, then the maximum number of original requests merged per clock cycle is 128. This means that a maximum of 128 original requests with a request length of 1 byte can be merged within one clock cycle.

[0031] In this application, the unit data volume of write data processed in each cycle is fixed. Therefore, the number of original requests merged in each cycle is related to the length of the original requests. For example, if the length of the original requests is small, the number of original requests merged in each cycle may be large; conversely, if the length of the original requests is large, the number of original requests merged in each cycle may be small.

[0032] For example, if the amount of write data processed per cycle is 128 bytes, and the request length is 1 byte, then the number of original requests merged per cycle can be 128. If the amount of write data processed per cycle is 128 bytes, and the request length is 8 bytes, then the number of original requests merged per cycle is 16. This dynamic adjustment mechanism, which changes the number of original requests merged per cycle based on the request length, can be flexibly configured according to different request patterns, thereby improving overall processing efficiency.

[0033] In some implementations, the request length for merging each time block can be determined based on the request length of the original request, the unit data volume of write data processed per block, and the maximum number of original requests merged per block; the number of original requests merged per block can be determined based on the unit data volume and the request length for merging each time block.

[0034] In some implementations, the request length threshold for merging per batch can be determined based on the unit data volume and the maximum number of original requests merged per batch; the number of original requests merged per batch can be determined based on the request length of the original requests, the request length threshold, and the unit data volume.

[0035] Step 103: Merge multiple original requests according to the number of requests to obtain at least one merged request, and map the data of each original request corresponding to the merged request based on the unit data volume to obtain the merged data of the merged request.

[0036] A merge request is a new request generated by combining multiple original requests. The request address and data in a merge request are reorganized for more efficient memory access. The core of merging lies in integrating the addresses and data of multiple original requests, allowing them to be processed uniformly within the same clock cycle. The merging operation not only reduces the number of accesses to downstream memory modules but also effectively utilizes memory bandwidth, improving overall performance.

[0037] Data mapping is used to correctly route the data from the original request to the corresponding location in the cache line. In some implementations, the data from each original request can be split into several byte blocks (sub-data) and mapped to different locations in the cache line according to address offsets. Each data block also carries a corresponding bitmap to identify which bytes are valid. During the merging process, if data from multiple original requests is mapped to the same location, a write-overwrite strategy can be applied to ensure that the final written data meets expectations.

[0038] In some implementations, original requests with the same cache line address are merged into one request based on the number of requests, resulting in at least one merged request.

[0039] In some implementations, the base address of the cache line is matched with the memory addresses of multiple original requests to determine the number of original requests in the same cache line; the number of original requests in the same cache line are merged into one request to obtain at least one merged request.

[0040] In some implementations, multiple original requests are merged according to their response time and request type to obtain at least one merged request. Response time refers to the time it takes for an original request to arrive at the request merging system. Request types include write and read types.

[0041] In some implementations, the requests can be sorted according to their response times, and the number of read requests at the top of the list can be merged into one request, and the number of original requests at the top of the list can be merged into one request, resulting in at least one merged request.

[0042] In this embodiment, the unit data volume of write data processed per cycle is determined based on the maximum value of the connection width and cache line size. The data of each original request corresponding to the merge request is mapped based on this unit data volume. By fixing the amount of write data processed per cycle, the interface's data width can be fully utilized, reducing interface data throughput waste. When M original requests are multiple data access requests with consecutive addresses, and the data volume of the M original requests matches the connection bandwidth, these M original requests can be directly merged into a single merge request without increasing the number of merge requests. When the connection width and cache line size are equal, a relatively good functional performance area (PowerPerformance) is achieved. The balance point of the Area (PPA) is determined by the number of original requests merged per cycle based on the request length and unit data volume of the original request. The total data volume of the original requests merged per cycle is less than or equal to the unit data volume. This adaptive adjustment of the number of original requests merged per cycle based on the request length and unit data volume reduces resource waste or performance degradation caused by different request lengths. As a result, efficient request merging is achieved, which can effectively reduce the number of accesses to downstream memory modules and maintain a high merging effect under different request lengths and address distributions, significantly improving the system's memory access efficiency and resource utilization.

[0043] In some embodiments, step 102 above can be implemented by the following steps 1021 to 1023: Step 1021: Determine the request length threshold for each merge based on the unit data volume and the maximum number of original requests merged per batch.

[0044] The request length threshold refers to the minimum combined request length, used to ensure that data throughput is reasonably allocated within each clock cycle and to avoid wasting interface bandwidth due to excessively small requests. It can be represented as `coalesce_request_length_threshold`. The request length threshold can be Q bytes.

[0045] The maximum number of original requests that can be merged per session is the maximum number of concurrent requests preset during system design. For example, the maximum number of original requests that can be merged per session can be 32.

[0046] In some implementations, the request length threshold for each merge is obtained by dividing the unit data volume by the maximum number of original requests to be merged per batch. For example, coalesce_request_length_thresholdQ = coalesce_data_granularity / M; where coalesce_request_length_threshold represents the request length threshold for each merge, coalesce_data_granularity represents the unit data volume, and M represents the maximum number of original requests to be merged per batch.

[0047] For example, if the unit data volume (coalesce_data_granularity) is 128 bytes and the maximum number of original requests M to be merged per cycle is 32, then the request length threshold Q to be merged per cycle is 4 bytes.

[0048] It should be noted that by setting a request length threshold Q, it can be ensured that the granularity of each request will not be less than the request length threshold during the data mapping process, thereby achieving effective control over the request length, which helps to improve data throughput efficiency and further reduce the number of accesses to downstream memory modules.

[0049] Step 1022: Determine the request length for each merge based on the original request length and the request length threshold.

[0050] The request length per clock cycle refers to the length of a single request formed by merging multiple original requests within each clock cycle.

[0051] In some implementations, the request length for each merge can be determined based on the relationship between the original request length and the request length threshold.

[0052] In some implementations, the maximum value between the original request length and the request length threshold can be used as the request length for each merge.

[0053] For example, if the length of the original request is greater than the request length threshold, the length of the request merged in each batch is equal to the length of the original request; if the length of the original request is less than or equal to the request length threshold, the length of the request merged in each batch is equal to the request length threshold.

[0054] It's important to note that using the maximum of the original request length and the request length threshold as the merged request length for each cycle allows for dynamic adaptation to scenarios with varying request lengths. When the original request length is small, choosing a larger request length threshold improves merging efficiency and avoids frequent cache line updates. Conversely, when the original request length is close to or exceeds the threshold, the original request length is used directly, preventing data overwrite conflicts or increased cached requests due to excessive merging. This strategy of using the maximum of the original request length and the request length threshold as the merged request length for each cycle is particularly suitable for write requests, improving the flexibility and stability of thread data to cacheline data logic without increasing the data cache area.

[0055] Step 1023: Based on the unit data volume and the request length of each merge, determine the number of original requests for each merge.

[0056] In some implementations, the number of original requests merged per cycle can be obtained by dividing the unit data volume by the length of the merged requests per cycle. For example, `write_coalesce_init_sub_req_num = coalesce_data_granularity / coalesce_request_length`; where `write_coalesce_init_sub_req_num` represents the number of original requests merged per cycle, `coalesce_data_granularity` represents the unit data volume, and `coalesce_request_length` represents the length of the merged requests per cycle. The number of requests determines how many requests can be merged per cycle to avoid exceeding the limitations of interface bandwidth and cache line size.

[0057] For example, if the unit data size is 128 bytes and the length of the request merged in each batch is 8 bytes, then a maximum of 32 requests can be merged in each batch (128 ÷ 8 = 16).

[0058] It should be noted that determining the number of original requests to be merged in each batch based on the unit data volume and the request length of each batch can ensure that the number of requests processed is maximized without overloading, thereby improving the system's parallel processing capability.

[0059] The following example illustrates how the number of original requests in each merged request is determined: The write request connection width W = cache line size granularity R = 128 bytes, the maximum number of original requests merged in each clock cycle M = 32, and the maximum request length of M write requests MAX_REQ_LEN = 16 bytes. Therefore, the amount of write data processed in each clock cycle (coalesce_data_granularity) = MAX(W,R) = 128.

[0060] When the length of a write request is 1 byte, the length of the request merged per cycle (coalesce_request_length) = the amount of data per unit (coalesce_data_granularity) / the maximum number of original requests merged per cycle M = 128 / 32 = 4 bytes, and the number of original requests merged together per cycle (write_coalesce_init_sub_req_num) = 32.

[0061] When the write request length is 2 bytes, the request length merged per cycle (coalesce_request_length) = unit data volume (coalesce_data_granularity) / maximum number of original requests merged per cycle M = 128 / 32 = 4 bytes, and the number of original requests merged together per cycle (write_coalesce_init_sub_req_num) = 32.

[0062] When the request length of a write request is 4 bytes, the request length merged per cycle (coalesce_request_length) = unit data volume (coalesce_data_granularity) / maximum number of original requests merged per cycle M = 128 / 32 = 4 bytes, and the number of original requests merged together per cycle (write_coalesce_init_sub_req_num) = 32.

[0063] When the request length of a write request is 8 bytes, the request length merged per cycle (coalesce_request_length) = MAX(request length, unit data size (coalesce_data_granularity) / maximum number of original requests merged per cycle M) = MAX(8, 4) = 8 bytes, and the number of original requests merged together per cycle (write_coalesce_init_sub_req_num) = 128 / 8 = 16.

[0064] When the request length of a write request is 16 bytes, the request length merged per cycle (coalesce_request_length) = MAX(request length, unit data size (coalesce_data_granularity) / maximum number of original requests merged per cycle M) = MAX(16, 4) = 16 bytes, and the number of original requests merged together per cycle (write_coalesce_init_sub_req_num) = 128 / 16 = 8.

[0065] In this embodiment, the number of original requests input to the merging logic is dynamically adjusted based on the request length and request length threshold of the original request. This effectively controls the data throughput per cycle, adapting it to the processing capabilities of the hardware interface and caching module. This avoids data congestion or resource waste, thereby improving the overall system response speed and stability, and ultimately enhancing memory access efficiency and user experience.

[0066] In some embodiments, step 103 above can be implemented by the following steps 1031 to 1033: Step 1031: Merge the original requests with addresses in the same cache line into one request to obtain at least one merged request.

[0067] The term "number of requests with addresses in the same cache line" refers to requests whose addresses fall within the same cache line range. For example, in a system with a cache line size of 128 bytes, if multiple requests have addresses between 0x1000 and 0x107F, then these multiple requests are considered to be in the same cache line. This allows multiple requests to be merged into a single request, thereby reducing the number of accesses to downstream memory modules, lowering bus bandwidth usage, and improving overall performance.

[0068] In some implementations, hardware logic can be used to merge multiple original requests whose request addresses are in the same cache line into a single request. For example, an address comparator can be used to determine whether multiple original requests fall within the same cache line and decide whether to merge them based on the comparison result. When multiple original requests are confirmed to fall within the same cache line, the merge operation generates a new merged request that contains the data information of all the original requests.

[0069] Step 1032: For any merge request, based on the logarithm of the cache line size (base 2) and the request length threshold, determine the offset of the address of each original request corresponding to the merge request within the cache line.

[0070] Offset refers to the position of the requested address relative to the start address of the cache line, and can be expressed in bytes.

[0071] In some implementations, the offset is calculated as the logarithm of the cache line size to base 2, and it needs to be aligned with the request length threshold. That is, the formula for calculating the offset of the request address within the cache line can be expressed as: address[log2(R) -1 : 0 ], and it needs to be aligned with the request length threshold (Q bytes), which means setting the value of address [log2(Q)-1 : 0 ] to 0. Here, R is the cache line size, and Q is the request length threshold. Aligning the request length threshold and offset for each merge ensures that the data from multiple original requests corresponding to the merged request are reasonably distributed within the cache line, thereby avoiding conflicts caused by data overlap.

[0072] For example, if the cache line size is 64 bytes, the bit field of the offset is [5:0] (log2(64) = 6 bits). By taking the logarithm of the cache line size in base 2, the specific location of the request address in the cache line can be quickly determined, thereby deciding which output port the data of the multiple original requests corresponding to the merged request should be routed to.

[0073] Step 1033: After aligning the addresses of each original request within the cache line, the data of each original request is mapped to the corresponding cache line position through data mapping logic to obtain the merged data of the merged request.

[0074] The data mapping logic is used to map the data of each original request corresponding to the merge request to the corresponding cache line position.

[0075] In some implementations, the data of each original request corresponding to the merge request can be mapped through data mapping logic to obtain merged data in the same cache line; the data volume of each original request corresponding to the merge request is the unit data volume.

[0076] In some implementations, the offset mechanism and data mapping logic in the data cross-connect can be used to map the data of each original request corresponding to the merge request to the corresponding cache line position to obtain the merged data of the merge request.

[0077] A data crossbar is a hardware module used for multiplexing and routing data. In this application, the data crossbar is used to rearrange the data of each original request corresponding to a merge request according to the offset position of the cache line within it, to generate a complete cache line data. For example, if the input port of the data crossbar has 8 original requests, each with a data length of 16 bytes, and the cache line size is 128 bytes, then the data crossbar will concatenate the data of these 8 original requests into a complete cache line data.

[0078] The data cross-switching mechanism works as follows: data from multiple original requests are mapped to the corresponding position of each original request's data within the cache line; then, the data from these multiple original requests are combined to form a complete cache line.

[0079] In some implementations, the demultiplexer and muxer in the data cross-connect switch can be used to map the data of each original request corresponding to the merge request, resulting in merged data within the same cache line. This rearranges the data of each original request corresponding to the merge request according to the offset position of each original request within the cache line. Specifically, the demultiplexer determines the offset information of each request within the cache line based on its address, and the muxer correctly arranges the data of the original requests into the cache line based on the offset information. The offset information indicates the position of each original request within the cache line.

[0080] In this embodiment, the data of each original request corresponding to the merge request is mapped to the corresponding cache line position through data mapping logic, so as to rearrange the data of multiple original requests with the same address in the same cache line and output them as a complete cache line data. This can reduce the number of accesses to the downstream memory module, thereby improving the overall performance and efficiency of the system and better adapting to the computing needs of high concurrency and high performance.

[0081] In some embodiments, step 1032 above can be implemented by the following steps 1032a to 1032c: Step 1032a: Using the demultiplexer of the data cross switch, determine the output port to which the data of each original request is routed based on the offset of the address of each original request in the cache line.

[0082] The demultiplexer is used to determine which output port the data of the multiple original requests corresponding to the merged request should be routed to based on the offset information of the request address in the cache line, thereby ensuring that the data of the multiple original requests corresponding to the merged request are correctly mapped to the corresponding positions in the cache line.

[0083] The offset refers to the position of the request address relative to the starting address within the cache line, and can be represented in bytes. The offset is calculated as the logarithm of the cache line size to base 2, and must be aligned to the request length threshold; that is, the offset of the request address within the cache line is address [log2(R) - 1: 0], and it needs to be aligned to Q bytes, which means setting the value of address [log2(Q) - 1: 0] to 0. Here, R is the cache line size, and Q is the request length threshold. Aligning the request length threshold with the offset in each merge ensures that the data from multiple original requests corresponding to the merged request are reasonably distributed within the cache line, thus avoiding conflicts caused by data overlap.

[0084] For example, if the cache line size is 64 bytes, the bit field of the offset is [5:0] (log2(64) = 6 bits). By taking the logarithm of the cache line size in base 2, the specific location of the request address in the cache line can be quickly determined, thereby deciding which output port the data of the multiple original requests corresponding to the merged request should be routed to.

[0085] It should be noted that by using the demultiplexer and offset mechanism of the data cross switch, an efficient data routing strategy can be achieved, thereby ensuring that the data of multiple original requests corresponding to the merged request can be accurately mapped to the appropriate position in the cache line. This helps to improve the data processing efficiency of the system and reduce the risk of performance degradation due to data conflicts.

[0086] Step 1032b: Using the multiplexer of the data cross switch, determine the data corresponding to each output port of the data cross switch from the original request data at the input port of the data cross switch.

[0087] Multiplexers are used to select the data for the current output port from the data of multiple original requests corresponding to a merge request.

[0088] The data corresponding to each output port of the data cross switch refers to the data selected from the data of multiple original requests corresponding to the merge request and sent to a specific output port under the control of the multiplexer of the data cross switch. This data may come from different original requests and has been sorted and organized according to the layout of the cache lines.

[0089] The mechanism implemented by using a multiplexer with a data cross switch can dynamically select the most suitable data for output within each clock cycle, improving the flexibility and accuracy of data transmission, and is particularly suitable for high-concurrency environments.

[0090] Step 1032c: Combine all the data corresponding to the output ports into the same cache line and output it.

[0091] Merged data refers to the data set formed by combining data from multiple original requests corresponding to a merge request after data routing and selection have been completed. The merged data has been organized into a uniform cache line format and can be directly submitted to the downstream memory module for processing, enabling efficient processing by the downstream memory module.

[0092] In some implementations, the data mapping process for the original requests is a pipelined process. First, the demultiplexer of the data cross switch determines the output port to which the data from the multiple original requests corresponding to the merged request should be routed, based on the offset of the request address. Then, the multiplexer of the data cross switch selects the data corresponding to each output port from the data at the input ports. Finally, all the selected data is combined into a complete buffer line output. The entire data mapping process is completed within each clock cycle, ensuring high throughput and low latency of the system.

[0093] In this embodiment, through the collaborative work of the demultiplexer and multiplexer of the data cross switch, as well as the setting of offset calculation and request length threshold, an efficient data merging and routing mechanism can be achieved, reducing the access frequency to downstream memory modules and improving overall performance and energy efficiency.

[0094] In some embodiments, the step 1032a above, "determining the output port to which the data of each original request corresponding to the merge request should be routed based on the offset of the address of the original request in the cache line", can be achieved through the following steps A1 to A3: Step A1: If the combined request length for each batch is greater than the request length threshold, divide the data of each original request according to the request length threshold to obtain multiple sub-data.

[0095] The request length threshold is also used to determine whether further splitting of the original request data is necessary. When the length of the original request data in the merge operation exceeds the request length threshold, the original request data in the merge operation can be split into several sub-data (sub-data blocks).

[0096] In some implementations, when the request length merged in each batch is greater than the request length threshold, the request length merged in each batch is equal to the original request length (request_length). In this case, it can be considered that the data of the request length bytes is divided into request length / Q sub-data, and each sub-data is still the request length threshold Q bytes.

[0097] In some implementations, the request length threshold can be dynamically adjusted based on the bandwidth of the application scenario. For example, in a high-bandwidth environment, the request length threshold can be appropriately increased to reduce the number of times request data is split; in a low-bandwidth environment, the request length threshold can be decreased to ensure that request data can be processed in a timely manner, thereby avoiding buffer overflow or performance bottlenecks.

[0098] Step A2: Determine the offset of each sub-data item's address within the cache line based on the logarithm of the cache line size (base 2).

[0099] The logarithm of the cache line size is a base-2 mathematical operation used to represent the bit range of the offset within the cache line. For example, if the cache line size is 64 bytes, then log2(64) = 6, indicating that the offset within the cache line is represented by a 6-bit binary number, i.e., the address [5:0]. The offset within the cache line is used to identify the specific location of the requested data within the cache line, so as to facilitate the location and mapping of the requested data.

[0100] In some implementations, the offset of each sub-data item's address within a cache line can be determined based on the sub-data's partitioning order and a request length threshold. For example, the offsets of each sub-data item's address within a cache line can be: offset, offset + Q, offset + 2 * Q, ...

[0101] Step A3: Determine the output port to which each sub-data should be routed based on the offset of the address of each sub-data within the cache line.

[0102] The output port is used to send the requested data to the downstream memory module.

[0103] For example, if the address of each sub-data item is offset within the cache line as offset, offset + Q, offset + 2 * Q, ..., then the output ports to which each sub-data item should be routed are 0, 1, 2, 3, ...

[0104] like Figure 2 As shown, the original request data is input through the first input port (input0) of the data crossbar switch. The request length is 8 bytes, and the request length threshold is 4 bytes. Therefore, the original request data can be split into a 4-byte low-address part and a 4-byte high-address part. The low-address part has an offset of 0 in the cache line, corresponding to the first output port (output0); the high-address part has an offset of 4 in the cache line. Since the bit width of each output port is 4 bytes, the high-address part corresponds to the second output port (output1).

[0105] In the hardware implementation, the number of output ports is related to the cache line size, and the bit width of each output port is a request length threshold. Each output port corresponds to a specific cache line position. For example, output port 0 corresponds to cache line positions 0 to 3, output port 1 corresponds to cache line positions 4 to 7, output port 2 corresponds to cache line positions 8 to 11, and so on. By properly configuring the mapping relationship between output ports and cache lines, the efficiency of request data transmission and the system response speed can be significantly improved.

[0106] In some implementations, if the request length of each original request is 4 bytes and the request length threshold Q is 4 bytes, then the data of each original request corresponds exactly to a Q-byte data block. No additional left shift operation is required, and the data can be directly mapped to the corresponding cache line position based on the address offset to form complete merged data.

[0107] In this embodiment, when the length of the merged request in each iteration exceeds a request length threshold, the original request data is divided, and the offset of each sub-data is calculated based on the logarithm of the cache line size. The output port is then determined based on the calculated offset. This effectively controls the granularity of request data splitting and routing accuracy, thereby improving the parallelism and throughput of request data processing, reducing memory access frequency and conflicts, and ultimately enhancing the overall performance and stability of the system.

[0108] In some embodiments, the step 1032a above, "determining the output port to which the data of the multiple original requests corresponding to the merged request should be routed based on the offset of the request address in the cache line," can be achieved through the following steps B1 to B3: Step B1: If the combined request length for each frame is less than or equal to the request length threshold, determine the left shift bits for each original request sequentially based on the logarithm of the request length threshold to base 2.

[0109] If the length of the merged request is less than or equal to the request length threshold, a left shift pre-operation needs to be performed on the original request within the request length threshold to ensure that the data of the original request corresponding to the merged request is arranged sequentially in the cache line, thereby improving the accuracy and efficiency of data mapping.

[0110] The left shift bit refers to the number of bytes moved when performing a left shift operation on the data in the original request, used to correctly map the data in the original request to the corresponding position in the cache line. The left shift bit is determined by the logarithm of the request length threshold, which is base 2.

[0111] In some implementations, when the request length (coalesce_request_length) of each merge is less than or equal to the request length threshold Q, it is necessary to first perform a pre-operation on the request_length bytes of the original request within the range of Q bytes, shifting the request length bytes of each original request left by Y bytes, where Y = the value of the address of the original request [log2(Q) - 1 :0 ].

[0112] Step B2: Shift the data of each original request to the left according to the number of left shifts to obtain multiple left-shifted data.

[0113] In some implementations, the left-shifted data is used as the Q-byte data for each input port.

[0114] Step B3: Based on the logarithm of the cache line size to base 2, determine the output ports to which multiple left-shifted data should be routed.

[0115] In some implementations, the offset of the address of each left-shifted data within the cache line is determined sequentially based on the logarithm of the cache line size to base 2; and the output port to which each left-shifted data is routed is determined based on the offset of the address of each left-shifted data within the cache line.

[0116] When the request length (request_length) of the sub-request is 1 byte, assuming the addresses of the M sub-requests are 0x1000, 0x1001, 0x1002, ..., 0x101F respectively; these 32 addresses all fall on the same cache line and can be merged together; therefore, data from all M input ports can be mapped. The offset of the sub-request address within the cache line is log2(Q) - 1 = 1; the left shift bits of the M sub-request addresses are 0, 1, 2, 3, 0, 1, 2, 3, ...

[0117] like Figure 3 As shown, the data data0 of original request 0 is shifted left by 0 bytes, the data data1 of original request 1 is shifted left by 1 byte, the data data2 of original request 2 is shifted left by 2 bytes, and the data data3 of original request 3 is shifted left by 3 bytes. Original requests 0, 1, 2, and 3 are all routed to output port 0. Similarly, the remaining 28 original requests are also mapped to their corresponding output ports in this manner, which will not be elaborated further in this embodiment.

[0118] In this embodiment, when the request length of the original request merged in each batch is less than or equal to the request length threshold, the data of the original request is shifted to the left, and the shifted data is used as the data of each input port. This can accurately adjust the data of the original request to the appropriate position, thereby improving the accuracy and efficiency of data processing.

[0119] In some embodiments, the request merging method provided in this application further includes the following steps C1 to C2: Step C1: If the request length for merging each time exceeds the request length threshold, set the bits in the bitmap corresponding to each sub-data to the first bit value; the first bit value indicates that the corresponding byte of data is valid.

[0120] This application also sets a bitmap for each Q-byte data input port. The bitmap includes Q bits, each bit corresponding to one byte, used to indicate whether the corresponding byte of data is valid. For example, if each input port includes 4 bytes of data, then the bitmap includes 4 bits. When all 4 bytes of data are valid, the bitmap can be 4'b1111; when the first byte of data in all 4 bytes is valid, the bitmap can be 4'b0001.

[0121] In some implementations, when the request length for each merge exceeds a request length threshold, it indicates that the total amount of data being merged is large enough to cover the entire Q-byte granularity. In this case, each sub-data is valid at the entire Q-byte granularity, so each bit in the bitmap corresponding to each sub-data is set to the first bit value (e.g., 1), indicating that this data can participate in subsequent routing and mapping operations. Setting each bit in the bitmap corresponding to each sub-data to the first bit value ensures that all data can be correctly identified and correctly routed, thereby improving data transmission efficiency.

[0122] For example, when the original request length is 4 bytes and the request length threshold is also 4 bytes, the original request length = the request length threshold Q, and the byte bitmap of the Q bits of the input ports of M original requests is 4'b1111.

[0123] Step C2: If the request length for each merged data is less than or equal to the request length threshold, set a portion of the bits in the bitmap corresponding to each sub-data to the first bit value.

[0124] When the request length for each merge is less than or equal to the request length threshold, it indicates that the total amount of data being merged is insufficient to fill a complete Q-byte granularity unit. In this case, not all data needs to participate in the mapping; therefore, only the bits containing valid data are set to the first bit value, while the other bits remain invalid. This method avoids interference from invalid data, reduces the possibility of data collisions, and improves resource utilization.

[0125] When the length of the original request is 1 byte, assume that the addresses of the M original requests are 0x1000, 0x1001, 0x1002 ....0x101F; these 32 addresses all fall on the same cache line and can be merged together; therefore, the data from the M input ports can all be mapped. log2(Q) - 1 = 1; the values ​​(Y) of the addresses [1:0] of the M original requests are 0, 1, 2, 3, 0, 1, 2, 3, ... The input port data of the M original requests are left-shifted data, and the bitmap of the Q bits of each left-shifted data is 4'b0001, 4'b0010, 4'b0100, 4'b1000, 4'b0001, 4'b0010, 4'b0100, 4'b1000, ...

[0126] In this embodiment, by determining the relationship between the request length of each merge and the request length threshold, the validity identifier of the data (bits in the bitmap) can be flexibly controlled, making data mapping more efficient and accurate. This can reduce unnecessary data transmission and storage overhead, thereby improving the overall system performance and resource utilization efficiency.

[0127] In some embodiments, the request merging method provided in this application further includes the following steps 1201 to 203: Step 201: Before merging multiple original requests, perform a storage body hash operation on the memory address of the original request to obtain the storage body identifier of the original request; the storage body identifier has a one-to-one correspondence with the merging operation.

[0128] The bank hash operation is used to determine the bank identifier corresponding to the memory address of the original request.

[0129] In some implementations, a memory bank hash operation can be performed on a portion of the original requested memory address to obtain the memory bank identifier of the original request. This portion of the address can be n bits of the lower-order part of the memory address. For example, the memory bank identifier of the original request can be determined based on the 6th and 7th bits of the original requested memory address.

[0130] As shown in Table 1 below, the following explanation uses hexadecimal memory addresses as an example. For memory address 0x1000, the lower 8 bits (bit 7 to bit 0) are 000000000, bits [7:6] are 00, and the corresponding memory bank identifier is Bank 0. For memory address 0x1010, the lower 8 bits (bit 7 to bit 0) are 00010000, bits [7:6] are 00, and the corresponding memory bank identifier is Bank 0. For memory address 0x1020, the lower 8 bits (bit 7 to bit 0) are 00100000, bits [7:6] are 00, and the corresponding memory bank identifier is Bank 0. For memory address 0x1030, the lower 8 bits (bit 7 to bit 0) are 00110000, bits [7:6] are 00, and the corresponding memory bank identifier is Bank 0.

[0131] For memory address 0x1040, the lower 8 bits (bits 7 to 0) are 01000000, and bits [7:6] are 01, corresponding to the bank identifier Bank 1. For memory address 0x1050, the lower 8 bits (bits 7 to 0) are 01010000, and bits [7:6] are 01, corresponding to the bank identifier Bank 1. For memory address 0x1060, the lower 8 bits (bits 7 to 0) are 01100000, and bits [7:6] are 01, corresponding to the bank identifier Bank 1. For memory address 0x1070, the lower 8 bits (bits 7 to 0) are 01110000, and bits [7:6] are 01, corresponding to the bank identifier Bank 1. For memory address 0x1080, the lower 8 bits (bits 7 to 0) are 10000000, and bits [7:6] are 10, corresponding to the memory bank identifier Bank2. For memory address 0x1090, the lower 8 bits (bits 7 to 0) are 10010000, and bits [7:6] are 10, corresponding to the memory bank identifier Bank2. For memory address 0x1090, the lower 8 bits (bits 7 to 0) are 10010000, and bits [7:6] are 10, corresponding to the memory bank identifier Bank2. For memory address 0x10A0, the lower 8 bits (bits 7 to 0) are 10100000, and bits [7:6] are 10, corresponding to the memory bank identifier Bank2. For memory address 0x10B0, the lower 8 bits (bits 7 to 0) are 10110000, and bits [7:6] are 10, corresponding to the bank identifier Bank 2. For memory address 0x10C0, the lower 8 bits (bits 7 to 0) are 11000000, and bits [7:6] are 11, corresponding to the bank identifier Bank 3. For memory address 0x10D0, the lower 8 bits (bits 7 to 0) are 11010000, and bits [7:6] are 11, corresponding to the bank identifier Bank 3. For memory address 0x10E0, the lower 8 bits (bits 7 to 0) are 11100000, and bits [7:6] are 11, corresponding to the bank identifier Bank 3. For memory address 0x10F0, the lower 8 bits (bit7 to bit0) are 11110000, and bits [7:6] are 11, corresponding to the bank identifier Bank 3.

[0132]

[0133] Table 1 It should be noted that the purpose of storage bank hashing is to optimize the parallel processing capability of the caching system and avoid cache bank conflicts caused by multiple requests being mapped to the same cache bank. Each storage bank identifier corresponds to one merge operation, that is, each merge operation corresponds to one cache bank.

[0134] Step 202: After obtaining the target merge request corresponding to any storage identifier, perform a group hash operation on the target merge request to obtain the group identifier of the target merge request.

[0135] Group hashing refers to performing a hash operation on the merge request again after it is generated to determine the group (Set) to which the merge request belongs. The target merge request refers to the merge request corresponding to any one storage unit.

[0136] In some implementations, the group identifier of the merge request can be determined based on the merged address information. The purpose of the group identifier is to help the memory module quickly locate which set the merge request should be processed in, thereby further reducing conflicts and improving cache hit rate.

[0137] Step 203: Generate a cache request based on the group identifier of the target merge request and the corresponding merge data; the cache request is used to instruct the memory module to perform the operation corresponding to the target merge request based on the corresponding merge data.

[0138] A cache request is a control instruction consisting of a merge request and its group identifier, used to guide the memory module in processing the merge request. A cache request may include, but is not limited to, key information such as: cache address, operation type (read / write), and data length. The group identifier of the merge request specifies the specific cache set and bank, ensuring that the memory module can correctly read or write data to the specified location according to the cache request.

[0139] By performing multiple hash operations on the original request, the system can transform it into a well-structured and highly executable cache request, thereby effectively improving the efficiency and response speed of the caching module. This cache request mechanism not only helps reduce unnecessary cache conflicts but also enhances the overall performance and stability of the system to some extent.

[0140] It should be noted that, as shown in Table 1, original requests 0 to 3, 4 to 7, 8 to 11, and 12 to 15 fall on cache lines 0x1000, 0x1040, 0x1080, and 0x10C0 respectively, and on cache banks 0, 1, 2, and 3 respectively. The optimal way to achieve cache bank parallelism is to process these four cache requests. However, in the existing technical solution, if the four merging logics choose original request 0 / original request 15 / original request 1 / original request 14 as the base address for merging, the four cache addresses obtained by the four merging logics will be 0x1000, 0x10C0, 0x1000, and 0x10C0 respectively. The two merge groups corresponding to original request 0 / original request 1 have the same cache address, and the two merge groups corresponding to original request 15 / original request 14 also have the same cache address, thus wasting cache parallelism.

[0141] In this embodiment, cache body hashing and group hashing are implemented separately. The memory address of each original request is first hashed to obtain a cache body identifier, and then the corresponding merging operation (merging logic) is entered based on the cache body identifier. The number of input addresses for each merging logic is still M. There are N * M inputs for N merging logics, but the number of valid inputs per clock cycle is equal to the number of valid original requests. After the merging logic, it undergoes N group hashings to obtain group representations, and then a cache request is generated and enters the memory module. In this way, it can be guaranteed that if there are cases where M original requests fall into different cache bodies, the parallelism of the cache bodies can be maintained at the best state, regardless of the identifier of the original request.

[0142] This application provides a request merging system, comprising: a write data merging module, used to determine the unit data volume of write data processed per cycle based on the maximum value between the connection width of write data between the upstream module and the memory merging module and the cache line size; the write data merging module is further used to determine the number of original requests to be merged per cycle based on the request length and unit data volume of the original requests; a request merging module is used to merge multiple original requests according to the number of requests to obtain at least one merged request; the write data merging module is further used to map the data of each original request corresponding to the merged request based on the unit data volume to obtain the merged data of the merged request.

[0143] like Figure 4As shown, the write data merging module can include P write data merging logics (thread data to cacheline data logic). These P write data merging logics are all used to map the data (W bytes) of M original requests based on a unit data volume to obtain merged data. The request merging module can include multiple merging logics (coalescer), which operate in the same way, merging multiple original requests according to the number of requests to obtain at least one merged request.

[0144] In some embodiments, the write data merging module includes: a data crossover switch, used to align the addresses of the original requests corresponding to the merge request within the cache line for any merge request, and then map the data of each original request to the corresponding cache line position through data mapping logic to obtain the merged data of the merge request; the offset is determined based on the logarithm of the cache line size to base 2 and is aligned with the request length threshold for merging in each cycle.

[0145] In some embodiments, the system further includes: a storage hash module, configured to perform a storage hash operation on the memory address of the original requests before merging multiple original requests to obtain the storage identifier of the original requests; the storage identifier has a one-to-one correspondence with the merging operation; a group hash module, configured to perform a group hash operation on the target merging request after obtaining the target merging request corresponding to any storage identifier to obtain the group identifier of the target merging request; and generate a cache request based on the group identifier of the target merging request and the corresponding merging data; the cache request is used to instruct the memory module to perform the operation corresponding to the target merging request based on the corresponding merging data.

[0146] The request merge module may also include a bank hash and a set hash.

[0147] like Figure 4 As shown, M sub-requests are first processed by a bank hash to obtain a bank identifier, and then enter the corresponding merging logic based on the bank identifier. The number of input addresses for each merging logic remains M. There are N * M inputs for N merging logics, but the number of valid inputs per clock cycle equals the number of valid sub-requests. Simultaneously, the write data merging logic maps the data (W bytes) of the M sub-requests to obtain the merged data based on a unit data volume. After merging, the data is processed by N set hashes to obtain a group identifier, and then a cache request is sent to the memory module (cache) to write the merged data into the corresponding cache based on the bank identifier and the group identifier.

[0148] The following describes the application of the data processing method provided in the embodiments of this application in a real-world scenario.

[0149] In existing technical solutions, multiple merging logics are typically set up, with each group assigned a base address (cache baseaddress). The memory address of the original request is compared with the base address. The cached request resulting from each merging goes into a cache hash to obtain either a cache bank ID or a group ID. This approach has a drawback: if the base addresses of multiple groups fall into the same cache bank, a cache bank conflict will occur. This can cause the cache addresses of some groups' merging logic to be unable to be received by the memory module at that time, posing a risk of performance degradation.

[0150] Meanwhile, in existing technical solutions, the write data merging logic typically involves collecting all data from M original requests (sub-requests) and then mapping the data based on the merging result. This approach requires an additional data buffer of at least M times the request length (MAX_REQ_LEN) to cache data when the maximum value of M times the request length (MAX_REQ_LEN) exceeds the granularity of the cache line (R). Furthermore, this causes significant layout, routing, and timing issues in the hardware implementation.

[0151] To address the aforementioned issues, this application proposes a new request merging scheme. The specific scheme is as follows: In the merging logic, the cache bank hash and set hash are implemented separately, and M sets of bank hashes are instantiated. The memory address of each original request is first processed by the cache bank hash, and then enters the corresponding merging logic according to the cache bank identifier. That is, each merging logic corresponds to one cache bank. The number of input addresses for each merging logic is still M, because it is possible that the memory addresses of the M original requests in a given clock cycle will fall on the same cache bank after being processed by the cache bank hash. There are N * M inputs for the N merging logics, but the number of valid inputs in each clock cycle is equal to the number of valid original requests in that clock cycle. After the merging logic, the set hashes are processed by N sets to obtain the set identifier, and then a cache request is generated and enters the memory module.

[0152] By using the above method, we can ensure that if any of the M original requests fall into different cache bodies, the cache parallelism is always optimal, regardless of the original request identifier. For example: the number of original requests M is 16, the number of cache bodies N is 4, the granularity of the cache body is 64 bytes, the original requests are read requests with a length of 16 bytes, and the addresses of the M original requests are 0x1000, 0x1010, 0x1020, 0x1030, 0x1040, 0x1050, 0x1060, 0x1070, 0x1080, 0x1090, 0x10A0, 0x10B0, 0x10C0, 0x10D0, 0x10E0, 0x10F0. Assuming the cache body hash is obtained by directly taking the address [7:6], then the original requests 0 to 3, 4 to 7, 8 to 11, and 12 to 15 fall on cache lines 0x1000, 0x1040, 0x1080, and 0x10C0 respectively, and fall on cache body 0, cache body 1, cache body 2, and cache body 3 respectively. The best way to handle the parallelism of the cache body is to process 4 requests, which this application satisfies.

[0153] However, in the existing technical solution, if the four merging logics select original request 0 / original request 15 / original request 1 / original request 14 as the base address for merging, it will be found that the four memory addresses obtained by the four merging logics are 0x1000, 0x10C0, 0x1000, 0x10C0 respectively. The two merge groups corresponding to original request 0 / original request 1 have the same cache address, and the two merge groups corresponding to original request 15 / original request 14 have the same cache address, thus wasting the cache parallel capability.

[0154] The above processing method perfectly matches the parallel processing capability of multiple caches for read requests, which do not carry write data. However, for write requests, further optimization and adjustments are needed. Specific optimization solutions are as follows: In hardware implementation, the interconnect resources between modules are relatively precious. For backend implementation and area considerations, the width of the write data connection between the upstream module and the memory merging module (assuming a width of W bytes / clock, where W is a power of 2) is finite, and is generally time-division multiplexed with the connection for the request length. Typically, W is less than the number of original requests M multiplied by the maximum length of the original request MAX_REQ_LEN, meaning that writing data for one init_request usually requires multiple clock cycles to complete.

[0155] Based on this, this application proposes a new merging scheme for write requests: instead of using a fixed number of original requests as input to the merging logic (existing solutions generally merge according to a fixed number), it fixes the amount of write data processed per cycle (which can be called coalesce_data_granularity, corresponding to the unit data amount mentioned above). The number of original requests merged in a cycle (which can be called write_coalesce_init_sub_req_num) multiplied by the request length is less than or equal to the amount of write data processed per cycle. The amount of write data processed per cycle is equal to the maximum value between the connection width W and the granularity R of the cache line size. This fully utilizes the interface's data bit width, avoiding wasting interface data throughput. Furthermore, when M original requests are multiple data access requests with consecutive addresses, and the data amount of the M original requests matches the connection bandwidth, the M original requests can be directly merged into one cache line without increasing the number of cached requests. With the connection width W and the granularity R of the cache line size being equal, a relatively good PPA balance point can be achieved.

[0156] In some embodiments, the number of input raw requests for the merging logic can also be adjusted based on the request length. The maximum value of the number of raw requests merged in a single batch (write_coalesce_init_sub_req_num) is M. When the request length is relatively small, the number of raw requests merged in a single batch multiplied by the request length will be less than the amount of write data processed per batch (coalesce_data_granularity). A merge request length (coalesce_request_length, corresponding to the request length merged per batch mentioned above) is set to the maximum value between the request length of the raw request and the request length threshold (the amount of write data processed per batch divided by the maximum number of raw requests merged in a single batch). The number of raw requests merged in a single batch is equal to the amount of write data processed per batch (coalesce_data_granularity) divided by the merge request length (coalesce_request_length), representing the granularity of data processing for each raw request in the write data merging logic (the logic that places the write data into the corresponding cache line position).

[0157] The value of the amount of write data processed per cycle (coalesce_data_granularity) / M is the minimum value of the coalesce request length, which can be called coalesce_request_length_threshold (assumed to be Q bytes). The granularity of the data crossover switch in threaddata to cacheline data (the logic of placing write data to the corresponding cacheline position) is Q bytes. The number of inputs to the data crossover switch is the line width W / the minimum value of the coalesce request length Q, and the number of outputs is the granularity of the cache line R / the minimum value of the coalesce request length Q.

[0158] like Figure 5 As shown, the demultiplexer (demux) of the data cross switch selects which output port to route to based on the address offset within the cache line; the multiplexer (mux) selects the input data based on the merging result, ultimately reflecting the overwrite strategy for writing data within the cache line. It's important to note that the address offset within the cache line is address[log2(R) -1 : 0 ], and it needs to be aligned to the Q byte, meaning the value of address[log2(Q) -1 : 0 ] is set to 0. If the cache line size R = 64B, then log2(64) = 6, and the Offset bit field is [5:0] (6 bits). If [5:0] = 000000, it represents the 0th byte of the cache line.

[0159] When the combined request length (coalesce_request_length) is greater than the request length threshold Q, the combined request length (coalesce_request_length) equals the original request length (request_length). This can be considered as dividing the request length bytes of data into equal parts divided by Q, with each part still being Q bytes. The offset of the address corresponding to each part in the cache line is offset, offset + Q, offset + 2 * Q, ... in sequence.

[0160] Each Q byte of data corresponds to a Q-bit bitmap (byte enable signal byte_equals), used to indicate whether the corresponding byte of data is valid. When the coalesce_request_length is greater than or equal to the request length threshold Q, the bitmap of each input Q-bit is all 1s.

[0161] When the merged request length (coalesce_request_length) is less than or equal to the request length threshold Q, a pre-operation needs to be performed on the original request's request length bytes within the Q-byte range: shift each original request length byte left by Y bytes, where Y = the value of the original request's address [log2(Q) - 1 : 0 ]. The left-shifted data is then used as the Q-byte input data. Simultaneously, the Q-bit bitmap is not all 1s; it is the result of shifting the original request length bytes left by Y bytes.

[0162] On the mux side of the data cross switch, if the addresses of multiple inputs can be merged into the same cache line, then the inputs of the current step can map the data to the cache line of the output together. At the same time, if the addresses of multiple inputs fall on offsets that overlap within the cache line, that is, they will be routed to the same output, then the data can be mapped or overwritten according to the write data overwrite strategy and the bit map carried by each input.

[0163] Using the above method, when the maximum value of the number of original requests multiplied by the length of the original requests exceeds the granularity of the cache line, there is no need to add a data cache area to cache the data. The same write data merging logic can meet the needs of different request lengths, and will not cause layout routing problems or timing problems due to the increase in request length. Moreover, the amount of data of the original requests merged in each cycle (coalesce_data_granularity) is equal to MAX(connection width W, cache line size R). This can make full use of the interface data bit width and avoid wasting the interface data throughput. It can also ensure that under better application scenario patterns (such as M original requests accessing consecutive addresses), they can be directly merged into 1 cache line without increasing the number of cached requests or causing a decrease in system performance.

[0164] Specific examples: For a write request, the coalesce width W = cache line size granularity R = 128 bytes, the number of input addresses for the merging logic M = 32, and the maximum request length of the M original requests MAX_REQ_LEN = 16 bytes. Therefore, the amount of write data processed per clock cycle (coalesce_data_granularity) = MAX(coalesce width W, cache line size R) = 128.

[0165] When the request length of a write request is 1 byte, the request length merged per cycle (coalesce_request_length) = the amount of data in the original request merged per cycle (coalesce_data_granularity, corresponding to the unit data amount mentioned above) / the maximum number of original requests merged per cycle M = 128 / 32 = 4 bytes, and the number of original requests merged together per cycle write_coalesce_init_sub_req_num = 32.

[0166] When the request length of a write request is 2 bytes, the request length merged per cycle (coalesce_request_length) = the amount of data in the original request merged per cycle (coalesce_data_granularity) / the maximum number of original requests merged per cycle M = 128 / 32 = 4 bytes, and the number of original requests merged together per cycle write_coalesce_init_sub_req_num = 32.

[0167] When the request length of a write request is 4 bytes, the request length merged per cycle (coalesce_request_length) = the amount of data in the original request merged per cycle (coalesce_data_granularity) / the maximum number of original requests merged per cycle M = 128 / 32 = 4 bytes, and the number of original requests merged together per cycle write_coalesce_init_sub_req_num = 32.

[0168] When the request length of a write request is 8 bytes, the request length merged per cycle (coalesce_request_length) = MAX(request length, data size of the original request merged per cycle (coalesce_data_granularity) / maximum number of original requests merged per cycle M) = MAX(8, 4) = 8 bytes, and the number of original requests merged together per cycle write_coalesce_init_sub_req_num = 128 / 8 = 16.

[0169] When the request length of a write request is 16 bytes, the request length to be merged in each cycle (coalesce_request_length) is equal to the maximum value between the request length of the original request and the request length threshold (the amount of write data processed in each cycle divided by the maximum number of original requests to be merged in the current cycle) = MAX(16, 4) = 16 bytes, and the number of original requests to be merged in each cycle is write_coalesce_init_sub_req_num = 128 / 16 = 8.

[0170] The request length threshold for each merge is Q = the amount of data in the original request for each merge (coalesce_data_granularity) / M = 4 bytes.

[0171] The data crossbar switch has 32 inputs and 32 outputs. Inputs are equivalent to input ports, and outputs are equivalent to output ports.

[0172] When the request length is 1 byte, if the addresses of the M original requests (sub-requests) are 0x1000, 0x1001, 0x1002, ..., 0x101F respectively; these 32 addresses all fall on the same cache line and can be merged together; therefore, all M input data can be mapped.

[0173] log2(Q) - 1 = 1; The offsets (1:0] of the addresses of the M original requests are 0, 1, 2, 3, 0,1,2, 3 ... respectively.

[0174] The bitmap of the Q bytes of the M original requests is as follows: 4'b0001, 4'b0010, 4'b0100, 4'b1000, 4'b0001, 4'b0010, 4'b0100, 4'b1000, ....

[0175] The data of each original request's request_length bytes is shifted left by Y bytes.

[0176] Original request 0, original request 1, original request 2, and original request 3 are all routed to the same output 0 because their addresses are all offset by 0 within the cache line; original request 4, original request 5, original request 6, and original request 7 are all routed to the same output 1 because their addresses are all offset by 4 within the cache line; ...

[0177] When the request length is 2 bytes, assuming there are M original request addresses (sub-requests) address) are 0x1000,0x1002,0x1004,0x1006,0x1008,0x100A,0x100C,0x100E,0x2000,0x2002,0x2004,0x2006,0x2008,0x200A,0x200C,0 x200E,0x3000,0x3002,0x3004,0x3006,0x3008,0x300A,0x300C,0x30 0E,0x4000,0x4002,0x4004,0x4006,0x4008,0x400A,0x400C,0x400E. These 32 addresses are grouped into 8 groups and fall into the same cache line, resulting in a total of 4 cache lines, assuming they correspond to cache lines 0 / 1 / 2 / 3 respectively. Therefore, in each clock cycle, only a portion of the M input data can be mapped. For example, if the first clock cycle maps data to cache line 0, then only the original requests 0–7 that fall into cache line 0 will be mapped; if the second clock cycle maps data to cache line 1, then only the original requests 8–15 that fall into cache line 1 will be mapped; and so on.

[0178] log2(Q)-1= 1; The values ​​(Y) of the addresses [1:0] of the M original requests are 0, 2, 0, 2, 0, 2, ... in sequence.

[0179] The data of each original request's request_length bytes is shifted left by Y bytes.

[0180] The bitmaps of the M original requests are 4'b0011, 4'b1100, 4'b0011, 4'b1100, 4'b0011, 4'b1100,...

[0181] For the data mapping of cache line 0 in the first clock tick, original request 0 and original request 1 are routed to the same output 0 because their addresses are offset by 0 within the cache line; original request 2 / original request 3 are routed to the same output 1 because their addresses are offset by 4 within the cache line; original request 4 / original request 5 are routed to the same output 2 because their addresses are offset by 8 within the cache line; and original request 6 / original request 7 are routed to the same output 3 because their addresses are offset by 12 within the cache line.

[0182] When the request length is 4 bytes, the request length is Q bytes, and the bit map of the M original requests is 4'b1111. The data mapping of the data cross switch is relatively clear and will not be elaborated further.

[0183] When the request length is 8 bytes, the data from 16 original requests is enough to merge the original requests (coalesce_data_granularity) into a single batch of 128 bytes. Therefore, the number of original requests to be merged into a single batch (write_coalesce_init_sub_req_num) is 16. Thus, original requests (sub-requests) 0 to 15 can be merged together; original requests 16 to 31 are merged together. Assuming the address of original request 0 is 0x1000, the 8 bytes of data are divided into request_length / Q = 2 parts. The offsets of the addresses corresponding to each part within the cache line are 0 and 4 respectively, which will be routed to output 0 and output 1 respectively. Figure 2 As shown.

[0184] Furthermore, to improve write performance, the write data merging logic described above can be copied P times. The value of P can be equal to the number of merging logics N, or other values. Different write data merging logics can process different cached line data in the same timeframe; each write data merging logic processes data in the same way.

[0185] This application proposes a request merging method, the core improvement of which lies in: dynamically determining the amount of write data processed per cycle based on the width of the write data connection between the upstream module and the memory merging module and the size of the cache line; and flexibly adjusting the number of original requests merged per cycle according to the request length of the original request and the amount of data, thereby optimizing memory access efficiency. By separating the cache body hash and group hash, and performing cache body hashing separately for each original request before allocating it to the corresponding merging logic, cache body conflicts can be effectively avoided and the parallelism of the cache body can be improved.

[0186] For write requests, this application further proposes a novel data mapping scheme: using a data crossbar to route and map the data in the original request, data merging operations for different request lengths can be completed without adding an extra data buffer. This scheme not only reduces the complexity of hardware implementation but also improves interface throughput and overall system performance.

[0187] This application achieves an efficient request and data merging mechanism by dynamically adjusting the merging strategy and optimizing the data mapping logic, thus solving problems such as low bandwidth utilization, waste of hardware resources, and cache conflicts in existing technologies.

[0188] The embodiments of this application include at least the following key points: 1. In the merging logic, the cache bank hash and group hash are implemented separately. The cache bank hash is instantiated M times. The memory address of each original request is first hashed using the cache bank hash, and then enters the corresponding merging logic based on the cache bank identifier. That is, each group of merging logic corresponds to one cache bank. The number of input addresses for each merging logic is still M, because it's possible that the memory addresses of the M original requests in a given clock cycle will fall into the same cache bank after being hashed using the cache bank hash. There are N * M inputs for the N merging logics, but the number of valid inputs in each clock cycle is equal to the number of valid original requests in that clock cycle. After the merging logic, the cache bank hash is processed by N group hashes to obtain the group identifier, and then a cache request is generated and enters the cache module.

[0189] 2. A novel merging scheme for write requests is proposed: The amount of write data processed per clock cycle is fixed. The number of original requests merged in a clock cycle (referred to as `write_coalesce_init_sub_req_num`) multiplied by the request length is less than or equal to the amount of write data processed per clock cycle. Here, the amount of write data processed per clock cycle (`coalesce_data_granularity`) is equal to the maximum value between the connection width W and the granularity R of the cache line size. This fully utilizes the interface's data bit width, avoiding wasted interface data throughput, and ensures that in favorable application scenarios (e.g., M original requests accessing consecutive addresses), they can be directly merged into one cache line without increasing the number of cached requests. This scheme adjusts the number of original requests input to the merging logic based on the request length. The maximum number of original requests merged in a clock cycle is M. When the request length is relatively small, the number of original requests merged in a clock cycle multiplied by the request length will be less than the amount of write data processed per clock cycle. To standardize the design of the data crossover switch when mapping write data to cached line data, a merge request length is set to the maximum of the original request length and the request length threshold (the amount of write data processed per cycle divided by the maximum number of original requests merged together in that cycle). The number of original requests merged together in that cycle (write_coalesce_init_sub_req_num) is equal to the amount of write data processed per cycle (coalesce_data_granularity) divided by the merge request length (coalesce_request_length).

[0190] The value of `coalesce_data_granularity` / M, representing the amount of write data processed per clock cycle, is the minimum length of the merge request. In the write data merging logic (thread data to cacheline data, i.e., the logic of placing write data to the corresponding cacheline position), the granularity of the data cross-switching switch is Q bytes. The number of inputs to the data cross-switching switch is the line width W / minimum length of the merge request Q, and the number of outputs is the cache line granularity R / minimum length of the merge request Q. The demultiplexer of the data cross-switching switch selects which output port to route to based on the address offset within the cache line; the multiplexer selects the input data based on the merging result, ultimately reflecting the write data overwrite strategy within the cache line. It is important to note that the address offset within the cache line is `address[log2(R) -1 : 0 ]`, and it needs to be aligned to Q bytes, meaning the value of `address [log2(Q)-1 : 0]` is set to 0.

[0191] 4. When the merged request length (coalesce_request_length) is greater than the request length threshold Q, the merged request length (coalesce_request_length) is equal to the original request length (request_length). It can be considered as dividing the request length bytes of data into two equal parts, each part is still Q bytes, and the offset of the address corresponding to each part in the cache line is offset, offset+Q, offset+2*Q, ...

[0192] 5. Each Q byte of data corresponds to a Q-bit bitmap (byte enable signal byte_equals), used to indicate whether the corresponding byte of data is valid. When the coalesce_request_length is greater than or equal to the request length threshold Q, the bitmap of each input Q-bit is all 1s.

[0193] 6. When the merged request length (coalesce_request_length) is less than or equal to the request length threshold Q, a pre-operation needs to be performed on the original request's request length bytes within the Q-byte range: shift each original request length byte left by Y bytes, where Y = the value of the original request's address [log2(Q)-1:0]. The left-shifted data is then used as the Q-byte input data. Simultaneously, the Q-bit bitmap is not all 1s; it is the result of shifting the original request length bytes left by Y bytes.

[0194] The embodiments of this application have at least the following technical effects: 1. By using the above method, it can be guaranteed that if there are M original requests that fall into different cache bodies, regardless of the identifier of the original request, the parallelism of the cache body can be guaranteed to be in the best state.

[0195] 2. When the maximum value of the number of original requests multiplied by the length of the original requests exceeds the granularity of the cache line, there is no need to add a data cache area to cache the data. The same write data merging logic can meet the needs of different request lengths, and will not cause layout routing problems or timing problems due to the increase in request length. Moreover, the amount of write data processed per cycle (coalesce_data_granularity) is equal to the maximum value between the connection width and the granularity of the cache line size. This can make full use of the interface's data bit width and avoid wasting the interface's data throughput. It can also ensure that in better application scenarios (such as M original requests accessing consecutive addresses), they can be directly merged into one cache line without increasing the number of cached requests or causing a decrease in system performance.

[0196] Based on the foregoing embodiments, this disclosure provides a request merging device, which includes the included units and the modules included in each unit, and can be implemented by a processor in a computer device; of course, it can also be implemented by specific logic circuits; in the implementation process, the processor can be a central processing unit (CPU), a microprocessor unit (MPU), a digital signal processor (DSP), or a field programmable gate array (FPGA), etc.

[0197] Figure 6 This is a schematic diagram of the composition structure of a request merging device provided in an embodiment of the present disclosure, as shown below. Figure 6 As shown, the request merging device 600 includes: a determining unit 610 and a merging unit 620, wherein: The determining unit 610 is used to determine the unit data volume of write data processed per cycle based on the maximum value of the connection width of write data between the upstream module and the memory merging module and the cache line size. The determining unit 610 is also used to determine the number of original requests to be merged in each batch based on the request length and unit data volume of the original request; wherein the total data volume of the original requests to be merged in each batch is less than or equal to the unit data volume. The merging unit 620 is used to merge multiple original requests according to the number of requests to obtain at least one merged request, and to map the data of each original request corresponding to the merged request based on the unit data volume to obtain the merged data of the merged request.

[0198] In some embodiments, the determining unit 610 is further configured to determine a request length threshold for each batch of requests based on the unit data volume and the maximum number of original requests merged per batch; determine the request length for each batch of requests based on the request length of the original requests and the request length threshold; and determine the number of requests for the original requests merged per batch based on the unit data volume and the request length for each batch of requests.

[0199] In some embodiments, the determining unit 610 is further configured to use the maximum value between the original request length and the request length threshold as the request length to be merged per beat.

[0200] In some embodiments, the merging unit 620 is further configured to merge a number of original requests with addresses in the same cache line into one request to obtain at least one merged request; determine a request length threshold for merging per cycle based on the unit data volume and the maximum number of original requests merged per cycle; for any merged request, determine the offset of the address of each original request in the cache line corresponding to the merged request based on the logarithm of the cache line size (base 2) and the request length threshold; after alignment processing based on the offset of the address of each original request in the cache line, map the data of each original request to the corresponding cache line position through data mapping logic to obtain the merged data of the merged request.

[0201] In some embodiments, the merging unit 620 is further configured to use the demultiplexer of the data cross switch to determine the output port to which the data of each original request is routed according to the offset of the address of each original request in the cache line; use the multiplexer of the data cross switch to determine the data corresponding to each output port of the data cross switch from the data of each original request at the input port of the data cross switch; and use the data corresponding to all output ports as merged data in the same cache line and output it.

[0202] In some embodiments, the merging unit 620 is further configured to, when the request length merged in each session is greater than the request length threshold, divide the data of each original request into multiple sub-data according to the request length threshold; determine the offset of the address of each sub-data in the cache line according to the logarithm of the cache line size to base 2; and determine the output port to which each sub-data should be routed according to the offset of the address of each sub-data in the cache line.

[0203] In some embodiments, the merging unit 620 is further configured to, when the request length merged in each frame is less than or equal to the request length threshold, sequentially determine the left shift bits of each original request based on the logarithm of the request length threshold to base 2; shift the data of each original request to the left according to the left shift bits to obtain multiple left-shifted data; and sequentially determine the output ports to which the multiple left-shifted data should be routed according to the logarithm of the cache line size to base 2.

[0204] In some embodiments, the merging unit 620 is further configured to, when the request length of each merge is greater than the request length threshold, set all bits in the bitmap corresponding to each sub-data to a first bit value; the first bit value indicates that the data of the corresponding byte is valid; and when the request length of each merge is less than or equal to the request length threshold, set some bits in the bitmap corresponding to each sub-data to the first bit value.

[0205] In some embodiments, the merging unit 620 is further configured to perform a storage bank hash operation on the memory address of the original requests before merging multiple original requests to obtain the storage bank identifier of the original requests; the storage bank identifier has a one-to-one correspondence with the merging operation; after obtaining the target merging request corresponding to any storage bank identifier, perform a group hash operation on the target merging request to obtain the group identifier of the target merging request; generate a cache request based on the group identifier of the target merging request and the corresponding merging data; the cache request is used to instruct the memory module to perform the operation corresponding to the target merging request based on the corresponding merging data.

[0206] The descriptions of the apparatus embodiments above are similar to those of the method embodiments above, and have similar beneficial effects. In some embodiments, the functions or modules included in the apparatus provided in this disclosure can be used to perform the methods described in the method embodiments above. For technical details not disclosed in the apparatus embodiments of this disclosure, please refer to the descriptions of the method embodiments of this disclosure for understanding.

[0207] It should be noted that, in the embodiments of this application, if the above-described request merging method is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the related technology, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, mobile hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware, software, or firmware, or any combination of hardware, software, and firmware.

[0208] This application provides a chip that includes the aforementioned request merging system.

[0209] This application provides a computer device including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements some or all of the steps in the above-described method.

[0210] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements some or all of the steps in the above-described method. The computer-readable storage medium can be transient or non-transient.

[0211] This application provides a computer program including computer-readable code. When the computer-readable code is run in a computer device, the processor in the computer device performs some or all of the steps in the above-described method.

[0212] This application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-described method. This computer program product can be implemented specifically through hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium; in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0213] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between them, while their similarities or commonalities can be referred to interchangeably. The descriptions of the above embodiments of the device, storage medium, computer program, and computer program product are similar to the descriptions of the above method embodiments and have similar beneficial effects. For technical details not disclosed in the embodiments of the device, storage medium, computer program, and computer program product of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0214] It should be noted that, Figure 7 This is a schematic diagram of a hardware entity of a computer device in an embodiment of this application, such as... Figure 7 As shown, the hardware entity of the computer device 700 includes: a processor 701, a communication interface 702, and a memory 703, wherein: Processor 701 typically controls the overall operation of computer device 700.

[0215] Communication interface 702 enables computer devices to communicate with other terminals or servers over a network.

[0216] The memory 703 is configured to store instructions and applications executable by the processor 701, and can also cache data to be processed or already processed (e.g., image data, audio data, voice communication data, and video communication data) in the processor 701 and various modules in the computer device 700. It can be implemented using flash memory or random access memory (RAM). Data transfer between the processor 701, the communication interface 702, and the memory 703 can be performed via bus 704.

[0217] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above steps / processes do not imply a sequential order of execution; the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0218] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0219] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0220] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0221] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0222] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0223] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, or the part that contributes to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, magnetic disks, or optical disks.

[0224] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A request merging method, characterized in that, The method includes: The unit data volume of write data processed per cycle is determined based on the maximum value between the connection width of write data between the upstream module and the memory merging module and the cache line size. Based on the request length of the original request and the unit data volume, the number of original requests merged in each batch is determined; wherein, the total data volume of the original requests merged in each batch is less than or equal to the unit data volume. Multiple original requests are merged according to the number of requests to obtain at least one merged request, and the data of each original request corresponding to the merged request is mapped based on the unit data volume to obtain the merged data of the merged request.

2. The method according to claim 1, characterized in that, The determination of the number of original requests merged per frame based on the request length of the original request and the unit data volume includes: Based on the unit data volume and the maximum number of original requests merged per batch, a request length threshold for merging per batch is determined. Based on the request length of the original request and the request length threshold, the request length for each merge is determined; Based on the unit data volume and the request length of each merge, the number of original requests for each merge is determined.

3. The method according to claim 2, characterized in that, The determination of the request length for each merge based on the request length of the original request and the request length threshold includes: The maximum value between the original request length and the request length threshold is taken as the request length for each merge.

4. The method according to any one of claims 1 to 3, characterized in that, The process of merging multiple original requests according to the number of requests to obtain at least one merged request, and mapping the data of each original request corresponding to the merged request based on the unit data volume to obtain the merged data of the merged request, includes: The number of original requests whose addresses are in the same cache line are merged into one request to obtain the at least one merged request; Based on the unit data volume and the maximum number of original requests merged per batch, a request length threshold for merging per batch is determined. For any merge request, the offset of the address of each original request corresponding to the merge request within the cache line is determined based on the logarithm of the cache line size (base 2) and the request length threshold. After aligning the addresses of each original request within the cache line, the data of each original request is mapped to the corresponding cache line position through data mapping logic to obtain the merged data of the merged request.

5. The method according to claim 4, characterized in that, After aligning the addresses of the original requests based on their offsets within the cache lines, the data of each original request is mapped to its corresponding cache line position using data mapping logic to obtain the merged data of the merged request, including: Using the demultiplexer of the data cross switch, the output port to which the data of each original request is routed is determined according to the offset of the address of each original request in the cache line; Using the multiplexer of the data cross switch, the data corresponding to each output port of the data cross switch is determined from the data of each original request at the input port of the data cross switch; All data corresponding to the output ports are merged into the same cache line and output.

6. The method according to claim 5, characterized in that, The step of determining the output port to which the data of each original request is routed based on the offset of the address of each original request within the cache line includes: If the length of the request merged in each frame is greater than the request length threshold, the data of each original request is divided according to the request length threshold to obtain multiple sub-data. Based on the logarithm of the cache line size (base 2), the offset of the address of each sub-data item within the cache line is determined sequentially. Based on the offset of the address of each sub-data item within the cache line, determine the output port to which each sub-data item should be routed.

7. The method according to claim 5, characterized in that, The step of determining the output port to which the data of each original request is routed based on the offset of the address of each original request within the cache line includes: If the request length of each merged request is less than or equal to the request length threshold, the left shift bits of each original request are determined sequentially based on the logarithm of the request length threshold to a base 2. The data of each original request is shifted to the left according to the specified left shift number, resulting in multiple left-shifted data; Based on the logarithm of the cache line size (base 2), the output ports to which the multiple left-shifted data should be routed are determined sequentially.

8. The method according to claim 6, characterized in that, The method further includes: If the request length for each merge exceeds the request length threshold, all bits in the bitmap corresponding to each sub-data are set to the first bit value; the first bit value indicates that the corresponding byte of data is valid. If the request length for each merged data is less than or equal to the request length threshold, a portion of the bits in the bitmap corresponding to each sub-data is set to the first bit value.

9. The method according to any one of claims 1 to 3, characterized in that, The method further includes: Before merging multiple original requests, a storage-based hash operation is performed on the memory address of each original request to obtain the storage-based identifier of the original request; the storage-based identifier has a one-to-one correspondence with the merging operation; After obtaining the target merge request corresponding to any storage identifier, a group hash operation is performed on the target merge request to obtain the group identifier of the target merge request; A cache request is generated based on the group identifier of the target merge request and the corresponding merge data; the cache request is used to instruct the memory module to perform the operation corresponding to the target merge request based on the corresponding merge data.

10. A request merging system, characterized in that, The system includes: The write data merging module is used to determine the unit data volume of write data processed per cycle based on the maximum value between the connection width of write data between the upstream module and the memory merging module and the cache line size. The write data merging module is further configured to determine the number of original requests to be merged in each batch based on the request length of the original request and the unit data volume; wherein the total data volume of the original requests merged in each batch is less than or equal to the unit data volume. The request merging module is used to merge multiple original requests according to the number of requests to obtain at least one merged request; The write data merging module is further configured to map the data of each original request corresponding to the merging request based on the unit data volume, so as to obtain the merged data of the merging request.

11. The system according to claim 10, characterized in that, The write data merging module includes: A data crossover switch is used to align the addresses of the original requests corresponding to the merge request within the cache line for any merge request, and then map the data of each original request to the corresponding cache line position through data mapping logic to obtain the merged data of the merge request; the offset is determined based on the logarithm of the cache line size to base 2 and is aligned with the request length threshold for each merge.

12. The system according to claim 10 or 11, characterized in that, The system also includes: The storage hash module is used to perform a storage hash operation on the memory address of the original requests before merging multiple original requests, to obtain the storage identifier of the original requests; the storage identifier has a one-to-one correspondence with the merging operation; The group hash module is used to perform a group hash operation on the target merge request after obtaining the target merge request corresponding to any storage identifier, to obtain the group identifier of the target merge request; and to generate a cache request based on the group identifier of the target merge request and the corresponding merge data; the cache request is used to instruct the memory module to perform the operation corresponding to the target merge request based on the corresponding merge data.

13. A chip, characterized in that, The chip includes the request merging system according to any one of claims 10 to 12.

14. A request merging device, characterized in that, The device includes: The determination unit is used to determine the unit data volume of write data processed per cycle based on the maximum value between the connection width of write data between the upstream module and the memory merging module and the cache line size. The determining unit is further configured to determine the number of original requests merged in each batch based on the request length of the original request and the unit data volume; wherein the total data volume of the original requests merged in each batch is less than or equal to the unit data volume. The merging unit is further configured to merge multiple original requests according to the number of requests to obtain at least one merged request, and to map the data of each original request corresponding to the merged request based on the unit data volume to obtain the merged data of the merged request.

15. A computer device comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method according to any one of claims 1 to 9.

16. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the method according to any one of claims 1 to 9.

17. A computer program product comprising a non-transitory computer-readable storage medium storing a computer program, wherein when the computer program is read and executed by a computer, it implements the steps of the method according to any one of claims 1 to 9.

Images