Order-preserving control method and device

Abstract

The invention relates to the technical field of computers, and provides an order-preserving control method and device, and the method comprises the steps: distributing requests from a plurality of sources to a plurality of physical request queues according to an address mapping rule; maintaining a sequence recording queue for each order-preserving request, wherein the sequence recording queue is used for recording the sequence information of the order-preserving request and a corresponding physical request queue identifier; according to a sequence record state in the sequence record queue, determining a currently sendable target order-preserving request and a corresponding target physical request queue; sending a sequence permission signal to the target physical request queue; and the target physical request queue sends the target order-preserving request to an output request queue in response to the order permission signal. On the premise that a special order-preserving queue is not added, order-preserving constraint control over the cross-physical independent queue is achieved, consumption increase of storage resources is avoided, and meanwhile the logic depth is controlled to meet the performance requirement.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a sequence-preserving control method and apparatus. Background Technology

[0002] In multi-core processors, on-chip, and high-performance memory control, a multi-physical independent queue structure is typically used to improve throughput. Requests from multiple sources are distributed to different physical queues for parallel processing based on address mapping rules. However, certain request types (such as specific instructions or strongly consistent operations) require sequential control of requests from the same source; that is, requests from the same source must be sent in the order they were generated. When requests are distributed to multiple physical queues according to address mapping, multiple requests from the same source requiring order preservation may enter different physical queues. Since each queue is scheduled independently, without a unified coordination mechanism, out-of-order requests for order preservation may occur. In existing technologies, adding order preservation queues increases the number of queues with the number of sources, leading to increased storage resource consumption and decreased queue utilization. On the other hand, using a single physical queue for sequential control, due to the lack of a parallel physical queue structure, cannot fully parallelize request processing, limiting throughput. Furthermore, the high logical depth of a single large queue limits clock frequency, making it difficult to meet the performance requirements of high-concurrency scenarios. Summary of the Invention

[0003] The purpose of this application is to provide a sequence-preserving control method and apparatus to alleviate the above-mentioned technical problems.

[0004] In a first aspect, the present invention provides a sequence-preserving control method, comprising: Requests from multiple sources are distributed to multiple physical request queues according to address mapping rules. The requests include ordered requests and non-ordered requests. Maintain a sequence record queue for each order preservation request to record the order information of the request and the corresponding physical request queue identifier; determine the target order preservation request that can be sent and the corresponding target physical request queue based on the order record status in the sequence record queue; send an order permission signal to the target physical request queue. In response to the sequence permission signal, the target physical request queue sends the target order-keeping request to the output request queue.

[0005] In an optional implementation, it further includes: Within each physical request queue, a dependency matrix is ​​used to manage the sequential dependencies between all requests in that queue. The rows and columns of the dependency matrix correspond to the request items in the queue, and the matrix elements represent the dependency state between the request items. The target physical request queue selects requests with no unmet dependencies from the ordered requests based on the dependency matrix as the target ordered requests.

[0006] In an optional implementation, after sending the target order-preserving request to the output request queue, the method further includes: updating the dependency matrix; Updating the dependency matrix includes: clearing the dependency markers of selected requests on other requests, and adjusting the dependencies between requests with the same address to ensure that ordered requests with the same address do not exist in the pipeline at the same time.

[0007] In an optional implementation, it further includes: After the non-order-preserving request has completed the main stream processing, it can be directly sent to the output request queue without waiting for the order permission signal.

[0008] In an optional implementation, it further includes: In the output request queue, a configurable arbitration module is used to select dequeueable requests for arbitration. The arbitration module supports a variety of configurable arbitration strategies. Arbitration strategies include at least one of the following: A fair arbitration strategy based on Least Recently Used (LRU); Load balancing strategy based on the number of incomplete requests from each source; Dynamic priority strategy based on historical completion delay information; It also includes a starvation prevention control mechanism: when a request from a certain source is not selected in multiple consecutive arbitration processes, a forced priority mechanism is triggered, where the starvation prevention threshold parameter is configurable.

[0009] In an optional implementation, it further includes: When a sequence dependency anomaly or data error is detected, subsequent requests from the relevant source are suspended. Send the error message to the corresponding source via the feedback path; Clear the relevant requests from the physical request queue or output request queue based on the error type; The request path will be reopened after the execution status is restored; The feedback path is a serial ring bus, and the error information includes at least one of the following: error code, error request address, error data, and CRC check value.

[0010] In an optional implementation, clearing related requests in the physical request queue or output request queue includes: selecting to clear specific requests or clearing all requests from the source of the error based on the error type.

[0011] In an optional implementation, sequential anomaly detection and recovery are controlled by a state machine, which includes an idle state, a waiting state, an error reporting state, and a recovery processing state. The state transitions are triggered by an error detection signal and a recovery completion signal.

[0012] In a second aspect, the present invention provides a sequence-keeping control device, comprising: Multiple physical request queues are used to receive and store requests from multiple sources according to address mapping rules. In response to the order permission signal, the target ordered request is sent to the output request queue; the requests include ordered requests and non-ordered requests. The sequence information queue module connects to multiple physical request queues and maintains a sequence record queue for each source. The sequence record queue records the sequence information of the order preservation request and the corresponding physical request queue identifier. Based on the sequence record status in the sequence record queue, it determines the target order preservation request that can be sent and the corresponding target physical request queue. It then sends a sequence permission signal to the target physical request queue. The output request queue, connected to multiple physical request queues, is used to temporarily store requests that have completed mainstream pipeline processing and meet the sending conditions.

[0013] In an optional implementation, each physical request queue is equipped with a dependency management unit, which manages the sequential dependencies between all requests in the queue through a dependency matrix. The rows and columns of the dependency matrix correspond to the request items in the queue, and the matrix elements represent the dependency status between the request items. The physical request queue is also used to select requests without unmet dependencies from the order-preserving requests as target order-preserving requests based on the dependency matrix.

[0014] In an optional implementation, the dependency management unit is further configured to update the dependency matrix after the target ordering request is sent into the output request queue. The update includes clearing the dependency markers of the selected request to other requests and adjusting the dependency relationships between requests at the same address to ensure that ordering requests at the same address do not exist in the pipeline at the same time.

[0015] In an optional implementation, the physical request queue is also used to directly send non-order-preserving requests that have completed mainstream pipeline processing into the output request queue without waiting for an order permission signal.

[0016] In an optional implementation, the output request queue is equipped with a configurable arbitration module for arbitrating dequeuable requests. The arbitration module supports multiple configurable arbitration strategies, including at least one of the following: a fair arbitration strategy based on the least recently used LRU, a load balancing strategy based on the number of incomplete requests from each source, and a dynamic priority strategy based on historical completion delay information. The arbitration module also includes an anti-starvation control unit, which triggers a forced priority mechanism when a request from a certain source is not selected in multiple consecutive arbitration processes. The anti-starvation threshold parameter is configurable.

[0017] In an optional implementation, an error handling controller is also included, connected to multiple physical request queues, output request queues, and various sources, for: When a sequence dependency anomaly or data error is detected, subsequent requests from the relevant source are suspended. Send the error message to the corresponding source via the feedback path; Clear the relevant requests from the physical request queue or output request queue based on the error type; The request path will be reopened after the execution status is restored.

[0018] In an optional implementation, the feedback path is a serial ring bus, and the error information includes at least one of error code, error request address, error data, and CRC check value.

[0019] In an optional implementation, the error handling controller selects to clear a specific request or clear all requests from the source of the error, depending on the error type.

[0020] In an optional implementation, the error handling controller is executed using a state machine, which includes an idle state, a waiting state, an error reporting state, and a recovery state. The state transitions are triggered by an error detection signal and a recovery completion signal.

[0021] Beneficial effects: 1. This invention constructs a multi-source sequence control mechanism suitable for multi-physical independent queue structures, which achieves order-preserving constraint control across physical independent queues without adding a dedicated order-preserving queue for each source end, avoiding increased storage resource consumption, while controlling the logic depth to meet performance requirements.

[0022] 2. This invention manages the dependencies between ordered and non-ordered requests through a unified dependency structure, thus solving the potential deadlock problem and improving stability.

[0023] 3. This invention improves efficiency and reliability by providing multiple scheduling and dequeueing strategies as well as anomaly detection and recovery mechanisms. Attached Figure Description

[0024] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 This is a block diagram of the multi-physical queue sequence control mechanism design according to an embodiment of the present invention; Figure 2 This is a connection structure diagram of the order info queue module according to an embodiment of the present invention; Figure 3This is a schematic diagram of the cyclic dependency relationship in the dependency matrix structure of this invention embodiment; Figure 4a This is a schematic diagram of the request queue dependency relationship according to an embodiment of the present invention; Figure 4b This is a schematic diagram of the dependency matrix structure according to an embodiment of the present invention; Figure 5a This is a schematic diagram illustrating the update of request queue dependencies according to an embodiment of the present invention; Figure 5b This is a schematic diagram of the dependency matrix structure update according to an embodiment of the present invention; Figure 6 This is a request queue state diagram after the dependency relationship is updated according to an embodiment of the present invention. Detailed Implementation

[0026] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0027] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0028] 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 invention pertains.

[0029] This embodiment provides a pre-order control method, which is applied to a multi-physical queue order control mechanism. It aims to solve the problem of how to achieve pre-order control across independent queues in a structure where multiple requests from multiple sources are allocated to multiple physical request queues according to address mapping rules.

[0030] The method includes: allocating requests from multiple sources to multiple physical request queues according to address mapping rules, the requests including ordered requests and non-ordered requests; maintaining a sequence record queue for each ordered request to record the order information of the ordered request and the corresponding physical request queue identifier; determining the target ordered request and the corresponding target physical request queue that can be sent based on the order record status in the sequence record queue; sending an order permission signal to the target physical request queue; and in response to the order permission signal, the target physical request queue sending the target ordered request to the output request queue.

[0031] Specifically, during operation, multiple request sending modules (sources) continuously issue read and write requests. To improve parallel processing capabilities and throughput, instead of serializing all requests, they are distributed across multiple physical request queues (pipe request queues) for parallel processing according to a preset address mapping rule. For example, the address mapping rule can use hashing of specific bits of the request address or direct truncation to evenly distribute requests across four or more physical request queues. Multiple order-keeping requests from the same source, due to their potentially different addresses, are highly likely to be assigned to different physical request queues. Without a unified coordination mechanism, each physical request queue is scheduled independently. Requests that enter the queue earlier may be sent later because requests that enter the queue later are processed faster, leading to severe out-of-order issues and violating the semantic requirements of strong consistency operations or device access.

[0032] To address the aforementioned issues, this embodiment introduces an order info queue module. This module does not store complete request data; instead, it acts as a lightweight global tracker, maintaining an independent order record queue for each request source. When a request source issues a pre-ordered request and writes it into the corresponding physical request queue, the order information corresponding to that request is simultaneously written into the order info queue module. This order information includes at least the global order information of the pre-ordered request (such as the request sequence number) and the identifier of the physical request queue into which the pre-ordered request currently falls (such as the queue number). In this way, the order info queue module understands the distribution and order of all pre-ordered requests from all sources.

[0033] The sequence information queue module continuously maintains status information related to each request source, including whether there are any pending order-keeping requests and the completion status of currently sent order-keeping requests. Based on these statuses, the sequence information queue module executes selection logic, determining the target order-keeping request to be sent only when the condition of "there is a pending order-keeping request and the preceding order-keeping request has been completed" is met. Because the sequence information queue module records the physical request queue identifier where the target order-keeping request resides, it can accurately send a sequence permission signal to that target physical request queue.

[0034] Upon receiving a sequence permission signal, the target physical request queue responds by sending the corresponding ordered request to the output request queue. It should be understood that multiple ordered requests may exist simultaneously in the physical request queue, but only the request that receives the sequence permission signal can be sent out. For non-ordered requests, since they do not have strict order constraints, they can directly enter the output request queue after completing the main pipeline processing, without waiting for a sequence permission signal, thus ensuring overall efficiency.

[0035] Through the above solution, this embodiment achieves order-keeping constraint control across physically independent queues without adding a dedicated, large-capacity order-keeping queue for each source end, by simply adding a small-scale sequential record queue structure. This design leverages the high parallelism of multiple physical queues while ensuring the strict order of order-keeping requests through a global coordination mechanism, avoiding increased storage resource consumption, and controlling the logic depth to meet performance requirements in high-concurrency scenarios.

[0036] like Figure 1 As shown, this embodiment provides a sequence-preserving control device for implementing sequence-preserving control across independent queues in a multi-physical queue structure. The device includes multiple physical request queues, a sequence information queue module, and an output request queue.

[0037] Specifically, multiple physical request queues are used to receive and store requests from multiple sources according to address mapping rules. Figure 1 In the architecture shown, multiple request sending modules, or sources, are displayed at the top. These sources can be processor cores, direct memory access controllers, or other master control devices. Each source sends requests, including ordered and non-ordered requests. To improve parallel processing capabilities, requests are allocated to different physical request queues according to preset address mapping rules. For example, four physical request queues can be set up, each running independently and capable of processing multiple requests simultaneously. This design fully utilizes hardware parallelism and avoids bottlenecks caused by a single queue.

[0038] The sequence information queue module connects to multiple physical request queues to maintain a sequence record queue for each source. This sequence record queue records the order information of the order-keeping requests issued by that source and the corresponding physical request queue identifier. Figure 1 In this architecture, the sequence information queue module is located to the lower right of the source and communicates with each source and physical request queue via internal connections. When a source issues a pre-order request, the sequence information queue module synchronously records the order information of the request, including its position in the global sequence and the physical request queue number to which it is assigned. Based on the order record status in the order record queue, the sequence information queue module determines the currently sendable target pre-order request and its corresponding target physical request queue. Once determined, the module sends a sequence permission signal to the target physical request queue. This mechanism ensures that even if pre-order requests from the same source are distributed across different physical queues, they can still be processed and sent in the original order they were issued.

[0039] The output request queue connects to multiple physical request queues to temporarily store requests that have completed mainstream pipeline processing and meet the sending conditions. Figure 1In this structure, the output request queue is located to the right of the output arbitrator module, serving as the final buffer before transmission. After the main stream processing is completed, requests in the physical request queue can directly enter the output request queue if they are non-order-preserving requests; otherwise, they must wait for the order clearance signal from the order information queue module before being sent to the output request queue. The output request queue only serves as a transmission buffer and does not handle source order control; its design focuses on efficiently passing requests to subsequent network or storage interfaces.

[0040] Specifically, such as Figure 1 As shown, each circle in the source box represents a sending module of multiple requests.

[0041] There are four physical request queues (pipe request queues) representing read and write requests from different senders. Based on the request address, requests are entered into different pipe request queues for parallel processing. Each pipe request queue can store both ordered and unordered requests. Requests from the same source may enter different pipe request queues.

[0042] The output arbiter module represents the arbiter module that sends the request.

[0043] The output request queue stores requests that have been processed in the pipeline and can store both ordered and unordered requests. The output request queue only serves as a sending buffer and does not handle source order control.

[0044] The order info queue is used to record the global order information of ordered requests sent by different sending modules, as well as information about which pipe request queue the request falls into. Non-ordered requests are not stored in the order info queue.

[0045] The arrowed connection between the output arbiter and the source represents the error feedback path, currently implemented as a serial ring bus. It operates in only one direction, used in the error correction mechanism where the output arbiter module sends error request information to the corresponding source to achieve error correction.

[0046] The error handle controller module is used to implement error reporting and correction functions. It is responsible for controlling the transmission of error information on the ring bus, controlling the error correction handshake signal, and flushing error source requests in the pipe request queue and output request queue.

[0047] After non-order-preserving requests in the pipe request queue are processed in the main stream, they can be sent directly to the output request queue if there is space available. However, after order-preserving requests in the pipe request queue are processed in the main stream, they need to wait for the order info queue to retrieve the pipe request queue number of the next available request, send the corresponding signal to the corresponding pipe request queue, and then the pipe request queue will send the corresponding request to the output request queue.

[0048] Data flow direction: Non-order-preserving requests → main stream complete → can directly enter the output request queue.

[0049] Order preservation request → main stream complete → order info queue needs to ensure order permission → only then can it enter the output request queue.

[0050] A sequence dependency record structure is set in the pipe request queue to identify the sequential dependencies between requests. This can be implemented as a dependency register matrix, which, together with the order info queue, ensures that ordered requests are sent in the correct order.

[0051] The output request queue module implements a multi_mode_scheduler, which provides three software-configurable dequeue logics. Additionally, the module includes a starvation prevention counter function, whose parameters are also software-configurable.

[0052] Through the collaborative work of the aforementioned modules, the device in this embodiment achieves cross-queue order preservation control in a multi-physical independent queue structure. Requests issued by the source are efficiently allocated and processed in parallel, while the sequence information queue module, acting as a global coordinator, ensures the strict order of the order-preserving requests. This design retains the high throughput advantage of multiple queues while solving the cross-queue out-of-order problem through a lightweight sequence recording mechanism, avoiding the resource waste caused by adding an independent, large-capacity order-preserving queue for each source.

[0053] like Figure 2 As shown, the `order info queue` module is specifically used to implement request ordering control for each source. This module maintains a corresponding order record queue for each request source, used to record the global order information of the order-keeping requests generated by that source. Each order record entry contains at least the identifier information of the physical pipe request queue where the corresponding order-keeping request resides.

[0054] When a request source issues a pipe request and writes it into the corresponding pipe request queue, the order information corresponding to the pipe request is synchronously written into the order info queue module to ensure that the recorded order information is consistent with the actual order in which requests enter the physical queue.

[0055] The order info queue module maintains status information related to each request source, including whether there are any pending ordering requests and the completion status of currently sent ordering requests. The selection logic, based on this status information, sends an order permission signal to the corresponding pipe request queue only when the condition of "there are pending ordering requests and the preceding ordering request has been completed" is met.

[0056] After obtaining the order permission, the corresponding pipe request queue selects the specific order-preserving request based on its internal order dependencies and sends it to the output request queue.

[0057] Once the order preservation request is completed, the pipe request queue sends a completion message to the order info queue module. The order info queue module then advances the sequence record pointer of the corresponding source and updates the completion status, thereby allowing subsequent order preservation requests from that source to continue to be granted permission to be issued.

[0058] Based on the aforementioned method and apparatus, this embodiment further elaborates on the specific implementation of managing the sequential dependencies between all requests within each physical request queue through a dependency matrix.

[0059] Specifically, in scenarios where multiple physical queues process requests in parallel, each physical request queue may simultaneously contain ordered and unordered requests from different sources. To precisely control the sending order of these requests, this embodiment sets up a dependency management unit within each physical request queue, which maintains a dependency matrix. The rows and columns of the dependency matrix correspond to the request items in the queue, and the matrix elements represent the dependency state between request items. For example, assuming there are N requests in the queue, an N×N matrix is ​​constructed, where the element E(i,j) is used to indicate whether the i-th queue item depends on the j-th queue item. When E(i,j) is in a valid state (e.g., logic 1), it means that the i-th request needs to wait for the j-th request to complete before it can be sent; when E(i,j) is in an invalid state (e.g., logic 0), it means that there is no dependency relationship.

[0060] The target physical request queue selects requests with no unmet dependencies from the ordered requests based on the dependency matrix. This selection process is as follows: When the sequence information queue module sends an order permission signal to a physical request queue, indicating that the queue can send ordered requests from a certain source, the physical request queue searches the dependency matrix within the set of ordered requests corresponding to that source. Specifically, the search logic involves scanning the rows corresponding to the relevant requests from that source in the matrix. If all column elements of a row (e.g., row i) are invalid (i.e., all are 0), it indicates that the i-th request does not depend on any other incomplete requests in the queue; that is, the request has no unmet dependencies and can be selected as the target ordered request for transmission.

[0061] To more intuitively understand the role of the dependency matrix, we will now combine... Figures 3 to 6 Please provide an explanation. Figure 3 This illustrates a scenario that could lead to deadlock. In this scenario, if only the traditional "same address conflict dependency" logic is used—that is, a later-entering request with the same address depends on a previously entered request with the same address—then, under complex cross-queue interactions, requests may form circular dependencies. For example, request A depends on request B, request B depends on request C, and request C, in turn, depends on request A, forming a closed loop. In this state, all requests are waiting for other requests to complete, resulting in no request being selected for transmission and leading to a deadlock.

[0062] Figure 3The square boxes represent the contents of two pipe request queues. nm_req indicates that this is a non-ordered request. dev indicates that this is an ordered request, and dev_C1_(0)_a indicates that this is the 0th ordered request from source1 with address a. If we only follow the traditional approach where subsequent requests in the same queue depend on previous requests with the same address, a looping dependency chain will appear as shown in the figure. In this case, none of the four ordered requests can be sent.

[0063] To address the aforementioned issues and achieve unified management of dependencies between ordered and non-ordered requests, this design employs a dependency matrix structure to uniformly handle request dependencies within the pipe request queue.

[0064] This embodiment effectively identifies and breaks such cyclic dependencies through a unified management mechanism for dependency matrices. Figure 4a as well as Figure 4b This demonstrates a typical dependency chain structure. Figure 4a The request queue contains multiple request items. Figure 4b The dependency matrix clearly shows the unidirectional dependencies between requests (e.g., a 1 in row 1, column 0 indicates that request 1 depends on request 0). With this structure, it's possible to easily find request items with all rows of 0 (the positions highlighted by the thick black line in the figure) and send them out.

[0065] After the target order-keeping request is sent to the output request queue, the process also includes updating the dependency matrix. Updating the dependency matrix includes: clearing the dependency markers of the selected request on other requests, and adjusting the dependencies between requests at the same address to ensure that order-keeping requests at the same address do not exist simultaneously in the pipeline.

[0066] Specifically, once the i-th request is selected and sent, the dependency management unit performs an update operation. First, it clears the dependency markers of the selected request on other requests. This typically means invalidating all elements in the i-th column of the dependency matrix (because the i-th request is about to complete or has already been sent, and other requests no longer need to wait for it). Second, it adjusts the dependencies between requests with the same address. This is to prevent multiple order-keeping requests with the same address from coexisting in the network, which could lead to potential out-of-order processing risks. The update rules check for subsequent requests with the same address as the selected request and re-establish or adjust the dependencies between these subsequent requests and other requests, ensuring that order-keeping requests with the same address are processed serially.

[0067] Figure 5a , Figure 5b and Figure 6 This demonstrates the effect of updating the dependency matrix. Figure 5a The request queue contains multiple request items. Figure 5b The dependency matrix clearly shows the unidirectional dependencies between requests (e.g., a value of 1 in row 1, column 0 indicates that request 1 depends on request 0). Through the update rules described above, complex dependencies that could have led to deadlocks are restructured into a linear, acyclic dependency structure. For example... Figure 5a , Figure 5b and Figure 6 As shown, the updated dependencies break the original loop, allowing requests to flow out sequentially according to their dependencies, thus avoiding deadlock. This embodiment, through this dynamically updated dependency matrix mechanism, not only achieves unified management of dependencies between ordered and non-ordered requests, but also fundamentally solves the deadlock problem caused by traditional dependency chains, significantly improving stability and reliability.

[0068] This embodiment, based on the methods and apparatus of the foregoing embodiments, further elaborates on the processing flow of non-order-preserving requests and the configurable arbitration strategy in the output request queue.

[0069] Specifically, in the multi-physical queue order control mechanism, requests are explicitly distinguished into ordered requests and non-ordered requests. For non-ordered requests, a fast processing path is designed to maximize throughput efficiency. After completing mainstream pipeline processing, non-ordered requests are directly sent to the output request queue without waiting for an order permission signal. This means that once a non-ordered request has completed the necessary preprocessing (such as address decoding and cache consistency checks) in the physical request queue, it can be immediately transferred from the physical request queue to the output request queue as long as there is free storage space. This design avoids the additional latency caused by non-ordered requests waiting for global coordination from the order information queue module, significantly reducing the processing latency of non-ordered requests and improving overall data processing capacity and response speed.

[0070] In the output request queue, a configurable arbitration module selects which requests can be dequeued for arbitration. This module supports multiple configurable arbitration strategies. Located within the output arbitrator module, this module (multi_mode_scheduler) is responsible for selecting the final request sent to the downstream network or storage interface from multiple candidate requests in the output request queue. To adapt to different architectures and performance requirements, this embodiment provides flexible arbitration strategy configuration options.

[0071] Arbitration strategies include at least one of the following: a fair arbitration strategy based on Least Recently Used (LRU); a load balancing strategy based on the number of incomplete requests from each source; and a dynamic priority strategy based on historical completion delay information. Specifically, the fair arbitration strategy based on Least Recently Used (LRU) is suitable for scenarios with a single dequeue port. This strategy records the time when each source request was last selected and prioritizes the source request with the longest waiting time, thus ensuring a fair service opportunity for each source and preventing one source from monopolizing bandwidth for an extended period. The load balancing strategy based on the number of incomplete requests from each source is suitable for scenarios with multiple dequeue ports. This strategy continuously monitors the number of incomplete requests currently backed up in the queue for each source and prioritizes scheduling requests from sources with larger backlogs to balance the load across sources and prevent some sources from overflowing their queues while others remain idle. The dynamic priority strategy based on historical completion delay information is suitable for scenarios where there are slow endpoint devices in the downstream network. This strategy monitors the historical latency from request issuance to completion and dynamically adjusts priorities, giving higher priority to paths with higher latency to optimize overall end-to-end latency performance.

[0072] In addition, the arbitration module includes an anti-starvation control mechanism: when a request from a certain source is not selected in multiple consecutive arbitration processes, a forced priority mechanism is triggered, where the anti-starvation threshold parameter is configurable. Specifically, the arbitration module maintains a waiting counter for each request source. In each arbitration cycle, if a request from a certain source is not selected, its corresponding counter is incremented; if it is selected, the counter is reset to zero. When the counter value of any source reaches the preset anti-starvation threshold (this threshold can be configured via software, for example, set to 8 or 16 times), the anti-starvation control mechanism immediately takes effect, forcing the arbitration module to prioritize the request from that source in the next arbitration cycle, regardless of whether the current arbitration strategy is LRU or load balancing. This mechanism effectively prevents the phenomenon of other low-priority sources' requests "starving" due to prolonged lack of scheduling under specific traffic patterns (such as a certain source continuously sending high-priority requests), ensuring robustness and fairness.

[0073] This embodiment, based on the methods and apparatus of the foregoing embodiments, further elaborates on the specific implementation of the sequence anomaly detection and recovery mechanism. In complex on-chip networks or multi-core processors, although mechanisms such as dependency matrices can avoid logical deadlocks, sequence dependency anomalies or data errors may still occur due to hardware failures, soft errors, or extreme timing violations. To improve robustness, this embodiment introduces an error handling controller.

[0074] Specifically, the error handling controller connects to multiple physical request queues, output request queues, and each request source. When a sequence dependency anomaly or data error is detected, the error handling controller first suspends subsequent request sending from the relevant source. This step is crucial as it prevents the error from spreading, stops new requests from entering the already disrupted pipeline, and thus limits the impact of the failure to a localized scope.

[0075] After pausing transmission, the error handling controller sends error information to the corresponding source via the feedback path. In this embodiment, the feedback path is a serial ring bus. The advantage of using a serial ring bus is that it saves wiring resources and can cover all request source modules connected to the bus. The error information includes at least one of the following: error code, error request address, error data, and CRC checksum. Specifically, the error code is used to identify the type of error, such as a sequence dependency violation, data validation error, or timeout error; the error request address helps locate the storage location or device where the error occurred; the error data records the specific data content at the time of the error, facilitating debugging and analysis; and the CRC checksum is used to ensure the integrity of the error information packet during transmission and prevent false alarms introduced by the feedback channel itself. After receiving the error packet containing the above information, the request source can perform targeted logging or upper-layer software intervention.

[0076] Next, the error handling controller clears the relevant requests from the physical request queue or output request queue based on the error type. This embodiment provides a flexible clearing strategy. For minor, isolated errors, such as a single request's data validation failure, a specific request can be cleared, removing only the erroneous request from the queue while retaining other normal requests from the same source. This approach minimizes the impact on normal business flow. For severe errors that may lead to state inconsistencies, such as detecting an unresolved sequential dependency deadlock or a severe hardware failure signal, all requests from the source of the error are cleared. This means that all pending requests corresponding to that source, whether in the physical request queue or the output request queue, will be flushed away. While this "reset-style" clearing strategy sacrifices some performance, it ensures that the state returns to a deterministic, known initial state, preventing residual dirty requests from triggering a chain reaction.

[0077] After the cleanup operation is completed, state restoration is performed and the request path is reopened. The entire process of sequential anomaly detection and recovery is controlled by a state machine to ensure the rigor and traceability of the process. The state machine includes an idle state, a waiting state, an error reporting state, and a recovery state. The specific workflow is as follows: During normal operation, the state machine is in an idle state, monitoring signals from each module in real time. Once an error detection signal is triggered, the state machine immediately transitions to a waiting state. In the waiting state, the error handling controller locks the error context and suspends request transmission from the relevant source. Subsequently, the state machine enters an error reporting state, where the controller sends the encapsulated error information to the corresponding request source via the serial ring bus and waits for confirmation or a handshake signal from the source. After completing error reporting and performing the queue clearing operation described above, the state machine transitions to a recovery state. In the recovery state, relevant pointers, counters, or status registers are reset, such as resetting the record pointer in the sequential information queue module to match the cleared queue state. When the recovery completion signal is triggered, indicating that the internal state is consistent and capable of receiving new requests, the state machine transitions back to the idle state, reopening the request path and allowing the source to resend the request.

[0078] Through the anomaly detection and recovery mechanism controlled by the state machine described above, this embodiment can orderly isolate, report and recover when a serious error occurs, avoiding crashes or deadlocks, and significantly improving the reliability and maintainability of the multi-physical queue sequence control mechanism.

[0079] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and there may be other division methods in actual implementation. Furthermore, multiple units or components may be combined or integrated into another, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be through some communication interface; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0080] Furthermore, the units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0081] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0082] It should be noted that if a function is implemented as a software module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, 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 steps 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, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0083] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0084] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A sequence-preserving control method, characterized in that, include: Requests from multiple sources are distributed to multiple physical request queues according to address mapping rules. The requests from multiple sources include ordered requests and non-ordered requests. A sequence record queue is maintained for each order preservation request to record the order information of the request and the corresponding physical request queue identifier; based on the order record status in the sequence record queue, the target order preservation request that can be sent and the corresponding target physical request queue are determined; and an order permission signal is sent to the target physical request queue. In response to the sequence permission signal, the target physical request queue sends the target order-keeping request to the output request queue.

2. The method according to claim 1, characterized in that, Also includes: Within each physical request queue, a dependency matrix is ​​used to manage the sequential dependencies between all requests in that queue. The rows and columns of the dependency matrix correspond to the request items in the queue, and the matrix elements represent the dependency state between the request items. The target physical request queue selects requests with no unmet dependencies from the order-preserving requests based on the dependency matrix as the target order-preserving requests.

3. The method according to claim 2, characterized in that, After sending the target order-preserving request to the output request queue, the method further includes: updating the dependency matrix; The update dependency matrix includes: clearing the dependency markers of selected requests on other requests, and adjusting the dependency relationships between requests with the same address to ensure that order-preserving requests with the same address do not exist in the pipeline at the same time.

4. The method according to claim 1, characterized in that, Also includes: After the non-order-preserving request has completed the main stream processing, it can be directly sent to the output request queue without waiting for the order permission signal.

5. The method according to claim 1, characterized in that, Also includes: In the output request queue, a configurable arbitration module is used to select dequeueable requests for arbitration. The arbitration module supports a variety of configurable arbitration strategies. The arbitration strategy includes at least one of the following: A fair arbitration strategy based on Least Recently Used (LRU); Load balancing strategy based on the number of incomplete requests from each source; Dynamic priority strategy based on historical completion delay information; It also includes a starvation prevention control mechanism: when a request from a certain source is not selected in multiple consecutive arbitration processes, a forced priority mechanism is triggered, where the starvation prevention threshold parameter is configurable.

6. The method according to claim 1, characterized in that, Also includes: When a sequence dependency anomaly or data error is detected, subsequent requests from the relevant source are suspended. Send the error message to the corresponding source via the feedback path; Clear the relevant requests from the physical request queue or output request queue based on the error type; The request path will be reopened after the execution status is restored; The feedback path is a serial ring bus, and the error information includes at least one of error code, error request address, error data, and CRC check value.

7. The method according to claim 6, characterized in that, The process of clearing related requests in the physical request queue or output request queue includes: selecting to clear specific requests or clearing all requests from the source of the error based on the error type.

8. The method according to claim 6, characterized in that, Sequential anomaly detection and recovery are controlled by a state machine, which includes an idle state, a waiting state, an error reporting state, and a recovery processing state. State transitions are triggered by error detection signals and recovery completion signals.

9. A sequence-preserving control device, characterized in that, include: Multiple physical request queues are used to receive and store requests from multiple sources according to address mapping rules, and in response to the order permission signal, send the target ordering request to the output request queue. The requests from multiple sources include order-preserving requests and non-order-preserving requests; The sequence information queue module, connected to multiple physical request queues, is used to maintain a sequence record queue for each source. The sequence record queue is used to record the sequence information of the order preservation request and the corresponding physical request queue identifier. Based on the sequence record status in the sequence record queue, the module determines the target order preservation request that can be sent and the corresponding target physical request queue. The module then sends a sequence permission signal to the target physical request queue. An output request queue, connected to multiple physical request queues, is used to temporarily store requests that have completed mainstream processing and meet the sending conditions.

10. The apparatus according to claim 9, characterized in that, Each physical request queue has a dependency management unit, which manages the sequential dependencies between all requests in the queue through a dependency matrix. The rows and columns of the dependency matrix correspond to the request items in the queue, and the matrix elements represent the dependency status between the request items. The physical request queue is also used to select requests with no unmet dependencies from the order-preserving requests according to the dependency matrix as the target order-preserving requests.

Images