Multi-channel driving method and device based on credit handshake, medium and equipment

Abstract

The invention discloses a multi-channel driving method and device based on credit handshake, a medium and equipment. The method comprises the following steps: respectively creating a processing process for processing a corresponding channel queue request for each channel; wherein all the processing processes run in parallel; any processing process is configured as follows: the available credit of the corresponding channel and the current to-be-processed request in the corresponding channel queue are monitored; after determining that the available credit quantity meets the credit demand of the current to-be-processed request, applying for the exclusive use permission of the shared interface; wherein the exclusive use permission has uniqueness, and when the exclusive use permission is not occupied, a plurality of processing processes are allowed to perform preemptive competition; and under the condition that the exclusive use permission is obtained, driving the current to-be-processed request to the shared interface, releasing the exclusive use permission after driving is completed, and entering a processing stage of the next to-be-processed request in the corresponding channel queue. According to the invention, decoupling between channels can be realized, and bandwidth resources of the interface can be utilized to the maximum extent.

Description

Technical Field

[0001] This invention relates to the field of chip verification technology, and in particular to a multi-channel driving method, apparatus, computer-readable storage medium, and electronic device based on a trust handshake. Background Technology

[0002] In the field of chip design verification, when multiple channels share a single interface to drive requests, existing technologies serialize all channels, meaning multiple channels queue up in a preset order to wait for the right to use the interface. If a channel currently occupying an interface is unable to drive a request due to insufficient credits, that channel will continue to occupy the interface, even if other channels have sufficient credits in their dedicated credit pools. These other channels will also be unable to drive requests because the interface is occupied and can only wait for the previous channel to release the interface. Clearly, existing technologies create a strong coupling relationship between channels, resulting in a serious waste of interface bandwidth resources. Summary of the Invention

[0003] The purpose of this invention is to provide a multi-channel driving method, apparatus, computer-readable storage medium, and electronic device based on a trust handshake. By configuring an independent and parallel processing process for each channel and combining a contention and preemption mechanism for exclusive usage rights with an immediate release mechanism, the decoupling between channels can be achieved, maximizing the utilization of interface bandwidth resources, thereby improving the overall processing efficiency of multi-channel requests.

[0004] A first aspect of the present invention provides a multi-channel driving method based on a credit handshake, comprising: A processing process is created for each channel; all processing processes run in parallel, and each processing process is used to handle requests in the corresponding channel queue. Configure any processing process as follows: Monitor the available credits for the corresponding channel and the current pending requests in the corresponding channel queue; After determining that the available credit amount meets the credit requirements of the current pending requests, an exclusive right to use the shared interface is requested; wherein, the exclusive right to use is unique, and multiple processing processes are allowed to compete for the right to use it by requesting it when it is not occupied; Once the exclusive access permission is obtained, the current pending request is driven to the shared interface. After the current pending request is driven to completion, the exclusive access permission is released, and the process enters the next pending request processing stage in the corresponding channel queue.

[0005] Optionally, after requesting exclusive access to the shared interface, each processing process is further configured to: If the exclusive usage rights for the current round are not obtained, wait for the release of the exclusive usage rights in order to re-participate in a new round of competition for the exclusive usage rights.

[0006] Optionally, the exclusive access permission is implemented using semaphores.

[0007] Optionally, after monitoring the available credits of the corresponding channel and the current pending requests in the corresponding channel queue, each processing process is further configured to: When the current pending request is a non-batch continuous request or the first request of a batch continuous request, it is determined whether the available credit amount is greater than or equal to the credit requirement of the current pending request; wherein, the credit requirement corresponding to the first request is the total credit requirement of the batch continuous requests. If so, then it is determined that the available credit amount meets the credit requirements of the current pending request; When the current pending request is not the first request in a batch of continuous requests, it is directly determined that the available credit amount meets the credit requirements of the current pending request.

[0008] Optionally, each channel queue is a first-in-first-out queue.

[0009] Optionally, the requests in each channel queue are obtained by a pre-defined distribution process performing the following steps: Receive a verification incentive request and distribute the verification incentive request to the channel queue corresponding to the channel information according to the channel information corresponding to the verification incentive request.

[0010] Optionally, distributing the verification incentive request to the channel queue corresponding to the channel information based on the channel information corresponding to the verification incentive request includes: When the received verification incentive request is a non-batch continuous request, the non-batch continuous request is directly distributed to the corresponding channel queue according to the channel information carried by the non-batch continuous request. When the received verification incentive request is the first request in a batch of continuous requests, the channel information carried by the first request is recorded, and the first request is distributed to the corresponding channel queue. When the received verification incentive request is a non-first request in a batch of continuous requests, the non-first request is distributed to the channel queue where the first request of the same batch of continuous requests is located, according to the recorded channel information; wherein, the recorded channel information is managed at the granularity of batch of continuous requests.

[0011] A second aspect of the present invention provides a multi-channel driving device based on a credit handshake, comprising: The process creation module is used to create a processing process for each channel; all processing processes run in parallel, and each processing process is used to process the requests in the corresponding channel queue. The process configuration module is used to configure any processing process as follows: The channel monitoring unit is used to monitor the available credits of the corresponding channel and the current pending requests in the corresponding channel queue. The permission application unit is used to apply for exclusive use permission of the shared interface after determining that the available credit amount meets the credit requirements of the current pending request; wherein, the exclusive use permission is unique and multiple processing processes are allowed to compete for the right to use the interface by applying when it is not occupied. The request driving unit is used to drive the current pending request to the shared interface when it obtains the exclusive access permission, and after the current pending request is driven, release the exclusive access permission and enter the processing stage of the next pending request in the corresponding channel queue.

[0012] A third aspect of the present invention provides a computer-readable storage medium comprising a stored computer program; wherein, when the computer program is executed, it controls the device in which the computer-readable storage medium is located to perform the multi-channel driving method based on credit handshake as described in any embodiment of the first aspect.

[0013] A fourth aspect of the present invention provides an electronic device including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor, when executing the computer program, implements the multi-channel driving method based on a credit handshake as described in any embodiment of the first aspect.

[0014] Compared with existing technologies, embodiments of the present invention provide a multi-channel driving method, apparatus, computer-readable storage medium, and electronic device based on credit handshake. Each channel is configured with an independent and parallel processing process, with no execution order dependency or data coupling between processes. The exclusive use of the shared interface is treated as a globally unique resource competed for by all processing processes with sufficient credit and pending requests. This transforms multi-channel request processing from a "serial queuing" approach to a "parallel preemption" approach, eliminating coupling between channels and ensuring that the shared interface is only occupied when a valid request is being transmitted. Furthermore, once the exclusive use is released, a new round of preemption competition immediately begins, preventing idle interface bandwidth resources. Therefore, embodiments of the present invention can achieve decoupling between channels, maximizing the utilization of interface bandwidth resources, thereby improving the overall processing efficiency of multi-channel requests. Attached Figure Description

[0015] Figure 1This is a flowchart illustrating an embodiment of the multi-channel driving method based on credit handshake provided by the present invention; Figure 2 This is a flowchart illustrating another embodiment of the multi-channel driving method based on credit handshake provided by the present invention; Figure 3 This is a schematic diagram of the structure of an embodiment of the multi-channel driving device based on credit handshake provided by the present invention; Figure 4 This is a schematic diagram of the structure of an embodiment of the electronic device provided by the present invention. Detailed Implementation

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

[0017] The "credit handshake mechanism" involved in this invention is as follows: The Design Under Test (DUT) first informs the verification environment of the current amount of credits available for a certain channel (equivalent to the transmission limit granted to the channel); the available credits of the channel change with the amount of credits available to the DUT, and when there are sufficient available credits, a request is driven to the interface, that is, the request is output to the physical / logical signal lines of the interface in a manner specified by the protocol, so that the DUT can recognize and receive the request; each time a request is driven, the channel and the DUT will consume a certain amount of credits, and the DUT will return the credits after processing the request, that is, complete one "handshake" cycle.

[0018] See Figure 1 This is a flowchart illustrating an embodiment of the multi-channel driving method based on credit handshake provided by the present invention.

[0019] A first aspect of the present invention provides a multi-channel driving method based on a credit handshake, including steps S1 to S2, as follows: Step S1: Create a processing process for each channel; all processing processes run in parallel, and each processing process is used to process the requests in the corresponding channel queue; Step S2: Configure any processing process as follows: Monitor the available credits for the corresponding channel and the current pending requests in the corresponding channel queue; After determining that the available credit amount meets the credit requirements of the current pending requests, an exclusive right to use the shared interface is requested; wherein, the exclusive right to use is unique, and multiple processing processes are allowed to compete for the right to use it by requesting it when it is not occupied; Once the exclusive access permission is obtained, the current pending request is driven to the shared interface. After the current pending request is driven to completion, the exclusive access permission is released, and the process enters the next pending request processing stage in the corresponding channel queue.

[0020] It should be noted that the processing processes of each channel run independently and in parallel, with no direct execution dependencies or order constraints, and no data coupling between them. Each processing process has a one-to-one binding relationship with its corresponding channel queue; the channel queue is used to cache verification stimulus requests generated by verification stimulus generators (such as Universal Verification Methodology Sequence (UVM Sequence)).

[0021] In this embodiment of the invention, any processing process is configured as a request-driven loop, as follows: The processing process continuously monitors the available credits of the corresponding channel (i.e., the amount of credits that the channel currently holds that can be used to send requests to the DUT), and whether there are any pending requests (the requests at the head of the channel queue) in the channel queue to which the processing process is bound. When a processing process determines that the available credits for the corresponding channel meet the credit requirements of the current pending requests, it immediately initiates an application for exclusive use of the shared interface. This exclusive use is globally unique and exclusive, meaning it can only be held by one processing process at a time, ensuring that the shared interface is occupied by at most one channel at any given time. All processing processes with sufficient credits and pending requests (i.e., those meeting the driving conditions) can initiate an application, and allocation is handled through a contention-based preemption mechanism. If a processing process successfully acquires exclusive access during contention, it will drive the currently pending request to the shared interface according to the interface protocol specification (using non-blocking process assignment in SystemVerilog syntax). After the current request is driven, the processing process immediately releases its exclusive access and enters the processing stage of the next pending request in the corresponding channel queue. Once the exclusive access is released, other processing processes that meet the credit conditions and have pending requests will initiate a new round of access contention, achieving efficient recycling of interface bandwidth resources. Therefore, each processing process, after acquiring exclusive access, processes only one pending request before releasing the access.

[0022] As can be seen from the above, the embodiments of the present invention configure independent and parallel processing processes for each channel, with no execution order dependency or data coupling relationship between the processes; the exclusive use right of the shared interface is used as a globally unique resource that all processing processes with sufficient credit and pending requests compete for, thereby transforming the multi-channel request processing from a "serial queuing" mode to a "parallel preemption" mode. There is no coupling relationship between the channels, and it is ensured that the shared interface is only occupied when there is a valid transmission request, and a new round of preemption competition immediately begins after the exclusive use right is released, avoiding the idleness of interface bandwidth resources. Therefore, the embodiments of the present invention can achieve decoupling between channels, maximize the utilization of interface bandwidth resources, and thus improve the overall processing efficiency of multi-channel requests.

[0023] Compared to methods that process all channels serially, assuming the same number of available credits for each channel, for the case of 3 channels, even in the worst-case scenario, the interface bandwidth utilization of this embodiment can still be improved by 66%.

[0024] In an optional embodiment, after requesting exclusive access to the shared interface, each processing process is further configured to: If the exclusive usage rights for the current round are not obtained, wait for the release of the exclusive usage rights in order to re-participate in a new round of competition for the exclusive usage rights.

[0025] It should be noted that when a processing process initiates a request for exclusive usage rights, if the arbitration result shows that the processing process does not obtain the exclusive usage rights for the current round (i.e., the exclusive usage rights are obtained by another processing process that applied at the same time and also met the credit conditions), then the processing process enters a waiting state. Once the exclusive usage rights are released by the processing process currently holding them, the processing process in the waiting state will participate in a new round of competition for usage rights.

[0026] In an optional embodiment, the exclusive access is implemented using semaphores.

[0027] It's important to note that when any processing process detects that its corresponding channel has sufficient credit and there are pending requests in the channel queue—that is, when the driving conditions are met—it will request a semaphore. The semaphore acts like a lock with only one key. Therefore, only one processing process among all those requesting the key can successfully acquire it. Only the channel that obtains the key is eligible to use the shared interface. At this point, the processing process of that channel will drive the current pending requests onto the shared interface, and upon completion, release the key for other channel processing processes to claim.

[0028] It is worth noting that "flag signals" are merely one example of implementing exclusive access permissions, not the only one. Any mechanism that can ensure "only one entity is authorized to access at any given time" can be used as an implementation method for exclusive access permissions, such as mutex locks or globally unique identifier tokens.

[0029] In an optional embodiment, after monitoring the available credits of the corresponding channel and the current pending requests in the corresponding channel queue, each processing process is further configured to: When the current pending request is a non-batch continuous request or the first request of a batch continuous request, it is determined whether the available credit amount is greater than or equal to the credit requirement of the current pending request; wherein, the credit requirement corresponding to the first request is the total credit requirement of the batch continuous requests. If so, then it is determined that the available credit amount meets the credit requirements of the current pending request; When the current pending request is not the first request in a batch of continuous requests, it is directly determined that the available credit amount meets the credit requirements of the current pending request.

[0030] like Figure 2 The diagram shown is a flowchart of another embodiment of the multi-channel driving method based on credit handshake provided by the present invention. Figure 2 In this embodiment, processes 0 through N are parallel processes created using SystemVerilog's parallel technology, and these processes are independent of each other. Process 0 is the distribution process, responsible for receiving verification incentive requests generated by the UVM Sequence and pushing them to different channel queues. Processes 1 through N are processing processes, responsible for processing requests from each channel, including waiting for requests, determining credit, and handling other driving conditions. The technical solution provided by this embodiment will be described below using process 1 as an example: Process 1 first checks if its dedicated channel request queue is empty. If empty, Process 1 will loop through the queue until a request arrives. If not empty, Process 1 determines if the current request to be processed is a sub-request of a batch request. If it is not a sub-request, it indicates that the current request to be processed is a non-burst request (i.e., an independent request), and it directly enters the credit determination stage. Specifically, the credit determination stage involves: determining whether the corresponding channel has sufficient credit (i.e., determining whether the available credit of the channel is greater than or equal to the credit requirement of the current request to be processed). If the credit is insufficient, Process 1 will loop through or block until sufficient credit is replenished (credit is returned from the DUT). If the credit is sufficient, it requests a semaphore and waits to receive the semaphore. If it is a sub-request, it further determines whether it is the first request of a burst request.

[0031] If it's the first burst request, it enters the credit check phase as well, where the credit requirement is checked as the total credit requirement for the entire burst request. If it's not the first burst request, it directly requests a semaphore and waits to acquire it. This is because the credit check phase of each burst request already includes a pre-verification of the credit requirements for all subsequent sub-requests within the entire burst request; subsequent sub-requests do not need to check the credit again, thus avoiding the efficiency loss caused by redundant verification. In short, for burst requests, the credit check phase only occurs for the first request; subsequent sub-requests skip this phase and directly compete for permissions.

[0032] Once process 1 successfully acquires the semaphore, it immediately drives the currently pending request to the shared interface and pops it from the channel queue. The channel queue is a first-in, first-out queue; after the current pending request is removed, the next pending request will become the current pending request in the next stage. After process 1 has driven the current pending request, it immediately releases the semaphore (allowing other processing processes to compete for it) and returns to the starting point of the entire process loop to begin processing the next pending request in the corresponding channel queue.

[0033] It should be noted that since the execution flow of processes 2 to N is the same as that of process 1, it will not be elaborated further here.

[0034] In an optional embodiment, the requests in each channel queue are obtained by a pre-defined distribution process performing the following steps: Receive a verification incentive request and distribute the verification incentive request to the channel queue corresponding to the channel information according to the channel information corresponding to the verification incentive request.

[0035] Further, the step of distributing the verification incentive request to the channel queue corresponding to the channel information based on the channel information corresponding to the verification incentive request includes: When the received verification incentive request is a non-batch continuous request, the non-batch continuous request is directly distributed to the corresponding channel queue according to the channel information carried by the non-batch continuous request. When the received verification incentive request is the first request in a batch of continuous requests, the channel information carried by the first request is recorded, and the first request is distributed to the corresponding channel queue. When the received verification incentive request is a non-first request in a batch of continuous requests, the non-first request is distributed to the channel queue where the first request of the same batch of continuous requests is located, according to the recorded channel information; wherein, the recorded channel information is managed at the granularity of batch of continuous requests.

[0036] It should be noted that the embodiments of the present invention are applied to the stimulus driving between the verification environment and the DUT, through a dedicated distribution process (corresponding to...). Figure 2 Process 0 in the process accurately and orderly delivers "non-batch continuous requests (independent requests) + burst requests" to the target channel queue for subsequent processing processes to call.

[0037] In specific implementation, such as Figure 2 As shown, after process 0 starts, it enters a loop to continuously receive verification incentive requests. Each time a verification incentive request is received, it is determined whether it is a sub-request of a burst request. If not, it indicates that the current verification incentive request is a non-batch continuous request and it is directly distributed to the corresponding channel queue. If it is, it enters the "record burst status - associate channel information - clear status" step, because the burst request only carries channel information in the first request.

[0038] The "record burst state - associate channel information - clear state" process is as follows: First, determine if the current verification incentive request is the first request in a burst request. If it is, record the burst state by channel (i.e., extract and record the channel information carried by the first request) and continue distributing the first request to the corresponding channel queue. If it is not the first request, determine if the current verification incentive request is the last request in a burst request. If it is not the last request, directly distribute the request based on the recorded channel information; otherwise, for the current burst request, clear the recorded burst state and distribute the last request to the corresponding channel queue. Clearly, the channel information recorded for the first request in a burst request is managed at the granularity of the entire burst request. That is, from the arrival of the first request until the last request of the burst request is processed and the record is cleared, this channel information remains valid for all sub-requests of the burst request.

[0039] See Figure 3 This is a schematic diagram of an embodiment of the multi-channel driving device based on credit handshake provided by the present invention.

[0040] A second aspect of the present invention provides a multi-channel driving device based on a credit handshake, comprising: The process creation module 11 is used to create a processing process for each channel; all processing processes run in parallel, and each processing process is used to process the requests in the corresponding channel queue. Processing process configuration module 12 is used to configure any processing process as follows: The channel monitoring unit 121 is used to monitor the available credits of the corresponding channel and the current pending requests in the corresponding channel queue; The permission application unit 122 is used to apply for exclusive use permission of the shared interface after determining that the available credit amount meets the credit requirements of the current pending request; wherein, the exclusive use permission is unique and allows multiple processing processes to compete for the right to use the interface through application when it is not occupied. The request driving unit 123 is used to drive the current pending request to the shared interface when it obtains the exclusive use permission, and after the current pending request is driven, release the exclusive use permission and enter the processing stage of the next pending request in the corresponding channel queue.

[0041] It should be noted that the multi-channel driving device based on credit handshake provided in the second aspect embodiment of the present invention can realize all the processes of the multi-channel driving method based on credit handshake described in any of the first aspect embodiments. The functions and technical effects of each module and unit in the device are the same as the functions and technical effects of the multi-channel driving method based on credit handshake described in any of the first aspect embodiments, and will not be repeated here.

[0042] A third aspect of the present invention provides a computer-readable storage medium comprising a stored computer program; wherein, when the computer program is executed, it controls the device on which the computer-readable storage medium is located to perform the multi-channel driving method based on credit handshake described in any of the first aspects of the present invention.

[0043] See Figure 4 This is a schematic diagram of an embodiment of the electronic device provided by the present invention.

[0044] A fourth aspect of the present invention provides an electronic device including a processor 21, a memory 22, and a computer program stored in the memory 22 and configured to be executed by the processor 21, wherein the processor, when executing the computer program, implements the multi-channel driving method based on credit handshake described in any of the first aspects of the present invention.

[0045] Preferably, the computer program can be divided into one or more modules / units (such as computer program one, computer program two, ...), and the one or more modules / units are stored in the memory 22 and executed by the processor 21 to complete the present invention. The one or more modules / units can be a series of computer program instruction segments capable of performing specific functions, and the instruction segments are used to describe the execution process of the computer program in the electronic device.

[0046] The processor 21 can be any one of a CPU (Central Processing Unit), 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 Unit). The processor 21 is the control center of the electronic device, connecting various parts of the electronic device via various interfaces and lines.

[0047] The memory 22 mainly includes a program storage area and a data storage area. The program storage area can store the operating system, applications required for at least one function, etc., and the data storage area can store related data, etc. In addition, the memory 22 can be a high-speed random access memory, or a non-volatile memory, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, and a flash card, etc., or the memory 22 can also be other volatile solid-state storage devices.

[0048] It should be noted that the aforementioned electronic devices may include, but are not limited to, processors and memory, as will be understood by those skilled in the art. Figure 4 The structural block diagram shown is merely a structural example of the above-described electronic device and does not constitute a limitation on the structure of the above-described electronic device. The above-described electronic device may include more or fewer components than shown, or combine certain components, or different components.

[0049] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A multi-channel driving method based on credit handshake, characterized in that, include: A processing process is created for each channel; all processing processes run in parallel, and each processing process is used to handle requests in the corresponding channel queue. Configure any processing process as follows: Monitor the available credits for the corresponding channel and the current pending requests in the corresponding channel queue; After determining that the available credit amount meets the credit requirements of the current pending requests, an exclusive right to use the shared interface is requested; wherein, the exclusive right to use is unique, and multiple processing processes are allowed to compete for the right to use it by requesting it when it is not occupied. Once the exclusive access permission is obtained, the current pending request is driven to the shared interface. After the current pending request is driven to completion, the exclusive access permission is released, and the process enters the next pending request processing stage in the corresponding channel queue.

2. The multi-channel driving method based on credit handshake as described in claim 1, characterized in that, After requesting exclusive access to the shared interface, each processing process is further configured as follows: If the exclusive usage rights for the current round are not obtained, wait for the release of the exclusive usage rights in order to re-participate in a new round of competition for the exclusive usage rights.

3. The multi-channel driving method based on credit handshake as described in claim 1, characterized in that, The exclusive usage rights are implemented using semaphore.

4. The multi-channel driving method based on credit handshake as described in claim 1, characterized in that, After monitoring the available credits of the corresponding channel and the current pending requests in the corresponding channel queue, each processing process is further configured as follows: When the current pending request is a non-batch continuous request or the first request of a batch continuous request, it is determined whether the available credit amount is greater than or equal to the credit requirement of the current pending request; wherein, the credit requirement corresponding to the first request is the total credit requirement of the batch continuous requests. If so, then it is determined that the available credit amount meets the credit requirements of the current pending request; When the current pending request is not the first request in a batch of continuous requests, it is directly determined that the available credit amount meets the credit requirements of the current pending request.

5. The multi-channel driving method based on credit handshake as described in claim 1, characterized in that, Each channel queue is a first-in-first-out queue.

6. The multi-channel driving method based on credit handshake as described in claim 1, characterized in that, The requests in each channel queue are obtained by a pre-defined distribution process performing the following steps: Receive a verification incentive request and distribute the verification incentive request to the channel queue corresponding to the channel information according to the channel information corresponding to the verification incentive request.

7. The multi-channel driving method based on credit handshake as described in claim 6, characterized in that, The step of distributing the verification incentive request to the channel queue corresponding to the channel information based on the channel information includes: When the received verification incentive request is a non-batch continuous request, the non-batch continuous request is directly distributed to the corresponding channel queue according to the channel information carried by the non-batch continuous request. When the received verification incentive request is the first request in a batch of continuous requests, the channel information carried by the first request is recorded, and the first request is distributed to the corresponding channel queue. When the received verification incentive request is a non-first request in a batch of continuous requests, the non-first request is distributed to the channel queue where the first request of the same batch of continuous requests is located, according to the recorded channel information; wherein, the recorded channel information is managed at the granularity of batch of continuous requests.

8. A multi-channel driving device based on credit handshake, characterized in that, include: The process creation module is used to create a processing process for each channel; all processing processes run in parallel, and each processing process is used to process the requests in the corresponding channel queue. The process configuration module is used to configure any processing process as follows: The channel monitoring unit is used to monitor the available credits of the corresponding channel and the current pending requests in the corresponding channel queue. The permission application unit is used to apply for exclusive use permission of the shared interface after determining that the available credit amount meets the credit requirements of the current pending request; wherein, the exclusive use permission is unique and multiple processing processes are allowed to compete for the right to use the interface by applying when it is not occupied. The request driving unit is used to drive the current pending request to the shared interface when it obtains the exclusive use permission, and release the exclusive use permission after the current pending request is driven, and enter the processing stage of the next pending request in the corresponding channel queue.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored computer program; wherein, when the computer program is executed, it controls the device on which the computer-readable storage medium resides to perform the multi-channel driving method based on credit handshake as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, The method includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor, when executing the computer program, implements the multi-channel driving method based on a credit handshake as described in any one of claims 1 to 7.

Images