CN115470125B

CN115470125B - Log file-based debugging method, device and storage medium

Info

Publication number: CN115470125B
Application number: CN202211074066.6A
Authority: CN
Inventors: 黄世杰
Original assignee: Core Huazhang Technology Beijing Co ltd
Current assignee: Core Huazhang Technology Beijing Co ltd
Priority date: 2022-09-02
Filing date: 2022-09-02
Publication date: 2023-07-25
Anticipated expiration: 2042-09-02
Also published as: CN115470125A

Abstract

The embodiment of the application provides a debugging method, equipment and storage medium based on log files. The method comprises the following steps: receiving a simulation result of logic system design, wherein the simulation result comprises a log file, and the log file comprises a plurality of log messages; receiving an instruction of selecting a target log message from the plurality of log messages by a user; determining key information of the target log message, wherein the key information comprises a target signal associated with the target log message; determining a plurality of debugging functions to be called according to the key information; and displaying results of the processing of the target log message by the plurality of debugging functions in a plurality of debugging windows respectively.

Description

Log file-based debugging method, device and storage medium

Technical Field

The embodiment of the application relates to the technical field of chip verification, in particular to a debugging method, equipment and storage medium based on a log file.

Background

In the field of verification of integrated circuits, in order to verify whether a logic system design is correct, a design verification environment is required for verifying the logic system design. The verification environment may be run on a computer or hardware simulation device after compilation to perform simulation tests on various functions of the logic system design to verify that the logic system design is correct.

The simulation test may return a simulation result, which may include a waveform file, a log file, etc.

The waveform file records the change in signal values of the plurality of signals over a period of time. The log file records text information related to the test, such as error information, time information, design file information, and the like.

The user needs to rely on the simulation results to debug to find errors in the logic system design.

Disclosure of Invention

A first aspect of the present application provides a method for debugging based on log files. The method comprises the following steps: receiving a simulation result of logic system design, wherein the simulation result comprises a log file, and the log file comprises a plurality of log messages; receiving an instruction of selecting a target log message from the plurality of log messages by a user; determining key information of the target log message, wherein the key information comprises a target signal associated with the target log message; determining a plurality of debugging functions to be called according to the key information; and displaying results of the processing of the target log message by the plurality of debugging functions in a plurality of debugging windows respectively.

A second aspect of the present application provides an electronic device. The electronic device includes a memory for storing a set of instructions; and at least one processor configured to execute the set of instructions to cause the electronic device to perform the method of the first aspect.

A third aspect of the present application provides 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 the first aspect.

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 these drawings without inventive effort to those of ordinary skill in the art.

Fig. 1 shows a schematic diagram of a host according to an embodiment of the present application.

FIG. 2 shows a schematic diagram of an emulation tool and a debug tool in accordance with an embodiment of the present application.

FIG. 3 illustrates an exemplary diagram of a log file window according to an embodiment of the present application.

FIG. 4 illustrates an exemplary schematic diagram of a joint debugging interface according to an embodiment of the present application.

Fig. 5 shows a flowchart of a log file based debugging method according to an embodiment of the present application.

Detailed Description

For the purposes of making the objects, technical solutions and advantages of the present application more apparent, the present application will be further described in detail below with reference to the accompanying drawings.

It is to be noted that unless otherwise defined, technical or scientific terms used herein should be taken in a general sense as understood by one of ordinary skill in the art to which this application belongs. The terms "first," "second," and the like, as used herein, do not denote any order, quantity, or importance, but rather are used to distinguish one element from another. The word "comprising" 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 without precluding other elements or items. The term "coupled" and the like are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect.

Simulation testing is the application of various stimuli to a logic system design on a host running a simulation test system to detect whether the logic system design can perform a predetermined function.

Fig. 1 shows a schematic diagram of a host 100 according to an embodiment of the present application. The host 100 may be an electronic device running an emulation system. As shown in fig. 1, the host 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 host 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 (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 be configured to store data (e.g., instruction sets, computer code, intermediate data, etc.). In some embodiments, the simulation test system used to simulate the test design may be a computer program stored in memory 104. As shown in fig. 1, the data stored by the memory may include program instructions (e.g., program instructions for implementing the methods of locating errors of the present application) as well as data to be processed (e.g., the memory may store temporary code generated during compilation). The processor 102 may also access program instructions and data stored in the memory and execute the program instructions to perform operations on the data to be processed. 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 host 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 host 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 host 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 (e.g., USB port, PCI-E bus), etc.

It should be noted that, although the above-described host architecture only shows the processor 102, the memory 104, the network interface 106, the peripheral interface 108, and the bus 110, in a specific implementation, the host architecture may also include other components necessary to achieve proper operation. Furthermore, those skilled in the art will appreciate that the above-described host architecture may also include only the components necessary to implement the embodiments of the present application, and not all the components shown in the figures.

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

In the field of chip design, a design may be simulated, typically with simulation tools. The simulation tool may be, for example, a GalaxSim simulation tool available from Kagaku Co., ltd. 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 testbench (testbench). For example, the verification environment 210b may be a UVM environment.

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 the simulation tool 202, the debug tool 200 may also interface with a hardware simulator (simulator).

One significant feature in the debugging process is the large amount of data that is read by the debugging tool 200 from the simulation results 206. The simulation results 206 may include waveform files, log files, coverage databases, and the like. The waveform file may include a large number of signal changes over a long simulation time, and the file volume may be on the order of hundreds of GB to several TB. While the log file may include a number of log messages, which may be tens of thousands or even hundreds of thousands. This makes it difficult for a user to quickly locate errors in the design of the logic system and the cause of the errors when relying on the simulation results 206 for debugging.

The embodiment of the application provides a debugging method, equipment and storage medium based on a log file, which are used for processing log information to extract key information and realizing joint debugging linkage of a plurality of debugging functions according to the key information so as to help a user to quickly locate errors and error reasons.

Fig. 3 shows an exemplary schematic diagram of a log file window 300 according to an embodiment of the present application.

As shown in fig. 3, the contents of log message 310 may be displayed in log file window 300. In the context of the exemplary log message 310, a UVM error is reported, including where the error was located in the logical system design (e.g., 163 lines of mrv55_l1i_id_model. Sv file), the time at which the error occurred (e.g., 811530 ns), event information (e.g., axi transaction), and address information (e.g., tr_addr=fff001).

Debug tool 200 may process log message 310 to obtain critical information. The key information may include primary key information directly acquired from the log message and secondary key information indirectly acquired from the log message. In some embodiments, debug tool 200 may utilize natural language processing (Natural Language Processing, NLP) techniques to determine primary critical information included in log message 310, such as where the errors described above were located in the logical system design, when the errors occurred, event information, and address information. Based on the primary critical information described above, debug tool 200 may further determine secondary critical information based on the source code of the logic system design. For example, debug tool 200 may determine the signals (e.g., a and b signals, not shown) related to the error based on where the error is located in the logical system design (e.g., line 163 of MRV55_l1i_id_model. Sv file). Debug tool 200 may also find functions associated with the error, etc., in the stack of memory based on the address information of the error and the time the error occurred.

FIG. 4 illustrates an exemplary schematic diagram of a federated debug interface 400 in accordance with an embodiment of the present application.

As shown in FIG. 4, joint debug interface 400 may include a plurality of debug windows 300, 402, 404, and 406, each debug window corresponding to a debug function. The user selects one of the log messages (e.g., message 310) in log file window 300, and interface 400 may initiate a corresponding debug function in each of the plurality of debug windows based on the log message selected by the user.

In some embodiments, window 402 and corresponding debug functionality may be used to display a waveform map of signals associated with log message 310. It will be appreciated that the waveform shown in this waveform diagram corresponds to the time at which an error in the log message occurred (e.g., 811530 ns).

In some embodiments, window 404 and corresponding debug functions may be used to generate and display a circuit diagram corresponding to log message 310. Debug tool 300 may determine the circuit module corresponding to log message 310 from the primary critical information and the secondary critical information. For example, window 404 shows a circuit diagram of two modules corresponding to signals a and b.

In some embodiments, window 406 and corresponding debug functionality may be used to display coverage corresponding to log message 310. For example, window 406 shows the coverage of signals a and b. The coverage of signals a and b may be obtained from a coverage database.

It is appreciated that debug tool 200 may provide more or fewer debug windows in joint debug interface 400 depending on the needs of the user. Also, for some log messages, debug tool 200 may not be able to provide all of the debug window, but only a portion of the debug window. For example, when the signal to which the log message relates is not coverage statistics, the debug tool 200 cannot invoke the window 406 for displaying the coverage of the signal.

In some embodiments, when a user switches from log message 310 to another log message, debug tool 200 may adjust the information displayed in the multiple debug windows in joint debug interface 400 to correspond to the new log message based on the new log message, thereby enabling joint debugging linkage of the log message with the multiple debug functions. In this way, on one hand, the user can judge the execution condition of the verification task by reading the log message, and meanwhile, the associated information corresponding to the log message can be acquired through a plurality of debugging windows, so that the user can conveniently debug the user.

The embodiment of the application also provides a debugging method based on the log file.

Fig. 5 shows a flow chart of a log file based debugging method 500 according to an embodiment of the present application. Method 500 may be performed by host 100 of fig. 1, and more specifically, by debug tool 200 running on host 100. The method 500 may include the following steps.

At step 502, debug tool 200 may receive a simulation result (e.g., simulation result 206 of FIG. 2) of a logic system design (e.g., logic system design 210a of FIG. 2). The simulation results may include a log file that may include a plurality of log messages (e.g., message 310 of fig. 3). In some embodiments, the simulation results may also include a coverage database and a waveform file corresponding to the log file.

At step 504, debug tool 200 may receive instructions from a user selecting a target log message (e.g. message 310 of fig. 3) from the plurality of log messages.

At step 506, debug tool 200 may determine critical information for the target log message, wherein the critical information comprises a target signal associated with the target log message.

The key information may include primary key information and secondary key information. In some embodiments, to determine key information of the target log message, debug tool 200 may determine primary key information included in the target log message using natural language processing; and determining the secondary critical information based on the description of the logical system design using the primary critical information. Primary key information may be obtained directly from the log message. For example, the primary critical information may include where the emulation error is located in the logical system design (e.g., row 163 of mrv55_l1i_model. Sv file in message 310 of fig. 3), the time at which the emulation error occurred (e.g., 811530ns in message 310 of fig. 3), event information corresponding to the emulation error (e.g., axi transaction in message 310 of fig. 3), and address information of the emulation error (e.g., tr_addr=fff001 in message 310 of fig. 3). The secondary critical information may include signals related to the simulation error (e.g., a and b signals) determined using primary critical information of where the simulation error is located in the logical system design, a function associated with the simulation error determined using primary critical information of address information of the simulation error and a time when the simulation error occurs, and the like.

At step 508, debug tool 200 may determine a plurality of debug functions to call based on the critical information. As shown in fig. 4, the debug function may include a coverage display function, a waveform display function, a circuit diagram display function, and the like.

At step 510, debug tool 200 may display the results of processing the target log message by the plurality of debug functions in a plurality of debug windows, respectively.

In some embodiments, debug tool 200 may extract waveform data corresponding to a target signal in the waveform file from the target signal; and displaying a waveform map of a target signal associated with the target log message in a waveform window (e.g., window 402 of fig. 4) based on the waveform data.

In some embodiments, debug tool 200 may determine a circuit module corresponding to the target log message from the primary critical information and the secondary critical information; and generating and displaying a circuit diagram corresponding to the target log message in a circuit diagram window (e.g., window 404 of FIG. 4) according to the description of the logical system design.

In some embodiments, debug tool 200 may look up the coverage of the target signal in the coverage database; in response to finding the coverage of the target signal, the coverage of the target signal is displayed in a coverage window (e.g., window 406 of FIG. 4).

The embodiment of the application can allow a user to adjust information displayed in a plurality of debugging windows in the joint debugging interface 400 by selecting different log messages so as to realize joint debugging linkage of the log messages and the plurality of debugging functions. Therefore, on one hand, the user can judge the execution condition of the verification task by reading the log information, and meanwhile, the associated information corresponding to the log information can be acquired through a plurality of debugging windows, so that the user can conveniently debug the user.

The embodiment of the application also provides electronic equipment. The electronic device may be the host 100 of fig. 1. The electronic device may include a memory to store a set of instructions; and at least one processor configured to execute the set of instructions to cause the electronic device to perform the method 500.

Embodiments of the present application also provide a non-transitory computer readable storage medium. The non-transitory computer readable storage medium stores a set of instructions for a computer that, when executed, cause the computer to perform the method 500.

Some embodiments of the present application are described above. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments 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 different embodiments may also be combined under the idea of the present application, the steps may be implemented in any order, and there are many other variations of the different aspects of the present application as described above, which are not provided in details for the sake of brevity.

While the present 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.

This application is intended to embrace all such alternatives, modifications and variances which fall within the broad scope of the appended claims. Accordingly, any omissions, modifications, equivalents, improvements and the like, which are within the spirit and principles of the application, are intended to be included within the scope of the present application.

Claims

1. A debug method based on log file includes:

receiving a simulation result of logic system design, wherein the simulation result comprises a log file, and the log file comprises a plurality of log messages;

receiving an instruction of selecting a target log message from the plurality of log messages by a user;

determining key information of the target log message, wherein the key information comprises a target signal associated with the target log message;

determining a plurality of debugging functions to be called according to the key information; and

and respectively displaying the results of the target log message processed by the plurality of debugging functions in a plurality of debugging windows.

2. The debugging method of claim 1, wherein the critical information comprises primary critical information and secondary critical information, determining critical information for a target log message further comprising:

determining the primary key information included in the target log message using natural language processing;

the secondary critical information is determined based on the description of the logical system design using the primary critical information.

3. The debug method of claim 1, wherein the simulation results further comprise a waveform file, displaying the results of the plurality of debug functions processing the target log message in a plurality of debug windows, respectively, further comprises:

extracting waveform data corresponding to a target signal from the waveform file according to the target signal;

and displaying a waveform diagram of a target signal associated with the target log message in a waveform window according to the waveform data.

4. The debug method of claim 2, wherein displaying results of processing the target log message by the plurality of debug functions in a plurality of debug windows, respectively, further comprises:

determining a circuit module corresponding to the target log message according to the primary key information and the secondary key information;

and generating and displaying a circuit diagram corresponding to the target log message in a circuit diagram window according to the description of the logic system design.

5. The debug method of claim 1, wherein the simulation results further comprise a coverage database, displaying the results of the plurality of debug functions processing the target log message in a plurality of debug windows, respectively, further comprises:

searching coverage rate of the target signal in the coverage rate database;

and in response to finding the coverage rate of the target signal, displaying the coverage rate of the target signal in a coverage rate window.

6. 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 cause the electronic device to perform the method of any one of claims 1 to 5.

7. 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 5.