A verification use case scheduling method, device, equipment and medium

Abstract

The application discloses a kind of verification use case scheduling method, device, equipment and medium, applied to prototype verification technical field, comprising: obtaining verification use case from verification use case pool, obtain target verification use case, the verification use case pool includes system-on-chip level verification use case and module level verification use case;The target verification use case is assigned to target use case execution channel in multiple use case execution channels, and the multiple use case execution channels are used to execute verification use case in parallel;The target verification use case is executed by the target use case execution channel, and the execution process of the target verification use case is controlled based on the state bit of the module to be tested;The state bit is used to represent the module state of the module to be tested, and the module state includes idle state, ready state, use state, possession state and reset state.

Description

Technical Field

[0001] This invention relates to the field of prototype verification technology, and in particular to a verification test case scheduling method, apparatus, device, and medium. Background Technology

[0002] Currently, in the later stages of prototype verification, in order to quickly perform regression testing of module-level verification cases and thus take into account both module-level and on-chip system-level verification cases, the various module-level verification cases are usually linked together to form several giant verification cases. This reduces the time spent on manual operation and checking test results. However, there may be hardware resource conflicts between multiple verification cases, and module-level verification cases are difficult to integrate into the testing of on-chip system-level verification cases, resulting in low automation and low testing efficiency during verification case testing.

[0003] Therefore, how to avoid hardware resource conflicts, improve the degree of test automation, and thus improve test efficiency is a problem that needs to be solved by those skilled in the art. Summary of the Invention

[0004] This invention provides a verification test case scheduling method, apparatus, device, and medium that can avoid hardware resource conflicts, improve the degree of test automation, and thus improve test efficiency.

[0005] In a first aspect, the present invention provides a method for scheduling verification test cases, comprising: Target verification cases are obtained by retrieving verification cases from the verification case pool, wherein the verification case pool includes on-chip system-level verification cases and module-level verification cases; The target verification test case is assigned to a target test case execution channel in a plurality of test case execution channels, wherein the plurality of test case execution channels are used to execute the verification test case in parallel; The target verification test case is executed through the target test case execution channel, and the execution process of the target verification test case is controlled based on the status bit of the module under test; The status bits are used to characterize the module status of the module under test. The module status includes idle state, ready state, used state, occupied state, and pending reset state. The idle state indicates that the module is not initialized. The ready state indicates that the module is initialized and waiting to be called by a verification test case. The used state indicates that the module is currently called by one or more verification test cases. The occupied state indicates that the module is currently exclusively occupied by one verification test case. The pending reset state indicates that the module will be reset.

[0006] Optionally, controlling the execution process of the target verification test case based on the status bits of the module under test includes: When the target verification test case calls the module command, if the status bit of the module under test indicates that the module under test is in a ready or used state, the target test case continues to be executed, the module under test is used, and if the status bit indicates that the module under test is in a ready state, the status bit is modified to switch the module under test to the used state; otherwise, the command execution failure information is returned, and the target verification test case is returned to the verification test case pool.

[0007] Optionally, controlling the execution process of the target verification test case based on the status bits of the module under test includes: When the target verification test case calls the module occupancy command, if the status bit of the module under test indicates that the module under test is in the ready state, then the target test case continues to be executed, the module under test is occupied, and the status bit is modified to switch the module under test to the occupied state; otherwise, the command execution failure information is returned, and the target verification test case is returned to the verification test case pool.

[0008] Optionally, controlling the execution process of the target verification test case based on the status bits of the module under test includes: When the target verification test case calls the initialization module command, the module state lock command is called to modify the lock bit in the status bit of the module under test to lock the module under test. After the initialization operation is performed on the module under test, the status bit is modified to switch the module under test to the ready state. Then, the module state unlock command is called to modify the lock bit in the status bit of the module under test to unlock the module under test.

[0009] Optionally, before calling the module state lock command to modify the lock bit in the status bits of the module under test, the following steps are also included: The current status bit of the module under test is detected. If the status bit indicates that the module under test is in an idle state, the step of calling the module status lock command to modify the lock bit in the status bit of the module under test is triggered. Otherwise, the execution of the initialization module command is terminated to skip the initialization operation.

[0010] Optionally, controlling the execution process of the target verification test case based on the status bits of the module under test includes: When the target verification test case calls the reset module command, if the status bit of the module under test indicates that the module under test is in the ready state, the status bit is modified to switch the module under test to the idle state and the reset operation is performed. If the status bit of the module under test indicates that the module under test is in the used state or the occupied state, the status bit is modified to switch the module under test to the pending reset state, wait for the module under test to enter the idle state, and then perform the reset operation.

[0011] Optionally, controlling the execution process of the target verification test case based on the status bits of the module under test includes: When the target verification test case calls the release module command, it modifies the status bit of the module under test to release the target verification test case's use of the module under test.

[0012] Secondly, the present invention provides a verification test case scheduling device, comprising: The test case acquisition module is used to acquire test cases from the test case pool to obtain target test cases. The test case pool includes on-chip system-level test cases and module-level test cases. The channel allocation module is used to allocate the target verification test case to a target test case execution channel among multiple test case execution channels, wherein the multiple test case execution channels are used to execute the verification test case in parallel; The test case execution module is used to execute the target verification test case through the target test case execution channel, and control the execution process of the target verification test case based on the status bit of the module under test; The status bits are used to characterize the module status of the module under test. The module status includes idle state, ready state, used state, occupied state, and pending reset state. The idle state indicates that the module is not initialized. The ready state indicates that the module is initialized and waiting to be called by a verification test case. The used state indicates that the module is currently called by one or more verification test cases. The occupied state indicates that the module is currently exclusively occupied by one verification test case. The pending reset state indicates that the module will be reset.

[0013] Thirdly, the present invention provides an electronic device, comprising: Memory, used to store computer programs; A processor for executing the computer program to implement the aforementioned verification test case scheduling method.

[0014] Fourthly, the present invention provides a computer-readable storage medium on which a computer program is stored, wherein the computer program, when executed by a processor, implements the aforementioned verification test case scheduling method.

[0015] Fifthly, the present invention provides a computer program product, including a computer program / instruction that, when executed by a processor, implements the aforementioned verification test case scheduling method.

[0016] As can be seen, the beneficial effects of this invention are as follows: A status bit is set for the module under test to characterize its state, including idle, ready, used, occupied, and pending reset states. Both on-chip system-level verification cases and module-level verification cases are placed in a verification case pool. Verification cases are selected from the pool and assigned execution channels. Multiple execution channels can execute verification cases in parallel. The assigned verification cases are executed through these channels, and the execution process of the target verification cases is controlled based on the status bit of the module under test. This ensures that verification cases will only continue to execute when the state condition is met, avoiding hardware resource conflicts caused by other verification cases using a module under test that has been exclusively occupied. It also takes into account both on-chip system-level and module-level verification cases. When on-chip system-level verification cases are executed, module-level verification cases can also be executed on modules that are not occupied. Combined with scheduling logic, the degree of automation is improved. Multi-channel parallel processing improves hardware resource utilization and testing efficiency. Attached Figure Description

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

[0018] Figure 1 A flowchart of a verification test case scheduling method provided in an embodiment of the present invention; Figure 2 A schematic diagram of a module state provided in an embodiment of the present invention; Figure 3 This invention provides a schematic diagram of module state switching according to an embodiment of the invention. Figure 4 A schematic diagram of verification test case scheduling provided in an embodiment of the present invention; Figure 5 A schematic diagram of a verification test case scheduling device provided in an embodiment of the present invention; Figure 6 This is a structural diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0019] 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 of ordinary skill in the art without creative effort are within the protection scope of the present invention.

[0020] The terms "comprising" and "having," and any variations thereof, in the specification and accompanying drawings of this invention are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may include steps or units not listed.

[0021] To enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0022] Chip prototyping is a method of verifying the functionality and performance of a chip design using a hardware platform such as an FPGA (Field Programmable Gate Array). Chip prototyping is a crucial step in the chip design flow, allowing the correctness of the chip design to be tested and verified under conditions close to real hardware before tape-out. Verifying the design's functionality, performance, and reliability before tape-out reduces the risk of tape-out failure. A complex SoC (System on Chip) often contains several modules. During prototyping, each module typically undergoes detailed functional verification first. Once the functionality of each module reaches a certain level, more complex functional verification or performance evaluation is performed at the SoC level. Module-level verification test cases complement SoC-level verification test cases, covering all functional verification aspects of the SoC.

[0023] As the design-verification process progresses and the chip matures, numerous RTL (Register Transfer Level) versions are inevitably produced. Limited by verification time and platform resources, it's often difficult to simultaneously address module-level and SoC-level verification test cases in each version. Furthermore, as the chip development process nears its later stages, attention tends to focus on SoC-level verification test cases, neglecting regression testing of module-level cases. To enable rapid regression testing of module-level verification test cases even in the later stages of the chip development process, thus addressing both module-level and SoC-level verification, it's necessary to increase the automation level of verification. A common approach is to chain together various module-level verification test cases into several large test cases to reduce the time spent on manual operations and checking test results. However, in bare-metal environments with SMP (Symmetric Multi-Processing) multi-core processors, or in environments using RTOS (Real-Time Operating System), the drawbacks of simply chaining test cases, leading to bloated and inefficient verification, are particularly pronounced. Because modules within a SoC are not isolated, some modules require support from other modules during verification, and some functional tests of certain modules may require exclusive use of other modules. Therefore, conflicts exist between some module-level verification test cases, and each test case involves a large amount of repetitive reset and initialization work. Furthermore, since only one test case can be executed at a time, in an SMP multi-core processor environment, there is also the problem of low multi-core utilization.

[0024] The aforementioned issues make the development and debugging of these simple, cascaded, giant verification test cases difficult. These cascaded verification test cases involve resetting and initializing numerous modules, making it difficult to test them simultaneously with SoC-level verification. They still face the dilemma of competing for verification resources with SoC-level verification test cases. In other words, during chip prototype verification, hardware resource conflicts may exist between multiple verification test cases, and module-level verification test cases are difficult to integrate into SoC-level verification test cases, resulting in low automation and low testing efficiency. To address this, this invention provides a verification test case scheduling scheme that can avoid hardware resource conflicts, improve testing automation, and thus improve testing efficiency.

[0025] Next, a verification test case scheduling method provided by an embodiment of the present invention will be described in detail. Figure 1 This invention provides a flowchart of a verification test case scheduling method, which includes: Step S11: Obtain verification cases from the verification case pool to obtain target verification cases, wherein the verification case pool includes on-chip system-level verification cases and module-level verification cases.

[0026] Module-level verification test cases are used to verify whether the functionality of a single module conforms to the design specifications, ensuring that each module can correctly execute its function during independent testing, while meeting boundary conditions and exception handling requirements. On-chip system-level verification test cases, compared to module-level verification test cases, focus more on the interaction between multiple modules and the overall system functionality, ensuring that all modules can work collaboratively after integration into the SoC, meeting system-level functional and performance requirements.

[0027] This embodiment can place both on-chip system-level verification cases and module-level verification cases into a verification case pool, and then retrieve and allocate verification cases from the pool. In an optional implementation, verification cases can be allocated according to a preset order, such as assigning verification cases numbers and allocating them by number, or allocating verification cases according to priority, with higher priority cases allocated first.

[0028] Step S12: Assign the target verification test case to the target test case execution channel in the multiple test case execution channels, wherein the multiple test case execution channels are used to execute the verification test case in parallel.

[0029] In this context, the test case execution channel is the smallest execution unit for verifying test cases. That is, within a system, the smallest execution unit for verifying test cases is the CPU core (Central Processing Unit) that executes the test case. For example, in a bare-metal environment of an SMP system, each CPU can execute the test case relatively independently, with each CPU core serving as a test case execution channel. In an RTOS environment, each thread has its own thread stack and can also execute the test case relatively independently, with each thread serving as a test case execution channel. SMP systems, or Symmetric Multiprocessing systems, are a type of computer architecture. This indicates that multiple CPUs share memory, buses, and other system resources within a system. RTOS systems, or Real-Time Operating Systems, are the counterpart to bare metal (no operating system). Real-time operating systems typically support multithreading, allowing multiple threads to execute tasks in parallel.

[0030] Step S13: Execute the target verification test case through the target test case execution channel, and control the execution process of the target verification test case based on the status bit of the module under test.

[0031] The status bits are used to characterize the module status of the module under test. The module status includes idle state, ready state, used state, occupied state, and pending reset state. The idle state indicates that the module is not initialized. The ready state indicates that the module is initialized and waiting to be called by a verification test case. The used state indicates that the module is currently called by one or more verification test cases. The occupied state indicates that the module is currently exclusively occupied by one verification test case. The pending reset state indicates that the module will be reset.

[0032] See Figure 2 As shown, Figure 2 This invention provides a schematic diagram of module states. For each module under test, 3+n state bits are generated: a locked bit, an enabled bit, a occupied bit, and n select bits, where n is the number of test case execution channels, i.e., the number of processor cores or RTOS threads. Each test case execution channel corresponds to one select bit. The combination of the enabled bit, occupied bit, and select bits describes the current state of the module, namely: idle state, ready state, used state, occupied state, and pending reset state. The locked bit, as a special state bit, does not participate in the combination of module states; it only indicates whether the other state bits, excluding the locked bit, are allowed to be modified by other verification test cases. By setting the locked bit, it can be ensured that the atomicity requirements of the operations in the verification test cases are correctly executed. For example, the reset and initialization operations of the module need to ensure that the module state is not changed by other execution channels during these two processes.

[0033] Idle state: The module is not initialized. This could be due to the clock gate or reset not being released, or it could be that the clock and reset have been released but a verification test case is still needed for basic configuration before it can function properly. In other words, the module has not entered a working state. This state is indicated by all bits being 0.

[0034] Ready state: The module has been initialized and is waiting for the verification test case to be invoked. This state is indicated by only the enable bit being 1 and the rest being 0.

[0035] Use State: The module is being invoked by one or more validation test cases. This invocation is non-exclusive, meaning the module can be invoked by multiple validation test cases simultaneously. This state is indicated by an enable bit of 1, one or more select bits of 1, and a hold bit of 0. In this state, the corresponding caller can be found by querying the select bits.

[0036] Occupied State: The module is currently occupied by a validation test case. Other validation test cases cannot use the module until this test case releases the occupation state. In this state, the enable bit is 1, and the occupation bit and a certain select bit are 1. The corresponding caller can be found by querying the select bit.

[0037] Pending Reset: This module is about to be reset. Except for the user executing the reset task, other use cases cannot use or occupy this module. Verification use cases already using or occupying this module should also exit use as soon as possible. This state may occur because the module has encountered an anomaly, or because a higher-priority use case wants to occupy it. For high-priority use cases, such as SoC-level verification use cases, it is necessary to occupy the usage rights of a large number of modules before regression testing of the remaining untouched modules. This state is indicated by an enable bit of 0 and one or more select bits of 1. Figure 2 In this case, x can be either 0 or 1.

[0038] Further, see Figure 3 As shown, Figure 3 This is a schematic diagram of module state switching provided in an embodiment of the present invention. Figure 3 The allowed module state switching paths are represented. The state of a module can be modified by the verification test case calling the interface. The state switching paths indicate the constraints that the module is subject to when switching states. The constraints are as follows: (1) Initialization operations on a module are only allowed in the idle state. The initialization operation causes the module to switch from the idle state to the ready state. (2) The use state and the possession state must be switched through the ready state. When a module is possessed, other test cases must wait for the module to be released before they can use it. When a module is used by one or more test cases, a new test case that wants to exclusively possess the module must first wait for the other test cases to release the module. When no test cases are using or possessing the module, the module returns to the ready state. (3) The module reset operation can only be performed when no other test cases are using or possessing the module, that is, only in the idle state and the ready state. When the module is in the use state or the possession state, the module will immediately enter the reset state. After other test cases release the module, the module enters the idle state and the reset operation is allowed. (4) The atomicity of the operation must be guaranteed when switching and reading the state. For RTOS systems, mutexes and semaphores can be used, while for bare-metal SMP multicore systems, spinlocks and other methods can be employed. This means that both modifying and reading the status bits are atomic operations.

[0039] In an optional embodiment, the execution process of the target verification test case based on the status bit of the module under test may include: when the target verification test case calls the module use command, if the status bit of the module under test indicates that the module under test is in a ready state or a used state, then the target test case continues to be executed, the module under test is used, and if the status bit indicates that the module under test is in a ready state, the status bit is modified to switch the module under test to the used state; otherwise, a command execution failure message is returned, and the target verification test case is returned to the verification test case pool.

[0040] In this embodiment, when calling the module command, the status bit can be read. If the status bit meets the condition, the selection bit corresponding to the target test case execution channel is set to 1, and the module is used. If the status bit does not meet the condition, the command execution result is returned as failed. The command to return to the test case pool can then be called to return the verification test case to the verification test case pool, meaning the test case can be skipped and returned to the verification test case pool to wait for the next call. The condition is that the enable bit is 1 and the occupy bit is 0, indicating that the module is in a ready or used state.

[0041] In an optional embodiment, controlling the execution process of the target verification test case based on the status bit of the module under test may include: when the target verification test case calls the module occupancy command, if the status bit of the module under test indicates that the module under test is in a ready state, then the target test case continues to be executed, the module under test is occupied, and the status bit is modified to switch the module under test to the occupied state; otherwise, command execution failure information is returned, and the target verification test case is returned to the verification test case pool.

[0042] In this embodiment, when the module possession command is invoked, the status bits can be read. If the status bits meet the conditions, the possession bit is set to 1, and the module is possessed. If the status bits do not meet the conditions, the command execution fails, and the return command can be invoked to return the verification test case to the verification test case pool. That is, the test case can be skipped and returned to the verification test case pool to wait for the next invocation. The conditions are: enable bit is 1, all select bits are 0, and possession bit is 0, meaning the module is in a ready state.

[0043] In an optional embodiment, the process of controlling the execution of the target verification test case based on the status bit of the module under test may include: when the target verification test case calls the initialization module command, the module status lock command is called to modify the lock bit in the status bit of the module under test to lock the module under test; after the initialization operation is performed on the module under test, the status bit is modified to switch the module under test to the ready state; and the module status unlock command is called to modify the lock bit in the status bit of the module under test to unlock the module under test.

[0044] In an optional embodiment, before calling the module state lock command to modify the lock bit in the state bit of the module under test, the method may further include: detecting the current state bit of the module under test; if the state bit indicates that the module under test is in an idle state, then triggering the step of calling the module state lock command to modify the lock bit in the state bit of the module under test; otherwise, ending the execution of the initialization module command to skip the initialization operation.

[0045] In other words, in this embodiment, the initialization module command only switches the enable bit to 1 (i.e., from idle to ready) when the module is in an idle state. The initialization process cannot be interrupted by other test cases; therefore, the initialization operation is protected using a lock bit. The initialization module command flow can include calling the module state lock command, performing the initialization operation, setting the enable bit to 1, and calling the module state unlock command. Alternatively, the verification test case can be designed such that if the status bit indicates the module under test is not in an idle state, a command failure message is returned, the verification test case calls the reset module command, and after the reset operation, the initialization module command is called again.

[0046] In an optional implementation, controlling the execution process of the target verification test case based on the status bit of the module under test may include: when the target verification test case calls the reset module command, if the status bit of the module under test indicates that the module under test is in a ready state, then modify the status bit to switch the module under test to an idle state and perform a reset operation; if the status bit of the module under test indicates that the module under test is in a used state or an occupied state, then modify the status bit to switch the module under test to a pending reset state, wait for the module under test to enter an idle state, and perform a reset operation.

[0047] In this embodiment, after the module under test enters the idle state, a module state lock command can be invoked to perform a reset operation, followed by an invocation of the module state unlock command. Alternatively, in this implementation, the enable bit can be set to 0, the module can be waited for to enter the idle state, the module state lock command can be invoked to perform a reset operation, and then the module state unlock command can be invoked.

[0048] In an optional implementation, controlling the execution process of the target verification test case based on the status bit of the module under test may include: when the target verification test case calls the release module command, modifying the status bit of the module under test to release the target verification test case's use of the module under test.

[0049] In this embodiment, when the release module command is invoked, the selection bit and the occupancy bit are set to 0 only if the selection bit corresponding to the use case execution channel is 1. Alternatively, in an optional implementation, if the occupancy bit is 0, the occupancy bit is not reset to 0.

[0050] That is, embodiments of the present invention can provide test case operation interface commands, and based on the allowed module state switching paths, the operation interfaces provided to each verification test case include: Module status lock command: Read the module's lock bit. If it is 0, change the module's lock bit to 1. If it is 1 and it is not the use case execution channel that is locked, continue to wait until the lock bit becomes 0.

[0051] Module state unlock command: Changes the module's lock bit to 0. Used in conjunction with the module state lock command, it ensures atomicity between the two commands' operations on the module. That is, the lock and unlock commands are invoked by a single verification test case.

[0052] The module initialization command enables bit 1 only when the module is in an idle state, transitioning from idle to ready. When a test case initializes a module, since initialization is a process that cannot be interrupted by other test cases (e.g., two verification test cases cannot initialize the same module simultaneously), the initialization operation needs to be protected with a lock bit. The command flow can be: call the module state lock command -> initialization operation -> enable bit 1 -> call the module state unlock command.

[0053] The module reset command immediately sets the enable bit to 0, switching the ready state to the idle state and the used and occupied states to the pending reset state. If the module is in the pending reset state, it continues to wait until the module becomes idle, and then performs the reset operation. The reset operation is also a process; therefore, the command flow can be: set the enable bit to 0 -> wait for the module to enter the idle state -> module state lock command -> reset operation -> module state unlock command. High-priority use cases can add the module reset command during design to quickly end other use cases' access to the module.

[0054] Using module commands: The selection bit corresponding to the test case execution channel will be set to 1 only when the enable bit is 1 and the hold bit is 0. If the status bit does not meet the conditions, the command execution will fail, and the test case can be skipped and returned to the test case pool to wait for the next invocation.

[0055] The occupy module command: The occupy bit will be set to 1 only if the enable bit is 1, all select bits are 0, and the occupy bit is 0. If the status bit does not meet the conditions, the command execution will fail, and the test case can be skipped and returned to the test case pool to wait for the next invocation.

[0056] Release Module Command: This command sets the selection bit and the occupancy bit to 0 only if the selection bit corresponding to the test case execution channel is 1. Alternatively, in an optional implementation, if the occupancy bit is 0, it is not reset to 0. This command is used to release the test case's use and occupancy of the module. When the corresponding selection bit is 1, it indicates that the current test case is using or occupies the module, and the module release operation can be performed.

[0057] Return to test case pool command: When a test case cannot continue execution because the conditions are not met, you can choose to return to the test case pool.

[0058] The above commands are universal for both SoC-level and module-level use cases. Each time a single command is invoked, it will only modify the state of a single module. Multiple commands can be invoked sequentially for multiple modules within each use case.

[0059] Further, see Figure 4As shown in the diagram, this embodiment of the invention provides a verification test case scheduling schematic. This embodiment provides test case scheduling logic, which can determine whether a test case meets the test conditions at any given moment based on the constraints of module state switching. Using the aforementioned operation interface, test case scheduling logic under multiple test case execution channels can be implemented. For the test case itself, the order in which the module operation interface commands are called is flexible and unrestricted, thereby maximizing the freedom of test case operations. However, in most cases, the calling order does not need to be overly complex to meet the requirements of the test case: such as... Figure 4 As shown, a typical test case can be divided into three parts: module state configuration, module usage, and module release. Module state configuration includes commands for module reset, initialization, and usage / possession. In this part, test cases whose test conditions are not met can return to the test case pool to wait for the next execution; test cases that meet the test conditions use the module normally and execute the test task; after the test case execution is complete, the command to release the module must be called to facilitate subsequent test cases using the module. Test cases can flexibly decide whether the above steps are needed; for example, the module release operation can be skipped to permanently possess the module during this debugging process. For SoC systems with multiple test case execution channels, a test case pool (i.e., the aforementioned verification test case pool) is created to store test cases. The test case pool can continuously allocate test cases to the test case execution channels. If a test case determines that the current conditions are not met, it can actively choose to return to the test case pool and wait for subsequent reassignment. Unmet test conditions can be conditions in the module usage command or module possession command. After a test case ends, it can enter the end test case pool.

[0060] In other words, this invention provides a prototype verification test case scheduling scheme based on module state management. It sets a series of state bits for each module within the SoC, and through combinations of these state bits, the current working state of the module is represented as idle, ready, used, occupied, and pending reset. It also provides an operation interface for configuring module state bits to the verification test cases. By constraining the switching logic between module states, verification test cases where hardware resources do not temporarily meet the test conditions are returned to the test case pool, repetitive initialization operations in test cases are skipped, and priority access for high-priority test cases is guaranteed. By constraining the switching between module states, test case failures caused by hardware resource conflicts are avoided. The execution order of test cases is optimized, allowing for the insertion of corresponding module-level verification test cases into modules not currently used by SoC-level test cases during SoC-level test case testing. This improves test case testing efficiency while also increasing the utilization efficiency of multi-core CPUs or multiple RTOS threads.

[0061] As can be seen, this embodiment of the invention sets status bits for the module under test (DUT) to characterize the module's state, including idle, ready, used, occupied, and pending reset states. On-chip system-level verification cases and module-level verification cases are placed in a verification case pool. Verification cases are selected from the pool and assigned execution channels. Multiple execution channels can execute verification cases in parallel. The assigned verification cases are executed through these channels, and the execution process of the target verification cases is controlled based on the DUT's status bits. This ensures that verification cases will only continue to execute when the state condition is met, avoiding hardware resource conflicts caused by other verification cases using a DUT that has been exclusively occupied. It balances on-chip system-level and module-level verification cases. While on-chip system-level verification cases are being executed, module-level verification cases can also be executed on modules that are not currently occupied. Combined with scheduling logic, this improves automation, enables multi-channel parallel processing, and increases hardware resource utilization and testing efficiency.

[0062] Furthermore, taking a SoC-level use case as an example, the verification use case scheduling scheme provided by the present invention is further illustrated. Such a SoC-level use case includes the following steps in sequence: 1. Reset operation, initialization operation and module possession command for module A; 2. Initialization operation for module B; 3. Module use command for module B and module C; 4. Execution of the remaining use case contents, including calling modules A, B and C; 5. Release module C.

[0063] When this test case is executed, if module A is in the occupied state (being occupied by another test case), module B is in the ready state (being initialized by another test case), and module C is in the used state (being used by another test case), then this test case will change module A to the pending reset state. After other modules release module A, a reset operation will be performed on module A, and then module A will be occupied. If it is detected that module B has been initialized, the initialization operation on module B will be skipped. If it is detected that module C is being used by another test case, since this test case only needs to use it and does not need to occupy it, the selection bit corresponding to this test case can be directly set to 1. After this test case is executed, only module C will be released, while the occupation of module A will continue, and the use of module B will continue. That is, after the execution of this SoC test case, module A will no longer be allowed to be called by other test cases, and module B will no longer be allowed to be occupied, reset, or initialized.

[0064] While this SoC-level test case is being executed, other test cases cannot call module A, nor can they occupy modules B and C. After the SoC-level test case finishes execution, other module-level verification test cases can still test module C, partially test module B, and test other modules not yet involved. Testers can review the results of this test and remove the tested SoC-level and module-level test cases from the test case pool, thereby allowing the testing of other verification test cases for modules A and B.

[0065] The above examples illustrate that this solution allows module-level test cases to be executed in a plug-and-play manner, making full use of hardware resources that are not involved in or are only partially tested by SoC-level test cases, while also improving the utilization efficiency of the test case execution channel.

[0066] In this embodiment, a module status bit is set for each module, and the combination of status bits describes the module's state. A switching path between module states is provided, and constraints on the switching path resolve the test case failure issue caused by hardware resource conflicts. Based on module state switching, the execution order rules of test cases are optimized, allowing module-level verification test cases to be inserted during the testing of SoC-level test cases, thereby improving test case testing efficiency.

[0067] In this way, by setting module status bits to describe the current working state of the module at each moment, the recorded status information can be used for debug analysis, improving the efficiency of problem localization. By constraining the switching logic between module states, test case failures caused by hardware resource conflicts are avoided, and repetitive initialization operations on a single module in multiple test cases are also prevented. Module-level verification test cases can be executed intermittently on unoccupied modules during SoC-level verification test case execution. The parallel processing capabilities of multi-core CPUs or RTOS threads are fully utilized to improve verification efficiency and hardware resource utilization. Through test case scheduling logic, the orderly execution of multiple test cases in complex verification scenarios is ensured, and high-priority SoC-level verification test cases are given priority access to hardware resources.

[0068] Further, see Figure 5 As shown, the present invention provides a verification test case scheduling device, comprising: The test case acquisition module 11 is used to acquire test cases from the test case pool to obtain target test cases, wherein the test case pool includes on-chip system-level test cases and module-level test cases; The channel allocation module 12 is used to allocate the target verification test case to the target test case execution channel among multiple test case execution channels, wherein the multiple test case execution channels are used to execute the verification test case in parallel; The test case execution module 13 is used to execute the target verification test case through the target test case execution channel, and control the execution process of the target verification test case based on the status bit of the module under test; The status bits are used to characterize the module status of the module under test. The module status includes idle state, ready state, used state, occupied state, and pending reset state. The idle state indicates that the module is not initialized. The ready state indicates that the module is initialized and waiting to be called by a verification test case. The used state indicates that the module is currently called by one or more verification test cases. The occupied state indicates that the module is currently exclusively occupied by one verification test case. The pending reset state indicates that the module will be reset.

[0069] Specifically, the test case execution module 13 can be used to execute the target test case and use the module command when the target verification test case calls the module command. If the status bit of the module under test indicates that the module under test is in a ready state or a used state, the target test case will continue to be executed, the module under test will be used, and if the status bit indicates that the module under test is in a ready state, the status bit will be modified to switch the module under test to a used state. Otherwise, the command execution failure information will be returned, and the target verification test case will be returned to the verification test case pool.

[0070] The test case execution module 13 can be specifically used to execute the target test case when the target verification test case calls the module occupancy command. If the status bit of the module under test indicates that the module under test is in the ready state, the target test case will continue to be executed, the module under test will be occupied, and the status bit will be modified to switch the module under test to the occupied state. Otherwise, the command execution failure information will be returned, and the target verification test case will be returned to the verification test case pool.

[0071] The test case execution module 13 can be specifically used to call the module state locking command to modify the locking bit in the status bit of the module under test when the target verification test case calls the initialization module command, so as to lock the module under test. After the initialization operation is performed on the module under test, the status bit is modified to switch the module under test to the ready state. Then, the module state unlock command is called to modify the locking bit in the status bit of the module under test to unlock the module under test.

[0072] The test case execution module 13 can be specifically used to detect the current status bit of the module under test. If the status bit indicates that the module under test is in an idle state, the step of modifying the lock bit in the status bit of the module under test by calling the module status lock command is triggered. Otherwise, the execution of the initialization module command is terminated to skip the initialization operation.

[0073] The test case execution module 13 can be specifically used to, when the target verification test case calls the reset module command, modify the status bit to switch the test module to the idle state and perform a reset operation if the status bit of the test module indicates that the test module is in the ready state, or modify the status bit to switch the test module to the pending reset state and wait for the test module to enter the idle state.

[0074] The test case execution module 13 can be specifically used to modify the status bit of the module under test when the target verification test case calls the release module command, so as to release the target verification test case's use of the module under test.

[0075] As can be seen, this embodiment of the invention sets status bits for the module under test (DUT) to characterize the module's state, including idle, ready, used, occupied, and pending reset states. On-chip system-level verification cases and module-level verification cases are placed in a verification case pool. Verification cases are selected from the pool and assigned execution channels. Multiple execution channels can execute verification cases in parallel. The assigned verification cases are executed through these channels, and the execution process of the target verification cases is controlled based on the DUT's status bits. This ensures that verification cases will only continue to execute when the state condition is met, avoiding hardware resource conflicts caused by other verification cases using a DUT that has been exclusively occupied. It balances on-chip system-level and module-level verification cases. While on-chip system-level verification cases are being executed, module-level verification cases can also be executed on modules that are not currently occupied. Combined with scheduling logic, this improves automation, enables multi-channel parallel processing, and increases hardware resource utilization and testing efficiency.

[0076] Figure 5 The description of the features in the corresponding embodiments can be found in [reference needed]. Figure 1 The relevant descriptions of the corresponding embodiments will not be repeated here.

[0077] Figure 6 A structural diagram of an electronic device provided in an embodiment of the present invention, such as... Figure 6 As shown, the electronic device includes: a memory 60 for storing computer programs; The processor 61 is used to implement the steps of the verification test case scheduling method as described in the above embodiments when executing a computer program.

[0078] The processor 61 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 61 may be implemented using at least one hardware form selected from Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor 61 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 61 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 61 may also include an Artificial Intelligence (AI) processor, which handles computational operations related to machine learning.

[0079] The memory 60 may include one or more computer-readable storage media, which may be non-transitory. The memory 60 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 60 is used to store at least the following computer program 601, which, after being loaded and executed by the processor 61, is capable of implementing the relevant steps of the verification test case scheduling method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 60 may also include an operating system 602 and data 603, and the storage method may be temporary or permanent storage. The operating system 602 may include Windows, Unix, Linux, etc. The data 603 may include, but is not limited to, verification test case data.

[0080] In some embodiments, the electronic device may further include a display screen 62, an input / output interface 63, a communication interface 64, a power supply 65, and a communication bus 66.

[0081] Those skilled in the art will understand that Figure 6 The structures shown do not constitute a limitation on electronic devices and may include more or fewer components than those shown.

[0082] It is understood that if the verification test case scheduling method in the above embodiments is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the current technology, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods in the various embodiments of the present invention. The aforementioned storage medium includes: USB flash drive, mobile hard drive, read-only memory (ROM), random access memory (RAM), electrically erasable programmable ROM, register, hard disk, removable disk, CD-ROM, magnetic disk or optical disk, and other media capable of storing program code.

[0083] Based on this, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the verification test case scheduling method described above.

[0084] This invention provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the aforementioned verification test case scheduling method.

[0085] The foregoing has provided a detailed description of a verification test case scheduling method, apparatus, device, and medium provided by embodiments of the present invention. The various embodiments are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0086] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0087] The present invention has provided a detailed description of a verification test case scheduling method, apparatus, device, and medium. Specific examples have been used to illustrate the principles and implementation methods of the invention. The descriptions of these embodiments are merely illustrative of the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to the invention without departing from its principles, and these improvements and modifications also fall within the scope of protection of the present invention.

Claims

1. A method for scheduling verification test cases, characterized in that, include: Target verification cases are obtained by retrieving verification cases from the verification case pool, wherein the verification case pool includes on-chip system-level verification cases and module-level verification cases; The target verification test case is assigned to a target test case execution channel in a plurality of test case execution channels, wherein the plurality of test case execution channels are used to execute the verification test case in parallel; The target verification test case is executed through the target test case execution channel, and the execution process of the target verification test case is controlled based on the status bit of the module under test; The status bits are used to characterize the module status of the module under test. The module status includes idle state, ready state, used state, occupied state, and pending reset state. The idle state indicates that the module is not initialized. The ready state indicates that the module is initialized and waiting to be called by a verification test case. The used state indicates that the module is currently called by one or more verification test cases. The occupied state indicates that the module is currently exclusively occupied by one verification test case. The pending reset state indicates that the module will be reset.

2. The verification test case scheduling method according to claim 1, characterized in that, The process of controlling the execution of the target verification test case based on the status bits of the module under test includes: When the target verification test case calls the module command, if the status bit of the module under test indicates that the module under test is in a ready or used state, the target test case continues to be executed, the module under test is used, and if the status bit indicates that the module under test is in a ready state, the status bit is modified to switch the module under test to the used state; otherwise, the command execution failure information is returned, and the target verification test case is returned to the verification test case pool.

3. The verification test case scheduling method according to claim 1, characterized in that, The process of controlling the execution of the target verification test case based on the status bits of the module under test includes: When the target verification test case calls the module occupancy command, if the status bit of the module under test indicates that the module under test is in the ready state, then the target test case continues to be executed, the module under test is occupied, and the status bit is modified to switch the module under test to the occupied state; otherwise, the command execution failure information is returned, and the target verification test case is returned to the verification test case pool.

4. The verification test case scheduling method according to claim 1, characterized in that, The process of controlling the execution of the target verification test case based on the status bits of the module under test includes: When the target verification test case calls the initialization module command, the module state lock command is called to modify the lock bit in the status bit of the module under test to lock the module under test. After the initialization operation is performed on the module under test, the status bit is modified to switch the module under test to the ready state. Then, the module state unlock command is called to modify the lock bit in the status bit of the module under test to unlock the module under test.

5. The verification test case scheduling method according to claim 4, characterized in that, Before calling the module status lock command to modify the lock bit in the status bits of the module under test, the following steps are also included: The current status bit of the module under test is detected. If the status bit indicates that the module under test is in an idle state, the step of calling the module status lock command to modify the lock bit in the status bit of the module under test is triggered. Otherwise, the execution of the initialization module command is terminated to skip the initialization operation.

6. The verification test case scheduling method according to claim 1, characterized in that, The process of controlling the execution of the target verification test case based on the status bits of the module under test includes: When the target verification test case calls the reset module command, if the status bit of the module under test indicates that the module under test is in the ready state, the status bit is modified to switch the module under test to the idle state and the reset operation is performed. If the status bit of the module under test indicates that the module under test is in the used state or the occupied state, the status bit is modified to switch the module under test to the pending reset state, wait for the module under test to enter the idle state, and then perform the reset operation.

7. The verification test case scheduling method according to claim 1, characterized in that, The process of controlling the execution of the target verification test case based on the status bits of the module under test includes: When the target verification test case calls the release module command, it modifies the status bit of the module under test to release the target verification test case's use of the module under test.

8. A verification test case scheduling device, characterized in that, include: The test case acquisition module is used to acquire test cases from the test case pool to obtain target test cases. The test case pool includes on-chip system-level test cases and module-level test cases. The channel allocation module is used to allocate the target verification test case to a target test case execution channel among multiple test case execution channels, wherein the multiple test case execution channels are used to execute the verification test case in parallel; The test case execution module is used to execute the target verification test case through the target test case execution channel, and control the execution process of the target verification test case based on the status bit of the module under test; The status bits are used to characterize the module status of the module under test. The module status includes idle state, ready state, used state, occupied state, and pending reset state. The idle state indicates that the module is not initialized. The ready state indicates that the module is initialized and waiting to be called by a verification test case. The used state indicates that the module is currently called by one or more verification test cases. The occupied state indicates that the module is currently exclusively occupied by one verification test case. The pending reset state indicates that the module will be reset.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the verification test case scheduling method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the verification test case scheduling method as described in any one of claims 1 to 7.

Images