Reset verification method and device in business process, equipment and medium

Abstract

The invention provides a reset verification method and device in a business process, equipment and a medium, and relates to the technical field of digital chip verification. The method comprises the following steps: executing service excitation and reset signal monitoring in parallel; after the reset signal is monitored, cleaning an unsent excitation sequence between the sequencer and the driver in a stage ending callback function of the main operation stage in the verification environment; and then triggering stage jump, so that all verification environment components including the test component are synchronously switched to a pre-reset stage. After it is confirmed that the tested device is stabilized to be in the idle state in the pre-reset stage, the internal counter and the state variable of the unified verification environment are reset, and the method returns to the main operation stage to restart the service process. According to the scheme, the problem of handshake synchronization failure of the sequencer and the driver during resetting in the business process can be avoided, the continuity and reliability of resetting processing in the business process are improved, code change of environment components is reduced, and the workload is effectively reduced.

Description

Technical Field

[0001] This disclosure relates to the field of digital chip verification technology, and more specifically, to a reset verification method, apparatus, device, and medium in a business process. Background Technology

[0002] In the field of digital chip verification, ensuring the functional correctness of the reset circuit is one of the key aspects of verification delivery. The reset circuit enables the chip to recover to a known, deterministic state after power-on or in an abnormal state. Its verification must not only cover simple power-on reset scenarios but also handle complex situations where the chip experiences sudden resets during operation, i.e., during business processing—often referred to as "in-process resets." Insufficient verification of such resets can easily lead to problems such as state machine lock-up, data loss, or functional abnormalities in practical applications. The Universal Verification Methodology (UVM), as a widely adopted verification framework, provides convenience for building reusable verification environments with its class-based hierarchical structure; however, it still faces significant challenges when handling the dynamic behavior of in-process resets.

[0003] Currently, the reset verification solution based on UVM in business processes requires modification of multiple components such as drivers, monitors, and test cases. However, this approach results in a large scope of modification to the verification environment and is highly invasive. Each component needs to add reset monitoring and processing logic, which not only increases code complexity and maintenance costs but also introduces risks in the collaboration between components. In particular, the stimulus sequence interaction between the sequencer and the driver is prone to inconsistencies in handshake and data synchronization when a reset event suddenly intervenes, often leaving incomplete sequences or causing state machine conflicts. This affects the accuracy and reliability of the environment recovery after the reset, thus restricting the completeness and efficiency of reset verification.

[0004] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The purpose of this disclosure is to provide a reset verification method, a reset verification device, an electronic device, and a computer-readable storage medium in a business process, thereby avoiding the problem of handshake synchronization failure between the sequencer and the driver during a reset in a business process, improving the continuity and reliability of the reset process, reducing code modifications to environmental components, and effectively reducing workload.

[0006] Other features and advantages of this disclosure will become apparent from the following detailed description, or may be learned in part from practice of this disclosure.

[0007] According to a first aspect of the present disclosure, a reset verification method for a business process is provided, applied to a unified verification environment, the unified verification environment including a verification environment component, the verification environment component including at least a test component, a sequencer, and a driver, the method comprising: The test component performs normal business processes and monitors reset signals in parallel, the reset signals being monitored by the test component during the main operation phase. In response to the detection of the reset signal, a sequence cleanup operation is performed. The sequence cleanup operation is performed in the phase end callback function of the main running phase. The sequence cleanup operation is used to stop the unsent stimulus sequence between the sequencer and the driver. A stage jump instruction is triggered, which is used to cause all verification environment components, including the test component, in the unified verification environment to jump synchronously from the main running stage to the pre-reset stage, and the verification environment components perform a reset operation in the pre-reset stage. In response to confirming the completion of the reset operation, control all verification environment components to restart a new normal business process.

[0008] In some example embodiments of this disclosure, based on the foregoing scheme, the step of performing a sequence cleanup operation in response to detecting the reset signal includes: A stop command is sent to the sequencer, the stop command being used to interrupt the transmission of untransmitted stimulus sequences in the sequencer and discard the untransmitted stimulus sequences; Receive a handshake confirmation signal from the driver, the handshake confirmation signal being used to confirm that all ongoing excitation sequences have been completed; Based on the handshake confirmation signal, the sequence status register is updated to mark the completion of the cleanup of the unsent stimulus sequence.

[0009] In some example embodiments of this disclosure, based on the foregoing scheme, the triggering phase jump instruction includes: The level of the reset signal is monitored, and the level of the reset signal is monitored during the main operation phase of the test component; When the level state of the reset signal is detected to switch from an invalid state to an valid state and this switch continues for more than a preset clock cycle, a stage jump instruction is generated. The phase jump instruction is passed to the phase scheduler of the unified verification environment so that the phase scheduler initiates synchronous phase jumps for all verification environment components.

[0010] In some example embodiments of this disclosure, based on the foregoing scheme, the step of transmitting the phase jump instruction to the phase scheduler of the unified verification environment, so that the phase scheduler initiates synchronous phase jumps for all verification environment components, includes: Send the stage jump instruction to the stage scheduler, wherein the stage jump instruction specifies the pre-reset stage as the jump target; The phase jump instruction is broadcast by the phase scheduler to all verification environment components, including the test component. Upon receiving the stage jump instruction, all verification environment components pause their current normal business processes and perform local state saving until all verification environment components confirm that they are ready to be reset, at which point they synchronously enter the pre-reset stage.

[0011] In some example embodiments of this disclosure, based on the foregoing scheme, the parallel monitoring of the reset signal includes: A reset monitoring thread is created and executed in parallel with the normal business process. The reset monitoring thread is created by the test component during the main running phase. The reset monitoring thread periodically reads the level value of the reset signal; When the level value of the reset signal indicates that a reset event has occurred, the event flag register is updated and the stage controller of the test component is triggered.

[0012] In some example embodiments of this disclosure, based on the foregoing scheme, the step of performing a sequence cleanup operation in response to detecting the reset signal includes: Bind the phase end callback function to the phase end event; When the phase end event is detected to be triggered, the phase end callback function is invoked to access the interface between the sequencer and the driver; The sequence cleanup operation on the sequencer and the driver is performed through the interface, and the internal state machine of the sequencer is reset.

[0013] In some example embodiments of this disclosure, based on the foregoing scheme, the unified verification environment includes the device under test, and the verification environment components further include a monitor; The reset operation performed during the pre-reset phase includes: Apply a reset pulse signal to the device under test and wait for the device under test to stabilize to an idle state; The monitor is used to acquire the output response of the device under test, and the reset behavior of the device under test is verified based on the output response to see if it meets expectations. In response to determining that the reset action was accurately completed, the internal counters and state variables of the unified verification environment are reset.

[0014] According to a second aspect of the present disclosure, a reset verification apparatus for a business process is provided, applied to a unified verification environment, the unified verification environment including a verification environment component, the verification environment component including at least a test component, a sequencer, and a driver, the apparatus comprising: The reset signal monitoring module is used to perform normal business processes and monitor reset signals in parallel. The reset signals are monitored by the test component during the main operation phase. A sequence cleanup module is used to perform a sequence cleanup operation in response to the detection of the reset signal. The sequence cleanup operation is performed in the phase end callback function of the main running phase. The sequence cleanup operation is used to stop the unsent stimulus sequence between the sequencer and the driver. The reset synchronization jump module is used to trigger a stage jump instruction, which is used to cause all verification environment components, including the test component, in the unified verification environment to synchronously jump from the main running stage to the pre-reset stage, and the verification environment components perform a reset operation in the pre-reset stage. The business process reset module is used to control all the verification environment components to restart a new normal business process in response to the determination that the reset operation has been completed.

[0015] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a processor; and a memory storing computer-readable instructions, which, when executed by the processor, implement the reset verification method in the business process of the first aspect.

[0016] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided, on which a computer program is stored, wherein when the computer program is executed by a processor, it implements the reset verification method in the business process of the first aspect.

[0017] The technical solutions provided in this disclosure may have the following beneficial effects: The reset verification method in the business process of the example embodiments of this disclosure, on the one hand, by simultaneously executing the normal business process and reset signal monitoring during the main running phase of the test component, enables the reset event to be identified in a timely manner during business processing, eliminating the need to add detection logic to multiple components such as drivers and monitors separately, thereby reducing the scope of changes to the verification environment and mitigating the risks of timing dispersion and state inconsistency caused by parallel monitoring of multiple components; on the other hand, after a reset event is detected, the control flow enters the main running phase, and uses the phase end callback function to centrally clean up the incomplete stimulus sequence between the sequencer and the driver, so that sequence interruption and state convergence are accurately handled before the phase switch, from This avoids issues such as handshake residue, data mismatch, and state machine conflicts that can easily occur during sudden reset events. Furthermore, by triggering a phase jump during the main operation phase, other components in the unified verification environment can enter the pre-reset phase with a consistent time base, thereby reducing inconsistencies caused by independent switching of components in traditional solutions and improving the overall coordination of the reset process. On the other hand, after the reset is completed in the pre-reset phase, the verification environment components automatically re-enter the main operation phase, allowing the business process to resume execution under unified initialization conditions. This avoids business interruptions or state shifts caused by inconsistent component recovery rhythms after reset, improving the responsiveness and stability of the reset process.

[0018] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0020] Figure 1 The illustration shows a schematic flowchart of a reset verification method in a business process according to some embodiments of the present disclosure.

[0021] Figure 2 The schematic diagram illustrates a sequence cleanup operation for stopping a sequencer and a driver according to some embodiments of the present disclosure.

[0022] Figure 3 The illustration shows a flowchart of the implementation of the synchronization phase jump of the verification environment component according to some embodiments of the present disclosure.

[0023] Figure 4The schematic diagram illustrates a flowchart of implementing a sequence cleanup operation according to some embodiments of the present disclosure.

[0024] Figure 5 The diagram illustrates a sequence of stages in a unified verification environment according to some embodiments of the present disclosure.

[0025] Figure 6 The illustration shows a sequence of stages for resetting during the implementation of services according to some embodiments of the present disclosure.

[0026] Figure 7 The illustration shows a schematic diagram of the composition of a reset verification device in a business process according to some embodiments of the present disclosure.

[0027] Figure 8 The schematic diagram illustrates the structural schematic of a computer system of an electronic device according to some embodiments of the present disclosure.

[0028] Figure 9 A schematic diagram of a computer-readable storage medium according to some embodiments of the present disclosure is shown.

[0029] In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts. Detailed Implementation

[0030] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this specification as detailed in the appended claims.

[0031] The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of this specification. The singular forms “a,” “the,” and “the” as used in this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0032] It should be understood that although the terms first, second, third, etc., may be used in this specification to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this specification, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0033] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be more thorough and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art.

[0034] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this disclosure. However, those skilled in the art will recognize that the technical solutions of this disclosure can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this disclosure.

[0035] Furthermore, the accompanying drawings are for illustrative purposes only and are not necessarily drawn to scale. The block diagrams shown in the drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0036] In this embodiment of the disclosure, a reset verification method for a business process is first provided. This reset verification method for a business process can be applied to electronic devices deployed with a unified verification environment. The unified verification environment refers to a complete simulation environment built based on the Universal Verification Methodology (UVM) for functional verification of the Device Under Test (DUT).

[0037] This unified verification environment may include at least one set of verification environment components for collaboratively performing operations such as stimulus generation, signal driving, response acquisition, and result checking under the same time base. For example, verification environment components may include at least a test component, a sequencer, and a driver. The test component is a top-level control unit used to organize and schedule the verification process, configuring business scenarios, managing stage states, and interacting with other verification environment components. The sequencer is a control unit used to manage the generation and distribution of stimulus sequences, generating stimulus transactions according to predetermined business logic and protocol timing, and sending the stimulus transactions to the driver in a controlled manner. The driver is a component used to convert the stimulus sequences from the sequencer into specific signal waveforms and apply them to the interface of the device under test, performing handshake, sampling, and driving according to protocol timing within the clock domain.

[0038] Figure 1 The illustration schematically depicts a reset verification method flow in a business process according to some embodiments of the present disclosure. (Reference) Figure 1 As shown, the reset verification method in this business process may include the following steps: Step S110: Execute the normal business process and monitor the reset signal in parallel. The reset signal is monitored by the test component during the main operation phase. Step S120: In response to detecting the reset signal, a sequence cleanup operation is performed. The sequence cleanup operation is performed in the phase end callback function of the main running phase. The sequence cleanup operation is used to stop the unsent stimulus sequence between the sequencer and the driver. Step S130: Trigger a stage jump instruction. The stage jump instruction is used to cause all verification environment components, including the test component, in the unified verification environment to jump synchronously from the main running stage to the pre-reset stage, and the verification environment components perform a reset operation in the pre-reset stage. Step S140: In response to confirming the completion of the reset operation, control all the verification environment components to restart the new normal business process.

[0039] According to the reset verification method in the business process of this example embodiment, on the one hand, by simultaneously executing the normal business process and reset signal monitoring during the main running phase of the test component, the reset event can be identified in a timely manner during business processing. This eliminates the need to add separate detection logic to multiple components such as drivers and monitors, thereby reducing the scope of changes to the verification environment and mitigating the risks of timing dispersion and state inconsistency caused by parallel monitoring of multiple components. On the other hand, after a reset event is detected, the control flow enters the main running phase, and the phase end callback function centrally cleans up any unfinished stimulus sequences between the sequencer and the driver, ensuring that sequence interruptions and state convergence are accurately handled before phase switching. This approach avoids issues such as handshake remnants, data mismatches, and state machine conflicts that can easily arise during sudden reset events. Furthermore, by triggering a phase jump during the main operation phase, other components in the unified verification environment can enter the pre-reset phase with a consistent time base, thereby reducing inconsistencies caused by independent switching of components in traditional solutions and improving the overall coordination of the reset process. Additionally, after the reset is completed in the pre-reset phase, the verification environment components automatically re-enter the main operation phase, allowing business processes to resume execution under unified initialization conditions. This avoids business interruptions or state shifts caused by inconsistent component recovery rhythms after reset, improving the responsiveness and stability of the reset process.

[0040] The reset verification method in the business process of this example embodiment will be further explained below.

[0041] In step S110, the normal business process is executed and the reset signal is monitored in parallel. The reset signal is monitored by the test component during the main operation phase.

[0042] In an example embodiment of this disclosure, the main running phase may correspond to the sub-phase in the running phase of UVM used to execute normal business incentives. At the beginning of the main running phase, the test component can trigger the sequencer to load and run at least one incentive sequence for business verification by calling a preset startup function, and at the same time trigger the driver to enter the working state, so that the driver receives incentive transactions from the sequencer and drives the interface signals of the design under test.

[0043] The test component can create one or more reset monitoring tasks within the main runtime phase. For example, reset monitoring tasks can be implemented using threads, processes, coroutines, or event callbacks to periodically or event-triggeredly acquire the level state of the reset signal during simulation time. For instance, the reset signal register or port value is read at the rising edge of the clock and compared with a preset valid level to determine if a reset event exists. In another optional implementation, reset monitoring can also be implemented by registering a reset signal change callback in the test component. That is, when the reset signal switches from an invalid state to a valid state, a callback function is triggered to mark the event to an internal flag or write it to an event register.

[0044] In this way, normal business processes and reset monitoring logic can run in parallel during the same main operation phase. This ensures that business incentives continuously apply pressure to the device under test, and that reset events can be captured in a timely manner when reset conditions are met. Thus, without changing the internal structure of the driver, sequencer, and other components, the test component can centrally assume the responsibility of sensing and reporting reset signals, providing a unified entry point for subsequent phase switching and reset processing.

[0045] In step S120, in response to the detection of the reset signal, a sequence cleanup operation is performed. The sequence cleanup operation is performed in the phase end callback function of the main running phase. The sequence cleanup operation is used to stop the unsent stimulus sequence between the sequencer and the driver.

[0046] In one example embodiment of this disclosure, performing sequence cleanup operations in the phase-end callback function of the main running phase refers to calling a pre-registered callback function to access the control interfaces of the sequencer and driver before the phase ends but before entering the next phase, in order to stop and clean up any incomplete stimulus sequences. In one example embodiment, the test component can register a phase-end callback function identifier with the phase management module during the initialization of the main running phase. After all regular tasks in the main running phase have been completed, the phase management module calls the phase-end callback function before the phase ends.

[0047] In the phase-end callback function, the test component first sends a stop command to the sequencer through the sequencer's control interface to prevent the sequencer from generating new stimulus sequences. It then iterates through the currently pending stimulus sequence queue, terminating stimulus transactions marked as "pending" but not yet having established a handshake with the driver. In another embodiment, the test component can also query the identifiers of stimulus transactions being processed internally by the driver through the driver's service interface, compare these transactions with the transaction queue on the sequencer side, and confirm and stop stimulus transactions that have entered the driver but have not yet been fully executed, preventing the continued transmission of service signals to the design under test after a reset.

[0048] In optional implementations, the sequence cleanup operation may further include resetting or resetting the sequence status register, statistical counter, and internal state machine, ensuring that the sequencer and driver have converged at the stimulus management level before entering subsequent stages. By placing the sequence cleanup operation within the stage end callback function of the main running stage, placing it at the boundary between the end of the main running stage's business processing and the start of the reset-related stage, a clear time boundary can be formed, ensuring that all stimulus sequences have been terminated and cleaned up before entering the reset process. This avoids sequence remnants or state machine conflicts caused by inconsistencies between the reset insertion timing and the stimulus execution progress.

[0049] In step S130, a stage jump instruction is triggered. The stage jump instruction is used to cause all verification environment components, including the test component, in the unified verification environment to jump synchronously from the main running stage to the pre-reset stage, and the verification environment components perform a reset operation in the pre-reset stage.

[0050] In one example embodiment of this disclosure, the pre-reset phase can be understood as a preparation phase before executing a specific reset action. During this phase, the verification environment component can complete local state saving, transaction termination confirmation, and pre-configuration related to the reset. For example, in one example implementation, after the test component completes the execution of the phase end callback function in the main running phase, it can call a phase jump function through the phase scheduling interface to request a switch from the main running phase to the pre-reset phase. This phase jump can be executed by a unified phase management module, which iterates through each registered verification environment component and updates its current phase pointer to the phase object corresponding to the pre-reset phase, so that each verification environment component can enter the pre-reset phase in the next simulation time slice to execute its respective pre-reset task.

[0051] In an alternative implementation, for other verification environment components besides the test components, such as agents, monitors, or inspection modules in the environment components, a phase awareness function connected to the phase management module can be implemented internally. After receiving an indication that the phase has jumped to the pre-reset phase, the current normal business process is paused, such as stopping the driving of new business transactions, stopping the collection of business data, or stopping the execution of comparison operations, and the current running state is saved to a local state variable or state register to provide a basis for subsequent reset execution and the recovery process after reset.

[0052] By triggering a unified phase transition during the main runtime phase, instead of each component determining when to enter the reset-related phase, it can be ensured that all components enter the pre-reset phase at a unified pace, avoiding inconsistencies in phase switching timing caused by independent judgments within components, and reducing the probability of handshake synchronization failure between the sequencer and driver when a reset occurs during business operations.

[0053] In step S140, in response to determining that the reset operation is complete, control all the verification environment components to restart a new normal business process.

[0054] In one example embodiment of this disclosure, the pre-reset phase may include applying and releasing a reset signal, detecting the device under test (DUT) entering an idle state, and resetting internal counters and flags in the verification environment. Once these operations meet pre-defined completion conditions, the test component can update the current phase from the pre-reset phase to the main running phase by calling the phase jump interface. Upon receiving the phase jump instruction, the phase management module will set the current phase of each verification environment component to the main running phase at a unified time point, so that each component re-enters the main running phase at the next simulation time. During this process, the test component can reconfigure the sequencer to load the service stimulus sequence at the start of the main running phase and instruct the driver to resume driving the service signals to the DUT. Monitors and other verification environment components can also resume acquiring and processing the DUT's responses during the main running phase. In another optional implementation, the action of entering the main running phase after the pre-reset phase can also be bound to the reset completion condition. That is, the phase jump is performed only after the internal state of the DUT has stabilized to the expected idle state, to avoid prematurely starting the service process before the DUT has been fully reset. By automatically returning to the main running phase after completing the reset operation in the pre-reset phase, the entire verification environment can restart business processing with a unified initial state. This ensures that the stimulus sequence and state before the reset have been cleared, and that the business process after the reset restarts from a consistent starting point, thereby improving the stability of reset verification during business processes.

[0055] The contents of steps S110 to S140 will be described in detail below.

[0056] In one example embodiment of this disclosure, it can be achieved through Figure 2 The steps outlined in the code implement sequence cleanup operations within the phase-end callback function of the main runtime phase. (Refer to...) Figure 2 As shown, it can specifically include: Step S210: Send a stop command to the sequencer. The stop command is used to interrupt the transmission of untransmitted stimulus sequences in the sequencer and discard the untransmitted stimulus sequences. Step S220: Receive a handshake confirmation signal from the driver, the handshake confirmation signal being used to confirm that all ongoing excitation sequences have been completed; Step S230: Based on the handshake confirmation signal, update the sequence status register to mark the completion of the cleanup of the unsent stimulus sequence.

[0057] The test component can call the sequencer's control interface to write predefined stop commands into the sequencer's internal control interface or stop flag register, causing the sequencer to stop generating stimulus sequences. The sequencer manages the generation, queuing, and scheduling of stimulus sequences, and internally includes a stimulus transaction queue, a transaction status register, and state machine logic for driver handshakes. After a reset is detected, sending a stop command to the sequencer freezes the stimulus generation process, keeping stimulus transactions not yet sent to the driver in a controlled termination state, preventing new transactions from being generated and written to the transaction queue during subsequent stage transitions.

[0058] Stop commands can be implemented using asynchronous event triggering. The test component sends a stop notification to the sequencer via an event object. Upon receiving the event at the next timing point, the sequencer sets a stop flag in its internal state machine and switches to a waiting state within a single state update. Alternatively, stop commands can be encapsulated as custom transaction objects and broadcast through the sequencer's analysis port, causing the sequencer to execute the same stop logic upon receiving the transaction.

[0059] After the sequencer stops sending the unsent stimulus sequence, the test component can receive the handshake confirmation signal returned by the driver through the handshake confirmation port or internal event monitoring interface provided by the driver. The driver can be used to convert stimulus transactions into timing signals conforming to the bus protocol, and internally includes an input buffer, a protocol handshake module, and a driver output module. After the stimulus sequence is interrupted, the driver may still be executing the handshake process of the last stimulus transaction, so it is necessary to wait for the protocol state machine on the driver side to safely exit the handshake phase before proceeding with subsequent state updates.

[0060] The handshake confirmation signal can be sent by the driver to the test component after the last clock cycle of the transaction drive is completed, via event triggering, status bit writing, or callback function postback, allowing the test component to clearly understand that the driver has entered an idle state. Alternatively, the test component can periodically read the driver's status register; when the status register indicates an idle state or protocol completion state, this state is considered an equivalent form of the handshake confirmation signal. The driver can also return an acknowledgment flag to the test component via a blocking task in UVM, providing a clear synchronization point for the handshake confirmation process. Receiving the handshake confirmation signal ensures that the driver's internal stimulus execution is no longer in an intermediate state, ensuring consistent boundary conditions for the sequence cleanup operation between the driver and the sequencer, and avoiding state machine or sequence remnants caused by incomplete handshakes.

[0061] After confirming that the driver has completed stimulus processing, the test component can access the sequence status register inside the sequencer and update the status flags associated with the stimulus sequence. The sequence status register records the current stimulus generation status of the sequencer, including the stimulus queue pointer, the number of pending transactions, the current state of the state machine, and synchronization flags coordinated with the driver. During the reset procedure, these status flags can be updated to "cleanup complete" or "termination status" to ensure that the sequencer does not mistakenly believe there are still stimulus transactions to be executed in the next phase.

[0062] Updating the sequence status register can include clearing the stimulus queue, resetting the queue pointer to zero, resetting the state machine to its initial state, and writing cleanup flags to specific control registers. For example, the update command can selectively clear only partially incomplete transactions based on the flags attached to the handshake confirmation signal. For instance, when the driver confirms that only part of the sequence has been executed, only the undriven stimulus portion can be cleared by comparing the transaction flags in the sequence status register. The sequence status register can also be managed using a lookup table or a state mapping table, allowing the cleanup operation to be implemented through a single mapping function, converting all state flags to the terminated state. By updating the sequence status register, the internal logic structure of the sequencer can be kept in a consistent and clean state, providing a stable and deterministic initialization basis for subsequent stage transitions into the pre-reset phase. This ensures that the entire reset process is unaffected by residual transactions from before the reset, thereby guaranteeing that the verification environment can restart its business processes in a consistent state after the reset.

[0063] By sending a stop command to the sequencer in the phase-end callback function of the main running phase, and cooperating with receiving the handshake confirmation signal from the driver and updating the sequence status register accordingly, the sending and execution of unsent stimuli on the sequencer side, the execution of stimuli on the driver side, and the handshake status between the two can obtain a unified and complete termination mark after the reset is triggered. This enables centralized cleanup and state convergence of the unsent stimuli sequence before entering the reset-related phase, avoiding the situation where residual transactions are mistakenly continued to be executed after the reset or the sequencer and driver states are out of sync. This improves the consistency of the stimulus link and the predictability of reset recovery in the reset scenario during the business process.

[0064] In one example embodiment of this disclosure, it can be achieved through Figure 3 The steps described above enable the triggering of a phase jump during the main runtime phase, causing all verification environment components, including the aforementioned test components, to synchronously jump to the pre-reset phase within the unified verification environment. (Refer to...) Figure 3 As shown, it can specifically include: Step S310: Monitor the level of the reset signal, which is monitored during the main operation phase of the test component; Step S320: When the level state of the reset signal is detected to switch from an invalid state to an effective state and this switch continues for more than a preset clock cycle, a stage jump instruction is generated. Step S330: The stage jump instruction is passed to the stage scheduler of the unified verification environment so that the stage scheduler initiates synchronous stage jumps for all verification environment components.

[0065] Specifically, the level of the reset signal can be monitored during the main operation phase of the test component. After the unified verification environment switches to the main operation phase, the test component can continuously monitor the level changes of the reset signal line or reset register used to indicate reset events within the main operation phase.

[0066] The reset signal can be the top-level signal corresponding to the on-chip reset port, or it can be a reset indicator variable abstracted from the verification environment. Its level state can be defined by high level active, low level active, or pulse active, etc. Of course, other trigger electrical signals can also be used for indication. This embodiment does not make any special limitations on this.

[0067] The test component can create a monitoring task during the main operation phase. This task periodically samples the level of the reset signal at the clock edge throughout the entire duration of the main operation phase and writes the sampling results to a local state variable to determine whether a transition from an invalid state to a valid state exists. Alternatively, the monitoring task can be implemented using an event-driven approach. This means that the simulation kernel is sensitive to changes in the reset signal's registered value. When any level flip of the reset signal occurs, a callback function is immediately triggered, and the current level state is read within the callback function to improve the real-time response to reset events. To avoid interference from accidental glitches, level jitter, or brief invalid triggers on phase transitions, the test component can also incorporate filtering strategies or stability judgment logic when monitoring the reset signal level state. For example, it can take multiple values ​​for the level in multiple consecutive sampling periods, or introduce a confirmation delay window after detecting a level change. Only if the level remains unchanged at the end of the delay window is the level state considered to have truly transitioned.

[0068] The preset clock period can be set according to the timing characteristics of the design under test, the sampling window of the reset circuit, and the simulation frequency. For example, it can be several system clock cycles, several reset clock cycles, or the number of simulation steps defined in a unified verification environment. This embodiment does not impose any special limitations on this. In one embodiment, the test component can start a counter at the first clock edge after detecting the reset signal transitioning from an invalid level to an valid level, and increment the counter at subsequent clock edges. When the count value is greater than or equal to a preset threshold, the current state is marked as "reset stable and valid," and a stage jump instruction is generated. If the reset signal is detected to return to an invalid level during the counting process, the counter is immediately cleared and the generation of this stage jump instruction is abandoned to ensure that only stable reset signals are responded to. In another embodiment, the preset clock period can be adjusted by the verification engineer according to the specific project needs through parameter configuration. The test component reads the threshold from the configuration file or environment variables during runtime, thereby reusing the same monitoring framework under different designs and different reset timings.

[0069] Stage jump instructions can be encapsulated as a type of stage control transaction object, which includes at least an identifier field indicating the target stage, a reset flag field indicating the triggering reason, and a timestamp field indicating the triggering time. This allows for unified management and scheduling of stage jump instructions from different sources by a unified verification environment. By generating stage jump instructions only after the reset signal has stabilized and become valid, false triggers caused by brief interference, spurious pulses, or abnormal jitter can be avoided. This ensures that stage jump behavior is based on time-verified reset events, thereby improving the reliability and determinism of stage control in the verification process.

[0070] The stage scheduler can be understood as the core module for stage management in a unified verification environment. It maintains the current global stage information, the mapping relationship between each verification environment component and the stage, and the stage switching rules to ensure that the stage progress of each component is consistent on the timeline.

[0071] The test component can call the phase jump interface function provided by the phase scheduler and pass in the phase jump instruction containing the reset trigger information and the target pre-reset phase identifier as parameters. After receiving the request, the phase scheduler first records the relationship between the current global phase and the target phase, and broadcasts the phase switching instruction to all registered verification environment components according to the established strategy.

[0072] The stage scheduler can maintain an independent stage control handle for each verification environment component. When a stage jump instruction is received, it updates the stage handle of each component sequentially, setting its current stage to the stage object corresponding to the pre-reset stage. This drives each component to enter the pre-reset stage in the next simulation time slice to perform local preparation operations related to reset. In an optional implementation, the stage scheduler can also support atomic control of stage jumps, meaning that global stage switching only takes effect simultaneously after confirming that all verification environment components have received and accepted the jump instruction. This avoids stage misalignment where some components remain in the main running stage while others have already entered the pre-reset stage. Furthermore, the stage scheduler can record the source and triggering conditions of each stage jump instruction for tracking and analysis during subsequent debugging or regression verification.

[0073] By continuously monitoring the level of the reset signal during the main operation phase of the test component, and only generating a phase jump instruction and submitting it to the phase scheduler when the reset signal is detected to switch from invalid to valid and lasts for more than a preset clock cycle, the triggering of phase jumps can be based on the objective condition that the reset signal is stable and valid. This allows for the full filtering of glitches and transient jitters during phase switching decisions, avoiding false jumps caused by brief abnormal levels or phase oscillations caused by frequent jitters. This improves the stability of phase control and the reliability of phase switching decisions in the unified verification environment during business reset scenarios.

[0074] In one example embodiment of this disclosure, the stage jump instruction can be transmitted to the stage scheduler of the unified verification environment through the following steps to initiate synchronous stage jumps for all verification environment components, specifically including: During the main running phase of the test component, a phase jump instruction can be sent to the phase scheduler, specifying the pre-reset phase as the jump target. The phase scheduler broadcasts the jump instruction to all verification environment components, including the test component. Upon receiving the jump instruction, all verification environment components, including the test component, suspend their current normal business processes and perform local state saving until all verification environment components confirm that the reset is ready, and then synchronously enter the pre-reset phase.

[0075] The test component can maintain a set of context information related to stage control during the main runtime phase. This context information may include the current runtime phase identifier, the target jump phase identifier, the reset event trigger flag, and the unique number of the stage jump instruction. When the test component detects that the reset signal meets the stable and valid conditions and has completed the required sequence cleanup operations during the main runtime phase, it can generate a stage jump instruction. This stage jump instruction can specify the pre-reset phase as the jump target. This specification can be achieved by writing the target phase's enumeration value, phase handle, or phase name string. After receiving the stage jump instruction, the stage scheduler can determine the next stage as the pre-reset phase based on the target identifier.

[0076] In practical implementation, stage jump instructions can be sent to the stage scheduler via function calls. For example, the test component can call the extended stage jump API (Application Programming Interface) in the Unified Verification Methodology (UVM) framework, passing the stage object representing the pre-reset stage as an input parameter. Alternatively, a transactional call can be used, where the test component sends a control transaction containing jump information through a dedicated analysis port, and the stage scheduler parses the transaction at the receiving port to receive the stage jump instruction. In optional implementations, the test component can also append extended fields such as trigger timestamp, reset reason code, and current main running stage end status to the stage jump instruction, providing the stage scheduler with more complete contextual information when subsequently processing stage jumps and recording reset events.

[0077] The stage scheduler can maintain a component list, which records the identification information of each verification environment component in the unified verification environment, its current stage, and its communication interface with the stage scheduler. When the stage scheduler parses the stage jump instruction and confirms that the target stage is the pre-reset stage, it can use a broadcast mechanism to send the jump instruction to each verification environment component registered in the list.

[0078] Broadcasting can be implemented via function callbacks, where the stage scheduler iterates through the callback handles of each verification environment component, sequentially calling their stage change interfaces and carrying a pre-reset stage identifier within the interface; or via event notifications, where the stage scheduler publishes a stage jump event on a global stage event bus, and each verification environment component listens for this event in its respective monitoring task and updates its current stage accordingly. This embodiment does not impose any special limitations on this approach. In an optional implementation, considering that some components may be temporarily in uninterruptible critical code segments, the stage scheduler can also first send a stage jump pre-announcement instruction to all verification environment components, and then uniformly issue the formal jump instruction after all components return ready confirmation, to ensure the atomicity of stage switching.

[0079] Normal business processes can include operations specific to the device under test (DUT), such as stimulus sending, response acquisition, protocol checking, and coverage statistics. Pausing normal business processes can be achieved by setting internal running flags, stopping new transactions, ceasing stimulus fetching, or temporarily suspending statistical count updates. During local state saving, each verification environment component can save current key variables according to its own responsibilities. For example, a driver can save the identifier of the most recent driven but not yet fully confirmed transaction, a monitor can save the position of the most recent sampling window, and a comparator can save the reference index of the most recent comparison. This state information can be written to local registers, configuration objects, or persistent logs.

[0080] Upon receiving a jump instruction from the stage scheduler, each verification environment component does not immediately terminate all ongoing operations. Instead, it safely pauses its current normal business process according to a predetermined shutdown strategy. Before or during the pause, it locally saves important business-related states so that after the reset process, it can determine whether to restore, rebuild, or discard the corresponding business context based on this state information. After completing the local state saving, each verification environment component can also return a reset-ready confirmation signal to the stage scheduler or test component. This confirmation signal can be a Boolean flag, status code, or callback completion event, indicating that the component has completed the pause and state saving and can enter the pre-reset phase. In an optional implementation, the stage scheduler can internally maintain a ready state table to record whether each verification environment component has returned a reset-ready confirmation. Only when all verification environment components are marked as ready will the stage scheduler uniformly switch the global stage to the pre-reset phase, thereby enabling all verification environment components to synchronously enter the pre-reset phase.

[0081] By sending a stage jump instruction explicitly specifying the pre-reset stage as the jump target to the stage scheduler during the main operation phase of the test component, and having the stage scheduler broadcast the corresponding jump instruction to all verification environment components except the test component, these verification environment components, upon receiving the jump instruction, first suspend their current normal business processes and perform local state saving. Then, after all components confirm that the reset is ready, they synchronously enter the pre-reset stage. This allows the stage scheduler to coordinate the stage advancement of each component under the conditions of unified entry, unified target, and unified effectiveness. Thus, during the reset preparation process, it takes into account the orderly convergence of business context and the time consistency of stage switching between components, avoiding the phenomenon that some components are still executing old business or that the stage is advanced / delayed, thereby improving the overall coordination and controllability of the reset process.

[0082] In one example embodiment of this disclosure, parallel monitoring of the reset signal during the main runtime phase of the test component can be achieved through the following steps, specifically including: A reset monitoring thread can be created during the main runtime phase of the test component and executed in parallel with the normal business process. The reset monitoring thread periodically reads the level value of the reset signal. When the level value of the reset signal indicates that a reset event has occurred, the event flag register is updated and the phase controller of the test component is triggered.

[0083] The reset monitoring thread can be created using a task, process, lightweight thread, or objection derivation mechanism in the unified verification methodology. Its execution cycle can be scheduled based on the system clock, reference clock, or simulation step size, etc. This embodiment is not limited to this.

[0084] The testing component can start a reset monitoring thread in a branch at the beginning of the main execution phase, and continue to schedule the business incentive sequence in the main branch, thereby achieving non-blocking between reset detection and business execution. The reset monitoring thread can also be implemented in an event-driven manner, that is, monitoring the value change event of the reset signal pin or reset register, and immediately executing the internal judgment logic of the thread when the event is triggered, so as to improve the timeliness of response to sudden reset behavior.

[0085] Reading the reset signal level involves setting up a loop structure within the reset monitoring thread. In each loop cycle, the current level of the reset signal is read and compared with an invalid or valid state to determine if a level change has occurred. The reset signal can be a hardware reset port within the design under test (DUT) or a reset control variable abstracted from the verification environment. Its level can be binary or quaternary logic. The monitoring thread can synchronize with the simulation time and clock changes when reading the level. In one implementation, the monitoring thread can read the reset signal at each rising edge of the system clock, store the read value in a local register variable, and perform a differential comparison with the recorded value from the previous cycle. When a transition from invalid to valid is detected, it is determined that a reset event has occurred. In another implementation, the monitoring thread can employ a multi-sampling strategy, such as continuously sampling the reset signal several times within a clock cycle and taking the majority decision result to filter out glitches. Furthermore, in scenarios where the reset signal may be pulse-triggered, the monitoring thread can also set a minimum width detection mechanism, i.e., the reset signal is considered valid only if it remains valid for a certain time threshold, to avoid erroneous judgments caused by brief disturbances.

[0086] When the level value of the reset signal indicates that a reset event has occurred, the event flag register is updated and the stage controller of the test component is triggered. Specifically, when the reset monitoring thread confirms during the periodic sampling process that the reset signal has switched from an invalid state to an effective state and meets the predetermined stability requirements, it immediately writes the relevant information of the reset event into the event flag register to record the occurrence of the reset event.

[0087] The event flag register can be an internal storage structure within the test component used to record critical events. Its value can include a single-bit reset flag, a multi-bit event code, or a reset trigger timestamp, among other information. After confirming that the event flag register has been written, the reset monitoring thread can call the phase control logic within the test component, triggering the phase controller to switch the unified verification environment to the main running phase.

[0088] The stage controller can automatically jump to the main running stage after the previous main running stage has been completed by setting a stage transition flag. For example, the stage controller can immediately trigger a stage switch, so that the callback logic of the main running stage takes effect in the next simulation cycle. In an optional implementation, the event flag register can also be bound to the stage controller, so that when the register state changes, the stage controller automatically reads the reset event information in the register and selects the subsequent stage advancement path based on the information.

[0089] By creating a reset monitoring thread that runs in parallel with the normal business process during the main operation phase of the test component, and having this thread periodically read the level value of the reset signal, updating the event flag register and triggering the phase controller of the test component when a reset signal is detected indicating a reset event, the detection and reporting of reset events can be separated from the specific business sequence execution process, forming an independent and continuous monitoring path. This allows for timely and accurate perception of reset conditions and driving phase transitions even in high-concurrency or long-transaction scenarios, preventing reset signals from being overwhelmed by business logic or experiencing processing delays. This improves the real-time response of reset triggers during business processes and the timing accuracy of subsequent phase switching.

[0090] In one example embodiment of this disclosure, it can be achieved through Figure 4 The steps outlined in the code implement sequence cleanup operations within the phase-end callback function of the main runtime phase. (Refer to...) Figure 4 As shown, it can specifically include: Step S410: Bind the phase end callback function to the phase end event; Step S420: When the phase end event is detected to be triggered, the phase end callback function is called to access the interface between the sequencer and the driver; Step S430: Perform a sequence cleanup operation on the sequencer and the driver through the interface, and reset the internal state machine of the sequencer.

[0091] Callback handling functions are predefined by the test component to handle the logic of a specific phase ending. They may contain access logic to sequencers, drivers, or other verification environment components. Phase ending events are signals or function call points that are automatically triggered by the phase management module when all regular tasks in the current phase have been completed and the next phase is about to begin.

[0092] In practical implementation, the test component can insert pre-written phase end callback functions into the callback list corresponding to the main runtime phase using the `add_callback` function in the unified verification methodology framework or the extended phase callback API. When the execution flow of the main runtime phase reaches its end and the phase management module is preparing to switch phases, the phase management module will call all functions in the callback list in the registration order, ensuring that the phase end callback function has an execution opportunity before the phase switch. For example, the binding of phase end callback functions can be implemented through an event mechanism, whereby the test component registers a trigger condition sensitive to the phase end event in the main runtime phase, and automatically executes the bound callback function when the phase end event is triggered. In another optional implementation, to improve the flexibility of callback binding, the test component can also bind different callback functions to different phases through configuration objects or strategy patterns, so that when it is necessary to extend the phase end behavior, the binding logic can be adjusted without modifying the core phase control code.

[0093] When a phase end event is detected, the phase end callback function is invoked to access the interfaces of the sequencer and driver. This means that after all basic tasks in the main runtime phase have been completed, the phase management module triggers an internally defined phase end event, causing the test component to execute the pre-registered phase end callback function. Within this callback function, the test component can call the control or service interfaces provided by the sequencer and driver, access their internal states, and perform operations related to sequence cleanup.

[0094] The sequencer interface may include control methods for stopping stimulus generation, methods for clearing the stimulus queue, or methods for querying the sequence status; the driver interface may include functions related to stopping signal driving, querying handshake completion status, or terminating the current protocol driving. Optionally, the phase end callback function may first check through the sequencer interface whether there are still unprocessed stimulus transactions. If so, it executes cleanup one by one according to the termination method defined by the sequencer. Then, it checks through the driver interface whether the driver is still in the stimulus-driven state. If the driver is performing a handshake operation, it waits for it to complete before continuing to execute the subsequent cleanup logic. Of course, the phase end callback function can also adopt an asynchronous query strategy, polling the sequencer and driver status registers to complete the cleanup judgment without blocking the entire phase progression. To improve cleanup efficiency, the phase end callback function can access the interfaces of both the sequencer and the driver simultaneously, executing status query and cleanup logic in parallel. This embodiment does not impose any special limitations on this.

[0095] The sequence cleanup operation on the sequencer and driver can be performed through the interface, and the internal state machine of the sequencer can be reset. That is, after the current state of the sequencer and driver is obtained in the phase end callback function, the test component uses the interface functions or internal control registers provided by the sequencer and driver to perform cleanup operations on the internal data structures related to the stimulus sequence, so that the sequencer and driver no longer hold any unfinished transactions related to the main running phase business; at the same time, the state machine structure inside the sequencer used to manage stimulus generation and scheduling can also be restored to the initial state.

[0096] For example, sequence cleanup operations may include deleting or clearing the sequencer's internal stimulus transaction queue, resetting the sequence execution pointer to zero, resetting the scheduling register used to manage transaction priorities, and marking the sequencer state as idle or without stimulus. When performing cleanup operations on the driver, the currently output signal mode can be stopped via the driver interface, the protocol handshake state machine can be restored to the protocol idle state, and unprocessed stimulus transactions in the input buffer can be cleared to ensure that the driver does not continue to use old stimuli to drive the device under test in the next stage.

[0097] Resetting the sequencer's internal state machine can be achieved by writing initialization values ​​to the control register or by calling the sequencer's `reset_state_machine()` method, returning the sequencer's state machine to the initial state of the component's lifecycle. Optionally, the sequencer can also rebuild the internal scheduler during sequence cleanup, ensuring that erroneous stimuli are not triggered in the next phase due to residual old states. If the sequencer's internal state machine uses a finite automaton structure, the test component can jump to its initial state by calling the state machine transition interface, without having to backtrack through intermediate states.

[0098] By pre-registering callback handling functions during the main operation phase and binding the phase end callback function to the phase end event, the phase end callback function is automatically invoked when the phase end event is detected to access the interface of the sequencer and driver. Through the interface, sequence cleanup operations on the sequencer and driver and the reset of the internal state machine of the sequencer are performed. This ensures that the stimulus cleanup and state machine reset actions are precisely anchored at the unified boundary point of "end of main operation phase". This guarantees that the business stimulus completely stops and the sequence state converges uniformly before entering the reset-related phase. It avoids stimulus residue and state machine deviation caused by scattered or missed cleanup timing, improves the cleanliness of the stimulus link before reset, and ensures the environmental consistency when the business restarts after reset.

[0099] In one example embodiment of this disclosure, the unified verification environment includes the device under test, and the verification environment components also include a monitor; the reset operation can be completed during the pre-reset phase through the following steps, specifically including: During the pre-reset phase, a reset pulse signal can be applied to the device under test (DUT) and the DUT can be allowed to stabilize to an idle state. The output response of the DUT can be acquired through a monitor, and the reset behavior of the DUT can be verified based on the output response to see if it meets expectations. In response to confirming that the reset behavior has been accurately completed, the internal counters and state variables of the unified verification environment can be reset to prepare for re-entering the main operation phase.

[0100] In the pre-reset phase, a reset pulse signal is applied to the device under test (DUT) and the DUT is waited to stabilize to an idle state. That is, after the unified verification environment completes the phase jump triggered by the main operation phase and enters the pre-reset phase, the test component or reset control module outputs a reset pulse with specific timing characteristics to the DUT through the driver or directly through the reset control interface according to the predetermined reset strategy, so that the internal registers, state machine and buffer structure of the DUT are restored to the initial state defined by the design.

[0101] The reset pulse signal is a control signal defined by the device under test (DUT) to trigger reset behavior. It can be a valid high pulse, a valid low pulse, or a reset sequence held for multiple cycles. Its duration and level characteristics are usually determined by the hardware design specifications of the DUT, and are not specifically limited here. For example, the reset pulse can be generated by a driver, which drives the reset signal port according to a predetermined reset template for several consecutive clock cycles, keeping the reset signal valid. Alternatively, the test component can bypass the driver and directly write to the reset control register in the simulation environment, making the reset pulse take effect immediately with higher priority. After the reset pulse is applied, the DUT typically needs to go through several clock cycles to complete internal clearing, state initialization, and protocol module reset. Therefore, the pre-reset phase also includes waiting for the DUT to stabilize to an idle state.

[0102] The idle state can be determined by the idle indicator bit, ready signal, or status register in the output signal of the device under test (DUT). For example, the monitor can periodically read the status register of the DUT, and when it detects that the register content matches the expected idle mode value, it considers that the DUT has completed the reset; the DUT can provide a dedicated reset completion indicator signal, and the monitor can end the waiting after detecting that the signal is valid.

[0103] After the device under test (DUT) completes its internal processing of the reset pulse, a monitor can sample the DUT's output ports, status register mappings, or protocol signals during the pre-reset phase to determine whether its post-reset external behavior matches design requirements. The monitor can be used to extract the DUT's response signals during simulation and may include sampling logic, a timestamp recording unit, and a protocol analysis module. The monitor can sample the DUT's status register over multiple consecutive clock cycles after the reset pulse is released. When the status value matches the default reset value specified in the DUT's hardware design document, the register reset is confirmed to be normal. In another implementation, for DUTs supporting standard bus protocols (such as the Advanced eXtensible Interface (AXI)), the monitor can check after reset whether protocol handshake-related signals have entered an idle state, such as whether the VALID and READY signals in the AXI protocol are both in an invalid state, to determine if the bus interface has been successfully reset. Optionally, the monitor can also compare the acquired DUT output response with the reference output of the same design in the baseline reset process, verifying whether the reset behavior meets design constraints using a protocol checker, assertion module, or coverage tool. By collecting and analyzing the output response of the device under test, it can be confirmed from an external observation level that the reset behavior has been executed as expected, avoiding the risk of uncleared states or asynchronous logic residues remaining after the reset pulse is applied.

[0104] After the monitor confirms that the device under test has been stably idle and the output response meets the design specifications after reset, the test component or environment management module resets the internal counters and state variables used to record the simulation execution status, so that the unified verification environment is in a clean, historical load-free state before entering the next main operation phase.

[0105] Internal counters may include sequence counters, transaction counters, monitoring event counters, or protocol interaction counters, which are used to record stimulus and response data within the current business cycle; state variables may include stage flag variables, event flag variables, internal environment cache, protocol state record tables, etc., which reflect the running context of the unified verification environment.

[0106] In one example implementation, the test component can clear these counters by directly writing to the counter register, or by calling the initialization method provided by the unified verification environment to uniformly reset the counters and state machine. The environment management module can adopt a soft rebuild approach, that is, resetting the state variables by destroying and rebuilding some internal objects (such as verification agents and protocol analyzer instances), thereby ensuring that there is no residual information from the previous business cycle in the next stage. The resetting of state variables can also be bound to the reset event log recording, that is, before clearing the variables, their current state is written to the debug log or coverage database to support subsequent debugging and analysis work.

[0107] By applying a reset pulse signal conforming to the design specifications to the device under test (DUT) during the pre-reset phase and waiting for the DUT to stabilize to an idle state, and then acquiring the output response of the DUT through a monitor and verifying whether the reset behavior meets expectations based on the output response, and only resetting the internal counters and state variables of the unified verification environment after confirming that the reset behavior is accurate, the reset state of the DUT hardware layer and the running context of the unified verification environment software layer can be bidirectionally aligned before entering the next main running phase. This ensures that the DUT does not have any historical running residues and that the verification environment does not interfere with the execution of the new round of business with past counts and flags. It avoids the situation of "the DUT has been reset but the environment has not been cleared" or the opposite after reset, and improves the consistency of the overall system from reset to restart and the reliability of verification results in the reset scenario during business.

[0108] Figure 5 The diagram illustrates a sequence of stages in a unified verification environment according to some embodiments of the present disclosure.

[0109] refer to Figure 5 As shown, the unified verification environment in this embodiment includes at least a construction phase 501, a connection phase 502, an expansion completion phase 503, a simulation startup phase 504, a running phase 505, a data extraction phase 518, an inspection phase 519, a reporting phase 520, and a completion phase 521. Within the running phase 505, according to a predetermined execution order, it may sequentially include a pre-reset phase 506, a reset phase 507, a post-reset phase 508, a pre-configuration phase 509, a configuration phase 510, a post-configuration phase 511, a pre-main running phase 512, a main running phase 513, a post-main running phase 514, a pre-shutdown phase 515, a shutdown phase 516, and a post-shutdown phase 517.

[0110] The unified verification process is divided into several phases. Phase 501 initializes the component objects of the unified verification environment; Phase 502 establishes port connections and resource bindings between components; Phase 503 completes the expansion and static configuration of the environment structure; Phase 504 starts the simulation timeline; Phase 505 is the main phase for executing business stimuli, reset monitoring, and dynamic phase transitions; Phases 506 through 517 of the running phase are executed sequentially to implement reset processing, environment configuration, business stimuli, sequence cleanup, and shutdown logic; Phases 518, 519, 520, and 521 are used to generate verification results, perform consistency checks, output verification reports, and terminate the entire verification process, respectively. By setting a clear order between reset-related phases and main running-related phases within Phase 505, the unified verification environment can process reset events in stages during business execution; and by continuously connecting shutdown-related phases and post-processing phases, the verification process has complete lifecycle management capabilities, thereby achieving complete behavioral verification of the device under test in different business, reset, and termination phases.

[0111] Figure 6 The illustration shows a sequence of stages for resetting during the implementation of services according to some embodiments of the present disclosure.

[0112] refer to Figure 6 As shown, during business operation, when a reset event is detected, the stage control flow jumps from the main post-run stage to the pre-reset stage, and the location where the stage end callback function is triggered in the main post-run stage. For example, the operation stages sequentially include pre-reset stage 506, reset stage 507, post-reset stage 508, and several intermediate stages for environment configuration and business preparation, as detailed in [link to documentation]. Figure 5 As shown; then, the pre-main operation phase 512 and the main operation phase 513 are executed sequentially. In the operation phase, the main operation phase 513 is the phase in which business incentive execution and reset monitoring are carried out in parallel, as well as the phase for incentive termination and sequence cleanup preparation.

[0113] When the phase end event is triggered in the main operation phase 513, the phase management module calls the phase end callback function to perform cleanup operations on the unsent stimulus sequences between the sequencer and the driver, and completes the preparation logic related to phase jump. If a reset event is detected during business execution, after the phase end callback function is executed, the current phase is jumped from the main operation phase 513 to the pre-reset phase 506 through the phase jump logic to re-enter the reset-related phase to perform the reset operation. Figure 6The stage jump path shown indicates that when a reset signal is detected in the main operation stage and the triggering condition is met, the stage scheduler switches the unified verification environment from the current stage back to the pre-reset stage according to the stage jump instruction. This achieves staged control of resets during business processes, enabling each verification environment component to perform reset processing in a consistent stage context, and ensuring that the execution order of the reset process after the stage switch is consistent with the cleanup logic of the stimulus sequence.

[0114] It should be noted that although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0115] Furthermore, in this example embodiment, a reset verification device for a business process is also provided. This reset verification device can be installed on an electronic device with a unified verification environment deployed thereon. The unified verification environment includes verification environment components, which at least include a test component, a sequencer, and a driver. (Refer to...) Figure 7 As shown, the reset verification device 700 in this business process includes: a reset signal monitoring module 710, a sequence cleanup module 720, a reset synchronization jump module 730, and a business process reset module 740. Wherein: The reset signal monitoring module 710 is used to perform normal business processes and monitor reset signals in parallel. The reset signals are monitored by the test component during the main operation phase. The sequence cleanup module 720 is used to perform a sequence cleanup operation in response to the detection of the reset signal. The sequence cleanup operation is performed in the phase end callback function of the main running phase. The sequence cleanup operation is used to stop the unsent stimulus sequence between the sequencer and the driver. The reset synchronization jump module 730 is used to trigger a stage jump instruction, which is used to cause all verification environment components, including the test component, in the unified verification environment to synchronously jump from the main running stage to the pre-reset stage, and the verification environment components perform a reset operation in the pre-reset stage. The business process reset module 740 is used to control all the verification environment components to restart a new normal business process in response to determining that the reset operation has been completed.

[0116] In some example embodiments of this disclosure, based on the foregoing scheme, the sequence cleanup module 720 is configured as follows: A stop command is sent to the sequencer, the stop command being used to interrupt the transmission of untransmitted stimulus sequences in the sequencer and discard the untransmitted stimulus sequences; Receive a handshake confirmation signal from the driver, the handshake confirmation signal being used to confirm that all ongoing excitation sequences have been completed; Based on the handshake confirmation signal, the sequence status register is updated to mark the completion of the cleanup of the unsent stimulus sequence.

[0117] In some example embodiments of this disclosure, based on the foregoing scheme, the reset synchronization jump module 730 is configured as follows: The level of the reset signal is monitored, and the level of the reset signal is monitored during the main operation phase of the test component; When the level state of the reset signal is detected to switch from an invalid state to an valid state and this switch continues for more than a preset clock cycle, a stage jump instruction is generated. The phase jump instruction is passed to the phase scheduler of the unified verification environment so that the phase scheduler initiates synchronous phase jumps for all verification environment components.

[0118] In some example embodiments of this disclosure, based on the foregoing scheme, the reset synchronization jump module 730 is configured as follows: Send the stage jump instruction to the stage scheduler, wherein the stage jump instruction specifies the pre-reset stage as the jump target; The phase jump instruction is broadcast by the phase scheduler to all verification environment components, including the test component. Upon receiving the stage jump instruction, all verification environment components pause their current normal business processes and perform local state saving until all verification environment components confirm that they are ready to be reset, at which point they synchronously enter the pre-reset stage.

[0119] In some example embodiments of this disclosure, based on the foregoing scheme, the reset signal monitoring module 710 is configured as follows: A reset monitoring thread is created and executed in parallel with the normal business process. The reset monitoring thread is created by the test component during the main running phase. The reset monitoring thread periodically reads the level value of the reset signal; When the level value of the reset signal indicates that a reset event has occurred, the event flag register is updated and the stage controller of the test component is triggered.

[0120] In some example embodiments of this disclosure, based on the foregoing scheme, the sequence cleanup module 720 is configured as follows: Bind the phase end callback function to the phase end event; When the phase end event is detected to be triggered, the phase end callback function is invoked to access the interface between the sequencer and the driver; The sequence cleanup operation on the sequencer and the driver is performed through the interface, and the internal state machine of the sequencer is reset.

[0121] In some example embodiments of this disclosure, based on the foregoing scheme, the unified verification environment includes the device under test, and the verification environment components further include a monitor; the service process reset module 740 is configured as follows: Apply a reset pulse signal to the device under test and wait for the device under test to stabilize to an idle state; The monitor is used to acquire the output response of the device under test, and the reset behavior of the device under test is verified based on the output response to see if it meets expectations. In response to determining that the reset action was accurately completed, the internal counters and state variables of the unified verification environment are reset.

[0122] The specific details of each module of the reset verification device in the above-mentioned business process have been described in detail in the corresponding reset verification method of the business process, so they will not be repeated here.

[0123] It should be noted that although several modules or units of the reset verification device in the business process have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0124] Furthermore, in an exemplary embodiment of this disclosure, an electronic device capable of implementing the reset verification method in the above-described business process is also provided.

[0125] Those skilled in the art will understand that various aspects of this disclosure can be implemented as a system, method, or program product. Therefore, various aspects of this disclosure can be embodied in the following forms: a completely hardware embodiment, a completely software embodiment (including firmware, microcode, etc.), or an embodiment combining hardware and software aspects, collectively referred to herein as a "circuit," "module," or "system."

[0126] The following reference Figure 8 To describe an electronic device 800 according to such an embodiment of the present disclosure. Figure 8 The electronic device 800 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0127] like Figure 8 As shown, the electronic device 800 is presented in the form of a general-purpose computing device. The components of the electronic device 800 may include, but are not limited to: at least one processing unit 810, at least one storage unit 820, a bus 830 connecting different system components (including storage unit 820 and processing unit 810), and a display unit 840.

[0128] The storage unit stores program code that can be executed by the processing unit 810, causing the processing unit 810 to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure. For example, the processing unit 810 can perform actions such as... Figure 1 Step S110, as shown, executes the normal business process and monitors the reset signal in parallel. The reset signal is monitored by the test component during the main operation phase. Step S120, in response to detecting the reset signal, performs a sequence cleanup operation. The sequence cleanup operation is performed in the phase end callback function of the main operation phase. The sequence cleanup operation is used to stop the unsent stimulus sequence between the sequencer and the driver. Step S130, triggers a phase jump instruction. The phase jump instruction is used to cause all verification environment components, including the test component, in the unified verification environment to synchronously jump from the main operation phase to the pre-reset phase, and the verification environment components perform a reset operation in the pre-reset phase. Step S140, in response to determining that the reset operation is completed, controls all verification environment components to restart a new normal business process.

[0129] Storage unit 820 may include readable media in the form of volatile storage units, such as random access memory (RAM) 821 and / or cache memory 822, and may further include read-only memory (ROM) 823.

[0130] Storage unit 820 may also include a program / utility 824 having a set (at least one) program module 825, such program module 825 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0131] Bus 830 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0132] Electronic device 800 can also communicate with one or more external devices 870 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 800, and / or with any device that enables electronic device 800 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 850. Furthermore, electronic device 800 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 860. As shown, network adapter 860 communicates with other modules of electronic device 800 via bus 830. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 800, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0133] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0134] In exemplary embodiments of this disclosure, a computer-readable storage medium is also provided, on which a program product capable of implementing the methods described above is stored. In some possible embodiments, various aspects of this disclosure may also be implemented as a program product including program code that, when the program product is run on a terminal device, causes the terminal device to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure.

[0135] refer to Figure 9 As shown, a program product 900 for implementing the reset verification method in the above-described business process according to an embodiment of the present disclosure is described. It may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the program product of the present disclosure is not limited thereto. In this document, a readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0136] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0137] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0138] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0139] Program code for performing the operations of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0140] Furthermore, the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of this disclosure and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0141] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0142] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the claims.

[0143] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A reset verification method in a business process, characterized in that, Applied to electronic devices deployed with a unified verification environment, the unified verification environment including verification environment components, the verification environment components including at least a test component, a sequencer, and a driver, the method includes: The test component performs normal business processes and monitors reset signals in parallel, the reset signals being monitored by the test component during the main operation phase. In response to the detection of the reset signal, a sequence cleanup operation is performed. The sequence cleanup operation is performed in the phase end callback function of the main running phase. The sequence cleanup operation is used to stop the unsent stimulus sequence between the sequencer and the driver. A stage jump instruction is triggered, which is used to cause all verification environment components, including the test component, in the unified verification environment to jump synchronously from the main running stage to the pre-reset stage, and the verification environment components perform a reset operation in the pre-reset stage. In response to confirming the completion of the reset operation, control all verification environment components to restart a new normal business process.

2. The method according to claim 1, characterized in that, The step of performing a sequence cleanup operation in response to detecting the reset signal includes: A stop command is sent to the sequencer, the stop command being used to interrupt the transmission of untransmitted stimulus sequences in the sequencer and discard the untransmitted stimulus sequences; Receive a handshake confirmation signal from the driver, the handshake confirmation signal being used to confirm that all ongoing excitation sequences have been completed; Based on the handshake confirmation signal, the sequence status register is updated to mark the completion of the cleanup of the unsent stimulus sequence.

3. The method according to claim 1, characterized in that, The trigger phase jump instruction includes: The level of the reset signal is monitored during the main operation phase of the test component. When the level state of the reset signal is detected to switch from an invalid state to an valid state and this switch continues for more than a preset clock cycle, a stage jump instruction is generated. The phase jump instruction is passed to the phase scheduler of the unified verification environment so that the phase scheduler initiates synchronous phase jumps for all verification environment components.

4. The method according to claim 3, characterized in that, The step of transmitting the phase jump instruction to the phase scheduler of the unified verification environment, so that the phase scheduler initiates synchronous phase jumps for all verification environment components, includes: Send the stage jump instruction to the stage scheduler, wherein the stage jump instruction specifies the pre-reset stage as the jump target; The phase jump instruction is broadcast by the phase scheduler to all verification environment components, including the test component. Upon receiving the stage jump instruction, all verification environment components pause their current normal business processes and perform local state saving until all verification environment components confirm that they are ready for reset, at which point they synchronously enter the pre-reset stage.

5. The method according to claim 1, characterized in that, The parallel monitoring reset signal includes: A reset monitoring thread is created and executed in parallel with the normal business process. The reset monitoring thread is created by the test component during the main running phase. The reset monitoring thread periodically reads the level value of the reset signal; When the level value of the reset signal indicates that a reset event has occurred, the event flag register is updated and the stage controller of the test component is triggered.

6. The method according to claim 1, characterized in that, The step of performing a sequence cleanup operation in response to detecting the reset signal includes: Bind the phase end callback function to the phase end event; When the phase end event is detected to be triggered, the phase end callback function is invoked to access the interface between the sequencer and the driver; The sequence cleanup operation on the sequencer and the driver is performed through the interface, and the internal state machine of the sequencer is reset.

7. The method according to claim 1, characterized in that, The unified verification environment includes the device under test, and the verification environment components also include a monitor; The reset operation performed during the pre-reset phase includes: Apply a reset pulse signal to the device under test and wait for the device under test to stabilize to an idle state; The monitor is used to acquire the output response of the device under test, and the reset behavior of the device under test is verified based on the output response to see if it meets expectations. In response to determining that the reset action was accurately completed, the internal counters and state variables of the unified verification environment are reset.

8. A reset verification device in a business process, characterized in that, An apparatus for use with an electronic device deployed in a unified verification environment, the unified verification environment including verification environment components, the verification environment components including at least a test component, a sequencer, and a driver, the apparatus comprising: The reset signal monitoring module is used to perform normal business processes and monitor reset signals in parallel. The reset signals are monitored by the test component during the main operation phase. A sequence cleanup module is used to perform a sequence cleanup operation in response to the detection of the reset signal. The sequence cleanup operation is performed in the phase end callback function of the main running phase. The sequence cleanup operation is used to stop the unsent stimulus sequence between the sequencer and the driver. The reset synchronization jump module is used to trigger a stage jump instruction, which is used to cause all verification environment components, including the test component, in the unified verification environment to synchronously jump from the main running stage to the pre-reset stage, and the verification environment components perform a reset operation in the pre-reset stage. The business process reset module is used to control all the verification environment components to restart a new normal business process in response to the determination that the reset operation has been completed.

9. An electronic device, characterized in that, include: Processor; and A memory storing computer-readable instructions that, when executed by the processor, implement the reset verification method in the business process as described in any one of claims 1 to 7.

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

Images