Processor and multiplex arbitration method for processor

Abstract

This application relates to processors and a multi-arbitration method for processors. Based on this application, for a processor employing a multi-arbitration topology, if any requesting source needs to handshake with multiple competing resources, the requesting source can simultaneously initiate multi-arbitration requests to multiple corresponding arbitrators. Furthermore, the multi-arbitration requests of the requesting source can be independently authorized by the multiple arbitrators in a decoupled manner. Therefore, the handshakes between the requesting source and the multiple competing resources can also be independently implemented in a decoupled manner. Moreover, the assembler in the processor can assemble the independently authorized information generated by the multiple arbitrators into fused authorized information equivalent to the synchronous authorized information. Thus, without affecting the data transmission mechanism, the data transmission rate can be prevented from being reduced due to waiting for synchronous authorization from multiple arbitrators, thereby helping to improve the overall efficiency of the processor that is reduced due to multi-arbitration.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence chips, and in particular to a processor and a multi-way arbitration method for the processor. Background Technology

[0002] Processors used in artificial intelligence can support multi-channel concurrent data transmission. Data transmission in each channel may involve associated operations using hardware resources, and the simultaneous execution of associated operations on multiple channels may involve competition for hardware resources. The hardware resources within the processor that are being competed for can be referred to as contested resources.

[0003] To this end, the processor may include arbitrators configured for multiple competing resources. Any hardware entity in each channel can act as a requestor to initiate an arbitration request to the arbitrator corresponding to any competing resource. Furthermore, a requestor that is granted a grant at any time through the authorized arbitration of the arbitrator corresponding to any competing resource can perform associated operations using that competing resource by handshaking with that competing resource.

[0004] The associated operations performed by each channel are diverse; that is, any channel may have only one associated operation, or any combination of at least two associated operations. Therefore, an arbitration request initiated by a requesting source in any channel at the same time may target one competing resource, or it may target any combination of at least two competing resources. If any requesting source initiates an arbitration request against at least two competing resources simultaneously, then synchronous authorization information for at least two competing resources needs to be generated simultaneously based on the authorized arbitration of the corresponding at least two arbitrators to synchronously trigger the requesting source to initiate a handshake with at least two competing resources. Moreover, the downstream side of the requesting source in any channel can determine that the requesting source has completed the handshake with at least two competing resources based on the synchronous authorization information, thereby determining that the associated operation using at least two competing resources has been executed.

[0005] However, the arbitration mechanisms of different arbitrators may differ, and the number of requesting sources participating in authorized arbitration on different arbitrators may also differ. Therefore, in a multi-way arbitration topology with multiple requesting sources on multiple arbitrators, it cannot be guaranteed that arbitration requests initiated by multiple arbitrators on the same requesting source will necessarily be authorized synchronously. This leads to uncontrollable delays in the generation of synchronous authorization information. Furthermore, a livelock phenomenon may occur where synchronous authorization information cannot be generated due to multiple arbitrators continuously and asynchronously authorizing arbitration requests on a certain requesting source. This affects the data transmission efficiency of each channel and reduces the overall processing efficiency of the processor.

[0006] Therefore, how to improve the overall efficiency of processors that is reduced due to multi-way arbitration has become a technical problem to be solved in related technologies. Summary of the Invention

[0007] Embodiments of this application provide a processor and a multiplexing method for the processor, which helps to improve the overall efficiency of the processor that is reduced due to multiplexing.

[0008] In one embodiment of this application, a processor is provided, comprising:

[0009] Multiple request sources, each configured to generate a request instruction; wherein the request instruction generated by each request source is used to characterize at least one competing resource specified by that request source among multiple competing resources shared by the multiple request sources;

[0010] Multiple dispatchers, each dispatcher corresponding to a multiple request source, and each dispatcher is configured to dispatch an arbitration request to the request source based on the request instruction generated by the corresponding request source, with each specified competitive resource as the handshake object;

[0011] Multiple arbitrators are associated with multiple competing resources. Any arbitrator request with any competing resource as the handshake object is dispatched to the arbitrator corresponding to that competing resource. Each arbitrator is configured to: authorize arbitration of all arbitration requests with the corresponding competing resource as the handshake object, and generate independent authorization information to the arbitrator that is authorized through authorized arbitration, allowing the arbitrator to handshake with the corresponding competing resource.

[0012] Multiple assemblers, each corresponding to a request source, are configured to: collect independent authorization information that allows the corresponding request source to handshake with each specified competing resource; and, in response to the completion of the collection of all independent authorization information that allows the corresponding request source to handshake with all specified competing resources, assemble all the collected independent authorization information into a merged authorization information that indicates that the corresponding request source has completed handshake with all specified competing resources.

[0013] In some examples, each dispatcher is optionally configured to periodically dispatch arbitration requests with each specified competing resource as the handshake target until independent authorization information is generated that allows the corresponding requesting source to handshake with the competing resource.

[0014] In some examples, optionally, each dispatcher is further configured to determine the generated independent authorization information based on the collection results of independent authorization information by the assembler corresponding to the same request source.

[0015] In some examples, optionally, each dispatcher is further configured to determine the generated independent authorization information based on the independent authorization information received by the corresponding request source.

[0016] In some examples, optionally, a handshake between any request source and a specified competing resource is used to trigger the execution of a target operation, which is associated with the transmission of data in the channel where the request source resides to the downstream side of the request source; each dispatcher is further configured to control the enabling state of the dispatch operation based on the downstream state of the corresponding request source; wherein the downstream state of any request source includes normal and blocked, the dispatch operation of each dispatcher is enabled when the downstream state of the corresponding request source is normal, and the dispatch operation of each dispatcher is deenabled when the downstream state of the corresponding request source is blocked.

[0017] In some examples, optionally, the fusion authorization information assembled by each assembler is transmitted to the downstream channel of the corresponding request source when the downstream state of the corresponding request source is normal; wherein, the transmission of the fusion authorization information assembled by each assembler is halted when the downstream state of the corresponding request source is blocked; each dispatcher is further configured to: detect the fusion authorization information assembled in the assembler corresponding to the same request source in response to the previous request instruction of the corresponding request source; wherein, if the fusion authorization information assembled in response to the previous request instruction of the corresponding request source has been transmitted, then the downstream state of the corresponding request source is determined to be normal; if the fusion authorization information assembled in response to the previous request instruction of the corresponding request source has not been transmitted, then the downstream state of the corresponding request source is determined to be blocked.

[0018] In some examples, optionally, each assembler is further configured to: determine whether all independent authorization information allowing the corresponding request source to handshake with all specified competing resources has been collected, based on the dispatch path of dispatching arbitration requests to the arbitrator corresponding to the specified competing resource by dispatchers corresponding to the same request source.

[0019] In some examples, optionally, each dispatcher is further configured to: provide the assembler corresponding to the same request source with a dispatch path for dispatching arbitration requests to the arbitrator corresponding to the specified competing resource; each assembler is further configured to: record the dispatch path provided by the dispatcher corresponding to the same request source, and, based on the update and maintenance of the recorded dispatch path, determine whether all independent authorization information allowing the corresponding request source to handshake with all specified competing resources has been collected.

[0020] In some examples, optionally, each assembler is specifically configured to: perform a subtraction operation on the recorded dispatch path count in response to a collection operation of independent authorization information that allows the corresponding request source to handshake with each specified competing resource; and determine that all independent authorization information that allows the corresponding request source to handshake with all specified competing resources has been collected in response to the recorded dispatch path count being zero due to the subtraction operation.

[0021] In some examples, optionally, the multiple competing resources include multiple executors, each executor being configured to: in response to a successful handshake with any requesting source, execute an access operation initiated by that requesting source to a specified storage space; wherein the target operation triggered by the handshake between any requesting source and the specified competing resource includes the access operation initiated by that requesting source to the specified storage space.

[0022] In some examples, optionally, each assembler is further configured to assemble and merge the operation information generated by the target operation triggered by the handshake between the corresponding request source and all specified competing resources with the fusion authorization information.

[0023] In some examples, optionally, the competing resources specified by the multiple request sources are not all the same.

[0024] In some examples, optionally, at least one requesting source specifies at least two competing resources.

[0025] In another embodiment of this application, a multi-way arbitration method for a processor is provided. The processor includes multiple request sources and multiple arbitrators corresponding one-to-one with multiple competing resources shared by the multiple request sources. Each request source is configured to initiate an arbitration request with at least one competing resource specified among the multiple competing resources as the handshake object. Each arbitrator is configured to authorize arbitration of all arbitration requests with the corresponding competing resource as the handshake object and generate independent authorization information for the request source that is authorized through authorized arbitration, allowing the request source to handshake with the corresponding competing resource.

[0026] The multiple arbitration method configures multiple dispatchers corresponding one-to-one with multiple request sources and multiple assemblers corresponding one-to-one with multiple request sources in the processor, and the multiple arbitration method includes:

[0027] Each dispatcher uses the request instruction generated by the corresponding request source to dispatch an arbitration application to the request source with each specified competitive resource as the handshake object; wherein, the request instruction generated by each request source is used to represent at least one competitive resource specified by the request source among multiple competitive resources, and the arbitration application of any request source with any competitive resource as the handshake object is dispatched to the arbitrator corresponding to the competitive resource.

[0028] Each assembler collects independent authorization information that allows the corresponding request source to handshake with each specified competing resource;

[0029] Each assembler, in response to the completion of collecting all independent authorization information that allows the corresponding request source to handshake with all specified competing resources, assembles all collected independent authorization information into a merged authorization information to indicate that the corresponding request source has completed handshake with all specified competing resources.

[0030] In some examples, optionally, each dispatcher uses the request instruction generated by the corresponding request source to dispatch an arbitration request to the request source with each specified competing resource as the handshake object, including: periodically dispatching an arbitration request with each specified competing resource as the handshake object using each dispatcher until independent authorization information allowing the corresponding request source to handshake with the competing resource is generated.

[0031] In some examples, the multiple arbitration method may optionally further include: using the results of each dispatcher's collection of independent authorization information based on the assembler corresponding to the same request source to determine the generated independent authorization information.

[0032] In some examples, the multiple arbitration method may optionally include: determining the generated independent authorization information using the independent authorization information received by each dispatcher based on the corresponding request source.

[0033] In some examples, optionally, the handshake between any request source and a specified competing resource is used to trigger the execution of a target operation, which is associated with the transmission of data in the channel where the request source resides to the downstream side of the request source; using each dispatcher to dispatch an arbitration request to the request source with each specified competing resource as the handshake object based on the request instruction generated by the corresponding request source, including: using each dispatcher to control the enable state of the dispatch operation based on the downstream state of the corresponding request source; wherein the downstream state of any request source includes normal and blocked, the dispatch operation of each dispatcher is enabled when the downstream state of the corresponding request source is normal, and the dispatch operation of each dispatcher is deenabled when the downstream state of the corresponding request source is blocked.

[0034] In some examples, optionally, the fusion authorization information assembled by each assembler is transmitted to the downstream channel of the corresponding request source when the downstream state of the corresponding request source is normal; wherein, the transmission of the fusion authorization information assembled by each assembler is halted when the downstream state of the corresponding request source is blocked; the multiple arbitration method further includes: using each dispatcher to detect the fusion authorization information assembled in response to the previous request instruction of the corresponding request source in the assembler corresponding to the same request source; wherein, if the fusion authorization information assembled in response to the previous request instruction of the corresponding request source has been transmitted, then the downstream state of the corresponding request source is determined to be normal; if the fusion authorization information assembled in response to the previous request instruction of the corresponding request source has not been transmitted, then the downstream state of the corresponding request source is determined to be blocked.

[0035] In some examples, the multiple arbitration method may optionally further include: using the dispatch path of each assembler to dispatch arbitration requests to the arbitrator corresponding to the specified competing resource based on the dispatcher corresponding to the same request source, determining whether all independent authorization information allowing the corresponding request source to handshake with all specified competing resources has been collected.

[0036] In some examples, optionally, the multiple arbitration method further includes: using each dispatcher to provide the assembler corresponding to the same request source with a number of dispatch paths for dispatching arbitration requests to the arbitrator corresponding to the specified competing resource; using each assembler to determine whether all independent authorization information allowing the corresponding request source to handshake with all specified competing resources has been collected based on the number of dispatch paths provided by the dispatcher corresponding to the same request source to the arbitrator corresponding to the specified competing resource, including: using each assembler to record the number of dispatch paths provided by the dispatcher corresponding to the same request source, and using each assembler to determine whether all independent authorization information allowing the corresponding request source to handshake with all specified competing resources has been collected based on the update and maintenance of the recorded number of dispatch paths.

[0037] In some examples, optionally, each assembler, based on the updated maintenance of the dispatch path count of the record, determines whether all independent authorization information allowing the corresponding request source to handshake with all specified competing resources has been collected, including: performing a subtraction operation on the dispatch path count of the record in response to a collection operation of the independent authorization information allowing the corresponding request source to handshake with each specified competing resource; and determining that all independent authorization information allowing the corresponding request source to handshake with all specified competing resources has been collected in response to the dispatch path count of the record being zero.

[0038] In another embodiment of this application, an electronic device is provided, including a processor as described in the foregoing embodiments.

[0039] Based on embodiments of this application, for a processor employing a multi-arbitration topology, if any requesting source needs to handshake with multiple competing resources, the requesting source can simultaneously initiate multi-arbitration requests to the corresponding multiple arbitrators. Furthermore, the multi-arbitration requests of the requesting source do not necessarily require simultaneous authorization by the corresponding multiple arbitrators; instead, multiple arbitrators can implement independent authorization (e.g., synchronous or asynchronous authorization) in a decoupled manner. Therefore, the handshakes between the requesting source and the multiple competing resources in response to the independent authorization of the multiple arbitrators can also be implemented independently and decoupled from each other. Moreover, the assembler in the processor can assemble the independent authorization information generated by the multiple arbitrators into fused authorization information equivalent to the synchronous authorization information. Thus, without affecting the data transmission mechanism, the data transmission rate can be prevented from being reduced due to waiting for simultaneous authorization from multiple arbitrators, thereby helping to improve the overall efficiency of the processor that is reduced due to multi-arbitration. Attached Figure Description

[0040] The following figures are for illustrative purposes only and do not limit the scope of this application:

[0041] Figure 1 This is an exemplary structural diagram of the multi-arbitration architecture of the processor in an embodiment of this application;

[0042] Figure 2 This is a schematic diagram illustrating an example of arbitration request dispatch in the multi-way arbitration architecture of a processor according to an embodiment of this application;

[0043] Figure 3 This is a schematic diagram illustrating an example of authorization information collection in a multi-way arbitration architecture of a processor according to an embodiment of this application.

[0044] Figure 4 This is a schematic diagram of the optimization logic in the multi-arbitration architecture of the processor in an embodiment of this application;

[0045] Figure 5 This is an exemplary flowchart illustrating a multi-way arbitration method for a processor according to an embodiment of this application. Detailed Implementation

[0046] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided with reference to the accompanying drawings and embodiments.

[0047] For example, in the embodiments of this application, the processor can be any one of the following integrated circuit chips suitable for artificial intelligence: GPU (Graphics Processing Unit), TPU (Tensor Processing Unit), NPU (Neural Network Processing Unit), DPU (Deep Learning Processing Unit), APU (Accelerated Processing Unit), and GPGPU (General-Purpose computing on Graphics Processing Units).

[0048] Figure 1 This is an exemplary structural diagram of a multi-arbitration architecture for a processor according to an embodiment of this application. Please refer to... Figure 1 In embodiments of this application, the processor may include multiple request sources 10_1~10_M, multiple dispatchers 20_1~20_M, multiple assemblers 30_1~30~M, and multiple arbitrators 50_1~50_N. Here, M represents the number of dispatchers 20_1~20_M and assemblers 30_1~30~M, and N represents the number of arbitrators 50_1~50_N. Both M and N are positive integers greater than 1, and M and N may be the same or different. Embodiments of this application do not intend to limit the numerical relationship between M and N.

[0049] For example, in the embodiments of this application, the multiple request sources 10_1 to 10_M respectively correspond to multiple channels of the processor.

[0050] For example, if the processor is a GPU or GPGPU, it can include multiple Streaming Processor Clusters (SPCs) for kernel computation. Each SPC can utilize kernel functions to perform kernel computation. Each SPC can be divided into at least two partitions, and each partition can include multiple processing kernels. In this case, the processor's support for multiple channels of concurrent data transfer can refer to multiple channels corresponding to multiple SPCs, or multiple channels within each SPC corresponding to multiple partitions.

[0051] For example, in the embodiments of this application, the multiple request sources 10_1 to 10_M can be any hardware entities in the corresponding multiple channels.

[0052] For example, the processor's multiple channels can employ a multi-stage transmission method, such as pipelined transmission. In this case, after each stage of data processing within any channel is completed, the hardware entity located at that stage can act as a request source to initiate the transmission of the processed data to the next downstream stage. That is, the multiple request sources 10_1 to 10_M in the embodiments of this application do not specifically refer to any particular hardware entity in the multiple channels, and the embodiments of this application are not intended to impose unnecessary restrictions on the multiple request sources 10_1 to 10_M.

[0053] For example, in the embodiments of this application, multiple dispatchers 20_1~20_M correspond one-to-one with multiple request sources 10_1~10_M, and multiple assemblers 30_1~30~M correspond one-to-one with multiple request sources 10_1~10_M. Therefore, it can also be considered that the multiple dispatchers 20_1~20_M and the multiple assemblers 30_1~30~M respectively correspond to multiple channels of the processor.

[0054] For example, in embodiments of this application, multiple arbitrators 50_1 to 50_N can be used with arbitrators not in... Figure 1 The multiple competing resources shown correspond one-to-one, and each of the multiple arbitrators 50_k from 50_1 to 50_N can be used to authorize arbitration of any arbitration request initiated by any requesting source 10_q in order to handshake with the corresponding competing resource. This restricts the corresponding competing resource to handshaking with only one requesting source 10_q at any given time, and to performing corresponding operations based on the handshake with that requesting source 10_q (e.g., operations related to transmitting data in the channel where that requesting source 10_q resides to the downstream side of that requesting source 10_q). Here, q is any positive integer greater than or equal to 1 and less than or equal to M.

[0055] For example, in the embodiments of this application, the arbitration mechanisms used by the multiple arbitrators 50_1 to 50_N to implement authorized arbitration may not all be the same. The embodiments of this application do not limit the arbitration mechanisms used by the multiple arbitrators 50_1 to 50_N to implement authorized arbitration.

[0056] For example, in embodiments of this application, multiple competing resources (i.e., N competing resources corresponding one-to-one with multiple arbitrators 50_1 to 50_N) include multiple executors. Each executor can be configured to execute an access operation initiated by the request source 10_q to a specified storage space in response to a successful handshake with any request source 10_q. For example, an executor that successfully handshakes with any request source 10_q can act as the master device and slave device of the request source 10_q to execute the access operation initiated by the request source 10_q to the specified storage space. That is, the target operation triggered by the handshake between any request source 10_q and the specified competing resource can include an access operation (e.g., a write operation and / or a read operation) initiated by the request source 10_q to the specified storage space, and the access operation can be associated with the transmission of data in the channel where the request source 10_q resides to the downstream side of the request source 10_q.

[0057] For example, data in the channel containing any request source 10_q can be transmitted downstream of request source 10_q. This can be used to perform a calculation operation "ax+by" using a specified parameter set {a, b} on the downstream side of request source 10_q, where the processing result {x, y} of a certain level in a multi-level data processing is processed using a specified parameter set {a, b}. In this case, the access operation initiated by request source 10_q to the specified storage space can include a write operation to write the processing result {x, y} to the specified storage space that can be read by the next level. Furthermore, the access operation initiated by request source 10_q to the specified storage space can also include read operations to retrieve each parameter from the pre-configured specified parameter set {a, b} from different specified storage spaces. Accordingly, a write operation to one storage space and read operations to multiple other storage spaces require handshaking with multiple executors used to perform access operations on these storage spaces before these executors can be triggered to complete the read and write operations respectively.

[0058] For example, in an embodiment of this application, each request source 10_q among the plurality of request sources 10_1 to 10_M can be configured to generate a request instruction. The request instruction generated by each request source 10_q can be used to characterize at least one competing resource specified by that request source 10_q among the plurality of competing resources shared by the plurality of request sources 10_1 to 10_M (i.e., N competing resources corresponding one-to-one with the plurality of arbitrators 50_1 to 50_N). That is, the number Q of competing resources specified by each request source 10_q among the plurality of competing resources shared by the plurality of request sources 10_1 to 10_M can be any positive integer greater than 1 and less than or equal to N.

[0059] For example, in the embodiments of this application, each dispatcher 20_q (i.e., the dispatcher 20_q corresponding to each request source 10_q) among the plurality of dispatchers 20_1 to 20_M can be configured to: dispatch an arbitration application to the request source 10_q with each specified competitive resource as the handshake object according to the request instruction generated by the corresponding request source 10_q.

[0060] For example, in an embodiment of this application, the request instruction generated by each of the multiple request sources 10_q (10_1 to 10_M) may include indication information for representing at least one specified competitive resource. For instance, the indication information in the request instruction generated by each request source 10_q may include a mask, which may have data bits corresponding one-to-one with the multiple competitive resources (i.e., N competitive resources corresponding one-to-one with the multiple arbitrators 50_1 to 50_N). The value of each data bit is used to represent whether the competitive resource corresponding to that data bit is specified by the request source 10_q. In this case, each dispatcher 20_q can dispatch at least one arbitration request based on the indication information in the request instruction generated by the corresponding request source 10_q. That is, each request source 10_q can initiate an arbitration request with that competitive resource as the handshake object through the dispatcher 20_q corresponding to that request source 10_q to one of the multiple arbitrators 50_1 to 50_N corresponding to each specified competitive resource.

[0061] For example, in an embodiment of this application, any arbitration application from any request source 10_q among multiple request sources 10_1 to 10_M, with any competing resource as the handshake object, can be dispatched by the request source 10_q to at least one arbitrator (i.e., Q arbitrators) among multiple arbitrators 50_1 to 50_N that corresponds to at least one specified competing resource (i.e., Q competing resources).

[0062] It is understood that in the embodiments of this application, the multiple dispatchers 20_1~20_M are not equivalent to multiplexers using a "multiple-choose-one" mechanism, but rather support any configurable number of selections. Specifically, any dispatcher 20_q corresponding to a request source 10_q can support the request source 10 to initiate an arbitration request to a corresponding arbitrator only in order to handshake with one competing resource, and can also support the request source 10 to simultaneously initiate at least two arbitration requests to at least two of the multiple arbitrators 50_1~50_N in order to handshake with at least two competing resources.

[0063] Figure 2 This is a schematic diagram illustrating an example of arbitration request dispatch in a multi-way arbitration architecture of a processor according to an embodiment of this application. Figure 2In the example of M=4 and N=3, the solid arrow lines between the four dispatchers 20_1~20_4 and the three arbitrators 50_1~50_3 represent the lines for dispatching arbitration requests, and the dashed lines between the four dispatchers 20_1~20_4 and the three arbitrators 50_1~50_3 represent the lines where no arbitration requests are dispatched. Figure 2 In the example shown, request source 10_1 sends three arbitration requests to three arbitrators 50_1 to 50_3 through dispatcher 20_1, request source 10_2 sends one arbitration request to one arbitrator 50_1 through dispatcher 20_2, request source 10_3 sends two arbitration requests to two arbitrators 50_1 and 50_2 through dispatcher 20_3, and request source 10_4 sends two arbitration requests to two arbitrators 50_1 and 50_3 through dispatcher 20_4.

[0064] From such Figure 2 As can be seen from the examples shown, in this embodiment, based on the characteristics of multiple dispatchers 20_1~20_M, the competing resources specified by multiple request sources 10_1~10_M among the multiple competing resources shared by multiple request sources 10_1~10_M (i.e., N competing resources corresponding one-to-one with multiple arbitrators 50_1~50_N) may not all be the same. For example, the competing resource specified by each request source 10_q among the multiple request sources 10_1~10_M can be determined by the service requirements of data processing in the channel where the request source 10_q is located, and this embodiment does not impose any restrictions on this. In addition, generally, in the embodiments of this application, the number of competing resources specified by at least one of the multiple request sources 10_1~10_M is at least two.

[0065] From such Figure 2 The examples shown also demonstrate that, in the embodiments of this application, in addition to the fact that the arbitration mechanisms used by the multiple arbitrators 50_1 to 50_N to implement authorized arbitration may not be entirely the same, the number of request sources participating in the authorized arbitration of the multiple arbitrators 50_1 to 50_N may also be different, that is, the arbitration burden of the multiple arbitrators 50_1 to 50_N may not be entirely the same.

[0066] For example, in an embodiment of this application, each of the plurality of arbitrators 50_1 to 50_N can be configured to: authorize arbitration of all arbitration applications with the corresponding competing resource as the handshake object, and generate independent authorization information for the request source 10_q that is authorized through authorized arbitration, allowing the request source 10_q to handshake with the corresponding competing resource, so as to trigger the request source 10_q to initiate an independent handshake with the corresponding competing resource to decouple from other competing resources.

[0067] Based on embodiments of this application, for a processor employing a multi-arbitration topology, if any request source 10_q among multiple request sources 10_1 to 10_M needs to handshake with multiple (i.e., Q greater than 1) competing resources, then the request source 10_q can simultaneously initiate multi-arbitration requests to the corresponding Q arbitrators among multiple arbitrators 50_1 to 50_N. Furthermore, the multi-arbitration requests of the request source 10_q do not necessarily require synchronous authorization by the corresponding Q arbitrators; rather, the Q arbitrators can implement independent authorization (e.g., synchronous or asynchronous authorization) in a decoupled manner. Therefore, the handshakes between the request source 10_q and the multiple competing resources in response to the independent authorization of the Q arbitrators can also be implemented independently and decoupled from each other.

[0068] For example, in the embodiments of this application, each assembler 30_q among the multiple assemblers 30_1~30~M (i.e., the assembler 30_q corresponding to each request source 10_q) can be configured to: collect independent authorization information that allows the corresponding request source 10_q to handshake with each specified competitive resource (i.e., the independent authorization information generated by the arbitrators corresponding to each competitive resource specified by the corresponding request source 10_q in the multiple arbitrators 50_1~50_N), that is, the independent authorization information that allows the request source 10_q to handshake with each specified competitive resource can be collected independently by the assembler 30_q corresponding to the request source 10_q.

[0069] For example, in the embodiments of this application, each assembler 30_q among the multiple assemblers 30_1~30~M (i.e., the assembler 30_q corresponding to each request source 10_q) can also be configured to: in response to the completion of the collection of all independent authorization information that allows the corresponding request source to handshake with all specified competing resources (i.e., the collection of all independent authorization information generated by the Q arbitrators corresponding to the Q competing resources specified by the corresponding request source 10_q in the multiple arbitrators 50_1~50_N), assemble all the collected independent authorization information into fused authorization information to indicate that the corresponding request source 10_q has completed handshake with all specified competing resources, that is, in response to the current request instruction of the corresponding request source 10_q, assemble the fused authorization information Grant_q_merge.

[0070] Figure 3 This is a schematic diagram illustrating an example of authorization information collection in a multi-way arbitration architecture of a processor according to an embodiment of this application. Figure 3 In the example, a request source 10_q initiates an arbitration request to three (i.e., N is 3) arbitrators 50_i, 50_j, and 50_k, where i, j, and k are all distinct positive integers greater than or equal to 1 and less than or equal to N.

[0071] In such Figure 3In the example shown, the three arbitrators 50_i, 50_j, and 50_k correspond to the first, second, and third contention resources specified by the request source 10_q, respectively, where:

[0072] At time t1, the arbitrator 50_j corresponding to the second contention resource generates independent grant information Grant_q_j that allows the request source 10_q to handshake with the second contention resource. This triggers the request source 10_q to initiate an independent handshake with the second contention resource, thereby enabling the second contention resource to complete an operation associated with the transmission of data in the channel where the request source 10_q is located to the downstream side of the request source 10_q. At the same time, the independent grant information Grant_q_j is collected from the arbitrator 50_j by the assembler 30_q corresponding to the request source 10_q.

[0073] At time t2 after time t1, the arbitrator 50_k corresponding to the third competing resource generates independent grant information Grant_q_k that allows the requesting source 10_q to handshake with the third competing resource. This triggers the requesting source 10_q to initiate an independent handshake with the third competing resource, thereby enabling the third competing resource to complete another operation associated with the transmission of data in the channel where the requesting source 10_q is located to the downstream side of the requesting source 10_q. At the same time, the independent grant information Grant_q_k is collected from the arbitrator 50_k by the assembler 30_q corresponding to the requesting source 10_q.

[0074] At time t3 after time t2, the arbitrator 50_i corresponding to the first competing resource generates independent grant information Grant_q_i that allows the request source 10_q to handshake with the first competing resource. This triggers the request source 10_q to initiate an independent handshake with the first competing resource, thereby enabling the first competing resource to complete the last operation associated with the transmission of data in the channel where the request source 10_q is located to the downstream side of the request source 10_q. At the same time, the independent grant information Grant_q_k is collected from the arbitrator 50_i by the assembler 30_q corresponding to the request source 10_q.

[0075] Subsequently, since all the independent grant information Grant_q_i, Grant_q_j, and Grant_q_k that allow request source 10_q to handshake with all designated first, second, and third competing resources has been collected, the assembler 30_q corresponding to request source 10_q can assemble all the collected independent grant information Grant_q_i, Grant_q_j, and Grant_q_k into a merged grant information Grant_q_merge that represents the completion of handshake between the corresponding request source 10_q and all designated first, second, and third competing resources.

[0076] Based on embodiments of this application, the assembler 30_q corresponding to each request source 10_q in the processor can assemble the independent grant information generated by Q arbitrators into a merged grant information Grant_q_merge, which is equivalent to the synchronous grant information. Therefore, without affecting the data transmission mechanism, the data transmission rate can be prevented from being reduced due to waiting for synchronous grants from multiple arbitrators, thereby helping to improve the overall efficiency of the processor that is reduced due to multi-way arbitration.

[0077] Furthermore, the embodiments of this application do not require improvements to the data transmission mechanism in the processor, nor do they require the deployment of complex structures that increase circuit area in order to implement complex synchronization mechanisms. Therefore, the above-mentioned effects are achieved without sacrificing power, performance, area (PPA).

[0078] For example, in an embodiment of this application, an arbitration application can be the same periodically dispatched arbitration application among multiple arbitrators 50_1 to 50_N. That is, each dispatcher 20_q among the multiple dispatchers 20_1 to 20_M (i.e., the dispatcher 20_q corresponding to each request source 10_q) can be specifically configured to periodically dispatch arbitration applications with each specified competitive resource as the handshake object, until independent authorization information allowing the corresponding request source 10_q to handshake with the competitive resource is generated from the arbitrator of the multiple arbitrators 50_1 to 50_N corresponding to the competitive resource.

[0079] For example, in the embodiments of this application, each dispatcher 20_q (i.e., the dispatcher 20_q corresponding to each request source 10_q) among the multiple dispatchers 20_1 to 20_M can be specifically configured to: periodically determine whether independent authorization information allowing the corresponding request source 10_q to handshake with each specified competitive resource has been generated, that is, whether the handshake between the corresponding request source 10_q and each specified competitive resource has been authorized, and determine whether each arbitration request should continue to be dispatched based on the determination result of each dispatch cycle.

[0080] Figure 4 This is a schematic diagram of the optimization logic in the multi-arbitration architecture of the processor according to an embodiment of this application. Figure 4 Let's take the example of a request source 10_q initiating an arbitration request to three arbitrators (N = 3): 50_i, 50_j, and 50_k. Figure 4As shown, each dispatcher 20_q (i.e., the dispatcher 20_q corresponding to each request source 10_q) among the multiple dispatchers 20_1~20_M first determines whether the independent authorization information allowing the corresponding request source 10_q to handshake with each specified competitive resource has been generated when each dispatch cycle arrives. That is, whether the handshake between the corresponding request source 10_q and each specified competitive resource has been authorized. If authorized, the arbitration request for that route will no longer be dispatched; if not authorized, the arbitration request for that route will continue to be dispatched.

[0081] For example, in the embodiments of this application, dispatcher 20_q and assembler 30_q corresponding to the same request source 10_q can interact or share information, such as Figure 3 As shown in the figure. In this case, each dispatcher 20_q among the multiple dispatchers 20_1 to 20_M (i.e., the dispatcher 20_q corresponding to each request source 10_q) can be further configured to: determine the generated independent authorization information based on the collection results of the independent authorization information by the assembler 30_q corresponding to the same request source 10_q, thereby realizing single-path control for the periodic dispatch of each arbitration application.

[0082] Exemplarily, in an embodiment of this application, as an alternative, each request source 10_q may, in response to independent authorization information received from any arbitrator, forward the independent authorization information to the corresponding dispatcher 20_q among the multiple dispatchers 20_1~20_M, or generate notification information indicating that the competing resource has been allowed to be handshaked to the corresponding dispatchers 20_q among the multiple dispatchers 20_1~20_M. In this case, each dispatcher 20_q among the multiple dispatchers 20_1~20_M (i.e., the dispatcher 20_q corresponding to each request source 10_q) may be further configured to: determine the generated independent authorization information based on the independent authorization information received by the corresponding request source 10_q (e.g., an independent authorization notification forwarded by the corresponding request source 10_q, or a notification information generated by the corresponding request source 10_q), thereby achieving single-path control for the periodic dispatch of each arbitration request.

[0083] For example, in an embodiment of this application, for a target operation triggered by a handshake between any request source 10_q and a specified competing resource, if the target operation is associated with the transmission of data in the channel where the request source 10_q is located to the downstream side of the request source 10_q, then each of the multiple dispatchers 20_1 to 20_M (i.e., the dispatcher 20_q corresponding to each request source 10_q) can be further configured to: control the enabling state of the dispatch operation according to the downstream state of the corresponding request source 10_q; wherein, the downstream state of any request source 10_q includes normal and blocked, the dispatch operation of each dispatcher 20_q (e.g., periodic dispatch) is enabled when the downstream state of the corresponding request source 10_q is normal, and the dispatch operation of each dispatcher 20_q (e.g., periodic dispatch) is deenabled when the downstream state of the corresponding request source 10_q is blocked, thereby realizing global control over the dispatch operation of the dispatcher 20_q. This allows for the optimization of the arbitration and authorization results for competing resources, namely, prioritizing the allocation of competing resources to channels that are not blocked, thereby further improving the overall processing efficiency of the processor.

[0084] For example, such as Figure 4 As shown, the operation of each dispatcher 20_q determining whether independent authorization information for the handshake between the corresponding request source 10_q and each specified competing resource has been generated can only be enabled if the downstream state of the corresponding request source 10_q is determined to be normal (i.e., not blocked).

[0085] For example, in an embodiment of this application, the fusion grant information Grant_q_merge assembled by each assembler 30_q (i.e., the assembler 30_q corresponding to each request source 10_q) among the multiple assemblers 30_1~30~M can be transmitted to the downstream channel of the corresponding request source 10_q when the downstream side of the request source 10_q is in a normal state. This allows the downstream side of the request source 10_q to determine, based on the fusion grant information Grant_q_merge, that the request source 10_q has completed handshakes with at least two competing resources, thereby determining that the associated operation using at least two competing resources has been executed. However, the transmission of the fusion grant information Grant_q_merge assembled by each assembler 30_q (i.e., the assembler 30_q corresponding to each request source 10_q) to the downstream side can also be halted when the downstream side of the request source 10_q is in a blocked state.

[0086] In this scenario, if dispatchers 20_q and assemblers 30_q corresponding to the same request source 10_q can interact or share information, then each dispatcher 20_q among the multiple dispatchers 20_1~20_M (i.e., the dispatcher 20_q corresponding to each request source 10_q) can be further configured to: detect the fusion authorization information Grant_q_merge assembled in response to the previous request instruction of the corresponding request source 10_q in the assembler 30_q corresponding to the same request source 10_q; wherein, if the fusion authorization information Grant_q_merge assembled in response to the previous request instruction of the corresponding request source 10_q has been transmitted (i.e., moved out of the assembler 30_q), then the downstream state of the corresponding request source 10_q is determined to be normal; if the fusion authorization information Grant_q_merge assembled in response to the previous request instruction of the corresponding request source 10_q has not been transmitted (i.e., still exists in the assembler 30_q), then the downstream state of the corresponding request source 10_q is determined to be blocked.

[0087] For example, in the embodiments of this application, each assembler 30_q among the multiple assemblers 30_1~30~M (i.e., the assembler 30_q corresponding to each request source 10_q) can be further configured to: assemble and merge the operation information generated by the target operation triggered by the handshake between the corresponding request source 10_q and all specified competing resources (e.g., the write response generated by the executor that successfully performs a write operation on the specified storage space, and / or the read response including read data generated by the executor that successfully performs a read operation on the specified storage space) with the fusion authorization information Grant_q_merge, so that it can be transmitted to the downstream side of the corresponding request source 10_q together with the fusion authorization information Grant_q_merge.

[0088] For example, in the embodiments of this application, each assembler 30_q (i.e., the assembler 30_q corresponding to each request source 10_q) among the multiple assemblers 30_1~30~M can be further configured to: determine whether all independent authorization information allowing the corresponding request source 10_q to handshake with all specified competitive resources has been collected, based on the dispatch path number (i.e. the number of resources of the competitive resource specified by the corresponding request source 10_q) dispatching the arbitration application to the arbitrator corresponding to the specified competitive resource by the dispatcher 20_q corresponding to the same request source 10_q.

[0089] For example, in an embodiment of this application, if dispatchers 20_q and assemblers 30_q corresponding to the same request source 10_q can interact or share information, then each dispatcher 20_q among the multiple dispatchers 20_1 to 20_M (i.e., the dispatcher 20_q corresponding to each request source 10_q) can be further configured to: provide the assembler 30_q corresponding to the same request source 10_q with a dispatch path for dispatching an arbitration application to the arbitrator corresponding to the specified competitive resource. In this case, each assembler 30_q among the multiple assemblers 30_1 to 30_M (i.e., the assembler 30_q corresponding to each request source 10_q) can be specifically configured to: record the dispatch path provided by the dispatcher 20_q corresponding to the same request source 10_q (i.e., the resource quantity of the competitive resource specified by the corresponding request source 10_q), and, based on the updating and maintenance of the recorded dispatch path, determine whether all independent authorization information allowing the corresponding request source 10_q to handshake with all specified competitive resources has been collected.

[0090] For example, such as Figure 4 As shown, each assembler 30_q (i.e., the assembler 30_q corresponding to each request source 10_q) among the multiple assemblers 30_1~30~M can be specifically configured to: in response to a collection operation of independent authorization information that allows the corresponding request source 10_q to handshake with each specified competing resource, perform a subtraction operation (i.e., decrement by 1) on the recorded dispatch path count; and, in response to the recorded dispatch path count being zero, determine that all independent authorization information that allows the corresponding request source 10_q to handshake with all specified competing resources has been collected.

[0091] Embodiments of this application also provide a multi-way arbitration method for a processor. The processor employing this method can adopt a multi-way arbitration topology, meaning the processor can include multiple request sources and multiple arbitrators corresponding one-to-one with multiple competing resources shared by the multiple request sources. Each request source is configured to initiate an arbitration request with at least one competing resource specified among the multiple competing resources as the handshake object. Each arbitrator is configured to authorize arbitration of all arbitration requests with the corresponding competing resource as the handshake object and generate independent authorization information allowing the request source authorized through authorized arbitration to handshake with the corresponding competing resource. Furthermore, the multi-way arbitration method also configures multiple dispatchers and multiple assemblers corresponding one-to-one with the multiple request sources in the processor. For example, the configuration of the processor employing this multi-way arbitration method can be found in the processor described above.

[0092] Figure 5 This is an exemplary flowchart illustrating a multi-way arbitration method for a processor according to an embodiment of this application. Figure 5 As shown, this multi-way arbitration method may include:

[0093] S510: Using the request instruction generated by each dispatcher based on the corresponding request source, an arbitration application with each specified competitive resource as the handshake object is dispatched to the request source; wherein, the request instruction generated by each request source is used to represent at least one competitive resource specified by the request source among multiple competitive resources, and the arbitration application of any request source with any competitive resource as the handshake object is dispatched to the arbitrator corresponding to the competitive resource.

[0094] S530: Utilize each assembler to collect independent authorization information that allows the corresponding request source to handshake with each specified competing resource;

[0095] S550: In response to the completion of collecting all the independent authorization information that allows the corresponding request source to handshake with all specified competing resources, each assembler assembles all the collected independent authorization information into a merged authorization information to indicate that the corresponding request source has completed the handshake with all specified competing resources.

[0096] Based on embodiments of this application, for a processor employing a multi-arbitration topology, if any requesting source needs to handshake with multiple competing resources, the requesting source can simultaneously initiate multi-arbitration requests to the corresponding multiple arbitrators. Furthermore, the multi-arbitration requests of the requesting source do not necessarily require simultaneous authorization by the corresponding multiple arbitrators; instead, multiple arbitrators can implement independent authorization (e.g., synchronous or asynchronous authorization) in a decoupled manner. Therefore, the handshakes between the requesting source and the multiple competing resources in response to the independent authorization of the multiple arbitrators can also be implemented independently and decoupled from each other. Moreover, the assembler in the processor can assemble the independent authorization information generated by the multiple arbitrators into fused authorization information equivalent to the synchronous authorization information. Thus, without affecting the data transmission mechanism, the data transmission rate can be prevented from being reduced due to waiting for simultaneous authorization from multiple arbitrators, thereby helping to improve the overall efficiency of the processor that is reduced due to multi-arbitration.

[0097] For example, in an embodiment of this application, S510 of the multiple arbitration method may include: periodically dispatching arbitration requests with each specified competing resource as the handshake object using each dispatcher until independent authorization information is generated that allows the corresponding request source to handshake with the competing resource.

[0098] For example, in an embodiment of this application, in order to facilitate single-channel control of arbitration applications dispatched by each dispatcher, the multi-channel arbitration method may further include: using the collection results of independent authorization information by each dispatcher based on the assembler corresponding to the same request source, or determining the generated independent authorization information based on the independent authorization information received by the corresponding request source.

[0099] For example, in an embodiment of this application, a handshake between any request source and a specified competing resource is used to trigger the execution of a target operation, which is associated with the transmission of data in the channel where the request source resides to the downstream side of the request source. In this case, in order to optimize the arbitration authorization result of the competing resource to further improve the overall processing efficiency of the processor, S510 of the multiple arbitration method may include: using each dispatcher to control the enable state of the dispatch operation (e.g., periodic dispatch) according to the downstream state of the corresponding request source; wherein, the downstream state of any request source includes normal and blocked, the dispatch operation (e.g., periodic dispatch) of each dispatcher is enabled when the downstream state of the corresponding request source is normal, and the dispatch operation (e.g., periodic dispatch) of each dispatcher is deenabled when the downstream state of the corresponding request source is blocked, so as to achieve global control over the dispatch operation of each dispatcher.

[0100] For example, in an embodiment of this application, the fusion authorization information assembled by each assembler can be transmitted to the downstream channel of the corresponding request source when the downstream side status of the corresponding request source is normal; wherein, the transmission of the fusion authorization information assembled by each assembler is halted when the downstream side status of the corresponding request source is blocked. In this case, to facilitate the distributor's detection of the transmission status, the multiple arbitration method may further include: using each distributor to detect the fusion authorization information assembled in response to the previous request instruction of the corresponding request source in the assembler corresponding to the same request source; wherein, if the fusion authorization information assembled in response to the previous request instruction of the corresponding request source has been transmitted, then the downstream side status of the corresponding request source is determined to be normal; if the fusion authorization information assembled in response to the previous request instruction of the corresponding request source has not yet been transmitted, then the downstream side status of the corresponding request source is determined to be blocked.

[0101] For example, in an embodiment of this application, in order to facilitate the execution of S530, the multiple arbitration method may further include: using each assembler to dispatch the arbitration application to the arbitrator corresponding to the specified competing resource according to the dispatcher corresponding to the same request source, and determining whether all independent authorization information that allows the corresponding request source to handshake with all specified competing resources has been collected.

[0102] For example, in an embodiment of this application, the multiple arbitration method further includes: providing each dispatcher with a dispatch path for dispatching arbitration applications to an arbitrator corresponding to a specified competing resource to an assembler corresponding to the same request source. In this case, the multiple arbitration method, by utilizing the dispatch path provided by each assembler for dispatching arbitration applications to an arbitrator corresponding to a specified competing resource based on the dispatcher corresponding to the same request source, determines whether all independent authorization information allowing the corresponding request source to handshake with all specified competing resources has been collected. This step may include: using each assembler to record the dispatch path provided by the dispatcher corresponding to the same request source, and using each assembler to determine whether all independent authorization information allowing the corresponding request source to handshake with all specified competing resources has been collected based on the updating and maintenance of the recorded dispatch path.

[0103] For example, in an embodiment of this application, the multi-way arbitration method utilizes the step of each assembler to determine whether all independent authorization information allowing the corresponding request source to handshake with all designated competing resources has been collected based on the update and maintenance of the recorded dispatch path count. This step may include: in response to a collection operation of the independent authorization information allowing the corresponding request source to handshake with each designated competing resource, performing a subtraction operation on the recorded dispatch path count; and in response to the recorded dispatch path count being zero, determining that all independent authorization information allowing the corresponding request source to handshake with all designated competing resources has been collected.

[0104] In another embodiment of this application, an electronic device is also provided, which may include the processor in the foregoing embodiments, or may include a processor for performing the multi-way arbitration method in the above embodiments.

[0105] It is understood that, in the embodiments of this application, the various parts described by example may be related by an "and / or" relationship. In this document, "and / or" means that the contexts connected by it may be a common "and" relationship or an alternative "or" relationship. Therefore, the various parts having an "and / or" relationship can be understood to include different combinations of situations where the "and / or" between each pair of parts represents a common "and" relationship or an alternative "or" relationship, and such combinations of different situations can be considered substantially equivalent to the scope of "at least one of the parts".

[0106] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A processor, characterized in that, include: Multiple request sources, each configured to generate a request instruction; wherein the request instruction generated by each request source is used to characterize at least one competing resource specified by that request source among multiple competing resources shared by the multiple request sources; Multiple dispatchers, each dispatcher corresponding to a multiple request source, and each dispatcher is configured to dispatch an arbitration request to the request source based on the request instruction generated by the corresponding request source, with each specified competitive resource as the handshake object; Multiple arbitrators are associated with multiple competing resources. Any arbitrator request with any competing resource as the handshake object is dispatched to the arbitrator corresponding to that competing resource. Each arbitrator is configured to: authorize arbitration of all arbitration requests with the corresponding competing resource as the handshake object, and generate independent authorization information for the arbitrator that is authorized through authorized arbitration, allowing the arbitrator to handshake with the corresponding competing resource. Multiple assemblers, each corresponding to a request source, are configured to: collect independent authorization information that allows the corresponding request source to handshake with each specified competing resource; and, in response to the completion of the collection of all independent authorization information that allows the corresponding request source to handshake with all specified competing resources, assemble all the collected independent authorization information into a merged authorization information that indicates that the corresponding request source has completed handshake with all specified competing resources.

2. The processor according to claim 1, characterized in that, Each dispatcher is specifically configured to periodically dispatch arbitration requests with each specified competing resource as the handshake target until an independent authorization message is generated allowing the corresponding requesting source to handshake with that competing resource.

3. The processor according to claim 2, characterized in that, Each dispatcher is further configured to: determine the generated independent authorization information based on the collection results of independent authorization information by the assembler corresponding to the same request source; or, Each dispatcher is further configured to determine the generated independent authorization information based on the independent authorization information received from the corresponding request source.

4. The processor according to claim 1, characterized in that, The handshake between any requesting source and a specified competing resource is used to trigger the execution of a target operation, which is associated with the transmission of data in the channel where the requesting source is located to the downstream side of the requesting source; Each dispatcher is further configured to control the enabling state of the dispatch operation based on the downstream state of the corresponding request source; wherein the downstream state of any request source includes normal and blocked, the dispatch operation of each dispatcher is enabled when the downstream state of the corresponding request source is normal, and the dispatch operation of each dispatcher is deenabled when the downstream state of the corresponding request source is blocked.

5. The processor according to claim 4, characterized in that, The fusion authorization information assembled by each assembler is transmitted to the downstream channel of the corresponding request source when the downstream status of the corresponding request source is normal; wherein, the transmission of the fusion authorization information assembled by each assembler is suspended when the downstream status of the corresponding request source is blocked. Each dispatcher is further configured to: detect the fusion authorization information assembled in response to the previous request instruction of the corresponding request source in the assembler corresponding to the same request source; wherein, if the fusion authorization information assembled in response to the previous request instruction of the corresponding request source has been transmitted, then the downstream state of the corresponding request source is determined to be normal; if the fusion authorization information assembled in response to the previous request instruction of the corresponding request source has not been transmitted, then the downstream state of the corresponding request source is determined to be blocked.

6. The processor according to claim 1, characterized in that, Each assembler is further configured to: dispatch arbitration requests to the arbitrator corresponding to the specified competing resource based on the dispatcher corresponding to the same request source, and determine whether all independent authorization information that allows the corresponding request source to handshake with all specified competing resources has been collected.

7. The processor according to claim 6, characterized in that, Each dispatcher is further configured to provide the assembler corresponding to the same request source with a dispatch path to dispatch arbitration requests to the arbitrator corresponding to the specified competing resource; Each assembler is further configured to: record the number of dispatch paths provided by dispatchers corresponding to the same request source, and, based on the updating and maintenance of the recorded number of dispatch paths, determine whether all independent authorization information allowing the corresponding request source to handshake with all specified competing resources has been collected.

8. The processor according to claim 7, characterized in that, Each assembler is specifically configured to: perform a subtraction operation on the recorded dispatch path count in response to a collection operation of independent authorization information that allows the corresponding request source to handshake with each specified competing resource; and determine that all independent authorization information that allows the corresponding request source to handshake with all specified competing resources has been collected in response to the recorded dispatch path count being zero due to the subtraction operation.

9. The processor according to claim 1, characterized in that, Multiple competing resources include multiple executors, each executor being configured to: in response to a successful handshake with any requesting source, execute an access operation initiated by that requesting source to a specified storage space; wherein the target operation triggered by the handshake between any requesting source and the specified competing resource includes the access operation initiated by that requesting source to the specified storage space; or, Each assembler is further configured to: assemble and merge the operation information generated by the target operation triggered by the handshake between the corresponding request source and all specified competing resources with the fusion authorization information; or, The competing resources specified by multiple request sources are not all the same; or, At least one requesting source specifies that the number of competing resources is at least two.

10. A multi-way arbitration method for a processor, characterized in that, The processor includes multiple request sources and multiple arbitrators corresponding one-to-one with multiple competing resources shared by the multiple request sources. Each request source is configured to initiate an arbitration request with at least one competing resource specified among the multiple competing resources as the handshake object. Each arbitrator is configured to authorize arbitration of all arbitration requests with the corresponding competing resource as the handshake object, and generate independent authorization information for the request source that is authorized through authorized arbitration, allowing the request source to handshake with the corresponding competing resource. The multiple arbitration method configures multiple dispatchers and multiple assemblers corresponding to multiple request sources in the processor, and the multiple arbitration method includes: Each dispatcher uses the request instruction generated by the corresponding request source to dispatch an arbitration application to the request source with each specified competitive resource as the handshake object; wherein, the request instruction generated by each request source is used to represent at least one competitive resource specified by the request source among multiple competitive resources, and the arbitration application of any request source with any competitive resource as the handshake object is dispatched to the arbitrator corresponding to the competitive resource. Each assembler collects independent authorization information that allows the corresponding request source to handshake with each specified competing resource; Each assembler, in response to the completion of collecting all independent authorization information that allows the corresponding request source to handshake with all specified competing resources, assembles all collected independent authorization information into a merged authorization information to indicate that the corresponding request source has completed handshake with all specified competing resources.

Images