A method, apparatus, and medium for managing uvm use case timeouts with a counting module

Abstract

The application discloses a kind of method, equipment and medium for managing UVM use case timeout using counting module, it is related to UVM management technical field, method includes: according to function, verification module signal is divided into multiple groups of signals, each group of signals respectively corresponds a kind of data interaction scene;Each group of signals is respectively instantiated a counting module, and each group of signals is accessed the observation data input port of corresponding counting module;From port, the corresponding timeout counting threshold value is transmitted into each counting module, and timeout counting value is dynamically modified in simulation process;Counting module is counted to the observation data of corresponding signal group by internal counter;If the count value of internal counter reaches timeout counting threshold value, then trigger timeout processing flow;If all counting modules do not trigger timeout processing flow, then simulation normally ends.The present application can not only accurately match the business differences of each module, but also adapt to the dynamic changes in complex scenarios, and is more flexible compared with fixed threshold scheme.

Description

Technical Field

[0001] This invention relates to the field of UVM management technology, and more specifically to a method, device, and medium for managing UVM use case timeouts using a counting module. Background Technology

[0002] In a UVM verification environment, UVM use cases typically get stuck for the following reasons: failure to trigger the UVM automatic termination mechanism; stimulus / response blocking (e.g., unresponsive chip code, process deadlock); environment configuration errors (e.g., abnormal clock reset, component connection errors); multi-threaded deadlock / improper management.

[0003] Normally, test cases can use UVM's built-in timeout mechanism, i.e., "+UVM_TIMEOUT=xxx", which will automatically exit after the test case simulation runs for the specified time. UVM_TIMEOUT, as UVM's built-in global timeout mechanism, has three main drawbacks: insufficient flexibility, inefficient location, and susceptibility to misjudgment. Specifically: 1) A single global threshold cannot provide fine-grained control (e.g., long timeouts are required for the cache management bus, while short timeouts are required for the data bus). 2) Termination is triggered without context information, making it impossible to directly locate the blockage point; 3) The simulation terminates directly after a timeout, resulting in the loss of critical states at the moment of blockage; 4) Threshold configuration relies on experience; setting it too short may terminate the normal process, while setting it too long may waste simulation time. Summary of the Invention

[0004] The purpose of this invention is to overcome the shortcomings of the prior art and provide a method, device and medium for managing UVM use case timeouts using a counting module.

[0005] The objective of this invention is achieved through the following technical solution: In a first aspect, this application discloses a method for managing UVM use case timeouts using a counting module, comprising: During the signal grouping phase, the verification module signals are divided into multiple groups of signals according to their functions, with each group of signals corresponding to a type of data interaction scenario. During the instantiation of the counting module stage, a counting module is instantiated for each group of signals, and each group of signals is connected to the observation data input port of the corresponding counting module; During the timeout count configuration phase, the corresponding timeout count threshold is passed to each counting module from the port, and the timeout count value is dynamically modified during the simulation. During the timeout detection and processing phase, the counting module counts the observed data of the corresponding signal group through an internal counter; If the count value of the internal counter reaches the timeout count threshold, the timeout processing procedure is triggered. If none of the counting modules trigger the timeout process, the simulation ends normally. The timeout handling process includes printing the complete hierarchy using the system's built-in %m function, explicitly printing the bus where the timeout occurred, retaining the critical state of the counting module at the moment of blocking, and simultaneously printing and recording the critical state in the log. Then, the simulation branch corresponding to the counting module is terminated.

[0006] Based on the first aspect, each counting module operates independently, and the timeout counting thresholds for different counting modules can be configured independently.

[0007] Based on the first aspect, the independent configuration of the timeout counting threshold specifically includes: setting the timeout counting threshold according to the spec of the bus corresponding to the counting module, wherein the timeout counting threshold is greater than the timeout time specified on the spec, and if the spec has a requirement for the timeout time, the timeout counting threshold is dynamically adjusted.

[0008] Based on the first aspect, the bit width of the observation data is not fixed. The relevant commands, data and enable bits are concatenated before observation.

[0009] Based on the first aspect, the counting module is equipped with a reference clock. When the reference clock is at its rising edge, if all bits of data are the same as before, the internal count is incremented by one; if all bits of data are different from before, the internal count is cleared to zero.

[0010] Based on the first aspect, the counting module is externally connected to a reset source. If the system observed by the counting module is reset, the internal count can be set to zero through the reset signal.

[0011] Based on the first aspect, the type of the last command sent before the timeout, the amount of data transmitted before the timeout, and the state machine of the observed system, wherein the state machine of the observed system before the timeout includes indicators that data transmission has not yet started, data is being transmitted, or data transmission has been completed.

[0012] Secondly, this application discloses an electronic device, the electronic device comprising: Memory, which stores executable instructions; A processor that executes the executable instructions in the memory to implement the method described above.

[0013] Thirdly, this application discloses a computer storage medium storing a computer program, which is executed by a processor to implement the method described above.

[0014] The beneficial effects of this invention are: 1) This application addresses the inherent "one-size-fits-all" flaw of existing technologies that commonly employ a global single threshold configuration mode by configuring thresholds independently in a layered / module-based manner, combined with a dynamic threshold adjustment mechanism based on simulation phase (initialization, steady-state operation, peak load) or real-time data flow characteristics (data throughput, link utilization). This not only enables threshold configuration to accurately match the differences in business operations of each module but also adapts to dynamic changes in complex scenarios, offering greater flexibility compared to fixed threshold schemes.

[0015] 2) When timeout issues occur in existing technologies, only termination is triggered without context information, making it impossible to directly locate the blockage point. This application can directly report the timeout location, thereby directly locating the problem, significantly shortening the problem location time, and greatly reducing the debugging workload and cost for technical personnel.

[0016] 3) This application combines the instantaneous state freeze function during blocking, which breaks through the traditional "timeout termination" mode. When the blocking threshold is triggered, the simulation is not terminated directly, and the key state data during the blocking moment is fully preserved, avoiding the loss of key information caused by timeout termination in the traditional mode.

[0017] 4) Existing threshold configuration technologies rely heavily on the practical experience of technical personnel, resulting in high configuration barriers and susceptibility to unreasonable threshold configurations due to experience biases. Thresholds that are too short may delay the termination of the normal process, while thresholds that are too long may waste simulation time, making it difficult to balance simulation efficiency and accuracy. This solution, through its intelligent threshold configuration function, automatically completes threshold adaptation based on Spec configuration, significantly reducing the operational barriers and complexity of threshold configuration, effectively avoiding configuration biases caused by experience dependence, and accurately balancing simulation efficiency and accuracy. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating a method for managing UVM use case timeouts using a counting module, according to an embodiment of the present invention. Detailed Implementation

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

[0020] This application discloses a method for managing UVM test case timeouts using a counting module. It replaces the native UVM_TIMEOUT with a more refined timeout management scheme, using a custom timer to independently manage timeouts for different logic blocks. This supports pre-timeout warnings, precise location of blocking points, and avoids abrupt termination due to global timeouts; it terminates directly after a timeout. The counting module requires a reference clock (clk), a reset source (rstn), observation data (data), and a set timeout count (des_cnt).

[0021] The technical terms used in this application are explained below: UVM: Universal Verification Methodology is a standardized verification methodology based on SystemVerilog, specifically designed for digital circuit verification. It provides a reusable and scalable verification framework to help engineers efficiently build verification environments for complex chips (such as SoCs, ASICs, and FPGAs).

[0022] Test cases: Here, test cases specifically refer to those used in the simulation process. They are designed to trigger specific stimuli for specific business scenarios, in order to verify the functionality and ensure its completeness and correctness.

[0023] Hierarchy: In the field of chip / electronic engineering, hierarchy is a key concept that runs through core aspects such as design, packaging, and interconnection. It refers to breaking down a complex system into manageable sub-units through a "layered and modular" approach, with each layer focusing on a specific function and achieving collaboration between layers through standardized interfaces.

[0024] In the field of chip / electronics engineering, a specification (SPEC) is a core document standard that defines the "functions, performance, interfaces, compatibility, and reliability" of a product / technology. It serves as a "technical contract" for design, development, verification, production, and upstream and downstream collaboration. Whether it's chiplet integration, high-speed interconnect protocols, or packaging processes, SPEC clearly defines the "requirements that must be met" and the "permissible boundaries," directly determining the product's compatibility, scalability, and feasibility for implementation.

[0025] %m: Adding %m ($display(“ … %m …”);) to the print function will print the hierarchical structure (… top.instance1 …) at the same time. This feature makes it easy to find the source of the print information when instantiating multiple identical modules, and explicitly indicates that the print information comes from instance0, instance1 or instance2.

[0026] The flowchart of the method is shown below. Figure 1 As shown, the specific steps include: During the signal grouping phase, the verification module signals are divided into multiple groups of signals according to their functions, with each group of signals corresponding to a type of data interaction scenario. For example, taking a front-end module that exchanges data between the chip and the outside world as an example, it typically includes: an external data signal group (for data interaction with the outside world, generally including commands, data, and enable bits); an internal data signal group (for data transmission within the chip); and a register configuration signal group (configured via the CPU module). During the instantiation of the counting module stage, a counting module is instantiated for each group of signals, and each group of signals is connected to the observation data input port of the corresponding counting module; During the timeout count configuration phase, the corresponding timeout count threshold is passed to each counting module from the port, and the timeout count value is dynamically modified during the simulation. During the timeout detection and processing phase, the counting module counts the observed data of the corresponding signal group through an internal counter; If the count value of the internal counter reaches the timeout count threshold, the timeout processing procedure is triggered. If none of the counting modules trigger the timeout process, the simulation ends normally. The timeout handling process includes printing the complete hierarchy using the system's built-in %m, explicitly printing the bus where the timeout occurred, retaining the critical state of the counting module at the moment of blocking, and simultaneously printing and recording the critical state to the log. Then, the simulation branch corresponding to the counting module is terminated (using the system's built-in $finish to terminate the simulation).

[0027] For example, each counting module operates independently, and the timeout counting thresholds for different counting modules can be configured independently. That is, users can instantiate multiple counting modules, set their own timeout counts, and use different thresholds for fine-grained management of each bus.

[0028] For example, the independent configuration of the timeout counting threshold specifically includes: setting the timeout counting threshold according to the spec of the bus corresponding to the counting module. Generally, the timeout counting threshold is greater than the timeout time specified on the spec. If the spec has a timeout time requirement, the timeout counting threshold is dynamically adjusted.

[0029] For example, the bit width of the observation data is not fixed. The relevant commands, data and enable bits are concatenated before observation.

[0030] For example, the counting module is provided with a reference clock. When the reference clock is on the rising edge, if all bits of data are the same as before, the internal count is incremented by one; if all bits of data are different from before, the internal count is cleared to zero.

[0031] For example, the counting module is externally connected to a reset source. If the system observed by the counting module is reset, the internal count can be set to zero by sensing the reset signal.

[0032] For example, the key states include: the type of the last command sent before the timeout, the amount of data transmitted before the timeout, and the state machine of the observed system before the timeout (indicating whether data transmission has not yet started, is in progress, or has been completed).

[0033] For example, this application discloses an electronic device, the electronic device comprising: Memory, which stores executable instructions; A processor that executes the executable instructions in the memory to implement the method described above.

[0034] For example, this application discloses a computer storage medium storing a computer program that is executed by a processor to implement the method described above.

[0035] The above description is merely a preferred embodiment of the present invention. It should be understood that the present invention is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the concept described herein through the above teachings or related technologies or knowledge. Modifications and variations made by those skilled in the art that do not depart from the spirit and scope of the present invention should be within the protection scope of the appended claims.

Claims

1. A method for managing UVM use case timeouts using a counting module, characterized in that, include: During the signal grouping phase, the verification module signals are divided into multiple groups of signals according to their functions, with each group of signals corresponding to a type of data interaction scenario. During the instantiation of the counting module stage, a counting module is instantiated for each group of signals, and each group of signals is connected to the observation data input port of the corresponding counting module; During the timeout count configuration phase, the corresponding timeout count threshold is passed to each counting module from the port, and the timeout count value is dynamically modified during the simulation. During the timeout detection and processing phase, the counting module counts the observed data of the corresponding signal group through an internal counter; If the count value of the internal counter reaches the timeout count threshold, the timeout processing procedure is triggered. If none of the counting modules trigger the timeout process, the simulation ends normally. The timeout handling process includes printing the complete hierarchy using the system's built-in %m function, explicitly printing the bus where the timeout occurred, retaining the critical state of the counting module at the moment of blocking, and simultaneously printing and recording the critical state in the log. Then, the simulation branch corresponding to the counting module is terminated.

2. The method for managing UVM use case timeouts using a counting module according to claim 1, characterized in that: Each counting module operates independently, and the timeout counting thresholds for different counting modules can be configured independently.

3. The method for managing UVM use case timeouts using a counting module according to claim 2, characterized in that, The independent configuration of the timeout counting threshold specifically includes: setting the timeout counting threshold according to the spec of the bus corresponding to the counting module, wherein the timeout counting threshold is greater than the timeout time specified on the spec, and if the spec has a timeout time requirement, the timeout counting threshold is dynamically adjusted.

4. The method for managing UVM use case timeouts using a counting module according to claim 1, characterized in that: The bit width of the observation data is not fixed. The relevant commands, data and enable bits are concatenated before observation.

5. A method for managing UVM use case timeouts using a counting module according to claim 1, characterized in that: The counting module is equipped with a reference clock. When the reference clock is on its rising edge, if all bits of data are the same as before, the internal count is incremented by one; if all bits of data are different from before, the internal count is cleared to zero.

6. The method for managing UVM use case timeouts using a counting module according to claim 1, characterized in that: The counting module is externally connected to a reset source. If the system observed by the counting module is reset, the internal count can be reset to zero through the reset signal.

7. A method for managing UVM use case timeouts using a counting module according to claim 1, characterized in that, The key states include: the type of the last command sent before the timeout, the amount of data transmitted before the timeout, and the state machine of the observed system. The state machine of the observed system before the timeout includes indicators that data transmission has not yet started, is transmitting data, or has completed data transmission.

8. An electronic device, characterized in that, The electronic device includes: Memory, which stores executable instructions; A processor that executes the executable instructions in the memory to implement the method of any one of claims 1-7.

9. A computer storage medium, characterized in that, The medium stores a computer program, which is executed by a processor to implement the method according to any one of claims 1-7.

Images