CN117370168B

CN117370168B - Method for setting simulation restoration point of logic system design and related equipment

Info

Publication number: CN117370168B
Application number: CN202311277508.1A
Authority: CN
Inventors: 黄世杰
Original assignee: Core Huazhang Technology Xiamen Co ltd
Current assignee: Core Huazhang Technology Xiamen Co ltd
Priority date: 2023-09-28
Filing date: 2023-09-28
Publication date: 2024-10-15
Anticipated expiration: 2043-09-28
Also published as: CN117370168A

Abstract

The application provides a method for setting a simulation restore point of a logic system design and related equipment. The method comprises the following steps: simulating a reference logic system design to obtain a reference log file; simulating a target logic system design to obtain a target log file, the target logic system design being modified based on the reference logic system design; comparing the reference log file with the target log file to locate suspicious points of the target logical system design; determining one or more simulation moments associated with the suspicious points according to the suspicious points; and re-simulating the target logic system design to respectively save one or more return points at one or more simulation moments associated with the suspicious points.

Description

Method for setting simulation restoration point of logic system design and related equipment

Technical Field

The present application relates to the field of computer software technologies, and in particular, to a method for setting a simulation restore point of a logic system design and related devices.

Background

In conducting a test of a logic system design (e.g., a chip design), different stimulus signals are typically applied to the logic system design over time, and the output signal of the logic system design is observed for changes over time (e.g., waveforms). The problem of the design can be found by the variation of the output signal and the design can be modified.

To better implement debugging of a logic system design, engineers typically need to repeatedly restore the test to a particular point in time (also referred to as a restore point) to observe the input signal and the output signal at that point in time, thereby performing debugging of the logic system design. This means that the testing of the logic system design needs to be able to quickly restore the test at the point in time specified by the engineer, including the values of the input signal, the output signal, and the signals inside the design at that point in time.

For quick restoration testing, it is conventional practice to artificially save a large amount of test information designed for a logic system at different points in time as a restoration point. The restore point may enable the simulation tool to restore the simulation at the corresponding time according to the saved test information. In this way, the corresponding restore point is loaded according to the specified point in time to be observed by the engineer, and the simulation is continued from the restore point until the specified point in time. Therefore, if the restore point is improperly set, the user may need to wait repeatedly during the simulation time from the restore point to the specified point in time, reducing the user's debugging efficiency.

Therefore, how to more precisely set the simulation restore point in the logic system design to be closer to the specified point in time to be observed by the user is a problem to be solved.

Disclosure of Invention

In view of the above, the present application is directed to a method and related device for setting a simulation restore point of a logic system design, which are used for solving or partially solving the above-mentioned technical problems.

In a first aspect of the present application, a method for setting a simulated restore point of a logic system design is provided, comprising: simulating a reference logic system design to obtain a reference log file; simulating a target logic system design to obtain a target log file, the target logic system design being modified based on the reference logic system design; comparing the reference log file with the target log file to locate suspicious points of the target logical system design; determining one or more simulation moments associated with the suspicious points according to the suspicious points; and re-simulating the target logic system design to respectively save one or more return points at one or more simulation moments associated with the suspicious points.

In a second aspect of the present application, there is provided an electronic apparatus comprising: a memory for storing a set of instructions; and at least one processor configured to execute the set of instructions to perform the method of the first aspect.

In a third aspect of the application, a non-transitory computer readable storage medium is provided, the non-transitory computer readable storage medium storing a set of instructions of an electronic device for causing the electronic device to perform the method of the first aspect.

According to the method and the related equipment for setting the simulation return point of the logic system design, provided by the embodiment of the application, the suspicious point is searched in the process of obtaining the simulation of the logic system design by comparing the log files, and the return point is set nearby the suspicious point. The designated point in time to be observed by the engineer is a suspicious point, and the time distance between the reset point thus set and the designated point in time (i.e., suspicious point) is short, even 0. The application has the advantages that the accurately set return point greatly shortens the simulation time from the return point to the appointed time point (namely, the suspicious point), so that the user can more quickly and efficiently complete the test analysis of the appointed time point, more accurately and quickly find out the fault position to modify, and improve the test efficiency.

Drawings

In order to more clearly illustrate the technical solutions of the present application or related art, the drawings that are required to be used in the description of the embodiments or related art will be briefly described below, and it is apparent that the drawings in the following description are only embodiments of the present application, and other drawings may be obtained according to the drawings without inventive effort to those of ordinary skill in the art.

Fig. 1 is a schematic structural diagram of an exemplary electronic device according to an embodiment of the present application.

FIG. 2 is a schematic diagram of a simulation tool and a debug tool according to an embodiment of the present application.

Fig. 3 is a schematic diagram of a process of generating a log file according to an embodiment of the present application.

FIG. 4 is a schematic diagram of a method for determining suspicious points in a logical system design according to an embodiment of the present application.

FIG. 5 is a schematic diagram of yet another method for determining suspicious points in a logical system design according to embodiments of the present application.

FIG. 6 is a schematic diagram of yet another method for determining suspicious points in a logical system design according to embodiments of the present application.

FIG. 7 is a schematic diagram of a logic system design according to an embodiment of the present application to save restore points during simulation.

FIG. 8 is a schematic diagram of another embodiment of a logic system design for maintaining restore points during simulation.

FIG. 9 is a flow chart of an exemplary method for setting a simulated restore point for a logic system design according to an embodiment of the present application.

Detailed Description

The present application will be further described in detail below with reference to specific embodiments and with reference to the accompanying drawings, in order to make the objects, technical solutions and advantages of the present application more apparent.

It should be noted that unless otherwise defined, technical or scientific terms used in the embodiments of the present application should be given the ordinary meaning as understood by one of ordinary skill in the art to which the present application belongs. The terms "first," "second," and the like, as used in embodiments of the present application, do not denote any order, quantity, or importance, but rather are used to distinguish one element from another. The word "comprising" or "comprises", and the like, means that elements or items preceding the word are included in the element or item listed after the word and equivalents thereof, but does not exclude other elements or items. The terms "connected" or "connected," and the like, are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect.

The simulating the logic system design may be simulating the logic system design on an electronic device running a simulation tool. In some embodiments, the logic system design may include one or more simulation events during the simulation process. These simulation events may be divided by time or by code segments of the design. The logic System design (e.g., chip design) may be written in a software programming language (e.g., java, javaScript, C, C++ or PHP (Hypertext Preprocessor)) or in a hardware programming language (e.g., verilog, VHDL, system C or System Verilog).

In the process of simulating a logical system design, a user typically analyzes phenomena and causes of errors at the point of time when the failures occur.

For some faults caused by potential problems, the source of the problem cannot be found at the time point of the fault. The simulation is returned to a certain time point before the time point by using the time backtracking test, so that a user can analyze and find the origin of the problem at the previous time point, and further effectively perform fault backtracking and solve the fault. In theory, the time backtracking test can return to any time point of the test for the backtracking test.

In the simulation process of the logic system design, for example, the simulation may be started from a zero time point of the logic system design, and the simulation process of the whole logic system design may be divided into a plurality of unit time periods. When the simulation is carried out to the middle time point corresponding to the unit time period, the simulation information corresponding to the middle time point is recorded. The simulation information includes values of key signals (also called primary signals, english name PRIMARY SIGNALS) and simulated environmental parameters. This point in time at which the simulation information is saved is also referred to as the restore point. Thus, the simulation tool may begin simulation at a return point near the specified point in time, allowing the user to quickly return from the return point to the user-specified point in time for simulation.

In the debugging process of the traditional logic system design, the setting of the restore point is fuzzy, so that the proper restore point cannot be accurately found near each user-specified time point. The time from the nearest return point simulation near the appointed time point to the appointed time point of the user is too long, the user needs to wait all the time, test analysis cannot be effectively performed, and the debugging efficiency of the user is reduced.

In view of the above, the present application provides a method, an electronic device and a storage medium for setting a simulation restore point of a logic system design.

Fig. 1 is a schematic structural diagram of an exemplary electronic device 100 according to an embodiment of the present application.

As shown in fig. 1, the electronic device 100 may include: processor 102, memory 104, network interface 106, peripheral interface 108, and bus 110. Wherein the processor 102, the memory 104, the network interface 106, and the peripheral interface 108 are communicatively coupled to each other within the electronic device via a bus 110.

The processor 102 may be a central processing unit (Central Processing Unit, CPU), an image processor, a neural Network Processor (NPU), a Microcontroller (MCU), a programmable logic device, a Digital Signal Processor (DSP), an Application SPECIFIC INTEGRATED Circuit (ASIC), or one or more integrated circuits. The processor 102 may be used to perform functions related to the techniques described herein. In some embodiments, processor 102 may also include multiple processors integrated as a single logical component. As shown in fig. 1, the processor 102 may include a plurality of processors 102a, 102b, and 102c.

The memory 104 may provide a database in which data (e.g., instruction sets, computer code, intermediate data, etc.) during operation is stored. The simulation tool for the test design may be a computer program stored in the memory 104. As shown in fig. 1, the data stored by the memory 104 may include program instructions (e.g., program instructions for implementing the aspects of the present application) as well as a database storing operational data (e.g., the memory may store temporary code generated during the compilation process). The processor 102 may also access program instructions and databases stored in the memory. The memory 104 may include volatile storage or nonvolatile storage. In some embodiments, memory 104 may include Random Access Memory (RAM), read Only Memory (ROM), optical disks, magnetic disks, hard disks, solid State Disks (SSD), flash memory, memory sticks, and the like.

The network interface 106 may be configured to provide communication with other external devices to the electronic device 100 via a network. The network may be any wired or wireless network capable of transmitting and receiving data. For example, the network may be a wired network, a local wireless network (e.g., bluetooth, wiFi, near Field Communication (NFC), etc.), a cellular network, the internet, or a combination of the foregoing. It will be appreciated that the type of network is not limited to the specific examples described above. In some embodiments, network interface 106 may include any combination of any number of Network Interface Controllers (NICs), radio frequency modules, receivers, modems, routers, gateways, adapters, cellular network chips, etc.

The peripheral interface 108 may be configured to connect the electronic apparatus 100 with one or more peripheral devices to enable information input and output. For example, the peripheral devices may include input devices such as keyboards, mice, touchpads, touch screens, microphones, various types of sensors, and output devices such as displays, speakers, vibrators, and indicators.

Bus 110 may be configured to transfer information between the various components of electronic device 100 (e.g., processor 102, memory 104, network interface 106, and peripheral interface 108), such as an internal bus (e.g., processor-memory bus), an external bus (USB port, PCI-E bus), etc.

It should be noted that, although the above-described architecture of the electronic device 100 only shows the processor 102, the memory 104, the network interface 106, the peripheral interface 108, and the bus 110, in the implementation, the architecture of the electronic device 100 may also include other components necessary to achieve normal operation. In addition, it will be understood by those skilled in the art that the above-described architecture of the electronic device 100 may include only components necessary for implementing the embodiment of the present application, and not all components shown in the drawings.

FIG. 2 shows a schematic diagram of a simulation tool 202 and a debugging tool 200 in accordance with an embodiment of the present application. The simulation tool 202 and the debugging tool 200 may be computer programs running on the electronic device 100.

In the field of chip design, a design may be simulated, typically with simulation tools. The simulation tool may be, for example, galaxSim simulation tool available from core chapter technologies, inc. The exemplary simulation tool 202 illustrated in FIG. 2 may include a compiler 120 and a simulator 220. Compiler 120 may compile the design (e.g., verification system 210) into object code 204, and simulator 220 may simulate based on object code 204 and output simulation results 206. For example, the simulation tool 202 may output simulation results (e.g., simulation waveform diagrams) onto an output device (e.g., displayed on a display) via the peripheral interface 108 of fig. 1. Verification system 210 may include a logic system design 210a and a verification environment 210b. Verification environment 210b may also be referred to as a test bench (testbench). For example, the verification environment 210b may be a UVM environment.

The simulation results 206 may also be stored in the form of a log database. The log database storing log information may also be referred to as a log file.

Debug tool 200 may also read simulation results 206. The Debug tool 200 may be, for example, a Fusion Debug tool available from core chapter technologies, inc. For example, debug tool 200 may read simulation results 206 stored in a waveform file and generate corresponding simulated waveforms for debugging. Debug tool 200 may also read a description of verification system 210 (typically SystemVerilog and Verilog code) and display to the user. Debug tool 200 may also generate various graphical interfaces (e.g. debug windows) to facilitate user debugging operations. The user may issue a debug command to the debug tool 200 (e.g., running the validation system 210 to a certain time), which the debug tool 200 then applies to the simulation tool 202 to execute accordingly. Debug tool 200 may also read log files. The log file may include various information of the simulation process, including information of the simulation error, a line number of the error, a time when the simulation error occurs, and the like.

It is understood that in addition to interfacing with simulation tool 202, debug tool 200 may also interface with hardware simulator (emulator).

Wherein 300 illustrates a flow chart for generating a reference log file and 310 illustrates a flow chart for generating a target log file.

The target logic system design 302 in reference logic system designs 301 and 310 in 300 may be a chip design or part of a complete chip design. And, the target logic system design 302 may be modified based on the reference logic system design 301. It will be appreciated that most of the designs of the reference logic system design 301 and the target logic system design 303 are identical, and thus, the simulation events included in the simulation process and the log files returned thereby may be identical or largely identical.

Simulation tool 202 may read and compile a description of a logical system design (e.g., source code) and generate an executable file for simulation.

After the simulation ends, the simulation data is stored in the memory 104. The subsequent simulator 220 may generate a log file from the simulation data in the memory 104. The logs in the log file may include information such as time stamps, event types, event descriptions, event levels, etc.

300, A reference logic system design 301 is simulated to obtain a reference log file 303; at 310, the target logic system design 302 is simulated to obtain a target log file 304.

Since the reference logic system design 301 corresponding to the reference log file 303 is generally considered the correct design, the reference log file 303 may be considered the correct log file. While the differences between the target log file 304 and the reference log file 303 may generally reflect errors introduced to the target logical system design 302, as the target logical system design 302 may be modified to introduce errors. Therefore, by comparing the difference between the target log file 304 and the reference log file 303, it is possible to quickly locate a log (hereinafter, collectively referred to as an abnormal log) in which an abnormality occurs in the target log file 304. The exception log may reflect errors that may occur in the target logical system design 302. And each log corresponds to a simulation time point. The point in time of the simulation corresponding to the exception log may be referred to as a suspicious point.

FIG. 4 is a schematic diagram of a method of determining suspicious points in a logical system design according to an embodiment of the present application.

In the present application, the simulation process of a logic system design may include a plurality of simulation events. In general, a simulation event refers to a specific event that occurs during the simulation process, such as a system error, a warning, information, debug information, and the like. These simulation events may be divided by time or by code of the design. One simulation event may be associated with multiple reference logs and multiple target logs.

In some embodiments, the simulation process of a logic system design may be pre-partitioned into multiple simulation events over time. The plurality of simulation events may include, for example, simulation event a. Simulation event A may include one or more stimulus signals applied by a test bench (testbench) to a design under test of a logic system design.

As shown in FIG. 4, simulation event A may be included in the process of simulation tool 202 simulating reference logic system design 301 and target logic system design 302. The simulation tool 202 may generate the reference log file 303 and the target log file 304, respectively, after the simulation of the reference logical system design 301 and the target logical system design 302 is completed. Reference log file 303 may include reference logs 1-4 and target log file 304 may include target logs 1-4. The simulation event A is associated with the reference logs 1-4 and the target logs 1-4. The reference logs 1 to 4 and the target logs 1 to 4 may correspond to each other in time series. It will be appreciated that, due to the differences in the reference logical system design 301 and the target logical system design 302, the reference logs 1-4 and the target logs 1-4 may correspond in time but are not necessarily identical.

As shown in FIG. 4, debug tool 200 may compare reference logs 1-4 and target logs 1-4 over a time series. The event information "TASK a" in the reference log 1 represents that the reference log 1 is associated into the simulation event a. Where "axiwr" denotes that a write operation is being performed to the AXI bus. And the reference log 1 records that the value written to the AXI bus is "0xabcd_1230". In comparison to reference log 1, target log 1 records a value of "0xabcd_123f" written to the AXI bus. Because of the same parameters in reference log 1 and target log 1, but different values, debug tool 200 may determine that reference log 1 and target log 1 do not match.

Because the reference log 1 and the target log 1 are not matched, the debug tool 200 marks the target log 1 as an exception log, records an event sequence corresponding to the exception log and a simulation time "2023-09-0518:49:13" of the exception log as a suspicious point a, and stores the suspicious point a in the memory 104.

FIG. 5 is a schematic diagram of a method of determining suspicious points in a logical system design according to an embodiment of the present application.

In some embodiments, as shown in FIG. 5, the simulation process of the reference logic system design 301 and the target logic system design 303 may include a simulation event B. The simulation tool 202 may generate the reference log file 303 and the target log file 304 after the simulation is completed. The reference log file 304 may include reference logs 5-8 and the target log file 304 may include target logs 5-8. The simulation event B is associated with the reference logs 5-8 and the target logs 5-8. The reference logs 5 to 8 and the target logs 5 to 8 may correspond to each other in time series.

Debug tool 200 may compare reference logs 5-8 and target logs 5-8 over a time series. The event information "TASK B" in the reference log 5 represents that the reference log 5 is associated into the simulation event B. The timestamp of the reference log 5 is "2023-09-05 16:49:55", and the timestamp of the target log 5 is "2023-09-05 17:49:13". The time stamps of reference log 6, reference log 7 and reference log 8 following reference log 5 can be seen in time series as "2023-09-05 16:49:56", "2023-09-0516:49:58" and "2023-09-05 16:49:59", respectively. The reference logs 5-8 are contiguously compact in time.

Debug tool 202 further analyzes target logs 5-8. The timestamp of the target log 5 is '2023-09-05 17:49:13', the timestamp of the target log 6 is '2023-09-06 17:00:19', the timestamp of the target log 7 is '2023-09-07 17:00:23', and the timestamp of the target log 8 is '2023-10-05 18:53:24'. Obviously, the time series of the target logs 5 to 8 are chaotic and unordered in time series. Because the time series of the target logs 5-8 are significantly confusing, the debug tool 200 may determine that the target logs 5-8 do not match the reference logs 5-8.

Since the reference logs 5 to 8 and the target logs 5 to 8 are not matched, the debug tool 200 marks the target logs 5 to 8 as abnormal logs, records the event sequence corresponding to the abnormal logs and the simulation time thereof as suspicious points b, and stores the suspicious points b in the memory 104.

FIG. 6 is a schematic diagram of a method of determining suspicious points in a logical system design according to an embodiment of the present application.

In some embodiments, as shown in FIG. 6, the simulation process of the reference logic system design 301 and the target logic system design 303 may include a simulation event C. The simulation tool 202 may generate the reference log file 303 and the target log file 304 after the simulation is completed. The reference log file 304 may include reference logs 9-12 and the target log file 304 may include target logs 9-12. The simulation event B is associated with the reference log 9 to 12 and the target log 9 to 12. The reference logs 9 to 12 and the target logs 9 to 12 may correspond to each other in time series.

Debug tool 200 may compare reference log 9-12 and target log 9-12 over a time series. The event information "TASK C" in the reference log 9 represents that the reference log 5 is associated into the simulation event C. The reference logs 9-12 record the input port parameter values and output port parameter values, respectively, in the simulation event C. The debug tool 200 may cluster the input port parameter values and the output port parameter values into sets of corresponding values. As shown in fig. 6, the reference log 9 has an input port parameter value of 75, and an output port parameter value of 81, which may be denoted as [75, 81]. By analogy, the parameter values of reference logs 9-12 may be clustered into an array X: [75, 81], [1, 23], [87, 97] and [62, 17]; the parameter values of the target logs 9-12 may be clustered into an array Y: [1, 23], [75, 51], [62, 81] and [87, 19].

Obviously, only the second element [1, 23] in array Y falls into array X, and none of the remaining elements falls into array X. Thus, the debug tool can confirm that the target logs 9, 11, and 12 do not match the reference logs 9, 11, and 12.

Since the reference logs 9, 11, and 12 and the target logs 9, 11, and 12 do not match, the debug tool 200 marks the target logs 9, 11, and 12 as exception logs, records the event sequence corresponding to the exception logs and the simulation time thereof as suspicious points c, and stores them in the memory 104.

The debug tool 200 of the present application may also identify suspicious points using machine learning and artificial intelligence techniques. For example, debug tool 200 may use unsupervised learning to cluster logs into groups that may be considered suspicious for logs that cannot be clustered. It will be appreciated that other methods of determining suspicious points may be employed and are not limited to the specific examples of embodiments of the present application.

FIG. 7 illustrates a logic diagram of a logic system design preserving restore points during simulation in accordance with an embodiment of the present application.

In simulating the target logic system design 303, the debug tool 200 first validates suspicious points in the plurality of logs. After the simulation is finished, based on the suspicious points which are confirmed and stored in the first simulation, the restoration points are stored in the second simulation process.

The restore point includes the time of the restore point and restore information at the time. The restored information includes the values of the key signals (also called the main signals, english name PRIMARY SIGNALS) and the simulated environmental parameters.

In some embodiments, the time of return of the point may include a simulation time point corresponding to the suspicious point and one or more simulation time points preceding the simulation time point corresponding to the suspicious point. As shown in fig. 7, the time corresponding to the suspicious point a is t5, and four times t1 to t4 before the time t5 and the time t5 are set as restore points.

In still other embodiments, the time of return of the point may include a simulation time point corresponding to the suspicious point and one or more simulation time points subsequent to the simulation time point corresponding to the suspicious point. As shown in fig. 7, the time corresponding to the suspicious point b is t6, and four times t7 to t10 after the time t6 and the time t6 are set as the restoration points.

In still other embodiments, the time of return of the point may include a simulation time point corresponding to the suspicious point and one or more simulation time points before and after the simulation time point corresponding to the suspicious point. As shown in fig. 7, the time corresponding to the suspicious point c is t13, and the return point is set to be the time t13, and two times t11 to t12 before t13, and two times t14 to t15 after t 13.

It is understood that the method of setting the restore point near the time corresponding to the suspicious point includes, but is not limited to, specific examples of embodiments of the present application.

In some embodiments, the restore information may be data in memory at a given time during the simulation. Based on the determined suspicious points, the debug tool 200 finds the restoration time to be saved, copies the data of the memory in the process at the given restoration time, and stores the copy result in the memory 104.

FIG. 8 illustrates yet another logic diagram of a logic system design to save restore points during simulation in accordance with an embodiment of the present application.

During simulation of a logical system design, a simulation event may be associated with multiple suspicious points. As shown in FIG. 6, emulation event C may be associated with three exception logs, each of which may be considered a suspicious point by debug tool 200. In some embodiments, the suspicious points may be very close in simulation time. When the distance between two suspicious points is very close, the debug tool 200 can flexibly set the restore point.

In some embodiments, as shown at 800 in FIG. 8, the distance of suspicious point d and suspicious point e is relatively close. According to the above method, the debug tool 200 sets the time point corresponding to the suspicious point d and one or more time points before and after the time point corresponding to the suspicious point d as the first set of restoration points X, and sets the time point corresponding to the suspicious point e and one or more time points before and after the time point corresponding to the suspicious point e as the second set of restoration points Y. This results in an excessive number of restore points between points 801 and 802. Too many restore points may occupy too many memory resources. In order to reduce the occupation of memory resources as much as possible, the user may preset a given threshold value, requiring that the density of restore points within a period of time not be higher than the given threshold value. The density of the restore points refers to the number of restore points per unit time period.

As shown in fig. 8, debug tool 200 may determine whether the density of the plurality of return points in the time period from time point 801 to time point 802 is greater than a given threshold. If the density of restore points within the time period is greater than a given threshold, debug tool 200 may delete portions of restore points such that the density within the time period is less than the threshold. It will be appreciated that the density of recovery points during this period of time after the deletion of a partial recovery point should be above a given minimum. For example, as shown in diagram (a) of 800, the debug tool 200 may delete the restore point corresponding to one suspicious point (e.g., suspicious point d) during the time period. As another example, as shown in graph (b) of 800, debug tool 200 may delete the restore points within the time period at intervals (e.g., 1 per 2 restore points at intervals, or one restore point per period of time at intervals). It will be appreciated that various ways of deleting the restore point may be applied to embodiments of the present application, and are not limited to the examples described above.

By selectively saving the restore point, debug tool 200 reduces memory resource occupancy by the save restore point and does not affect the efficiency of the restore point to the specified point in time. On the basis of ensuring the debugging efficiency, the burden of memory resources is reduced.

The embodiment of the application also provides a method for setting the simulation restoration point of the logic system design, the debugging tool 200 can set the restoration point of the logic system design near the suspicious point, the simulation time from the restoration point to the suspicious point is greatly shortened, the debugging analysis time of a user is saved, so that the user can perform design test faster, and faults in the logic system design can be found out more efficiently.

FIG. 9 illustrates a flow diagram of an exemplary method 900 for setting a simulated restore point for a logic system design in accordance with an embodiment of the present application. Method 900 may be performed by electronic device 100 of fig. 1, and more particularly, by debug tool 200 running on electronic device 100. The method 900 may include the following steps.

In step 902, the simulation tool 202 may simulate a reference logic system design (e.g., logic system design 301 in FIG. 3) to obtain a reference log file (e.g., reference log file 303 in FIG. 3). The reference logic system design may include multiple simulation events (e.g., simulation event A in FIG. 4, simulation event B in FIG. 5, and simulation time per C in FIG. 6).

In step 904, the simulation tool 202 may simulate a target logic system design (e.g., the logic system design 302 of FIG. 3) to obtain a target log file (e.g., the target log file 304 of FIG. 3), which is modified based on the reference logic system design (e.g., the logic system design 301 of FIG. 3). The target logic system design may include multiple simulation events (e.g., simulation event A in FIG. 4, simulation event B in FIG. 5, and simulation time per C in FIG. 6).

In step 906, debug tool 200 compares the reference log file (e.g. reference log file 304 in fig. 3) to the target log file (e.g. reference log file 303 in fig. 3) to locate a suspicious point of the target logical system design;

in some embodiments, as shown in FIG. 4, debug tool 200 obtains multiple reference logs (e.g. reference logs 1-4 in FIG. 4) and multiple target logs (e.g. target logs 1-4 in FIG. 4) associated with one simulation event (e.g. simulation event A in FIG. 4) from the reference log file 303 and the target log file 304, respectively.

It is determined whether values of the same parameters in the plurality of reference logs and the plurality of target logs (e.g., parameter values of reference log 1 and target log 1 in fig. 4) are the same. In response to the values of the same parameters (e.g., parameter values of reference log 1 and target log 1 in fig. 4) being different, it is determined that the plurality of reference logs (e.g., reference log 1 in fig. 4) and the plurality of target logs (e.g., target log 1 in fig. 4) do not match.

In response to one or more mismatches of the plurality of target logs (e.g., target log 1 in fig. 4) and the plurality of reference logs (e.g., reference log 1 in fig. 4), determining a point in time corresponding to the one or more target logs in simulation time as the suspicious point (e.g., suspicious point a in fig. 4).

In still other embodiments, as shown in FIG. 5, debug tool 200 obtains multiple reference logs (e.g. reference logs 5-8 in FIG. 5) and multiple target logs (e.g. target logs 5-8 in FIG. 5) associated with one simulation event (e.g. simulation event B in FIG. 5) from the reference log file 303 and the target log file 304, respectively.

It is determined whether there is an abnormality in the time series of the plurality of reference logs and the plurality of target logs (for example, the time series of the reference logs 5 to 8 and the target logs 5 to 8 in fig. 5). In response to the plurality of reference logs and the time series of the plurality of target logs, for example, the reference logs 5 to 8 and the time series of the target logs 5 to 8 in fig. 5, being abnormal, it is determined that the plurality of reference logs (for example, the reference logs 5 to 8 in fig. 5) and the plurality of target logs do not match (for example, the target logs 5 to 8 in fig. 5).

In response to one or more mismatches of the plurality of target logs (e.g., target logs 5-8 in fig. 5) and the plurality of reference logs (e.g., reference logs 5-8 in fig. 5), determining a point in time corresponding to the one or more target logs in simulation time as the suspicious point (e.g., suspicious point b in fig. 5).

In still other embodiments, as shown in FIG. 6, debug tool 200 obtains multiple reference logs (e.g. reference logs 9-12 in FIG. 6) and multiple target logs (e.g. target logs 9-12 in FIG. 6) associated with one simulation event (e.g. simulation event C of FIG. 6) from the reference log file 303 and the target log file 304, respectively.

Extracting a plurality of reference values and a plurality of target values of the target parameter from the plurality of reference logs (for example, reference logs 9 to 12 in fig. 6) and the plurality of target logs (for example, target logs 9 to 12 in fig. 6), respectively; clustering the plurality of reference values into one or more groups (e.g., array X in the description above); determining whether the plurality of target values (e.g., target values of target logs 9-12 in fig. 6) fall within the one or more groups (e.g., array X in the above description); debug tool 200 marks the target values that cannot fall into the one or more groups (e.g. input parameter values and output parameter values of target logs 9, 11, and 12 in fig. 6) as abnormal target values; and determining that the target logs (e.g., target logs 9, 11, and 12 in fig. 6) corresponding to the abnormal target values do not match.

In response to one or more mismatches of the plurality of target logs (e.g., target logs 9-12 in fig. 6) and the plurality of reference logs (e.g., reference logs 9-12 in fig. 5), determining a point in time corresponding to the one or more target logs in simulation time as the suspicious point (e.g., suspicious point c in fig. 6).

In step 908, the debug tool 200 determines one or more simulation moments associated with the suspicious points (e.g., suspicious point a in fig. 4, suspicious point b in fig. 5, and suspicious point c in fig. 6) from the suspicious points.

In some embodiments, as shown in fig. 7, the one or more simulation moments include: the point in time of the suspicious spot (e.g., suspicious spot a in fig. 7) at the simulation time (e.g., time t5 in fig. 7), one or more points in time of the suspicious spot (e.g., time t 1-t 4 in fig. 7) before the point in time of the simulation time.

In still other embodiments, as shown in fig. 7, the one or more simulation moments include: the point in time of the suspicious spot (e.g., suspicious spot b in fig. 7) at the simulation time (e.g., time t6 in fig. 7), one or more points in time of the suspicious spot after the point in time of the simulation time (e.g., time t 7-time t10 in fig. 7).

In still other embodiments, as shown in fig. 7, the one or more simulation moments include: the point in time of the suspicious spot (e.g., suspicious spot c in fig. 7) at the simulation time (e.g., time t13 in fig. 7), one or more points in time before the point in time of the suspicious spot at the simulation time, and one or more points in time after the point in time (e.g., time t 11-t 12, t 14-t 15 in fig. 7).

In step 910, the simulation tool 202 re-simulates the target logic system design (e.g., logic system design 302 of FIG. 3) to save one or more return points at the one or more simulation moments (e.g., moments t 1-t 15 of FIG. 6), respectively.

In some embodiments, simulation tool 202 may obtain the primary input and the simulation parameters for one of the restore points; the process of simulating the target logic system design (e.g., logic system design 302 of FIG. 3) is restored to a simulation time corresponding to the restore point based on the primary inputs and the simulation parameters.

In some embodiments, the simulation tool 202 may determine whether the density of the plurality of return points over a period of time (e.g., the density of the return points over periods 801 through 802 in fig. 8) is greater than a given threshold. And responsive to the density of the plurality of return points being greater than the given threshold, deleting a portion of the return points in the plurality of return points such that the density during the time period is less than the given threshold. For example, as shown in diagram (a) of 800, the debug tool 200 may delete the restore point corresponding to one suspicious point (e.g., suspicious point d) during the time period. As another example, as shown in graph (b) of 800, debug tool 200 may delete the restore points within the time period on an interval basis (e.g., 1 for every 2 restore points or one restore point for every period of time).

According to the method for setting the simulation restoration point of the logic system design, provided by the embodiment of the application, the debugging tool 200 can set the restoration point of the logic system design near the suspicious point, so that the simulation time from the restoration point to the suspicious point is greatly shortened, the debugging analysis time of a user is saved, the user can perform design test more quickly, and the faults in the logic system design can be found more efficiently.

It should be noted that, the method of the embodiment of the present application may be performed by a single device, for example, a computer or a server. The method of the embodiment can also be applied to a distributed scene, and is completed by mutually matching a plurality of devices. In the case of such a distributed scenario, one of the devices may perform only one or more steps of the method of an embodiment of the present application, the devices interacting with each other to accomplish the method.

It should be noted that the foregoing describes some embodiments of the present application. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments described above and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

Those of ordinary skill in the art will appreciate that: the discussion of any of the embodiments above is merely exemplary and is not intended to suggest that the scope of the application (including the claims) is limited to these examples; the technical features of the above embodiments or in the different embodiments may also be combined within the idea of the application, the steps may be implemented in any order, and there are many other variations of the different aspects of the embodiments of the application as described above, which are not provided in detail for the sake of brevity.

Additionally, well-known power/ground connections to Integrated Circuit (IC) chips and other components may or may not be shown within the provided figures, in order to simplify the illustration and discussion, and so as not to obscure the embodiments of the present application. Furthermore, the devices may be shown in block diagram form in order to avoid obscuring the embodiments of the present application, and also in view of the fact that specifics with respect to implementation of such block diagram devices are highly dependent upon the platform within which the embodiments of the present application are to be implemented (i.e., such specifics should be well within purview of one skilled in the art). Where specific details (e.g., circuits) are set forth in order to describe example embodiments of the application, it should be apparent to one skilled in the art that embodiments of the application can be practiced without, or with variation of, these specific details. Accordingly, the description is to be regarded as illustrative in nature and not as restrictive.

While the application has been described in conjunction with specific embodiments thereof, many alternatives, modifications, and variations of those embodiments will be apparent to those skilled in the art in light of the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may use the embodiments discussed.

The present embodiments are intended to embrace all such alternatives, modifications and variances which fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, and the like, which are within the spirit and principles of the embodiments of the application, are intended to be included within the scope of the application.

Claims

1. A method of setting a simulated restore point for a logic system design, comprising:

simulating a reference logic system design to obtain a reference log file;

Simulating a target logic system design to obtain a target log file, the target logic system design being modified based on the reference logic system design;

comparing the reference log file with the target log file to locate suspicious points of the target logical system design;

determining one or more simulation moments associated with the suspicious points according to the suspicious points; and

Re-simulating the target logic system design to respectively save one or more return points at one or more simulation moments associated with the suspicious points.

2. The method of claim 1, wherein comparing the reference log file and the target log file to locate a suspicious point of the target logical system design further comprises:

acquiring a plurality of reference logs and a plurality of target logs associated with one simulation event from the reference log file and the target log file respectively;

determining whether the plurality of reference logs and the plurality of target logs match; and

And in response to the plurality of reference logs not matching one or more of the plurality of target logs, determining a point in time corresponding to the one or more target logs in simulation time as the suspicious point.

3. The method of claim 2, wherein determining whether the plurality of reference logs and the plurality of target logs match further comprises:

determining whether values of the same parameters in the plurality of reference logs and the plurality of target logs are the same;

determining that the plurality of reference logs and the plurality of target logs do not match in response to the values of the same parameter being different; or alternatively

Determining whether there is an anomaly in the time series of the plurality of reference logs and the plurality of target logs;

Determining that the plurality of reference logs and the plurality of target logs do not match in response to the plurality of reference logs and the plurality of target logs having anomalies in their time series; or alternatively

Extracting a plurality of reference values and a plurality of target values of the target parameter from the plurality of reference logs and the plurality of target logs, respectively;

clustering the plurality of reference values into one or more groups;

determining whether the plurality of target values fall within the one or more groups;

marking the target values that cannot fall into the one or more groups as abnormal target values; and

And determining that the target logs corresponding to the abnormal target values are not matched.

4. The method of claim 1, wherein the one or more simulation moments comprise: a point in time of the suspicious point at a simulation time, one or more points in time of the suspicious point before the point in time of the simulation time, or one or more points in time of the suspicious point after the point in time of the simulation time.

5. The method of claim 1, wherein re-simulating the target logic system design to save one or more return points at the one or more simulation moments, respectively, further comprises:

simulating the target logic system design; and

The main inputs of the simulation and simulation parameters are saved as the one or more return points at one or more simulation moments associated with the suspicious point.

6. The method of claim 5, further comprising:

determining whether the density of the plurality of return points over a period of time is greater than a given threshold; and

In response to the density of the plurality of return points being greater than the given threshold, deleting a portion of the return points in the plurality of return points such that the density during the time period is less than the given threshold.

7. The method of claim 1, further comprising:

acquiring main input and simulation parameters of one restoration point; and

And restoring the process of simulating the design of the target logic system to the simulation time corresponding to the restoration point according to the main input and the simulation parameters.

8. An electronic device, comprising:

a memory for storing a set of instructions; and

At least one processor configured to execute the set of instructions to perform the method of any one of claims 1 to 7.

9. A non-transitory computer readable storage medium storing a set of instructions of a computer for, when executed, causing the computer to perform the method of any one of claims 1 to 7.