Virtualized verification environment, verification method, computer equipment and storage medium

Abstract

The invention provides a virtualized verification environment, a verification method, computer equipment and a storage medium. The verification environment comprises a clock controller, a clock gating unit, an agent module and a Q-Channel model, wherein the model is used for executing the following functions: outputting a state signal to the clock controller; receiving a clock signal output by the clock gating unit, and receiving a request signal output by the clock controller; and completing handshake with the clock controller, and determining whether to execute a request of the request signal according to the state signal, so as to verify the clock signal in the model after the model completes handshake with the clock controller. Wherein the request signal is automatically initiated by the clock controller under the condition of receiving the enable signal and the state signal; the request signal comprises a request for entering a low-power-consumption state or a request for exiting the low-power-consumption state. According to the method, automatic handshake can be realized, the output logic of the handshake signal does not need to be considered at the excitation end, the code quantity is reduced, and the coverage rate is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the chip design technical field, in particular to a virtualized verification environment, a verification method, a computer device and a storage medium. BACKGROUND

[0002] The standardized design of P-Channel and Q-Channel allows them to be applied in a variety of different SOC (System on Chip) level chip designs, which provides a flexible and consistent way to manage the power consumption of the chip. Since the interface cannot exist independently of the control logic, the verification of the correctness of the interface control logic needs to ensure that the control logic complies with the standard protocol interface timing and internal state transition, and then the controller needs to return the handshake behavior and output logic that complies with the protocol as a slave (slave) of the low-power interface verification model.

[0003] However, the traditional low-power interface verification model has certain limitations. Its protocol handshake logic depends on the verification of the transmitted handshake signal, and the output logic of the handshake signal needs to be considered at the excitation end during verification, which requires a large amount of code. SUMMARY

[0004] The purpose of the embodiments of the present application is to provide a virtualized verification environment and method, and a computer device to solve the above problems.

[0005] In a first aspect, the embodiments of the present application provide a virtualized verification environment, comprising: a clock controller, a clock gating unit, a proxy module and a Q-Channel model; the Q-Channel model is used to simulate a Q-Channel interface; wherein the Q-Channel model is used to perform the following functions: outputting a state signal to the clock controller; the state signal is used to represent that the device represented by the Q-Channel model is in an idle state or a working state; receiving a clock signal output by the clock gating unit, and receiving a request signal output by the clock controller; wherein: the clock signal is generated by the clock gating unit according to a clock pause signal output by the clock controller; the clock pause signal is output by the clock controller according to a delay signal in the case of receiving an enable signal and a delay signal output by the proxy module; the request signal is automatically initiated by the clock controller in the case of receiving the enable signal and the state signal; the request signal includes an entry low-power state request or an exit low-power state request; handshake with the clock controller, and determine whether to respond to the request signal according to the state signal, to verify the clock signal in the Q-Channel model after the Q-Channel model and the clock controller complete handshake.

[0006] In the implementation solution, the Q-Channel model can automatically generate a state signal to automatically trigger a handshake, compared with the related art, the automatic handshake can be implemented, the output logic of the handshake signal does not need to be considered at the excitation end, and a large number of cases (use cases) do not need to be constructed to manually call the interface, so that the code amount can be reduced. In addition, the clock controller in the application automatically initiates an entering low-power state request or an exiting low-power state request in the case of receiving the enable signal and the state signal, so that different request scenarios can be covered, the verification coverage scenario is increased, and the verification reliability is improved.

[0007] Optionally, the Q-Channel model is specifically used for: in the case that the request signal includes an entering low-power state request and the state signal represents that the device represented by the Q-Channel model is not idle, the entering low-power state request is not executed, and a working state is maintained; in the case that the request signal includes an entering low-power state request and the state signal represents that the device represented by the Q-Channel model is idle, the entering low-power state request is executed, and an entering low-power state is performed; and in the case that the request signal includes an exiting low-power state request and the state signal represents that the device represented by the Q-Channel model is not idle, the exiting low-power state request is executed, and a working state is restored.

[0008] In the implementation solution, in the case that the request signal includes an entering low-power state request and the state signal represents that the device represented by the Q-Channel model is not idle, the entering low-power state request is not executed, and a working state is maintained; in the case that the request signal includes an entering low-power state request and the state signal represents that the device represented by the Q-Channel model is idle, the entering low-power state request is executed, and an entering low-power state is performed; and in the case that the request signal includes an exiting low-power state request and the state signal represents that the device represented by the Q-Channel model is not idle, the exiting low-power state request is executed, and a working state is restored. In this way, the operation performed by the Q-Channel model is consistent with the operation that should be performed by the Q-Channel interface in the actual chip, so that the verification process is more reliable and more comprehensive.

[0009] Optionally, the Q-Channel model is defined according to a preset standard protocol.

[0010] In the implementation solution, the Q-Channel model is defined according to a preset standard protocol, so that when verification is performed, a function does not need to be configured, and the operation of a DUT (device under test) can be implemented only by enabling a low-power function.

[0011] Optionally, the state signal is randomly generated by the Q-Channel model.

[0012] In the above implementation, the state signal is randomly generated by the Q-Channel model, so that the situation during verification can be consistent with the complex and changeable system state in the actual application scenario, thereby increasing the coverage of the limit scenario and improving the verification completeness.

[0013] In the first aspect, the embodiments of the present application also provide a verification method, comprising: calling the Q-Channel model to execute the function to complete handshake with the clock controller through the virtualized verification environment of any of the foregoing; and verifying whether the clock signal in the Q-Channel model is correctly turned off or restored after the Q-Channel model and the clock controller complete handshake.

[0014] Based on the above implementation, the verification of the correctness of the clock signal after the Q-Channel model and the clock controller complete handshake can be automatically implemented, thereby improving the verification efficiency.

[0015] In the first aspect, the embodiments of the present application also provide a verification method, applied to a Q-Channel model in a virtualized verification environment, the virtualized verification environment comprising a clock controller, a clock gating unit, a proxy module, and the Q-Channel model; the method comprising: outputting a state signal to the clock controller; the state signal being used to represent an idle state of a device represented by the Q-Channel model; receiving a clock signal output by the clock gating unit and a request signal output by the clock controller; wherein: the clock signal is generated by the clock gating unit according to a clock pause signal output by the clock controller; the clock pause signal is output by the clock controller according to a delay signal in the case of receiving an enable signal output by the proxy module and the delay signal; the request signal is automatically initiated by the clock controller in the case of receiving the enable signal and the state signal; the request signal comprises an entering low-power state request or an exiting low-power state request; completing handshake with the clock controller and determining whether to execute the request of the request signal according to the state signal, so as to verify the clock signal in the Q-Channel model after the Q-Channel model and the clock controller complete handshake.

[0016] Optionally, determining whether to execute the request signal based on the status signal includes: if the request signal includes a request to enter a low-power state and the status signal indicates that the device represented by the Q-Channel model is not idle, determining not to execute the request to enter a low-power state and completing a handshake with the clock controller to maintain the working state; if the request signal includes a request to enter a low-power state and the status signal indicates that the device represented by the Q-Channel model is idle, determining to execute the request to enter a low-power state and completing a handshake with the clock controller to enter a low-power state; if the request signal includes a request to exit a low-power state and the status signal indicates that the device represented by the Q-Channel model is not idle, determining to execute the request to exit a low-power state and completing a handshake with the clock controller to restore the working state.

[0017] Optionally, the Q-Channel model is defined for handshaking according to a preset standard protocol.

[0018] In a first aspect, embodiments of this application also provide a computer device, including: a processor and a memory; the memory stores a first program for implementing a virtualized verification environment as described above and a second program for implementing a verification method as described above; the processor is used to execute the first program and the second program stored in the memory.

[0019] In a first aspect, embodiments of this application also provide a computer-readable storage medium storing a first program for implementing a virtualized verification environment of any of the above and a second program for implementing a verification method of any of the above, wherein the first program and the second program can be executed by one or more processors.

[0020] In a second aspect, embodiments of this application provide a virtualized verification environment, including: a power controller, an agent module, and a P-Channel model; the P-Channel model is used to simulate a P-Channel interface; wherein, the P-Channel model is used to perform the following functions: sending a status signal to the power controller; the status signal is used to characterize the state of the power supply corresponding to the P-Channel model; receiving a power state switching request output by the power controller; wherein: the power state switching request is automatically initiated by the power controller upon receiving the enable signal output by the agent module and the status signal sent by the P-Channel model; completing a handshake with the power controller using an accept signal or a reject signal, and executing the power state switching request upon completing a handshake with the power controller using an accept signal, so as to check whether the changes in the signals received by the P-Channel model from the power controller are correct after the P-Channel model completes a handshake with the power controller.

[0021] In the above implementation scheme, the P-Channel model can automatically generate status signals to automatically trigger the handshake mechanism. Compared with related technologies, it can achieve automatic handshake without considering the output logic of the handshake signal at the excitation end. When building the verification program, it also eliminates the need to manually call a large number of interfaces using numerous test cases, thereby reducing the amount of code. Furthermore, the power controller in this application automatically initiates a power state switching request upon receiving enable and status signals, thus covering different request scenarios, increasing the verification coverage, and improving verification reliability.

[0022] Optionally, the state signal is generated by the P-Channel model without configuring generation constraints.

[0023] In the above implementation, by not configuring generation constraints for the state signals, the generated state signals can cover various power states such as correct and illegal, which can correspond to the complex and ever-changing system states in actual application scenarios, thereby increasing the coverage of extreme scenarios and improving the completeness of verification.

[0024] Optionally, the P-Channel model is further configured to: randomly use an accept signal to handshake with the power controller, or use a reject signal to handshake with the power controller upon receiving the power state switching request.

[0025] In the above implementation method, by randomly using accept or reject signals to perform the handshake, the situation of accepting or rejecting the handshake can be randomly simulated, thus corresponding to the complex and ever-changing situation in actual application scenarios and improving the completeness of verification.

[0026] Optionally, the P-Channel model is specifically used to: complete a handshake with the power controller according to a set delay time; wherein, the delay time is randomly generated by the P-Channel model in response to the power state switching request within a preset time range.

[0027] In the above implementation, by randomly generating the delay time for completing the handshake with the power controller, different handshake completion scenarios can be simulated, thus corresponding to the complex and ever-changing situations in actual application scenarios and improving the completeness of verification.

[0028] Optionally, the P-Channel model includes a request accept function and a request reject function; the power state switching request is also automatically initiated by the power controller when the proxy module disables the enable signal and receives a power policy signal from the proxy module; the P-Channel model is further configured to: in response to receiving the power state switching request and a request to call the request reject function, use a reject signal to handshake with the power controller; and, in response to receiving the power state switching request and a request to call the request accept function, use an accept signal to handshake with the power controller and execute the power state switching request.

[0029] In the above implementation, by pre-configuring the power policy signals, the power controller can automatically initiate a power state switching request without requiring an enable signal. Handshake control is achieved by calling the request accept or reject function, thus realizing controlled P-Channel verification. Even if the verifier calls the request accept or reject function, this approach eliminates the need to consider the handshake signal output logic on the stimulus side and avoids manually calling numerous interfaces using a large number of test cases, reducing the amount of code.

[0030] In a second aspect, embodiments of this application also provide a verification method, comprising: calling the P-Channel model to perform the function through any of the virtualized verification environments provided in the second aspect, so as to complete a handshake with the power controller; and after the P-Channel model completes a handshake with the power controller, checking whether the changes in the signals received by the P-Channel model from the power controller are correct.

[0031] Based on the above implementation method, the correctness of the changes in the signal received from the power controller after the P-Channel model and the power controller complete the handshake can be verified automatically, thereby improving the verification efficiency.

[0032] In a second aspect, embodiments of this application also provide a verification method applied to a P-Channel model in a virtualized verification environment, the virtualized verification environment including a power controller, an agent module, and a P-Channel model; the method includes: sending a status signal to the power controller; the status signal being used to characterize the state of the power supply corresponding to the P-Channel model; receiving a power state switching request output by the power controller; wherein: the power state switching request is automatically initiated by the power controller upon receiving an enable signal output by the agent module and a status signal issued by the P-Channel model; completing a handshake with the power controller using an accept signal or a reject signal, and executing the power state switching request upon completing a handshake with the power controller using an accept signal, so as to check whether the changes in the signals received by the P-Channel model from the power controller are correct after the P-Channel model completes a handshake with the power controller.

[0033] Optionally, a handshake can be completed with the power controller using an accept signal or a reject signal, including: randomly using an accept signal to handshake with the power controller, or using a reject signal to handshake with the power controller.

[0034] Optionally, the P-Channel model includes a request accept function and a request reject function; the power state switching request is also automatically initiated by the power controller when the proxy module disables the enable signal and receives a power policy signal from the proxy module; the method further includes: in response to receiving the power state switching request and a call request to the request reject function, using a reject signal to handshake with the power controller; or, in response to receiving the power state switching request and a call request to the request accept function, using an accept signal to handshake with the power controller and execute the power state switching request.

[0035] This application also provides a computer device, including: a processor and a memory; the memory stores a third program for implementing any of the virtualized verification environments provided in the second aspect above and a fourth program for implementing any of the verification methods provided in the second aspect above; the processor is used to execute the third program and the fourth program stored in the memory.

[0036] This application also provides a computer-readable storage medium, characterized in that the computer-readable storage medium stores a third program for implementing any of the virtualized verification environments provided in the second aspect above and a fourth program for implementing any of the verification methods provided in the second aspect above, wherein the third program and the fourth program can be executed by one or more processors. Attached Figure Description

[0037] 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.

[0038] Figure 1 A virtualized verification environment for the traditional Q-Channel model; Figure 2 A basic structural diagram of a Q-Channel virtualization verification environment provided in this application embodiment; Figure 3 A flowchart illustrating a verification method in a Q-Channel virtualized verification environment provided in this application embodiment; Figure 4 A flowchart illustrating another verification method in a Q-Channel virtualized verification environment provided in this application embodiment; Figure 5 A method corresponding to the embodiments of this application is provided. Figure 1 A schematic diagram of the Q-Channel virtualization verification environment; Figure 6 A schematic diagram of a basic module-level verification environment provided for embodiments of this application; Figure 7 A virtualized verification environment for the traditional P-Channel model; Figure 8 A basic structural diagram of a verification environment for P-Channel virtualization provided in this application embodiment; Figure 9 A flowchart illustrating a verification method in a P-Channel virtualization verification environment provided in this application embodiment; Figure 10 A flowchart illustrating another verification method in a P-Channel virtualization verification environment provided in this application embodiment; Figure 11 A method corresponding to the embodiments of this application is provided. Figure 7 A schematic diagram of the Q-Channel virtualization verification environment. Detailed Implementation

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

[0040] Example 1 To facilitate understanding of the solutions and advantages of the embodiments of this application, the relevant technologies will be introduced and explained below: See Figure 1 As shown, Figure 1 This demonstrates a virtualized verification environment for a traditional Q-Channel model. The system includes an APB Agent that configures the DUT (Device Under Test), the DUT (clock controller CLK_CTRL and clock gating unit Cg_stdcell), and the Q-Channel model via an APB (Advanced Peripheral Bus, peripheral bus in the AMBA bus architecture) interface. The APB Agent configures the clock controller's delay and enable signals; the clock controller and Q-Channel model handshake via Q-Channel, controlling the model's clock signals by controlling the clock gating unit; the Sequence is a handshake signal written by the verifier for handshaking with the clock controller.

[0041] The steps for verifying the DUT using a traditional Q-Channel virtualization verification environment are as follows: (1) The verifier configures the enable and delay signals of the clock controller through the APB interface; (2) The verifier configures the Qactive signal of the Q-Channel model through the APB interface; (3) The clock controller automatically initiates a request to enter / exit the low-power state based on the Qactive signal; (4) The verifier selects to accept or reject the request sent by the clock controller by calling the function in the Q-Channel model; (5) After the handshake is completed, the clock of the Q-Channel model is checked to ensure that it is correctly turned off / restored through assertions and other means.

[0042] in, Figure 1 The input signals Qreq, Qdeny, Qaccept, and Qactive are standard low-power interface signals used in the standard architecture to implement low-power control. Qactive is an indicator signal indicating whether entry into a low-power state is possible. Qreq, Qaccept, and Qdeny are handshake signals; a handshake between Qreq and Qaccept indicates that entry into a low-power state is possible, while a handshake between Qreq and Qdeny indicates that entry into a low-power state is refused. Ckstop: This represents the clock stop signal. When Qreq and Qaccept handshake, clk_ctrl (the clock controller) outputs a clock stop signal, which, after passing through cg_stdcell (the clock gating unit), stops the controlled clock signal. clk represents the clock signal. Apbif represents the enable signal.

[0043] It can be seen that the traditional Q-Channel virtualization verification environment relies on the handshake signal sequence passed by the verifier for the protocol handshake logic. However, manual handshake by the verifier can lead to situations where the corresponding signal is forgotten during the sequence writing process, resulting in system anomalies. Furthermore, verification requires considering the output logic of the handshake signal at the stimulus end, resulting in a large amount of code. In addition, the sequence representation is written according to the project, which is a positive verification approach and lacks verification for error scenarios such as unacceptable state transitions, resulting in insufficient completeness.

[0044] In order to address at least some of the problems existing in the related technologies, this application provides a new Q-Channel virtualization verification environment and its corresponding verification method.

[0045] See Figure 2 As shown, Figure 2 This illustration shows a basic structural diagram of the Q-Channel virtualization verification environment provided in this application embodiment, including: a clock controller, a clock gating unit (the clock controller and the clock gating unit constitute the DUT in the virtualized verification environment), a proxy module, and a Q-Channel model. The clock controller is connected to the proxy module, the clock gating unit, and the Q-Channel model, respectively, and the clock gating unit is connected to the Q-Channel model.

[0046] In this embodiment, the Q-Channel model is used to simulate the Q-Channel interface. The Q-Channel interface is a standard low-power interface defined by a bus protocol, which can be deployed in physical devices to implement clock-related low-power control. The Q-Channel model, defined through code, is a simulation model that can simulate the functionality of the Q-Channel interface. It should be noted that while the actual Q-Channel interface is deployed in a physical device, the Q-Channel model, as a simulation model, is deployed in a simulation platform. During simulation, there is no actual physical device with the Q-Channel interface deployed; however, when simulating, the Q-Channel model is assumed to be deployed in a physical device and simulates the relevant functions of the actual Q-Channel interface. Therefore, during simulation verification, the Q-Channel model will represent a physical device.

[0047] In the embodiments of this application, based on Figure 2 During verification in the illustrated environment, the Q-Channel model can generate status signals and send them to the clock controller. These status signals characterize the idle state of the device as represented by the Q-Channel model.

[0048] The agent module can respond to the enable signal input by the verifier or the upper-level control program and output the enable signal to the clock controller.

[0049] When the clock controller receives the enable signal from the agent module, it can automatically and randomly generate a request signal based on the currently received status signal. This request signal includes either a request to enter a low-power state or a request to exit a low-power state.

[0050] Simultaneously, the clock controller can output a clock pause signal to the clock gating unit, thereby controlling the clock gating unit to generate a clock signal according to the clock pause signal and output it to the Q-Channel model. Optionally, the clock pause signal can be input as a delay signal by the verifier or the upper-level control program through a proxy module to the clock controller, which then generates a corresponding clock pause signal based on the delay signal and provides it to the clock gating unit; alternatively, the clock pause signal can also be randomly generated by the clock controller.

[0051] The Q-Channel model receives the clock signal output from the clock gating unit and the request signal output from the clock controller, completes a handshake with the clock controller, and determines whether to execute the request signal based on the status signal, so as to verify the clock signal in the Q-Channel model after the Q-Channel model completes the handshake with the clock controller.

[0052] In this way, the Q-Channel model can automatically generate status signals to trigger the handshake mechanism. Compared with related technologies, it can achieve automatic handshake without considering the output logic of the handshake signal at the excitation end. When building the verification program, it also eliminates the need to manually call a large number of interfaces using numerous test cases, thereby reducing the amount of code. Furthermore, the clock controller in this application automatically initiates a request to enter or exit a low-power state upon receiving enable and status signals, thus covering different request scenarios, increasing the verification coverage, and improving verification reliability.

[0053] In some optional embodiments of this application, when the clock controller receives the enable signal and the status signal, it can automatically generate a request signal that is different from the current power consumption state of the virtualized verification environment. For example, if the current power consumption state of the virtualized verification environment is a low-power state, it can automatically generate a request to exit the low-power state; or, if the current power consumption state of the virtualized verification environment is not a low-power state, it can automatically generate a request to enter the low-power state.

[0054] In this embodiment of the application, the clock signal in the Q-Channel model can be verified by verifying whether the clock signal in the Q-Channel model is correctly turned off or restored.

[0055] In this embodiment of the application, when verifying the clock signal in the Q-Channel model, it can be done manually by a verifier, or a detection module can be set up to perform automated verification.

[0056] In this embodiment, assertions or other methods can be used to detect whether the clock signal in the Q-Channel model is correctly turned off or restored after the Q-Channel model and the clock controller complete their handshake. The turning off and restoration of the clock signal in the Q-Channel model is related to the Q-Channel model's processing of the request signal and the status of the clock pause signal (or delay signal) during the handshake.

[0057] In this application embodiment, an assertion library can be pre-built to record the correct shutdown or recovery status of the clock signal in the Q-Channel model under different request signals and clock pause signals (or delay signals), thereby realizing the detection of whether the clock signal in the Q-Channel model is correctly shut down or recovered.

[0058] In some optional embodiments of this application, the Q-Channel model is specifically used for: If the request signal includes a request to enter a low-power state and the state signal indicates that the device represented by the Q-Channel model is not idle, the request to enter a low-power state is not executed, and the working state is maintained. If the request signal includes a request to enter a low-power state and the state signal indicates that the device is idle as represented by the Q-Channel model, then the request to enter a low-power state is executed, and the device enters a low-power state. If the request signal includes an exit low-power state request and the state signal indicates that the device represented by the Q-Channel model is not idle, the exit low-power state request is executed, and the working state is restored.

[0059] This ensures that the operations performed by the Q-Channel model are consistent with the operations that the Q-Channel interface in the actual chip should perform, making the verification process more reliable and comprehensive.

[0060] Optionally, in some optional embodiments of this application, the Q-Channel model simulates the controlled device's possible acceptance or rejection of low-power handshake behavior. During verification, the model can randomly accept or reject without additional function calls to enable the DUT to operate.

[0061] In some optional embodiments of this application, the state signal can be randomly generated by the Q-Channel model to achieve complete randomness of the state signal. For example, the Q-Channel model can be configured with random value generation code to randomly generate either a signal value from two standard signal values ​​as the state signal. For instance, assuming signal value 1 represents not idle and signal value 0 represents idle, the Q-Channel model can automatically and randomly generate either signal value 0 or 1 as the state signal through the random value generation code. This allows the verification situation to correspond to the complex and ever-changing system states in actual application scenarios, thereby increasing the coverage of extreme scenarios and improving the completeness of the verification.

[0062] In some optional embodiments of this application, the proxy module can be implemented using the APB interface. For example, a simulation module capable of simulating the functions of the APB interface can be written according to the APB interface specification as the proxy module in this application embodiment.

[0063] Accordingly, see Figure 3 As shown, Figure 3 A flowchart illustrating a verification method using the Q-Channel model provided in the embodiments of this application, applied to the aforementioned virtualized verification environment, is shown, including: S301: The Q-Channel model generates status signals and sends them to the clock controller.

[0064] S302: The agent module responds to the enable signal input by the verifier or the upper-level control program and outputs the enable signal to the clock controller.

[0065] In the embodiments of this application, there is no timing restriction between steps S301 and S302.

[0066] S303: When the clock controller receives the enable signal from the agent module, it automatically and randomly generates a request signal based on the currently received status signal and sends it to the Q-Channel model. The request signal includes either a request to enter a low-power state or a request to exit a low-power state.

[0067] S304: The clock controller outputs a clock pause signal to the clock gating unit.

[0068] S305: The clock gating unit generates a clock signal according to the clock pause signal and outputs it to the Q-Channel model.

[0069] In the embodiments of this application, there is no timing restriction between steps S303 and steps S304 and S305.

[0070] S306: The Q-Channel model, upon receiving the clock signal output from the clock gating unit and the request signal output from the clock controller, completes a handshake with the clock controller and determines whether to execute the request signal based on the status signal.

[0071] In this embodiment of the application, after the Q-Channel model and the clock controller complete the handshake, the clock signal in the Q-Channel model can be verified, thereby realizing the verification of the DUT (i.e., the clock controller and clock gating unit).

[0072] In this embodiment of the application, the process of determining whether to execute the request of the request signal based on the status signal may include the following: Scenario 1: If the request signal includes a request to enter a low-power state and the status signal indicates that the device represented by the Q-Channel model is not idle, determine that the request to enter a low-power state will not be executed and the handshake with the clock controller will be completed to maintain the working state; Scenario 2: If the request signal includes a request to enter a low-power state and the status signal indicates that the device is idle as represented by the Q-Channel model, then it is determined to execute the request to enter a low-power state and complete the handshake with the clock controller to enter a low-power state. Scenario 3: If the request signal includes a request to exit the low-power state and the status signal indicates that the device represented by the Q-Channel model is not idle, determine to execute the request to exit the low-power state and complete the handshake with the clock controller to restore the working state.

[0073] Based on the same inventive concept, see also Figure 4 As shown, Figure 4 A schematic diagram of the verification process using the virtualized verification environment provided in the embodiments of this application is shown, including: S401: Using the virtualized verification environment provided in this embodiment, the Q-Channel model is invoked to execute the functions of the Q-Channel model in order to complete the handshake with the clock controller.

[0074] S402: After the Q-Channel model and the clock controller complete the handshake, verify whether the clock signal in the Q-Channel model has been correctly turned off or restored.

[0075] It is understandable that, for the sake of brevity, some of the content described in the verification environment embodiments will not be repeated in the method embodiment section, and the relevant content can be reused if there is no conflict.

[0076] To facilitate understanding of the solutions in the embodiments of this application, the following will be used as examples. Figure 5Taking the Q-Channel virtualization verification environment shown as an example, the solution of this application embodiment will be further illustrated. Figure 5 The agent module is the APB Agent, and the Q-Channel device model is the Q-Channel model.

[0077] See Figure 5 The Q-Channel virtualization verification environment shown is compared with... Figure 1 The Q-Channel virtualization verification environment shown is Figure 5 The Q-Channel virtualization verification environment shown has the following characteristics: (1) Compared with the solution in this embodiment, Figure 1 In this approach, the status signal (Qactive) can be generated completely randomly to indicate whether the device is idle, which corresponds to the complex and ever-changing system states in real-world application scenarios. (2) After receiving the request signal from the clock controller, the Q-Channel model can begin to make judgments: 1) If a request is made to exit low power mode and the status signal is valid (i.e., the status signal indicates that the device represented by the Q-Channel model is not idle), the Q-Channel model will automatically accept the request to complete the handshake and resume the working state. 2) If a request is made to enter a low-power state and the status signal is invalid (i.e., the status signal indicates that the device represented by the Q-Channel model is idle), the Q-Channel model will automatically accept the request to complete the handshake and enter the low-power state. 3) If a request is made to enter low power mode, but the status signal is valid (i.e., the status signal indicates that the device represented by the Q-Channel model is not idle), the Q-Channel model will automatically reject the request and complete the handshake behavior to continue working.

[0078] Figure 5 The Q-Channel virtualization verification environment shown eliminates the handshake step of the Q-Channel model verification verifier inputting the Sequence, and instead achieves automatic handshake. There is no need to consider the output logic of the handshake signal on the excitation end, which reduces the amount of code. As shown above, the state signal of the Q-Channel model uses a completely random method, which can cover scenarios such as the device needing to exit the low power state when it is not idle, the device needing to enter the low power state when it is not idle, and the device needing to enter the low power state when it is idle, which can maximize the coverage of scenarios.

[0079] use Figure 5 The steps for verifying the DUT in the Q-Channel virtualization verification environment shown are as follows: (1) The clock controller responds to the configuration of the verifier or upper-level software through the APB interface (i.e., APB Agent, which is the agent module) to obtain the enable signal and delay signal; (2) The clock controller automatically and randomly initiates a request to enter / exit the low-power state based on the Qactive signal; (3) The Q-Channel model automatically hands over to the clock controller; (4) After the handshake is completed, the clock of the Q-Channel model is checked to ensure that it is correctly turned off / restored through assertions and other means.

[0080] For details on the implementation process, please refer to [the relevant documentation / instructions]. Figure 3 As shown, it will not be elaborated further here.

[0081] use Figure 5 When performing verification in the Q-Channel virtualization verification environment shown, the verifier only needs to configure the enable signal of the DUT during the system initialization phase. Subsequent state switching handshakes are all automatically completed by the Q-Channel model, and all requests are sent randomly, which increases the coverage of extreme scenarios, reduces the workload and code complexity of the verifier, and improves the completeness of verification while improving work efficiency.

[0082] Furthermore, when performing module-level verification using the aforementioned Q-Channel virtualization verification environment, please refer to... Figure 6 As shown, Figure 6 This demonstrates a basic module-level verification environment, which includes, at the top level of verification, features such as... Figure 6 The master (upstream driving component), slave (verification model, Q-Channel model in this embodiment), and DUT (Device Under Test) interact with each other. After the environment is compiled, the corresponding test stimuli are issued through the master, and verification is completed according to different requirements. Among them, Testcase is the test case, and Compiler is the compilation module used to compile the Testcase.

[0083] based on Figure 6 A modular environment structure, using Figure 5 The verification process for the Q-Channel virtualization verification environment shown includes the following steps: Step S1: Instantiate the Q-Channel verification model and DUT at the top level of verification, connect the interface between the DUT and the model, and define the system clock and reset signal; Step S2: Write a Sequence (this Sequence does not contain a handshake signal); Step S2 includes the following two sub-steps: Step S2-1: In the Sequence, use the APB VIP (Verification IP, a verification IP core used to verify the APB bus design) to configure the clock controller register through the APB interface to enable the clock controller.

[0084] Step S2-2: In the Sequence, use the APB VIP to configure the Q-Channel handshake signal delay of the DUT through the APB interface to configure the clock controller register.

[0085] Step S3: Add the Sequence to the Testcase.

[0086] Step S4: Add the check assertions developed according to the standard protocol to the SVA directory (assertions directory) and bind them to the top level of the verification.

[0087] Step S5: Compile and run the testcase using the module-level environment; Step S6: Collect functional coverage data and check the correctness of the DUT functions.

[0088] By using this invention, the following technical effects can be achieved: Highly efficient automated verification capability: The Q-Channel model enables one-click handshake through a clock controller, reducing human error and stimulus configuration complexity. At the same time, it is compatible with diverse scenario configurations, improving the coverage of verification scenarios and enhancing the completeness of verification.

[0089] Highly compatible architecture design: It adopts a module-level incentive code architecture and an automated handshake mechanism to achieve lightweight model integration. The structure of the Q-Channel virtualized verification environment supports rapid cross-project portability and parameterized configuration, adapting to the verification needs of multiple types of chips.

[0090] In this embodiment, the DUT (clock controller and clock gating unit) can be a simulation circuit. Based on the same inventive concept, this embodiment provides a computer device, including a processor and a memory. The memory may store a first program for implementing the virtualized verification environment provided in this embodiment and a second program for implementing the verification method provided in this embodiment; the processor is used to execute the first program and the second program stored in the memory.

[0091] In the embodiments of this application, the processor can be a GPU (Graphics Processing Unit), CPU (Central Processing Unit), AI (Artificial Intelligence) processor, NPU (Neural Network Processing Unit), ISP (Image Signal Processor), DPU (Display Processing Unit), VPU (Video Processing Unit), DSP (Digital Signal Processor) data processing core, etc., or it can be a processor chip applied to scenarios such as large-scale data computation. The memory 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.

[0092] It is also understood that computer devices may include more or fewer components, or have different configurations. For example, they may have an internal communication bus for communication between the processor and memory; they may also have external communication interfaces, such as USB (Universal Serial Bus) interfaces, CAN (Controller Area Network) bus interfaces, etc.; and they may also have information display components such as displays, but this is not a limitation.

[0093] Based on the same inventive concept, this embodiment also provides 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. This computer-readable storage medium stores a first program for implementing the virtualized verification environment provided in this embodiment and a second program for implementing the verification method provided in this embodiment; the first program and the second program can be executed by one or more processors. Further details will not be elaborated here.

[0094] Example 2 To facilitate understanding of the solutions and advantages of the embodiments of this application, the relevant technologies will be introduced and explained below: See Figure 7 As shown, Figure 7This demonstrates a virtualized verification environment for a traditional P-Channel model. The system includes an APB Agent that configures the DUT (Power Controller PWR_CTRL), and the P-Channel model via the APB interface. The APB Agent is used to configure the power controller's enable and power policy signals; the power controller and the P-Channel model communicate via a P-Channel handshake to control the model's reset, isolation, and power signals; and the Sequence is a handshake signal written by the verifier for communicating with the power controller.

[0095] The steps for validating the DUT using a traditional P-Channel virtualization verification environment are as follows: (1) The verifier configures the enable signal of the power controller through the APB interface; (2) The verifier configures the power strategy signal of the power controller through the APB interface, sends a power state switching request, and pulls Preq high; (3) The verifier selects to accept or reject the request sent by the power controller by calling the function in the P-Channel model; (4) After the handshake is completed, check whether the reset, isolation and other signals received by the power controller from the P-Channel model change correctly by means of assertion and other methods.

[0096] in, Figure 7 The input signals Preq, Paccept, Pdeny, Pactive, and Pstate are standard interface information used to manage power states. Pactive indicates the current power state; Pstate indicates the target state to which the user needs to transition; the Preq and Paccept handshake indicates that the requested Pstate can be switched successfully; the Preq and Pdeny handshake indicates that the requested Pstate cannot be switched to if it is not illegal or inappropriate, and the user returns to the original state; nisolate and npwrup: P-Channel has the function of controlling power states, and these two signals are power-related, changing with Pstate; rst-n: The reset signal, like nisolate and npwrup, changes with Pstate. APbif represents the enable signal.

[0097] It can be seen that the traditional P-Channel virtualization verification environment relies on the handshake signal sequence passed by the verifier for the protocol handshake logic. However, manual handshake by the verifier can lead to situations where the corresponding signal is forgotten during the sequence writing process, resulting in system anomalies. Furthermore, verification requires considering the output logic of the handshake signal at the stimulus end, resulting in a large amount of code. In addition, the sequence writing is done on a project-by-project basis, which is a positive verification approach and lacks verification for error scenarios such as unacceptable state transitions, resulting in insufficient completeness.

[0098] In order to address at least some of the problems existing in the related technologies, this application provides a new verification environment for P-Channel virtualization and its corresponding verification method.

[0099] See Figure 8 As shown, Figure 8 This diagram illustrates the basic structure of a verification environment for P-Channel virtualization provided in this embodiment, including: a power controller, an agent module, and a P-Channel model. The power controller is connected to both the agent module and the P-Channel model.

[0100] In this embodiment, the P-Channel model is used to simulate the P-Channel interface. The P-Channel interface is a standard low-power interface defined by a bus protocol, which can be deployed in physical devices to achieve power-related low-power control. The P-Channel model is a simulation model defined by code that can simulate the functionality of the P-Channel interface.

[0101] In the embodiments of this application, based on Figure 8 When the verification environment shown is used for verification, the P-Channel model can send status signals to the power controller. These status signals characterize the state of the power supply corresponding to the P-Channel model.

[0102] The agent module can respond to the enable signal input by the verifier or the upper-level control program and output the enable signal to the power controller.

[0103] When the power controller receives the enable signal from the agent module and the status signal from the P-Channel model, it can automatically output a power state switching request to the P-Channel model.

[0104] When the P-Channel model receives a power state switching request from the power controller, it uses an accept signal or a reject signal to complete a handshake with the power controller. If the handshake is completed using an accept signal, the P-Channel model executes the power state switching request. After the P-Channel model completes the handshake with the power controller, it checks whether the changes in the signals received by the P-Channel model from the power controller are correct.

[0105] In this embodiment, the accept signal can be Paccept, which is used to handshake with a power state switching request (such as Preq): indicating that the power state switching request can be executed, that is, a power state switch can be performed. The deny signal can be Pdeny, which is used to handshake with a power state switching request (such as Preq): indicating that the power state switching request is illegal or inappropriate, and the power state cannot be switched.

[0106] In this embodiment, the power state switching request is automatically initiated by the power controller upon receiving the enable signal output by the agent module and the status signal issued by the P-Channel model.

[0107] In some alternative implementations, the state signals can be generated by the P-Channel model without configuring generation constraints. This allows the generated state signals to cover various power states, including correct and invalid states, thus reflecting the complex and ever-changing system states in real-world applications. This increases the coverage of extreme scenarios and improves the completeness of the verification.

[0108] In some optional implementations, the P-Channel model is also used to: randomly use an accept signal or a reject signal to handshake with the power controller upon receiving a power state switching request. For example, the P-Channel model may include code that randomly invokes the accept and reject signals, thereby randomly calling one of the accept or reject signals to handshake with the power controller. In this way, by randomly using the accept or reject signal to handshake with the power controller, the situation of the device or P-Channel model accepting or rejecting the handshake can be randomly simulated, thus corresponding to the complex and varied situations in real-world application scenarios and improving the completeness of the verification.

[0109] In some exemplary embodiments of the above optional implementations, the ratio of accept signals to rejection signals can be randomly generated, thereby randomly using either accept signals or rejection signals to handshake with the power controller according to this ratio. For example, assuming the randomly generated ratio of accept signals to rejection signals is 6:4, then in every 10 handshakes, accept signals can be randomly used in 6 of the 10 handshakes, and rejection signals can be used in the other 4 handshakes.

[0110] In some alternative implementations, the P-Channel model can be specifically used to complete a handshake with the power controller according to a set delay time. This delay time is randomly generated by the P-Channel model within a preset time range in response to a power state switching request. This allows for the simulation of different handshake completion scenarios, thus reflecting the complex and varied situations in real-world applications and improving the completeness of the verification.

[0111] The above implementation achieves a fully automated handshake. In some alternative implementations, a controlled handshake can also be achieved with partial intervention from the verifier.

[0112] For example, the P-Channel model can include request acceptance and request rejection functions. Power state switching requests are also automatically initiated by the power controller when the agent module is disabled and a power policy signal is received from the agent module.

[0113] The P-Channel model is also used to: handshake with the power controller using a rejection signal in response to receiving a power state switching request and a request to reject the function; and to handshake with the power controller using an acceptance signal and execute the power state switching request in response to receiving a power state switching request and a request to accept the function.

[0114] In this way, the verifier can control the verification process by calling the request accept function or request reject function. This approach also eliminates the need to consider the output logic of the handshake signal on the stimulus side and avoids building a large number of cases to manually call the interface, thus reducing the amount of code.

[0115] In this embodiment, the power strategy signal refers to the signal that implements the power control strategy. The power control strategy is used to set how the power supply switches states and can be pre-programmed.

[0116] In this embodiment of the application, when verifying whether the changes in the signal received by the P-Channel model from the power controller are correct, the verification can be performed manually by a verification engineer, or a detection module can be set up to perform automated verification.

[0117] In this embodiment, assertions or other methods can be used to detect whether the changes in the signals received by the P-Channel model from the power controller are correct after the P-Channel model and the power controller have completed their handshake. The changes in the signals received by the P-Channel model from the power controller are related to the P-Channel model's handling of power state switching requests, the type of signal used for the handshake, and the handshake delay duration.

[0118] In this embodiment, an assertion library can be pre-built to record the changes in the signals received by the P-Channel model from the power controller under different power state switching request processing methods, different handshake situations, and different handshake delay durations, thereby enabling the detection of whether the changes in the signals received by the P-Channel model from the power controller are correct.

[0119] In some optional embodiments of this application, the proxy module can be implemented using the APB interface. For example, a simulation module capable of simulating the functions of the APB interface can be written according to the APB interface specification as the proxy module in this application embodiment.

[0120] Correspondingly, you can participate Figure 9 As shown, Figure 9 A flowchart illustrating a verification method applied in the virtualized verification environment provided in the embodiments of this application is shown, including: S901: The P-Channel model sends status signals to the power controller.

[0121] In this embodiment, the state signal is used to characterize the state of the power supply corresponding to the P-Channel model.

[0122] S902: The agent module responds to the enable signal input by the verifier or the upper-level control program and outputs an enable signal to the power controller.

[0123] In the embodiments of this application, there is no timing restriction between steps S301 and S302.

[0124] S903: Upon receiving the enable signal from the agent module and the status signal from the P-Channel model, the power controller automatically outputs a power state switching request to the P-Channel model.

[0125] S904: When the P-Channel model receives a power state switching request from the power controller, it uses an accept signal or a reject signal to complete a handshake with the power controller, and executes the power state switching request if it completes the handshake with the power controller using an accept signal.

[0126] After the P-Channel model completes its handshake with the power controller, it can be checked whether the changes in the signals received by the P-Channel model from the power controller are correct.

[0127] In some optional embodiments of this application, using an accept signal or a reject signal to complete a handshake with the power controller includes: randomly using an accept signal to perform a handshake with the power controller, or using a reject signal to perform a handshake with the power controller.

[0128] In some optional embodiments of this application, the P-Channel model may include a request acceptance function and a request rejection function. The power state switching request may also be automatically initiated by the power controller when the agent module is enabled and a power policy signal from the agent module is received. In this case, the method may further include: In response to receiving a power state switching request and a request to call the request rejection function, a handshake is initiated with the power controller using a rejection signal; or, In response to receiving a power state switching request and a request to accept the request function, the system uses an accept signal to handshake with the power controller and executes the power state switching request.

[0129] Based on the same inventive concept, see also Figure 10 As shown, Figure 10 A schematic diagram of the verification process using the virtualized verification environment provided in the embodiments of this application is shown, including: S1001: Using the virtualized verification environment provided in this embodiment, the P-Channel model is invoked to execute its functions in order to complete a handshake with the power controller.

[0130] S1002: After the P-Channel model completes the handshake with the power controller, check whether the changes in the signals received by the P-Channel model from the power controller are correct.

[0131] It is understandable that, for the sake of brevity, some of the content described in the verification environment embodiments will not be repeated in the method embodiment section, and the relevant content can be reused if there is no conflict.

[0132] Based on the above implementation scheme, the P-Channel model can automatically generate state signals to automatically trigger the handshake mechanism. Compared with related technologies, it can achieve automatic handshake without considering the output logic of the handshake signal at the excitation end. When building the verification program, it also eliminates the need to manually call a large number of interfaces using numerous test cases, thereby reducing the amount of code. Furthermore, the power controller in this application automatically initiates a power state switching request upon receiving enable and state signals, thus covering different request scenarios, increasing the verification coverage, and improving verification reliability.

[0133] To facilitate understanding of the solutions in the embodiments of this application, the following will be used as examples. Figure 11 Taking the P-Channel virtualization verification environment shown as an example, the solution of this application embodiment will be further illustrated. Figure 11 The agent module is APB Agent, PWR-CTRL is the power controller, and P-Channel device model is the P-Channel module.

[0134] See Figure 11 The P-Channel virtualization verification environment shown is compared with... Figure 7 The P-Channel virtualization verification environment shown is Figure 11 The P-Channel virtualization verification environment shown has the following characteristics: (1) Compared with the solution in this embodiment, Figure 7 In this approach, the status signal (Pactive) is unconstrained and can cover various power states, including correct and invalid.

[0135] (2) The P-Channel model has a request accept function and a request reject function to meet the handshake requirement of the verifier under certain circumstances.

[0136] (3) Add an automatic handshake function to randomly generate handshake weights (i.e., the ratio of accept signals to reject signals). Upon receiving a state switching request from the power controller, the P-Channel model automatically determines whether to accept or reject the handshake based on the handshake weights.

[0137] (4) The delay time during the handshake process is randomized within the protocol specification.

[0138] Figure 11 The P-Channel virtualized verification environment shown eliminates the step of the verifier sending the sequence, and Figure 11 The status signals of the P-Channel virtualization verification environment shown are presented in a completely random manner, which can maximize the coverage of the scene.

[0139] useFigure 11 When the P-Channel virtualization verification environment verifies the DUT, there are two methods, as follows: Method 1: (1-1) The APB interface (i.e., APB Agent, which is the agent module) responds to the verifier's configuration operation by turning off the enable signal of the power controller (i.e., not inputting an enable signal to the power controller).

[0140] (2-1) The APB interface responds to the power policy signal of the power controller input by the verifier, controls the power controller to send a power state switching request, and pulls Preq high.

[0141] (3-1) The P-Channel model responds to calls to functions in the P-Channel model by choosing to accept or reject requests from the power controller.

[0142] (4-1) After the handshake is completed, check whether the reset, isolation and other signals received by the power controller from the P-Channel model change correctly by means of assertion and other methods.

[0143] Method 2: (1-2) The APB interface responds to the verifier's configuration operation by turning on the power controller's enable signal (i.e., inputting an enable signal to the power controller). (2-2) The power controller automatically initiates a power state switching request based on a completely random Pactive signal; (3-2) The P-Channel model accepts or rejects the handshake based on randomly generated handshake weights; (4-2) After the handshake is completed, check whether the reset, isolation and other signals received by the power controller from the P-Channel model change correctly by means of assertion and other methods.

[0144] For details on the implementation process, please refer to [the relevant documentation / instructions]. Figure 9 As shown, it will not be elaborated further here.

[0145] use Figure 11 When performing verification in the P-Channel virtualization verification environment shown, the verifier can configure the DUT's enable signal only during the system initialization phase. Subsequent state transition handshakes can be automatically completed by the P-Channel model, and all requests are sent randomly, increasing the coverage of extreme scenarios, reducing the verifier's workload and code complexity, and improving verification completeness while improving work efficiency.

[0146] Furthermore, when performing module-level verification using the aforementioned P-Channel virtualization verification environment, please refer to... Figure 6 As shown,Figure 6 This demonstrates a basic module-level verification environment, which includes, at the top level of verification, features such as... Figure 6 The master (upstream driving component), slave (verification model, P-Channel model in this embodiment), and DUT (Device Under Test) interact with each other. After the environment is compiled, the corresponding test stimuli are issued through the master, and verification is completed according to different requirements. Among them, Testcase is the test case, and Compiler is the compilation module used to compile the Testcase.

[0147] based on Figure 6 A modular environment structure, using Figure 11 The verification process for the P-Channel virtualization verification environment shown includes the following steps: Step S1: Instantiate the P-Channel model and DUT at the top level for verification, connect the interface between the DUT and the P-Channel model, and define the system clock and reset signal; Step S2: Write a Sequence (this Sequence does not contain a handshake signal); Step S2 includes the following sub-steps: Step S2-1: In the Sequence, program the following: Use the APB VIP to configure the power controller register to send a power-on request via the APB interface; Step S2-2: In the Sequence, include: calling the function in the P-Channel model to accept the power-on request; Step S2-3: In the Sequence, program the following: Use the APB VIP to configure the power controller register through the APB interface to enable the power controller function; Step S2-4: In the Sequence, set the random number of times to call the P-Channel model's automatic handshake function each time; Step S3: Add the Sequence to the Testcase; Step S4: Add the check assertions developed according to the standard protocol to the SVA directory and bind them to the top level of the verification; Step S5: Compile and run the Testcase using the module-level environment script; Step S6: Collect functional coverage data and check the correctness of the DUT functions.

[0148] By using this invention, the following technical effects can be achieved: Highly efficient automated verification capability: The P-Channel model achieves dynamic decision-making based on random handshake weight configuration (which can respond randomly or be manually intervened), reducing human error and incentive configuration complexity. At the same time, it is compatible with diverse scenario configurations, improving the coverage of verification scenarios and enhancing the completeness of verification.

[0149] Enhanced Dynamic Error Scenario Coverage: Supports dynamic control of power state switching with completely random active indication signals. By using a fault injection mechanism (random handshake weights) to cover unconventional power conversion sequences, the detection rate of abnormal scenarios is improved, which can effectively expose deep-seated hardware design defects.

[0150] Highly compatible architecture design: It adopts a module-level incentive code architecture and an automated handshake mechanism to achieve lightweight model integration. The structure of the P-Channel virtualized verification environment supports rapid cross-project portability and parameterized configuration, adapting to the verification needs of multiple types of chips.

[0151] In this embodiment, the DUT (Power Under Test) can be a simulation circuit. Based on the same inventive concept, this embodiment provides a computer device, including a processor and a memory. The memory may store a third program for implementing the virtualized verification environment provided in this embodiment and a fourth program for implementing the verification method provided in this embodiment; the processor is used to execute the third and fourth programs stored in the memory.

[0152] In the embodiments of this application, the processor can be a data processing core such as a GPU, CPU, AI processor, NPU, ISP, DPU, VPU, or DSP, or a processor chip applied to scenarios such as large-scale data computation. The memory can be RAM, ROM, or flash memory. The above are merely examples and should not be construed as limiting this application.

[0153] It is also understood that computer devices may include more or fewer components, or have different configurations. For example, they may have an internal communication bus for communication between the processor and memory; they may also have external communication interfaces, such as USB interfaces, CAN bus interfaces, etc.; and they may also have information display components such as displays, but these are not limitations.

[0154] Based on the same inventive concept, this embodiment also provides a computer-readable storage medium, such as a floppy disk, optical disk, hard disk, flash memory, USB flash drive, SD card, MMC card, etc., in which a third program for implementing the virtualized verification environment provided in this embodiment and a fourth program for implementing the verification method provided in this embodiment are stored; the third program and the fourth program can be executed by one or more processors. Further details will not be provided here.

[0155] In the embodiments provided in this application, it should be understood that the disclosed environment and methods can be implemented in other ways. The embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0156] In the various embodiments of this application, the functional modules can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0157] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

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

[0159] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. 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 virtualized verification environment, characterized in that, include: The system comprises a clock controller, a clock gating unit, a proxy module, and a Q-Channel model; the Q-Channel model is used to simulate the Q-Channel interface; wherein the Q-Channel model performs the following functions: The clock controller outputs a status signal; the status signal is used to characterize whether the device represented by the Q-Channel model is in an idle state or an operating state. The system receives a clock signal output by the clock gating unit and a request signal output by the clock controller; wherein: the clock signal is generated by the clock gating unit based on a clock pause signal output by the clock controller; the clock pause signal is output by the clock controller based on the delay signal upon receiving an enable signal and a delay signal from the proxy module; the request signal is automatically initiated by the clock controller upon receiving the enable signal and the status signal; the request signal includes a request to enter a low-power state or a request to exit a low-power state. The system completes a handshake with the clock controller and determines whether to respond to the request signal based on the status signal, so as to verify the clock signal in the Q-Channel model after the Q-Channel model completes the handshake with the clock controller.

2. The virtualized verification environment as described in claim 1, characterized in that, The Q-Channel model is specifically used for: If the request signal includes a request to enter a low-power state and the state signal indicates that the device represented by the Q-Channel model is not idle, the request to enter a low-power state is not executed, and the working state is maintained. If the request signal includes a request to enter a low-power state and the state signal indicates that the device represented by the Q-Channel model is idle, the request to enter a low-power state is executed, and the device enters a low-power state. If the request signal includes a request to exit the low-power state and the state signal indicates that the device represented by the Q-Channel model is not idle, the request to exit the low-power state is executed, and the working state is restored.

3. The virtualized verification environment as described in claim 1 or 2, characterized in that, The Q-Channel model defines the handshake according to a preset standard protocol.

4. The virtualized verification environment as described in claim 1 or 2, characterized in that, The state signal is randomly generated by the Q-Channel model.

5. A verification method, characterized in that, include: The Q-Channel model is invoked to perform the function in the virtualized verification environment as described in any one of claims 1-4, in order to complete a handshake with the clock controller; After the Q-Channel model and the clock controller complete their handshake, verify whether the clock signal in the Q-Channel model has been correctly turned off or restored.

6. A verification method, characterized in that, In a Q-Channel model applied to a virtualized verification environment, the virtualized verification environment includes a clock controller, a clock gating unit, an agent module, and the Q-Channel model; the method includes: Output a status signal to the clock controller; the status signal is used to characterize the idle state of the device as represented by the Q-Channel model; The system receives a clock signal output by the clock gating unit and a request signal output by the clock controller; wherein: the clock signal is generated by the clock gating unit based on a clock pause signal output by the clock controller; the clock pause signal is output by the clock controller based on the delay signal upon receiving an enable signal and a delay signal from the proxy module; the request signal is automatically initiated by the clock controller upon receiving the enable signal and the status signal; the request signal includes a request to enter a low-power state or a request to exit a low-power state. The system completes a handshake with the clock controller and determines whether to execute the request signal based on the status signal, so as to verify the clock signal in the Q-Channel model after the Q-Channel model completes the handshake with the clock controller.

7. The verification method as described in claim 6, characterized in that, Determining whether to execute the request signal based on the status signal includes: If the request signal includes a request to enter a low-power state and the state signal indicates that the device represented by the Q-Channel model is not idle, it is determined that the request to enter a low-power state will not be executed and a handshake will be completed with the clock controller to maintain the working state. If the request signal includes a request to enter a low-power state and the state signal indicates that the device represented by the Q-Channel model is idle, it is determined to execute the request to enter a low-power state and complete the handshake with the clock controller to enter a low-power state. If the request signal includes a request to exit the low-power state and the state signal indicates that the device represented by the Q-Channel model is not idle, it is determined to execute the request to exit the low-power state and complete the handshake with the clock controller to restore the working state.

8. The verification method as described in claim 6, characterized in that, The Q-Channel model defines the handshake according to a preset standard protocol.

9. A computer device, characterized in that, include: A processor and a memory; the memory stores a first program for implementing a virtualized verification environment as described in any one of claims 1-4 and a second program for implementing a verification method as described in any one of claims 5-8; the processor is configured to execute the first program and the second program stored in the memory.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a first program for implementing a virtualized verification environment as described in any one of claims 1-4 and a second program for implementing a verification method as described in any one of claims 5-8, wherein the first program and the second program can be executed by one or more processors.

Images