Monitoring method and device, verification equipment, medium and program

Abstract

The embodiment of the invention provides a monitoring method and device, verification equipment, a medium and a program, the monitoring method is applied to a register monitor and comprises the steps that a design path corresponding to a target register and a path character string stored in the register monitor are obtained, and the value of a signal in the design path of the target register is a monitoring object of the register monitor; an update waiting task is called, the update waiting task is used for registering callback functions on a plurality of signals of the design path, and the callback functions are automatically called when the values of the signals change so as to respond to and process the changes of the values of the signals; when the value of the signal in the design path changes, a callback function is executed to trigger a value change occurrence event, the value change occurrence event being used to indicate that the value of the signal in the design path changes. According to the method, the change of the value of the register can be monitored, the value in the register model is updated in real time, state synchronization of the register model and the register in the to-be-tested design is ensured, and the simulation verification accuracy is improved.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computer technology, and specifically to a monitoring method, apparatus, verification device, medium, and program. Background Art

[0002] In integrated circuit design (such as chip design), simulation verification is a key step in ensuring functional correctness, and the DUT is the verification target for the corresponding IC design. During the simulation verification process, the verification platform constructs a register abstraction layer (RAL) based on the UVM (Universal Verification Methodology) to abstract and model the registers in the DUT. This allows verification personnel to access and control the registers in the DUT through the register model.

[0003] In this context, how to provide a monitoring method that can realize active monitoring of registers and improve the accuracy of simulation verification has become a technical problem that needs to be solved urgently by those skilled in the art. Summary of the Invention

[0004] In view of this, the embodiments of the present application provide a monitoring method, apparatus, verification equipment, medium and program that can actively monitor changes in register values, update the values ​​in the register model in real time, ensure that the register model is synchronized with the register status in the design to be tested, and improve the accuracy of simulation verification.

[0005] To achieve the above objectives, the embodiments of the present application provide the following technical solutions.

[0006] In a first aspect, an embodiment of the present application provides a monitoring method, characterized in that it is applied to a register monitor, and the method includes:

[0007] Obtaining a design path corresponding to a target register and storing the path string in a register monitor, wherein the value of a signal in the design path of the target register is a monitoring object of the register monitor;

[0008] Calling a waiting update task, wherein the waiting update task is used to register a callback function on a plurality of signals of the design path, and the callback function is automatically called when the value of the signal changes, so as to respond to and process the change of the signal value;

[0009] When the value of the signal in the design path changes, a callback function is executed to trigger a value change event, where the value change event is used to indicate that the value of the signal in the design path has changed.

[0010] Optionally, the value change event is further used to trigger an automatic update task, and the automatic update task automatically updates the mirror value in the register model corresponding to the target register based on the change in the value of the signal.

[0011] Optionally, the waiting update task includes a waiting for any signal change subtask; and calling the waiting update task includes calling the waiting for any signal change subtask;

[0012] The calling of the waiting for any signal change subtask includes:

[0013] Utilize the waiting for any signal change subtask to receive the path character string;

[0014] Based on the path character string, calling the DPI task of the waiting for any signal change subtask, wherein the DPI task is the waiting for any signal change subtask in the DPI environment;

[0015] The DPI task registers callback functions for value change callbacks on a plurality of signals of the design path.

[0016] Optionally, calling the DPI task of the waiting for any signal change subtask based on the path character string includes:

[0017] Convert the path string into a dynamic array;

[0018] Through DPI, a DPI task of the subtask of waiting for arbitrary signal changes is imported, and the dynamic array and the size of the dynamic array are used as parameters of the DPI task.

[0019] Optionally, the dynamic array indicates a design level signal of each field of the target register, and the design level signal is a signal of the design path;

[0020] The callback function for registering a value change callback on multiple signals of the design path through the DPI task includes:

[0021] Based on the size of the dynamic array, the signals indicated by the dynamic array are processed as follows:

[0022] Get the handle of the signal;

[0023] Register a callback function on the handle of the signal, and set the callback reason of the callback function to the change of the signal value;

[0024] The function body of the callback function is set as the value change callback, and the parameter is set as the address of the waiting state.

[0025] Optionally, when the value of the signal in the design path changes, executing the callback function to trigger a value change event includes:

[0026] When the value of the signal that registers the callback function changes, the callback function is executed;

[0027] And, based on the wait event triggering task output by register verification, the wait value change event is triggered and the process corresponding to the DPI task is suspended;

[0028] After the callback function is executed, the value change event is triggered and the process is woken up.

[0029] Optionally, also include:

[0030] After waking up the process, checking whether the wait state is a first value;

[0031] If so, cancel the callback function registered with the signal;

[0032] If not, returning to the step of waiting for an event to trigger a task based on register verification output, waiting for a value change event to be triggered, and suspending the process corresponding to the DPI task;

[0033] When the callback function is executed, the wait state is modified to a first value based on the address of the wait state.

[0034] Optionally, the method further includes:

[0035] Through DPI, export the waiting event trigger task to wait for the value change event to be triggered;

[0036] Through DPI, an event triggering task is exported to trigger the value change event.

[0037] In a second aspect, an embodiment of the present application provides a monitoring device, applied to a register monitor, comprising:

[0038] a design path acquisition module, configured to acquire a design path corresponding to a target register and store the acquired design path into a path string of a register monitor, wherein the value of a signal in the design path of the target register is a monitoring object of the register monitor;

[0039] A waiting update task calling module is used to call a waiting update task, wherein the waiting update task is used to register a callback function on a plurality of signals of the design path, and the callback function is automatically called when the value of the signal changes to respond to and process the change in the value of the signal;

[0040] The value change event acquisition module is used to execute a callback function to trigger a value change event when the value of the signal in the design path changes. The value change event is used to indicate that the value of the signal in the design path has changed.

[0041] In a third aspect, an embodiment of the present application provides a verification device comprising at least one memory and at least one processor, wherein the memory stores one or more computer-executable instructions, and the processor calls the one or more computer-executable instructions to execute the monitoring method as described in the first aspect above.

[0042] In a fourth aspect, an embodiment of the present application provides a storage medium, which stores one or more computer-executable instructions. When the one or more computer-executable instructions are executed, the monitoring method described in the first aspect above is implemented.

[0043] In a fifth aspect, an embodiment of the present application provides a computer program product, comprising one or more computer-executable instructions, which, when executed, implement the monitoring method described in the first aspect above.

[0044] It can be seen that the monitoring method provided by the embodiment of the present application is applied to the register monitor, by obtaining the design path corresponding to the target register and storing it in the path string of the register monitor, wherein the value of the signal in the design path of the target register is the monitoring object of the register monitor; then, the waiting for the value change of the signal in the design path can be realized by calling the waiting update task, wherein the waiting update task is used to register a callback function on multiple signals of the design path, and the callback function is automatically called when the value of the signal changes to respond to and process the change of the value of the signal; when the value of the signal in the design path changes, the callback function is executed to trigger a value change event to indicate that the value of the signal in the design path has changed. That is, the embodiment of the present application obtains the design path of the monitored target register, and the value of the signal in the design path of the target register is the monitoring object of the register monitor, and by registering the callback function on multiple signals of the design path, when the value of the signal changes, the callback function is automatically called and a value change event is obtained, and the value change event can indicate that the value of the signal in the design path has changed, thereby achieving the purpose of active monitoring of the register. Furthermore, the embodiment of the present application can update the mirror value in the corresponding register model in real time according to the change of the value in the register, ensuring that the register model is synchronized with the register state in the design to be tested, thereby improving the accuracy of simulation verification. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without any creative work.

[0046] Figure 1 It is a structural diagram of the verification platform;

[0047] Figure 2 This is a flow chart of the monitoring method provided in the embodiment of the present application;

[0048] Figure 3 This is a structural diagram of a monitoring device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0049] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0050] Integrated circuit design can rely on electronic design automation tools to improve efficiency and accuracy. Specifically, designers can use HDL (Hardware Description Language) to describe the integrated circuit design based on the integrated circuit specification (such as the chip specification), and then use electronic design automation tools to perform synthesis, simulation, and verification.

[0051] Simulation verification is an important part of the integrated circuit design process. Verifiers can develop a verification platform based on their understanding of the integrated circuit specification to verify the functional correctness of the integrated circuit design. The verification environment and verification platform can be described using an integrated circuit simulation verification language (such as SystemVerilog).

[0052] After setting up the verification environment and verification platform, you can perform simulation verification of the integrated circuit design. Specifically, based on the verification requirements of the integrated circuit design (such as chip design), a corresponding design under test is established. The verification platform applies stimuli to the design under test and checks whether the design under test responds to the stimuli as expected, thus achieving simulation verification of the design under test.

[0053] To understand how the verification platform works, please refer to Figure 1 , Figure 1It is a structural diagram of the verification platform.

[0054] like Figure 1 As shown, the simulation device includes a design to be tested 1, a driver 2, a checker 3 and a verification platform controller 4, wherein the driver 2, the checker 3 and the verification platform controller 4 constitute a verification platform.

[0055] The verification platform controller 4 is responsible for issuing stimuli and receiving response inspection results. The verification platform controller 4 can interact with the user; the driver 2 receives the stimuli sent by the verification platform controller 4 and drives the stimuli into the design to be tested 1; under the action of the stimuli, the design to be tested 1 generates a corresponding response according to the function to be verified; the checker 3 obtains the response generated by the design to be tested 1 and checks the obtained response. The inspection result can be passed to the verification platform controller 4.

[0056] The process of checking the response by the checker 3 is, for example: using the expected response corresponding to the design to be tested under stimulation, the response generated by the design to be tested and the expected response are compared. If the comparison results are the same, it means that the inspection result passes; if the comparison results are different, it means that the inspection result fails.

[0057] Furthermore, a set of stimuli can be established for a function of the design under test that needs to be verified. By analyzing the pass rate of the inspection results of the response generated by the design under test under the set of stimuli, it is determined whether the verification of the function of the design under test is successful.

[0058] To facilitate simulation testers to use simulation equipment to simulate chip designs, the verification platform provides a multi-language interaction (Direct Programming Interface, DPI) interface to realize the interaction between C language and SV (SystemVerilog) language.

[0059] UVM (Universal Verification Methodology) is a methodology used in the field of integrated circuit verification, written in the System Verilog language. During the simulation verification process, the verification platform will build a register abstraction layer (RAL) based on UVM to abstract and model the registers in the design under test, allowing verifiers to easily access the registers in the design under test. By accessing the register model in the RAL through the test program, the registers in the design under test can be controlled.

[0060] In the design to be tested, a register can be composed of multiple fields. Each readable and writable field of the register is composed of one to multiple DFFs (D-type Flip-Flops), which are used to store data under the control of the clock signal and update the data under the action of the clock pulse edge to achieve synchronous control; multiple registers can form a register group or design module to store and process large amounts of data. The register group can contain multiple registers of the same or different types, and each register can have different bit widths and field divisions; in the design module, the register group can be instantiated multiple times to form a complex design structure. For example, a processor may contain multiple register groups, each register group is set as a register with different functions (such as general registers, status registers, control registers, etc.) to store different types of data.

[0061] In the UVM register abstract model, the registers in the design under test can be modeled through classes such as uvm_reg, uvm_reg_field, and uvm_reg_block. Among them, the uvm_reg_field class is used to simulate a field in the register and define the behavior and properties of the field in the register, including bit width, position, access rights (read / write / read-only / write-only), etc.; the uvm_reg class is used to simulate a complete register and encapsulates the basic properties and behaviors of the register. Therefore, a uvm_reg class can contain multiple uvm_reg_field instances; the uvm_reg_block class is used to simulate a register group, that is, a set of registers containing multiple uvm_reg instances. In the register model, the uvm_reg_block class is used to organize the hierarchy of registers and is the top-level container in the register model.

[0062] Among them, the uvm_reg_block class can contain one uvm_reg instance to multiple uvm_reg instances, or one uvm_reg_block instance to multiple uvm_reg_block instances, thereby forming a hierarchical register structure corresponding to the hierarchical structure in the design to be tested.

[0063] Furthermore, in the register model, the register model includes the mirrored field value of the register in the design under test. The mirrored value represents the register model's cache of the current value of the hardware register. Through the mirrored value, the register model can infer and track the value of the register without actually accessing the hardware; RAL can infer the value of the register in the design under test based on the access attributes of the register, and then update the mirrored value in the register model, but it cannot update the register that is automatically updated in the design under test.

[0064] One approach to updating the mirror value in the RAL is to use a backdoor to monitor changes in the signals of the design under test to update the mirror value in the RAL. In the UVM RAL (Register Abstraction Layer), backdoor access is a method for directly manipulating register signals within the DUT (Device Under Test). This method does not access registers through the front-end interface (e.g., the front-end bus) of the design under test, but rather directly through the back-end interface. In a specific implementation, a backdoor access class can be designed in the register model to implement the monitoring function of the design's signals.

[0065] However, a register backdoor access model can only correspond to one register instance in the design under test. When there are multiple register design instances in the design under test, each register design instance has different design signals, and it is impossible to provide a universal backdoor class for monitoring, resulting in low scalability. Secondly, each register needs to generate a unique backdoor class to independently monitor the signals in the design under test and update the registers in the design under test. It is necessary to allocate a backdoor class for each register and start the backdoor class update thread, resulting in lengthy source code.

[0066] To solve the above problems, an embodiment of the present application provides a monitoring method, which is applied to a register monitor and can actively monitor the changes in the values ​​of registers in the design to be tested, update the mirror values ​​in the register model in real time, and ensure that the register model is synchronized with the register status in the design to be tested, so as to improve the accuracy of simulation verification.

[0067] Please refer to Figure 2 , Figure 2 This is a flow chart of the monitoring method provided in an embodiment of the present application.

[0068] like Figure 2 As shown, the monitoring method may include the following steps.

[0069] Step S201: obtaining a design path corresponding to a target register and storing it in a path character string of a register monitor, wherein the value of a signal in the design path of the target register is a monitoring object of the register monitor.

[0070] In an embodiment of the present application, a register monitor is used to monitor the status of registers in the design under test, such as continuously tracking changes in values ​​in registers; the registers monitored by the register monitor are called target registers, and the number of the target registers can be one or more.

[0071] Step S201 may be included in the process of initializing the register monitor. Specifically, initializing the register monitor may include initializing the monitoring object of the register monitor and initializing the path string. By initializing the monitoring object of the register monitor, the embodiment of the present application may define the target register as the monitoring object of the register monitor. By initializing the path string, the embodiment of the present application may execute step S201, obtain the design path corresponding to the target register, and store it in the path string of the register monitor. Subsequently, the monitoring function of the target register may be realized by monitoring the value of the signal of the design path of the target register. That is, in the embodiment of the present application, the monitoring object of the register monitor is the target register, which may specifically be the value of the signal in the design path of the target register.

[0072] In an optional embodiment, an active monitor class active_monitor can be extended from the backdoor access backdoor class to implement the monitoring function of the register monitor, wherein the extended class can encapsulate common functions (such as register monitors) and reuse them to improve the code reuse rate, thereby supporting any number of register instances; thus, the active monitor class active_monitor can be regarded as a constructed register monitor, and the active monitor class active_monitor can include member variables target and m_paths_str[$], wherein target represents the monitoring object of the register monitor, and m_paths_str[$] represents the path string of the register monitor; further, by defining target as the target register and m_paths_str[$] as the design path corresponding to the target register, the initialization of the active monitor class active_monitor, that is, the initialization of the register monitor, can be completed, wherein the data type of target is uvm_reg, that is, a complete register instance, and the data type of m_paths_str[$] is string, that is, a string type.

[0073] That is to say, after completing the definition of the member variables in the active monitor class, the monitoring object and design path are assigned to the corresponding member variables, for example, the target register is assigned to target, and the design path corresponding to the target register is assigned to the path string, thereby completing the instantiation and initialization process of the register monitor.

[0074] In an optional embodiment of assigning target, a monitoring object of a register monitor can be constructed through a constructor. When constructing the object, the monitoring object can be specified by the caller, and the specified monitoring object can be assigned to target, thereby completing the definition of the monitored target register.

[0075] After completing the initialization of the register monitor's monitoring object, it is necessary to obtain the design path corresponding to the target register and store it in the register monitor's path string. In an optional implementation, the design path corresponding to the target register can be represented as an HDL_path (Hardware Description Language Path), which refers to the complete design path of the register in the design under test, including the complete hierarchical path of all fields contained in the register. The HDL_path is a hierarchical string used to locate a specific signal or module in a complex hardware design. The HDL_path reflects the hierarchical structure of the hardware design, starting from the top-level module, gradually deepening into the sub-modules, and ultimately locating a specific signal or register. During simulation or debugging, the HDL_path can help verification personnel quickly locate the value or state of a specific signal.

[0076] That is to say, in an embodiment of the present application, the signal in the design path HDL_path corresponding to the target register can be a data stream transmitted in the target register, specifically a design-level signal of each field of the target register. The design-level signal of each field of the target register can represent the interaction relationship between each field inside the register and the control logic, data input and output interface in the hardware design; therefore, the embodiment of the present application can locate the value or state of a specific signal in the design path by obtaining the design path of the target register, thereby realizing the monitoring function of the target register.

[0077] In an optional implementation, by calling the method of obtaining the design path in the task of initializing the path string, the complete hierarchical path of all fields contained in the target register can be obtained and stored in m_paths_str, which is a data structure for storing the obtained hierarchical path.

[0078] In an optional example, the data structure m_paths_str storing the acquired hierarchical paths may be a queue.

[0079] Step S202: calling a waiting update task, wherein the waiting update task is used to register a callback function on multiple signals of the design path, and the callback function is automatically called when the value of the signal changes to respond to and process the change in the value of the signal.

[0080] After completing the initialization process of the register monitor, the wait for update task (wait_for_change) is called to monitor whether the value of the register in the design to be tested has changed; specifically, the wait for update task can be used to register a callback function on multiple signals in the design path, wherein the callback function refers to a function that can be automatically called when the value of the signal in the design path changes, and is used to respond to and process the change in the value of the signal, such as updating, saving data or triggering other events; therefore, in an embodiment of the present application, the callback function can be used to wait for and monitor the value change of the signal in the design path, and automatically perform specific operations when the value changes, such as updating the mirror value of the register model, thereby improving the automation and real-time performance of the code.

[0081] The following is a detailed introduction to the execution process of the waiting update task in the embodiment of the present application.

[0082] In an optional implementation, the waiting update task includes a waiting for any signal change subtask (wait_for_any_changed); accordingly, calling the waiting update task may include calling the waiting for any signal change subtask; specifically, the embodiment of the present application may utilize the waiting for any signal change subtask to receive the path string; based on the path string, call the DPI task of the waiting for any signal change subtask, wherein the DPI task is the waiting for any signal change subtask in the DPI environment; and then, through the DPI task, register a callback function on multiple signals of the design path.

[0083] In the embodiment of the present application, the wait for update task (wait_for_change) includes a wait for any signal change subtask (wait_for_any_changed), and the wait for any signal change subtask can be called to wait for the value of any signal in the design path to change.

[0084] It should be noted that the Direct Programming Interface (DPI) interface is a standard defined by the System Verilog standard to facilitate interaction with the C language, and can implement interaction between the C language and the SV (SystemVerilog) language. Therefore, the subtask of waiting for arbitrary signal changes in the DPI environment includes implementation on the C language side and on the SV side.

[0085] System Verilog has strong hardware modeling capabilities and is a language used for hardware design and verification design, supporting hardware description and verification features. However, System Verilog has limited computing power and is not suitable for handling complex data operations, data processing, and algorithm implementation. For compute-intensive tasks, System Verilog's execution efficiency is low, which may become a bottleneck for simulation performance. C, on the other hand, is a compiled language with high execution efficiency and is suitable for handling compute-intensive tasks. Therefore, for tasks that System Verilog is not good at, DPI can be used to call C functions (such as callback functions) to implement data acquisition and processing, so that when the value of the signal in the design path changes, it can automatically respond to and process the value change.

[0086] In a specific implementation, through the DPI task, callback functions can be registered on multiple signals of the design path; and through the collaboration between the SV end and the C end, the strengths of both can be fully utilized to improve verification efficiency and flexibility.

[0087] Furthermore, in an optional implementation, calling the DPI task of the waiting for arbitrary signal change subtask based on the path string includes: converting the path string into a dynamic array; importing the DPI task of the waiting for arbitrary signal change subtask through DPI, and the dynamic array and the size of the dynamic array are used as parameters of the DPI task.

[0088] In an embodiment of the present application, the path strings m_paths_str of the obtained multiple design paths can be converted into a dynamic array. The dynamic array can conveniently and flexibly manage and access data, has the characteristics of continuous storage and fast access speed, and is suitable for scenarios with frequent searches or traversals; during the simulation verification process, the dynamic array is received through DPI, which can realize the requirement of returning corresponding events when any signals in multiple fields of the register change.

[0089] In an optional example, the wait for any signal change subtask (wait_for_any_changed) receives the path string m_paths_str, converts it into a dynamic array, and then calls the DPI task imported by DPI, expressed as wait_for_any_changed_dpi(sigs,sigs.size()), where sigs represents a dynamic array, which includes the hierarchical path of each field of the register, and sigs.size() represents the size of the dynamic array; thus, the dynamic array and the size of the dynamic array serve as parameters of the DPI task (i.e., the DPI task of the wait for any signal change subtask), so that when the DPI task is subsequently executed, the signal changes of the design path can be monitored based on the above parameters.

[0090] The following is a detailed introduction to the implementation process of the DPI task on the C language side.

[0091] In an embodiment of the present application, the implementation on the C language side mainly includes registering a callback function and executing the callback function. Specifically, the dynamic array indicates the design-level signals of each field of the target register, and the design-level signals are the signals of the design path. Therefore, in the optional implementation of registering the callback function on multiple signals of the design path through the DPI task, the embodiment of the present application can, based on the size of the dynamic array, perform the following processing on the signals indicated by the dynamic array: obtain the handle of the signal; register the callback function on the handle of the signal, and set the callback reason of the callback function to the change of the value of the signal; wherein the function body of the callback function is set as the value change callback, and the parameter is set as the address of the waiting state.

[0092] In an embodiment of the present application, when a dynamic array is received through DPI, the first parameter received (for example, the dynamic array sigs) corresponds to a handle type of svOpenArrayHandle on the C language side, and the second parameter is the size of the dynamic array; in System Verilog, svOpenArrayHandle is a handle type used to represent a dynamic array, which is mainly used to transfer dynamic arrays between System Verilog and C functions, and allows System Verilog code to access and operate dynamic arrays in C functions.

[0093] Furthermore, according to the size of the dynamic array, the processing is repeated, starting from the first element in the dynamic array (the elements of the dynamic array are represented as the hierarchical path of the fields contained in the target register) until all elements of the dynamic array are processed. The specific processing flow may include the following steps:

[0094] The svGetArrElemPtr function, defined by the Verilog Procedural Interface (VPI), retrieves the value of a specified element in a dynamic array, i.e., the design-level signals for each field of the target register. VPI is a C-language programming interface defined by the Verilog HDL standard. It contains a set of function definitions. Simulators that support VPI implement this interface, allowing C programs to access, modify, and control the hardware circuit design being simulated in the simulator.

[0095] Get the signal handle through the vpi_handle_by_name function provided by VPI. A handle is essentially a pointer that points to a specific object in Verilog simulation, such as a signal. During the simulation process, the handle can be used to dynamically monitor the change of the signal value.

[0096] The callback function is registered on the handle through the function vpi_regsiter_cb provided by VPI, and the callback function is automatically called when the value of the specified signal changes. The callback reason for the callback function can be cbValueChange, that is, the value of the signal changes. In other words, when the value of the signal changes, the callback function is automatically called and executed.

[0097] In an embodiment of the present application, the function body of the callback function can be set as a value change callback, that is, when the value of the monitoring signal changes, the callback function is executed. At the same time, the parameters of the callback function can be set to the address of the wait state (wait_status). When the callback function is executed, by obtaining the address of wait_status, wait_status is set to 1, indicating that the callback function has been executed, that is, the value of the signal it monitors has changed.

[0098] In an optional example, when the callback function is executed, the address of the waiting state is obtained, and the waiting state is modified to a first value, such as 1, based on the address of the waiting state, indicating that the callback function has been executed.

[0099] Furthermore, by calling the trigger event task trigger_event output by System Verilog, the value change event value_change_occurs on the System Verilog side is triggered, wherein trigger_event is an operation for activating or triggering an event, triggering a specific event, such as triggering the value change event value_change_occurs.

[0100] That is to say, in the embodiment of the present application, the callback function is implemented on the C language side, and the value change occurrence event value_change_occurs is implemented on the System Verilog side.

[0101] Furthermore, the above processing flow is repeated to register callback functions for all elements in the dynamic array, that is, to register callback functions in all signals, and to set the variable wait_status in the callback function, so as to realize waiting for changes in multiple arbitrary signals to ensure comprehensive monitoring of the design-level signals of each field in the register; wherein, the callback functions and their parameters registered on all signals are the same, so when any signal changes, the callback function is automatically called, and wait_status can be set to 1.

[0102] Step S203: When the value of the signal in the design path changes, a callback function is executed to trigger a value change event, where the value change event is used to indicate that the value of the signal in the design path has changed.

[0103] In an embodiment of the present application, when the value of the signal in the design path changes, the callback function is automatically called and executed to trigger a value change event. The triggering of the value change event indicates that the value of the signal in the design path has changed; and then, according to the change in the value of the signal, the mirror value of the corresponding register model can be automatically updated to ensure that the register model is synchronized with the register state in the design to be tested, thereby improving the accuracy of simulation verification.

[0104] Furthermore, based on the wait event triggering task output by register verification, the wait value change event is triggered, and the process corresponding to the DPI task is suspended.

[0105] In an embodiment of the present application, the wait event trigger task wait_event_triggered output by System Verilog can be called to wait for the value change event value_change_occurs to be triggered; wherein wait_event_triggered indicates that an operation or process is waiting for the triggering of a specific event, for example, waiting for the value change event to be triggered.

[0106] At the same time, while waiting for the value change event to be triggered, the process corresponding to the DPI task is suspended to wait for the value of the signal to change and the value change event to be triggered; that is, while waiting for the value change event to be triggered, if the value of the signal does not change, the process corresponding to the DPI task will be suspended until the value of the signal changes.

[0107] Furthermore, after the callback function is executed, the value change event is triggered and the process is awakened, indicating that the value of the signal has changed, and the process corresponding to the DPI task is awakened. The value change event is used to indicate that the value of the signal in the design path has changed.

[0108] Furthermore, after the callback function is executed, the current process is awakened, and it is necessary to check whether the wait state value is 1; if the wait state value is 0, it indicates that the callback function is in a continued wait state, waiting for the value of the signal to change or other events, then returns to the aforementioned step, i.e., "the wait event based on the output of register verification triggers the task, the wait value change event is triggered, and the process corresponding to the DPI task is suspended"; if the wait state value is 1, it indicates that the callback function is in the execution state, and the callback function has been executed, then all registered callback functions need to be canceled to release resources to avoid false triggering.

[0109] The following is a detailed introduction to the implementation of the DPI task on the System Verilog side.

[0110] In the embodiment of the present application, the implementation on the System Verilog side mainly includes waiting and triggering value change events.

[0111] The implementation of the DPI task on the System Verilog side includes a support module Stub. Stub is a key part of the DPI implementation. It is used to bridge System Verilog and C code, define DPI tasks and functions, and implement complex simulation logic, including the definition of the value change event value_change_occurs, and the tasks of waiting and triggering the value change event (wait_event_triggered and trigger_event).

[0112] In an optional implementation, the System Verilog side can export the wait event trigger task wait_event_triggered through DPI, which is used to wait for the value change occurrence event value_change_occurs to be triggered. At the same time, when the value change occurrence event is triggered, the event trigger task trigger_event is exported through DPI to trigger the value change occurrence event value_change_occurs. The value change occurrence event is used to indicate that the value of the signal in the design path has changed, and then the mirror value in the register model can be updated based on the value change occurrence event.

[0113] In an embodiment of the present application, the value change event is also used to trigger an automatic update task, and the automatic update task automatically updates the mirror value in the register model corresponding to the target register based on the change in the value of the signal.

[0114] In an optional example, during the entire process of calling and executing the wait for update task (wait_for_change), the automatic update task (is_auto_updated()) always returns 1, indicating that during the entire process, as long as a value change event occurs, the automatic update task will be automatically triggered to automatically update the mirror value in the register model corresponding to the target register based on the change in the value of the signal.

[0115] Therefore, through the design and implementation of the active_monitor class mentioned above, including the joint collaboration of DPI tasks on both the SystemVerilog and C language sides, a general register monitor function is realized. This register monitor can support any number of register instances and monitor any number of registers. Therefore, it can update the mirror value in the corresponding register model in real time according to the change of the register value, ensuring the synchronization of the register model and the register status in the design under test, so as to collect register function coverage and realize register function simulation verification.

[0116] It can be seen that the monitoring method provided by the embodiment of the present application is applied to the register monitor, by obtaining the design path corresponding to the target register and storing it in the path string of the register monitor, wherein the value of the signal in the design path of the target register is the monitoring object of the register monitor; then, the waiting for the value change of the signal in the design path can be realized by calling the waiting update task, wherein the waiting update task is used to register a callback function on multiple signals of the design path, and the callback function is automatically called when the value of the signal changes to respond to and process the change of the value of the signal; when the value of the signal in the design path changes, the callback function is executed to trigger a value change event to indicate that the value of the signal in the design path has changed. That is, the embodiment of the present application obtains the design path of the monitored target register, and the value of the signal in the design path of the target register is the monitoring object of the register monitor, and by registering the callback function on multiple signals of the design path, when the value of the signal changes, the callback function is automatically called and a value change event is obtained, and the value change event can indicate that the value of the signal in the design path has changed, thereby achieving the purpose of active monitoring of the register. Furthermore, the embodiment of the present application can update the mirror value in the corresponding register model in real time according to the change of the value in the register, ensuring that the register model is synchronized with the register state in the design to be tested, thereby improving the accuracy of simulation verification.

[0117] In a further optional implementation, based on the monitoring method provided in the embodiment of the present application, the embodiment of the present application further provides a monitoring device applied to a register monitor. The monitoring device described below can be referenced in correspondence with the monitoring method described above. In an optional implementation, Figure 3 This is a schematic diagram of the structure of the monitoring device provided in the embodiment of the present application. Figure 3 , the apparatus may include:

[0118] A design path acquisition module 301 is configured to acquire a design path corresponding to a target register and store the acquired design path in a path string of a register monitor, wherein the value of a signal in the design path of the target register is a monitoring object of the register monitor;

[0119] A waiting update task calling module 302 is used to call a waiting update task, wherein the waiting update task is used to register a callback function on a plurality of signals of the design path, and the callback function is automatically called when the value of the signal changes to respond to and process the change in the value of the signal;

[0120] The value change event acquisition module 303 is used to execute a callback function to trigger a value change event when the value of the signal in the design path changes. The value change event is used to indicate that the value of the signal in the design path has changed.

[0121] In an optional implementation, the value change event is further used to trigger an automatic update task, and the automatic update task automatically updates the mirror value in the register model corresponding to the target register based on the change in the value of the signal.

[0122] In an optional implementation, the waiting update task includes a waiting for any signal change subtask; and the calling the waiting update task includes calling the waiting for any signal change subtask;

[0123] The waiting update task calling module 302 is used to call the waiting for any signal change subtask including:

[0124] Utilize the waiting for any signal change subtask to receive the path character string;

[0125] Based on the path character string, calling the DPI task of the waiting for any signal change subtask, wherein the DPI task is the waiting for any signal change subtask in the DPI environment;

[0126] The DPI task registers callback functions for value change callbacks on a plurality of signals of the design path.

[0127] In an optional implementation, the waiting update task calling module 302 is configured to call the DPI task of the waiting for any signal change subtask based on the path string, including:

[0128] Convert the path string into a dynamic array;

[0129] Through DPI, a DPI task of the subtask of waiting for arbitrary signal changes is imported, and the dynamic array and the size of the dynamic array are used as parameters of the DPI task.

[0130] In an optional implementation, the dynamic array indicates a design-level signal of each field of the target register, the design-level signal being a signal of the design path;

[0131] The waiting update task calling module 302 is used to register the value change callback function on multiple signals of the design path through the DPI task, including:

[0132] Based on the size of the dynamic array, the signals indicated by the dynamic array are processed as follows:

[0133] Get the handle of the signal;

[0134] Register a callback function on the handle of the signal, and set the callback reason of the callback function to the change of the signal value;

[0135] The function body of the callback function is set as the value change callback, and the parameter is set as the address of the waiting state.

[0136] In an optional implementation, the value change occurrence event acquisition module 303 is configured to execute a callback function to trigger a value change occurrence event when the value of a signal in the design path changes, including:

[0137] When the value of the signal that registers the callback function changes, the callback function is executed;

[0138] And, based on the wait event triggering task output by register verification, the wait value change event is triggered and the process corresponding to the DPI task is suspended;

[0139] After the callback function is executed, the value change event is triggered and the process is woken up.

[0140] In an optional implementation, it also includes:

[0141] After waking up the process, checking whether the wait state is a first value;

[0142] If so, cancel the callback function registered by the signal;

[0143] If not, returning to the step of waiting for an event to trigger a task based on register verification output, waiting for a value change event to be triggered, and suspending the process corresponding to the DPI task;

[0144] When the callback function is executed, the wait state is modified to a first value based on the address of the wait state.

[0145] In an optional implementation, it also includes:

[0146] Through DPI, export the waiting event trigger task to wait for the value change event to be triggered;

[0147] Through DPI, an event triggering task is exported to trigger the value change event.

[0148] In a further optional implementation, an embodiment of the present application also provides a verification device, comprising at least one memory and at least one processor, wherein the memory stores one or more computer-executable instructions, and the processor calls the one or more computer-executable instructions to execute the monitoring method as described in the aforementioned embodiment.

[0149] In a further optional implementation, an embodiment of the present application further provides a storage medium, wherein the storage medium stores one or more computer-executable instructions, and when the one or more computer-executable instructions are executed, the monitoring method as described in the above embodiment is implemented.

[0150] In a further optional implementation, an embodiment of the present application also provides a computer program product, comprising one or more computer-executable instructions, which, when executed, implement the monitoring method as described in the aforementioned embodiment.

[0151] The above describes multiple embodiment schemes provided by the embodiments of the present application. The various optional methods introduced in each embodiment scheme can be combined and cross-referenced with each other without conflict, thereby extending a variety of possible embodiment schemes, which can all be considered as embodiment schemes disclosed and open in the embodiments of the present application.

[0152] Although the embodiments of the present application are disclosed above, the present application is not limited thereto. Any person skilled in the art may make various changes and modifications without departing from the spirit and scope of the present application. Therefore, the scope of protection of the present application shall be based on the scope defined by the claims.

Claims

1. A monitoring method, characterized in that: Applied to a register monitor, the method comprises: Obtaining a design path corresponding to a target register and storing the path string in a register monitor, wherein the value of a signal in the design path of the target register is a monitoring object of the register monitor; Calling a waiting update task, wherein the waiting update task is used to register a callback function on a plurality of signals of the design path, and the callback function is automatically called when the value of the signal changes, so as to respond to and process the change of the signal value; When the value of the signal in the design path changes, a callback function is executed to trigger a value change event, where the value change event is used to indicate that the value of the signal in the design path has changed.

2. The monitoring method according to claim 1, wherein: The value change occurrence event is further used to trigger an automatic update task, which automatically updates the mirror value in the register model corresponding to the target register based on the change in the value of the signal.

3. The monitoring method according to claim 1, wherein: The waiting update task includes a waiting for any signal change subtask; the calling of the waiting update task includes calling the waiting for any signal change subtask; The calling of the waiting for any signal change subtask includes: Utilize the waiting for any signal change subtask to receive the path character string; Based on the path character string, calling the DPI task of the waiting for any signal change subtask, wherein the DPI task is the waiting for any signal change subtask in the DPI environment; The DPI task registers callback functions for value change callbacks on a plurality of signals of the design path.

4. The monitoring method according to claim 3, characterized in that The DPI task of calling the waiting for any signal change subtask based on the path character string includes: Convert the path string into a dynamic array; Through DPI, a DPI task of the subtask of waiting for arbitrary signal changes is imported, and the dynamic array and the size of the dynamic array are used as parameters of the DPI task.

5. The monitoring method according to claim 4, characterized in that: The dynamic array indicates a design level signal of each field of the target register, and the design level signal is a signal of the design path; The callback function for registering a value change callback on multiple signals of the design path through the DPI task includes: Based on the size of the dynamic array, the signals indicated by the dynamic array are processed as follows: Get the handle of the signal; Register a callback function on the handle of the signal, and set the callback reason of the callback function to the change of the signal value; The function body of the callback function is set as the value change callback, and the parameter is set as the address of the waiting state. The monitoring method according to claim 5, characterized in that: When the value of the signal in the design path changes, executing the callback function to trigger a value change event includes: When the value of the signal that registers the callback function changes, the callback function is executed; And, based on the wait event triggering task output by register verification, the wait value change event is triggered and the process corresponding to the DPI task is suspended; After the callback function is executed, the value change event is triggered and the process is woken up.

7. The monitoring method according to claim 6, characterized in that: Also includes: After waking up the process, checking whether the wait state is a first value; If so, cancel the callback function registered with the signal; If not, returning to the step of waiting for an event to trigger a task based on register verification output, waiting for a value change event to be triggered, and suspending the process corresponding to the DPI task; When the callback function is executed, the wait state is modified to a first value based on the address of the wait state.

8. The monitoring method according to claim 6, characterized in that: The method further comprises: Through DPI, export the waiting event trigger task to wait for the value change event to be triggered; Through DPI, an event triggering task is exported to trigger the value change event.

9. A monitoring device, characterized in that: Applied to a register monitor, the device comprises: a design path acquisition module, configured to acquire a design path corresponding to a target register and store the acquired design path into a path string of a register monitor, wherein the value of a signal in the design path of the target register is a monitoring object of the register monitor; A waiting update task calling module is used to call a waiting update task, wherein the waiting update task is used to register a callback function on a plurality of signals of the design path, and the callback function is automatically called when the value of the signal changes to respond to and process the change in the value of the signal; The value change event acquisition module is used to execute a callback function to trigger a value change event when the value of the signal in the design path changes. The value change event is used to indicate that the value of the signal in the design path has changed.

10. A verification device, characterized in that: The system comprises at least one memory and at least one processor, wherein the memory stores one or more computer-executable instructions, and the processor calls the one or more computer-executable instructions to execute the monitoring method according to any one of claims 1 to 8.

11. A storage medium, characterized in that: The storage medium stores one or more computer-executable instructions, and when the one or more computer-executable instructions are executed, the monitoring method according to any one of claims 1 to 8 is implemented.

12. A computer program product, characterized in that The method comprises one or more computer executable instructions, and when the one or more computer executable instructions are executed, the monitoring method according to any one of claims 1 to 8 is implemented.

Images