Command stream generation method, test method and related product

Abstract

The invention provides a command stream generation method, a test method and device based on a command stream, electronic equipment, a computer readable storage medium and a computer program product, and relates to the technical field of processor test. According to the command stream generated by the application, commands in the same command set are respectively packaged into command queues, command subsets in the command queues are obtained, and Fint synchronization commands are inserted into the tail ends of the command subsets of the command queues; the commands in the command set can have a dependency relationship, and the commands in the command set generated at each time do not have a dependency relationship with the commands in the command set generated at other times. According to the method, the generated command stream is better in randomness, higher in dependency solvability and lower in occurrence risk of a command deadlock problem.

Description

Technical Field

[0001] This application relates to the field of processor testing technology, and more specifically, to a command stream generation method, a command stream-based testing method, an apparatus, an electronic device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] Currently, for processors that provide highly parallel computing, such as GPUs (Graphics Processing Units), GPGPUs (General-purpose computing on graphics processing), NPUs (Neural Network Processing Units), and TPUs (Tensor Processing Units), it is necessary to construct a command stream that can be allocated to different execution units for simultaneous execution during RTL (Register Transfer Level) testing or C language-based simulation testing.

[0003] Currently, there are generally two ways to generate command streams. The first is for verification engineers to manually construct the command stream line by line, and the second is to generate the command stream through the CUDA (Compute Unified Device Architecture) programming model.

[0004] The first approach requires significant effort from verification engineers, is labor-intensive, and prone to errors, making it difficult to guarantee its correctness and completeness. Furthermore, once the command flow is constructed, it is typically not modified for the same test scenarios, resulting in poor randomness during testing. In addition, the dependencies within the command flow are complex, and this approach relies entirely on verification engineers to manually manage these dependencies, which can easily lead to improper dependency management and command deadlocks, impacting verification efficiency and reliability.

[0005] The second approach requires engineers to have a deep understanding of the CUDA programming model and have completed full integration with the underlying software stack; otherwise, they cannot correctly use the CUDA programming model to generate command streams, making this approach technically more challenging. Furthermore, the command streams generated by the CUDA programming model are relatively fixed, and are typically not modified for the same test scenarios, resulting in poor randomness during testing. Also, when generating command streams based on the CUDA programming model, command deadlock issues due to improper dependency management are also prone to occur. Summary of the Invention

[0006] The purpose of this application is to provide a command stream generation method, a command stream-based testing method, an apparatus, an electronic device, a computer-readable storage medium, and a computer program product, so as to at least partially solve the above-mentioned problems.

[0007] In a first aspect, embodiments of this application provide a command stream generation method, comprising: randomly generating a command set based on each command subclass; the commands in the command set may have dependencies on each other, and the commands in the command set do not include Fence synchronization commands; encapsulating each command in the command set into each command queue to obtain a command subset in each command queue, and inserting a Fence synchronization command at the end of the command subset in each command queue; repeating the above process until a preset termination condition is met to obtain the command stream; wherein, the commands in each generated command set have no dependencies on the commands in other generated command sets; and when the command stream is issued, commands in different command queues can be issued in parallel, and commands in the same command queue are issued sequentially.

[0008] In the above implementation scheme, since each generated command set does not include a Fence synchronization command, continuous execution and parallel distribution are allowed among the command subsets distributed to each command queue. Because a Fence synchronization command is inserted at the end of each command subset in each command queue, commands in the next command subset can only be executed after the commands in the previous command set have been completed, thus improving the execution synchronization between command subsets within the same command set. Furthermore, since the commands in each generated command set have no dependencies on commands in other generated command sets, logical decoupling between command sets is achieved, preventing dependencies from propagating across command sets, effectively cutting off potential deadlock chains, and reducing the risk of deadlock. Therefore, the scheme provided by this application embodiment, compared to the first scheme in related technologies, eliminates the need for verification engineers to manually construct command flows, effectively reducing labor costs and improving the efficiency of command flow generation. Compared to the second approach in related technologies, this method requires no in-depth understanding of the CUDA programming model from engineers, nor does it require full integration with the underlying software stack, resulting in a lower technical barrier and greater versatility. Furthermore, the solution presented in this application can randomly generate the required command flow for each test, offering better randomness and thus improving test coverage and effectiveness. Simultaneously, in this application's solution, dependencies are concentrated within each command set, with no dependencies between command sets, effectively reducing the complexity of dependencies, improving the solvability of dependencies in the command flow, and lowering the risk of command deadlock.

[0009] Optionally, the command stream includes multiple command groups; each command group includes multiple command queues; each command in each generated command set is encapsulated into a command queue belonging to the same command group; a link-to connection relationship can be configured between command queues in different command groups; the method further includes configuring a link-to connection relationship between two command queues in different command groups.

[0010] In the above implementation, by setting up command groups and configuring Link-to connections between two command queues in different command groups, the adjacency relationship between command queues can be tested through Link-to connection configuration for scenarios such as multi-task scheduling. This meets the testing requirements of such scenarios and increases the manageability of commands in these scenarios.

[0011] Optionally, each time a command in the command set is encapsulated into a command queue, the setting commands in the command set are encapsulated into a first target command queue; the first target command queue is one of all command queues.

[0012] In the above implementation, by encapsulating all setting commands into the same command queue, setting commands can only be initiated within the same queue. Since commands within the same queue are issued and executed sequentially, this avoids the problem of multiple setting commands that should have a specific order being issued and executed in parallel due to being assigned to different command queues, which could lead to errors in the execution results. This also avoids the risk of dependency disorder caused by the uncertainty of command execution order due to the parallel issuance of commands by different command queues in a parallel execution environment.

[0013] Optionally, the commands include setting commands and wait commands, and each wait command corresponds to a setting command; for each wait command, the value of the wait command is updated as the setting command corresponding to the wait command is executed.

[0014] In the above implementation, the value of the wait class command is updated as the corresponding setting class command is executed. Since the setting class commands are located in the same command queue and are issued and executed sequentially, the correctness of the value of the wait class command can be improved. This improves the logical solvability of the dependencies in the command set and reduces the risk of execution stagnation or command deadlock caused by mismatched wait values.

[0015] Optionally, each command subclass includes at least one of the following: Compute_kernel (computation task set), Flush_invert (memory flush), Dynamic_lautch (dynamic loading), Terminate (termination), Cfg_update (configuration update), Jump (jump), Nop (empty command), and Linear_copy (continuous copy).

[0016] In the above implementation, the random generation of command sets through the various command subclasses can provide a richer variety of commands, thereby enabling the generated command stream to cover more scenarios and achieving higher test coverage.

[0017] Optionally, the command stream is a first test command stream for performing RTL testing, or the command stream is a second test command stream for performing C language-based simulation testing.

[0018] Secondly, embodiments of this application also provide a command stream-based testing method, comprising: sending each command in the command stream to each execution unit of the device under test (DUT); wherein the command stream is a command stream generated according to any of the methods described in the first aspect; commands in different command queues in the command stream are sent in parallel, and commands in the same command queue are sent sequentially; and the test result is determined based on the execution status of each command in the command stream by each execution unit.

[0019] In the above implementation, testing is performed using command streams generated based on any of the methods in the first aspect. Since the command streams used for testing have better randomness, this improves the randomness of the tests and increases coverage. Furthermore, because the command streams used for testing have a lower risk of command deadlock, the probability of the tests completing normally is increased, thus improving testing efficiency.

[0020] Optionally, when the command stream includes multiple command groups and there are Link-to connections between command queues in different command groups: in multiple second target command queues configured with Link-to connections, if the command of the first second target command queue in the Link-to connection is issued, but the command of the second target command queue in the Link-to connection is not issued, then the command of the second target command queue in the Link-to connection is issued.

[0021] The above implementation method can be used to test the adjacency relationship between command queues, meeting the testing requirements of this type of scenario.

[0022] Optionally, in the same command queue, for multiple target commands with dependencies, the subsequent target commands are issued after the first target command has been executed.

[0023] In the above implementation, for multiple dependent target commands within the same command queue, subsequent target commands are sent out only after the first target command has been executed. This ensures that dependent target commands are executed in the correct order, avoiding execution order errors caused by parallel command sending and improving the reliability and accuracy of testing.

[0024] Optionally, after sending each command in the command stream to each execution unit of the device under test (DUT), the method further includes: for any set of commands, after all commands in the command set have been sent, updating the values ​​of all wait-type commands in the command set to the final values ​​of the setting-type commands corresponding to the wait-type commands.

[0025] In the above implementation, for any command set, after all commands in the command set have been issued, the values ​​of all wait-type commands in the command set are uniformly updated to the final values ​​of the corresponding setting-type commands. This improves the correctness of the wait-type command values, thereby enhancing the logical solvability of the dependencies within the command set and reducing the risk of execution stalls or command deadlocks caused by mismatched wait values.

[0026] Thirdly, embodiments of this application also provide a command stream generation apparatus, comprising: a command generation module, configured to randomly generate a command set based on each command subclass; the commands in the command set may have dependencies on each other, and the commands in the command set do not include a fence synchronization command; an encapsulation module, configured to encapsulate each command in the command set into a command queue, obtaining a command subset in each command queue, and inserting a fence synchronization command at the end of the command subset in each command queue; the command generation module and the encapsulation module are configured to continuously repeat the above process until a preset termination condition is met, thereby obtaining the command stream; wherein, the commands in each generated command set do not have dependencies on the commands in other generated command sets; and when the command stream is issued, commands in different command queues can be issued in parallel, and commands in the same command queue are issued sequentially.

[0027] The command stream generation device described above has the same technical effect as the first aspect described above, so it will not be described again here.

[0028] Fourthly, embodiments of this application also provide a test apparatus based on a command stream, characterized in that it includes: a distribution module, used to send each command in the command stream to each execution unit of the device under test (DUT); wherein the command stream is a command stream generated according to any of the methods described in the first aspect; commands in different command queues in the command stream are sent out in parallel, and commands in the same command queue are sent out sequentially; and a result acquisition module, used to determine the test result based on the execution status of each command in the command stream by each execution unit.

[0029] The command-flow-based testing device described above has the same technical effect as the second aspect mentioned above, so it will not be described again here.

[0030] Fifthly, embodiments of this application also provide an electronic device, including a processor and a memory, wherein the processor is configured to execute one or more programs stored in the memory to implement any of the command stream generation methods provided in the first aspect above, and / or to implement any of the command stream-based testing methods provided in the second aspect above.

[0031] Sixthly, this application also provides a computer-readable storage medium storing one or more programs, which can be executed by one or more processors to implement any of the command stream generation methods provided in the first aspect above, and / or to implement any of the command stream-based testing methods provided in the second aspect above.

[0032] In a seventh aspect, this application also provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it implements any of the command stream generation methods provided in the first aspect above, and / or implements any of the command stream-based testing methods provided in the second aspect above.

[0033] Eighthly, this application also provides a chip that is obtained by testing it using any of the command flow-based testing methods provided in the second aspect above. Attached Figure Description

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

[0035] Figure 1 A basic flowchart of a command stream generation method provided in this application embodiment is shown below; Figure 2 A schematic diagram of a command flow structure provided in an embodiment of this application; Figure 3 This is a schematic diagram of another command flow structure provided in an embodiment of this application; Figure 4 This application provides a schematic diagram of a command flow structure with multiple command groups as an embodiment of the present application. Figure 5 A basic flowchart of a command flow-based testing method provided in this application embodiment; Figure 6 A schematic diagram of the basic structure of a command stream generation device provided in this application embodiment; Figure 7 A schematic diagram of the basic structure of a command-flow-based testing device provided in an embodiment of this application; Figure 8 This is a schematic diagram of the basic structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0037] To obtain a command flow with better randomness and lower risk of command deadlock, please refer to Figure 1 As shown, Figure 1 This paper illustrates a basic flowchart of the command stream generation method provided in an embodiment of this application, including: S101: Randomly generate a set of commands based on each command subclass.

[0038] In the embodiments of this application, a base class Command may be included, and then various subclasses of the base class may be included, such as at least one of the following classes: Compute_kernel, Flush_invert, Dynamic_lautch, Terminate, Cfg_update, Jump, Nop, and Linear_copy. These subclasses may inherit from the Command class and generate commands of different types.

[0039] Among them, the Compute_kernel class is used to implement computing tasks, the Flush_invert class is used to implement memory flushing, the Dynamic_lautch class is used to implement dynamic loading, the Terminate class is used to implement termination operations, the Cfg_update class is used to implement configuration update operations, the Jump class is used to implement jump operations, the Nop class is used to generate empty commands, and the Linear_copy class is used to implement continuous copying.

[0040] In this embodiment of the application, a Command_generate class can be implemented, thereby generating a command set by randomly generating commands that can be matched with each command subclass according to the function of each command subclass.

[0041] In the embodiments of this application, when randomly generating a command set based on each command subclass, the commands in the command set may have dependencies on each other, and the commands in the command set do not include the Fence synchronization command.

[0042] It is understandable that in modern highly parallel processor architectures (such as GPUs, GPGPUs, NPUs, TPUs, etc.), due to their highly parallel computing characteristics, multiple commands can be allocated to different execution units for simultaneous execution. When there are dependencies between commands in a command stream, a command scheduler is needed to resolve and schedule these dependencies before distributing them to the appropriate execution units. Dependencies in a command stream can generally be categorized into the following three types: Fence Count dependency: A command depends on another command's value being reached before it can execute. For example, command A sets a Fence Count value, and command B must wait for that value to reach the value set by A before it can execute. In this case, command B depends on the completion of command A.

[0043] Event dependency: A dependency in which a command can only execute if the Event flag of another command is set. For example, if command A writes a certain Event flag into memory (such as DDR (Double Data Rate)) during execution, command B must wait for that Event flag to be set before it can continue execution, thus forming a dependency of B on A.

[0044] Fence synchronization dependency: A dependency relationship in which all commands following the Fence synchronization command must wait for all commands preceding the Fence synchronization command to be executed before they can continue to execute. It is a type of global synchronization mechanism.

[0045] In the embodiments of this application, each command set generated may have FenceCount dependency or Event dependency, but not Fence synchronization dependency. This allows commands in the same command set to be executed continuously and distributed in parallel. As long as the dependencies between commands with FenceCount dependency and Event dependency are satisfied, they can be distributed.

[0046] In the embodiments of this application, the above categories are merely examples and do not represent that only the above command subclasses can be used in the solutions of the embodiments of this application.

[0047] In the embodiments of this application, the various types described above, as well as the various classes mentioned below, can be implemented using a hardware language, such as, but not limited to, System Verilog.

[0048] S102: Encapsulate each command in the command set into a command queue to obtain a command subset in each command queue.

[0049] In this embodiment, the number of command queues can be pre-set according to the current testing needs, and then each command in the command set can be distributed to each command queue and encapsulated. For example, see [link to relevant documentation]. Figure 2 As shown, each BL is a set of commands, and each block is a subset of commands.

[0050] In this embodiment, commands in different command queues can be sent in parallel during command flow, while commands in the same command queue are sent sequentially. Furthermore, if a command in a command queue depends on another command, that command waits for the other command to execute before being sent, and the dependency is satisfied.

[0051] In this embodiment, the number of command queues can be set according to the parallelism of the DUT (Device Under Test) to be tested. The higher the parallelism, the larger the number of command queues can be set.

[0052] In some optional embodiments of this application, an equal-probability distribution method can be used to distribute each command in the command set to each command queue, so that the commands in each command queue are basically equivalent. This ensures that the delivery efficiency of commands in each command queue is as close as possible during subsequent testing, thereby improving the testing effect. Of course, other methods can also be used in this application to distribute each command in the command set to each command queue.

[0053] In this embodiment, a Command_queue class can be implemented to encapsulate commands that need to be dispatched to the same command queue into the same command queue. In this embodiment, the command queue can be a physical queue, such as a cache in a device, or it can be a virtual queue, which is a collection of commands encapsulated by the Command_queue class.

[0054] S103: Insert a Fence synchronization command at the end of the command subset of each command queue.

[0055] In this embodiment, the Command_queue class encapsulates the commands distributed to the same command queue from the current command set, thus obtaining a block of command subsets in that command queue. A Fence synchronization command is then inserted after this block. Since the Fence synchronization command can implement the aforementioned Fence synchronization dependency, commands in the next command set can only be executed after the commands in the previous command set have been completed. This improves the execution synchronization between command subsets within the same command set.

[0056] For example, see still Figure 2As shown, the commands from command sets BL0, BL1, and BL2 are distributed to four command queues Q1, Q2, Q3, and Q4. In any command queue, a Fence synchronization command F is inserted after the command subset blocks included in BL0, BL1, and BL2. Thus, for any command queue, commands in the next block are only distributed after all preceding blocks have been executed.

[0057] S104: Repeat steps S101, S102, and S103 until the preset termination condition is met, and obtain the command flow.

[0058] In the embodiments of this application, each time a command set is generated, the generated command can only have a dependency relationship with other commands in the current command set, and has no Fence synchronization dependency. It has no dependency relationship with commands in other command sets generated in previous times, thereby realizing logical decoupling between command sets, so that dependencies will not propagate across command sets, effectively cutting off potential deadlock chains and reducing the risk of deadlock.

[0059] For example, such as Figure 2 As shown, there is no dependency between the commands in BL0 and the commands in BL1, nor between the commands in BL0 and the commands in BL2, nor between the commands in BL1 and the commands in BL2.

[0060] In the embodiments of this application, the preset termination condition may include, but is not limited to, at least one of the following: the number of times the command set is generated reaches a preset number; the number of commands generated reaches a preset number of commands; the command generation time reaches a preset time; all commands in the command queue reach a preset limit value, etc.

[0061] When the preset termination conditions include multiple conditions, steps S101, S102, and S103 can be skipped if any one of the conditions is met.

[0062] Considering that the Fence synchronization command is mainly used to restrict the execution of subsequent commands, in the absence of a command group, for the last subset of commands in the command queue, a Fence synchronization command need not be inserted after it. See, for example... Figure 3 As shown in the accompanying drawings of the embodiments of this application, F represents the Fence synchronization command, block represents the command subset, BL represents the command set, and Q represents the command queue.

[0063] Therefore, in an optional embodiment of this application, step S103 may be omitted during the final repetition of steps S101, S102, and S103. For example, if the preset end condition is that the number of command set generation times reaches a preset number, then only steps S101 and S102 are executed when the current number of command set generation times is one step away from reaching the preset number. As another example, if the preset end condition is that the number of generated commands reaches a preset number of commands, then only steps S101 and S102 are executed when the difference between the preset number of commands and the current number of generated commands is less than or equal to the minimum number of commands generated in a single cycle. As yet another example, if the preset end condition is that the command generation time reaches a preset time, then only steps S101 and S102 are executed when the difference between the preset time and the current command generation time is less than or equal to the minimum time required for a single cycle.

[0064] In another optional embodiment of this application, after repeating steps S101, S102, and S103 in the last round, the Fence synchronization command after the last command subset in the command queue can be deleted and then encapsulated to obtain the command stream.

[0065] In this embodiment of the application, a Command_stream class can be implemented. This Command_stream class encapsulates all commands into a command stream, which is then obtained and distributed by the command scheduler for testing.

[0066] In some optional embodiments of this application, command groups can also be set, and each command group may include multiple command queues, for example... Figure 4 As shown.

[0067] At this point, each command in the generated command set is encapsulated into a command queue belonging to the same command group.

[0068] For example, see Figure 4 As shown, the commands in the first three command sets BL0, BL1, and BL2 are encapsulated into the four command queues Q1, Q2, Q3, and Q4 of command group G1, respectively. The commands in the last three command sets BL3, BL4, and BL5 are encapsulated into the four command queues Q5, Q6, Q7, and Q8 of command group G2, respectively.

[0069] In this embodiment, link-to connections can be configured between command queues in different command groups to test the adjacency relationships between command queues and meet the testing requirements of scenarios such as multi-task scheduling. Correspondingly, when generating command streams, link-to connections can also be configured between two command queues in different command groups according to testing needs. For example, as... Figure 4 As shown, a link-to connection can be configured between command queues Q1 and Q5, between command queues Q2 and Q6, between command queues Q3 and Q7, and between command queues Q4 and Q8.

[0070] In this embodiment, the Link-to connection refers to a direct connection. For example, if A is Link-to connected to B, it means that after A finishes execution, execution will directly switch to B. Therefore, in this embodiment, taking command queue Q1 Link-to connected to command queue Q5 as an example, it means that after the commands in command queue Q1 are executed, the commands in command queue Q5 are then distributed and executed. Thus, in this embodiment, although commands between command queues can be issued in parallel, for two command queues configured with a Link-to connection, the command of the command queue that is linked first in the Link-to connection is allowed to be issued only after the command of the command queue linked first in the Link-to connection has been issued. This allows for testing of the adjacency relationship between command queues during testing.

[0071] In this embodiment of the application, a Command_group class can be implemented to encapsulate all commands in the same command group into a command group, and then the Command_stream class can encapsulate all command groups into a command stream.

[0072] It's important to note that, in cases where command groups exist, optionally, for the last subset of commands in the last command queue, the Fence synchronization command can be omitted from the subsequent insertion. For example, for... Figure 4 As shown in the structure, for command queues Q5, Q6, Q7, and Q8, it is not necessary to insert the Fence synchronization command after the last command subset.

[0073] In this embodiment of the application, the number of command groups can be set to two or more.

[0074] In an optional embodiment of this application, each time a command in the command set is encapsulated into a command queue, the setting commands in the command set are encapsulated into a first target command queue. The first target command queue is one of all command queues. For example, as... Figure 3As shown, all configuration commands can be encapsulated into command queue Q1. By encapsulating all configuration commands into the same command queue, configuration commands can only be initiated within that queue. Since commands within the same queue are issued and executed sequentially, this avoids the problem of multiple configuration commands that should have a specific order being issued and executed in parallel due to being assigned to different command queues. This can lead to errors in the execution results and also avoids the risk of dependency disorder caused by the uncertainty of command execution order due to parallel issuance of commands from different command queues in a parallel execution environment.

[0075] In one optional embodiment of this application, for cases where multiple command groups are set, in addition to encapsulating all setting commands into a first target command queue, a first target command queue can also be set in each command group. When encapsulating commands for each command group, the setting commands encapsulated for that command group are encapsulated into the first target command queue of that command group, and a Link-to connection relationship is set for the first target command queues in different command groups.

[0076] For example, such as Figure 4 As shown, command queue Q1 in command group G1 can be used as a first target command queue, and setting commands in command sets BL0, BL1, and BL2 can be encapsulated into command queue Q1 in sequence; command queue Q4 in command group G2 can be used as a first target command queue, and setting commands in command sets BL3, BL4, and BL5 can be encapsulated into command queue Q4 in sequence.

[0077] In this embodiment, the setting commands can implement commands such as set_qfc / set_event. The set_qfc command is used to set the Fence Count value in the queue, and the set_event command is used to set and set the Event flag.

[0078] In one optional embodiment of this application, the commands include wait-type commands, and each wait-type command corresponds to a set-type command. For example, the wait_qfc command corresponds to the set_qfc command, and the wait_event command corresponds to the set_event command.

[0079] For each `wait` command, its value is updated as the corresponding `set` command is executed. For example, the value of the `wait_qfc` command is updated after the execution of its corresponding `set_qfc` command, and the value of the `wait_event` command is updated after the execution of its corresponding `set_event` command. This ensures that dependencies based on QFC (Queue Fence Count) (i.e., Fence Count dependency) or dependencies based on Event (i.e., Event dependency) are logically resolvable, avoiding execution stalls or command deadlocks caused by mismatched wait values.

[0080] In the embodiments of this application, different command sets do not use the same Fence Count and Event identifier, so as to achieve isolation between different command sets and avoid cross-command set dependencies.

[0081] Based on the command stream generated above, this application embodiment also provides a command stream-based testing method, which can be found in [reference needed]. Figure 5 As shown, it includes: S501: Send each command in the command stream to the respective execution unit of the DUT.

[0082] In the embodiments of this application, the DUT can be a GPU, GPGPU, NPU, TPU, or other chips in the design. The execution unit can be a functional module in each chip, such as a streaming processor in each chip.

[0083] In the embodiments of this application, the tests performed can be RTL tests of the DUT, or C language-based simulation tests of the DUT. That is, the command stream in the embodiments of this application can be a first test command stream generated based on the aforementioned method for performing RTL tests, or a second test command stream generated based on the aforementioned method for performing C language-based simulation tests.

[0084] In the embodiments of this application, commands in different command queues in the command stream are issued in parallel, and commands in the same command queue are issued sequentially.

[0085] In this embodiment, the command scheduler can sequentially retrieve commands from each command queue, resolve their dependencies, and then issue them. When a command with dependencies is encountered, for the command queue containing that command, the scheduler waits for the commands it depends on to complete before issuing the command. That is, within the same command queue, for multiple target commands with dependencies, the later target commands are issued only after the earlier target command has completed its execution. This ensures that the target commands with dependencies are executed in the correct order, avoiding execution order errors caused by parallel command issuance and improving the reliability and accuracy of the test.

[0086] In one optional embodiment of this application, after each command in the command stream is sent to each execution unit of the DUT, for any command set, after all commands in the command set have been issued, the values ​​of all wait-type commands in the command set are updated to the final values ​​of the setting-type commands corresponding to the wait-type commands.

[0087] For example, with Figure 3 For example, assuming the command in BL0 has been issued, we can traverse BL0, find all wait-type commands in BL0, and based on the identifier value of the wait-type command, find the setting-type command with that identifier value (setting-type commands with the same identifier value correspond to wait-type commands). Update the final value of the setting-type command to the value of the wait-type command, thereby improving the correctness of the wait-type command value, ensuring that all dependencies based on QFC or Event are logically resolvable, and avoiding execution stalls or command deadlocks caused by mismatched wait values.

[0088] S502: Determine the test results based on the execution status of each command in the command stream by each execution unit.

[0089] In one optional embodiment of this application, the execution results of each command can be collected and compared with preset standard results to determine the test results.

[0090] In this embodiment, when multiple command groups exist, commands can be issued in parallel to each command queue within the same command group, following the order of the command groups. After the commands for any command queue in the current command group have been issued, a command queue in the next command group is determined for issuance. If a command queue in the current command group has a Link-to connection, after the commands for that command queue in the current command group have been issued, a second target command queue with a Link-to connection to that command queue is determined in the next command group, and commands in that second target command queue are issued.

[0091] It is important to note that if a command queue in the current command group does not have a link-to connection, after all commands in that command queue have been issued, a command queue in the next command group can be randomly selected for command issuance. This may result in the selected command queue in the next command group having a link-to connection, but the command is not issued only after all commands in the preceding command queue have been issued. This situation is permitted in this application.

[0092] In other words, for cases where a Link-to connection exists, if the command of the second target command queue that comes first in the Link-to connection is completed, but the command of the second target command queue that comes later in the Link-to connection has not been issued, then the command of the second target command queue that comes later in the Link-to connection will be issued.

[0093] In this embodiment of the application, if the execution result of each command matches the preset standard result, it can be determined that the adjacency relationship between the command queues is established when there is a Link-to connection relationship.

[0094] In the embodiments of this application, each time a test is performed (regardless of whether the test is performed for the same scenario), a command stream can be randomly generated based on the aforementioned method, thereby achieving a more diverse testing experience and improving test coverage.

[0095] Based on the method provided in this application embodiment, since each generated command set does not include a Fence synchronization command, continuous execution and parallel distribution are allowed among the command subsets distributed to each command queue. Because a Fence synchronization command is inserted at the end of the command subsets in each command queue, commands in the next command set can only be executed after the commands in the previous command set have been completed, thereby improving the execution synchronization between command subsets within the same command set. Furthermore, since the commands in each generated command set have no dependencies on commands in other generated command sets, logical decoupling between command sets is achieved, preventing dependencies from propagating across command sets, effectively cutting off potential deadlock chains, and reducing the risk of deadlock. Therefore, the solution provided in this application embodiment, compared to the first solution in related technologies, eliminates the need for verification engineers to manually construct command flows, effectively reducing labor costs and improving the efficiency of command flow generation. Compared to the second approach in related technologies, this method requires no in-depth understanding of the CUDA programming model by engineers, nor does it require comprehensive integration of the underlying software stack, resulting in a lower technical barrier and greater universality. Furthermore, the solution presented in this application can randomly generate the required command flow for each test, offering better randomness and thus improving test coverage and effectiveness. Simultaneously, in this application's solution, dependencies are concentrated in each command set, with no dependencies between command sets, effectively reducing dependency complexity, improving the solvability of dependencies in the command flow, and lowering the risk of command deadlock. Moreover, the better randomness of the command flow used in testing enhances test randomness and coverage. Additionally, the lower risk of command deadlock increases the probability of successful test completion and improves test efficiency.

[0096] To facilitate understanding of the solutions in the embodiments of this application, the following will be used as examples. Figure 4 The structure shown is used as an example to further illustrate the solution of this application embodiment.

[0097] In this exemplary embodiment, the following classes are implemented based on the System Verilog language: Command_stream, Command_group, Command_queue, Command_generate, Command, Compute_kernel, Flush_invert, Dynamic_lautch, Terminate, Cfg_update, Jump, Nop, and Linear_copy.

[0098] Among them, Command_stream and Command_group have an aggregation relationship; Command_group and Command_queue have an aggregation relationship; Command_queue and Command have an aggregation relationship; Command is the base class, which is inherited by specific command subclasses such as Compute_kernel, Flush_invert, Dynamic_launch, Terminate, Cfg_update, Jump, Nop, and Linear_copy.

[0099] The `Command_generate` class provides the `add_block()` function, which adds a block to all queues. Blocks are formed by distributing commands from the BL (Block Flow) to the command queues with equal probability. Dependencies are allowed between commands within each block, and dependencies are also allowed between commands within blocks distributed from the same BL. However, constraints (inserting a Fence synchronization command at the end of the block, encapsulating all setup commands in the same command queue, and updating the value of wait commands as the corresponding setup command is executed) ensure that the final value of dependencies satisfies the dependency conditions.

[0100] To further isolate dependency propagation, separate Fence Count and Event identifiers are used between different BLs to block cross-BL dependencies.

[0101] When generating the command stream, the Command_generate class randomly generates BL0 according to each command subclass and distributes it to the command queues Q1 to Q4 with equal probability. After being encapsulated by the Command_queue class, the Fence synchronization command is inserted after each block of BL0.

[0102] Next, the Command_generate class randomly generates BL1 based on each command subclass and distributes it to the command queues Q1 to Q4 with equal probability. After being encapsulated by the Command_queue class, the Fence synchronization command is inserted after each block of BL1.

[0103] Next, the Command_generate class randomly generates BL2 based on each command subclass and distributes it to the command queues Q1 to Q4 with equal probability. After being encapsulated by the Command_queue class, the Fence synchronization command is inserted after each block of BL2.

[0104] Command group G1 is obtained by encapsulating command queues Q1 to Q4 using Command_group.

[0105] Next, the Command_generate class randomly generates BL3 based on each command subclass and distributes it to the command queues Q5 to Q8 with equal probability. After being encapsulated by the Command_queue class, the Fence synchronization command is inserted after each block of BL3.

[0106] Next, the Command_generate class randomly generates BL4 based on each command subclass and distributes it to the command queues Q5 to Q8 with equal probability. After being encapsulated by the Command_queue class, the Fence synchronization command is inserted after each block of BL4.

[0107] The Command_generate class randomly generates BL5 based on each command subclass and distributes it to the command queues Q5 to Q8 with equal probability. After being encapsulated by the Command_queue class, the Fence synchronization command is inserted after each block of BL5.

[0108] Command group G2 is obtained by encapsulating command queues Q5 to Q8 using Command_group.

[0109] Configure the link-to connection between command queues Q1 and Q5, between command queues Q2 and Q6, between command queues Q3 and Q7, and between command queues Q4 and Q8.

[0110] The command stream is obtained by encapsulating command group G1 and command group G2 using Command_stream.

[0111] During testing, commands for BL0 in Q1 through Q4 are first fetched and sent in parallel until the end of the block is reached. After executing the Fence synchronization command, commands for BL1 in Q1 through Q4 are fetched and sent in parallel. This process continues until commands for BL2 in Q1 through Q4 are executed. Then, the Fence synchronization command is executed, and commands for BL3 in Q5 through Q8 are fetched and sent in parallel. This process continues until the last Fence synchronization command is executed.

[0112] Specifically, when a command is issued, commands waiting for dependency values ​​will be blocked in their command queue until the commands they depend on have completed execution, at which point the command will be dispatched for execution. Furthermore, at the end of the BL (Browser Flow), the system will refresh the values ​​of all wait-type commands within that BL to reflect the final values ​​of their corresponding set-type commands, ensuring that dependencies are resolvable.

[0113] With the above scheme, there will be no dependency deadlock between commands within each BL; at the same time, since there are no dependencies between BLs, there will be no dependency deadlock between all command queues, thus ensuring the deadlock-free execution of the command flow as a whole.

[0114] Based on the same inventive concept, this application also provides a command stream generation device 600 and a command stream-based testing device 700. Please refer to... Figure 6 and Figure 7 As shown, Figure 6 It shows the use of Figure 1 The command stream generation device of the method shown, Figure 7 It shows the use of Figure 5 The method illustrated is a command-flow-based test apparatus. It should be understood that the specific functions of apparatus 600 and 700 are described above; to avoid repetition, detailed descriptions are omitted here. Apparatus 600 and 700 include at least one software functional module that can be stored in memory or embedded in the operating system of apparatus 600 or 700 in the form of software or firmware. Specifically: See Figure 6 As shown, the device 600 includes: a command generation module 601 and an encapsulation module 602. Wherein: The command generation module 601 is used to randomly generate a command set based on each command subclass; the commands in the command set may have dependencies on each other, and the commands in the command set do not include the fence synchronization command; The encapsulation module 602 is used to encapsulate each command in the command set into each command queue to obtain a command subset in each command queue, and to insert a Fence synchronization command at the end of the command subset in each command queue. The command generation module 601 and the encapsulation module 602 are used to continuously repeat the above process until the preset termination condition is met, thereby obtaining the command stream; In this context, the commands in each generated command set are not dependent on the commands in other generated command sets; and when the command stream is issued, commands in different command queues can be issued in parallel, while commands in the same command queue are issued sequentially.

[0115] In one feasible embodiment of this application, the command stream includes multiple command groups; each command group includes multiple command queues; each command in each generated command set is encapsulated into a command queue belonging to the same command group; a link-to connection relationship can be configured between command queues in different command groups; the encapsulation module 602 is further used to configure a link-to connection relationship between two command queues in different command groups.

[0116] In one feasible implementation of this application, each time each command in the command set is encapsulated into a command queue, the setting commands in the command set are encapsulated into a first target command queue; the first target command queue is one of all command queues.

[0117] In one feasible embodiment of this application, the command includes a setting command and a wait command, and each wait command corresponds to a setting command; for each wait command, the value of the wait command is updated as the setting command corresponding to the wait command is executed.

[0118] In one feasible implementation of the embodiments of this application, each command subclass includes at least one of the following: Compute_kernel class for computing task set, Flush_invert class for memory flushing, Dynamic_lautch class for dynamic loading, Terminate class for termination, Cfg_update class for configuration update, Jump class for jump, Nop class for empty command, and Linear_copy class for continuous copying.

[0119] In one feasible embodiment of this application, the command stream is a first test command stream for performing RTL testing, or the command stream is a second test command stream for performing simulation testing based on the C language.

[0120] See Figure 7 As shown, the device 700 includes: a distribution module 701 and a result acquisition module 702. Wherein: The distribution module 701 is used to send each command in the command stream to each execution unit of the device under test (DUT); wherein, the command stream is a command stream generated according to the aforementioned command stream generation method; commands in different command queues in the command stream are sent out in parallel, and commands in the same command queue are sent out sequentially; The result acquisition module 702 is used to determine the test result based on the execution status of each command in the command stream by each of the execution units.

[0121] In this embodiment of the application, when the command stream includes multiple command groups and there are Link-to connections between command queues in different command groups, the distribution module 701 is specifically used to: in multiple second target command queues configured with Link-to connections, if the command of the first second target command queue in the Link-to connection is issued and the command of the second target command queue in the Link-to connection is not issued, then issue the command of the second target command queue in the Link-to connection.

[0122] In one feasible implementation of this application, the distribution module 701 is specifically used to: in the same command queue, for multiple target commands with dependencies, after the first target command is executed, send the subsequent target command.

[0123] In one feasible embodiment of this application, the apparatus 700 may further include an update module, which is used to update the values ​​of all wait-type commands in any command set to the final values ​​of the setting-type commands corresponding to the wait-type commands after the distribution module 701 sends each command in the command stream to each execution unit of the DUT.

[0124] It should be understood that, for the sake of brevity, some of the content described in the method embodiments will not be repeated in this device embodiment.

[0125] Based on the same inventive concept, this application provides an electronic device, see [link to relevant documentation]. Figure 8 As shown, it includes a processor 801 and a memory 802. Wherein: The processor 801 is used to execute one or more programs stored in the memory 802 to implement the command stream generation method described above, and / or the command stream-based testing method.

[0126] It is understandable that the processor 801 can be a GPU, CPU (Central Processing Unit), AI (Artificial Intelligence) processor, NPU, ISP (Image Signal Processor), DPU (Display Processing Unit), VPU (Video Processing Unit), DSP (Digital Signal Processor), TPU data processing core, etc., or it can be a processor chip used in scenarios such as large-scale data computation. The memory 802 can be RAM (Random Access Memory), ROM (Read-Only Memory), or flash memory. The above are merely examples and should not be construed as limiting this application.

[0127] It's understandable. Figure 8 The structure shown is for illustrative purposes only; the electronic device may also include components that are more advanced than those shown. Figure 8 The more or fewer components shown, or having the same Figure 8 Different configurations are shown. For example, it may also have an internal communication bus for communication between the processor 801 and the memory 802; or it may have an external communication interface, such as a USB (Universal Serial Bus) interface, a CAN (Controller Area Network) bus interface, etc.; or it may have an information display component such as a display screen, but this is not a limitation.

[0128] In the embodiments of this application, the electronic device can be any type of device capable of chip testing, such as a simulation platform.

[0129] In this application embodiment, a chip is also provided, which is obtained after testing using the command flow-based testing method of this application embodiment. This chip may be, but is not limited to, a processor chip providing highly parallel computing, such as a GPU, GPGPU, NPU, or TPU.

[0130] Based on the same inventive concept, embodiments of this application also provide a computer-readable storage medium, such as a floppy disk, optical disk, hard disk, flash memory, USB flash drive, SD (Secure Digital Memory Card), MMC (Multimedia Card), etc., in which one or more programs implementing the above steps are stored. These one or more programs can be executed by one or more processors to implement the above command stream generation method and / or the command stream-based testing method. Further details will not be elaborated here.

[0131] Based on the same inventive concept, this application also provides a computer program product including a computer program, which, when executed by a processor, implements the above-described command stream generation method and / or a test method based on the command stream. For details, please refer to the above-described method embodiments, which will not be repeated here.

[0132] In the embodiments of this application, the computer program product may be, but is not limited to, firmware installation packages, software installation packages, etc. The computer program for the above-described command stream generation method and / or command stream-based testing method may be the entire program of the firmware installation package or software installation package, or it may be a part of the entire program of the firmware installation package or software installation package. For example, the computer program for the above-described command stream generation method and / or command stream-based testing method may exist as a functional package part of the test software.

[0133] In the embodiments of this application, the terms and English abbreviations are exemplary examples given for ease of description and should not be construed as limiting the application in any way. This application does not preclude the possibility of defining other terms that can achieve the same or similar functions in existing or future agreements.

[0134] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When these computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated.

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

[0136] It should be understood that in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0137] In this article, "multiple" refers to two or more.

[0138] In summary, the above description is merely a preferred embodiment of the technical solution of this application and is not intended to limit the scope of protection of 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 command stream generation method, characterized in that, include: A set of commands is randomly generated based on each command subclass; The commands in the command set may have dependencies on each other, and the commands in the command set do not include the fence synchronization command; Each command in the command set is encapsulated into a command queue to obtain a command subset in each command queue; Insert the Fence synchronization command at the end of the command subset of each command queue; Repeat the above process until the preset termination condition is met to obtain the command stream; In this context, commands in each generated command set are independent of commands in other generated command sets; and when the command stream is issued, commands in different command queues can be issued in parallel, while commands in the same command queue are issued sequentially.

2. The command stream generation method as described in claim 1, characterized in that, The command stream includes multiple command groups; each command group includes multiple command queues; each command in each generated command set is encapsulated into a command queue belonging to the same command group. Link-to connections can be configured between command queues in different command groups; The method also includes configuring a link-to connection between two command queues in different command groups.

3. The command stream generation method as described in claim 1, characterized in that, Each time a command in the command set is encapsulated into a command queue, the setting commands in the command set are encapsulated into the first target command queue. The first target command queue is one of all command queues.

4. The command stream generation method as described in claim 3, characterized in that, The commands include setting commands and wait commands, and each wait command corresponds to a setting command. For each of the wait-class commands, the value of the wait-class command is updated as the corresponding setting-class command is executed.

5. The command stream generation method according to any one of claims 1-4, characterized in that, Each command subclass includes at least one of the following: The classes include: Compute_kernel (compute task set), Flush_invert (memory flush), Dynamic_lautch (dynamic loading), Terminate (termination), Cfg_update (configuration update), Jump (jump), Nop (empty command), and Linear_copy (continuous copy).

6. The command stream generation method according to any one of claims 1-4, characterized in that, The command stream is either a first test command stream for performing RTL testing, or a second test command stream for performing simulation testing based on the C language.

7. A command-flow-based testing method, characterized in that, include: Each command in the command stream is sent to each execution unit of the device under test (DUT); wherein, the command stream is a command stream generated according to the command stream generation method as described in any one of claims 1-6; commands in different command queues in the command stream are sent out in parallel, and commands in the same command queue are sent out sequentially; The test results are determined based on the execution status of each command in the command stream by each of the execution units.

8. The command-flow-based testing method as described in claim 7, characterized in that, When the command stream includes multiple command groups, and there are Link-to connections configured between command queues in different command groups: In a plurality of second target command queues configured with Link-to connections, if the command of the first second target command queue in the Link-to connection has been issued, but the command of the second target command queue in the Link-to connection has not been issued, then the command of the second target command queue in the Link-to connection that is later is issued.

9. The command-flow-based testing method as described in claim 7 or 8, characterized in that, In the same command queue, for multiple target commands that have dependencies, the subsequent target commands are issued after the first target command has been executed.

10. The command-flow-based testing method as described in claim 7 or 8, characterized in that, After sending each command in the command stream to its respective execution unit of the device under test (DUT), the method further includes: For any of the command sets, after all commands in the command set have been issued, the values ​​of all wait-type commands in the command set are updated to the final values ​​of the setting-type commands corresponding to those wait-type commands.

11. A command stream generation device, characterized in that, include: The command generation module is used to randomly generate a set of commands based on each command subclass. The commands in the command set may have dependencies on each other, and the commands in the command set do not include the fence synchronization command; The encapsulation module is used to encapsulate each command in the command set into a command queue, thereby obtaining a command subset in each command queue, and inserting a Fence synchronization command at the end of the command subset in each command queue. The command generation module and the encapsulation module are used to continuously repeat the above process until the preset termination condition is met, thereby obtaining the command stream; In this context, the commands in each generated command set are not dependent on the commands in other generated command sets; and when the command stream is issued, commands in different command queues can be issued in parallel, while commands in the same command queue are issued sequentially.

12. A test apparatus based on command flow, characterized in that, include: The distribution module is used to send each command in the command stream to each execution unit of the device under test (DUT); wherein the command stream is a command stream generated according to the command stream generation method as described in any one of claims 1-6; commands in different command queues in the command stream are sent out in parallel, and commands in the same command queue are sent out sequentially; The result acquisition module is used to determine the test results based on the execution status of each command in the command stream by each of the execution units.

13. An electronic device, characterized in that, It includes a processor and a memory, the processor being configured to execute one or more programs stored in the memory to implement the command stream generation method as described in any one of claims 1-6, and / or to implement the command stream-based testing method as described in any one of claims 7-10.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores one or more programs, which can be executed by one or more processors to implement the command stream generation method as described in any one of claims 1-6, and / or to implement the command stream-based testing method as described in any one of claims 7-10.

15. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the command stream generation method as described in any one of claims 1-6, and / or implements the command stream-based testing method as described in any one of claims 7-10.

16. A chip, characterized in that, The results were obtained after testing using the command flow-based testing method as described in any one of claims 7-10.

Images