CN115470125A

CN115470125A - Debugging method and device based on log file and storage medium

Info

Publication number: CN115470125A
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: 2022-12-13
Anticipated expiration: 2042-09-02
Also published as: CN115470125B

Abstract

The embodiment of the application provides a debugging method, equipment and a storage medium based on a log file. The method comprises the following steps: receiving a simulation result of a 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 a user for selecting a target log message from the plurality of log messages; 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 the results of the plurality of debugging functions processing the target log message in a plurality of debugging windows respectively.

Description

Debugging method and device based on log file and storage medium

Technical Field

The embodiment of the application relates to the technical field of chip verification, in particular to a debugging method, debugging equipment and a 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 verification environment needs to be designed for verifying the logic system design. The verification environment may be run on a computer or hardware simulation device after compilation to perform simulation testing 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, and the like.

The waveform file records changes 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 for debugging to find errors in the logic system design.

Disclosure of Invention

A first aspect of the present application provides a log file-based debugging method. The method comprises the following steps: receiving a simulation result of a logic system design, wherein the simulation result comprises a log file which comprises a plurality of log messages; receiving an instruction of a user to select a target log message from the plurality of log messages; 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 the results of the plurality of debugging functions processing the target log message 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 according to the first aspect.

A third aspect of the 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 in the present application or related technologies, the drawings required for the embodiments or related technologies in the following description are briefly introduced, and it is obvious that the drawings in the following description are only the embodiments of the present application, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without creative efforts.

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

FIG. 2 shows a schematic diagram of a simulation tool and a debugging tool according to an embodiment of the 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 diagram of a federated debugging interface in accordance with 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

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

It is to be noted that, unless otherwise defined, technical or scientific terms used herein shall have the ordinary meaning as understood by those of ordinary skill in the art to which this application belongs. As used in this application, the terms "first," "second," and the like, do not denote any order, quantity, or importance, but rather are used to distinguish one element from another. The word "comprising" and similar words are intended to mean that the elements or items listed before the word cover the elements or items listed after the word and their equivalents, without excluding other elements or items. "connected," and like terms, 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 computer 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 application. The host 100 may be an electronic device running an emulation system. As shown in fig. 1, the host 100 may include: a processor 102, a memory 104, a network interface 106, a peripheral interface 108, and a 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 (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. Processor 102 may be used to perform functions associated with the techniques described herein. In some embodiments, processor 102 may also include multiple processors integrated into a single logic 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 for simulating a 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., for implementing the method of locating errors of the present application) as well as data to be processed (e.g., the memory may store temporary code generated during the compilation process). The processor 102 may also access memory-stored program instructions and data and execute the program instructions to operate on the data to be processed. The memory 104 may include volatile memory devices or non-volatile memory devices. In some embodiments, the memory 104 may include Random Access Memory (RAM), read Only Memory (ROM), optical disks, magnetic disks, hard disks, solid State Disks (SSDs), flash memory, memory sticks, and the like.

The network interface 106 may be configured to provide communications 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 above. It is to be understood 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, transceivers, modems, routers, gateways, adapters, cellular network chips, and the like.

Peripheral interface 108 may be configured to connect 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, touch pads, touch screens, microphones, various sensors, and output devices such as displays, speakers, vibrators, indicator lights, and the like.

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

It should be noted that although the 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 normal 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 need not include all of the components shown in the figures.

FIG. 2 shows a schematic diagram of a simulation tool 202 and a debugging tool 200 according to an embodiment of the application. Simulation tool 202 and debug tool 200 may be computer programs running on host 100.

In the field of chip design, a design may be simulated using a simulation tool. The simulation tool may be, for example, a GalaxSim simulation tool available from china chapters science and technology ltd. The example simulation tool 202 shown in FIG. 2 may include a compiler 120 and a simulator 220. Compiler 120 may compile a design (e.g., verification system 210) into object code 204, simulator 220 may simulate from object code 204, and output simulation results 206. For example, the simulation tool 202 may output simulation results (e.g., a simulation waveform diagram) 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. The verification environment 210b may also be referred to as a test bench (testbench). For example, verification environment 210b may be a UVM environment.

The debug tool 200 may also read the simulation results 206. The debugging tool 200 may be, for example, a Fusion Debug tool available from Chihua Chapter science and technology, inc. For example, the debugging tool 200 may read the simulation results 206 stored in a waveform file and generate corresponding simulation waveforms for debugging. Debug tool 200 can also read the description of verification system 210 (typically SystemVerilog and Verilog code) and display to the user. The debugging tool 200 may also generate various graphical interfaces (e.g., debugging windows) to facilitate the debugging work for the user. The user may issue a debug command to the debug tool 200 (e.g., run the verification system 210 to a certain point), which the debug tool 200 then applies to the simulation tool 202 to execute accordingly. Debug tool 200 may also read the log file. Various information of the simulation process can be included in the log file, including information of simulation errors, a row number of error reporting, a time when the simulation errors occur, and the like.

It will be appreciated that in addition to interfacing with simulation tool 202, debug tool 200 may also interface with a hardware simulator (emulator).

A significant feature in the debugging process is the enormous amount of simulation results 206 read by the debugging tool 200. The simulation results 206 may include waveform files, log files, coverage databases, and the like. The waveform file may contain a large number of signal variations over a long simulation time, and the file volume may be on the order of hundreds of GB to a few TB. And a log file may include a plurality of log messages, which may number in the tens of thousands, or even hundreds of thousands. This makes it difficult for a user to quickly locate errors in the logic system design 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 a storage medium based on a log file, which are used for extracting key information by processing log 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 illustrates an exemplary diagram of a log file window 300 according to an embodiment of the application.

As shown in fig. 3, the contents of a log message 310 may be displayed in a log file window 300. In the contents of exemplary log message 310, a UVM error is reported, including where the error is located in the logical system design (e.g., 163 lines of MRV55_ l1i _ id _ model. Sv file), the time the error occurred (e.g., 811530 ns), event information (e.g., axi transaction), and address information (e.g., tr _ addr = fff 001).

The debugging tool 200 may process the 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, debugging tool 200 may utilize Natural Language Processing (NLP) techniques to determine primary key information included in log message 310, such as the location in the logic system design where the error is located, the time at which the error occurred, event information, and address information. Based on the primary key information, debugging tool 200 may further determine secondary key information from source code of the logic system design. For example, debug tool 200 may determine signals (e.g., a and b signals, not shown) related to the error based on where the error is located in the logic system design (e.g., 163 rows of the MRV55_ l1i _ id _ model. Debug tool 200 may also find the function associated with the error in the stack of memory based on the address information of the error and the time the error occurred, etc.

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

As shown in FIG. 4, the joint debugging interface 400 may include a plurality of debugging

windows

300, 402, 404, and 406, each of which corresponds to a debugging functionality. A user selects a log message (e.g., message 310) in log file window 300, and interface 400 may enable corresponding debugging functions in multiple debugging windows, respectively, according to the log message selected by the user.

In some embodiments, window 402 and corresponding debugging functionality may be used to display a waveform diagram of signals associated with log message 310. It is understood that the waveform shown in the waveform diagram corresponds to the time (e.g., 811530 ns) at which the error of the log message occurs.

In some embodiments, window 404 and corresponding debugging functionality may be used to generate and display a circuit diagram corresponding to log message 310. The debug tool 300 can determine the circuit module corresponding to the 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 debugging functionality may be used to display the 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 to be appreciated that the debugging tool 200 can provide more or fewer debugging windows in the joint debugging interface 400 as desired by the user. Also, for some log messages, debug tool 200 may not be able to provide a full debug window, but only a partial debug window. For example, when the signal to which the log message relates is not coverage counted, debugging tool 200 cannot call window 406 for displaying the coverage of the signal.

In some embodiments, when the user switches from the log message 310 to another log message, the debugging tool 200 may adjust the information displayed in the multiple debugging windows in the joint debugging interface 400 according to the new log message to correspond to the new log message, thereby implementing joint debugging linkage of the log message and multiple debugging functions. Therefore, on one hand, a 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 debugging of the user is facilitated.

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

FIG. 5 shows a flowchart of a log file-based debugging method 500 according to an embodiment of the 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 simulation results (e.g., simulation results 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, which 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 can receive an instruction for a user to select a target log message (e.g., message 310 of FIG. 3) among the plurality of log messages.

At step 506, debug tool 200 may determine key information for a target log message, wherein the key information includes 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 for a target log message, debugging tool 200 may determine primary key information included in the target log message using natural language processing; and determining the secondary key information based on the description of the logic system design using the primary key information. The primary key information may be obtained directly from the log message. For example, the primary key information may include where the simulation error is located in the logic system design (e.g., line 163 of the MRV55_ l1i _ id _ model.sv file in message 310 of fig. 3), the time at which the simulation error occurred (e.g., 811530ns in message 310 of fig. 3), event information corresponding to the simulation error (e.g., axi transaction in message 310 of fig. 3), and address information of the simulation error (e.g., tr _ addr = fff001 in message 310 of fig. 3). The secondary key information may include signals related to the simulated error (e.g., a and b signals) determined using the primary key information of where the simulated error is located in the logic system design, functions associated with the simulated error determined using the primary key information of address information of the simulated error and the time at which the simulated error occurred, and so on.

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

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

In some embodiments, the debugging tool 200 may extract waveform data corresponding to a target signal in the waveform file according to 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 the 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 logic system design.

In some embodiments, the debugging 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 key information is acquired by processing a large amount of log messages through the natural language, and the corresponding debugging function is called according to the key information, so that the embodiment of the application can allow a user to adjust the information displayed in a plurality of debugging windows in the combined debugging interface 400 by selecting different log messages, and the joint debugging linkage of the log messages and a plurality of debugging functions is realized. Therefore, on one hand, a 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 debugging of the user is facilitated.

The embodiment of the application also provides the 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 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 may 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 may also be possible or may be advantageous.

Those of ordinary skill in the art will understand that: the discussion of any embodiment above is meant to be exemplary only, and is not intended to intimate that the scope of the disclosure, including the claims, is limited to these examples; within the context of the present application, features from the above embodiments or from different embodiments may also be combined, 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 detail for the sake of brevity.

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

The present application is intended to embrace all such alternatives, modifications and variances which fall within the broad scope of the appended claims. Therefore, any omissions, modifications, substitutions, improvements, and the like that may be made without departing from the spirit and principles of the application are intended to be included within the scope of the application.

Claims

1. A log file-based debugging method comprises the following steps:

receiving a simulation result of a 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 a user to select a target log message from the plurality of log messages;

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 plurality of debugging functions processing the target log message in a plurality of debugging windows.

2. A debugging method in accordance with claim 1, wherein the key information comprises primary key information and secondary key information, determining key information for a target log message further comprising:

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

determining the secondary key information based on the description of the logic system design using the primary key information.

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

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

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

4. A debugging method in accordance with claim 2, wherein displaying results of the plurality of debugging functions processing the target log message in a plurality of debugging 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. A debugging method in accordance with claim 1, wherein the simulation results further comprise a coverage database, and displaying the results of the plurality of debugging functions processing the target log message in a plurality of debugging windows, respectively, further comprises:

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

and responding to the found coverage rate of the target signal, and displaying the coverage rate of the target signal in a coverage rate window.

6. An electronic device comprises

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 of claims 1-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 of claims 1 to 5.