A method, device, module and system for counting statistics of round-trip time of a request

Abstract

The application discloses a kind of requested round trip delay timing statistics method, device, module and system, it is related to system on chip and request scheduling technical field, this method includes: obtaining target request and determining the physical path encoding of target physical path according to its carried route mark information, generates delay statistics mark and fills to the user-defined field of bus request address channel, without relying on local large storage table to perform table lookup operation, the association of request and corresponding physical path, response can be realized, while sending target request signal, start round trip delay timing, when forwarding request signal and response signal, keep the physical path encoding and delay statistics mark in user-defined field unchanged, determine corresponding response by detecting the delay statistics mark and physical path encoding simultaneously existing in response signal and stop timing, obtain the accurate single actual delay value of target physical path, improve the efficiency and accuracy of delay statistics.

Description

Technical Field

[0001] This invention relates to the fields of system-on-a-chip and request scheduling technology, and in particular to a statistical method, apparatus, module and system for calculating the round-trip delay of requests. Background Technology

[0002] In a system-on-chip (SOC) architecture, various functional modules generally rely on a network-on-chip (Noc) to achieve cross-module data interaction. Peripheral interface modules, DMA (Direct Memory Access) modules, etc., can send read and write requests to computing modules and storage control modules and receive response data via the network-on-chip.

[0003] The various functional modules within the system often employ asynchronous clock designs, with different operating frequencies. For example, the PCIe (Peripheral Component Interconnect Express) interface module is limited by its maximum operating frequency due to constraints on interface standards, manufacturing processes, and bandwidth matching. On-chip networks, on the other hand, need to simultaneously support the data interaction requirements of multiple high-speed modules such as GPUs (Graphics Processing Units) and high-bandwidth storage units, and are typically designed to operate at higher frequencies. Furthermore, various modules can flexibly operate at different frequency points below the maximum rated frequency, depending on the application scenario, performance requirements, and power consumption constraints.

[0004] When a low-frequency PCIe interface module sends a request to a high-frequency on-chip network as the request initiator, the response data will be transmitted back along the original path. Due to the limited operating frequency and processing capacity of the request initiator, it is difficult to process the returned response data in a timely manner, which can easily cause the response data to accumulate in the local buffer, thereby generating back pressure and transmitting it back to the on-chip network and upstream modules, affecting the overall data transmission efficiency.

[0005] Traditional methods for addressing on-chip network request transmission and congestion control often rely on large local storage tables for lookup operations. This involves storing a large amount of request identifiers and path information to match requests and responses. This not only consumes excessive system hardware resources but also reduces matching efficiency due to lookup delays. It is difficult to accurately associate requests with their corresponding physical paths and responses, and it is prone to confusion in latency statistics for different paths and requests. This can lead to problems such as incorrect or missed timing, and it is impossible to accurately obtain the actual latency value of each physical path. This makes it difficult to match the response processing capacity with the request sending rate, ultimately causing problems such as response backlog, backpressure propagation, on-chip network congestion, and increased latency. These issues seriously affect the stability of on-chip system request transmission and overall operating efficiency. Summary of the Invention

[0006] This invention provides a statistical method, apparatus, module, and system for calculating the round-trip delay of requests, in order to solve the problems of high system hardware resource utilization, low efficiency and accuracy of delay statistics, and low stability and overall operating efficiency of on-chip system request transmission caused by the need for local table lookup operations to achieve correlation matching in request control.

[0007] According to one aspect of the present invention, a statistical method for calculating the round-trip delay of a request is provided, executed by a request initiation module in a system-on-a-chip, the system-on-a-chip including a request initiation module, at least one level of request transmission module, and a request response module, the method comprising:

[0008] The system obtains the target request for which round-trip delay timing is to be performed, and obtains the physical path code of the target physical path that matches the target request based on the routing flag information carried in the target request; wherein, the physical path is the path that the request takes from being sent to the request response module via the request transmission module to being returned to the request initiating module via the request transmission module.

[0009] Generate a delay statistics flag that matches the target request, and fill the user-defined field of the bus request address channel with the physical path code of the target request and the delay statistics flag according to the preset bit format to obtain the target request signal;

[0010] Simultaneously with sending the target request signal from the request initiation module, start the round-trip delay timer for the target request;

[0011] In the process of forwarding the request signal through the request transmission module, the physical path code and delay statistics flag in the user-defined field remain unchanged. The request response module extracts the physical path code and delay statistics flag from the user-defined field in the received forwarded signal and fills them back into the user-defined field of the bus response channel to generate a response signal carrying the physical path code and delay statistics flag and transmits it back.

[0012] If the current delay statistics flag and the current physical path code are extracted from the received current response signal, and it is determined that the current response signal is a response to the target request, then the round-trip delay timer for the target request is stopped, and a single actual delay value of the target physical path matching the target request is obtained.

[0013] The physical path encoding and delay statistics flags in the user-defined fields of the bus response channel remain unchanged during the forwarding of the response signal through the request transmission module.

[0014] According to another aspect of the present invention, a statistical device for calculating the round-trip delay of a request is provided, configured in a request initiation module of a system-on-a-chip. The system-on-a-chip includes a request initiation module, at least one level of request transmission module, and a request response module. The device includes:

[0015] The request acquisition module is used to acquire the target request to be timed for round-trip delay, and to acquire the physical path code of the target physical path matching the target request based on the routing flag information carried by the target request; wherein, the physical path is the path that the request takes from being sent to the request response module via the request transmission module to being returned to the request initiation module via the request transmission module.

[0016] The request signal module generates a delay statistics flag that matches the target request, and fills the physical path code of the target request and the delay statistics flag into the user-defined field of the bus request address channel according to a preset bit format to obtain the target request signal.

[0017] The delay timing module is used to start round-trip delay timing for the target request at the same time as the target request signal is sent from the request initiation module. During the forwarding of the request signal through the request transmission module, the physical path code and delay statistics flag in the user-defined field remain unchanged. The request response module extracts the physical path code and delay statistics flag from the user-defined field in the received forwarded signal and fills it back into the user-defined field of the bus response channel to generate a response signal carrying the physical path code and delay statistics flag and transmits it back.

[0018] The stop timing module is used to stop the round-trip delay timing for the target request if the current response signal is determined to be a response to the target request based on the current delay statistics flag and the current physical path code extracted from the received current response signal. This allows for obtaining a single actual delay value for the target physical path that matches the target request. The physical path code and delay statistics flag in the user-defined fields of the bus response channel remain unchanged during the forwarding of the response signal through the request transmission module.

[0019] According to another aspect of the present invention, a request initiation module is provided, including request injection control hardware, which is used to perform a statistical method for round-trip delay timing of requests as described in any embodiment of the present invention.

[0020] According to another aspect of the present invention, a system-on-a-chip is provided, including a request initiation module, at least one level request transmission module, and a request response module as described in any embodiment of the present invention.

[0021] The technical solution of this invention obtains the target request through a request initiation module and determines the physical path code of the target physical path based on the routing flag information it carries. It then generates a delay statistics flag and fills it into a user-defined field in the bus request address channel. This eliminates the need for lookup operations in a large local storage table. By embedding the physical path code and delay statistics flag into the bus user-defined field, it achieves precise association between the request and its corresponding physical path and response, avoiding confusion in delay statistics for different paths and requests. The round-trip delay timer is started simultaneously with the sending of the target request signal, ensuring synchronization between the timing start and request transmission and guaranteeing initial timing accuracy. When forwarding request and response signals, the physical path code and delay in the user-defined field are strictly maintained. By keeping the statistical flags unchanged, the loss or corruption of flags during transmission can be effectively avoided. Furthermore, the correspondence between requests and responses can be maintained without additional table lookups. By detecting the delay statistics flags and physical path codes present in the response signal, the corresponding response is determined and the timing is stopped. This allows for accurate differentiation between the response corresponding to the target request and other responses, avoiding accidental or missed timing stops. Consequently, the accurate single-transaction actual delay value of the target physical path can be obtained quickly. This reduces the occupation of large local storage and the consumption of system hardware resources, while improving the efficiency and accuracy of delay statistics. It provides reliable data support for subsequent physical path congestion judgment and request injection control, ultimately improving the stability of on-chip system request transmission and optimizing the overall system operating efficiency and resource utilization.

[0022] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0024] Figure 1 This is a flowchart of a statistical method for calculating the round-trip delay time of a request, provided in Embodiment 1 of the present invention;

[0025] Figure 2 This is a flowchart of another statistical method for calculating the round-trip delay time of a request, provided according to Embodiment 2 of the present invention;

[0026] Figure 3 This is a flowchart of a statistical method for calculating the round-trip delay time of a request, provided in Embodiment 3 of the present invention;

[0027] Figure 4 This is a schematic diagram of the structure of a statistical device for calculating the round-trip delay time according to Embodiment 4 of the present invention;

[0028] Figure 5 This is a schematic diagram of the structure of a request initiation module according to Embodiment 5 of the present invention;

[0029] Figure 6 This is a schematic diagram of a system-on-a-chip provided in Embodiment Six of the present invention;

[0030] Figure 7 This is a schematic diagram illustrating the format of the physical path encoding and delay statistics flags defined for each channel, applicable to an embodiment of the present invention.

[0031] Figure 8 This is a schematic diagram illustrating the generation of physical path codes and delay statistics flags by the sending module in the first-level module, applicable to an embodiment of the present invention.

[0032] Figure 9 This is a schematic diagram illustrating another method applicable to embodiments of the present invention, in which the sending module generates physical path codes and delay statistics flags in the first-level module;

[0033] Figure 10 This is a schematic diagram illustrating how the signal from the input write address channel is converted into a write response channel signal in the nth-level module, according to an embodiment of the present invention.

[0034] Figure 11 This is a schematic diagram illustrating how the signal from the input read address channel is converted into a read response channel signal in the nth-level module, according to an embodiment of the present invention.

[0035] Figure 12 This is a schematic diagram illustrating the recovery of physical path information and delay statistics in a first-level module, applicable to an embodiment of the present invention.

[0036] Figure 13 This is a schematic diagram illustrating another method for recovering physical path information and delay statistics in a first-level module, applicable to embodiments of the present invention.

[0037] Figure 14 This is a schematic diagram illustrating the process of transmitting information from various related channels using a three-level module, applicable to an embodiment of the present invention. Detailed Implementation

[0038] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0039] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0040] Example 1

[0041] Figure 1 This is a flowchart illustrating a statistical method for calculating the round-trip delay time of a request, provided in Embodiment 1 of the present invention. This embodiment is applicable to on-chip system request scheduling. The method can be executed by a statistical device for calculating the round-trip delay time of a request. This statistical device can be implemented in hardware and / or software and is generally configured within the request initiation module of the on-chip system. The on-chip system includes a request initiation module, at least one level of request transmission module, and a request response module.

[0042] In this embodiment of the invention, the system-on-a-chip (SoC) can be specifically understood as an integrated chip system that integrates multiple functional modules such as peripheral interfaces, network interconnection, storage control, and computing units into a single chip, providing a unified on-chip data interaction and hardware operation platform for various modules. The request initiation module can be specifically understood as a functional module in the SoC that acts as the request source, used to send read / write and other business requests externally, and serves as the carrier for request generation and initial management.

[0043] The request transmission module can be understood as an intermediate interconnection module in the on-chip system that handles the relay and routing of request and response data, establishing a data path between the request initiation module and the request response module. The request response module can be understood as a terminal function module in the on-chip system that receives and processes external requests and generates corresponding response data; it is primarily a storage control or computation processing module.

[0044] like Figure 1 As shown, the method includes:

[0045] S110. Obtain the target request to be timed for round-trip delay, and obtain the physical path code of the target physical path that matches the target request based on the routing flag information carried in the target request.

[0046] The physical path is the path that the request takes from being sent from the request transmission module to the request response module, and from the request response module returning the response to the request to the request initiating module via the request transmission module.

[0047] In this embodiment of the invention, the target request can be specifically understood as: business read / write requests selected by the on-chip system that require statistical analysis of the round-trip time from sending to receiving a response. The routing identifier information can be specifically understood as: identifier-type information carried within the request message itself, used to identify the forwarding destination and home path, which may include the destination address, target device identifier, etc.

[0048] The target physical path can be understood as the complete, fixed transmission path through which the target request originates from the request initiation module, passes through the request transmission module, reaches the request response module, and the response data is transmitted back to the request initiation module along the same path. The physical path encoding can be understood as a unique index assigned to each physical path, used to identify, address, and retrieve the parameter data corresponding to that path.

[0049] Specifically, the request initiation module filters and determines the target requests that require round-trip delay timing operations. It reads the routing flag information carried within the target request message and, based on the system's preset association rules, matches the routing flag information to determine the complete round-trip transmission link corresponding to the request. Then, it obtains the physical path code corresponding to this transmission link, completing the precise pairing of the request and the link code. For example, this can be achieved by dividing device ranges based on the destination address and mapping codes. Alternatively, other matching methods can be used, such as port number binding or direct link binding of device identifiers, to lock the transmission link. This determines the complete physical path from the request initiation module through various request transmission modules to the request response module, and then from the request response module generating a response signal that is transmitted back to the request initiation module along the original transmission path. Finally, the physical path code corresponding to this round-trip transmission path is determined.

[0050] S120. Generate a delay statistics flag that matches the target request, and fill the physical path code of the target request and the delay statistics flag into the user-defined field of the bus request address channel according to the preset bit format to obtain the target request signal.

[0051] In this embodiment of the invention, the delay statistics flag can be specifically understood as: a flag bit that marks whether the current request participates in round-trip delay sampling, for example, it can be denoted as S_Flag, and timing and stop timing processing is only performed when the flag is valid. The bus request address channel can be specifically understood as: an address transmission channel in the bus used to initiate read and write requests, which may include AW (Write Address Channel) and AR (Read Address Channel).

[0052] User-defined fields can be understood as: custom bit regions reserved in the bus protocol, used to carry physical path encoding and delay statistics flags, and do not occupy standard service addresses and data bits. For example, they can correspond to the AXI (Advanced eXtensible Interface) bus RUSER (Read data channel User signal) and BUSER (Write response channel User signal) signals.

[0053] Optionally, based on the above embodiments, the physical path encoding and delay statistics flag of the target request are filled into the user-defined field of the bus request address channel according to a preset bit format to obtain the target request signal, which may include:

[0054] Divide the user-defined fields of the write address channel or read address channel into a preset bit region; wherein the preset bit region includes a first region and a second region;

[0055] Write the physical path encoding of the target request into the first area and write the delay statistics flag of the target request into the second area to obtain the target request signal;

[0056] When forwarding the request signal, the request transmission module keeps the bit values ​​of the physical path code in the first region and the delay statistics flag in the second region unchanged, and sends the signal to the subsequent modules.

[0057] In this embodiment of the invention, the preset bit region can be specifically understood as: a fixed bit segment pre-defined within the user-defined field, divided into a first region and a second region, each dedicated to storing different information. The first region can be specifically understood as: a fixed bit segment allocated to the physical path encoding in the user-defined field. The second region can be specifically understood as: a fixed bit segment allocated to the delay statistics flag in the user-defined field. Here, "first" and "second" are only used to distinguish different regions and have no meaning regarding order or priority.

[0058] Specifically, in the request sending module, a preset bit area is divided in the user-defined field of the write address channel or the read address channel. For example, fixed dedicated bits are set in the AWUSER signal (Write Address User) of the AXI write address channel and the ARUSER signal of the read address channel to store the codes NEW_A and NEW_B mapped by the physical path and delay statistics flag.

[0059] When the target request is a write request, the NEW_A and NEW_B values ​​mapped to the corresponding physical path and delay statistics flags are assigned to the specified bits of the write request signal and sent along with the write address channel message. When the target request is a read request, the NEW_A and NEW_B values ​​are assigned to the specified bits of the read request signal and sent along with the read address channel message. The encapsulation of the target request signal is completed by dividing the address channel into a first region and a second region to record the physical path code and delay statistics flag respectively.

[0060] When forwarding read / write request signals, the request transmission module keeps the bit values ​​of the physical path encoding and delay statistics flag recorded inside the request signal unchanged, thereby enabling the transparent transmission of custom field information.

[0061] In addition to the implementation method of using fixed bit allocation for each signal of the read and write address channels, the same signal can be dynamically time-division multiplexed with bits, and reserved check bits can be added to improve transmission reliability. It can also support the segmented extension bit allocation of multiple physical path codes and multiple statistical flags without modifying the standard bus architecture and protocol definition. It only uses the existing user extension signals for information recording, is compatible with the standard bus interface, and realizes that path codes and delay statistical flags are naturally bound with request messages and transparently transmitted throughout the process.

[0062] By pre-dividing independent bit storage areas within the user-defined fields of the corresponding address channels on the bus, and neatly writing the physical path code and delay statistics flag into the corresponding areas to complete the encapsulation of the request signal, the orderly arrangement and independent storage of the two types of identification information can be achieved. This effectively avoids information confusion caused by different identification data crowding each other out. Relying on the fixed bit writing rules, the identification embedding standard throughout the entire system can also be unified, ensuring that the identification encapsulation form of various request signals remains consistent. At the same time, the request transmission module strictly maintains that the data bit values ​​in the two areas do not change during the step-by-step forwarding process, ensuring that the identification information is transmitted completely and without loss throughout the entire transmission link. This eliminates the need for additional storage units to cache matching information and saves the cumbersome process of local large-capacity storage table lookup matching, simplifying the request link identification and delay statistics determination process. It ensures that the path code and statistics flag follow the request signal flow synchronously throughout the entire process, laying a stable and reliable information transmission foundation for the subsequent response end to accurately extract the corresponding identification, complete request-response pairing, and accurately start and stop delay timing. Overall, it improves the stability of identification transmission and the overall operating efficiency of delay statistics during signal forwarding within the on-chip network.

[0063] S130. At the same time as sending the target request signal from the request initiation module, start the round-trip delay timer for the target request.

[0064] In the process of forwarding the request signal through the request transmission module, the physical path code and delay statistics flag in the user-defined field remain unchanged. The request response module extracts the physical path code and delay statistics flag from the user-defined field in the received forwarded signal and fills it back into the user-defined field of the bus response channel to generate a response signal carrying the physical path code and delay statistics flag and transmits it back.

[0065] Optionally, based on the above embodiments, generating a response signal through the request-response module may include:

[0066] The request-response module extracts the physical path code and delay statistics flag from the user-defined fields in the received forwarded signal. Following the same bit area format as the request address channel, the physical path code is written into the third area of ​​the user-defined fields in the response channel, and the delay statistics flag is written into the fourth area of ​​the user-defined fields in the response channel, so that the response signal carries the same physical path code and delay statistics flag as the request signal.

[0067] When forwarding the response signal, the request transmission module keeps the bit values ​​of the physical path code in the third region and the delay statistics flag in the fourth region unchanged, and sends the signal to the subsequent modules.

[0068] In this embodiment of the invention, the forwarding signal can be specifically understood as a request signal carrying user-defined fields, forwarded by the intermediate request transmission module. The third and fourth regions can be specifically understood as two fixed-bit regions pre-divided within the user-defined fields of the response channel; the third region stores the physical path code, and the fourth region stores the delay statistics flag. The third and fourth regions are only used to distinguish different regions and have no sequential priority.

[0069] Specifically, after receiving the request signal forwarded by the front end, the request-response module extracts the physical path code and delay statistics flag from its user-defined fields. Following the same bit region arrangement format as the request address channel, it divides the user-defined fields of the response channel into a third and fourth region. The physical path code is written to the third region, and the delay statistics flag is written to the fourth region, ensuring that the generated response signal carries the same path code and delay statistics flag as the original request signal. For example, the same fixed bits are uniformly allocated to the AXI write address channel and read address channel to store the codes NEW_A and NEW_B.

[0070] During the subsequent forwarding of the response signal, each level of the request transmission module keeps the bit values ​​of the third and fourth regions of the user-defined fields in the response channel unchanged, and forwards the response signal to the front-end module in a transparent manner until it reaches the request initiating module.

[0071] By having the request-response module directly extract the physical path code and delay statistics flag from the custom fields of the received request signal, and write them into the dedicated bit area of ​​the response channel using the same bit arrangement rules as the requesting end, it can be ensured that the two types of identification information carried by the response signal are completely consistent with the original request signal. Relying on the standardized field arrangement, it can ensure that the identification reading and writing rules at both ends of the link are mutually compatible, effectively avoiding information parsing failures caused by format differences. At the same time, the request transmission module keeps the bit values ​​corresponding to the two types of identifiers unchanged throughout the entire process of transmitting the response signal, allowing the identification information to flow back to the request initiating module along the original transmission path completely and without error. It can achieve accurate source matching of request and response without the need for additional pairing verification data and local storage table lookup process. This simplifies the information pairing logic in the response return stage, reduces hardware resource consumption and data processing time, and ensures that the request initiating module can accurately determine the corresponding response and complete the delay timing stop operation based on the return identifier. This further improves the accuracy of the round-trip delay statistics results and provides coherent and complete identification data support for subsequent path congestion analysis and request traffic management based on complete link identification data.

[0072] S140. If the current delay statistics flag and the current physical path code are extracted from the received current response signal, and it is determined that the current response signal is a response to the target request, then the round-trip delay timing for the target request is stopped, and a single actual delay value of the target physical path matching the target request is obtained.

[0073] The physical path encoding and delay statistics flags in the user-defined fields of the bus response channel remain unchanged during the forwarding of the response signal through the request transmission module.

[0074] In this embodiment of the invention, the single actual delay value can be specifically understood as: the actual round-trip delay value obtained by sending a single request to the response within a single statistical time window.

[0075] Specifically, within the request initiation module, a delay statistics flag S_Flag is generated for the target request that needs to participate in delay statistics to identify the delay sampling attribute. This delay statistics flag, along with the physical path number information, is embedded in the request message and sent synchronously with the business request. At the same time as the target request signal is sent from the request initiation module, the round-trip delay timer for the target request is started.

[0076] The request transmission modules at all levels transmit this type of identification information transparently throughout the entire process of forwarding requests and responses, without modification or stripping it. When the downstream request and response modules return a response message, they then carry the physical path information and delay statistics flag back to the request initiating module as is.

[0077] The request initiation module parses the bus read response channel or write response channel signals to extract physical path information and obtain the delay statistics flag S_Flag. Based on the physical path number carried in the response message, it identifies the belonging transmission path and then uses the valid delay statistics flag to trigger the delay counting process from stopping the request to the response return, thus obtaining a single actual delay value of the target physical path matching the target request.

[0078] In addition to the implementation method of merging the RUSER and BUSER of the AXI bus to carry dual types of information, it is also possible to use separate custom fields to independently store physical path codes and delay statistics flags. It is also possible to add a parity bit to perform parity checks on user-defined field information to prevent transmission errors. Furthermore, a request number binding mechanism can be added for multiple concurrent requests to achieve one-to-one matching of delay timing for multiple target requests without crosstalk. Without changing the definition of the bus standard service channel, it can use the bus user-defined fields to transparently transmit path codes and statistics flags to achieve end-to-end delay sampling of request sending start timing and response return stop timing. The intermediate modules transmit transparently throughout the process without additional parsing processing. The hardware implementation is simple and highly compatible, providing a reliable message carrying and timing matching mechanism for the accurate collection of the actual delay value of a single round trip for each physical path.

[0079] Optionally, based on the above embodiments, initiating round-trip delay timing for the target request may include:

[0080] Start a round-trip delay counter for the corresponding physical path of the target request, and increment the counter in units of the clock cycle of the request initiating module;

[0081] Accordingly, based on the above embodiments, if the current delay statistics flag and the current physical path code are extracted simultaneously from the received current response signal, and it is determined that the current response signal is a response to the target request, then the round-trip delay timing for the target request is stopped, and a single actual delay value of the target physical path matching the target request is obtained, which may include:

[0082] If the current delay statistics flag and the current physical path code are extracted from the received current response signal, and it is determined that the current response signal is a response to the target request, then the parsed current delay statistics flag is checked to see if it is valid.

[0083] If so, the corresponding round-trip delay counter is stopped from counting based on the current delay statistics flag obtained from parsing, and the count value of the round-trip delay counter is determined as a single actual delay value of the target physical path that matches the current physical path encoding target request.

[0084] In this embodiment of the invention, the round-trip delay counter can be specifically understood as: a hardware counting unit independently configured for each physical path, used to measure the total time from the issuance of each target request to the return of the response, in units of the clock cycle of the request initiation module.

[0085] The current latency statistics flag can be understood as: an identifier bit parsed from the user-defined field of the response signal, used to mark whether the request participates in round-trip latency sampling statistics. The current physical path code can be understood as: a path number extracted from the response signal, used to match the corresponding physical path with the corresponding round-trip latency counter.

[0086] The effective state can be understood as: the delay statistics flag is in a state where sampling is enabled and the start and stop of delay timing is allowed.

[0087] Specifically, while the target request is sent out, a round-trip delay counter dedicated to the physical path to which the target request belongs is started. This counter accumulates time cycle by cycle with the reference clock period of the request initiation module as the smallest measurement granularity, and establishes the delay start measurement benchmark at the time of request sending.

[0088] When the receiving end parses the current response signal and finds that it contains both a matching delay statistics flag and a physical path code, and the matching result confirms that the response is the corresponding response feedback of the target request, it further verifies whether the level or configuration state of the delay statistics flag is in a valid enabled state. If the flag is determined to be valid, it promptly latches and stops the continued incrementing of the corresponding round-trip delay counter, and solidifies the cumulative count value at the time the counter stops as the single actual delay sample value corresponding to the target physical path.

[0089] Understandably, at the hardware level, multiple sets of parallel and independent round-trip delay counting channels can be deployed for each physical path according to the concurrent request depth. Each target request to be timed under the same path occupies a dedicated counting channel. When the request is sent, an idle counting channel is allocated according to the physical path code and the request identifier is bound. Synchronously, each starts to increment the timer independently with the reference clock period of the request initiating module as the granularity, without interfering with each other.

[0090] By using the clock cycle of the request initiating module as a unified counting benchmark for incremental timing, the duration statistics can be completed in accordance with the actual working sequence of the request initiating end. This avoids the problem of inconsistent timing benchmarks caused by asynchronous clocks of different modules, ensuring that the timing process conforms to the actual local operating conditions. Subsequently, when receiving the return response signal, the physical path code and delay statistics flag are extracted synchronously to complete identity matching. The validity status of the statistics flag is further verified before the timing is stopped. This can filter out the corresponding response signals that truly need to complete the delay statistics, eliminate the erroneous timing stop behavior caused by irrelevant response signals, and strictly lock the counter of the corresponding physical path according to the valid statistics flag to complete the processing. The standard clock cycle count value is directly determined as the single actual delay value, reducing the probability of misjudgment and omission in the delay statistics process. This can provide accurate and standardized basic delay data for subsequent calculation of the average of multiple delay data, path congestion factor calculation, and request sending traffic control, effectively improving the accuracy of overall transmission status judgment and traffic control.

[0091] Optionally, based on the above embodiments, the request initiation module is a peripheral interface module, which may include a high-speed peripheral component interconnection module; correspondingly, based on the above embodiments, the method is executed by a request injection control hardware independently configured in the peripheral interface module.

[0092] In this embodiment of the invention, the peripheral interface module can be specifically understood as an interface function module used for data interaction and request transmission / reception between peripherals and the on-chip bus and internal modules. The high-speed peripheral component interconnect module can be specifically understood as a high-performance peripheral interconnect interface hardware unit used to realize high-speed data transmission and transaction request interaction between high-speed peripherals and the on-chip system. The request injection control hardware can be specifically understood as a dedicated hardware logic circuit independently deployed within the peripheral interface module, which does not rely on software scheduling and independently carries out and executes control processes such as request scheduling, latency statistics, and transmission control.

[0093] By configuring the request initiation module as a peripheral interface module that includes a high-speed peripheral component interconnection module, and relying on the independently deployed request injection control hardware within the module to execute the entire set of statistical management methods, the entire process of business operations, such as round-trip delay statistics, identifier encapsulation and matching, timing start / stop, and request traffic control, can be decoupled from the main control processor's scheduling. This effectively releases the system's core computing resources, avoids a large number of interface-side request management services crowding out general computing power, and adapts to high-speed peripheral high-bandwidth, high-concurrency data interaction scenarios. By using dedicated hardware to solidify the execution logic, the processing speed of request path identification, delay timing, and response matching can be improved, adapting to peripheral interfaces and on-chip... The actual architectural characteristics of asynchronous clocks and different operating frequencies between networks enable precise monitoring of transmission status based on the bandwidth constraints and frequency limitations of the peripheral interface itself. This eliminates the need for upper-layer software programs to continuously poll and determine the transmission status, reducing latency fluctuations and operational overhead caused by software scheduling. Furthermore, it allows for path latency statistics and injection control locally on the peripheral interface, shortening control response time. This enables fine-grained traffic adjustment from the request origin, alleviating response backlog and reverse pressure transmission problems caused by insufficient processing capacity of low-frequency peripheral interfaces. Ultimately, this significantly improves the smoothness of data interaction and overall transmission stability between high-speed peripheral interfaces and the on-chip network.

[0094] The technical solution of this invention obtains the target request through a request initiation module and determines the physical path code of the target physical path based on the routing flag information it carries. It then generates a delay statistics flag and fills it into a user-defined field in the bus request address channel. This eliminates the need for lookup operations in a large local storage table. By embedding the physical path code and delay statistics flag into the bus user-defined field, it achieves precise association between the request and its corresponding physical path and response, avoiding confusion in delay statistics for different paths and requests. The round-trip delay timer is started simultaneously with the sending of the target request signal, ensuring synchronization between the timing start and request transmission and guaranteeing initial timing accuracy. When forwarding request and response signals, the physical path code and delay in the user-defined field are strictly maintained. By keeping the statistical flags unchanged, the loss or corruption of flags during transmission can be effectively avoided. Furthermore, the correspondence between requests and responses can be maintained without additional table lookups. By detecting the delay statistics flags and physical path codes present in the response signal, the corresponding response is determined and the timing is stopped. This allows for accurate differentiation between the response corresponding to the target request and other responses, avoiding accidental or missed timing stops. Consequently, the accurate single-transaction actual delay value of the target physical path can be obtained quickly. This reduces the occupation of large local storage and the consumption of system hardware resources, while improving the efficiency and accuracy of delay statistics. It provides reliable data support for subsequent physical path congestion judgment and request injection control, ultimately improving the stability of on-chip system request transmission and optimizing the overall system operating efficiency and resource utilization.

[0095] Example 2

[0096] Figure 2 This is a flowchart illustrating another method for calculating the round-trip delay time according to Embodiment 2 of the present invention. This embodiment is a refinement of the method for calculating the round-trip delay time according to the above embodiments. Figure 2 As shown, the method includes:

[0097] S210. Assign multiple statistical time windows independently to each physical path.

[0098] In this embodiment of the invention, the statistical time window can be specifically understood as: a continuous fixed-duration statistical interval divided for each physical path, used for sampling request round-trip delay data in different time periods.

[0099] S220. Whenever the request initiation module is detected to issue the first request within any statistical time window on any physical path, the first request within the detected window is determined as the target request to be timed for round-trip delay.

[0100] S230. Obtain the target request to be timed for round-trip delay, and obtain the physical path code of the target physical path that matches the target request based on the routing flag information carried in the target request.

[0101] The physical path is the path that the request takes from being sent from the request transmission module to the request response module, and from the request response module returning the response to the request to the request initiating module via the request transmission module.

[0102] S240. Generate a delay statistics flag that matches the target request, and fill the physical path code of the target request and the delay statistics flag into the user-defined field of the bus request address channel according to the preset bit format to obtain the target request signal.

[0103] S250. At the same time as sending the target request signal from the request initiation module, start the round-trip delay timer for the target request.

[0104] In the process of forwarding the request signal through the request transmission module, the physical path code and delay statistics flag in the user-defined field remain unchanged. The request response module extracts the physical path code and delay statistics flag from the user-defined field in the received forwarded signal and fills it back into the user-defined field of the bus response channel to generate a response signal carrying the physical path code and delay statistics flag and transmits it back.

[0105] S260. If the current delay statistics flag and the current physical path code are extracted from the received current response signal, and it is determined that the current response signal is a response to the target request, then the round-trip delay timing for the target request is stopped, and a single actual delay value of the target physical path matching the target request is obtained.

[0106] The physical path encoding and delay statistics flags in the user-defined fields of the bus response channel remain unchanged during the forwarding of the response signal through the request transmission module.

[0107] Specifically, each physical path is independently allocated and its own dynamic congestion factor (Congestion_coeff[i], corresponding to the i-th physical path) is maintained. The statistical period of each physical path is divided into multiple consecutive statistical time windows (Window_T[j]). Each statistical time window is limited to sampling and recording the delay value from request to response only once and storing it as Statistics_latency[i][j]. Here, j refers to the j-th statistical time window, which is used to distinguish multiple consecutive statistical periods under the same physical path.

[0108] Whenever the request initiation module detects that the first request is issued within any statistical time window on any physical path, the first request within the detected window is determined as the target request to be timed for round-trip delay.

[0109] Furthermore, based on the above embodiments, the statistical method for calculating the round-trip delay may further include:

[0110] After continuously collecting a preset number of single actual delay values ​​for the same physical path, the collected single actual delay values ​​are summed and the average delay value is calculated. Based on the calculation result obtained by dividing the average delay value by the physical delay value of the matching physical path, the current dynamic congestion factor of the matching physical path is updated once.

[0111] In this embodiment of the invention, the average delay can be specifically understood as: the average round-trip delay obtained by averaging the accumulated actual delay values ​​of a set number of single physical paths.

[0112] Specifically, after a single physical path (the i-th physical path) has accumulated a preset number of round-trip delay samples (Cfg_N[i]), the sum of all the actual delay values ​​for each single trip corresponding to the preset number is divided by Cfg_N[i] to obtain the average delay value. Then, the average delay value is further divided by the normalized physical delay value Req_Normalized_Latency[i] of the corresponding physical path. Finally, the congestion factor Congestion_coeff[i] of the physical path is generated and updated.

[0113] In addition, the time window duration and the preset sampling quantity Cfg_N[i] can be dynamically and adaptively adjusted according to the traffic load of the physical path. The sliding time window superimposed weighted average method can be used instead of the arithmetic average to calculate the mean delay. The congestion factor update filter threshold can also be set to avoid the frequent jump of the congestion factor caused by instantaneous delay jitter. It can realize independent sampling, accurate quantification and smooth iterative update of the congestion status of each physical path. The ratio of the measured round-trip delay of the service to the hardware's inherent normalized physical delay is used as the basis for congestion assessment, which objectively reflects the degree to which the actual transmission delay of the link deviates from the ideal hardware delay.

[0114] By continuously collecting a sufficient number of single actual delay values ​​along the same physical path and calculating the average, the latency data deviation caused by instantaneous data stream fluctuations and clock domain interaction differences during a single request transmission can be effectively smoothed out. This makes the obtained average latency value more consistent with the long-term stable real transmission operation state of the physical path. Then, the average value is compared with the inherent physical latency value of the corresponding path to update the dynamic congestion factor. Quantitative benchmarking can be completed based on the inherent transmission attributes of the path, so that the finally updated congestion factor can intuitively and accurately reflect the congestion level of the current path compared to the idle state. This abandons the one-sidedness of judging the path status based on a single instantaneous latency data, and realizes a standardized quantitative assessment of the congestion level of each physical path. This not only makes the congestion status judgment results more objective and valuable, but also provides an accurate and reliable quantitative basis for subsequent correction of the actual carrying capacity of the path and the determination of reasonable request sending thresholds based on the congestion factor. This allows the system to carry out traffic control in advance based on the real-time updated congestion status, alleviate transmission pressure from the source, and reduce the occurrence of transmission congestion and data accumulation within the on-chip network.

[0115] Furthermore, based on the above embodiments, the statistical method for calculating the requested round-trip delay time may further include:

[0116] The system uses a statistical time window counter corresponding to each physical path to periodically count the number of requests issued within the window under that physical path in real time, according to the clock frequency of the request initiation module.

[0117] Specifically, whenever the statistical time window counter of the preset physical path counts to the preset number, a zeroing operation is performed and the physical path is triggered to perform a dynamic congestion factor update operation.

[0118] In this embodiment of the invention, the statistical time window counter can be specifically understood as a hardware counting register configured separately for each physical path, used to periodically accumulate according to a reference clock, and to control the cyclic switching and periodic triggering of the time window. The number of the first request within the window can be specifically understood as the cumulative statistical number of the first request issued by the physical path, used to determine the timing of dynamic congestion factor updates.

[0119] Specifically, an independent statistical time window counter Counter_W[i] (corresponding to the i-th physical path) is configured for each physical path. The counter uses the reference clock frequency F1 of the request initiation module as the working timing reference. It starts from the value 0 and automatically increments by 1 every time a reference clock cycle passes and a request is issued within the window, and continues to run in a loop. When the Counter_W[i] count value increases to the preset window configuration number Cfg_W[i] of the corresponding physical path, the counter is automatically reset to 1 and starts the next round of loop counting. At the same time, the corresponding physical path is triggered to perform a dynamic congestion factor update operation.

[0120] In addition, it can be configured to support variable step size increments, and Cfg_W[i] can be dynamically and adaptively adjusted according to the business load. A window enable register can be added to realize on-demand switching control of some physical path time windows.

[0121] By configuring an independent statistical time window counter for each physical path and performing periodic cyclic counting according to the reference clock frequency of the request initiation module, it can accurately divide regular statistical time windows with hardware timing, count the number of requests sent in the first request within each physical path window in real time, and automatically reset the counter when the count reaches a preset threshold, synchronously triggering the update operation of the corresponding physical path's dynamic congestion factor. Relying on the hardware counter's autonomous cyclic timing and event triggering, no software intervention is required for scheduling, reducing system control overhead and logical complexity. At the same time, it ensures that the time window period division of each physical path is uniform and consistent, and the congestion factor update timing is controllable, avoiding the problems of delayed sampling chaos and congestion coefficient update lag caused by random triggering. This allows the congestion factor to be periodically iterated and calibrated according to a fixed timing sequence, matching the real-time congestion change pattern of the link, and improving the balance of system traffic scheduling and overall operational reliability in multi-physical path concurrent transmission scenarios.

[0122] Furthermore, based on the above embodiments, the statistical method for calculating the requested round-trip delay time may further include:

[0123] During on-chip system initialization or application scenario switching, a corresponding congestion factor register and statistical time window counter are allocated to each physical path, and the statistical time of each physical path is divided into multiple consecutive statistical time windows; the congestion factor register is configured to store the initial value and dynamic update value of the congestion factor of the corresponding physical path; the statistical time window counter is configured to perform periodic cyclic counting according to the clock frequency of the request initiation module.

[0124] In this embodiment of the invention, the congestion factor register can be specifically understood as: a dedicated hardware register independently deployed for each physical path, used to store the initial configuration value of the congestion factor of the corresponding physical path and the dynamically updated value during operation.

[0125] Specifically, during the hardware design phase, a dedicated congestion factor register Congestion_coeff[i] is independently deployed for each physical path (corresponding to the i-th physical path). During on-chip system initialization or application scenario switching, the system can write and configure the initial value of the congestion factor to the corresponding register, and at the same time divide the congestion statistics time of each physical path into multiple consecutive statistics time windows Window_T[j].

[0126] Hardware synchronization allocates an independent statistical time window counter Counter_W[i] to each physical path. By writing a configuration value less than or equal to the maximum length of the hardware to the configurable register Cfg_W[i], the preset number used for determining the timing of dynamic congestion factor updates can be flexibly set.

[0127] The congestion factor register stores the initial and dynamically updated values ​​of the congestion factor for the corresponding physical path, and the statistical time window counter matches the clock frequency of the request initiation module to achieve periodic cyclic counting.

[0128] By independently allocating a dedicated congestion factor register and statistical time window counter to each physical path during on-chip system initialization or application scenario switching, and dividing the congestion statistics duration of each physical path into multiple consecutive statistical time windows, while specifying that the congestion factor register is dedicated to storing the initial congestion factor configuration value and dynamically updated values ​​during operation for the corresponding physical path, and configuring the statistical time window counter to perform periodic cyclic counting based on the clock frequency of the request initiation module, dedicated hardware resources are provided to support independent storage of congestion parameters, regular division of statistical time periods, and hardware timing control for each physical path. Resource allocation and parameter presetting are completed in one go during system startup or scenario switching, without the need to dynamically occupy additional hardware resources during operation. Relying on independent registers and counters, the congestion status of each physical path is decoupled and managed, avoiding mutual interference between congestion parameters and statistical timing between different physical paths. At the same time, by using regularly divided continuous statistical time windows in conjunction with periodic counting driven by a reference clock, a unified timing and hardware configuration foundation is laid for the dynamic management of request delay sampling, periodic iterative updates of congestion factors, and request injection traffic within the subsequent window. This improves the independence, timing regularity, and overall management stability of congestion statistics in multi-physical path concurrent transmission scenarios.

[0129] The technical solution of this invention, by configuring independent statistical time windows for each physical path, enables partitioned control of latency statistics for different transmission paths. By limiting the selection of only the first sent request within a single window as the latency statistics object, it effectively avoids data redundancy and interference between statistical results caused by a large number of concurrent requests on the same path within the same time period. This not only orderly divides the execution time of latency statistics, making the latency sampling rhythm of each physical path more regular and unified, but also reduces invalid and repetitive latency statistics operations, saving system timing and data processing resources. Furthermore, by limiting the selection of representative request samples through the window to complete round-trip latency statistics, it effectively weakens the data fluctuation interference caused by massive concurrent requests, improves the representativeness and reference value of latency data collection for a single physical path, and makes subsequent control work based on this latency data, such as path congestion determination and request sending traffic control, more closely reflect the actual transmission operation status of the path, further ensuring the rationality and accuracy of cross-module request transmission control within the on-chip system. The system obtains the target request through the request initiation module and determines the physical path code of the target physical path based on the routing flag information it carries. It generates a delay statistics flag and fills it into the user-defined field of the bus request address channel. Without relying on a large local storage table for table lookup, it can achieve accurate association between the request and the corresponding physical path and response. When forwarding request and response signals, it strictly keeps the physical path code and delay statistics flag in the user-defined field unchanged. By detecting the delay statistics flag and physical path code that are present in the response signal, it determines the corresponding response and stops the timing. It quickly obtains the accurate single-time actual delay value of the target physical path, improves the efficiency and accuracy of delay statistics, and optimizes the overall system operating efficiency and resource utilization.

[0130] Example 3

[0131] Figure 3 This is a flowchart illustrating another method for calculating round-trip delay time for a request, provided in Embodiment 3 of the present invention. This embodiment is a refinement of the step described in the above embodiment: "obtaining the physical path code of the target physical path matching the target request based on the routing flag information carried by the target request." Figure 3 As shown, the method includes:

[0132] S310. Obtain the target request to be used for round-trip delay timing, and obtain the target address or target device identifier that matches the target request based on the routing flag information carried in the target request.

[0133] S320. Determine the target device range to which the target address or target device identifier belongs, and map the target device range to a preset physical path code, which serves as the physical path code for the target physical path that matches the target request.

[0134] The physical path is the path that the request takes from being sent from the request transmission module to the request response module, and from the request response module returning the response to the request to the request initiating module via the request transmission module.

[0135] In this embodiment of the invention, the target address can be specifically understood as: the address encoding information carried in the request message used to identify the target storage space, peripheral register, or on-chip unit, and the destination address information used to locate the hardware resource to be accessed. The target device identifier can be specifically understood as: a unique identification number, device ID (Identifier), or port identifier pre-assigned to each functional device, storage module, and computing module in the on-chip system, used to distinguish target hardware devices of different types and locations.

[0136] The target device range can be understood as: a pre-divided address range bound to each physical path, used for mapping and matching physical path addresses. The physical path encoding can be understood as: a unique index assigned to each physical path, used to identify, address, and retrieve the corresponding path's parameter data.

[0137] Specifically, in the process of parsing the routing identifier information carried in the request and identifying the corresponding target physical path, the destination address information or target device identification information is first extracted from the current request message as routing identifier information (such as Info_C). This type of information can be in the form of the request destination address, target device identification number, etc. Then, the extracted routing identifier information is matched and compared with the address ranges corresponding to each physical path preset by the system one by one. The physical path code corresponding to the successfully matched entry is determined as the target physical path code corresponding to the current request, and the target physical path traversed by the current request is determined based on the target physical path code.

[0138] For example, when the destination address carried in the request falls within the DDR (Double Data Rate) 1 addressing range, the Index_B (address index identifier B, a name identifier for a custom address generator) address generator generates a physical path value i with a value of 0 to address the delay normalized value of the first physical path. When it falls within the DDR2 addressing range, it generates a physical path value i with a value of 1 to address the delay normalized value of the second physical path. When it falls within the DDR3 addressing range, it generates a physical path value i with a value of 2 to address the delay normalized value of the third physical path. This matching and index generation function can be implemented by the destination address resolution module built into the on-chip system. Then, the physical path code corresponding to the successfully matched address range is determined as the target physical path code of the current request, and the target physical path traversed by the current request round-trip transmission is locked based on this code.

[0139] Here, DDR stands for Double Data Rate Storage Unit, which is a target storage device divided into different addressing intervals. Index_B is a custom address generator identifier, which is used to generate the corresponding physical path value i according to the DDR addressing interval to which the requested destination address belongs, and then match the corresponding physical path code and normalized delay value.

[0140] S330. Generate a delay statistics flag that matches the target request, and fill the physical path code of the target request and the delay statistics flag into the user-defined field of the bus request address channel according to the preset bit format to obtain the target request signal.

[0141] S340. At the same time as sending the target request signal from the request initiation module, start the round-trip delay timer for the target request.

[0142] In the process of forwarding the request signal through the request transmission module, the physical path code and delay statistics flag in the user-defined field remain unchanged. The request response module extracts the physical path code and delay statistics flag from the user-defined field in the received forwarded signal and fills it back into the user-defined field of the bus response channel to generate a response signal carrying the physical path code and delay statistics flag and transmits it back.

[0143] S350. If the current delay statistics flag and the current physical path code are extracted from the received current response signal, and it is determined that the current response signal is a response to the target request, then the round-trip delay timing for the target request is stopped, and a single actual delay value of the target physical path matching the target request is obtained.

[0144] The physical path encoding and delay statistics flags in the user-defined fields of the bus response channel remain unchanged during the forwarding of the response signal through the request transmission module.

[0145] Furthermore, based on the above embodiments, the statistical method for calculating the round-trip delay may further include:

[0146] Whenever a current request to be sent is obtained, the routing flag information carried in the current request is parsed, and the current physical path corresponding to the current request is determined according to the preset mapping relationship between the routing flag information and the physical path.

[0147] Obtain the physical delay value of the current physical path, and based on the physical delay value, predict the maximum physical capacity that the current physical path can receive responses.

[0148] Based on the current dynamic congestion factor of the current physical path and the maximum physical capacity that the current physical path can receive responses, calculate the maximum actual capacity that the current physical path can receive responses.

[0149] Obtain the current determined response processing capacity of the current physical path in the response buffer within the request initiation module, and combine the maximum actual capacity with the current determined response processing capacity to calculate the total response processing capacity of the current physical path;

[0150] Set the maximum number of incomplete requests allowed for the current physical path based on the total response processing capacity;

[0151] Count the number of incomplete requests that have been sent and have not yet received a response on the current physical path. If the number of incomplete requests is less than the maximum number of incomplete requests, the current request is identified as the target request for round-trip delay timing.

[0152] In this embodiment of the invention, the current request can be specifically understood as: a read / write service request message generated by the request initiation module in the on-chip system and to be sent out.

[0153] The current physical path can be understood as the complete fixed transmission path through which the current request originates from the request initiation module, passes through the request transmission module, arrives at the request response module, and the response data is transmitted back to the request initiation module along the original path.

[0154] Physical latency can be specifically understood as the inherent hardware transmission delay of a request completing a round trip via the target physical path; it is a fixed timing attribute parameter of the path itself. Maximum physical capacity can be specifically understood as the theoretically maximum capacity that the current physical path can simultaneously accommodate and carry responses under hardware timing and link bandwidth constraints.

[0155] The dynamic congestion factor can be understood as a dynamic coefficient that reflects the current link congestion level and data backlog of the target physical path in real time, changing in real time with network load, packet queuing, and other conditions. The maximum actual capacity can be understood as the actual upper limit of the physical path's capacity to safely accept responses without packet backlog or link blockage, after considering the impact of real-time congestion.

[0156] The current determined response processing capacity can be understood as follows: the available steady-state processing margin of the physical path (such as the i-th path) at the response buffer level of the request initiating module is dynamically calculated in real time by the hardware logic depth. This can correspond to the parameter Resp_DeterminedCapacity_Current[i], which belongs to the determined capacity part of the buffer static configuration plus real-time updates.

[0157] The total response processing capacity can be understood as: the upper limit of the overall available response carrying capacity of the entire physical path (such as the i-th path) after the buffer's determined processing capacity and the maximum actual capacity of the link are combined and calculated. The corresponding parameter can be Resp_EffectiveCapacity_Current[i].

[0158] The maximum number of uncompleted requests allowed at present can be understood as: the maximum number of requests that have been sent but have not yet received a response that can be allowed on a single physical path (such as the i-th path). The parameter can be Outstanding_Req_Max[i].

[0159] Accordingly, a target request is a current service request that has passed the admission judgment, is allowed to be sent normally from the request initiation module, and needs to be included in subsequent round-trip transmission delay sampling, timing statistics, and link status monitoring. Not all requests arriving at the sending end can become target requests. Only requests that meet the following conditions—the number of incomplete requests is less than the maximum allowable threshold, and resources and link capacity are sufficient—will be selected as target requests to be timed, thus gaining the qualification to be sent and entering the scope of system delay observation and path performance statistics.

[0160] Specifically, the request initiation module collects the current request to be sent and parses and identifies the routing identifier information carried in the current request. It can directly match the link topology based on the routing identifier information to determine the complete round-trip transmission path, or it can determine its affiliation based on the request's own attribute characteristics (e.g., based on the request's inherent attributes such as read / write access type, accessed storage area range, or current peripheral device type). It then matches and determines the corresponding physical path information index value, thus marking the current physical path traversed by the current request from the request initiation module through various request transmission modules to the request response module, and by the response data from the request response module back through the request transmission modules to the request initiation module. Besides relying on routing identifier parsing and request attribute matching, physical path identification and index assignment can also be completed through preset address range mapping and device identifier binding to path numbers.

[0161] Obtain the physical delay value of the current physical path (e.g., the i-th path), and use the round-trip transmission delay of a single request response as the basic timing period to predict the maximum physical capacity that the current physical path can receive responses.

[0162] For example, by combining the number of response packets that the fixed link bandwidth of the physical path can carry per unit time, and then adding the forwarding overhead brought by the path topology layer, the parallel carrying limit of the concurrent transmission channel, and the inherent forwarding latency of the on-chip network routing node for compensation and correction, the maximum carrying capacity of the physical path that the hardware can simultaneously accept response packets under no-congestion and no-load conditions is quantified. This maximum carrying capacity is assigned as the predicted capacity parameter Resp_PredictedCapacity_Current_max[i] of the i-th physical path, which serves as the benchmark for the hardware's inherent maximum physical capacity that is not affected by real-time traffic load.

[0163] Obtain the real-time dynamic congestion factor of the current physical path (such as the i-th path) corresponding to the current request. Using the maximum physical capacity of the physical path that can receive a response, which is pre-calculated, as the inherent benchmark of the hardware, the maximum physical capacity and the real-time congestion factor of the physical path are coupled and calculated. Taking into account the hardware limit capacity specification and the current link congestion level, the maximum actual capacity of the physical path that can receive a response corresponding to the current request is predicted and solved, and the capacity parameter Resp_PredictedCapacity_Current[i] is assigned to it.

[0164] In addition to the basic calculation method of directly weighting the maximum physical capacity using congestion factors, it can also set correction coefficients according to congestion levels and perform offset compensation in combination with path service priorities. This can organically combine the static hardware limit capacity with the dynamic real-time network load status, retaining the inherent hardware capacity constraints of physical paths while taking into account the bearing attenuation caused by real-time congestion, and accurately fitting the current real available response acceptance limit for each physical path.

[0165] In the request initiation module, the baseline values ​​of the response processing capacity of the determined parts of all physical paths are preset and stored in advance. At runtime, based on the physical path index information to which the current request belongs, the response processing capacity value Resp_DeterminedCapacity_Current[i] of the determined part of the current physical path is obtained. Then, the maximum actual actual capacity of the physical path that can receive responses after congestion correction is fused with the obtained response processing capacity value of the determined part. The calculation can be performed by either a simple operation of direct addition or a weighted combination with weight coefficients to generate the total response processing capacity Resp_EffectiveCapacity_Current[i] of the current physical path.

[0166] Based on the total response processing capacity Resp_ExpectedCapacity_Current[i] corresponding to the current physical path to which the current request belongs (such as the i-th path), the maximum number of uncompleted requests Outstanding_Req_Max[i] allowed for the current physical path is generated by mapping and converting this capacity. This maximum number of uncompleted requests is not a fixed static configuration value, but is dynamically and adaptively adjusted in real time according to the fluctuation of the total response processing capacity.

[0167] In addition, security redundancy coefficients and business priority offsets can be added for fine-tuning, ensuring that the maximum number of uncompleted requests always matches the current cache capacity and link congestion status of the physical path, accurately adapting to real-time operating conditions.

[0168] In the request sending module, a dedicated register is configured for each physical path to count and store the number of requests that have been sent but not yet responded to in real time: Outstanding_Req_Current[i] (corresponding to the i-th physical path). When the system is reset, this count value for all paths is initialized to 0.

[0169] Get the maximum number of uncompleted requests dynamically generated on the same physical path, Outstanding_Req_Max[i]. Compare the real-time number of uncompleted requests with the maximum threshold. When Outstanding_Req_Current[i] is less than Outstanding_Req_Max[i], it is determined that the link and buffer resources are sufficient, and the current request is allowed to be sent out normally from the request initiation module. At the same time, the request is identified as the target request to be subject to round-trip delay timing.

[0170] Understandably, the maximum number of uncompleted requests is a threshold that dynamically changes in real time based on the total response processing capacity of the physical path, the link congestion status, and the buffer load, rather than being fixed. When physical path link congestion worsens, response buffer usage increases, and the total response processing capacity passively decreases, the dynamically set maximum number of uncompleted requests threshold will decrease accordingly. At this time, the existing uncompleted requests already issued on the path have not yet received timely responses and cannot quickly decrease, which will result in the current number of uncompleted requests not having enough time to decrease synchronously and momentarily exceeding the dynamic threshold. At the same time, the arrival of a sudden batch of requests and the extension of request response latency will cause old requests to occupy the link count for a long time, which will further widen the numerical difference and cause the number of uncompleted requests to exceed the maximum allowable number.

[0171] Therefore, when the number of incomplete requests in real time is greater than or equal to the maximum threshold, the current request is prohibited from being sent to avoid continuing to inject requests into the link and causing congestion.

[0172] By parsing routing flag information to accurately match the corresponding physical path, and relying on the inherent physical latency value of the path to predict its basic response capacity limit, and then combining it with the real-time updated dynamic congestion factor to derive the maximum actual capacity that fits the real-time transmission conditions, the overall response processing capacity of the path is obtained by integrating it with the actual processing capacity of the response buffer inside the request initiation module. This scientifically determines the maximum number of incomplete requests that the current path can accommodate, and compares the actual number of incomplete requests sent in real time to filter and determine the target requests for which latency statistics can be performed. This allows for completion from the request origin based on the inherent hardware performance of the path, the real-time congestion situation, and the local cache processing capacity. Multi-level traffic control changes the traditional delayed flow control and passive backpressure management mode, enabling early prediction of transmission load and proactive limitation of request issuance rhythm. This avoids the problems of response data accumulation and reverse pressure transmission caused by exceeding the path's capacity limit. It not only ensures a more balanced and reasonable load distribution among various transmission paths within the on-chip network, but also filters out compliant requests that are suitable for the current transmission status to conduct round-trip delay statistics. This further ensures the effectiveness and representativeness of delay sampling data, making subsequent delay statistics results highly consistent with the actual operating conditions of the path. It comprehensively improves the overall data transmission efficiency, operational stability, and the precision of delay statistics and traffic control of the on-chip system.

[0173] Furthermore, based on the above embodiments, before obtaining the current request, the following may also be included:

[0174] Subtract the configurable reserve from the physical depth of the response buffer in the request initiation module corresponding to each physical path to obtain the logical depth of the response buffer, which serves as the initial determination of the response processing capacity of the response buffer corresponding to each physical path.

[0175] Accordingly, based on the above embodiments, the method may further include:

[0176] Whenever a response corresponding to the current physical path is written to the response buffer, the current determined response processing capacity is decremented by 1; whenever a response corresponding to the current physical path is read from the response buffer, the current determined response processing capacity is incremented by 1.

[0177] In this embodiment of the invention, the response buffer can be specifically understood as: a cache area within the request initiation module used to temporarily store response data returned from each physical path. The physical depth of the response buffer can be specifically understood as: the maximum number of entries that the hardware can actually accommodate in the response buffer allocated to each physical path within the request initiation module, which is the hardware's inherent storage capacity limit. The configurable reserve can be specifically understood as: a flexibly configurable buffer margin value used to reserve some buffer space to cope with sudden response traffic and avoid instantaneous congestion triggering backpressure.

[0178] The logical depth of the response buffer can be understood as the available logical capacity obtained after deducting the reserved amount from the physical depth, serving as the actual available response capacity limit at the system scheduling level. The initial determination of response processing capacity can be understood as the baseline capacity value that the response buffer can accept and process for each physical path in the initial state of the system.

[0179] Specifically, before obtaining the current request execution path identification and request injection control process, the capacity of the response buffer inside the request initiation module corresponding to each physical path is initialized in advance. The maximum physical depth of the response buffer of each physical path (physical path index number i) is subtracted from the corresponding configurable reserved amount depth_margin[i], and the result is assigned to the logical depth of the response buffer Resp_buffer_depth[i]. This logical depth represents the maximum number of logical responses that the corresponding path response buffer can accept during system operation. It has the characteristic of dynamic configuration and is not constrained by the fixed value of hardware physical capacity. This is used as the initial determination of the response processing capacity of each physical path.

[0180] The system continuously maintains the buffer state dynamically during operation. When a response from the corresponding physical path is written to the response buffer, the current determined response processing capacity is decremented by 1. When a response is read from the response buffer, the value is incremented by 1. If response writing and response reading occur in parallel at the same time, the current determined response processing capacity value remains unchanged.

[0181] In addition to the implementation method of calculating the logical depth by deducting a fixed reserve from the physical depth, the configurable reserve size can also be dynamically adjusted according to the system load level and business priority, or the initial value of the logical depth can be configured differently according to the transmission bandwidth and business latency requirements of different physical paths. It can accurately define the upper limit of logical processing while preserving the redundancy of hardware physical buffer capacity, and draw the real idle carrying capacity of the response buffer in real time. This provides a dynamic and accurate capacity basis for subsequent calculation of total response processing capacity, setting of the maximum number of uncompleted requests, and request injection rate limiting control, avoiding the problems of buffer overflow and premature backpressure.

[0182] By using the inherent physical depth of the response buffer as a basis, subtracting configurable reserves to calculate the logical depth, and setting this as the initial response processing capacity for each physical path, the system dynamically updates the determined response processing capacity by successively decreasing and increasing it based on the real-time behavior of response writing and reading from the buffer during system operation. This approach not only preserves hardware redundancy space in the buffer using configurable reserves, avoiding buffer overflow and premature propagation of backpressure caused by instantaneous response traffic surges, but also allows the logical depth to replace the physical depth as the scheduling benchmark, freeing it from the constraints of fixed hardware physical capacity and enabling flexible configuration of response processing capacity. Furthermore, it can determine the remaining available capacity of the response buffer for each physical path in real time, ensuring that subsequent calculations of total response processing capacity, limits on the maximum number of uncompleted requests, and request injection control all align with the actual load level of the buffer. This avoids the control lag or excessive rate limiting issues caused by using fixed capacity thresholds, improving the adaptability and rationality of request traffic scheduling in multi-physical-path concurrent transmission scenarios and enhancing the overall stability of on-chip system transmission operation.

[0183] Furthermore, based on the above embodiments, before obtaining the current request, the following may also be included:

[0184] The number of unfinished requests corresponding to each physical path is initialized to zero, which is used as the initial number of unfinished requests corresponding to each physical path;

[0185] Accordingly, based on the above embodiments, the method may further include:

[0186] Whenever a request corresponding to the current physical path is successfully sent from the request initiation module to the request transmission module, the number of incomplete requests for the current physical path is incremented by 1; whenever a response corresponding to the current physical path is read from the response buffer of the request initiation module, the number of incomplete requests for the current physical path is decremented by 1.

[0187] In this embodiment of the invention, the number of incomplete requests can be specifically understood as: the cumulative number of requests that have been sent from the request initiation module but for which a corresponding response has not yet been received, and which have been processed. The initial number of incomplete requests can be specifically understood as: the initial value of the incomplete request count set for each physical path at the time of system power-on initialization or application scenario switching.

[0188] Specifically, before executing the parsing and path identification process for the current request, the number of incomplete requests for each physical path in the on-chip system is initialized and uniformly set to zero to form the initial incomplete request count baseline for each physical path.

[0189] During normal system operation, the count value is dynamically maintained in real time. When the request for the corresponding physical path is successfully sent from the request initiation module to the request transmission module, the number of incomplete requests is automatically incremented by 1. When the response data for the corresponding physical path is read from the response buffer inside the request initiation module and the business processing is completed, the number of incomplete requests is automatically decremented by 1. If the request sending and response reading events occur at the same time, the number of incomplete requests remains unchanged.

[0190] In addition to the basic method of triggering count increments and decrements by request sending and response reading, it can also support configuring independent counting thresholds and update granularities for different physical paths according to request service priority and transmission link bandwidth weight. It can accurately and in real time characterize the real-time stock status of non-closed-loop requests in each physical path, providing accurate counting basis for subsequent comparison of the number of incomplete requests and the maximum number of incomplete requests, and carrying out request injection access control, thus realizing fine-grained traffic control based on real request load.

[0191] By uniformly initializing the number of incomplete requests on each physical path to zero before processing the current request, a unified counting starting benchmark is established, avoiding traffic statistics deviations caused by initial counting disorder. At the same time, when a request is successfully sent from the request initiation module to the request transmission module, the number of incomplete requests is incremented by 1, and after the response is read from the response buffer and processed, it is decremented by 1. This allows for real-time, accurate, and dynamic tracking of the real-time inventory of requests sent but not yet completed in the response loop on each physical path. It fully records the entire lifecycle flow of a request from initiation and transmission to the completion of response processing. It can achieve real-time statistics of path request load in a lightweight manner without relying on complex link monitoring mechanisms. This provides a reliable numerical basis for comparing the real-time number of incomplete requests with the preset maximum number of incomplete requests and accurately determining whether a request can be injected and sent. This enables advance rate limiting and dynamic scheduling based on the actual load status of each physical path, preventing excessive accumulation of requests on a single physical path, on-chip network link congestion, and back pressure propagation from the response buffer. It ensures the balance, orderliness, and overall operational stability of on-chip system request scheduling in multi-physical path concurrent transmission scenarios.

[0192] Furthermore, based on the above embodiments, before obtaining the physical delay value of the current physical path, the following may also be included:

[0193] When the on-chip system initializes or switches application scenarios, it configures and stores the clock frequency information of each module in the on-chip system and the physical delay information of the modules passing through all physical paths; based on the clock frequency information of each module and the physical delay information of each module under its physical path, it performs physical delay normalization processing on each physical path to obtain a normalized physical delay value counted by the clock frequency of the request initiating module, which is used as the physical delay value corresponding to each physical path.

[0194] In this embodiment of the invention, the clock frequency information can be specifically understood as: the main clock frequency parameters of each functional module within the on-chip system, and different modules can adopt a heterogeneous clock domain design. The physical delay information can be specifically understood as: the inherent transmission delay generated by each physical path passing through each hardware module, which is a fixed delay parameter inherent to the hardware topology and wiring.

[0195] The normalization of physical delay can be understood as follows: converting the original delays under different clock domains into equivalent delay values ​​under the reference clock of the request initiating module. The normalized physical delay value can be understood as: a standard delay value after eliminating the heterogeneous clock differences between multiple modules, using the request initiating module's clock as a unified counting reference.

[0196] Specifically, before obtaining the physical delay value of the current physical path, global parameter configuration and delay normalization preprocessing need to be completed in advance. When the on-chip system starts initialization or the business application scenario is switched, the clock frequency parameters of all functional modules at all levels in the system are pre-configured and stored in the request initiation module. At the same time, the original physical delay values ​​corresponding to all physical paths are preset and saved. Then, based on the stored clock frequencies of each level of modules and the original physical delay information of each physical path, the discrete delay data of each level of modules along each physical path are uniformly converted and normalized to the reference clock frequency F1 of the first level module. The normalized delay parameter Dynamic_Normalized_Latency[i] corresponding to the i-th physical path is generated and stored, which is used as the standard physical delay value of the physical path.

[0197] In addition, it supports dynamic fine-tuning based on module clock frequency during runtime and online recalculation and updating of normalized delay values. It can also group and configure multiple sets of clock and delay parameters according to different application scenarios and switch and call them as needed. It can effectively shield the delay measurement deviation caused by heterogeneous clock domains of multiple modules in the on-chip system, so that the delay parameters of each physical path have a unified measurement benchmark, and provide delay data with consistent timing benchmark for subsequent path maximum physical capacity prediction, congestion factor calculation and request injection control.

[0198] By uniformly configuring and storing the clock frequency information of each functional module and the physical delay information of each physical path's traversed modules during on-chip system initialization or application scenario switching, and performing delay normalization conversion processing on each physical path based on the clock frequency and the original physical delay information, the original delay under the heterogeneous clock domains of multiple modules is uniformly converted into a normalized physical delay value with the clock frequency of the request initiating module as the sole counting benchmark, and used as a standard delay parameter. This can eliminate delay measurement deviations caused by inconsistencies in the working clocks of different modules, unify the measurement standard of physical path delays across the entire system, and avoid path delays caused by clock domain differences. To address the issues of inaccurate latency values ​​and inaccurate maximum physical capacity prediction, a method of configuring and normalizing latency parameters once during initialization or scenario switching and then storing them permanently is adopted. This reduces the real-time computational overhead and hardware logic complexity during system operation, ensuring that the latency parameters of each physical path are horizontally comparable and time-series consistent. This provides a unified baseline latency data support for subsequent prediction of maximum physical capacity of physical paths, dynamic congestion factor correction, control of the number of incomplete requests, and setting of request injection thresholds. It also ensures the accuracy and stability of request traffic scheduling and congestion control logic under a multi-heterogeneous clock module and multi-physical path concurrent transmission architecture.

[0199] Optionally, based on the above embodiments, normalizing the physical delay for each physical path to obtain a normalized physical delay value counted at the clock frequency of the request initiating module may include:

[0200] Traverse all physical path codes, and read the clock frequency parameters and physical delay parameters of the modules traversed by each physical path in turn; multiply the physical delay parameters of the modules traversed by each physical path by the corresponding clock frequency parameters and sum them up; divide the sum by the clock frequency parameters of the request initiating module and round up to obtain the normalized physical delay value of the physical path.

[0201] In this embodiment of the invention, the clock frequency parameter can be specifically understood as: the inherent operating main frequency configuration value of each functional module, such as Cfg_F[j], where j is the module number. The physical delay parameter can be specifically understood as: the original path delay value corresponding to a single physical path passing through each module, such as Fn_path_latency[i], where i is the path index.

[0202] Specifically, by traversing all physical path codes, the clock frequency parameter Cfg_F[j] and physical delay parameter (physical delay information) Fn_path_latency[i] (representing the delay information of the i-th physical path passing through the n-th level module) corresponding to each module through each physical path are read sequentially. According to the preset operation logic, the clock frequency parameter of each module and the physical delay parameter of the corresponding path are multiplied and summed. Then, the sum is divided by the reference clock frequency parameter corresponding to the request initiating module (i.e., the clock frequency parameter Cfg_F[1] of the first module). The result is then integerized using the Ceiling rounding function to obtain the normalized delay parameter Dynamic_Normalized_Latency[Index_B0] in the form of an integer clock cycle. Among them, Index_B0 is the physical path index number (path ID), which is used to uniquely identify, traverse, and address a physical path in the on-chip system. It is the addressing subscript for hardware calculation of normalized delay. For example, Index_B0=1 represents the first physical path, and Index_B0=2 represents the second physical path.

[0203] For example, Dynamic_Normalized_Latency[2]=20 means that the equivalent delay of the second physical path is 20 reference clock cycles.

[0204] At the hardware level, when the system is reset or the module clock frequency parameters are reconfigured, a physical path index entity Index_B0 can be automatically generated and multiple sets of module delay parameters corresponding to each path can be retrieved. The normalized delay calculation for a single path is completed by substituting them into the formula one by one. Then, the batch calculation and storage of all physical path parameters are achieved by iterating through the Index_B0 index values. When the application scenario is switched and the clock frequency parameters are reconfigured, the Index_B address generator can be triggered by the linkage between the scenario switching enable register and the physical path quantity register to start counting calculations one by one. When the count value reaches the threshold set by the physical path quantity register, it is determined that the normalized delay calculations for all paths are completed and the traversal stops.

[0205] In addition, different weight correction coefficients can be set according to module type, or delay calculation can be performed by grouping and segmenting according to business scenarios. At the same time, the normalized delay parameters can be automatically refreshed at multiple times such as power-on initialization, parameter reconfiguration, and scenario switching, relying on the register configuration event triggering mechanism.

[0206] By traversing all physical path codes and reading the clock frequency and physical delay parameters of each path's modules, delay normalization is achieved by multiplying the clock frequency of each module by its corresponding physical delay, summing the results, dividing by the reference clock frequency of the request initiating module, and rounding up. This process converts the dispersed physical delays of multiple modules in heterogeneous clock domains within the on-chip system into integer quantized delay values ​​based on the clock cycle of the request initiating module. This eliminates the inconsistency in delay measurement caused by differences in clock frequencies between different modules. The rounding up integer operation rule aligns with the hardware circuit's support for integers. The computational design simplifies the complexity of hardware logic implementation and eliminates the need for floating-point arithmetic units. At the same time, it uses standardized formulas to perform batch delay calculations for all physical paths, ensuring that the normalized delay value calculation rules for each path are consistent and the results can be compared horizontally. This provides a consistent, accurate, and easily stored and retrieved delay parameter for subsequent prediction of maximum response capacity of physical paths, congestion status assessment, and request injection traffic control. It avoids capacity prediction deviations and inaccurate rate limiting judgments caused by inconsistent delay benchmarks, and improves the rigor and operational stability of the overall scheduling logic in multi-physical-path concurrent transmission scenarios.

[0207] The technical solution of this invention obtains the target request through the request initiation module, extracts the routing flag information built into the target request to obtain the corresponding target address or target device identifier, and then determines the device interval to which it belongs based on the preset interval division rules and maps it to the corresponding physical path code. This can quickly complete the accurate correspondence and binding between the request and the transmission path, without building a complex path retrieval architecture or retrieving large-capacity stored data for line-by-line comparison and matching. This simplifies the physical path identification process and shortens the path determination time. At the same time, relying on standardized interval mapping logic to unify the path determination criteria for various types of requests can avoid the judgment deviation caused by manual path division or random path matching. This ensures that requests of different types and at different times can be accurately matched to the actual physical transmission path they flow through. This lays a solid foundation for subsequent accurate embedding of path identifiers, targeted round-trip delay statistics, and differentiation of different path transmission states. It also provides a reliable path division basis for subsequent congestion analysis and traffic control based on single path delay data, improving the regularity and identification accuracy of overall transmission management. The system generates delay statistics flags and populates them into user-defined fields of the bus request address channel. This eliminates the need for lookup operations in a large local storage table, enabling precise association between requests and their corresponding physical paths and responses. Round-trip delay timing is initiated simultaneously with sending the target request signal. When forwarding request and response signals, the physical path code and delay statistics flag in the user-defined fields are strictly maintained. By detecting the simultaneous presence of delay statistics flags and physical path codes in the response signal, the system determines the corresponding response and stops timing, quickly obtaining the accurate single-trip actual delay value of the target physical path. This improves the efficiency and accuracy of delay statistics, optimizing overall system operating efficiency and resource utilization.

[0208] Example 4

[0209] Figure 4 This is a schematic diagram of a statistical device for calculating the round-trip delay time of a request, provided in Embodiment 4 of the present invention. Figure 4 As shown, the device includes: a request acquisition module 410, a request signal module 420, a delay timing module 430, and a stop timing module 440, wherein:

[0210] The request acquisition module 410 is used to acquire the target request to be timed for round-trip delay, and to acquire the physical path code of the target physical path matching the target request based on the routing flag information carried by the target request; wherein, the physical path is the path that the request takes from being sent to the request response module via the request transmission module to being returned to the request initiating module via the request transmission module.

[0211] The request signal module 420 is used to generate a delay statistics flag that matches the target request, and fill the physical path code of the target request and the delay statistics flag into the user-defined field of the bus request address channel according to a preset bit format to obtain the target request signal.

[0212] The delay timing module 430 is used to start the round-trip delay timing for the target request at the same time as the target request signal is sent from the request initiation module. During the forwarding of the request signal through the request transmission module, the physical path code and delay statistics flag in the user-defined field remain unchanged. The request response module extracts the physical path code and delay statistics flag from the user-defined field in the received forwarded signal and fills them back into the user-defined field of the bus response channel to generate a response signal carrying the physical path code and delay statistics flag and transmits it back.

[0213] The stop timing module 440 is used to stop the round-trip delay timing for the target request if the current response signal is determined to be a response to the target request based on the current delay statistics flag and the current physical path code extracted from the received current response signal. This allows for obtaining a single actual delay value for the target physical path that matches the target request. The physical path code and delay statistics flag in the user-defined field of the bus response channel remain unchanged during the forwarding of the response signal through the request transmission module.

[0214] The technical solution of this invention obtains the target request through a request initiation module and determines the physical path code of the target physical path based on the routing flag information it carries. It then generates a delay statistics flag and fills it into a user-defined field in the bus request address channel. This eliminates the need for lookup operations in a large local storage table. By embedding the physical path code and delay statistics flag into the bus user-defined field, it achieves precise association between the request and its corresponding physical path and response, avoiding confusion in delay statistics for different paths and requests. The round-trip delay timer is started simultaneously with the sending of the target request signal, ensuring synchronization between the timing start and request transmission and guaranteeing initial timing accuracy. When forwarding request and response signals, the physical path code and delay in the user-defined field are strictly maintained. By keeping the statistical flags unchanged, the loss or corruption of flags during transmission can be effectively avoided. Furthermore, the correspondence between requests and responses can be maintained without additional table lookups. By detecting the delay statistics flags and physical path codes present in the response signal, the corresponding response is determined and the timing is stopped. This allows for accurate differentiation between the response corresponding to the target request and other responses, avoiding accidental or missed timing stops. Consequently, the accurate single-transaction actual delay value of the target physical path can be obtained quickly. This reduces the occupation of large local storage and the consumption of system hardware resources, while improving the efficiency and accuracy of delay statistics. It provides reliable data support for subsequent physical path congestion judgment and request injection control, ultimately improving the stability of on-chip system request transmission and optimizing the overall system operating efficiency and resource utilization.

[0215] Furthermore, based on the above embodiments, the statistical device for calculating the requested round-trip delay time may further include: a window allocation module and a request determination module, wherein:

[0216] The window allocation module is used to independently allocate multiple statistical time windows for each physical path;

[0217] The request determination module is used to determine the first request in any statistical time window of any physical path as the target request to be used for round-trip delay timing whenever the request initiation module issues the first request in any statistical time window.

[0218] Based on the above embodiments, the request acquisition module 410 is specifically used for:

[0219] Based on the routing flag information carried in the target request, obtain the target address or target device identifier that matches the target request; determine the target device range to which the target address or target device identifier belongs, and map the target device range to a preset physical path code, which is used as the physical path code of the target physical path that matches the target request.

[0220] Based on the above embodiments, the request signal module 420 is specifically used for:

[0221] A preset bit region is divided in the user-defined field of the write address channel or read address channel; wherein the preset bit region includes a first region and a second region; the physical path code of the target request is written into the first region, and the delay statistics flag of the target request is written into the second region to obtain the target request signal; wherein, when forwarding the request signal, the request transmission module keeps the bit values ​​of the physical path code of the first region and the delay statistics flag of the second region in the user-defined field unchanged, and sends the signal to the subsequent modules.

[0222] Based on the above embodiments, the delay timing module 430 is specifically used for:

[0223] The request-response module extracts the physical path code and delay statistics flag from the user-defined fields in the received forwarded signal. Following the same bit area format as the request address channel, it writes the physical path code into the third area of ​​the user-defined fields in the response channel and the delay statistics flag into the fourth area of ​​the user-defined fields in the response channel. This ensures the response signal carries the same physical path code and delay statistics flag as the request signal. When forwarding the response signal, the request transmission module maintains the bit values ​​of the physical path code in the third area and the delay statistics flag in the fourth area of ​​the user-defined fields unchanged before sending the signal to subsequent modules.

[0224] Based on the above embodiments, the delay timing module 430 is further used for:

[0225] Start a round-trip delay counter for the corresponding physical path of the target request, and increment the counter in units of the clock cycle of the request initiating module;

[0226] Accordingly, based on the above embodiments, the stop timing module 440 is specifically used for:

[0227] If the current delay statistics flag and the current physical path code are extracted from the received current response signal, and it is determined that the current response signal is a response to the target request, is the parsed current delay statistics flag valid? If so, the corresponding round-trip delay counter is stopped from counting based on the parsed current delay statistics flag, and the count value of the round-trip delay counter is determined as a single actual delay value of the target physical path that matches the target request in the current physical path code.

[0228] Furthermore, based on the above embodiments, the statistical device for calculating the round-trip delay time may further include: a delay averaging module and a factor update module, wherein:

[0229] The delay averaging module is used to sum the collected single actual delay values ​​and calculate the average delay value after continuously collecting a preset number of single actual delay values ​​for the same physical path.

[0230] The factor update module is used to update the current dynamic congestion factor of the matching physical path based on the calculation result obtained by dividing the average delay by the physical delay value of the matching physical path.

[0231] Furthermore, based on the above embodiments, the statistical device for calculating the round-trip delay time may further include: a path determination module, a maximum physical module, a maximum actual module, a total response module, a setting incomplete module, and a target request determination module, wherein:

[0232] The path determination module is used to parse the routing flag information carried in the current request whenever a current request to be sent is obtained, and determine the current physical path corresponding to the current request according to the preset mapping relationship between the routing flag information and the physical path.

[0233] The maximum physical module is used to obtain the physical delay value of the current physical path and predict the maximum physical capacity that the current physical path can receive responses based on the physical delay value.

[0234] The maximum actual module is used to calculate the maximum actual capacity of the current physical path to receive responses based on the current dynamic congestion factor of the current physical path and the maximum physical capacity of the current physical path to receive responses.

[0235] The total response module is used to obtain the current determined response processing capacity of the current physical path in the response buffer of the request initiation module, and to calculate the total response processing capacity of the current physical path by combining the maximum actual capacity with the current determined response processing capacity.

[0236] The "Set Incomplete" module is used to set the maximum number of incomplete requests allowed for the current physical path based on the total response processing capacity.

[0237] The target request determination module is used to count the number of incomplete requests that have been sent and have not yet received a response on the current physical path. When the number of incomplete requests is less than the maximum number of incomplete requests, the current request is determined as the target request to be subject to round-trip delay timing.

[0238] Based on the above embodiments, the request initiation module is a peripheral interface module, including a high-speed peripheral component interconnection module; correspondingly, based on the above embodiments, the statistical method for calculating the round-trip delay of the request is executed by the request injection control hardware independently configured in the peripheral interface module.

[0239] The statistical device for request round-trip delay timing provided in the embodiments of the present invention can execute the statistical method for request round-trip delay timing provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the method execution.

[0240] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0241] Example 5

[0242] Figure 5 This is a schematic diagram of the structure of a request initiation module provided in Embodiment 5 of the present invention. Figure 5 As shown, the request initiation module 510 includes request injection control hardware 520, which is used to execute a statistical method for calculating the round-trip delay of a request as described in any embodiment of the present invention.

[0243] Specifically, the request initiation module 510 is internally configured with dedicated request injection control hardware 520. This hardware circuit is designed to directly execute the round-trip delay timing statistical method for requests described in the various embodiments of the present invention in a purely hardware manner. This includes steps such as target request filtering, routing information parsing and matching physical path encoding, writing and transmitting bus custom field identifiers, round-trip delay timing start and stop control, summarizing and calculating multiple sets of delay data, dynamically updating physical path congestion factors, and filtering compliant statistical requests based on path carrying capacity.

[0244] The request injection control hardware includes a request receiving unit and a request injection control hardware controller, with the request receiving unit connected to the request injection control hardware controller. The request receiving unit receives requests aggregated from the request initiation module and sends them to the request injection control hardware controller, which executes the method described in any embodiment of the present invention.

[0245] The request receiving unit is the front-end interface unit of the request injection control hardware, used to receive and aggregate all service requests to be sent from the request initiation module. The request injection control hardware controller is the core logic unit of the request injection control hardware and is the direct execution entity of the method described in any embodiment of the present invention. The request injection control hardware consists of the request receiving unit and the request injection control hardware controller, which are interconnected. The request receiving unit receives all requests aggregated to the request initiation module and sends these requests to the request injection control hardware controller, which then executes the method described in any embodiment of the present invention.

[0246] Based on the above embodiments, the request injection control hardware may further include a scenario configuration register group. This register group is connected to the request injection control hardware controller and is used to store clock frequency information of each module and physical delay information of each physical path. The scenario configuration register group is a set of readable and writable hardware registers specifically configured for the request injection control hardware. It is a static parameter storage unit, and configuration values ​​are written to it through software or initialization processes for use by hardware logic. The physical path delay information is used to store the inherent physical delay of each physical path, i.e., the basic transmission delay of the link itself, which can be used as a benchmark reference value for congestion calculation.

[0247] A scenario configuration register group is added to the basic architecture of the request injection control hardware. This register group is connected to the request injection control hardware controller and stores the clock frequency information of each module of the system and the physical delay information of each physical path. During the execution of the method described in any embodiment of the present invention, the controller can obtain the timing reference and the inherent delay parameters of the link by reading the register group, providing standardized configuration support for round-trip delay measurement, time window management, and dynamic updating of congestion factors. By adding the scenario configuration register group, standardized and configurable timing and link reference parameters can be provided for round-trip delay timing, time window counting, and congestion factor calculation. It can adapt to application scenarios with different system architectures, different clock frequencies, and different inherent delays of links without modifying the hardware logic, improving the versatility and scenario adaptability of the request injection control hardware. At the same time, the controller unit can complete timing calibration and reference comparison by directly reading the register parameters, avoiding real-time software scheduling intervention and ensuring the accuracy, stability, and execution efficiency of delay statistics and congestion assessment.

[0248] Based on the above embodiments, the request injection control hardware may further include a delay normalization calculation hardware circuit. This circuit is connected to the request injection control hardware controller and is used to perform cross-clock domain normalization processing on the physical path delay to obtain a normalized physical delay value. The delay normalization calculation hardware circuit is a dedicated circuit for realizing unified measurement of delay across clock domains. Since the clock frequencies of different modules and different physical paths within the system may be inconsistent, the delay values ​​measured directly using their respective clock cycles cannot be compared horizontally. Therefore, this circuit performs cross-clock domain normalization conversion on the delay values ​​of different physical paths, converting the delay data measured under the local clock domain of each path into a normalized physical delay value under a unified reference clock, providing a standard measurement basis for subsequent congestion factor calculation and traffic control.

[0249] The specific implementation of delay normalization involves traversing all physical path codes, sequentially reading the clock frequency parameters and physical delay parameters of the modules traversed by each physical path, multiplying the physical delay parameter of each module by its corresponding clock frequency parameter, summing the results, dividing the sum by the clock frequency parameter of the request initiating module, and rounding the result up to obtain the normalized physical delay value for that physical path. By adding a hardware circuit for delay normalization calculation, the measurement deviation caused by the difference in local clock frequencies of each path can be eliminated, and the delay values ​​under different clock domains can be uniformly converted into standard measurement values ​​based on the same reference clock. This makes the delay data of different physical paths horizontally comparable, eliminating the need for software conversion or complex cross-clock domain synchronization logic. It can be directly used for congestion factor calculation, link load assessment, and traffic balancing scheduling, improving the accuracy, consistency, and robustness of delay statistics and control logic in multi-clock domain systems. At the same time, the hardware implementation of the conversion process avoids the overhead and lag caused by software intervention, ensuring the real-time performance and stability of request injection control.

[0250] Based on the above embodiments, the request injection control hardware may further include a response buffer capacity statistics hardware circuit. This circuit is connected to the request injection control hardware controller and is used to count the current determined response processing capacity of the response buffer. The response buffer capacity statistics hardware circuit is used to monitor and count the status of the response buffer in real time. It can count the idle capacity and load status of the response buffer in real time, determine the number of response messages it can currently receive and process, i.e., the current determined response processing capacity, and provide real-time feedback for the request injection control hardware controller's traffic management and request injection strategy.

[0251] The specific statistical rules are as follows: whenever a response corresponding to the target physical path is written to the response buffer, the current determined response processing capacity is decremented by 1; whenever a response corresponding to the target physical path is read from the response buffer, the current determined response processing capacity is incremented by 1. By adding this hardware circuit, the request injection control hardware controller can provide direct and accurate feedback on the backend processing capacity, enabling the controller to dynamically adjust the request injection rate and the number of concurrent requests based on the real-time capacity of the buffer. This avoids message loss, processing blockage, or system deadlock caused by response buffer overflow. Without relying on software polling or complex cross-module state synchronization, closed-loop traffic control based on the actual backend processing capacity can be achieved, improving the adaptability, stability, and overall system throughput efficiency of request injection in multi-physical path concurrent transmission scenarios.

[0252] Based on the above embodiments, the request injection control hardware may further include an incomplete request counting hardware circuit. This circuit is connected to the request injection control hardware controller and is used to count the number of incomplete requests on the target physical path and perform addition, subtraction, and updates. The incomplete request counting hardware circuit is a logic circuit designed for real-time counting of the number of requests sent but not yet responded to on the target physical path. It can count the number of requests sent but not yet responded to on each target physical path in real time, and automatically perform addition, subtraction, and updates when a request is sent and a response is received, providing the controller unit with real-time quantitative data on the current load status of each path.

[0253] By adding a hardware circuit for counting incomplete requests, the number of incomplete requests for each target physical path can be counted in real time at the hardware level. The count is automatically added or subtracted during request sending and response receiving, without relying on software polling or cross-module synchronization. This provides the controller unit with accurate and low-latency path load status feedback, enabling the request injection control logic to dynamically adjust the traffic injection rate based on the current number of incomplete requests for each path. This avoids path request queue overflow, transmission congestion, and exhaustion of response buffer resources, improving the real-time performance, accuracy, and system stability of request traffic management in high-concurrency multi-path scenarios. At the same time, the hardware implementation of the counting and updating process eliminates the latency and errors caused by software intervention, ensuring the efficient closed-loop operation of the request injection control logic.

[0254] Based on the above embodiments, the request injection control hardware may further include a request transmission control hardware circuit. This circuit is connected to the request injection control hardware controller and is used to output a request transmission allow or prohibit signal based on the comparison result between the number of incomplete requests and the maximum number of incomplete requests. The request transmission control hardware circuit is a hardware management unit used to determine whether to allow the current request to be transmitted. The request transmission allow or prohibit signal is an enable control signal output by the hardware circuit based on the comparison result, which directly controls whether to allow the current request to initiate transmission.

[0255] This hardware circuit can acquire the number of incomplete requests and the preset maximum number of incomplete requests for each target physical path in real time. By comparing these two values, it outputs a request sending allow signal or a request sending prohibit signal based on the comparison result. This hardware-based access control for whether a request is allowed to be sent is implemented. For example, when the number of incomplete requests is less than the maximum number of incomplete requests, the current request is identified as a target request to be subject to round-trip delay timing. By adding this hardware circuit, the number of concurrent requests on each physical path can be limited and access constrained at the hardware level, avoiding the accumulation of incomplete requests on a single physical path, queue overflow, and bus congestion. No software intervention is required for decision-making and scheduling. The response speed is fast, the decision timing is regular, and dynamic throttling and flow control can be implemented according to the real-time load of each path, ensuring load balancing and system throughput stability for concurrent request transmission on multiple physical paths. At the same time, it forms a closed-loop linkage control with the incomplete request counting hardware circuit, enabling pure hardware autonomous decision-making, real-time constraints, and reliable rate limiting throughout the request injection process.

[0256] Optionally, based on the above embodiments, the request injection control hardware controller may include a destination address or target device identifier parsing hardware circuit and a physical path matching hardware circuit. The destination address or target device identifier parsing hardware circuit is connected to the physical path matching hardware circuit and is used to parse the request address and match it to obtain the target physical path code. The destination address or target device identifier parsing hardware circuit is used to extract and parse key routing information such as the destination address and the unique identifier of the target device from the received request message as the original input for path matching; the physical path matching hardware circuit has a pre-set mapping table between the address or device identifier and the physical path code, and according to the parsed address or device identifier, it looks up the table to match and output the unique corresponding target physical path code.

[0257] The two hardware circuits within the request injection control hardware controller are interconnected and work together. The destination address or target device identifier resolution hardware circuit parses the destination address or target device identifier of the request, and then sends it to the physical path matching hardware circuit. Route matching is completed through preset mapping rules, and finally the target physical path code corresponding to the current request is parsed and matched. By setting these two cascaded hardware circuits inside the controller, request address parsing and physical path code matching are completed automatically in a hardware pipeline manner. No software is required to participate in address translation and path lookup. The parsing and matching latency is low and the throughput is high. It can quickly complete the path assignment of a large number of concurrent requests in real time, providing accurate physical path code basis for subsequent latency statistics, incomplete request counting, request sending rate limiting, and congestion factor calculation. At the same time, the parsing and matching logic is hardware-based and fixed. The rules are configurable and adaptable to multi-device and multi-path networking scenarios, improving the real-time performance, parallel processing capability, and architectural versatility of the entire request injection control system.

[0258] The request injection control hardware of this invention is divided into an interconnected request receiving unit and a request injection control hardware controller. The request receiving unit uniformly aggregates requests from the request initiation module and forwards them to the controller unit. The request injection control hardware controller then fully executes the method described in any embodiment of this invention, achieving hardware decoupling between the request receiving path and the control logic. The request receiving unit is responsible for request access and distribution, while the controller unit is responsible for core logic such as path matching, latency statistics, congestion factor updates, and traffic management. This simplifies the complexity of hardware design and facilitates the logic iteration and expansion of the controller unit. The entire request injection control process can be executed in a closed loop using a hardware-based, fixed approach, without relying on software scheduling, reducing system overhead, while ensuring the real-time performance, timing stability, and management efficiency of request injection control in high-concurrency scenarios.

[0259] By integrating request injection control hardware within the request initiation module to independently execute round-trip delay timing and statistics methods, all business logic, including path identification, identifier encapsulation, delay counting, data aggregation, congestion factor updates, and request sending control, can be solidified in dedicated hardware circuits. This eliminates the need to occupy the operating resources of the on-chip system's main processor and various general-purpose computing units, offloading the high-concurrency request processing pressure on the interface side and reducing the scheduling burden on the core control unit. Simultaneously, relying on hardware-based parallel processing mechanisms, the execution speed of various processes can be improved, shortening the response time for request identification, delay statistics, and traffic control. This aligns with application scenarios involving high-frequency data interaction between peripheral interfaces under the multi-module asynchronous clock operation architecture of the on-chip system. It allows for end-to-end control at the request origin, avoiding delay fluctuations and operational overhead caused by software-based layer-by-layer parsing and judgment. This ensures both the real-time and accuracy of round-trip delay statistics collection and enables fine-grained hardware-level control of request injection rhythm. It alleviates the response accumulation and backpressure transmission problems caused by insufficient interface processing capacity from the source, further optimizing the overall data transmission order of the on-chip network and improving system data interaction efficiency and long-term operational stability.

[0260] Example 6

[0261] Figure 6 This is a schematic diagram of a system-on-a-chip provided in Embodiment Six of the present invention. Figure 6 As shown, the system-on-chip 610 includes a request initiation module 620 as described in any embodiment of the present invention, at least one request transmission module (such as request transmission module 1, 630 and request transmission module N, 640, etc.) and a request response module 650.

[0262] Specifically, the system-on-a-chip consists of a request initiation module integrating request injection control hardware, a request transmission module that can be configured as one or more levels, and a request response module connected in sequence. The request initiation module can be a peripheral interface module with a high-speed peripheral component interconnect express (PCIe) interface, which can actively generate and send read and write requests. The request transmission module can be an on-chip network (NoC) switch, used for forwarding and routing requests and responses, and can be configured as one or more levels in series (such as module 1 to module N) depending on the system scale. The request response module is a terminal processing module such as a storage controller or computing unit, such as a double data rate synchronous dynamic random access memory control module, used to receive requests and return responses. After the request is sent from the request initiation module, it is routed to the request response module through one or more request transmission modules. After the request response module completes its processing, it sends the response back along the original physical path and finally returns to the request initiation module, forming a fixed and bidirectional physical transmission path, which provides the hardware architecture foundation for round-trip delay statistics, physical delay normalization, dynamic congestion factor updates, and request injection rate limiting.

[0263] In a specific example, the system structure from the issuance of a request to the return of its corresponding response may include a PCIe module, which connects upwards to a NOC 1 module, and the NOC 1 module further connects upwards to a NOC 2 module, with the DDR module at the top. It is understood that multiple NOC modules can be connected in between; this embodiment of the invention uses only two as an example and is not intended to limit the scope.

[0264] In this process, the PCIe module's request port sends a request signal upwards, which passes sequentially through the request ports of NOC 1 and NOC 2 modules, finally reaching the DDR module's request port. The DDR module processes the request and generates a response signal, which is then sent downwards from its response port, passing sequentially through the response ports of NOC 2 and NOC 1 modules, finally reaching the PCIe module's response port, thus achieving a closed-loop transmission of request and response. The PCIe module is the first-level module, i.e., the request initiation module, containing a request sending module and a response receiving module. Its request sending module acts as the request source, sending the request to NOC 1 (the second-level module), and its response receiving module acts as the response destination, receiving the response from NOC 1. NOC 1 is the second-level module (request transmission module). Its request sending module receives the request from the first-level module and forwards it to NOC 2 (the third-level module), while its response receiving module receives the response from NOC 2 and forwards it to the first-level module. NOC 2 is the third-level module (request transmission module). Its request sending module receives requests from NOC 1 and forwards them to DDR, which is the nth-level module. Its response receiving module receives responses from DDR and forwards them to NOC 1. DDR is the nth-level module (request response module). Its request sending module receives and processes requests from the preceding NOC 2, and its response module generates corresponding responses and sends them to the preceding NOC 2. The modules achieve bidirectional signal transmission through the request and response paths.

[0265] In a specific example, a four-level module signal transmission system architecture can consist of four sequentially connected modules, from bottom to top: Level 1 module, Level 2 module, Level 3 module, and Level 4 module. In the request transmission path, the request sending module of Level 1 sends the request to Level 2 module, Level 2 module receives the request and forwards it to Level 3 module, Level 3 module receives the request and forwards it to Level 4 module, and Level 4 module processes the request from the previous level and generates the corresponding response signal. In the response transmission path, the response generated by Level 4 module is returned to Level 3 module via its response receiving module, Level 3 module receives the response and forwards it to Level 2 module, Level 2 module receives the response and forwards it to Level 1 module, and Level 1 module receives the response from the previous level and processes it.

[0266] In a specific example, the overall signal transmission structure on the request and response paths can be divided into two paths: the request sending path, which is arranged from bottom to top as request sending module 1, request sending module 2, request sending module 3, and request sending module n, with the request being transmitted upwards from the first-level module to the nth-level module; and the response return path, which is arranged from top to bottom as response return module n, response return module 3, response return module 2, and response return module 1, with the response being transmitted downwards from the nth-level module to the first-level module. Specifically, the request originates from the first-level module (request sending module 1, i.e., the request initiating module), passes through request sending module 2 and request sending module 3 (i.e., at least one level of request transmission modules), and finally reaches request sending module n (i.e., the request response module). The nth-level module processes the request and generates a response, which then passes through response return module 3 and response return module 2, finally returning to the first-level module (response return module 1). Furthermore, different requests originating from the first-level module may have different physical modules traversed by the request sending path and response return path, reflecting the characteristic that different requests may have different physical paths from origination to response return.

[0267] In a specific example, signal transmission can have different physical paths, such as three physical paths, which may include PCIe modules, NOC modules, and DDR modules (DDR1, DDR2, DDR3). The PCIe module contains request buffer 1 and response buffer 1. The NOC module contains request buffers 3, 4, 5, 6, 7, and 8, and response buffers 3, 4, 5, 6, 7, and 8, as well as two arbitration units. The DDR1 module contains request buffer 9 and response buffer 9, the DDR2 module contains request buffer 10 and response buffer 10, and the DDR3 module contains request buffer 11 and response buffer 11. There are three physical paths from the PCIe module request buffer 1 to the PCIe module response buffer 1: the first path is the path to DDR1, where the PCIe module request buffer 1 enters request buffer 5 after passing through the arbitration unit of the NOC module, then sequentially passes through request buffer 6 and request buffer 8, and finally reaches the DDR1 request buffer 9. The first path is for accessing DDR2: after processing the request, it returns via response buff 9, then passes through response buffs 8, 7, and 3 of the NOC module, finally reaching the PCIe module's response buff 1 via the arbitration unit. The second path is for accessing DDR2: the PCIe module's request buff 1 passes through the NOC module's arbitration unit and enters request buff 4, then passes through request buff 7, reaching DDR2's request buff 10. DDR2 processes the request and returns via response buff 10, then passes through response buffs 6 and 4 of the NOC module, finally reaching the PCIe module's response buff 1 via the arbitration unit. The third path is for accessing DDR3: the PCIe module's request buff 1 passes through the NOC module's arbitration unit and enters request buff 3, reaching DDR3's request buff 11. DDR3 processes the request and returns via response buff 11, then passes through response buffs 5 of the NOC module, finally reaching the PCIe module via the arbitration unit. The module response buff1 fully presents the signal flow of the three different request-response transmission physical paths and the connection relationship of each buffer unit and arbitration unit.

[0268] Understandably, the latency of requests and responses along the physical path can be divided into physical latency and actual latency. The physical latency of a physical path is typically represented by the number of register cycles traversed and the clock frequency at which the path operates. For each physical path, the number of register cycles traversed is fixed during physical design. Different physical paths can have different physical latencies. Furthermore, although all physical paths from request issuance to response return are determined during physical design, their corresponding clock frequencies may differ in different application scenarios, leading to different physical latencies for the same physical path at different clock frequencies. For simplicity, within the same level module, the request sending module and response receiving module of its internal instances use the same clock frequency. The clock frequencies of the first-level module, second-level module, ..., nth-level module are denoted as F1, F2, ..., Fn, respectively. However, in real system architecture design, the design of modules at the same level does not strictly restrict the request sending module and response receiving module to use the same clock frequency; it only increases the number of 'n' without affecting the underlying principle. Similarly, the same physical module can also operate at different clock frequencies, such as NOC2. The module can place some logic in NOC1, allowing NOC1 to physically operate on two different clock domains. This only increases the number of 'n', without affecting the underlying principle. In different application scenarios, F1, F2, ..., Fn can each operate at multiple different frequency points. For example, in the physical path of PCIe requests accessing DDR1, when the PCIe module is running at PCIe Gen5 (IO bandwidth 32Gbps), the corresponding clock frequency F1 is 1GHz. When switching application scenarios and running at PCIe Gen4 (IO bandwidth 16Gbps), the clock frequency F1... The clock frequency can be reduced to 0.5GHz. In both scenarios, the number of register cycles traversed by the request and response is the same, but the clock frequency is different, resulting in different physical delays. Actual delay refers to the actual delay used from the time the request is sent to the time the response is returned. In real systems, it is generally not fixed and is dynamically variable in different application scenarios. Actual delay is determined by a function of physical delay and the instantaneous congestion level of the physical path in the system. It can vary depending on the physical path and its clock frequency. Even if the same physical path is running at the same clock frequency, it will vary depending on the instantaneous congestion level of the system. In this paper, the congestion level of the physical path is represented by the congestion factor (Congestion_coeff). The congestion factor (Congestion_coeff) of each physical path is a dynamic independent variable that is dynamically updated during operation. Initially, the value is usually 1, indicating that no congestion has occurred. The value changes dynamically during system operation, and the smaller the value, the more severe the congestion.

[0269] In a specific example, the request injection hardware architecture can include two processing links: request and response. It also includes multiple processing units such as preset clock frequencies for each module, physical latency for all physical paths, congestion factor management, response processing capacity, and the number of incomplete requests. In the request processing link, the "preset clock frequencies for each module" unit and the "preset physical latency for all physical paths" unit first output configuration information to the "normalized physical latency value for all physical paths" unit. The output of this unit, along with the output of the "physical path corresponding to the request" unit, is sent to a "selector" that outputs the "physical latency value of the physical path corresponding to the request." This value, along with the corresponding path congestion factor output by the congestion factor management unit, is sent to subsequent processing units. The "physical latency value of the physical path corresponding to the request" first calculates the "maximum physical capacity that the i-th physical path corresponding to the current request can receive a response from," and then combines this with the congestion factor to calculate the "maximum actual capacity that the i-th physical path corresponding to the current request can receive a response from." Simultaneously, The output of the "response processing capability of the determined part of each physical path" unit and the "maximum actual capability of the physical path corresponding to the current request to receive the response" are sent to the "selector" to output the "total response processing capability of the physical path corresponding to the current request", and then obtain the "maximum number of uncompleted requests allowed for the current physical path"; in the response processing link, the output of the "physical path corresponding to the response" unit is sent to the "number of uncompleted requests of each physical path" unit, and its output and the "maximum number of uncompleted requests allowed for the current physical path" are sent to the "selector" together. Finally, all relevant information is summarized to the "judgment and control whether to allow the request to be sent" unit, and the final control signal is output; among them, the clock frequency of each level module is determined by the system configurable register Cfg_F[j] (representing the frequency of different level modules, for example, Cfg_F[2]=10 can indicate that the clock frequency of the second level module is 1GHz (different configurable register level values ​​correspond to different clock frequencies, for example, 10 corresponds to 1GHz). The frequency (F1, F2, ..., Fn) of each module is configured in these registers when starting or switching application scenarios, and the frequency values ​​of each module are configured in these registers to represent the corresponding frequency information. The entire architecture fully presents the hardware processing logic of the entire process from request and response input to request sending control, covering all aspects of physical delay normalization, congestion factor management, response processing capacity calculation, incomplete request count statistics and final request sending decision.

[0270] In a specific example, the system-configurable registers may include a register bus area containing signal interfaces such as read address, read data, write enable, write address, and write data, as well as read address decoding units, write enable and write address decoding units; and a register area containing registers Cfg_F1, Cfg_F2, and Cfg_F3 (Cfg_F1 corresponds to the first-level module clock frequency register, Cfg_F2 corresponds to the second-level module clock frequency register, and Cfg_F3 corresponds to the third-level module clock frequency register); wherein, the read address signal is input to the read address decoding unit, and the read address decoding unit reads the data from Cfg_F1, Cfg_F2, and Cfg_F3 according to the address information. Data is read from _F3 and a read data signal is output. The write enable, write address, and write data signals are input to the write enable and write address decoding unit. This unit generates write enable 1, write enable 2, and write enable 3 signals based on the write address information, which control the write operations of Cfg_F1, Cfg_F2, and Cfg_F3 respectively, writing the write data to the corresponding registers. The output signals cfg_F1, cfg_F2, and cfg_F3 of Cfg_F1, Cfg_F2, and Cfg_F3 are directly used by the relevant hardware modules. The system can perform read or write operations on these clock frequency registers through the register bus, fully presenting the configuration and access hardware logic of the clock frequency registers of each module.

[0271] In a specific example, the physical implementation of the register may include a multi-input selector, whose input signals include a reset value, write data, and a feedback signal from the register output Q, and whose control signals are reset and write enable; and a register, including a D input, a Clk (clock) input, and a Q output; wherein, the selector selects the output signal based on the combination of the reset signal and the write enable signal: when the reset is valid, the reset value input is selected; when the write enable is valid, the write data input is selected; when both are invalid, the feedback signal at the register Q is selected. The output of the selector is connected to the D input of the register; the register latches the signal at the D input to the Q output on the rising edge (or valid edge) of the clock signal Clk, and at the same time, the Q signal is used as the register output signal on one side and fed back to the selector on the other side to realize the register's hold, reset, and write operation functions.

[0272] In a specific example, physical delay registers for all physical paths configurable by the system are implemented. This hardware can consist of a register bus, a register set Info-A, a selector, and an Index_B address generator. The register bus area includes interfaces for read data, read address, write enable, write address, and write data signals, as well as read address decoding units and write enable and write address decoding units. The read address signal is input to the read address decoding unit, which reads data from registers 1, 2, and 3 and outputs a read data signal. The write enable, write address, and write data signals are input to the write enable and write address decoding unit, which generates the write address signal. Enable 1, write enable 2, and write enable 3 signals control the write operations of registers 1, 2, and 3 respectively, writing the data to the corresponding registers; the register set Info-A contains registers 1, 2, and 3, where register 1 stores the physical delay parameters of each level of the first physical path {F1_path_latency[1], F2_path_latency[1], F3_path_latency[1]}, and register 2 stores the physical delay parameters of each level of the second physical path {F1_path_latency[2], F2_path_latency[3]}. h_latency[2], F3_path_latency[2]}, register 3 stores the physical delay parameters of each level of the third physical path {F1_path_latency[3], F2_path_latency[3], F3_path_latency[3]}, and the values ​​of these registers can be directly output to the selector; the selector is controlled by the Index_B signal output by the Index_B address generator, and selects the delay parameters of the corresponding physical path from register 1, register 2, and register 3 according to the index signal, and finally outputs the modules of each level of the physical path. Physical delay information {F1_path_latency[i], F2_path_latency[i], F3_path_latency[i]}, for example, F2_path_latency[1]=6 indicates that the delay of the first physical path in the F2 clock domain is 6 F2 clock cycles. When the system starts or switches application scenarios, the values ​​of these registers can be configured through the register bus. In the case of many physical paths or dynamic routing scenarios, the design can be simplified by merging the delay information of similar paths. The hardware implementation logic of configuring, storing and indexing physical path delay parameters is presented.

[0273] In a specific example, a hardware implementation of normalized delays for three physical paths is achieved, which can be composed of a register area and an arithmetic area. The register area contains three parts: the first part is the clock frequency registers Cfg_F1, Cfg_F2, and Cfg_F3; the second part is the physical path delay set Info-A, containing registers 1, 2, and 3, which store the delay parameters {F1_path_latency[i], F2_path_latency[i], F3_path_latency[i], and F3_path_latency[i]} of each level of the modules in the first, second, and third physical paths, respectively. The third part is the scene control register, which includes the scene switching enable, physical path count register, and clock and reset signals; the Index_B address generator receives the scene switching enable, physical path count, clock and reset signals, generates the Index_B signal and sends it to the selector. The selector reads the delay parameters {F1_path_latency[i], F2_path_latency[i], F3_path_latency[i]} of the corresponding physical path from Info-A according to Index_B; in the operation area, Cfg_F1, Cfg _F2 and Cfg_F3 are respectively fed into the multiplier with the corresponding delay parameters to complete the multiplication operation. The output of the multiplier is fed into the adder for summation, and then divided by Cfg_F1 by the divider. After that, it is fed into the ceiling (rounding up) operation to perform the ceiling operation. Finally, the normalized delay values ​​of the 1st, 2nd and 3rd physical paths, Dynamical_Normalized_Latency[1], Dynamical_Normalized_Latency[2], and Dynamical_Normalized_Latency[3] (e.g., D) are output. ynamical_Normalized_Latency[2]=20 indicates that the delay of the second physical path is 20 F1 clock cycles (this refers to the result normalized to the F1 reference). When the system resets or switches application scenarios to reconfigure Cfg_F[j], it will trigger the Index_B address generator to traverse all physical paths by configuring the switching scenario enable and the physical path number register, complete the normalized delay calculation and store it, and keep the calculation result at other times. This presents the hardware implementation logic of cross-clock domain normalized delay calculation based on multi-level clock frequency and physical path delay.

[0274] In a specific example, the address generator can consist of an adder, a selector, a register, and conditional control logic. The adder receives the value 1 and the feedback signal from the Q terminal of the register, and outputs the addition result to one input port of the selector, while the value 0 is directly input to the other input port of the selector. The conditional control logic receives reset, scene switching enable, and physical path quantity signals, and outputs a control signal to the selector, controlling it to select either the addition result or the value 0 as the output. The output of the selector is connected to the D input of the register, and the Clk input of the register receives the clock signal. On the effective edge of the clock, the D input signal is latched to the Q terminal. One path of the Q terminal signal serves as the output signal of the address generator, and the other path feeds back to the adder, realizing the function of incrementing the address by 1 or resetting it to zero.

[0275] In a specific example, the hardware implementation for obtaining the delay value of physical path matching can be composed of a physical path delay set and a matching processing unit; the delay normalization value storage unit of the three physical paths includes the delay normalization value of the first physical path Dynamic_Normalized_Latency[1], the delay normalization value of the second physical path Dynamic_Normalized_Latency[2], and the delay normalization value of the third physical path Dynamic_Normalized_Latency[3]; the matching processing unit first receives the destination address information carried in the request from the "destination address resolution" module, resolves it to obtain the physical path value i corresponding to the request, and then sends the value to the "physical path value i corresponding to the request" module to generate The index signal Index_B1 is sent to the selector. The selector receives the normalized delay values ​​of the three physical paths and the Index_B1 signal, selects the normalized delay value of the corresponding physical path according to the index, and finally outputs the normalized delay value Req_Normalized_Latency of the physical path corresponding to the request. Specifically, when the address carried by the request falls within the DDR1 addressing range, Index_B1 is 0, and the normalized delay value of the first physical path is used; when it falls within the DDR2 addressing range, Index_B1 is 1, and the normalized delay value of the second physical path is used; when it falls within the DDR3 addressing range, Index_B1 is 2, and the normalized delay value of the third physical path is used. This presents the hardware implementation logic of matching the physical path by parsing the destination address information of the request and obtaining the corresponding normalized delay value.

[0276] In a specific example, the process of determining the maximum actual capacity can be divided into two calculation links: the first link is used to calculate the maximum physical capacity, and the second link is used to combine the congestion factor correction to obtain the maximum actual capacity; wherein, the register module contains the configurable register RspAccepted_Cap_F1 (representing the number of responses that the response module of the first module can receive in each F1 clock cycle) and the physical path delay normalization value Req_Normalized_Latency corresponding to the request. After the two are input into the multiplier, the maximum physical capacity Resp_PredictedCapacity_Current_max that the i-th physical path corresponding to the current request can receive is output; in the second link, the congestion factor Congestion_coeff[1] of the 1st, 2nd and 3rd physical paths is calculated. The input selector is Congestion_coeff[2] and Congestion_coeff[3]. The output selector outputs the congestion factor of the physical path corresponding to the request, which is controlled by the physical path value i corresponding to the request. Then, it is input into the multiplier together with Resp_PredictedCapacity_Current_max output by the first link, and finally the maximum actual capacity Resp_PredictedCapacity_Current that the i-th physical path corresponding to the current request can receive is obtained. The hardware realizes physical prediction and congestion correction of the physical path response receiving capacity through the configurable RspAccepted_Cap_F1 register, the normalized value of the request path delay and the dynamically updated congestion factor, and presents the calculation logic of the maximum actual response capacity.

[0277] In the first-level module, congestion factors (Congestion_coeff[i]) are allocated and dynamically updated separately for different physical paths (e.g., the i-th path). A register is deployed for each physical path to store the corresponding congestion factor. The initial value can be configured during system initialization or application scenario switching, and updated according to the status during runtime. At the same time, the congestion statistics time of each physical path i is divided into multiple consecutive statistical time windows (Window_T[j]). The hardware allocates a statistical time window counter Counter_W[i] running at the F1 clock frequency for each physical path. This counter starts from 1 and increments every clock cycle. After reaching the window length preset by the configurable register Cfg_W[i], it restarts from 1. If there are many physical paths, several paths can also share a statistical time window. Within each statistical time window, only the "request sent - response returned" delay value (Statistics_latency[i][j], where j refers to the j-th statistical time window, used to distinguish multiple consecutive statistical periods under the same physical path) of the first request is counted. Requests that do not require latency statistics are counted. The latency value starts counting when the first-level module sends a request, incrementing every F1 clock cycle until a corresponding response is received. The hardware implements Max latency statistics counters (Timer_L) for each physical path, used in a sequential loop. The minimum value of Max is determined by the maximum number of outstanding requests for that physical path and the minimum available length of the statistical time window. In the sending module of the first-level module, a statistical flag S_Flag is generated for requests requiring latency statistics, and this flag, along with the physical path information i, is sent along with the request. When the response is returned, these two pieces of information are brought back. The response module identifies the path to which the physical path i belongs through the physical path i carried in the response and stops the corresponding delay count through S_Flag. After obtaining a preset number (Cfg_N[i]) of delay values, these delay values ​​are added together and divided by Cfg_N[i], and then divided by the delay normalization value (Req_Normalized_Latency[i]) of the physical path to finally obtain the congestion factor Congestion_coeff[i] of the path, so as to reflect the dynamic congestion degree of different physical paths at different times.

[0278] In a specific example, the implementation process of dynamically adjusting the congestion factor of a physical path can be as follows: the input information may include the Cfg_W parameter (derived from the statistical time window length configuration register), the request issued by physical path i ("request issued"), the response returned by physical path i ("response returned"), Cfg_N[i] (derived from the delay statistics configuration register), and the delay normalization value Req_Normalized_Latency[i].First, Counter_W (a statistical time window counter) runs at a clock frequency of F1, incrementing by 1 every clock cycle. After reaching the preset value of Cfg_W, it loops back to count and outputs to the Timer_L start-counting control module. This module contains a status register A. When Counter_W is 0, A is set to 0; when A is 0 and Counter_W is less than Cfg_W, and the request is valid, A is set to 1. Otherwise, the value of A remains unchanged. As A increases from 0 to 1, it increments sequentially according to the arrangement of the Timer_Ls and loops back to trigger the "start counting" signal of the m-th Timer_L[m]. Assume there are four groups of Timer_Ls, m=1,2,3,4, and Tim... The internal status register x of the Timer_L start counting control module is initially set to 1, and increments or loops back each time A changes. The Timer_L stop counting control module includes a physical path register B. When receiving a response return signal, the Timer_L stop counting control module checks whether the physical path information carried in the response is the same as B. If they are different, no processing is performed. If they are the same, it continues to check whether the S_Flag (delay count end flag) carried in the response is valid. If invalid, no processing is performed. If valid, the internal status register C is set from 0 to 1 and then back to 0. When C changes from 0 to 1, the m-th Timer_L[m] "stop counting" signal is triggered sequentially and loops back. The internal status register q of the stop counting control module is initially set to 1. It increments or loops back each time C transitions, simultaneously transmitting the C transition information to the Timer_L read enable module (referred to as read enable). The Timer_L read enable module contains a counter D for the number of completed delay statistics and a current header Timer_L counter sequence number register E. D is initially set to 0 and increments by 1 each time C transition information is received. When D is greater than Cfg_N, D is subtracted from Cfg_N, triggering the Timer_L read enable for Cfg_N consecutive sequence numbers. The sequence number starts from the value of E, which is initially set to 1. After triggering the read, it is incremented by Cfg_N or loops back. The middle four groups of Timer_L counting units (Ti) mer_L[1] to Timer_L[4]), each Timer_L counting unit has a built-in counter F, with an initial value of 1. It increments when it receives the "start counting" signal, stops when it receives the "stop counting" signal, and returns to the initial value when it receives the "read enable" signal. The selector of each Timer_L counting unit outputs the value of F when the read enable is valid, otherwise it outputs 0. The adder receives the delay values ​​output by 4 groups of Timer_L and sums them. The result is divided by Cfg_N and then by Req_Normalized_Latency[i] in sequence by the divider, and finally outputs the congestion factor Congestion_coeff of physical path i.

[0279] In the process of statistically analyzing the delay information from request to response for a single physical path, two judgments are required on the returned response: first, identifying the physical path information to which the response belongs; and second, determining whether the response belongs to a response type that can be used for delay statistics. This invention proposes a corresponding implementation method. In the sending module of the first-level module, for requests requiring delay statistics, a flag S_Flag is generated to identify whether they participate in delay statistics, along with the corresponding physical path information i. This flag and physical path information are sent along with the request. When the nth-level module returns a response, these two types of information are then sent back to the first-level module. The response module of the first-level module can then assign the request to the corresponding physical path based on the physical path information i carried in the response, and use the statistical flag S_Flag to control the stopping of the delay count from request to response return.

[0280] The existing AXI bus protocol does not natively define physical path information and delay statistics flag S_Flag fields in its request and response fields. The response receiving module of the first-level module receives responses from different physical paths through the AXI bus interface. Responses from different physical paths are prone to being returned out of order on the AXI bus, making it impossible for the receiving module to directly determine the physical path corresponding to the current response. At the same time, not all responses have delay statistics attributes. For example, only the first request within a single statistical time window needs to have its delay counted, while other requests do not need to participate in the statistics. Therefore, it is necessary to customize the transmission rules based on the existing AXI bus protocol to realize the hardware generation, sending, transmission, and parsing of physical path information and delay statistics flag information.

[0281] The AXI bus contains five standard transmission channels: AW, which is mainly used to transmit the address and control information corresponding to write requests. Typical signals include AWADDR (Write Address Address), AWLEN (Write Address Length), AWSIZE (Write Address Size), AWBURST (Write Address Burst), AWID (Write Address Identification), AWVALID (Write Address Valid), AWREADY (Write Address Ready), and the user-defined AWUSER signal, which allows for customizable bit width and content.

[0282] The transmission direction is from the master device to the slave device. Typical signals used to carry write data include WDATA (WriteData), WSTRB (Write Strobe), WLAST (Write Last), WVALID (Write Valid), WREADY (Write Ready), and the customizable WUSER (Write User).

[0283] Typical signals used to initiate read requests and transmit address and control information include ARADDR (Read Address Address), ARLEN (Read Address Length), ARSIZE (Read Address Size), ARBURST (Read Address Burst), ARID (Read Address Identification), ARVALID (Read Address Valid), ARREADY (Read Address Ready), and the customizable ARUSER (Read Address User).

[0284] Typical signals used to return the results of write operations include BRESP (Write Response Response), BID (Write Response Identification), BVALID (Write Response Valid), BREADY (Write Response Ready), and customizable BUSER user-defined signals.

[0285] The transmission direction is from the slave device to the master device. Typical signals used to return read operation data and response information include RDATA (Read Data), RRESP (Read Response), RLAST (ReadLast), RID (Read Identification), RVALID (Read Valid), RREADY (Read Ready), and the customizable RUSER signal.

[0286] The code NEW_A corresponding to the physical path information set is predefined, and the flag code NEW_B representing whether the request participates in the delay statistics is also defined. First, the request sending module of the first-level module matches and determines the corresponding physical path and obtains the corresponding NEW_A code based on the physical path identifier information Info_C carried in the request. Then, it generates a flag S_Flag based on whether delay statistics are needed and matches and obtains the corresponding NEW_B code.

[0287] On the first-level module sending module side, for write requests, fixed dedicated bits are allocated in the AXI write address channel's AWUSER user-defined signal, and the physical path code NEW_A and statistical flag code NEW_B are assigned to the corresponding bits and sent together with the entire AW module; for read requests, fixed dedicated bits are allocated in the AXI read address channel's ARUSER user-defined signal, and after writing the NEW_A and NEW_B codes, they are transmitted with the AR module; the bus from the first-level module sending module to the destination request receiving module and all intermediate modules retain the same fixed bit definitions in AWUSER and ARUSER, and transmit the relevant channel signals carrying NEW_A and NEW_B codes transparently without modifying the content.

[0288] After receiving the write address channel and read address channel signals and completing the request processing, the request module of the Nth level module performs response-side information backfilling: For write requests, the corresponding NEW_A and NEW_B codes are written into the fixed bits of the BUSER user-defined signal of the AXI write response channel; for read requests, the corresponding NEW_A and NEW_B codes are written into the fixed bits of the RUSER user-defined signal of the AXI read data channel; when the response module of the Nth level module sends back the response, it synchronously sends the configured BUSER and RUSER signals as components of the write response channel and read response channel, respectively.

[0289] The bus and intermediate modules between the Nth-level module response module and the first-level module response receiving module also use the same fixed bit rules in BUSER and RUSER to transparently transmit response channel signals carrying NEW_A and NEW_B codes. Finally, the first-level module response receiving module parses the BUSER signal of the AXI write response channel and the RUSER signal of the read data channel to extract the NEW_A and NEW_B codes. The physical path information corresponding to the response is obtained by parsing the NEW_A code, and the S_Flag delay statistics flag information is obtained by parsing the NEW_B code, thereby realizing the physical path identification and delay statistics enable determination of the response.

[0290] Figure 7 This is a schematic diagram illustrating the format of the physical path encoding and delay statistics flag defined for each channel in an embodiment of the present invention. As shown in the figure, for the physical path encoding NEW_A and the statistical delay flag NEW_B defined for each AXI channel AWUSER, ARUSER, BUSER, and RUSER, each user signal field is divided into three parts: the physical path encoding NEW_A, the statistical delay value flag encoding NEW_B, and other user information for the channel. Among them, the AWUSER field carries the physical path and delay statistics information of the write request, the ARUSER field carries the corresponding information of the read request, the BUSER field transmits the path and statistical flag information of the write response, and the RUSER field transmits the path and statistical flag information of the read response. The NEW_A and NEW_B of all channels adopt the same bit allocation rule to ensure that the physical path information and delay statistics flag remain consistent in the request and response transmission link, while retaining other information bit fields of the user signal, without affecting the compatibility of the original AXI bus protocol.

[0291] Figure 8 This is a schematic diagram illustrating the generation of physical path code and delay statistics flag in the first-level module of the present invention. As shown in the figure, for the apparatus for generating physical path code NEW_A and statistical delay flag code NEW_B in the AWUSER in the first-level module, the destination address information carried in the write request is input to the destination parsing module to obtain physical path code NEW_A; the statistical delay flag information carried in the write request is input to the statistical delay flag encoding module to generate flag code NEW_B; subsequently, NEW_A and NEW_B are jointly input to the "physical path code NEW_A and statistical delay flag code NEW_B bit in AWUSER" configuration module, and finally the AWUSER signal carrying NEW_A and NEW_B codes is output, realizing the hardware logic of embedding physical path information and delay statistics flag into the AXI write address channel user signal.

[0292] Figure 9 This is a schematic diagram of another embodiment of the present invention where the sending module generates physical path code and delay statistics flag in the first-level module. As shown in the figure, for the device that generates physical path code NEW_A and statistical delay flag code NEW_B in ARUSER in the first-level module, the destination address information carried by the read request is input to the destination parsing module to obtain physical path code NEW_A; the statistical delay flag information carried by the read request is input to the statistical delay flag encoding module to generate flag code NEW_B; subsequently, NEW_A and NEW_B are jointly input to the "physical path code NEW_A and statistical delay flag code NEW_B bit in ARUSER" configuration module, and finally outputs the ARUSER signal carrying NEW_A and NEW_B codes, realizing the hardware logic of embedding physical path information and delay statistics flag into the AXI read address channel user signal.

[0293] Figure 10 This is a schematic diagram illustrating how the signal from the input write address channel is converted into a write response channel signal in the nth-level module, applicable to an embodiment of the present invention. As shown in the figure, for the device that converts the AWUSER signal from the input write address channel into the BUSER signal from the write response channel in the nth-level module, the input includes the AWUSER signal containing the physical path code NEW_A and the statistical delay flag code NEW_B. The physical path code NEW_A and the statistical delay flag code NEW_B are then parsed from it. Subsequently, these two codes are input to the "physical path code NEW_A and statistical delay flag code NEW_B bits in BUSER" configuration module, and finally the BUSER signal carrying the NEW_A and NEW_B codes is output, realizing the hardware logic of sending back the physical path information and delay statistics flag carried in the write request to the write response channel.

[0294] Figure 11 This is a schematic diagram illustrating how the signal from the input read address channel is converted into a read response channel signal in the nth-level module, applicable to an embodiment of the present invention. As shown in the figure, for the device that converts the ARUSER signal from the input read address channel into the RUSER signal from the read response channel in the nth-level module, the input includes the physical path code NEW_A and the statistical delay flag code NEW_B. The physical path code NEW_A and the statistical delay flag code NEW_B are then parsed from it. Subsequently, these two codes are input to the "physical path code NEW_A and statistical delay flag code NEW_B bits in RUSER" configuration module, and finally the RUSER signal carrying the NEW_A and NEW_B codes is output, realizing the hardware logic of transmitting the physical path information and delay statistics flag carried in the read request back to the read data channel.

[0295] Figure 12This is a schematic diagram illustrating the recovery of physical path information and delay statistics in a first-level module, applicable to an embodiment of the present invention. As shown in the figure, for the device that recovers physical path information and statistical delay flags from BUSER information in the first-level module, a BUSER signal containing physical path code NEW_A and statistical delay flag code NEW_B bits is input. This signal is divided into two paths and sent to the "physical path code NEW_A" parsing module and the "statistical delay flag code NEW_B" parsing module, respectively. The "physical path code NEW_A" module parses out the physical path information i and outputs it, while the "statistical delay flag code NEW_B" module parses out the statistical delay information and outputs it, thereby realizing the hardware logic of restoring the physical path and delay statistics flags from the write response channel user signal.

[0296] Figure 13 This is a schematic diagram illustrating another method for recovering physical path information and delay statistics in the first-level module, applicable to embodiments of the present invention. As shown in the figure, for the device that recovers physical path information and statistical delay flags from RUSER information in the first-level module, an input RUSER signal containing physical path code NEW_A and statistical delay flag code NEW_B bits is provided. This signal is divided into two paths and sent to the "physical path code NEW_A" parsing module and the "statistical delay flag code NEW_B" parsing module, respectively. The "physical path code NEW_A" module parses out the physical path information i and outputs it, while the "statistical delay flag code NEW_B" module parses out the statistical delay information and outputs it, thereby realizing the hardware logic for restoring the physical path and delay statistics flags from the user signal of the read data channel.

[0297] Figure 14 This is a schematic diagram illustrating the process of transmitting relevant channel information in a three-level module according to an embodiment of the present invention. As shown in the figure, the process of transmitting USER information for each relevant channel of AXI in the first-level module, second-level module, and third-level module can include four types of signals: AWUSER, ARUSER, BUSER, and RUSER. Each type of USER signal is divided into three fields: physical path code NEW_A, statistical delay flag code NEW_B, and other information. In the request transmission direction, the first-level module generates AWUSER, ARUSER, BUSER, and RUSER signals carrying NEW_A and NEW_B. The ARUSER signal is sequentially passed through to the Level 2 and Level 3 modules. Each intermediate module keeps the NEW_A and NEW_B fields unchanged and only forwards the USER signal. In the response transmission direction, the Level 3 module generates BUSER and RUSER signals carrying NEW_A and NEW_B, which are sequentially passed through to the Level 2 and Level 1 modules. Each intermediate module also forwards the NEW_A and NEW_B fields of the USER signal completely, ensuring that the physical path information and statistical delay flags are preserved throughout the cross-level transmission, realizing end-to-end transmission of information in the request and response links.

[0298] At the first-level module, the response processing capacity of all physical paths in the "determined part" is preset and stored. Then, based on the physical path information corresponding to the current request, the response processing capacity value Resp_DeterminedCapacity_Current[i] corresponding to the current determined part is obtained from the preset response processing capacity of each path.

[0299] In the response module of the first-level module, a response buffer with a defined physical depth is set. The maximum physical depth of the response buffer for each physical path i is denoted as Resp_buffer_depth_max[i], representing the maximum number of responses corresponding to the i-th physical path request that the buffer can receive at the physical layer. This parameter is determined during the physical design phase. The logical depth Resp_buffer_depth[i] of the response buffer can be defined in two ways: first, by directly assigning the maximum physical depth to the logical depth; second, by subtracting a configurable margin depth_margin[i] from the maximum physical depth and then assigning it to the logical depth. Resp_buffer_depth[i] represents the maximum logical number of responses from the i-th physical path that the response module can accept during system runtime; it supports dynamic configuration and does not require fixed physical layer limitations.

[0300] The current determined response processing capacity, Resp_DeterminedCapacity_Current[i], represents the actual number of responses from the i-th physical path that the response module can currently accept. Its dynamic management rules are as follows: Upon reset, the initial value of Resp_DeterminedCapacity_Current[i] is equal to Resp_buffer_depth[i]; when a response corresponding to a physical path is written to the response module's buffer, this value is decremented by 1; when a response corresponding to a physical path is read from the response module's buffer, this value is incremented by 1; if write and read operations occur simultaneously, this value remains unchanged.

[0301] In a specific example, the logic for determining the response processing capability register of the currently determined portion of a physical path can be as follows: The response write and response read signals are input to the conditional logic module, which generates control signals based on the read / write events, driving the selector to select the corresponding increment value from the input 1, -1, and 0; this increment value is fed into the adder and added to the output feedback value of the register to obtain the updated capability value; the output of the adder is then input to the second selector, which is controlled by the reset signal. When reset, it outputs Resp_buffer_depth[i] (the logical depth of the response buffer, obtained from the information set of all physical paths by requesting the corresponding physical path index i), and when working normally, it outputs the calculation result of the adder; finally, the output of the selector is sent to the D terminal of the register, and under the synchronization of the clock signal Clk, the value of the response processing capability register of the currently determined portion of the i-th physical path is updated, and its output Q is fed back to the adder, forming a closed-loop update mechanism, realizing the dynamic management logic of decrementing by 1 when writing, incrementing by 1 when reading, keeping it unchanged during reading and writing, and restoring to the logical depth when reset.

[0302] Based on the maximum actual capacity Resp_PredictedCapacity_Current[i] of the physical path i corresponding to the current request and the value of "determined portion of the response processing capacity" Resp_DeterminedCapacity_Current[i], the total response processing capacity Resp_EffectiveCapacity_Current[i] of the physical path i can be obtained. The total response processing capacity of each physical path is determined by the physical transmission path buffer before the first-level module and the response buffer inside the first-level module. The hardware implements a total response processing capacity module for each physical path at the first-level module. The total response processing capacity of the physical path can be obtained by adding Resp_EffectiveCapacity_Current[i] = Resp_DeterminedCapacity_Current[i] + Resp_PredictedCapacity_Current[i].

[0303] In a specific example, the core of the hardware instance that determines the total response processing capacity is an adder circuit. Its inputs are "the response processing capacity of the currently predicted part of the i-th physical path (i.e., Resp_PredictedCapacity_Current[i])" and "the response processing capacity of the currently determined part of the i-th physical path (i.e., Resp_DeterminedCapacity_Current[i])". Both are input to the "addition" module for summation, and the final output is "the total response processing capacity of the i-th physical path (i.e., Resp_EffectiveCapacity_Current[i])". Here, Resp_PredictedCapacity_Current[i] represents the predicted response capacity based on congestion correction, and Resp_DeterminedCapacity_Current[i] represents the determined response capacity based on buffer depth. The sum of the two gives the complete total response processing capacity, realizing the integrated calculation of the physical path response processing capacity.

[0304] Based on the total response processing capacity Resp_EffectiveCapacity_Current[i] (current effective response processing capacity) of the physical path corresponding to the current request, the maximum number of outstanding requests currently allowed for physical path i, Outstanding_Req_Max[i], can be obtained. This value is dynamic rather than static, and both Outstanding_Req_Max[i] and Resp_EffectiveCapacity_Current[i] must satisfy Outstanding_Req_Max[i]. In this embodiment, the value of Resp_EffectiveCapacity_Current[i] is directly assigned to Outstanding_Req_Max[i]. In other embodiments, a number less than this value can also be assigned to Outstanding_Req_Max[i]. The hardware deploys a maximum number of outstanding requests register for each physical path at the first-level module to dynamically manage the upper limit of outstanding requests for that path.

[0305] In a specific example, the process for determining the maximum number of uncompleted requests allowed on a physical path can be as follows: The input is "the total response processing capacity of the i-th physical path Resp_EffectiveCapacity_Current[i]", which is input to the "function (equal to)" module. The module directly assigns the value of Resp_EffectiveCapacity_Current[i] to the output, and finally outputs "the maximum number of uncompleted requests allowed on the i-th physical path Outstanding_Req_Max[i]", realizing a direct mapping from the total response processing capacity to the maximum number of uncompleted requests. Resp_EffectiveCapacity_Current[i] is the comprehensive response capacity based on path caching and congestion, and Outstanding_Req_Max[i] is the upper limit of uncompleted requests dynamically set based on this capacity. The two are associated through the assignment function module to ensure that the request sending of the path does not exceed its actual response processing capacity.

[0306] According to the above rules, Outstanding_Req_Current[i] (current number of incomplete requests) represents the number of incomplete requests sent by the request sending module corresponding to the i-th physical path. The hardware deploys a current number of incomplete requests register for each physical path at the first-level module. The value is 0 when reset. When a request corresponding to a physical path is sent by the sending module, the value is incremented by 1. When a response corresponding to a physical path is read from the response module buffer, the value is decremented by 1. If request sending and response reading occur simultaneously, the value remains unchanged, thereby realizing the dynamic statistics and management of the number of incomplete requests.

[0307] In a specific example, the logic for determining the current number of incomplete requests for a physical path can be as follows: Request sending and response reading signals are input to a conditional logic module. This module generates control signals based on read / write events, driving a selector to choose the corresponding increment value from the inputs of 1, -1, and 0. This increment value is fed into an adder and added to the output feedback value of the register to obtain the updated number of incomplete requests. The output of the adder is then input to a second selector, which is controlled by a reset signal. Upon reset, the selector outputs 0; during normal operation, it outputs the calculation result of the adder. Finally, the output of the selector is fed into the D terminal of the register. Under the synchronization of the clock signal Clk, the value of the current number of incomplete requests for the i-th physical path is updated, and its output Q is fed back to the adder, forming a closed-loop update mechanism. This achieves dynamic management logic: incrementing by 1 when a request is sent, decrementing by 1 when a response is read, remaining unchanged when both occur simultaneously, and clearing to zero upon reset.

[0308] According to the current number of outstanding requests Outstanding_Req_Current[i] and the maximum number of outstanding requests Outstanding_Req_Max[i] corresponding to the physical path of the current request, the sending module of the first-level module can dynamically control the sending timing of requests: when Outstanding_Req_Current[i]<Outstanding_Req_Max[i], the request is allowed to be sent to the lower-level module (such as NoC); otherwise, the sending of the request is restricted. In this way, the injection rate is actively controlled during the request sending phase, so that the return rate of response data matches the processing capability of the receiving module, thereby reducing the backpressure risk of the response path and improving the overall throughput efficiency of the system.

[0309] In a specific example, the request scheduling process can be: taking the physical path value i corresponding to the request as a selection signal to drive two multiplexers respectively; the first multiplexer selects Outstanding_Req_Current[i] of the i-th path from the current number of outstanding requests Outstanding_Req_Current[1], Outstanding_Req_Current[2], etc. of each physical path; the second multiplexer selects Outstanding_Req_Max[i] of the i-th path from the maximum number of outstanding requests Outstanding_Req_Max[1], Outstanding_Req_Max[2], etc. of each physical path; then, these two values are input together to the "judge and control whether to allow sending the request" module, and by comparing the sizes of Outstanding_Req_Current[i] and Outstanding_Req_Max[i], the enable signal for request sending is output, so as to implement dynamic request scheduling control based on physical paths.

[0310] The request initiation module's built-in request injection control hardware independently performs a series of operations, including round-trip latency statistics, path identifier matching, congestion status quantification, and request traffic management. This enables accurate collection of latency status for each physical transmission path and real-time prediction of congestion during cross-module data interaction within the system. Utilizing standardized identifier embedding and a global pass-through mechanism, it achieves efficient and accurate matching of requests and responses, eliminating the resource consumption and matching delays associated with local large-capacity storage table lookups. Furthermore, it can adaptively adjust the number and frequency of requests based on the inherent hardware performance of each path, real-time transmission load, and local cache processing capabilities. This adapts to the actual operating architecture where different functional modules within the system have asynchronous clocks and varying operating frequencies, resolving issues such as response accumulation, reverse pressure transmission, and on-chip network link congestion caused by insufficient processing capacity of the low-frequency request initiation module. This allows for a more rational arrangement of various read and write requests within the system, ensuring the smoothness and stability of cross-module data interaction throughout the system. It also provides a reliable basis for overall system transmission resource scheduling based on accurate latency statistics, comprehensively improving the data interaction efficiency, resource utilization, and overall operational management sophistication of the entire on-chip system.

[0311] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0312] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A statistical method for timing round-trip delays of a request, characterized in that, The method is executed by a request initiation module in the system-on-a-chip, the system-on-a-chip including a request initiation module, at least one level of request transmission module, and a request response module, and includes: The system obtains the target request for which round-trip delay timing is to be performed, and obtains the physical path code of the target physical path that matches the target request based on the routing flag information carried in the target request; wherein, the physical path is the path that the request takes from being sent to the request response module via the request transmission module to being returned to the request initiating module via the request transmission module. Generate a delay statistics flag that matches the target request, and fill the user-defined field of the bus request address channel with the physical path code of the target request and the delay statistics flag according to the preset bit format to obtain the target request signal; Simultaneously with sending the target request signal from the request initiation module, start the round-trip delay timer for the target request; In the process of forwarding the request signal through the request transmission module, the physical path code and delay statistics flag in the user-defined field remain unchanged. The request response module extracts the physical path code and delay statistics flag from the user-defined field in the received forwarded signal and fills them back into the user-defined field of the bus response channel to generate a response signal carrying the physical path code and delay statistics flag and transmits it back. If the current delay statistics flag and the current physical path code are extracted from the received current response signal, and it is determined that the current response signal is a response to the target request, then the round-trip delay timer for the target request is stopped, and a single actual delay value of the target physical path matching the target request is obtained. Among them, the physical path encoding and delay statistics flag in the user-defined fields of the bus response channel remain unchanged during the forwarding of the response signal through the request transmission module.

2. The method according to claim 1, characterized in that, The method further includes: Multiple statistical time windows are independently allocated to each physical path; Whenever the request initiation module detects that the first request is issued within any statistical time window on any physical path, the first request within the detected window is determined as the target request to be timed for round-trip delay.

3. The method according to claim 1, characterized in that, Based on the routing flag information carried in the target request, obtain the physical path code of the target physical path that matches the target request, including: Based on the routing flag information carried in the target request, obtain the target address or target device identifier that matches the target request; Determine the target device range to which the target address or target device identifier belongs, and map the target device range to a preset physical path code, which serves as the physical path code for the target physical path that matches the target request.

4. The method according to claim 1, characterized in that, The physical path encoding and delay statistics flag of the target request are filled into the user-defined field of the bus request address channel according to a preset bit format to obtain the target request signal, including: Divide the user-defined fields of the write address channel or read address channel into a preset bit region; wherein the preset bit region includes a first region and a second region; Write the physical path encoding of the target request into the first area and write the delay statistics flag of the target request into the second area to obtain the target request signal; When forwarding the request signal, the request transmission module keeps the bit values ​​of the physical path code in the first region and the delay statistics flag in the second region unchanged, and sends the signal to the subsequent modules.

5. The method according to claim 1, characterized in that, The request-response module generates response signals, including: The request-response module extracts the physical path code and delay statistics flag from the user-defined fields in the received forwarded signal. Following the same bit area format as the request address channel, the physical path code is written into the third area of ​​the user-defined fields in the response channel, and the delay statistics flag is written into the fourth area of ​​the user-defined fields in the response channel, so that the response signal carries the same physical path code and delay statistics flag as the request signal. When forwarding the response signal, the request transmission module keeps the bit values ​​of the physical path code in the third region and the delay statistics flag in the fourth region unchanged, and sends the signal to the subsequent modules.

6. The method according to claim 1, characterized in that, Initiate round-trip delay timing for the target request, including: Start a round-trip delay counter for the corresponding physical path of the target request, and increment the counter in units of the clock cycle of the request initiating module; Accordingly, if the current delay statistics flag and the current physical path code are extracted simultaneously from the received current response signal, and it is determined that the current response signal is a response to the target request, then the round-trip delay timing for the target request is stopped, and a single actual delay value of the target physical path matching the target request is obtained, including: If the current delay statistics flag and the current physical path code are extracted from the received current response signal, and it is determined that the current response signal is a response to the target request, then the parsed current delay statistics flag is checked to see if it is valid. If so, the corresponding round-trip delay counter is stopped from counting based on the current delay statistics flag obtained from parsing, and the count value of the round-trip delay counter is determined as a single actual delay value of the target physical path that matches the current physical path encoding target request.

7. The method according to claim 6, characterized in that, The method further includes: After continuously collecting a preset number of single actual delay values ​​for the same physical path, the collected single actual delay values ​​are summed and the average delay value is calculated. The dynamic congestion factor of the matching physical path is updated based on the calculation result obtained by dividing the average delay by the physical delay value of the matching physical path.

8. The method according to claim 1, characterized in that, The method further includes: Whenever a current request to be sent is obtained, the routing flag information carried in the current request is parsed, and the current physical path corresponding to the current request is determined according to the preset mapping relationship between the routing flag information and the physical path. Obtain the physical delay value of the current physical path, and based on the physical delay value, predict the maximum physical capacity that the current physical path can receive responses. Based on the current dynamic congestion factor of the current physical path and the maximum physical capacity that the current physical path can receive responses, calculate the maximum actual capacity that the current physical path can receive responses. Obtain the current determined response processing capacity of the current physical path in the response buffer within the request initiation module, and combine the maximum actual capacity with the current determined response processing capacity to calculate the total response processing capacity of the current physical path; Set the maximum number of incomplete requests allowed for the current physical path based on the total response processing capacity; Count the number of incomplete requests that have been sent and have not yet received a response on the current physical path. If the number of incomplete requests is less than the maximum number of incomplete requests, the current request is identified as the target request for round-trip delay timing.

9. The method according to any one of claims 1-8, characterized in that, The request initiation module is a peripheral interface module, including a high-speed peripheral component interconnection module; correspondingly, the method is executed by the request injection control hardware independently configured in the peripheral interface module.

10. A statistical device for timing the round-trip delay of a request, characterized in that, A request initiation module configured in a system-on-a-chip, the system-on-a-chip including a request initiation module, at least one level of request transmission module and request response module, the device comprising: The request acquisition module is used to acquire the target request to be timed for round-trip delay, and to acquire the physical path code of the target physical path matching the target request based on the routing flag information carried by the target request; wherein, the physical path is the path that the request takes from being sent to the request response module via the request transmission module to being returned to the request initiation module via the request transmission module. The request signal module generates a delay statistics flag that matches the target request, and fills the physical path code of the target request and the delay statistics flag into the user-defined field of the bus request address channel according to a preset bit format to obtain the target request signal. The delay timing module is used to start round-trip delay timing for the target request at the same time as the target request signal is sent from the request initiation module. During the forwarding of the request signal through the request transmission module, the physical path code and delay statistics flag in the user-defined field remain unchanged. The request response module extracts the physical path code and delay statistics flag from the user-defined field in the received forwarded signal and fills it back into the user-defined field of the bus response channel to generate a response signal carrying the physical path code and delay statistics flag and transmits it back. The stop timing module is used to stop the round-trip delay timing for the target request if the current response signal is determined to be a response to the target request based on the current delay statistics flag and the current physical path code extracted from the received current response signal. This allows for obtaining a single actual delay value for the target physical path that matches the target request. The physical path code and delay statistics flag in the user-defined fields of the bus response channel remain unchanged during the forwarding of the response signal through the request transmission module.

11. A request initiation system, characterized in that, It includes request injection control hardware, which is used to perform a statistical method for timing the round-trip delay of a request as described in any one of claims 1-9.

12. A system-on-a-chip, characterized in that, It includes the request initiation system as described in claim 11, at least one level of request transmission module, and request response module.

Images