Debugging method and device and storage medium

By reading simulation data and restoring simulation while the emulator is suspended, the problem of low simulation testing and debugging efficiency in the existing technology is solved, and dynamic debugging is realized during the simulation process, which improves the overall efficiency.

CN119885991APending Publication Date: 2025-04-25XINHUAZHANG TECH (XIAMEN) CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411830846.8
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-12-12
Publication Date
2025-04-25

AI Technical Summary

Technical Problem

In the prior art, the simulation test time is long and it is impossible to debug during the simulation test, resulting in low debugging efficiency.

Method used

When the emulator is emulating, in response to the pause simulation instruction, the emulator is controlled to pause simulation; when the pause state, the simulation data is read and the simulation test continues when the simulation is restored.

Benefits of technology

Debugging during simulation testing is realized, reducing the alternating process between simulation testing and debugging, and improving debugging efficiency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119885991A_ABST
    Figure CN119885991A_ABST
Patent Text Reader

Abstract

The embodiment of the invention provides a debugging method and device and a storage medium. The method comprises the steps of controlling the simulator to suspend simulation in response to an instruction of suspending simulation when the simulator is in a simulation state; acquiring target simulation data from a register of the simulator in response to an instruction for reading the simulation data in a state that the simulator pauses simulation; in the state that the simulator pauses simulation, responding to a simulation recovery instruction, and controlling the simulator to recover simulation.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The embodiments of the present application relate to the field of chip verification technology, and in particular to a debugging method, device and storage medium. Background Art

[0002] In the field of integrated circuit verification, in order to verify whether the logic system design is correct, a verification environment needs to be designed to verify the logic system design. After compilation, the verification environment can be run on a computer or hardware simulation device to simulate and test various functions of the logic system design, thereby verifying whether the logic system design is correct.

[0003] In the related art, debugging can only be performed after the simulation test is completed. However, the simulation test takes a long time. Debugging is performed after the simulation test is completed, and simulation testing is performed again after debugging is completed, which takes a long time and has low efficiency. Summary of the invention

[0004] A first aspect of the present application provides a debugging method, comprising:

[0005] In a state where the simulator is simulating, in response to an instruction to suspend simulation, controlling the simulator to suspend simulation;

[0006] In a state where the simulator is in a paused state, in response to an instruction to read the simulation data, the target simulation data is obtained from a register of the simulator;

[0007] In a state where the simulator suspends simulation, in response to an instruction to resume simulation, the simulator is controlled to resume simulation.

[0008] The second aspect of the present application provides an electronic device, which includes a memory for storing a group of instructions and at least one processor configured to execute the group of instructions so that the electronic device executes the method according to the first aspect.

[0009] A third aspect of the present application provides a non-transitory computer-readable storage medium, which stores a set of instructions for a computer, and when the set of instructions is executed, causes the computer to perform the method as described in the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to more clearly illustrate the technical solutions in the present application or related technologies, the drawings required for use in the embodiments or related technical descriptions are briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0011] Figure 1A schematic diagram of a host according to an embodiment of the present application is shown.

[0012] Figure 2 A schematic diagram of a simulation tool and a debugging tool according to an embodiment of the present application is shown.

[0013] Figure 3 A schematic diagram of a debugging method according to an embodiment of the present application is shown.

[0014] Figure 4 A schematic diagram of a debugging method according to an embodiment of the present application is shown.

[0015] Figure 5 A flow chart of a method for pausing simulation according to an embodiment of the present application is shown.

[0016] Figure 6 A schematic diagram of a debugging method according to an embodiment of the present application is shown.

[0017] Figure 7 A flowchart of a debugging method according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0018] In order to make the purpose, technical solutions and advantages of the present application more clear, the principles and spirit of the present application will be described below with reference to several exemplary embodiments. It should be understood that these embodiments are provided only to enable those skilled in the art to better understand and implement the present application, and are not intended to limit the scope of the present application in any way. On the contrary, these embodiments are provided to make the present application more thorough and complete, and to fully convey the scope of the present application to those skilled in the art.

[0019] It should be understood herein that any number of elements in the drawings is for illustration rather than limitation, and any naming is only for distinction rather than having any limiting meaning.

[0020] It should be noted that, unless otherwise defined, the technical terms or scientific terms used in the embodiments of the present application should be understood by people with ordinary skills in the field to which the present application belongs. The "first", "second" and similar words used in the embodiments of the present application do not represent any order, quantity or importance, but are only used to distinguish different components. "Including" or "comprising" and similar words mean that the elements or objects appearing in front of the word cover the elements or objects listed after the word and their equivalents, without excluding other elements or objects. "Connecting" or "connected" and similar words are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. "Up", "down", "left", "right" and the like are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may also change accordingly. The article "one" or "a" before the element does not exclude the existence of multiple such elements.

[0021] The principles and spirit of the present application are explained in detail below with reference to several representative implementations of the present application.

[0022] Simulation testing is to apply various stimuli to the logic system design on the host running the simulation test system to detect whether the logic system design can achieve the predetermined functions.

[0023] Figure 1 FIG. 1 is a schematic diagram of a host 100 according to an embodiment of the present application. The host 100 may be an electronic device running a simulation system. Figure 1 As shown, the host 100 may include: a processor 102, a memory 104, a network interface 106, a peripheral interface 108 and a bus 110. The processor 102, the memory 104, the network interface 106 and the peripheral interface 108 are connected to each other in communication within the host through the bus 110.

[0024] 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 related to the technology described in this application. In some embodiments, processor 102 may also include multiple processors integrated into a single logical component. Figure 1 As shown, the processor 102 may include a plurality of processors 102a, 102b, and 102c.

[0025] The memory 104 may be configured to store data (eg, instruction sets, computer codes, intermediate data, etc.). In some embodiments, the simulation test system for simulation test design may be a computer program stored in the memory 104. Figure 1 As shown, the data stored in the memory may include program instructions (e.g., program instructions for implementing the method for locating errors in the logic system design of the present application) and data to be processed (e.g., the memory may store temporary codes generated during the compilation process). The processor 102 may also access the program instructions and data stored in the memory, and execute the program instructions to operate on the data to be processed. The memory 104 may include a volatile storage device or a non-volatile storage device. In some embodiments, the memory 104 may include a random access memory (RAM), a read-only memory (ROM), an optical disk, a magnetic disk, a hard disk, a solid-state drive (SSD), a flash memory, a memory stick, etc.

[0026] The network interface 106 can be configured to provide communication with other external devices to the host 100 via a network. The network can be any wired or wireless network capable of transmitting and receiving data. For example, the network can 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 thereof. It is understood that the type of network is not limited to the above specific examples. In some embodiments, the network interface 106 can include any number of network interface controllers (NICs), radio frequency modules, transceivers, modems, routers, gateways, adapters, cellular network chips, etc., in any combination.

[0027] The peripheral interface 108 can be configured to connect the host 100 to one or more peripheral devices to achieve information input and output. For example, the peripheral devices can include input devices such as a keyboard, a mouse, a touch pad, a touch screen, a microphone, and various sensors, and output devices such as a display, a speaker, a vibrator, and an indicator light.

[0028] The bus 110 may be configured to transmit 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), etc.

[0029] It should be noted that, although the above host architecture only shows the processor 102, the memory 104, the network interface 106, the peripheral interface 108 and the bus 110, in the specific implementation process, the host architecture may also include other components necessary for normal operation. In addition, it can be understood by those skilled in the art that the above host architecture may also only include the components necessary for implementing the embodiment of the present application, and does not necessarily include all the components shown in the figure.

[0030] Figure 2 The schematic diagram of the simulation tool 202 and the debugging tool 200 according to the embodiment of the present application is shown. The simulation tool 202 and the debugging tool 200 may be computer programs running on the host 100.

[0031] In the field of chip design, a design can usually be simulated using a simulation tool, such as the GalaxSim simulation tool produced by Xinhuazhang Technology Co., Ltd. Figure 2 The exemplary simulation tool 202 shown may include a compiler 120 and a simulator 220. The compiler 120 may compile a design (e.g., a verification system 210) into a target code 204, and the simulator 220 may perform simulation according to the target code 204 and output a simulation result 206. For example, the simulation tool 202 may output the simulation result (e.g., a simulation waveform) via Figure 1 The 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 testbench. For example, the verification environment 210b may be a UVM environment.

[0032] The simulation result 206 may also be stored in the form of a waveform database. The waveform database storing the waveform data may also be referred to as a waveform file.

[0033] The debugging tool 200 can also read the simulation result 206. The debugging tool 200 can be, for example, the Fusion Debug debugging tool produced by Xinhuazhang Technology Co., Ltd. For example, the debugging tool 200 can read the simulation result 206 stored in a waveform file, and generate a corresponding simulation waveform for debugging. The debugging tool 200 can also read the description of the verification system 210 (usually SystemVerilog and Verilog code) and display it to the user. The debugging tool 200 can also generate various graphical interfaces (for example: debugging window) to facilitate the user's debugging work. The user can issue a debugging command to the debugging tool 200 (for example, run the verification system 210 to a certain moment), and the debugging tool 200 applies the debugging command to the simulation tool 202 to execute accordingly. The debugging tool 200 can also read a log file. The log file can include various information of the simulation process, including information of the simulation error, the line number of the error, the time when the simulation error occurred, etc.

[0034] It is understandable that, in addition to being connected to the simulation tool 202 , the debugging tool 200 may also be connected to a hardware emulator.

[0035] Figure 3 A schematic diagram of a debugging method according to an embodiment of the present application is shown.

[0036] The compiler 120 may compile the C code into an elf file and a hex file, transmit the elf file to the GDB debugger, and transmit the hex file to the emulator 220 .

[0037] Among them, C code is used to define the software logic and algorithms running on the SoC.

[0038] Among them, the elf file can be used as the input file of the GDB debugger to debug the C code or assembly code, and track and debug the rtl code from the perspective of debugging the C code / assembly code.

[0039] The simulator 220 may process the SoC design file through the GalaxSim simulator or other simulators to obtain an xSim executable file.

[0040] The generated xSim executable file may be run through the simulator 220 to simulate the behavior of the SoC.

[0041] The simulator 220 can execute the hex file through the xSim executable file to perform simulation, obtain the simulation result 206, and store the simulation result 206 in the log database and the waveform database.

[0042] Among them, the hex file is loaded into the memory as an input file of the CPU simulation to start executing the instruction code in the hex file, which is equivalent to executing the elf file generated by the C code.

[0043] The GDB debugger server in the debugging tool 200 can communicate with the GDB debugger, receive the debugging command transmitted by the GDB debugger, and the GDB debugger server can process the debugging command.

[0044] The GDB debugger server in the debugging tool 200 can communicate with the emulator 220, and can obtain data in the log database from the emulator 220 via a converter. Specifically, the converter can perform data conversion on the simulation result 206 in the log database according to the debugging configuration file to obtain waveform data, and transmit the waveform data to the debugging tool 200. The waveform database can also be obtained from the emulator 220. Control commands can also be transmitted to the emulator 220.

[0045] The debugging tool 200 may obtain the assembly code from the compiler 120 and debug the assembly code based on the waveform data.

[0046] In the above embodiment, the user can only develop and debug the C code after the CPU hardware simulation test is completed. This stage has reached the later stage of the chip development process. Users can usually only debug the software code (such as C code) and hardware code (chip rtl code) through the waveform data generated after running the simulation. It is time-consuming to run a complete simulation, especially the large SOC simulation is very time-consuming. After each simulation, debugging is performed, and then errors are found. After correcting the errors, the simulation is rerun, which is repeated and inefficient. In addition, the log message (CPUlog) after the simulation is completed usually only saves key information, rather than all the information in the simulation process. If you need to view any other information, you need to change the design to write out the required information, then recompile, and rerun the simulation, which is very time-consuming; in addition, the complete simulation data file may be very large, and storing and loading this data will take up a lot of disk space and memory resources. Therefore, how to debug during the simulation process is an urgent problem to be solved.

[0047] Figure 4 A schematic diagram of a debugging method according to an embodiment of the present application is shown.

[0048] The compiler 120 may compile the C code into an elf file and a hex file, transmit the elf file to the GDB debugger, and transmit the hex file to the emulator 220 .

[0049] Among them, C code is used to define the software logic and algorithms running on the SoC.

[0050] Among them, the elf file can be used as the input file of the GDB debugger to debug the C code or assembly code, and track and debug the rtl code from the perspective of debugging the C code / assembly code.

[0051] The simulator 220 may process the SoC design file through the GalaxSim simulator or other simulators to obtain an xSim executable file.

[0052] The generated xSim executable file may be run through the simulator 220 or directly run to simulate the behavior of the SoC.

[0053] The simulator 220 can execute the hex file through the xSim executable file to perform simulation, obtain the simulation result 206, and store the simulation result 206 in the log database and the waveform database.

[0054] Among them, the hex file is loaded into the memory as an input file of the CPU simulation to start executing the instruction code in the hex file, which is equivalent to executing the elf file generated by the C code.

[0055] The GDB debugger can pause the simulation and read the simulation data in the register of the simulator 220 when the simulator 220 has not completed the simulation, so that the user can dynamically perform GDB debugging during the simulation process.

[0056] When the emulator 220 is in the emulation state, the GDB debugger can transmit an instruction for pausing the emulation to the emulator 220 to control the emulator to suspend the emulation.

[0057] The suspend conditions supported by the simulator 220 are as follows:

[0058] Event: When the value of a signal changes (for example, from 0 to 1).

[0059] Specific time: Stop the simulation at a specific time point.

[0060] A specific line in the source code: Stops when execution reaches a certain line in the source code.

[0061] Task or Function: Stop in a specific task or function.

[0062] Assertion trigger: Use the assertion command to stop the simulation. Assertions are usually used to verify whether certain conditions in the design are met.

[0063] However, during the debugging process of the CPU, it is necessary to control the program counter PC (Program Counter) to pause when the register value is equal to a certain value, but the simulator 220 does not support the conditional pause of "the value of the signal is equal to a specific value". Therefore, it is necessary to solve the conditional pause of "the value of the signal is equal to a specific value" to pause the simulator 220.

[0064] Figure 5 A flow chart of a method for pausing simulation according to an embodiment of the present application is shown.

[0065] Among them, the current time is t0.

[0066] The simulator 220 starts or resumes running, sets a time condition to pause, and runs for a period of time dt, for example, 10 ns.

[0067] After pausing, obtain the required signal waveform data within the time from t0 to t0+dt.

[0068] Checks whether the waveform data meets the specified value starting from t0.

[0069] If not, determine whether the simulation is finished. If the simulation is finished, stop the simulation. If the simulation is not finished, update the current time t0 and re-execute the above steps.

[0070] If it is satisfied, find the time point t1 that satisfies the specific value.

[0071] The simulator 220 rewinds to time t0.

[0072] Restart and set the running time t1-t0.

[0073] At this time, time t1 is reached and a pause occurs.

[0074] When the simulator 220 is in a state of pausing simulation, the GDB debugger may transmit an instruction to read simulation data to the simulator 220 , and obtain target simulation data from the register of the simulator 220 .

[0075] When the simulator 220 is in a state of pausing simulation, the GDB debugger may transmit a resume simulation instruction to the simulator 220 to control the simulator 220 to resume simulation.

[0076] When the emulator 220 is in a state of pausing simulation, the GDB debugger may transmit an instruction for writing debugging data to the emulator 220 , and write the target debugging data into the emulator 220 .

[0077] The emulator 220 may receive the instruction for writing debugging data transmitted by the GDB debugger, wherein the instruction for writing debugging data includes C code debugging data; and write the C code debugging data into the emulator 220 .

[0078] The emulator 220 may receive the instruction for writing debugging data transmitted by the GDB debugger, wherein the instruction for writing debugging data includes assembly code debugging data; and write the assembly code debugging data into the emulator 220 .

[0079] The GDB debugger may communicate with the emulator 220 through a GDB debugger server.

[0080] The GDB debugger server may include a GDB communication protocol module, a command processing module, an interactive control module, and a WFDB tool (Waveform Database, a set of file standards for reading and storing physiological signal data and related annotations) module.

[0081] Among them, commands can be dynamically input through the interactive control module during simulation operation to change the simulation behavior.

[0082] In the embodiment of the present application, by designing the conditions for pausing simulation, the simulation can be paused when the simulator 220 has not yet completed the simulation, and the simulation data in the register of the simulator 220 can be read, so that the user can debug during the simulation process.

[0083] In the above embodiment, the rtl code is tracked and debugged from the perspective of debugging c code / assembly code through the GDB debugger. However, in some application scenarios, there is a demand for directly debugging rtl code.

[0084] Figure 6 A schematic diagram of a debugging method according to an embodiment of the present application is shown.

[0085] The compiler 120 may compile the C code into an elf file and a hex file, transmit the elf file to the GDB debugger, and transmit the hex file to the emulator 220 .

[0086] Among them, C code is used to define the software logic and algorithms running on the SoC.

[0087] Among them, the elf file can be used as the input file of the GDB debugger to debug the C code or assembly code, and track and debug the rtl code from the perspective of debugging the C code / assembly code.

[0088] The simulator 220 may process the SoC design file through the GalaxSim simulator or other simulators to obtain an xSim executable file.

[0089] The generated xSim executable file may be run through the simulator 220 or directly run to simulate the behavior of the SoC.

[0090] The simulator 220 can execute the hex file through the xSim executable file to perform simulation, obtain the simulation result 206, and store the simulation result 206 in the log database and the waveform database.

[0091] Among them, the hex file is loaded into the memory as an input file of the CPU simulation to start executing the instruction code in the hex file, which is equivalent to executing the elf file generated by the C code.

[0092] The GDB debugger can read the simulation data in the register of the simulator 220 when the simulator 220 is in the simulation state, so that the user can dynamically perform GDB debugging during the simulation process.

[0093] When the emulator 220 is in the emulation state, the GDB debugger can transmit an instruction for pausing the emulation to the emulator 220 to control the emulator to suspend the emulation.

[0094] The suspend conditions supported by the simulator 220 are as follows:

[0095] Event: When the value of a signal changes (for example, from 0 to 1).

[0096] Specific time: Stop the simulation at a specific time point.

[0097] A specific line in the source code: Stops when execution reaches a certain line in the source code.

[0098] Task or Function: Stop in a specific task or function.

[0099] Assertion trigger: Use the assertion command to stop the simulation. Assertions are usually used to verify whether certain conditions in the design are met.

[0100] However, during the debugging process of the CPU, it is necessary to control the program counter PC (Program Counter) to pause when the register value is equal to a certain value, but the simulator 220 does not support the conditional pause of "the value of the signal is equal to a specific value". Therefore, it is necessary to solve the conditional pause of "the value of the signal is equal to a specific value" to pause the simulator 220.

[0101] Figure 5 A flow chart of a method for pausing simulation according to an embodiment of the present application is shown.

[0102] Among them, the current time is t0.

[0103] The simulator 220 starts or resumes running, sets a time condition to pause, and runs for a period of time dt, for example, 10 ns.

[0104] After pausing, obtain the required signal waveform data within the time from t0 to t0+dt.

[0105] Checks whether the waveform data meets the specified value starting from t0.

[0106] If not, determine whether the simulation is finished. If the simulation is finished, stop the simulation. If the simulation is not finished, update the current time t0 and re-execute the above steps.

[0107] If it is satisfied, find the time point t1 that satisfies the specific value.

[0108] The simulator 220 rewinds to time t0.

[0109] Restart and set the running time t1-t0.

[0110] At this time, time t1 is reached and the simulation is paused.

[0111] When the simulator 220 is in a state of pausing simulation, the GDB debugger may transmit an instruction to read simulation data to the simulator 220 , and obtain target simulation data from the register of the simulator 220 .

[0112] When the simulator 220 is in a state of pausing simulation, the GDB debugger may transmit a resume simulation instruction to the simulator 220 to control the simulator 220 to resume simulation.

[0113] When the emulator 220 is in a state of pausing simulation, the GDB debugger may transmit an instruction for writing debugging data to the emulator 220 , and write the target debugging data into the emulator 220 .

[0114] The emulator 220 may receive the instruction for writing debugging data transmitted by the GDB debugger, wherein the instruction for writing debugging data includes C code debugging data; and write the C code debugging data into the emulator 220 .

[0115] The emulator 220 may receive the instruction for writing debugging data transmitted by the GDB debugger, wherein the instruction for writing debugging data includes assembly code debugging data; and write the assembly code debugging data into the emulator 220 .

[0116] The emulator 220 may receive the instruction for writing debug data transmitted by the debugging tool 200 , wherein the instruction for writing debug data includes register transfer level code debugging data; and write the register transfer level code debugging data into the emulator 220 .

[0117] Among them, register transfer level code refers to the hardware design code described at the register transfer level (RTL). At the RTL level, hardware design focuses on the flow of data between registers and the logical relationship between them. RTL code is usually written in a hardware description language (HDL), such as Verilog or VHDL.

[0118] The GDB debugger may communicate with the emulator 220 and the debugging tool 200 through the GDB debugger server.

[0119] The GDB debugger server may include a GDB communication protocol module, a command processing module and an interactive control module.

[0120] The debugging tool 200 may include a waveform debugging module, a source code debugging module, a low power debugging module, a circuit diagram debugging module, a coverage debugging module, and other debugging modules.

[0121] Waveform Debug:

[0122] Waveform debugging allows engineers to observe how signals change over time to verify that the design is correct. Waveform data is captured and analyzed in the waveform window.

[0123] Source Debug:

[0124] Source code debugging usually involves direct inspection and modification of the code. You can debug module code, modify parameters to change the behavior of the module, and modify suspected problematic code.

[0125] Low Power Debug:

[0126] Low power debugging involves debugging in different low power modes (such as Standby mode).

[0127] Coverage Debug:

[0128] Coverage debugging focuses on the completeness of the test, that is, what proportion of the code is covered by the test. You can generate a coverage report that shows the number of lines executed, the number of lines not executed, and the coverage percentage. In addition, you can also view the specific file lines that are not executed, as well as the branch coverage.

[0129] Other Debug Modules:

[0130] In addition to the specific debugging areas mentioned above, there are many other debugging modules and tools.

[0131] The debugging tool 200 may include a WFDB tool module (Waveform Database), which is a set of file standards for reading and storing physiological signal data and related annotations.

[0132] In the embodiment of the present application, the rtl code can be tracked and debugged from the perspective of debugging c code / assembly code through the GDB debugger; the rtl code can also be debugged directly.

[0133] The embodiment of the present application also provides a debugging method.

[0134] Figure 7 FIG. 7 is a flowchart of a debugging method 700 according to an embodiment of the present application. The method 700 may be Figure 1 The method 700 is executed by the host 100, more specifically, by the debugging tool 200 running on the host 100. The method 700 may include the following steps.

[0135] In step 702 , the debugging tool 200 may control the simulator 220 to suspend simulation in response to an instruction to suspend simulation while the simulator 220 is in the simulating state.

[0136] In some embodiments, the instruction to pause the simulation includes a preset value;

[0137] The method of controlling the simulator 220 to suspend simulation in response to an instruction to suspend simulation while the simulator 220 is simulating comprises:

[0138] Controlling the simulator 220 to simulate a first time period, obtaining simulation data from a register of the simulator 220, and searching for the preset value in the simulation data;

[0139] In response to finding the preset value in the simulation data, determining a simulation time point corresponding to the preset value, controlling the simulator 220 to re-simulate from the start time point of the first time period, and pausing the simulation at the simulation time point;

[0140] or,

[0141] In response to not finding the preset value in the simulation data, the simulator 220 is controlled to continue simulating the first time period until the preset value is found in the simulation data.

[0142] In some embodiments, the control simulator 220 re-simulates from the starting time point of the first time period and pauses the simulation at the simulation time point, including:

[0143] Determine a second time period based on the starting time point and the simulation time point;

[0144] The control simulator 220 re-simulates the second time period from the starting time point and then pauses the simulation.

[0145] In some embodiments, the controlling simulator 220 to simulate a first time period, obtaining simulation data from a register of the simulator 220, and searching for the preset value in the simulation data include:

[0146] The simulation data includes waveform data.

[0147] In step 704 , the debugging tool 200 may obtain the target simulation data from the register of the simulator 220 in response to an instruction to read simulation data while the simulator 220 is in a state of pausing simulation.

[0148] In step 706 , the debugging tool 200 may control the simulator 220 to resume simulation in response to an instruction to resume simulation while the simulator 220 is in a state of suspending simulation.

[0149] In some embodiments, the method further comprises:

[0150] The debugging tool 200 may write the target debugging data into the emulator 220 in response to an instruction to write debugging data while the emulator 220 is in a state where the emulator 220 is suspending simulation.

[0151] In some embodiments, in a state where the emulator 220 is in a paused state, in response to an instruction to write debug data, writing the target debug data into the emulator 220 comprises:

[0152] Receiving a first debugger (eg, Figure 4 The instruction for writing debugging data transmitted by the GDB debugger in the embodiment of the present invention, wherein the instruction for writing debugging data includes C code debugging data;

[0153] The C code debugging data is written into the simulator 220 .

[0154] In some embodiments, in a state where the emulator 220 is in a paused state, in response to an instruction to write debug data, writing the target debug data into the emulator 220 comprises:

[0155] Receiving a first debugger (eg, Figure 4 The instruction for writing debugging data transmitted by the GDB debugger in the embodiment of the present invention, wherein the instruction for writing debugging data includes assembly code debugging data;

[0156] The assembly code debugging data is written into the simulator 220 .

[0157] In some embodiments, in a state where the emulator 220 is in a paused state, in response to an instruction to write debug data, writing the target debug data into the emulator 220 comprises:

[0158] Receiving a second debugger (eg, Figure 6 The instruction for writing debug data transmitted by the debugging tool 200 in the embodiment of the present invention, wherein the instruction for writing debug data includes register transfer level code debug data;

[0159] The register transfer level code debugging data is written into the simulator 220 .

[0160] In the embodiment of the present application, by designing the conditions for pausing simulation, the simulation can be paused when the simulator 220 has not yet completed the simulation, and the simulation data in the register of the simulator 220 can be read, so that the user can debug during the simulation process.

[0161] The present application also provides an electronic device. The electronic device may be Figure 1 The electronic device may include a memory for storing a set of instructions; and at least one processor configured to execute the set of instructions so that the electronic device performs the method 700.

[0162] The embodiment of the present application further provides a non-transitory computer-readable storage medium. The non-transitory computer-readable storage medium stores a set of computer instructions, and the set of instructions is used to make the computer perform method 700 when executed.

[0163] Some embodiments of the present application are described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0164] Those skilled in the art should understand that the discussion of any of the above embodiments is merely illustrative and is not intended to imply that the scope of the present application (including the claims) is limited to these examples. In line with the concept of the present application, the technical features in the above embodiments or different embodiments may be combined, 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 detail for the sake of simplicity.

[0165] Although the present application has been described in conjunction with specific embodiments of the present application, many replacements, modifications and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may use the embodiments discussed.

[0166] This application is intended to cover all such substitutions, modifications and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this application should be included in the scope of protection of this application.

Claims

1. A debugging method, characterized in that: include: In a state where the simulator is simulating, in response to an instruction to suspend simulation, controlling the simulator to suspend simulation; In a state where the simulator is in a paused state, in response to an instruction to read the simulation data, the target simulation data is obtained from a register of the simulator; In a state where the simulator suspends simulation, in response to an instruction to resume simulation, the simulator is controlled to resume simulation.

2. The method according to claim 1, characterized in that The method further comprises: In a state where the emulator suspends emulation, target debug data is written into the emulator in response to an instruction to write debug data.

3. The method according to claim 1, characterized in that The instruction to pause the simulation includes a preset value; The method of controlling the simulator to suspend simulation in response to an instruction to suspend simulation while the simulator is simulating comprises: Controlling the simulator to simulate a first time period, obtaining simulation data from a register of the simulator, and searching for the preset value in the simulation data; In response to finding the preset value in the simulation data, determining a simulation time point corresponding to the preset value, controlling the simulator to re-simulate from the start time point of the first time period, and pausing the simulation at the simulation time point; or, In response to not finding the preset value in the simulation data, controlling the simulator to continue simulating the first time period until finding the preset value in the simulation data.

4. The method according to claim 3, characterized in that The controlling simulator to re-simulate from the starting time point of the first time period and pausing the simulation at the simulation time point comprises: Determine a second time period based on the starting time point and the simulation time point; The simulator is controlled to re-simulate the second time period from the starting time point and then pause the simulation.

5. The method according to claim 3, characterized in that: The controlling simulator to simulate a first time period, obtaining simulation data from a register of the simulator, and searching for the preset value in the simulation data include: The simulation data includes waveform data.

6. The method according to claim 2, characterized in that The method of writing target debugging data into the emulator in response to an instruction to write debugging data while the emulator is in a state where the emulator is suspended from emulation comprises: receiving the instruction for writing debugging data transmitted by the first debugger, wherein the instruction for writing debugging data includes C code debugging data; Write the C code debugging data into the emulator.

7. The method according to claim 2, characterized in that The method of writing target debugging data into the emulator in response to an instruction to write debugging data while the emulator is in a state where the emulator is suspended from emulation comprises: receiving the instruction for writing debugging data transmitted by the first debugger, wherein the instruction for writing debugging data includes assembly code debugging data; The assembly code debugging data is written into the emulator.

8. The method according to claim 2, characterized in that: The method of writing target debugging data into the emulator in response to an instruction to write debugging data while the emulator is in a state where the emulator is suspended from emulation comprises: receiving the instruction for writing debugging data transmitted by the second debugger, wherein the instruction for writing debugging data includes register transfer level code debugging data; The register transfer level code debug data is written into the simulator.

9. An electronic device, comprising: a memory for storing a set of computer instructions; as well as At least one processor is used to execute the computer instructions so that the electronic device performs the method as claimed in any one of claims 1 to 8. 10 . A non-transitory computer-readable storage medium storing computer instructions for causing a computer to execute the method according to claim 1 .