Read transaction management in a storage controller

Abstract

The application provides a method for managing read transactions in a storage controller (100), comprising the following steps: receiving a plurality of read requests from an initiator (S1) for requesting read data from an external storage device; sequentially storing the plurality of read requests in a read rollback buffer (S2); assigning each read request to a transaction ID tracker according to a transaction ID of the read request (S3); marking a data valid state for the read request (S4); marking a header data valid state for the transaction ID tracker (S5); arbitrating the read requests whose header data valid state is marked as completed (S6); and returning the read data to the initiator in an order determined in the arbitration process (S7). The application also discloses a storage controller for managing read transactions.

Description

Technical Field

[0001] This invention relates to the field of storage controller design, and more specifically, to methods and systems for managing the order of read transactions in a storage system. Background Technology

[0002] The memory controller is a critical component in modern computing systems, responsible for managing data transfer between the processor and storage devices. In many systems, read requests from different threads may be issued out of order, but to ensure proper system operation, the correct order of data returns must be maintained. Traditional memory controllers typically employ complex arbitration logic to manage the order of read responses, which can lead to increased latency and power consumption.

[0003] The following are some examples of existing technologies related to managing read transactions of storage controllers.

[0004] US Patent Publication No. US6772300B1 discloses a computer system including main memory and a chipset coupled to the main memory. The chipset includes a transaction memory, a first memory bank controller, and a second memory bank controller coupled to the transaction memory. The first memory bank controller stores transaction data to be transferred to a first main memory bank in the transaction memory according to a first linked list. The second memory bank controller stores transaction data to be transferred to a second main memory bank in the transaction memory according to a second linked list.

[0005] Another example is U.S. Patent Publication No. US2012331197A1, which discloses a storage controller for controlling access to a storage device with non-uniform access timing characteristics. An interface receives transactions from at least one transaction source, while a buffer temporarily stores pending transactions that have not yet been sent to the storage device. This buffer maintains multiple ordered lists (containing multiple entries) for storing pending transactions, including at least one priority-based ordered list and at least one access timing-based ordered list. Each entry is associated with a pending transaction and is ordered in the priority-based ordered list according to the priority of the associated pending transaction. During arbitration operations, an arbitration circuit selects a winning transaction based on these ordered lists and sends it to the storage device.

[0006] Furthermore, US Patent No. US2009019238A1 discloses a storage controller that receives read requests from the processor into a read queue. The storage controller dynamically adjusts the order in which requests are served based on the number of pending requests in the read queue. When the read queue is relatively empty, requests are served in a first-in, first-out (FIFO) order to minimize latency. When the read queue becomes full, requests are served in a manner that maximizes storage bus throughput to reduce the likelihood of the read queue becoming full, thereby preventing further processor requests from being paused.

[0007] Clearly, existing read transaction management methods and systems lack the ability to efficiently manage and prioritize read transactions with the same transaction ID. Summary of the Invention

[0008] The following is a simplified overview of the invention, intended to provide a basic understanding of certain aspects of the invention. This overview is not a complete summary of the invention. Its sole purpose is to introduce some concepts of the invention in a simplified form, laying the groundwork for a more detailed description thereafter.

[0009] One object of the present invention is to provide a method and apparatus for efficiently managing out-of-order read transactions in a storage controller.

[0010] Another objective of this invention is to develop a scalable solution for handling a large number of unresolved read transactions.

[0011] Accordingly, these objectives can be achieved by following the teachings of this invention. This invention proposes a method for managing read transactions in a storage controller, characterized by the following steps: receiving multiple read requests from an initiator for requesting to read data from an external storage device, each read request being associated with a transaction ID; storing the multiple read requests sequentially in a read retirement buffer, each read request entry being associated with a retirement buffer entry number; and assigning each read request to a transaction ID tracker based on its transaction ID. Wherein, if a transaction ID is not yet recorded in the read retirement buffer, an unused transaction ID tracker is selected and assigned to the read request. Read requests with the same transaction ID as earlier read requests in the read retirement buffer are assigned to the same transaction ID tracker. The transaction ID tracker records the first and last rollback buffer entry numbers associated with that transaction ID tracker; when read data is returned from an external storage device, the data validity status of the read request is marked; when the data validity status of the first rollback buffer entry number associated with the transaction ID tracker is marked as complete, the header data validity status of the transaction ID tracker is marked; based on the order of read requests in their respective transaction ID trackers, the rollback order of read requests marked as complete is arbitrated by selecting the next data return request; and the read data is returned to the initiator in the order determined during the arbitration process.

[0012] Furthermore, this invention also proposes a storage controller for managing read transactions, characterized by comprising: a read rollback buffer for sequentially storing read requests and assigning a read rollback buffer number to each read request entry; multiple transaction ID trackers, each tracker associated with a group of read requests having the same transaction ID, each transaction ID tracker storing the first and last rollback buffer entry numbers of the read requests associated with that transaction ID tracker; a data validity tracking module configured to: set a data validity status for the read request entry when read data of the request is returned from an external storage device; and set a header data validity status for the transaction ID tracker when the data validity status of the first rollback buffer entry number associated with the tracker is complete; an arbitration module configured to arbitrate the rollback order of read requests with a header data validity status of complete by selecting the next read request to return data, based on the order of the read requests in their respective transaction ID trackers; and a data return module configured to return the read data to the initiator in the order determined by the arbitration module.

[0013] The above and other objects, features, aspects and advantages of the present invention can be better understood by carefully reading the following detailed description and taking appropriate reference to the accompanying drawings. Attached Figure Description

[0014] To gain a detailed understanding of the features mentioned above, the invention can be described in more detail through specific embodiments, some of which are illustrated in the accompanying drawings. However, it should be noted that the drawings only show typical embodiments of the invention and should not be considered as limiting its scope; other equally effective embodiments may also exist.

[0015] These and other features, advantages, and benefits of the invention will become apparent from the following accompanying drawings, wherein like reference numerals refer to like structures in the views, wherein:

[0016] Figure 1 A flowchart illustrating a method for reading transactions in a storage controller according to an embodiment of the present invention is shown. Detailed Implementation

[0017] Detailed embodiments are disclosed herein if needed; however, it should be understood that these disclosed embodiments are merely examples of the invention, which can be embodied in many forms. Therefore, the specific structural and functional details disclosed herein should not be construed as limiting, but rather as the basis for the claims. It should be understood that the drawings and detailed description are not intended to limit the invention to the specific forms disclosed; rather, the invention is intended to cover all modifications, equivalents, and alternatives within the scope defined by the appended claims. In this application, “may” is used in a permissive sense (i.e., indicating a potential possibility) rather than a mandatory sense (i.e., indicating a requirement). Similarly, “comprising,” “including,” and “including” mean “including, but not limited to.” Furthermore, “a” and “an” mean “at least one,” and “a plurality” means “one or more,” unless otherwise stated. When abbreviations or technical terms are used, these terms have meanings generally accepted in the relevant art.

[0018] The invention is described below with reference to the accompanying drawings, which use reference numerals throughout the specification corresponding to the same elements. However, the invention can be embodied in many forms and should not be construed as limited to the embodiments described herein. Rather, these embodiments are provided to make this disclosure more complete and to fully convey the scope of the invention to those skilled in the art. In the following detailed description, numerical values ​​and ranges are provided for the various embodiments described. These numerical values ​​and ranges are by way of example only and are not intended to limit the scope of the claims. Furthermore, various materials have been identified that are suitable for different aspects of the various embodiments. These materials are also by way of example only and are not intended to limit the scope of the invention.

[0019] refer to Figure 1 The invention will be described in further detail with reference to the accompanying drawings.

[0020] like Figure 1 As shown, this invention proposes a method (100) for managing read transactions in a storage controller. The method (100) first receives multiple read requests from the initiator (step S1), each read request being associated with a unique transaction ID. Subsequently, these read requests are sequentially stored in a read rollback buffer (step S2), with each read request entry assigned a unique rollback buffer entry number. Next, each read request is assigned to a specific transaction ID tracker (step S3). If the transaction ID of a read request is not already recorded in the read rollback buffer, an unused tracker is selected and assigned to that request. Conversely, if a read request has the same transaction ID as an earlier read request in the read rollback buffer, it is assigned to the same existing transaction ID tracker. Each transaction ID tracker records the first and last rollback buffer entry numbers associated with the read requests it tracks.

[0021] A transaction ID is a thread identifier used to identify read transactions from the same thread. Specifically, in a system based on the AXI protocol, a transaction ID refers to an AXI ID, and a transaction ID tracker refers to an AXI ID tracker.

[0022] When read data for a specific request is returned from the external storage device, its corresponding data validity status is marked (step S4). Furthermore, when the data validity status of the first request in the transaction ID tracker (e.g., the tracker header) is marked as complete, the data validity status of that tracker header is marked (step S5). Subsequently, the method (100) arbitrates the rollback order of read requests whose transaction ID tracker header data validity status is marked (step S6). This arbitration process includes selecting the next read request for data return based on the order of the read requests in their assigned trackers. Finally, the read data is returned to the initiator according to the order determined by the arbitration process (step S7).

[0023] According to one embodiment of the invention, for read requests assigned to the same transaction ID tracker, the backoff buffer entry number of the read request is recorded in the earlier read request entry within the same transaction ID tracker. A linked list is created within each tracker, where each entry points to the next read request associated with the same transaction ID. This linked list structure facilitates efficient tracking of the order of read requests within each tracker, allowing the storage controller to easily determine the next read request that needs to be backoffed based on its position in the linked list.

[0024] According to one embodiment of the present invention, when no unused transaction ID trackers are available for allocation to a read request, a transaction ID tracker already associated with another transaction ID will be allocated to the read request according to predetermined rules to achieve transaction ID tracker sharing. This tracker allocation method ensures that all read requests are properly managed, even if the number of concurrent transactions exceeds the number of initially available trackers. The process of allocating read requests to shared trackers is controlled by predetermined rules, for example, allocating requests to trackers associated with transaction IDs that match the low-order subset (binary number) of the currently requesting transaction ID.

[0025] According to one embodiment of the invention, read requests are assigned to a transaction ID tracker that matches a subset of the low-order bits of the transaction ID of the read request. Specifically, a transaction ID tracker can be selected based on the low-order [M-1:0] bits of the AXI ID, where M represents the number or depth of transaction ID trackers. For example, when all transaction ID trackers 0, 1, 2, 3 (M=4) are occupied, a new read request entry with an AXI ID of 9 (binary number 1001) will be assigned to transaction ID tracker 1 (binary number 001) because their low-order three bits match, i.e., "001". This technique assigns read requests to available trackers in a more predictable and consistent manner.

[0026] By using a subset of low-order bits, it can be ensured that read requests are assigned to the same tracker based on the defined pattern of transaction ID or AXI ID, thereby improving the efficiency of tracking and managing related requests. This approach provides a scalable solution for handling a large number of concurrent transactions, while minimizing the possibility of tracker contention and improving the overall performance of the system.

[0027] It should be understood that the above method of allocating transaction ID trackers is only one possible implementation, applicable when the number of transaction ID trackers is a power of 2. Other implementations of allocating transaction ID trackers can also be adopted, such as round-robin assignment, hashing, or XOR operations, to ensure that read requests are fairly and efficiently distributed among available trackers.

[0028] According to one embodiment of the invention, the arbitration rollback order includes prioritizing the rollback of read requests based on their dwell time (i.e., "age") in the read rollback buffer. This helps prevent starvation of earlier transactions, ensuring that all read requests are eventually processed in a timely manner. This mechanism is particularly beneficial in resource-contested scenarios because it prevents newer transactions from monopolizing system bandwidth, thus ensuring fair access for all pending read requests. As an alternative, rollback order arbitration can also be implemented using round-robin arbitration instead of prioritization to simplify the implementation.

[0029] According to one embodiment of the invention, the arbitration rollback order includes sequentially scheduling the rollback of read requests with the same transaction ID in a non-interleaved manner. For the first transaction, the tracker arbitrates, selecting the tracker with the marked data validity status and header data validity status. Subsequent read requests belonging to the same transaction ID will be rolled back sequentially before proceeding to the next transaction ID. By prioritizing the completion of each transaction ID before moving on to the next, this approach improves the predictability of data transmission, making it particularly suitable for applications that require strict adherence to the read response order within a specific transaction.

[0030] According to another embodiment of the invention, the arbitration rollback sequence includes arranging the rollback of read requests with different transaction IDs from the previous read requests in an interleaved manner. This means that read requests from different transaction IDs are rolled back in an alternating order. For example, the system might roll back the read request with transaction ID 1 first, then the read request with transaction ID 2, and then another read request with transaction ID 1. This interleaving method helps ensure fair resource allocation and prevents starvation of low-ID transactions. By distributing the service of read requests among different transaction IDs, interleaved rollback can improve the overall throughput and responsiveness of the system.

[0031] According to one embodiment of the present invention, after the read data of a read request is returned to the initiator, the data validity status and header data validity status are reset. By resetting these status flags, the storage controller can correctly identify and prioritize the next batch of read requests to be rolled back, thereby maintaining the integrity of the tracking mechanism and ensuring the smooth and continuous operation of the system.

[0032] Furthermore, this invention also proposes a storage controller for managing read transactions, characterized by: a read rollback buffer for sequentially storing read requests and assigning a read rollback buffer number to each read request entry; multiple transaction ID trackers, each tracker associated with a group of read requests having the same transaction ID, each transaction ID tracker storing the first and last rollback buffer entry numbers of the read requests associated with the transaction ID tracker; a data validity tracking module configured to set a data validity status for a read request entry when the external storage device returns read data; and to set a header data validity status for the transaction ID tracker when the data validity status of the first rollback buffer entry number associated with the tracker is complete; an arbitration module configured to arbitrate the rollback order of read requests with a header data validity status of complete by selecting the next read request to return data, based on the order of the read requests in their respective transaction ID trackers; and a data return module configured to return read data to the initiator in the order determined by the arbitration module.

[0033] According to one embodiment of the invention, the arbitration module is configured to prioritize read request rollbacks based on the time a read request has resided in the read rollback buffer (i.e., its "age"). This age-based prioritization mechanism ensures that earlier read requests are processed before newer ones, thereby minimizing latency and preventing starvation of earlier transactions.

[0034] The invention will now be described in more detail by way of examples. These examples illustrate specific embodiments of the invention using a storage controller operating on the AXI protocol. These examples are intended to illustrate the key principles and advantages of the invention so that the reader can more easily understand and put these examples into practice. However, it should be understood that the following examples are not intended to limit the scope of the invention in any way.

[0035] Example

[0036] Example 1: Loading a new command into the backplane buffer

[0037] In this scenario, the transaction ID and the AXIID of the read command are synonymous; therefore, the transaction ID tracker is also called the AXIID tracker. Table 1 provides a simplified representation of the read rollback buffer and the AXI ID tracker. The read rollback buffer is depicted as an array of 10 entries (N=10), each capable of storing a read request. Each entry in the buffer is associated with a unique rollback buffer entry number. Next to the read rollback buffer, four AXI ID trackers (M=4) are shown, each tracker used to track read requests associated with a specific AXI ID.

[0038] Table 1

[0039]

[0040] When a new read command is received, the system first determines the appropriate AXI ID tracker to assign to it. The assignment process follows a set of priority rules. First, if the new command's AXI ID matches any existing read request's AXI ID already stored in the buffer, the new command is assigned to the same AXI ID tracker as the existing request. If the AXI ID is not already associated with any tracker, the system selects the next available unused tracker (i.e., the tracker with the valid flag set to 0). In this example, a "first-come, first-served" strategy is used to select the first available unused tracker. The selection method is not limited to this and can also be based on a hash function or XOR operation. Finally, if all available trackers are in use, the system assigns the new command to an existing tracker according to predetermined rules, such as selecting a tracker based on the low-order [M-1:0] bits of the AXI ID. This dynamic allocation strategy ensures that all read requests are assigned to a tracker even if the number of concurrent transactions exceeds the initial number of available trackers.

[0041] Table 2 below shows the initial state of the system when the first command arrives.

[0042] Table 2

[0043]

[0044] The command, with AXIID 5, is received and stored in entry 0 of the read backoff buffer. The "Valid" field of this entry is set to 1, indicating that it is a valid, pending read request. Since AXIID 5 is not currently being tracked by any AXIID tracker, and assuming no prior bursts of activity for this AXIID, the system selects the first available unused tracker (AXIID tracker 0) according to a "first-come, first-served" policy. The "Valid" field of AXIID tracker 0 is set to 1, and its head and tail pointers are assigned to backoff buffer entry 0, indicating that this tracker is now tracking this specific read request.

[0045] Furthermore, Table 3 shows the system status after the second command arrives.

[0046] Table 3

[0047]

[0048] The command's AXI ID is 10, which is received and stored in entry 1 of the read rollback buffer. Since AXI ID 10 is not currently being tracked by any AXI ID tracker, the system selects the next available unused tracker, AXI ID tracker 1. The "Valid" field of AXI ID tracker 1 is set to 1, and the tracker's head and tail pointers are updated to point to the newly added rollback buffer entry 1, indicating that this tracker is now tracking this specific read request.

[0049] Table 4 shows the system status after the third command arrives.

[0050] Table 4

[0051]

[0052] The command, also with AXI ID 10, is received and stored in entry 2 of the read rollback buffer. Since AXI ID 10 is already being tracked by AXI ID tracker 1 (as evidenced by the presence of a previous read request with the same AXI ID in entry 1), the new command is assigned to the same AXI ID tracker 1. The tail pointer of AXI ID tracker 1 is then updated to point to the new entry 2, effectively expanding the list of read requests associated with that AXI ID in the tracker. This operation indicates that read requests with the same transaction ID should be assigned to the same AXI ID tracker.

[0053] Table 5

[0054]

[0055] Furthermore, Table 5 shows the system state after the arrival of the fourth command. This command, with AXI ID 5, was received and stored in entry 3 of the read rollback buffer. Since AXI ID 5 has already been tracked by AXI ID tracker 0, and a previous read request with the same AXI ID exists in entry 0, the new command is assigned to the same AXI ID tracker 0. Then, the tail pointer of AXI ID tracker 0 is updated to point to the new entry 3, effectively expanding the list of read requests associated with this AXI ID in the tracker. This operation indicates that read requests with the same transaction ID should be assigned to the same AXI ID tracker.

[0056] Table 6

[0057]

[0058] Next, Table 6 shows the system status after the fifth command arrives. This command, with AXI ID 11, is received and stored in entry 4 of the read backoff buffer. Since AXI ID 11 is not currently being tracked by any AXI ID tracker, the system selects the next available unused tracker, AXI ID tracker 2. The "Valid" field of AXI ID tracker 2 is set to 1, and its head and tail pointers are updated to point to the newly added backoff buffer entry 4.

[0059] Table 7

[0060]

[0061] Table 7 shows the system status after the sixth command arrives. This command, with AXI ID 8, is received and stored in entry 5 of the read backoff buffer. Since AXI ID 8 is not currently being tracked by any AXI ID tracker, the system selects the next available unused tracker, AXI ID tracker 3. The "Valid" field of AXI ID tracker 3 is set to 1, and its head and tail pointers are updated to point to the newly added backoff buffer entry 5.

[0062] Table 8

[0063]

[0064] Furthermore, Table 8 shows the system state after the arrival of the seventh command. This command, with AXI ID 9, was received and stored in entry 6 of the read backoff buffer. Since AXI ID 9 is not currently being tracked by any AXI ID tracker, and all available trackers (trackers 0 through 3) are in use, the system needs to assign the command to an existing tracker. To handle this situation, the system employs a mechanism that assigns the read request to an available tracker when all trackers are occupied. In this example, the system examines the low-order bits of the AXI ID, specifically the lower three bits, because there are four trackers to determine the target tracker. Based on the values ​​of these low-order bits, the system selects AXI ID tracker 1 to process the command.

[0065] Example 2: Rollback of a transaction

[0066] When read data is returned from an external storage device to the storage controller, the "Data Valid" field associated with the read request in the read rollback buffer is set to 1. The order in which data is returned from the storage device does not necessarily correspond to the order in which the read requests were initially received and stored in the buffer.

[0067] Table 9 below highlights a scenario where multiple read requests exist in the system, and the "Data Valid" field for multiple read requests is set to 1, indicating that the corresponding read data has been received from the storage device. Specifically, currently, the "Data Valid" field for entries 3, 4, and 5 in the read rollback buffer is set to 1. However, not all of these entries can be rolled back immediately. The table emphasizes the importance of adhering to the AXI ID ordering rule, which requires that read requests within the same transaction ID must be returned to the initiator in the order they were received. Therefore, although entry 3 has its "Data Valid" field set, it cannot be rolled back immediately because it is not the first read request for AXI ID 5 (entry 0 holds the first request for AXI ID 5). Therefore, only entries 4 and 5 are eligible for immediate rollback because they represent the "header" of their respective transaction ID trackers (tracker 2 and tracker 3), and their "Data Valid" field is set to 1. The table then introduces the concept of arbitration to select the next read request to be rolled back from the eligible candidates.

[0068] Table 9

[0069]

[0070] Table 10

[0071]

[0072] Table 10 details the arbitration process, including selecting the next tracker to roll back based on age priority and the subsequent updating of tracker status flags. First, AXI ID trackers with the "Header Data Valid" field set to 1 are identified. In this specific scenario, only AXI ID trackers 2 and 3 meet this condition. Assuming an age-based arbitration strategy, the arbitration module selects AXI ID tracker 2 for rollback because it is the earlier of the two eligible trackers. After the read data associated with entry 4 (the header of AXI ID tracker 2) is rolled back, the "Data Valid" and "Valid" fields for that entry are reset to 0. Since AXI ID tracker 2 only tracked a single entry—entry 4—its header and tail pointers now point to the same invalid entry. Therefore, the "Valid" field and its "Header Data Valid" field of AXI ID tracker 2 are also reset to 0.

[0073] Table 11

[0074]

[0075] Table 11 illustrates the next step in the rollback process. Since the "Data Valid" field of rollback buffer entry 5 associated with AXI ID 8 is set to 1, and it is the "Header" entry for its corresponding AXIID tracker 3, it is now eligible for rollback. The arbitration module selects this entry for rollback in the next cycle. After rollback entry 5, the "Data Valid" field of entry 5 in the read rollback buffer is reset to 0, indicating that this entry has been processed and the read data has been returned to the initiator. The "Valid" field of entry 5 in the read rollback buffer is also reset to 0, indicating that this buffer entry is now available to store new read requests. Since entry 5 is the last entry tracked by AXI ID tracker 3, the "Valid" field of AXIID tracker 3 is also reset to 0, indicating that this tracker no longer tracks any active read requests.

[0076] Table 12

[0077]

[0078] Table 12 shows that multiple read requests have received corresponding read data from the storage device. Currently, the "Data Valid" field of the read requests stored in rollback buffer entries 0 and 1 is set to 1, indicating that the required read data has been received. This situation causes two AXI ID trackers (the trackers associated with the read requests in entries 0 and 1) to set their "Header Data Valid" field to 1, indicating that the headers of these trackers currently contain valid data and are ready for rollback. This highlights the situation where multiple trackers have valid data to be rolled back, laying the foundation for the arbitration process to select the next read request to be returned to the initiator.

[0079] Table 13

[0080]

[0081] Furthermore, Table 13 shows the system state after the read request stored in rollback buffer entry 0 has been rolled back. Although entry 0 has been rolled back, AXIID tracker 0 remains valid because it is still tracking another active read request (the read request stored in entry 3). To maintain accurate tracking, the head pointer of AXIID tracker 0 is updated to point to the next entry in the sequence, i.e., entry 3. Since the read data for the read request stored in entry 3 has been received, its "Data Valid" field is set to 1, and the "Header Data Valid" field of AXIID tracker 0 remains set to 1, indicating that the head of this tracker still contains valid data to be rolled back.

[0082] Table 14

[0083]

[0084] Table 14 shows the decision point at which the system must select the next read request to be rolled back. At this stage, two entries are eligible for rollback: rollback buffer entry 3 (associated with AXIID 5) and rollback buffer entry 1 (associated with AXIID 10). If non-interleaved priority is implemented, rollback buffer entry 3 will be selected for rollback, ensuring that all read requests belonging to the same transaction ID (AXI ID 5 in this example) are rolled back consecutively before proceeding to the next transaction ID. Since entry 3 is the last entry tracked by AXIID tracker 0, rolling back this entry effectively completes the processing of all read requests associated with AXIID 5. Therefore, both "valid" fields of AXIID tracker 0 are reset to 0, indicating that this tracker is no longer active. The system can then continue rolling back entry 1 in the next cycle.

[0085] Table 15

[0086]

[0087] Table 15 also explores another scenario where AXI ID interleaving is preferred. In this case, if AXI ID interleaving is selected, the system will prioritize rolling back the rollback buffer entry 1 belonging to a different transaction ID (AXI ID 10). This interleaving strategy helps to distribute read requests more evenly across different transaction IDs, preventing potential starvation for transactions with lower request frequencies. After rolling back buffer entry 1, the header field of AXIID tracker 1 is updated to point to the next entry in the sequence, i.e., entry 2, which can be traced from the rollback buffer entry 1 in the "Next Entry" field. However, since buffer entry 2 has not yet received its read data, the "Header Data Valid" field of AXIID tracker 1 is reset to 0. This indicates that the header of this tracker currently does not contain valid data to be rolled back. With the rollback of entry 1, the system can continue rolling back entry 3 in the next cycle, as it is now the header of its corresponding tracker (AXI ID tracker 0), and its "Data Valid" field has been set to 1.

[0088] These examples illustrate the operational method of the present invention. The order in which read data is returned can vary depending on the chosen arbitration strategy. For example, for AXI ID 5 and AXI ID 10, the order could be entry 0 (AXI ID 5), entry 1 (AXI ID 10), then entry 3 (AXI ID 5), or it could be entry 0 (AXI ID 5), entry 3 (AXI ID 5), then entry 1 (AXI ID 10). Importantly, both orders follow the AXI ID sorting rules, ensuring that read requests within the same transaction ID are returned in the correct order. A key advantage of the present invention is its ability to significantly reduce the complexity of managing and comparing transactions by focusing on a limited number of AXI ID trackers (M) instead of inspecting the entire read backoff buffer (K ​​entries). This simplification results in improved performance, reduced latency, and a more manageable design, especially in systems with a large number of incomplete read transactions. The number of trackers (M) can be adjusted according to system requirements and resource constraints to achieve an optimal balance between performance and hardware complexity.

[0089] This invention addresses the limitations of traditional storage controllers in managing out-of-order read transactions. Unlike conventional methods that typically require searching the entire read backoff buffer to determine the next pending read request, this invention introduces a method utilizing a dedicated transaction ID tracker to efficiently group and manage read requests associated with the same transaction ID. This approach significantly reduces the complexity and hardware overhead associated with the arbitration process, thereby improving performance and reducing latency, particularly in systems with a large number of incomplete read transactions.

[0090] Various modifications to the embodiments described above will be apparent to those skilled in the art based on the description and drawings of the present invention. The principles associated with the various embodiments described above can be applied to other embodiments. Therefore, the purpose of the above description is not to limit itself to the embodiments shown in the drawings, but to provide the broadest scope consistent with the principles, novelty, and inventiveness disclosed or implied above. Thus, the present invention is intended to cover all other alternatives, modifications, and variations that fall within the scope of the present invention and the appended claims.

[0091] In the following patent claims and the foregoing description of the invention, unless the context requires otherwise due to phonetic expression or necessary meaning, the word “comprising” or variations thereof, such as “including” or “containing”, are used in the sense of inclusion, that is, to specify the presence of the said feature, but do not exclude the possibility of the presence or addition of further features in various embodiments of the invention.

Claims

1. A method (100) for managing read transactions in a storage controller, characterized in that, Includes the following steps: Receive multiple read requests (S1) from the initiator to request data to be read from the external storage device. Each read request is associated with a transaction ID. The multiple read requests are stored sequentially in the read rollback buffer (S2), and each read request entry is associated with a rollback buffer entry number; Each read request is assigned to the transaction ID tracker (S3) based on its transaction ID; where: If the transaction ID is not yet recorded in the read rollback buffer, an unused transaction ID tracker is selected and assigned to the read request; The read request that has the same transaction ID as an earlier read request in the read rollback buffer is assigned to the same transaction ID tracker; The transaction ID tracker records the first rollback buffer entry number and the last rollback buffer entry number associated with the transaction ID tracker; When the read data of the read request is returned from the external storage device, the data validity status of the read request is marked (S4); When the data validity status of the first rollback buffer entry number associated with the transaction ID tracker is marked as complete, the header data validity status of the transaction ID tracker is marked (S5); Based on the order of the read requests in their respective transaction ID trackers, the rollback order of the read requests whose header data validity status is marked as completed is arbitrated by selecting the next data return request (S6). The read data is returned to the initiator in the order determined during the arbitration process (S7).

2. The method according to claim 1, wherein, For read requests assigned to the same transaction ID tracker, the backoff buffer entry number of the read request is recorded in the earlier read request entry of the same transaction ID tracker.

3. The method according to claim 1, wherein, When no unused transaction ID tracker is available to be assigned to the read request, the transaction ID tracker that is already associated with another transaction ID is assigned to the read request according to predetermined rules to share the transaction ID tracker.

4. The method according to claim 3, wherein, The read request is assigned to the transaction ID tracker that matches the low-order subset of the transaction ID of the read request.

5. The method according to claim 1, wherein, Arbitration of the rollback order (S6) includes: prioritizing the rollback of the read request based on the dwell time of the read request in the read rollback buffer.

6. The method according to claim 1, wherein, Arbitration of the rollback order (S6) includes: sequentially scheduling the rollback of read requests with the same transaction ID in a non-interleaved manner.

7. The method according to claim 1, wherein, Arbitrate the rollback order (S6), including: scheduling the rollback of read requests with different transaction IDs than the previous read requests in an interleaved manner.

8. The method according to claim 1, wherein, After the read data of the read request is returned to the initiator (S7), the data validity status and the header data validity status are reset.

9. A storage controller for managing read transactions, characterized in that, include: The read rollback buffer is used to store read requests sequentially, and a read rollback buffer number is associated with each request entry; Multiple transaction ID trackers, each tracker is associated with a set of read requests with the same transaction ID, and each transaction ID tracker stores the first and last backoff buffer entry numbers of the read requests associated with the transaction ID tracker; The data validity tracking module is configured as follows: When the external storage device returns the read data for the read request, the data validity status is set for the read request entry, and When the data validity status of the first rollback buffer entry number associated with the tracker is complete, the header data validity status is set for the transaction ID tracker; The arbitration module is configured to arbitrate the rollback order of read requests whose header data is valid and whose status is complete, based on the order of the read requests in their respective transaction ID trackers by selecting the next read request to return data. The data return module is configured to return the read data to the initiator in the order determined by the arbitration module.

10. The storage controller according to claim 9, wherein, The arbitration module is configured to prioritize the rollback of read requests based on the dwell time of the read request in the read rollback buffer.

Images