Verification environment process monitoring method and device and electronic equipment
By monitoring the expected end time of the child process in the uvm verification environment and selecting the most recent target end time, the problem of low simulation debugging efficiency caused by child process exceptions is solved, and more efficient simulation debugging is achieved.
Patent Information
- Application Number
- CN202510614894.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-13
- Publication Date
- 2025-08-15
AI Technical Summary
In complex UVM verification environments, child process exceptions lead to low simulation debugging efficiency. The existing technology requires setting time thresholds for the longest child process, resulting in excessive simulation time.
By determining the expected end time of each started child process in the child process queue and selecting the expected end time closest to the current simulation time as the target end time, monitor whether the target child process ends on time and determines whether it is abnormal.
Improve simulation debugging efficiency, avoid setting the maximum time threshold for all subprocesses, and save simulation debugging time.
Smart Images
Figure CN120493824A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of computer technology, and in particular to a process monitoring method, device, electronic device and storage medium for a verification environment. Background Art
[0002] As chip design complexity increases, the complexity of the verification environment also increases exponentially. A complex Universal Verification Methodology (UVM) verification environment includes multiple UVM components. Each UVM component can control the start and end of the main process using the raise_objection (suspend objection) and drop_objection (drop objection) commands within the Phase (simulation phase) mechanism. Each main process may need to schedule multiple subprocesses based on verification requirements. However, during the execution of a subprocess, various exceptions may occur, preventing the subprocess from executing smoothly or returning to the main process. Therefore, the main process cannot be terminated using drop_objection.
[0003] To this end, a common practice is to set a timeout for the main process. This means that when the simulation time of the main process exceeds the configured time threshold, the current main process is terminated, thereby ending the entire simulation task. However, this requires that the time threshold configured for the main process be greater than the simulation time of the longest-running subprocess. This means that even if many subprocesses with relatively short simulation times experience anomalies, it takes a long time to detect and handle the anomalies, significantly reducing the efficiency of simulation debugging. Summary of the Invention
[0004] In view of this, embodiments of the present invention provide a process exception handling method, device, electronic device, and storage medium in a verification environment, which can improve the efficiency of simulation debugging.
[0005] In the first aspect, an embodiment of the present invention provides a process monitoring method for a verification environment, including: determining the expected end time of each started sub-process in the sub-process queue, wherein each of the started sub-processes runs in the verification environment and serves the verification requirements of the main process; from each of the expected end times, selecting an expected end time closest to the current simulation time as the target end time, wherein the started sub-process corresponding to the target end time is the target sub-process; and determining whether an abnormality occurs in the target sub-process based on whether the target sub-process ends when the simulation time reaches the expected end time.
[0006] In one embodiment, the method further includes: in response to the creation of any child process, obtaining configuration parameters of the any child process, the configuration parameters including the expected running time; determining the expected end time of the any child process based on the start time of the any child process and the expected running time; placing the any child process as a started child process into the child process queue to obtain a first update queue, and storing the corresponding relationship between the expected end time and the any child process in a preset statistical library.
[0007] In one embodiment, the preset statistical library includes at least one expected end time, wherein each expected end time corresponds to at least one started sub-process.
[0008] In one embodiment, determining the expected end time of each started sub-process in the sub-process queue includes: determining the expected end time of each started sub-process in the sub-process queue based on the correspondence between the expected end time and the started sub-process stored in the preset statistical library.
[0009] In one embodiment, the number of the sub-process queues is at least one, wherein the expected end time corresponding to each started sub-process in each sub-process queue is the same; the preset statistical library is used to save the corresponding relationship between the expected end time and the sub-process queue; the placing of any sub-process as a started sub-process into the sub-process queue to obtain a first updated queue, and storing the corresponding relationship between the expected end time and any sub-process into the preset statistical library includes: determining whether there is a target queue corresponding to the expected end time in each sub-process queue according to the expected end time of any sub-process; and if the target queue exists, In the case of a target queue, any child process is stored in the target queue, and each child process queue is updated to obtain the first updated queue; the correspondence between the expected end time and any child process is saved in the preset statistical library through the correspondence between the target queue and the expected end time; or, in the case of the non-existence of the target queue, a new child process queue is created and any child process is stored in the newly created child process queue, and each child process queue is updated to obtain the first updated queue; the correspondence between the expected end time of any child process and the newly created child process queue is stored in the preset statistical library.
[0010] In one embodiment, after placing any of the sub-processes as a started sub-process into the sub-process queue to obtain a first update queue, and storing the correspondence between the expected end time and any of the sub-processes into a preset statistical library, the method further includes: using the first update queue as the new sub-process queue, jumping to the step of determining the expected end time of each started sub-process in the sub-process queue and continuing to execute until the simulation ends.
[0011] In one embodiment, the started sub-process is created by a component in the verification environment; the configuration parameters also include the component that creates any of the sub-processes; after determining that an abnormality occurs in the target sub-process, the method also includes: locating the target sub-process based on the configuration parameters and the tree relationship structure between the components in the verification environment.
[0012] In one embodiment, determining whether an exception occurs in the target sub-process based on whether the target sub-process ends when the simulation time reaches the expected end time includes: determining that no exception occurs in the target sub-process if the target sub-process has ended when the simulation time reaches the expected end time, or determining that an exception occurs in the target sub-process if the target sub-process has not ended when the simulation time reaches the expected end time.
[0013] In one embodiment, after determining that an exception occurs in the target sub-process, the method further includes: performing exception handling according to a preset strategy.
[0014] In one embodiment, the preset strategy includes at least one of the following: ignoring the exception, reporting the exception, and stopping the simulation.
[0015] In one embodiment, the exception handling according to the preset strategy includes: when the preset strategy is to ignore the exception or report the exception, deleting the target sub-process from the sub-process queue to obtain a second update queue; using the second update queue as the new sub-process queue, jumping to the step of determining the expected end time of each started sub-process in the sub-process queue and continuing to execute until the simulation ends.
[0016] In one embodiment, after determining that no abnormality occurs in the target sub-process, the method further includes: deleting the target sub-process from the sub-process queue to obtain a third update queue; using the third update queue as the new sub-process queue, jumping to the step of determining the expected end time of each started sub-process in the sub-process queue and continuing to execute until the simulation ends.
[0017] In the second aspect, an embodiment of the present invention also provides a process monitoring device for a verification environment, comprising: a first determination unit, for determining the expected end time of each started sub-process in the sub-process queue, wherein each of the started sub-processes runs in the verification environment and serves the verification requirements of the main process; a selection unit, for selecting an expected end time closest to the current simulation time from each of the expected end times as the target end time, wherein the started sub-process corresponding to the target end time is the target sub-process; a second determination unit, for determining whether an abnormality occurs in the target sub-process based on whether the target sub-process ends when the simulation time reaches the expected end time.
[0018] In one embodiment, the device also includes: an acquisition unit, used to obtain the configuration parameters of any sub-process in response to the creation of any sub-process, and the configuration parameters include the expected running time; a third determination unit, used to determine the expected end time of any sub-process based on the start time of any sub-process and the expected running time; a placement unit, used to place any sub-process as a started sub-process into the sub-process queue, obtain a first update queue, and store the corresponding relationship between the expected end time and any sub-process in a preset statistical library.
[0019] In one embodiment, the preset statistical library includes at least one expected end time, wherein each expected end time corresponds to at least one started sub-process.
[0020] In one embodiment, the first determining unit is specifically configured to determine the expected end time of each started sub-process in the sub-process queue based on the correspondence between the expected end time and the started sub-process stored in the preset statistical library.
[0021] In one embodiment, the number of the sub-process queues is at least one, wherein the expected end time corresponding to each started sub-process in each sub-process queue is the same; the preset statistical library is used to save the corresponding relationship between the expected end time and the sub-process queue; the putting unit is specifically used to: determine whether there is a target queue corresponding to the expected end time in each sub-process queue based on the expected end time of any sub-process; if the target queue exists, store the any sub-process in the target queue, and update each sub-process queue to obtain the first updated queue; save the corresponding relationship between the expected end time and the any sub-process in the preset statistical library through the corresponding relationship between the target queue and the expected end time; or, if the target queue does not exist, create a new sub-process queue and store the any sub-process in the newly created sub-process queue, update each sub-process queue to obtain the first updated queue; store the corresponding relationship between the expected end time of any sub-process and the newly created sub-process queue in the preset statistical library.
[0022] In one embodiment, the device also includes: a first jump unit, which is used to put any of the sub-processes into the sub-process queue as a started sub-process to obtain a first update queue, and store the corresponding relationship between the expected end time and the started sub-process in a preset statistical library, and then use the first update queue as the new sub-process queue to jump to the step of determining the expected end time of each started sub-process in the sub-process queue and continue to execute until the simulation ends.
[0023] In one embodiment, the started sub-process is created by a component in the verification environment; the configuration parameters also include the component that creates any of the sub-processes; the device also includes: a positioning unit, which is used to locate the target sub-process based on the configuration parameters and the tree relationship structure between the components in the verification environment after determining that an abnormality has occurred in the target sub-process.
[0024] In one embodiment, the second determination unit is specifically used to: determine that no abnormality occurs in the target sub-process when the target sub-process has ended when the simulation time reaches the expected end time, or determine that an abnormality occurs in the target sub-process when the target sub-process has not ended when the simulation time reaches the expected end time.
[0025] In one embodiment, the device further includes: an exception handling unit, configured to perform exception handling according to a preset strategy after determining that an exception occurs in the target sub-process.
[0026] In one embodiment, the preset strategy includes at least one of the following: ignoring the exception, reporting the exception, and stopping the simulation.
[0027] In one embodiment, the exception handling unit is specifically used to: when the preset strategy is to ignore the exception or report the exception, delete the target sub-process from the sub-process queue to obtain a second update queue; use the second update queue as the new sub-process queue, jump to the step of determining the expected end time of each started sub-process in the sub-process queue and continue to execute until the simulation ends.
[0028] In one embodiment, the device also includes: a deletion unit, which is used to delete the target sub-process from the sub-process queue after determining that no abnormality occurs in the target sub-process, to obtain a third update queue; a second jump unit, which is also used to use the third update queue as the new sub-process queue, jump to the step of determining the expected end time of each started sub-process in the sub-process queue and continue to execute until the simulation ends.
[0029] In a third aspect, an embodiment of the present invention further provides an electronic device, comprising: a housing, a processor, a memory, a circuit board, and a power supply circuit, wherein the circuit board is placed inside the space enclosed by the housing, and the processor and the memory are arranged on the circuit board; a power supply circuit for supplying power to various circuits or devices of the above-mentioned electronic device; the memory is used to store executable program code; the processor runs a program corresponding to the executable program code by reading the executable program code stored in the memory, and is used to execute the process monitoring method of the verification environment provided by any embodiment of the present invention.
[0030] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium, which stores one or more programs, and the one or more programs can be executed by one or more processors to implement the process monitoring method of the verification environment provided by any embodiment of the present invention.
[0031] The process monitoring method, device, electronic device and storage medium for a verification environment provided by an embodiment of the present invention can determine the expected end time of each started sub-process in the sub-process queue that serves the verification needs of the main process in the verification environment, and select an expected end time closest to the current simulation time from each expected end time as the target end time, wherein the started sub-process corresponding to the target end time is the target sub-process; and determine whether the target sub-process has an abnormality based on whether the target sub-process ends when the simulation time reaches the expected end time. Since it is possible to determine the expected end time of each started sub-process and select the expected end time closest to the current simulation time for monitoring, it is possible to determine whether the sub-process that is about to end ends on time and whether the sub-process that is about to end ends has an exception. As the simulation time goes by, each sub-process has the opportunity to become the sub-process with the expected end time closest to the current simulation time, thereby completing the monitoring of all started sub-processes. In this way, there is no need to set the simulation time of the sub-process that consumes the most time in each sub-process as the time threshold in order to accommodate the possibility of exceptions in all sub-processes in the main process as in the prior art. Therefore, it can effectively save simulation debugging time and improve the efficiency of simulation debugging. BRIEF DESCRIPTION OF THE DRAWINGS
[0032] In order to more clearly illustrate the embodiments of the present invention 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 only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.
[0033] Figure 1 A flow chart of a process monitoring method for a verification environment provided by an embodiment of the present invention; Figure 2 A schematic diagram of a subprocess created in an embodiment of the present invention; Figure 3 A schematic diagram of a preset statistical library in an embodiment of the present invention; Figure 4 A schematic diagram of the architecture of the verification environment in an embodiment of the present invention; Figure 5 A schematic diagram of a component tree structure provided by an embodiment of the present invention; Figure 6 A schematic diagram of a process monitoring method for a verification environment provided by an embodiment of the present invention; Figure 7 A flow chart of a process monitoring method for a verification environment provided by an embodiment of the present invention; Figure 8 A schematic structural diagram of a process monitoring device for a verification environment provided by an embodiment of the present invention; Figure 9 A schematic structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION
[0034] The embodiments of the present invention are described in detail below with reference to the accompanying drawings.
[0035] It should be understood that the embodiments described are only a portion of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by persons of ordinary skill in the art without creative work are within the scope of protection of the present invention.
[0036] In a first aspect, an embodiment of the present invention provides a process monitoring method for a verification environment, which can improve the efficiency of simulation debugging.
[0037] like Figure 1 As shown, an embodiment of the present invention provides a process monitoring method for a verification environment, comprising: S11, determining an expected end time of each started sub-process in the sub-process queue, wherein each of the started sub-processes runs in the verification environment and serves the verification requirements of the main process.
[0038] In this step, the expected end time of each started sub-process in the sub-process queue can be determined. In order to complete specific verification requirements, a main process may need to schedule multiple sub-processes. These sub-processes can be used to sequentially complete a verification task in the main process, or they can be used to concurrently complete a verification task in the main process. In an embodiment of the present invention, each started sub-process can be placed in a sub-process queue and uniformly managed through the sub-process queue. Each started sub-process can have a corresponding expected end time, which is an estimate of the end time of the operation of the started sub-process. The expected end time can be configured according to experience, or it can be flexibly adjusted according to the actual time during the simulation process.
[0039] During specific implementation, the start and end of the main process can be controlled by raise_objection and drop_ojection in the Phase mechanism in the uvm component. In one embodiment, the subprocess is implemented by constructing a process object class. Specifically, the process object class can be derived from uvm_object and inherit the methods of uvm_object, such as the print method. In addition to the methods inherited from uvm_object, in one embodiment of the present invention, the subprocess can also define its own properties, such as start time, expected end time, exception handling method, etc. Furthermore, the subprocess can also provide interface functions for external calls, such as: parameter configuration interface, exception handling interface, status reporting interface, etc.
[0040] S12: Select an expected end time closest to the current simulation time from the expected end times as a target end time, wherein the started sub-process corresponding to the target end time is the target sub-process.
[0041] In this step, the expected end time closest to the current simulation time can be selected as the target end time from the expected end times of each started sub-process in the sub-process queue determined in step S11. By selecting the expected end time closest to the current simulation time, each started sub-process in the sub-process queue can be monitored in descending order. For example, if the end time of sub-process 1 is the expected end time closest to the current simulation time in the sub-process queue, then the expected end time of sub-process 1 is the target end time. The started sub-process corresponding to the target end time is the target sub-process. In this case, sub-process 1 is the target sub-process.
[0042] It should be noted that in embodiments of the present invention, the target subprocess corresponding to the target end time may be a single subprocess or multiple subprocesses with the same expected end time. For example, if process 1 and process 2 have the same end time, and the target end time is the expected end time of subprocess 1 or subprocess 2, the target subprocesses are subprocess 1 and subprocess 2. If the target end time is null, meaning that the simulation of all started subprocesses in the subprocess queue has ended, the simulation ends.
[0043] S13, determining whether an abnormality occurs in the target sub-process according to whether the target sub-process ends when the simulation time reaches the expected end time.
[0044] Since the target end time is an estimate of the end time of the target sub-process, the target end time has a high degree of fit with the actual end time of the target sub-process. Based on this, in this step, the operation of the sub-process can be monitored according to the target end time selected in step S12. Specifically, if the target sub-process ends when the target end time arrives, it means that the operation of the target sub-process meets expectations. If the target sub-process has not ended when the target end time arrives, it means that the operation of the target sub-process does not meet expectations, and it is determined that an abnormality has occurred in the target sub-process.
[0045] The process monitoring method for a verification environment provided by an embodiment of the present invention can determine the expected end time of each started sub-process in the sub-process queue that serves the verification needs of the main process in the verification environment, and select an expected end time closest to the current simulation time from each expected end time as the target end time, wherein the started sub-process corresponding to the target end time is the target sub-process; and determine whether the target sub-process has an abnormality based on whether the target sub-process ends when the simulation time reaches the expected end time. Since it is possible to determine the expected end time of each started sub-process and select the expected end time closest to the current simulation time for monitoring, it is possible to determine whether the sub-process that is about to end ends on time and whether the sub-process that is about to end ends has an exception. As the simulation time goes by, each sub-process has the opportunity to become the sub-process with the expected end time closest to the current simulation time, thereby completing the monitoring of all started sub-processes. In this way, there is no need to set the simulation time of the sub-process that consumes the most time in each sub-process as the time threshold in order to accommodate the possibility of exceptions in all sub-processes in the main process as in the prior art. Therefore, it can effectively save simulation debugging time and improve the efficiency of simulation debugging.
[0046] Specifically, each sub-process can be created and run according to the verification requirements of the main process, and accordingly, the sub-process queue can also be updated as the sub-process is created and run. In one embodiment of the present invention, the process monitoring method provided by the embodiment of the present invention may also include: in response to the creation of any sub-process, obtaining the configuration parameters of any sub-process, the configuration parameters including the expected running time; determining the expected end time of any sub-process based on the start time of any sub-process and the expected running time; placing any sub-process into the sub-process queue as a started sub-process to obtain a first update queue, and storing the corresponding relationship between the expected end time and any sub-process into a preset statistical library. In this embodiment, after the sub-process is created, it is added to the sub-process queue as a started sub-process. In this way, all started sub-processes of the main process can be included in unified management. Once the simulation ends abnormally, the abnormal sub-process can be determined, thereby improving the efficiency of simulation debugging.
[0047] At the start of a simulation, the subprocess queue is empty, allowing a subprocess to be created. In response to the creation of any subprocess, the configuration parameters of that subprocess are first obtained. The configuration parameters of any subprocess may include an expected runtime. In embodiments of the present invention, the expected runtime may be the time required for the subprocess simulation. In specific implementations, the expected runtime of a subprocess can be configured to a relatively large value based on experience during the first simulation. This value can be flexibly adjusted in subsequent simulations based on the actual simulation time.
[0048] After obtaining the expected runtime of any subprocess, in one embodiment of the present invention, the expected end time of any subprocess can be determined based on the start time and expected runtime of any subprocess. For example, the expected end time of the subprocess can be determined by adding the start time of the subprocess to the expected runtime. In another example, the subprocess can set a simulation start time, and the expected end time of the subprocess can be determined by adding the simulation start time to the expected runtime.
[0049] After creating a child process, the child process can be placed in a child process queue as a started child process, resulting in a first update queue. The correspondence between the expected end time and the started child process is stored in a preset statistical library. The preset statistical library records the correspondence between started child processes and expected end times. Thus, when the target end time expires, the target child process corresponding to the target end time can be queried through the preset statistical library. The specific form of the preset statistical library is not limited. For example, in one example, the preset statistical library can be an array, while in another example, the preset statistical library can be a set.
[0050] In one embodiment, the preset statistical library includes at least one expected end time, wherein each expected end time corresponds to at least one started sub-process. In a specific implementation, one expected end time generally corresponds to one started sub-process. If two started sub-processes have the same expected end time, then this expected end time will correspond to two started sub-processes. For example, if sub-process 1 and sub-process 2 have the same expected end time, then in the preset statistical library, this expected end time will correspond to two started sub-processes: sub-process 1 and sub-process 2.
[0051] In embodiments of the present invention, the expected end time can be used as a data index. That is, subprocesses with the same expected end time use the same expected end time, which corresponds to multiple started subprocesses with the same expected end time. This ensures the uniqueness of the expected end time in the subprocess queue, thereby accelerating execution and further improving the efficiency of simulation debugging.
[0052] In one embodiment, determining the expected end time of each started sub-process in the sub-process queue includes determining the expected end time of each started sub-process in the sub-process queue based on a correspondence between the expected end time and the started sub-process stored in the preset statistical library. For example, the preset statistical library stores a correspondence between started sub-processes and expected end times, and thus, the expected end time of each started sub-process in the sub-process queue can be determined based on this correspondence.
[0053] In one embodiment, the expected end time of the started sub-process is equal to the start time of the started sub-process plus the expected runtime of the started sub-process. In one example, the expected runtime can be scaled using a modulation parameter, and the expected end time of the started sub-process is determined based on the scaled expected runtime. For example, when the modulation parameter is greater than 1, the expected runtime of the sub-process is increased by the modulation parameter ratio; when the modulation parameter is less than 1, the expected runtime of the sub-process is decreased by the modulation parameter ratio. Using the modulation factor increases the flexibility of setting the expected end time of the sub-process, thereby improving the efficiency of simulation debugging.
[0054] In one embodiment, the number of the sub-process queues is at least one, wherein the expected end time corresponding to each started sub-process in each sub-process queue is the same; the preset statistical library is used to save the corresponding relationship between the expected end time and the sub-process queue; the placing of any sub-process as a started sub-process into the sub-process queue to obtain a first updated queue, and storing the corresponding relationship between the expected end time and any sub-process into the preset statistical library includes: determining whether there is a target queue corresponding to the expected end time in each sub-process queue according to the expected end time of any sub-process; and if the target queue exists, In the case of a target queue, any child process is stored in the target queue, and each child process queue is updated to obtain the first updated queue; the correspondence between the expected end time and any child process is saved in the preset statistical library through the correspondence between the target queue and the expected end time; or, in the case of the non-existence of the target queue, a new child process queue is created and any child process is stored in the newly created child process queue, and each child process queue is updated to obtain the first updated queue; the correspondence between the expected end time of any child process and the newly created child process queue is stored in the preset statistical library.
[0055] In this embodiment, processing is performed based on whether there is a target queue classification corresponding to the expected end time in the sub-process queue: if so, any sub-process is stored in the target queue, and each sub-process queue is updated to obtain the first update queue; the correspondence between the expected end time and any sub-process is saved in the preset statistical library through the correspondence between the target queue and the expected end time; if not, a new sub-process queue is created and any sub-process is stored in the newly created sub-process queue, and each sub-process queue is updated to obtain the first update queue; the correspondence between the expected end time of any sub-process and the newly created sub-process queue is stored in the preset statistical library.
[0056] For example, if Figure 2As shown, when a new child process 1 is started, a child process 1 object instance is first created, its internal parameters are configured, and the expected end time of child process 1 (endtime1 = $time + guard_time) is calculated based on the current simulation time ($time) and the configured guard time (guard_time). A check is then performed to determine whether the expected end time endtime1 exists in the preset statistical library. If the expected end time does not exist, a new child process queue is created and child process 1 is stored in the newly created child process queue. Each of the newly created child process queues is then updated to generate the first updated queue. The corresponding relationship between the expected end time endtime1 of child process 1 and the newly created child process queue is stored in the preset statistical library.
[0057] When sub-process 2 is started, a sub-process 2 object will also be created and the corresponding parameters will be configured. If the end time of process 2 is different from that of sub-process 1, a new sub-process queue will be created and sub-process 2 will be stored in the newly created sub-process queue, and each sub-process queue will be updated; the corresponding relationship between the expected end time endtime2 of sub-process 2 and the newly created sub-process queue will be stored in the preset statistical library. If the expected end time of sub-process 2 is equal to that of sub-process 1, sub-process 2 will be added to the sub-process queue containing sub-process 1, and each sub-process queue will be updated. Specifically, if Figure 3 As shown in the figure, when the end time of sub-process 1 and sub-process 2 is different, there will be two sub-process queues. When the end time of process 1 and process 2 is the same, there is a sub-process queue class with two processes in the sub-process queue, namely sub-process 1 and sub-process 2.
[0058] In one embodiment, after placing any of the sub-processes as a started sub-process into the sub-process queue to obtain a first update queue, and storing the corresponding relationship between the expected end time and any of the sub-processes in a preset statistical library, the method further includes: using the first update queue as the new sub-process queue, jumping to the step of determining the expected end time of each started sub-process in the sub-process queue and continuing to execute until the simulation ends. For example, when the newly created sub-process 3 is added to the sub-process queue, a first update queue is obtained, that is, the first update queue newly adds the started sub-process 3 on the basis of the atomic process queue. At the same time, after storing the corresponding relationship between the expected end time of sub-process 3 in the preset statistical library, it is managed as a new sub-process queue according to the first update queue, and the process jumps to step S11 to continue.
[0059] In one embodiment, the started sub-process is created by a component in the verification environment; the configuration parameters also include the component that creates any of the sub-processes; after determining that an abnormality occurs in the target sub-process, the method also includes: locating the target sub-process based on the configuration parameters and the tree relationship structure between the components in the verification environment.
[0060] In specific implementation, Figure 4 As shown in the figure, a process management component instance can be created in the uvm_env environment through the singleton mode. This instance can be obtained by other verification components in the verification environment. During simulation, each verification component can operate on the process management component instance. After the child process is started, the child process is added to the child process queue managed by the process management component instance for monitoring and error reporting. Because the uvm component has its own tree structure in the environment, the processes created in the component are also in the tree structure, as shown in the figure. Figure 5 As shown, when the process is abnormal, the location of the current process can be reported through the tree structure of UVM. In the embodiment provided by the present invention, the location of the sub-process can be located by verifying the tree relationship structure of the components in the environment, thereby saving positioning time and effectively improving simulation debugging efficiency.
[0061] In an embodiment of the present invention, a cyclic timer can be set to manage the expected end time of each started subprocess in the subprocess queue. This cyclic timer has two trigger conditions to start a new round of timer: when a new subprocess is started, and when the timer reaches the target end time. Once either of these conditions is met, the timer clears the timed-out processes in the current queue and then selects the expected end time closest to the current simulation time from the subprocess queue as the target end time, starting a new round of timer. This cycle continues until the simulation ends.
[0062] In one embodiment, determining whether an exception has occurred in the target sub-process based on whether the target sub-process has ended when the simulation time reaches the expected end time includes: determining that no exception has occurred in the target sub-process if the target sub-process has already ended when the simulation time reaches the expected end time, or determining that an exception has occurred in the target sub-process if the target sub-process has not yet ended when the simulation time reaches the expected end time. Specifically, for example, if the target sub-process has ended when the target end time endtime3 arrives, then no exception has occurred in the target sub-process; if the target sub-process has not yet ended, then it is determined that an exception has occurred in the target sub-process.
[0063] In one embodiment, after determining that an exception has occurred in the target subprocess, the method further includes: performing exception handling according to a preset policy. For example, if subprocess 2 has not yet terminated after the target end time has been reached, the timer is exited, the expected end time corresponding to subprocess 2 is deleted from the associative array, and the exception is handled and reported according to the exception handling method for subprocess 2. If the exception handling method for subprocess 2 is simulation termination, the simulation is terminated; otherwise, after reporting the error, the target end time is selected for monitoring.
[0064] In one embodiment, the preset policy includes at least one of the following: ignoring exceptions, reporting exceptions, and stopping simulation. In a specific embodiment provided by the present invention, the preset policy can flexibly configure the handling method of abnormal processes, thereby improving the efficiency of simulation debugging by debugging multiple process problems through error reporting in the early stages of verification environment debugging. In a specific implementation, the preset policy can use enumeration variables, such as ignoring exceptions, reporting errors, exiting simulation, etc., and perform different exception handling through the preset policy.
[0065] For example, if the parameter is to ignore exceptions, the target end time is selected from the sub-process queue and monitoring is restarted.
[0066] For example, if the exception handling method parameter is to report an error, the target sub-process information is reported, and the target end time is selected from the sub-process queue to restart monitoring.
[0067] For example, if the exception handling method parameter is to exit the simulation, the target sub-process information is reported, the sub-process queue is cleared, and the simulation ends.
[0068] In one embodiment, the exception handling according to the preset strategy includes: when the preset strategy is to ignore the exception or report the exception, deleting the target sub-process from the sub-process queue to obtain a second update queue; using the second update queue as the new sub-process queue, jumping to the step of determining the expected end time of each started sub-process in the sub-process queue and continuing to execute until the simulation ends. For example, when sub-process 5 encounters an exception, sub-process 5 is deleted from the sub-process queue to obtain a second update queue, that is, the started sub-process 4 is deleted from the second update queue, and the second update queue is managed as the new sub-process queue, and jumping to step S11 to continue executing until the simulation ends. For another example: after the started sub-process 4 is deleted from the second update queue, the started sub-process queue is empty, and the simulation ends.
[0069] In one embodiment, after determining that no abnormality has occurred in the target sub-process, the method further includes: deleting the target sub-process from the sub-process queue to obtain a third update queue; using the third update queue as the new sub-process queue, jumping to the step of determining the expected end time of each started sub-process in the sub-process queue and continuing to execute until the simulation ends. For example, when no abnormality has occurred in sub-process 6, sub-process 6 is deleted from the sub-process queue to obtain a third update queue, that is, the started sub-process 6 is deleted from the third update queue, and the third update queue is managed as a new sub-process queue, and jumping to step S11 to continue executing until the simulation ends. For another example: after the started sub-process 6 is deleted from the third update queue, if the started sub-process queue is empty, the simulation ends.
[0070] For example, Figure 6 As shown, in one embodiment, a process object module and a process management module can be constructed.
[0071] The process object module can define its own properties for a subprocess, such as process start time, process end time, and process exception handling method (enumeration type: ignore, end simulation, exception report). Furthermore, the process object module also provides interface functions, including but not limited to: configuration parameter interface, exception handling interface, and status reporting interface.
[0072] The process management module internally maintains an associative array of sub-process queues and uses the sub-process end time as a data index to perform process management: adding new processes and clearing timed-out processes. Specifically, the process management module contains a daemon process, which is a cyclic timer. The timer selects the expected end time closest to the current simulation time from the current process queue as the daemon time, and clears timed-out processes from the process queue based on the simulation situation, handles abnormal processes, and reports the status of abnormal processes. For example, the process management module schedules the exception handling interface in the process object module to handle abnormal processes based on the process's exception handling method. For another example, after completing exception handling, the process management module reports the status information of all current abnormal processes. After the current daemon time expires, the timer selects the expected end time closest to the current simulation time from the process queue as the daemon time and starts a new round of timing. This cycle continues until the simulation ends. The process monitoring method for a verification environment provided by an embodiment of the present invention is described in detail below through a specific example.
[0073] like Figure 7 As shown, the process monitoring method of the verification environment provided by the embodiment of the present invention may include: S401, in response to creation of any child process, obtaining configuration parameters of the child process, the configuration parameters including expected running time; Each of the started sub-processes runs in the verification environment and serves the verification requirements of the main process.
[0074] Optionally, the started sub-process is created by a component in the verification environment; the configuration parameters also include the component that creates any of the sub-processes.
[0075] S402: Determine an expected end time of any sub-process according to the start time of any sub-process and the expected running time.
[0076] S403: Determine, based on the expected end time of any of the sub-processes, whether there is a target queue corresponding to the expected end time in each of the sub-process queues.
[0077] S404, when the target queue exists, storing any child process into the target queue, and updating each child process queue to obtain the first update queue; saving the correspondence between the expected end time and any child process in the preset statistical library through the correspondence between the target queue and the expected end time; or, when the target queue does not exist, creating a new child process queue and storing any child process into the newly created child process queue, updating each child process queue to obtain the first update queue; storing the correspondence between the expected end time of any child process and the newly created child process queue in the preset statistical library.
[0078] Optionally, the preset statistical library includes at least one expected end time, wherein each expected end time corresponds to at least one started sub-process.
[0079] The first update queue is used as the new sub-process queue and execution continues.
[0080] S405: Determine the expected end time of each started sub-process in the sub-process queue.
[0081] S406, selecting an expected end time closest to the current simulation time from the expected end times as the target end time; The started sub-process corresponding to the target end time is the target sub-process.
[0082] S407 , determining whether an abnormality occurs in the target sub-process based on whether the target sub-process ends when the simulation time reaches the expected end time.
[0083] S408, when the preset policy is to ignore the exception or report the exception, deleting the target child process from the child process queue to obtain a second update queue; S409: Locate the target sub-process according to the configuration parameters and the tree relationship structure between the components in the verification environment.
[0084] The second update queue is used as the new sub-process queue, and the process jumps to step S405 and continues to execute until the simulation ends.
[0085] In a second aspect, an embodiment of the present invention further provides a process monitoring device for a verification environment, which can improve the efficiency of simulation debugging.
[0086] like Figure 8 As shown, an embodiment of the present invention provides a process monitoring device for a verification environment, comprising: A first determining unit 61 is configured to determine an expected end time of each started sub-process in the sub-process queue, wherein each of the started sub-processes runs in the verification environment and serves the verification requirements of the main process; A selection unit 62 is configured to select an expected end time closest to the current simulation time from the expected end times as a target end time, wherein the started sub-process corresponding to the target end time is the target sub-process; The second determining unit 63 is configured to determine whether an abnormality occurs in the target sub-process according to whether the target sub-process ends when the simulation time reaches the expected end time.
[0087] The process monitoring device for a verification environment provided by an embodiment of the present invention can determine the expected end time of each started sub-process in the sub-process queue that serves the verification needs of the main process in the verification environment, and select an expected end time closest to the current simulation time from each expected end time as the target end time, wherein the started sub-process corresponding to the target end time is the target sub-process; and determine whether the target sub-process has an abnormality based on whether the target sub-process ends when the simulation time reaches the expected end time. Since it is possible to determine the expected end time of each started sub-process and select the expected end time closest to the current simulation time for monitoring, it is possible to determine whether the sub-process that is about to end ends on time and whether the sub-process that is about to end ends has an exception. As the simulation time goes by, each sub-process has the opportunity to become the sub-process with the expected end time closest to the current simulation time, thereby completing the monitoring of all started sub-processes. In this way, there is no need to set the simulation time of the sub-process that consumes the most time in each sub-process as the time threshold in order to accommodate the possibility of exceptions in all sub-processes in the main process as in the prior art. Therefore, it can effectively save simulation debugging time and improve the efficiency of simulation debugging.
[0088] In one embodiment, the device also includes: an acquisition unit, used to obtain the configuration parameters of any sub-process in response to the creation of any sub-process, and the configuration parameters include the expected running time; a third determination unit, used to determine the expected end time of any sub-process based on the start time of any sub-process and the expected running time; a placement unit, used to place any sub-process as a started sub-process into the sub-process queue, obtain a first update queue, and store the corresponding relationship between the expected end time and any sub-process in a preset statistical library.
[0089] In one embodiment, the preset statistical library includes at least one expected end time, wherein each expected end time corresponds to at least one started sub-process.
[0090] In one embodiment, the first determining unit 61 is specifically configured to determine the expected end time of each started sub-process in the sub-process queue based on the correspondence between the expected end time and the started sub-process stored in the preset statistical library.
[0091] In one embodiment, the number of the sub-process queues is at least one, wherein the expected end time corresponding to each started sub-process in each sub-process queue is the same; the preset statistical library is used to save the corresponding relationship between the expected end time and the sub-process queue; the putting unit is specifically used to: determine whether there is a target queue corresponding to the expected end time in each sub-process queue based on the expected end time of any sub-process; if the target queue exists, store the any sub-process in the target queue, and update each sub-process queue to obtain the first updated queue; save the corresponding relationship between the expected end time and the any sub-process in the preset statistical library through the corresponding relationship between the target queue and the expected end time; or, if the target queue does not exist, create a new sub-process queue and store the any sub-process in the newly created sub-process queue, update each sub-process queue to obtain the first updated queue; store the corresponding relationship between the expected end time of any sub-process and the newly created sub-process queue in the preset statistical library.
[0092] In one embodiment, the device also includes: a first jump unit, which is used to put any of the sub-processes into the sub-process queue as a started sub-process to obtain a first update queue, and store the corresponding relationship between the expected end time and the started sub-process in a preset statistical library, and then use the first update queue as the new sub-process queue to jump to the step of determining the expected end time of each started sub-process in the sub-process queue and continue to execute until the simulation ends.
[0093] In one embodiment, the started sub-process is created by a component in the verification environment; the configuration parameters also include the component that creates any of the sub-processes; the device also includes: a positioning unit, which is used to locate the target sub-process based on the configuration parameters and the tree relationship structure between the components in the verification environment after determining that an abnormality has occurred in the target sub-process.
[0094] In one embodiment, the second determination unit 63 is specifically used to: determine that no abnormality occurs in the target sub-process when the target sub-process has ended when the simulation time reaches the expected end time, or determine that an abnormality occurs in the target sub-process when the simulation time reaches the expected end time when the target sub-process has not ended.
[0095] In one embodiment, the device further includes: an exception handling unit, configured to perform exception handling according to a preset strategy after determining that an exception occurs in the target sub-process.
[0096] In one embodiment, the preset strategy includes at least one of the following: ignoring the exception, reporting the exception, and stopping the simulation.
[0097] In one embodiment, the exception handling unit is specifically used to: when the preset strategy is to ignore the exception or report the exception, delete the target sub-process from the sub-process queue to obtain a second update queue; use the second update queue as the new sub-process queue, jump to the step of determining the expected end time of each started sub-process in the sub-process queue and continue to execute until the simulation ends.
[0098] In one embodiment, the device also includes: a deletion unit, which is used to delete the target sub-process from the sub-process queue after determining that no abnormality occurs in the target sub-process, to obtain a third update queue; a second jump unit, which is also used to use the third update queue as the new sub-process queue, jump to the step of determining the expected end time of each started sub-process in the sub-process queue and continue to execute until the simulation ends.
[0099] In a third aspect, an embodiment of the present invention further provides an electronic device capable of improving the efficiency of simulation debugging.
[0100] like Figure 9 As shown, the electronic device provided by an embodiment of the present invention may include: a shell 71, a processor 72, a memory 73, a circuit board 74 and a power supply circuit 75, wherein the circuit board 74 is placed inside the space enclosed by the shell 71, and the processor 72 and the memory 73 are arranged on the circuit board 74; the power supply circuit 75 is used to supply power to various circuits or devices of the above-mentioned electronic device; the memory 73 is used to store executable program code; the processor 72 runs the program corresponding to the executable program code by reading the executable program code stored in the memory 73, so as to execute the process monitoring method of the verification environment provided by any of the aforementioned embodiments.
[0101] The specific execution process of the above steps by the processor 72 and the steps further executed by the processor 72 by running the executable program code can be found in the description of the above embodiment and will not be repeated here.
[0102] In the fourth aspect, an embodiment of the present invention also provides a computer-readable storage medium, which stores one or more programs. The one or more programs can be executed by one or more processors to implement the process monitoring method of any verification environment provided by the aforementioned embodiments, thereby also achieving the corresponding technical effects, which have been described in detail above and will not be repeated here.
[0103] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply the existence of any such actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element.
[0104] Each embodiment in this specification is described in a related manner. The same or similar parts between the embodiments can be referred to each other. Each embodiment focuses on the differences from other embodiments.
[0105] In particular, for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.
[0106] For the convenience of description, the above device is described as being divided into various units / modules based on their functions. Of course, when implementing the present invention, the functions of each unit / module can be implemented in the same or multiple software and / or hardware.
[0107] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing the relevant hardware through a computer program. The program can be stored in a computer-readable storage medium, and when executed, the program can include the processes in the above-described method embodiments. The storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).
[0108] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in the present invention should be included in the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.
Claims
1. A process monitoring method for a verification environment, characterized in that: include: Determining an expected end time of each started sub-process in the sub-process queue, wherein each of the started sub-processes runs in the verification environment and serves the verification requirements of the main process; From the expected end times, select the expected end time closest to the current simulation time as the target end time, wherein the started sub-process corresponding to the target end time is the target sub-process; Whether an abnormality occurs in the target sub-process is determined based on whether the target sub-process ends when the simulation time reaches the expected end time.
2. The method according to claim 1, characterized in that The method further comprises: In response to creation of any child process, obtaining configuration parameters of the any child process, the configuration parameters including expected running time; Determining an expected end time of any sub-process according to the start time of any sub-process and the expected running time; The any sub-process is placed into the sub-process queue as a started sub-process to obtain a first update queue, and the corresponding relationship between the expected end time and the any sub-process is stored in a preset statistical library.
3. The method according to claim 2, characterized in that The preset statistical library includes at least one expected end time, wherein each expected end time corresponds to at least one started sub-process.
4. The method according to claim 2, characterized in that Determining the expected end time of each started sub-process in the sub-process queue includes: Based on the corresponding relationship between the expected end time and the started sub-process stored in the preset statistical library, the expected end time of each started sub-process in the sub-process queue is determined.
5. The method according to claim 2, characterized in that The number of the sub-process queues is at least one, wherein the expected end time corresponding to each started sub-process in each sub-process queue is the same; the preset statistical library is used to store the corresponding relationship between the expected end time and the sub-process queue; The step of placing any one of the sub-processes as a started sub-process into the sub-process queue to obtain a first update queue, and storing the corresponding relationship between the expected end time and any one of the sub-processes into a preset statistical library includes: Determining, based on the expected end time of any of the sub-processes, whether there is a target queue corresponding to the expected end time in each of the sub-process queues; If the target queue exists, storing any of the child processes in the target queue and updating each of the child process queues to obtain the first updated queue; and saving the corresponding relationship between the expected end time and any of the child processes in the preset statistical library through the corresponding relationship between the target queue and the expected end time; Alternatively, if the target queue does not exist, a new child process queue is created and any of the child processes is stored in the newly created child process queue, each of the child process queues is updated to obtain the first updated queue; the correspondence between the expected end time of any of the child processes and the newly created child process queue is stored in a preset statistical library.
6. The method according to claim 2, characterized in that After placing any of the subprocesses as a started subprocess into the subprocess queue to obtain a first update queue, and storing the corresponding relationship between the expected end time and any of the subprocesses into a preset statistical library, the method further includes: The first update queue is used as the new sub-process queue, and the process jumps to the step of determining the expected end time of each started sub-process in the sub-process queue and continues to execute until the simulation ends.
7. The method according to claim 2, characterized in that The started sub-process is created by a component in the verification environment; the configuration parameters also include the component that created any of the sub-processes; After determining that the target subprocess is abnormal, the method further includes: The target sub-process is located according to the configuration parameters and the tree relationship structure between the components in the verification environment.
8. The method according to claim 1, characterized in that The determining whether an abnormality occurs in the target sub-process according to whether the target sub-process ends when the simulation time reaches the expected end time includes: When the target sub-process has ended when the simulation time reaches the expected end time, it is determined that no abnormality has occurred in the target sub-process; or, when the target sub-process has not ended when the simulation time reaches the expected end time, it is determined that an abnormality has occurred in the target sub-process.
9. The method according to claim 8, characterized in that After determining that the target subprocess is abnormal, the method further includes: Handle exceptions according to preset strategies.
10. The method according to claim 9, characterized in that The preset strategy includes at least one of the following: ignoring the exception, reporting the exception, and stopping the simulation.
11. The method according to claim 10, characterized in that The exception handling according to the preset strategy includes: When the preset policy is to ignore the exception or report the exception, deleting the target child process from the child process queue to obtain a second update queue; The second update queue is used as the new sub-process queue, and the process jumps to the step of determining the expected end time of each started sub-process in the sub-process queue and continues until the simulation ends.
12. The method according to claim 8, characterized in that After determining that no abnormality occurs in the target subprocess, the method further includes: Deleting the target subprocess from the subprocess queue to obtain a third update queue; The third update queue is used as the new sub-process queue, and the step of determining the expected end time of each started sub-process in the sub-process queue is skipped and continued until the simulation ends.
13. A process monitoring device for a verification environment, characterized in that: include: a first determining unit, configured to determine an expected end time of each started sub-process in the sub-process queue, wherein each of the started sub-processes runs in the verification environment and serves the verification requirements of the main process; A selection unit is configured to select an expected end time closest to the current simulation time from the expected end times as a target end time, wherein the started sub-process corresponding to the target end time is the target sub-process; The second determining unit is configured to determine whether an abnormality occurs in the target sub-process according to whether the target sub-process ends when the simulation time reaches the expected end time.
14. An electronic device, characterized in that: The electronic device includes: a housing, a processor, a memory, a circuit board and a power supply circuit, wherein the circuit board is placed inside the space enclosed by the housing, and the processor and the memory are arranged on the circuit board; the power supply circuit is used to supply power to various circuits or devices of the above-mentioned electronic device; the memory is used to store executable program code; the processor runs the program corresponding to the executable program code by reading the executable program code stored in the memory, so as to execute the process monitoring method described in any one of claims 1 to 12.
15. A computer-readable storage medium, characterized in that The computer-readable storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the process monitoring method according to any one of claims 1 to 12.