Request scheduling method and system

Abstract

This application provides a request scheduling method and system, relating to the field of chip technology. The method includes: when it is detected that at least one on-chip network of a first chip needs to send at least one access request to a second chip, obtaining at least one flow control status parameter corresponding to the first on-chip network; determining whether the first on-chip network meets the request scheduling conditions based on the at least one flow control status parameter and the first request type of the first access request corresponding to the first on-chip network; and if it is determined that the first on-chip network meets the request scheduling conditions, performing request scheduling on the first on-chip network based on the first weight of the first on-chip network to send the first access request to the second chip. This achieves fine-grained request scheduling based on flow control status parameters, request type, and weight, avoiding monopolization of transmission resources by a single on-chip network, ensuring orderly transmission of access requests from different on-chip networks, and improving transmission real-time performance and stability.

Description

Technical Field

[0001] This application relates to the field of chip technology, and in particular to a request scheduling method and system. Background Technology

[0002] In multi-on-chip (SoC) network access, the main approach is to use a network architecture where multiple SoCs share the same cross-chip interconnect interface for access request transmission. However, sharing the transmission interface introduces interface contention issues between the multiple SoCs. Furthermore, due to differences in access requests, data traffic, and receiver processing capabilities among different SoCs, it's possible that one SoC may monopolize all transmission resources, preventing other SoCs from initiating cross-chip access requests. This compromises the real-time performance and reliability of access request transmission and makes it difficult to rationally manage and allocate transmission resources across different SoCs. Summary of the Invention

[0003] This application provides a request scheduling method and system to solve the problems of interface contention, resource monopoly, transmission blocking, and difficulty in rationally allocating transmission resources caused by multiple on-chip networks sharing cross-chip interconnect interfaces in related technologies.

[0004] A first aspect of this application provides a request scheduling method, comprising: when it is detected that at least one on-chip network of a first chip needs to send at least one access request to a second chip, obtaining at least one flow control status parameter corresponding to the first on-chip network, wherein the first on-chip network is any one of the at least one on-chip networks, and the at least one flow control status parameter is used to reflect the cross-chip transmission resource usage of the first on-chip network; determining whether the first on-chip network meets the request scheduling conditions based on the at least one flow control status parameter and a first request type of the first access request corresponding to the first on-chip network; and, if it is determined that the first on-chip network meets the request scheduling conditions, performing request scheduling on the first on-chip network based on a first weight of the first on-chip network to send the first access request to the second chip.

[0005] In some embodiments, the first request type includes a first write request and a first read request, and at least one flow control status parameter includes a first pending request quantity and a first credit value. Determining whether the first on-chip network meets the request scheduling conditions based on at least one flow control status parameter and the first request type of the first access request corresponding to the first on-chip network includes: when the first request type is a first write request, determining whether the first on-chip network meets the request scheduling conditions based on the first pending request quantity and the first credit value, wherein the first pending request quantity is used to indicate the number of access requests that the first on-chip network has sent but not received a response to, and the first credit value is used to indicate the remaining data buffer space available in the second chip of the first on-chip network; and when the first request type is a first read request, determining whether the first on-chip network meets the request scheduling conditions based on the first pending request quantity.

[0006] In some embodiments, when the first request type is a first write request, determining whether the first on-chip network meets the request scheduling conditions based on the first number of pending requests and the first credit value includes: when the first request type is a first write request, determining whether the first number of pending requests is less than a preset threshold and whether the first credit value is greater than a target value; when the first number of pending requests is less than the preset threshold and the first credit value is greater than the target value, determining that the first on-chip network meets the request scheduling conditions.

[0007] In some embodiments, when the first request type is a first read request, determining whether the first on-chip network meets the request scheduling conditions based on the number of first pending requests includes: when the first request type is a first read request, determining whether the number of first pending requests is less than a preset threshold; and when the number of first pending requests is less than the preset threshold, determining that the first on-chip network meets the request scheduling conditions.

[0008] In some embodiments, after determining that a first on-chip network meets the request scheduling conditions, the method includes: performing request scheduling on the first on-chip network based on a first weight of the first on-chip network to send a first read request to a target on-chip network of a second chip; if it is detected that the target on-chip network needs to send first read data to the first on-chip network according to the first read request, determining a second credit value of the target on-chip network, the second credit value being used to indicate the remaining data buffer space available in the first chip of the target on-chip network; if the second credit value is greater than a target value, determining that the target on-chip network meets the request scheduling conditions, and performing request scheduling on the target on-chip network based on the second weight of the target on-chip network to send the first read data to the first on-chip network.

[0009] In some embodiments, the method performs request scheduling on the first on-chip network based on a first weight. Then, the method includes: performing a first update operation on at least one flow control status parameter based on the request scheduling status and a first request type of the first on-chip network to obtain at least one first updated flow control status parameter. The at least one first updated flow control status parameter is used to determine whether the first on-chip network meets the request scheduling conditions.

[0010] In some embodiments, a first access request is sent to a second chip, and then the method includes: upon detecting a response signal returned by the second chip based on the first access request, performing a second update operation on at least one flow control status parameter based on a first request type to obtain at least one second updated flow control status parameter, wherein the at least one second updated flow control status parameter is used to determine whether the first on-chip network meets the request scheduling conditions.

[0011] A second aspect of this application provides a request scheduling system, the system comprising:

[0012] The first core and the second core connected to the first core;

[0013] The first chip includes at least one on-chip network, a flow control state parameter management module, and a weighted round-robin scheduling module;

[0014] At least one on-chip network is used to send at least one access request to the second chip;

[0015] The flow control status parameter management module is used to obtain at least one flow control status parameter corresponding to the first on-chip network when it is detected that at least one on-chip network needs to send at least one access request to the second chip. The first on-chip network is any one of the at least one on-chip networks. The at least one flow control status parameter is used to reflect the cross-chip transmission resource usage of the first on-chip network.

[0016] The weighted round-robin scheduling module is used to determine whether the first on-chip network meets the request scheduling conditions based on at least one flow control status parameter and the first request type of the first access request corresponding to the first on-chip network; and if it is determined that the first on-chip network meets the request scheduling conditions, it performs request scheduling on the first on-chip network based on the first weight of the first on-chip network so as to send the first access request to the second chip.

[0017] In some embodiments, the first request type includes a first write request and a first read request, and at least one flow control status parameter includes a first number of pending requests and a first credit value. The weighted round-robin scheduling module is further configured to: when the first request type is a first write request, determine whether the first on-chip network meets the request scheduling conditions based on the first number of pending requests and the first credit value, wherein the first number of pending requests is used to indicate the number of access requests that the first on-chip network has sent but has not received a response to, and the first credit value is used to indicate the remaining data buffer space available in the second chip of the first on-chip network; and when the first request type is a first read request, determine whether the first on-chip network meets the request scheduling conditions based on the first number of pending requests.

[0018] In some embodiments, the flow control status parameter management module is further configured to: perform a first update operation on at least one flow control status parameter based on the request scheduling status and the first request type of the first on-chip network, to obtain at least one first updated flow control status parameter, wherein the at least one first updated flow control status parameter is used to determine whether the first on-chip network meets the request scheduling conditions; or, in the case of detecting a response signal returned by the second chip based on the first access request, perform a second update operation on at least one flow control status parameter based on the first request type, to obtain at least one second updated flow control status parameter, wherein the at least one second updated flow control status parameter is used to determine whether the first on-chip network meets the request scheduling conditions.

[0019] In summary, the request scheduling method proposed in this application, when multiple on-chip networks initiate cross-chip access requests, first determines in advance whether each on-chip network meets the request scheduling conditions by combining the access request type and at least one flow control status parameter reflecting the cross-chip transmission resource usage of each on-chip network. Scheduling is only performed on access requests from on-chip networks that meet the scheduling conditions, avoiding transmission congestion caused by a single on-chip network monopolizing resources on the shared cross-chip interconnect interface. Then, arbitration scheduling is performed on the access requests that meet the scheduling conditions based on weights, achieving orderly and efficient transmission of access requests from different on-chip networks, ensuring the real-time performance and reliability of channel transmission, and improving the overall utilization and allocation rationality of transmission resources.

[0020] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application, and do not constitute an undue limitation of this application.

[0022] Figure 1A schematic diagram of an architecture for sharing a cross-chip interconnect interface across multiple on-chip networks, provided for an embodiment of this application;

[0023] Figure 2 A schematic diagram of a data flow for cross-chip access request transmission in a multi-on-chip network provided in this application embodiment;

[0024] Figure 3 A flowchart illustrating the first request scheduling method provided in this application embodiment;

[0025] Figure 4 A flowchart illustrating the second request scheduling method provided in this application embodiment;

[0026] Figure 5 A flowchart illustrating the third request scheduling method provided in this application embodiment;

[0027] Figure 6 A flowchart illustrating the fourth request scheduling method provided in this application embodiment;

[0028] Figure 7 A schematic diagram illustrating a specific multi-on-chip network initiating a cross-chip write request, provided as an embodiment of this application;

[0029] Figure 8 This is a schematic diagram illustrating a specific example of a multi-on-chip network initiating a cross-chip read request, provided in an embodiment of this application.

[0030] Figure 9 A schematic diagram illustrating a specific credit value return method provided in this application embodiment;

[0031] Figure 10 This application provides a schematic diagram of the structure of a request scheduling system according to an embodiment of the present application.

[0032] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0033] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0034] In chips employing a chip-to-chip architecture, high-speed interconnection between different chips is typically achieved using die-to-die (D2D) interface technology that conforms to the Universal Chip Interconnect Express (UCIe) standard. When multiple on-chip networks exist within a chip, such as Control Network-on-Chip (CNOC) and Data Network-on-Chip (DNOC), and all require cross-chip access, these multiple on-chip networks need to share the same UCIe transport interface for access request transmission, thus introducing interface contention issues between multiple on-chip networks.

[0035] like Figure 1 The diagram illustrates an architecture for multiple on-chip networks (MCNs) sharing a cross-chip interconnect interface. To address the interface contention issue caused by multiple MCNs sharing the same interface for cross-chip access, related technologies introduce an arbitration scheduling mechanism based on a Weighted Round-Robin Arbiter (WRR Arbiter) between the multiple MCNs and the UCIe protocol. This mechanism unifies the scheduling of access requests from different MCNs. Specifically, access requests from multiple MCNs (such as CNOC and DNOC) must first be arbitrated by the WRR Arbiter before being sequentially merged into the same UCIe channel. Finally, the requests are parsed by a demultiplexer (such as an AXI demuxer) in the peer chip and distributed to the corresponding MCN. This achieves fair and orderly access to the shared interface from multiple request sources to a certain extent. The data flow during cross-chip access by multiple MCNs is as follows: Figure 2 As shown.

[0036] However, due to the resource coupling between multiple on-chip networks within UCIe, the above approach still introduces the following problems:

[0037] (1) Outstanding contention problem: Multiple on-chip networks share the outstanding capability of the UCIe protocol (i.e., the number of incomplete requests that can be submitted to UCIe simultaneously within a given time period). Heavy-loaded networks (such as DNOC) may occupy all outstanding capabilities, causing light-loaded networks (such as CNOC) to be unable to initiate cross-chip control or protocol requests.

[0038] (2) Data channel backpressure problem: Multiple on-chip networks share the internal buffer and data path of the UCIe protocol. When a long-term backpressure occurs on a certain on-chip network (such as DNOC) on the receiving side, the backpressure may be passed to the sending side step by step, thereby blocking the transmission of other on-chip networks (such as CNOC).

[0039] Because CNOC carries protocol and control-related critical information, its transmission priority is high and it should not be blocked by DNOC under any circumstances. Therefore, to address the above issues, this application proposes a request scheduling method. Before scheduling access requests, the method combines flow control status parameters reflecting the cross-chip interconnection resource usage of each on-chip network with the access request type to predict the scheduling conditions. Weighted round-robin scheduling is then performed only on access requests from on-chip networks that meet the scheduling conditions. This achieves isolated management and control of transmission resources across different on-chip networks, preventing any single network from monopolizing outstanding quantities and transmission channels, limiting the data injection rate of the sending-side on-chip network, preventing backpressure from a single network from blocking other on-chip networks, ensuring the real-time performance and reliability of transmission across all on-chip networks, and improving the resource utilization of cross-chip interconnection interfaces and the overall system stability.

[0040] The request scheduling method provided in this application will be described in detail below with reference to the accompanying drawings.

[0041] Figure 3 A flowchart illustrating a first request scheduling method provided in an embodiment of this application. Figure 3 As shown, the request scheduling method includes steps 101-103.

[0042] Step 101: If it is detected that at least one on-chip network of the first chip needs to send at least one access request to the second chip, obtain at least one flow control status parameter corresponding to the first on-chip network.

[0043] In the embodiments of this application, a chip is a complex system-on-a-chip (SoC) that is broken down into multiple independently implementable, interconnected small functional chips. In a chip using a chip architecture, the first chip and the second chip are two independent isomorphic chips that are interconnected at high speed through D2D technology, and their interconnection interface conforms to the UCIe industry standard.

[0044] In this embodiment, the first chip is the sending chip of the cross-chip access request, and the second chip is the receiving chip of the request. It is understood that the first chip can also be a receiving chip, and the second chip can also be a sending chip; this is not limited in the embodiments of this application.

[0045] Network-on-a-Chip (NoC) is the interconnection network within a chip responsible for data transmission. For example, CNOC refers to a control message network-on-a-chip used to transmit protocol messages, control messages, and command messages; it is a low-bandwidth, low-latency, light-load network. DNOC refers to a data message network-on-a-chip used to transmit computational data and storage access data; it is a high-bandwidth, heavy-load network. It can be understood that a chip can contain at least one network-on-a-chip, and each network-on-a-chip has cross-chip access requirements. The first network-on-a-chip can be any one of the at least one network-on-a-chip.

[0046] Optionally, at least one flow control status parameter reflecting the cross-chip transmission resource usage of the first on-chip network includes the number of pending requests and a credit value. The number of pending requests, also known as the outstanding number or incomplete transaction number, refers to the number of access requests that the on-chip network has sent to the UCIe interface but has not yet received a response from the receiving end, used to limit the concurrent request volume of the on-chip network. The credit value indicates the available data buffer space remaining in the corresponding receiving chip of the on-chip network of the sending chip. A sufficient credit value means that the receiving chip has space to buffer data, and in this case, sending access requests from the on-chip network of the sending chip to the receiving chip will not cause congestion at the receiving end.

[0047] To prevent outstanding resource contention and data backpressure issues when multiple on-chip networks share the same cross-chip interconnect interface, this application configures an outstanding threshold for each on-chip network with cross-chip access requirements. The scheduling results of each on-chip network are monitored through an outstanding management module. When the number of outstanding requests (i.e., the number of pending requests) of a certain on-chip network reaches its configured threshold, subsequent scheduling of that on-chip network is suspended, thereby ensuring that any on-chip network always retains the basic outstanding resource usage capability.

[0048] Meanwhile, this application introduces a credit-based fine-grained flow control mechanism, setting up a credit management module for on-chip networks with cross-chip access requirements. The credit management module monitors the buffer resources of the receiving chip in real time, accurately limiting the data injection rate of each on-chip network of the transmitting chip, and avoiding the blocking of other normal on-chip networks due to long-term backpressure of a single on-chip network.

[0049] Step 102: Based on at least one flow control status parameter and the first request type of the first access request corresponding to the first on-chip network, determine whether the first on-chip network meets the request scheduling conditions.

[0050] In the embodiments of this application, the first access request is a cross-chip interaction request initiated by the first on-chip network. The number of first access requests can be one or more, and is not limited in the embodiments of this application.

[0051] Optionally, the request type refers to the type of access request, including write requests and read requests. This application employs different request scheduling condition judgment logic for different request types.

[0052] In one example, when the first access request for the first on-chip network is a write request, it is necessary to determine whether the first on-chip network meets the scheduling requirements by combining two indicators: the number of pending requests (ensuring that the first on-chip network does not consume excessive outstanding resources) and the credit value (ensuring that the receiving chip has sufficient buffer space to receive data). Only when both of the above indicators meet the scheduling requirements will the access request for the first on-chip network be scheduled.

[0053] When the first access request corresponding to the first on-chip network is a read request, since the read request only involves sending the read address and not sending data, it is only necessary to determine the number of pending requests on the first on-chip network, without needing to check the data buffer space of the receiving chip. When the on-chip network in the receiving chip sends read data to the first on-chip network in the sending chip, the receiving chip needs to check whether the sending chip has enough data buffer space to receive the read data.

[0054] Step 103: If it is determined that the first on-chip network meets the request scheduling conditions, the first on-chip network is scheduled based on the first weight of the first on-chip network to send the first access request to the second chip.

[0055] In the embodiments of this application, scheduling weights are pre-configured for different on-chip networks, which determine the number of times an on-chip network can be scheduled per unit time. When multiple on-chip networks simultaneously meet the scheduling conditions, weighted round-robin scheduling is performed according to the weights of each on-chip network, thereby sending the legitimate access request of the sending chip (i.e., the first chip) to the corresponding on-chip network of the receiving chip (i.e., the second chip) through the UCIe cross-chip interconnect interface.

[0056] The weighted round-robin scheduling mechanism ensures that each on-chip network that meets the scheduling conditions has a guaranteed transmission opportunity, and also enables on-demand allocation of bandwidth.

[0057] In summary, the request scheduling method proposed in this application, when multiple on-chip networks initiate cross-chip access requests, firstly, by combining the access request type and at least one flow control status parameter reflecting the cross-chip transmission resource usage of each on-chip network, pre-determines whether each on-chip network meets the request scheduling conditions. Scheduling is only performed on access requests from on-chip networks that meet the scheduling conditions, avoiding transmission congestion caused by a single on-chip network monopolizing resources on shared cross-chip interconnect interfaces. Then, arbitration scheduling is performed on access requests that meet the scheduling conditions based on weights, achieving orderly and efficient transmission of access requests from different on-chip networks, ensuring the real-time performance and reliability of channel transmission, and simultaneously improving the overall utilization and allocation rationality of transmission resources.

[0058] As one possible implementation method, Figure 4 A flowchart of a second request scheduling method provided in an embodiment of this application is shown. Based on the above embodiments, the first request type includes a first write request and a first read request, and at least one flow control status parameter includes a first number of pending requests and a first credit value. Based on at least one flow control status parameter and the first request type of the first access request corresponding to the first on-chip network, determining whether the first on-chip network meets the request scheduling conditions includes the following steps:

[0059] Step 201: If the first request type is a first write request, determine whether the first on-chip network meets the request scheduling conditions based on the first number of pending requests and the first credit value.

[0060] In embodiments of this application, the first pending request quantity, i.e., the outstanding quantity corresponding to the first on-chip network, is used to indicate the number of access requests that the first on-chip network has sent but not yet received a response to; the first credit value, i.e., the credit value corresponding to the first on-chip network, is used to indicate the remaining data buffer space available to the first on-chip network in the second chip. The first on-chip network is any one of at least one on-chip network.

[0061] In some embodiments, when the first request type is a first write request, determining whether the first on-chip network meets the request scheduling conditions based on the first number of pending requests and the first credit value includes: determining whether the first number of pending requests is less than a preset threshold and whether the first credit value is greater than a target value; and determining that the first on-chip network meets the request scheduling conditions when the first number of pending requests is less than the preset threshold and the first credit value is greater than the target value.

[0062] The first write request is a cross-chip write request initiated by the first on-chip network. The number of first write requests can be one or more, and is not limited in the embodiments of this application. The preset threshold is an outstanding threshold pre-configured for the first on-chip network to prevent it from consuming all outstanding resources; it can be configured according to actual needs. The target value is the minimum remaining buffer space threshold at the receiving end (e.g., 0), indicating that the receiving end has insufficient space to cache write data.

[0063] Optionally, if the number of first pending requests is greater than or equal to a preset threshold, or if the first credit value is equal to the target value, it is determined that the first on-chip network does not meet the request scheduling conditions.

[0064] Optionally, during initialization, the initial values ​​of the two core flow control status parameters, the number of pending requests and the credit value, are set as follows: The initial number of pending requests is configured to 0, indicating that the on-chip network has not yet sent any cross-chip access requests to the UCIe interface, and there are no incomplete transactions occupying transmission resources in the initial state. The initial credit value is determined by the hardware buffer specifications of the receiving chip, that is, the initial credit value corresponds to the depth of the internal buffer of the receiving chip, and is calculated based on the buffer size of the receiving chip and the AXI (Advanced eXtensible Interface) bus data width, as follows:

[0065]

[0066] Assuming the receiver chip's buffer size is 32KB and the receiver chip's AXI bus data width is 512 bits, the calculated buffer depth is 512. Therefore, the initial credit value is configured to be 512 by default, meaning that the receiver chip has a complete available data buffer margin in the initial state and can receive data normally.

[0067] Step 202: If the first request type is a first read request, determine whether the first on-chip network meets the request scheduling conditions based on the number of first pending requests.

[0068] In the embodiments of this application, the first write request is a cross-chip read request initiated by the first on-chip network. The number of first read requests can be one or more, and is not limited in the embodiments of this application.

[0069] In some embodiments, when the first request type is a first read request, determining whether the first on-chip network meets the request scheduling conditions based on the number of first pending requests includes: when the first request type is a first read request, determining whether the number of first pending requests is less than a preset threshold; and when the number of first pending requests is less than the preset threshold, determining that the first on-chip network meets the request scheduling conditions.

[0070] It's important to note that in the AXI protocol, the read address channel and the read data channel operate in two directions. When the first on-chip network (CNB) of the first chip initiates a read request to the second chip, the read address information is sent from the first chip and received by the second chip; conversely, the read data is returned from the second chip and received by the first chip. Since the first chip only transmits the read address information when sending a read request to the second chip, no data transmission is involved. Therefore, before sending the read address, only the scheduling conditions of the CNB need to be determined based on the number of pending requests. The determination of the CNB based on the credit value is only necessary when the receiving chip returns the read data.

[0071] Optionally, after determining that the first on-chip network meets the request scheduling conditions, the first on-chip network is requested and scheduled based on its first weight to send the first read request to the target on-chip network of the second chip; if it is detected that the target on-chip network needs to send the first read data to the first on-chip network according to the first read request, a second credit value of the target on-chip network is determined; if the second credit value is greater than the target value, the target on-chip network is determined to meet the request scheduling conditions, and the target on-chip network is requested and scheduled based on its second weight to send the first read data to the first on-chip network.

[0072] The target on-chip network is the on-chip network corresponding to the first on-chip network in the receiving end chip (i.e., the second chip); the second credit value is used to indicate the amount of data buffer space available for the target on-chip network in the first chip.

[0073] The process by which the receiving chip determines whether the on-chip network meets the scheduling conditions based on the credit value can be referenced from the credit value verification logic on the transmitting side, and will not be elaborated here.

[0074] In summary, this application achieves differentiated scheduling condition judgment based on access request type and flow control status parameters, enabling classified management of different types of access requests and resource isolation of different on-chip networks. It balances scheduling accuracy and execution efficiency, comprehensively ensuring the real-time transmission performance of the on-chip network and the overall stability of the system.

[0075] As one possible implementation method, Figure 5A flowchart of a third request scheduling method provided in an embodiment of this application is shown. Based on the above embodiments, after request scheduling is performed on the first on-chip network according to the first weight of the first on-chip network, the method includes the following steps:

[0076] Step 301: Based on the request scheduling status and the first request type of the first on-chip network, perform a first update operation on at least one flow control status parameter to obtain at least one first updated flow control status parameter.

[0077] In the embodiments of this application, the first update operation is an immediate update of the flow control status parameters (including the number of pending requests and the credit value) after the access request is scheduled. The first updated flow control status parameters are the new parameters after the original flow control parameters are updated in real time after the scheduling operation is completed, which are used for the next scheduling judgment to ensure the real-time performance and accuracy of the flow control status.

[0078] Specifically, each time the first on-chip network is successfully scheduled by the WRR Arbiter, the number of pending requests and the credit value of the first on-chip network are updated as needed according to the request type. That is, the number of pending requests of the first on-chip network is incremented by 1 (i.e., outstanding++); the credit value of the first on-chip network is subtracted from the burst length of the currently scheduled access request. The burst length is used to describe the number of data beats corresponding to one address phase, indicating how much buffer space is reserved for the receiving chip.

[0079] In one example, when the first request type is a write request, if the first on-chip network is successfully scheduled once, the above addition operation (i.e., outstanding++) is performed on the number of pending requests on the first on-chip network (i.e., the first number of pending requests) and the above subtraction operation (i.e., credit-awlen, where awlen is the AXI protocol standard signal, and in the AXI protocol, awlen is the write burst length field) is performed on the credit value (i.e., the first credit value).

[0080] When the first request type is a read request, if the first on-chip network is successfully scheduled once, the above addition operation (i.e., outstanding++) is only performed on the first pending request quantity of the first on-chip network; when the target on-chip network of the receiving chip returns read data to the first on-chip network, if the target on-chip network is successfully scheduled once, the subtraction operation (i.e., credit-arlen, where arlen is the AXI protocol standard signal, and in the AXI protocol, arlen is the read burst length field) is performed on the credit value (i.e., the second credit value) of the target on-chip network.

[0081] In summary, this application achieves real-time pre-allocation and precise control of cross-chip transmission resources by updating the flow control status parameters of the corresponding on-chip network in real time after each scheduling request is completed. This ensures the balance between scheduling fairness and resource controllability, provides a reliable basis for subsequent scheduling decisions, and effectively avoids transmission congestion problems.

[0082] As one possible implementation method, Figure 6 A flowchart of a fourth request scheduling method provided in an embodiment of this application is shown. Based on the above embodiments, after sending the first access request to the second chip, the method includes the following steps:

[0083] Step 401: Upon detecting a response signal returned by the second chip based on the first access request, a second update operation is performed on at least one flow control status parameter based on the first request type to obtain at least one second updated flow control status parameter. The at least one second updated flow control status parameter is used to determine whether the first on-chip network meets the request scheduling conditions.

[0084] In the embodiments of this application, the second update operation is a return update operation performed on the flow control status parameters (including the number of pending requests and the credit value) after receiving the response corresponding to the access request. The second updated flow control status parameters are the new parameters after the return update of the flow control parameters, which are then used for the next scheduling judgment.

[0085] Specifically, when a response signal corresponding to an access request is received, a second update operation is performed on the number of pending requests and the credit value of the first on-chip network as needed, based on the request type. That is, the number of pending requests of the first on-chip network is reduced by 1 (i.e., outstanding--); and the credit value of the first on-chip network is added back to the burst transmission length field of the completed access request.

[0086] In one example, when the first request type is a write request, if a write response signal is received, the above-mentioned subtraction operation (i.e., outstanding--) is performed on the number of pending requests on the first on-chip network (i.e., the first number of pending requests) and the above-mentioned addition operation (i.e., credit+awlen) is performed on the credit value (i.e., the first credit value).

[0087] In this process, after the second chip writes the write request data to the local target on-chip network, it will send awlen to the first chip through the local interface to perform the credit value return operation on the first chip.

[0088] When the first request type is a read request, if a read response signal is received, the above-mentioned subtraction operation (i.e., outstanding--) is only performed on the first number of pending requests of the first on-chip network. When the target on-chip network of the receiving chip returns read data to the first on-chip network and receives a response signal that the data was successfully written from the sending chip (i.e., the first chip), the credit value (i.e., the second credit value) of the target on-chip network is added back (i.e., credit+arlen).

[0089] In this process, after the first chip writes the read data returned by the second chip to its local on-chip network, it sends the arlen to the second chip through its local interface in order to perform the credit value return operation on the second chip.

[0090] In summary, this application achieves the cyclic release and dynamic balancing of cross-chip transmission resources by returning and updating the flow control status parameters after receiving the response signal. This ensures that the flow control status parameters can reflect the resource usage in real time, thereby enabling the sustainable recycling of transmission resources, avoiding deadlock problems caused by the inability to release resources, ensuring that each on-chip network can always obtain the necessary transmission resources, and improving the overall stability of system transmission.

[0091] Furthermore, to aid understanding, this application uses the example of two on-chip networks (CNOC and DNOC) initiating a cross-chip write request to illustrate the specific write request scheduling process in detail, such as... Figure 7 As shown, Figure 7 This is a schematic diagram illustrating a specific example of a multi-chip network initiating a cross-chip write request, provided in an embodiment of this application. DIE0 corresponds to the first chip, and DIE1 corresponds to the second chip.

[0092] Reference Figure 7 First, let me explain each module involved in this application:

[0093] 1) WRR arbiter: Weighted round-robin scheduling module, used to schedule CNOC and DNOC according to the configured weights.

[0094] 2) ost manage: The outstanding management module is used to record the number of pending requests of the on-chip network. When the on-chip network is scheduled once by the WRR arbiter, the outstanding is updated for the first time, i.e. outstanding++; when a response signal is received, the outstanding is updated for the second time, i.e. outstanding--.

[0095] 3) Credit Management: This module records the credit value corresponding to the on-chip network. When the on-chip network is scheduled by the WRR arbiter, the first update operation is performed on the credit, i.e., credit - awlen. When the creditmanage module receives the credit return value from the local info_o interface (actually corresponding to the awlen sent by DIE1 to the local info_o interface of DIE0 through the local info_i interface, which indicates that the data of length awlen in the buffer of DEI1 has been successfully written to the DNOC of DEI1), the second update operation is performed on the credit, i.e., credit + awlen.

[0096] The essence of credit is the currently free buffer space of the receiving chip (DIE1). Through credit management, it is ensured that the buffer space can fully absorb the write data sent by DIE0, that is, it can be completely buffered by the DIE1 buffer. It should be noted that since DNOC is a heavy-load network, credit management is only added to DNOC. In practical applications, it is not limited to heavy-load networks, and credit management can also be added to light-load networks (such as CNOC).

[0097] 4) UCIE: A cross-core protocol based on the UCIe interconnect interface standard, which includes a controller (ctrl) and a physical layer (phy). The ctrl is responsible for the digital logic of "protocol, transaction, management and scheduling", while the phy is responsible for the analog / mixed signal circuitry of "how bits are physically transferred between cores".

[0098] 5) AXI demux: The AXI demultiplexer is used to parse requests from a network on a chip that have been transmitted via UCIE and scheduled by the WRR arbiter, and then forward them to the corresponding CNOC or DNOC.

[0099] 6) aw_len_fifo: Used to cache awlen, AXI_demux parses and forwards traffic to DNOC. When write data of length awlen is successfully written to DNOC of DIE1, one awlen is cached in aw_len_fifo and sent to DIE0 through the info_i interface, and output by info_o.

[0100] 7) aw&w: Represents the on-chip network's write channel (the standard write address / write data channel interface of the AXI protocol).

[0101] Next, the process of CNOC and DNOC initiating cross-chip write requests will be explained:

[0102] 1) CNOC initiates a cross-chip write request: First, the out-manage module queries whether the number of outstanding CNOCs has reached its configured threshold (i.e., the preset threshold in this application). If it has not reached the threshold, it can participate in WRR arbiter scheduling; otherwise, scheduling of CNOCs is suspended. When a CNOC's write request is scheduled by the WRR arbiter and passed to DIE1 via UCIE, it is parsed by AXI demux and forwarded to the CNOC on DIE1.

[0103] 2) DNOC initiates a cross-chip write request: First, the credit management module queries the DNOC's credit. If there is no credit (corresponding to the case where the credit value of this application equals the target value), scheduling of the DNOC is stopped. If there is credit, its outstanding value is queried. If the current outstanding value has not yet reached its configured threshold, the DNOC is scheduled, and the first update operation is performed on both the outstanding value and the credit. If the current outstanding value has reached the configured threshold, scheduling of the DNOC is stopped. (It can be understood that credit management and OST management can also be processed in parallel.) Figure 7 (This illustrates serial processing). When a write request from DNOC is scheduled by the WRR arbiter and passed to DIE1 via UCIE, it is parsed by the AXI demux and forwarded to the DNOC path on DIE1. The buffer on the DNOC path of DIE1 buffers the write data from DNOC. If the DNOC on DIE1 does not backpressure, the data is read from the buffer and sent to DNOC. After sending a burst length of data, an awlen is written to aw_len_fifo, and then passed to the info_o interface of DIE0 via the info_i interface. Credit is then returned through the credit manage module.

[0104] Furthermore, this application uses the example of two on-chip networks initiating a cross-chip read request to provide a detailed explanation of the specific read request scheduling process, such as... Figure 8 As shown, Figure 8 This is a schematic diagram illustrating a specific example of a multi-on-chip network initiating a cross-chip read request, provided as an embodiment of this application. Figure 8 The functions of each module in the reading request Figure 7 The same applies to writing requests, so I won't go into details here.

[0105] Reference Figure 8 The process of CNOC and DNOC initiating cross-chip read requests is explained below:

[0106] 1) When CNOC and DNOC initiate a read request (i.e., initiate a read address channel request ar), they need to go through their respective ostmanage modules to check whether the current outstanding value has reached their respective configured threshold. If it has not reached the threshold, they can participate in WRRarbiter scheduling; otherwise, the scheduling of read requests will be suspended.

[0107] 2) Scheduled read requests are transmitted to DIE1 via UCIE; and then forwarded to CNOC or DNOC via AXI demux. DNOC_r (read data returned by DNOC) on DIE1 needs to be managed by the credit manager to determine if there is credit. If so, it participates in WRR arbiter scheduling and credit-arlen is performed; otherwise, it does not participate in WRR arbiter scheduling. After CNOC_r (i.e., read data returned by CNOC) and DNOC_r are scheduled by the WRR arbiter on DIE1, they are passed to DIE0 via UCIE, resolved by AXI demux, and forwarded to the CNOC_r or DNOC_r path on DIE0.

[0108] 3) DIE0's buffer first buffers the received DNOC read data and forwards it to the local DNOC. When the read data is successfully written to the DNOC, the corresponding arlen is written to ar_len_fifo, and then passed to DIE1's info_o interface through the info_i interface, and sent to the credit_manage module for credit return.

[0109] It is understood that the above example is an explanation of the cross-chip access processing flow using two on-chip networks as an example. In actual applications, the number of on-chip networks is not limited to two, but can be multiple, and is not limited in the embodiments of this application.

[0110] Figure 7 and Figure 8 The processing flow is illustrated using the example of DIE0 initiating a write / read request to DIE1. In actual implementations, both DIE0 and DIE1 can initiate read and write requests to each other. In this scenario, the processing flow of the ost manage module and credit manage module is similar to... Figure 7 and Figure 8 The key difference lies in the new changes to credit refunds, such as... Figure 9The illustration shown in this application provides a specific diagram of credit value return. When DIE0 and DIE1 initiate read / write requests to each other, the info_i interface of DIE0 must not only transmit the arlen corresponding to the read data initiated by DIE0 (see reference). Figure 8 ), and also needs to return the awlen that initiated the write request from DIE1 (see reference) Figure 7 The same applies to DIE1.

[0111] To address the issue of contention between `awlen` and `arlen` when both are returned simultaneously, this application employs an RR arbiter (round-robin scheduler) to schedule the two return requests. Accordingly, a demux module needs to be added to the `info_o` interface to parse and send the received `awlen` and `arlen` to their respective credit management modules (i.e.,...). Figure 9 Credit is returned using aw_credit manage and ar_credit manage.

[0112] It should be noted that the return value of credit (i.e., awlen / arlen) in this application is transmitted through the info interface. In actual applications, the AXI interface can also be reused (the credit information needs to be transmitted with higher priority, that is, when credit information and data are transmitted at the same time, the credit information is transmitted first). This is not restricted in the embodiments of this application.

[0113] Figure 10 This is a schematic diagram of the structure of a request scheduling system 1000 provided in an embodiment of this application. Figure 10 As shown, the request scheduling system includes:

[0114] First core 1010 and second core 1020 connected to first core 1010;

[0115] The first chip 1010 includes at least one on-chip network 1011, a flow control state parameter management module 1012, and a weighted round-robin scheduling module 1013;

[0116] At least one on-chip network 1011 is used to send at least one access request to the second chip 1020;

[0117] The flow control status parameter management module 1012 is used to obtain at least one flow control status parameter corresponding to the first on-chip network when it is detected that at least one on-chip network 1011 needs to send at least one access request to the second chip 1020. The first on-chip network is any one of the at least one on-chip network 1011. The at least one flow control status parameter is used to reflect the cross-chip transmission resource usage of the first on-chip network.

[0118] The weighted round-robin scheduling module 1013 is used to determine whether the first on-chip network meets the request scheduling conditions based on at least one flow control status parameter and the first request type of the first access request corresponding to the first on-chip network; and if it is determined that the first on-chip network meets the request scheduling conditions, it performs request scheduling on the first on-chip network based on the first weight of the first on-chip network so as to send the first access request to the second chip 1020.

[0119] In some embodiments of this application, the first request type includes a first write request and a first read request, and at least one flow control status parameter includes a first number of pending requests and a first credit value. The weighted round-robin scheduling module 1013 is used to: determine whether the first on-chip network meets the request scheduling conditions based on the first number of pending requests and the first credit value when the first request type is a first write request; the first number of pending requests is used to indicate the number of access requests that the first on-chip network has sent but not received a response to, and the first credit value is used to indicate the remaining data buffer space available in the second chip 1020 for the first on-chip network; and determine whether the first on-chip network meets the request scheduling conditions based on the first number of pending requests when the first request type is a first read request.

[0120] In some embodiments of this application, the weighted round-robin scheduling module 1013 is used to: determine whether the number of first pending requests is less than a preset threshold and whether the first credit value is greater than a target value when the first request type is a first write request; and determine that the first on-chip network meets the request scheduling conditions when the number of first pending requests is less than the preset threshold and the first credit value is greater than the target value.

[0121] In some embodiments of this application, the weighted round-robin scheduling module 1013 is used to: determine whether the number of first pending requests is less than a preset threshold when the first request type is a first read request; and determine that the first on-chip network meets the request scheduling conditions when the number of first pending requests is less than the preset threshold.

[0122] In some embodiments of this application, the second chip 1020 further includes a target on-chip network 1021. The weighted round-robin scheduling module 1013 is configured to: after determining that the first on-chip network meets the request scheduling conditions, perform request scheduling on the first on-chip network based on the first weight of the first on-chip network to send the first read request to the target on-chip network 1021 of the second chip 1020; when it is detected that the target on-chip network 1021 needs to send the first read data to the first on-chip network according to the first read request, determine a second credit value of the target on-chip network 1021, the second credit value being used to indicate the remaining data buffer space available to the target on-chip network 1021 in the first chip 1010; when the second credit value is greater than a target value, determine that the target on-chip network 1021 meets the request scheduling conditions, and perform request scheduling on the target on-chip network 1021 based on the second weight of the target on-chip network 1021 to send the first read data to the first on-chip network.

[0123] In some embodiments of this application, the flow control status parameter management module 1012 is used to perform a first update operation on at least one flow control status parameter based on the request scheduling status and the first request type of the first on-chip network, to obtain at least one first updated flow control status parameter. The at least one first updated flow control status parameter is used to determine whether the first on-chip network meets the request scheduling conditions. Alternatively, when a response signal returned by the second chip 1020 based on the first access request is detected, a second update operation is performed on at least one flow control status parameter based on the first request type to obtain at least one second updated flow control status parameter. The at least one second updated flow control status parameter is used to determine whether the first on-chip network meets the request scheduling conditions.

[0124] Since the system provided in this application corresponds to the methods provided in the above embodiments, the implementation of the methods is also applicable to the system provided in this embodiment, and will not be described in detail in this embodiment.

[0125] The methods and systems provided in the embodiments of this application have been described above. To implement the functions of the methods provided in the embodiments of this application, the electronic device may include hardware structures and software modules, and may implement the above functions in the form of hardware structures, software modules, or a combination of hardware structures and software modules. One of the above functions may be executed in the form of hardware structures, software modules, or a combination of hardware structures and software modules.

[0126] Figure 11 This is a block diagram illustrating an electronic device 1100 for implementing the above-described request scheduling method according to an exemplary embodiment.

[0127] Reference Figure 11The electronic device 1100 may include a communication interface 1101, capable of interacting with other devices; a processor 1102, connected to the communication interface 1101 to interact with other devices, used to execute the methods provided by one or more of the above-described technical solutions when running a computer program; and a memory 1103, on which the computer program is stored. Specifically, the specific processing procedure of the processor 1102 can refer to the request scheduling method described in the above embodiments of this application.

[0128] Of course, in practical applications, the various components in electronic device 1100 are coupled together through bus system 1104. It can be understood that bus system 1104 is used to realize the connection and communication between these components. In addition to a data bus, bus system 1104 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, in... Figure 11 The general designated all buses as Bus System 1104.

[0129] The memory 1103 in this embodiment is used to store various types of data to support the operation of the electronic device 1100. Examples of such data include any computer program used to operate on the electronic device 1100.

[0130] The methods disclosed in the embodiments of this application can be applied to processor 1102, or implemented by processor 1102. Processor 1102 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 1102 or by instructions in the form of software. The processor 1102 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 1102 can implement or execute the methods, steps and logic block diagrams disclosed in the embodiments of this application. A general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, which is located in memory 1103. Processor 1102 reads the information in memory 1103 and completes the steps of the aforementioned method in combination with its hardware.

[0131] In an exemplary embodiment, the electronic device 1100 may be implemented by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers (MCUs), microprocessors, or other electronic components to perform the aforementioned method.

[0132] Embodiments of this application also propose a chip including one or more interface circuits and one or more processors; the interface circuits are used to receive signals from the memory of an electronic device and send signals to the processors, the signals including computer instructions stored in the memory, and when the processor executes the computer instructions, it causes the electronic device to execute the request scheduling method described in the above embodiments of this application.

[0133] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application 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 this application described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of systems and methods consistent with some aspects of this application as detailed in the appended claims.

[0134] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0135] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0136] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a system including a processing module or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0137] It should be understood that various parts of the embodiments of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0138] Furthermore, the functional units in the various embodiments of the present invention can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc.

[0139] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A request scheduling method, characterized in that, The method includes: If it is detected that at least one on-chip network of the first chip needs to send at least one access request to the second chip, at least one flow control status parameter corresponding to the first on-chip network is obtained, wherein the first on-chip network is any one of the at least one on-chip networks, and the at least one flow control status parameter is used to reflect the cross-chip transmission resource usage of the first on-chip network; wherein the at least one flow control status parameter includes a first number of pending requests and a first credit value; wherein the first number of pending requests is used to indicate the number of access requests that the first on-chip network has sent and has not received a response to, and the first credit value is used to indicate the remaining data buffer space available to the first on-chip network in the second chip; Based on the at least one flow control status parameter and the first request type of the first access request corresponding to the first on-chip network, it is determined whether the first on-chip network meets the request scheduling conditions; wherein, the first request type includes a first write request and a first read request; If it is determined that the first on-chip network meets the request scheduling conditions, the first on-chip network is requested and scheduled based on the first weight of the first on-chip network so as to send the first access request to the second chip. Wherein, after determining that the first on-chip network meets the request scheduling conditions, the method includes: Based on the first weight of the first on-chip network, request scheduling is performed on the first on-chip network to send the first read request to the target on-chip network of the second chip. If it is detected that the target on-chip network needs to send the first read data to the first on-chip network according to the first read request, a second credit value of the target on-chip network is determined. The second credit value is used to indicate the amount of data buffer space available to the target on-chip network in the first chip. If the second credit value is greater than the target value, it is determined that the target on-chip network meets the request scheduling conditions, and the target on-chip network is requested to be scheduled based on the second weight of the target on-chip network so as to send the first read data to the first on-chip network.

2. The method according to claim 1, characterized in that, Determining whether the first on-chip network meets the request scheduling conditions based on the at least one flow control status parameter and the first request type of the first access request corresponding to the first on-chip network includes: When the first request type is the first write request, the first on-chip network is determined to meet the request scheduling conditions based on the first number of pending requests and the first credit value. When the first request type is the first read request, the on-chip network is determined to meet the request scheduling conditions based on the number of the first pending requests.

3. The method according to claim 2, characterized in that, When the first request type is the first write request, determining whether the first on-chip network meets the request scheduling conditions based on the first number of pending requests and the first credit value includes: If the first request type is the first write request, determine whether the number of the first pending requests is less than a preset threshold and whether the first credit value is greater than the target value; If the number of the first pending requests is less than the preset threshold and the first credit value is greater than the target value, it is determined that the first on-chip network meets the request scheduling conditions.

4. The method according to claim 2, characterized in that, When the first request type is the first read request, determining whether the first on-chip network meets the request scheduling conditions based on the number of the first pending requests includes: If the first request type is the first read request, determine whether the number of the first pending requests is less than a preset threshold; If the number of the first pending requests is less than the preset threshold, the first on-chip network is determined to meet the request scheduling conditions.

5. The method according to claim 1, characterized in that, Based on the first weight of the first on-chip network, a request scheduling is performed on the first on-chip network. Afterwards, the method includes: Based on the request scheduling status of the first on-chip network and the first request type, a first update operation is performed on the at least one flow control status parameter to obtain at least one first updated flow control status parameter. The at least one first updated flow control status parameter is used to determine whether the first on-chip network meets the request scheduling conditions.

6. The method according to claim 1, characterized in that, After sending the first access request to the second chip, the method includes: Upon detecting a response signal returned by the second chip based on the first access request, a second update operation is performed on the at least one flow control status parameter based on the first request type to obtain at least one second updated flow control status parameter. The at least one second updated flow control status parameter is used to determine whether the first on-chip network meets the request scheduling conditions.

7. A request scheduling system, characterized in that, The system includes: A first core and a second core connected to the first core; The first chip includes at least one on-chip network, a flow control state parameter management module, and a weighted round-robin scheduling module; The at least one on-chip network is used to send at least one access request to the second chip; The flow control status parameter management module is used to obtain at least one flow control status parameter corresponding to the first on-chip network when it is detected that the at least one on-chip network needs to send the at least one access request to the second core. The first on-chip network is any one of the at least one on-chip networks. The at least one flow control status parameter is used to reflect the cross-core transmission resource usage of the first on-chip network. The at least one flow control status parameter includes a first number of pending requests and a first credit value. The first number of pending requests is used to indicate the number of access requests that the first on-chip network has sent but has not received a response to. The first credit value is used to indicate the remaining data buffer space available to the first on-chip network in the second core. The weighted round-robin scheduling module is used to determine whether the first on-chip network meets the request scheduling conditions based on the at least one flow control status parameter and the first request type of the first access request corresponding to the first on-chip network; and if it is determined that the first on-chip network meets the request scheduling conditions, it performs request scheduling on the first on-chip network based on the first weight of the first on-chip network to send the first access request to the second chip; wherein, the first request type includes a first write request and a first read request; The weighted round-robin scheduling module is also used for: Based on the first weight of the first on-chip network, request scheduling is performed on the first on-chip network to send the first read request to the target on-chip network of the second chip. If it is detected that the target on-chip network needs to send the first read data to the first on-chip network according to the first read request, a second credit value of the target on-chip network is determined. The second credit value is used to indicate the amount of data buffer space available to the target on-chip network in the first chip. If the second credit value is greater than the target value, it is determined that the target on-chip network meets the request scheduling conditions, and the target on-chip network is requested to be scheduled based on the second weight of the target on-chip network so as to send the first read data to the first on-chip network.

8. The system according to claim 7, characterized in that, The weighted round-robin scheduling module is also used for: When the first request type is the first write request, the first on-chip network is determined to meet the request scheduling conditions based on the first number of pending requests and the first credit value. When the first request type is the first read request, the on-chip network is determined to meet the request scheduling conditions based on the number of the first pending requests.

9. The system according to claim 7, characterized in that, The flow control status parameter management module is also used for: Based on the request scheduling status of the first on-chip network and the first request type, a first update operation is performed on the at least one flow control status parameter to obtain at least one first updated flow control status parameter. The at least one first updated flow control status parameter is used to determine whether the first on-chip network meets the request scheduling conditions, or... Upon detecting a response signal returned by the second chip based on the first access request, a second update operation is performed on the at least one flow control status parameter based on the first request type to obtain at least one second updated flow control status parameter. The at least one second updated flow control status parameter is used to determine whether the first on-chip network meets the request scheduling conditions.

Images