CN117172203A - Methods, electronic devices and storage media for processing script commands - Google Patents

Abstract

This application provides a method, electronic device, and storage medium for processing script commands. The method includes: reading a script associated with a logical system design, the script including a plurality of script commands; obtaining an identifier included in the script; and determining a component to be analyzed among the plurality of script commands according to the identifier. one or more target script commands; running the script to obtain a log message corresponding to the one or more target script commands; and analyzing the log message based on the identifier.

Description

Methods, electronic devices and storage media for processing script commands

Technical field

This application relates to the field of chip verification technology, and in particular, to a method, electronic device, and storage medium for processing script commands.

Background technique

Hardware simulation tools (eg, prototype verification boards or emulators) can prototype and debug a logic system design that includes one or more modules. The logic system design may be, for example, a design for an application-specific integrated circuit (Application Specific Integrated Circuit, ASIC for short) or a system-on-chip (System-On-Chip, SOC for short). Therefore, the logic system design tested in the simulation tool can also be called the design under test (DesignUnderTest, referred to as DUT). The simulation tool can simulate the design under test through one or more configurable components (for example, Field Programmable Gate Array (FPGA)), including performing various operations of the design under test, so as to predict the design before manufacturing. Test and verify the functionality of various modules of the design under test. By connecting multiple peripheral daughter cards to the simulation tool, you can also test the effect of the design under test and various peripherals running as a complete system.

There are many software supporting hardware simulation tools, such as compilers, synthesizers, debuggers, etc.

The compiler is used to compile the source code of the logic system design, the synthesizer is used to synthesize the logic system design into a netlist form and burn it into the FPGA, and the debugger is used to implement some simple debugging functions. It can be understood that the above software runs on the host computer connected to the hardware simulation tool.

Debugging of logical system designs relies heavily on analysis of the execution results of debugging commands (e.g., log messages). How to better facilitate the analysis of log messages is an urgent technical issue that needs to be solved.

Contents of the invention

A first aspect of the present application provides a method of processing script commands. The method includes: reading a script associated with a logical system design, the script including a plurality of script commands; obtaining an identifier included in the script; and determining a component to be analyzed among the plurality of script commands according to the identifier. one or more target script commands; running the script to obtain a log message corresponding to the one or more target script commands; and analyzing the log message based on the identifier.

A second aspect of the present application provides an electronic device, including: 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 as described in the first aspect Methods.

A third aspect of the present application provides a non-transitory computer-readable storage medium storing a set of instructions for a computer that, when executed, cause the computer to perform: The method described in the first aspect.

Description of drawings

In order to more clearly illustrate the technical solutions in this application or related technologies, the drawings needed to be used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings in the following description are only for the purposes of this application. Embodiments, for those of ordinary skill in the art, other drawings can also be obtained based on these drawings without exerting creative efforts.

Figure 1 shows a schematic structural diagram of an exemplary host according to an embodiment of the present application.

Figure 2 shows a schematic diagram of a simulation system according to an embodiment of the present application.

Figure 3 shows a schematic structural diagram of a debugging tool according to an embodiment of the present application.

Figure 4 shows a flow chart of a method for processing script commands according to an embodiment of the present application.

Detailed ways

In order to make the purpose, technical solutions and advantages of the present application more clear, the present application will be further described in detail below in conjunction with specific embodiments and with reference to the accompanying drawings.

It should be noted that, unless otherwise defined, the technical terms or scientific terms used in this application should have the usual meanings understood by those with ordinary skills in the field to which this application belongs. "First", "second" and similar words used in this application do not indicate any order, quantity or importance, but are only used to distinguish different components. Words such as "include" and similar means that the elements or things appearing before the word include the elements or things listed after the word and their equivalents, without excluding other elements or things. "Connect" and similar words are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect.

As mentioned above, debugging logical system designs relies heavily on log messages obtained after executing script commands. However, there are usually many script files executed during debugging, and a corresponding large number of log messages will be generated after each script command is executed. This makes it difficult for users to find the execution results of the script commands they care about in a large number of log messages, let alone analyze them.

Therefore, how to accurately locate the script command of concern, obtain the log messages generated by executing the command, and then analyze these log messages is an urgent technical problem that needs to be solved.

This application provides a method, electronic device, and storage medium for processing script commands to address this technical problem.

Figure 1 shows a schematic structural diagram of a host 100 according to an embodiment of the present application. The host 100 may be an electronic device running the simulation 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 . Among them, the processor 102, the memory 104, the network interface 106 and the peripheral interface 108 implement communication connections between each other within the electronic device through the 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 (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits. 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 into a single logical component. As shown in Figure 1, processor 102 may include multiple processors 102a, 102b, and 102c.

Memory 104 may be configured to store data (eg, sets of instructions, computer code, intermediate data, etc.). In some embodiments, a simulation test system for simulating a test design may be a computer program stored in memory 104 . As shown in Figure 1, the data stored in the memory may include program instructions (for example, program instructions used to implement the method of locating errors of the present application) and data to be processed (for example, the memory may store temporary codes generated during the compilation process) . The processor 102 may also access program instructions and data stored in memory and execute the program instructions to operate on data to be processed. Memory 104 may include volatile storage or non-volatile storage. In some embodiments, memory 104 may include random access memory (RAM), read only memory (ROM), optical disks, magnetic disks, hard drives, solid state drives (SSD), flash memory, memory sticks, and the like.

Network interface 106 may be configured to provide communication with other external devices to host 100 via a network. The network can 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 (eg, 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 specific examples above. In some embodiments, network interface 106 may include any number and any combination of network interface controllers (NICs), radio frequency modules, transceivers, modems, routers, gateways, adapters, cellular network chips, and the like.

The peripheral interface 108 may be configured to connect the host 100 with one or more peripheral devices to implement information input and output. For example, peripheral devices may include input devices such as keyboards, mice, touch pads, touch screens, microphones, and various sensors, as well as output devices such as displays, speakers, vibrators, and indicator lights.

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

It should be noted that although the above-mentioned electronic device architecture only shows the processor 102, the memory 104, the network interface 106, the peripheral interface 108 and the bus 110, during specific implementation, the electronic device architecture may also include all necessary components to achieve normal operation. Required additional components. In addition, those skilled in the art can understand that the above-mentioned electronic device architecture may also include only the components necessary to implement the solutions of the embodiments of the present application, and does not necessarily include all the components shown in the figures.

It can be understood that the above-mentioned compiler, synthesizer, and debugger, especially the debugger of this application, are run by the host 100 .

Figure 2 shows a schematic diagram of a simulation system 200 according to an embodiment of the present application.

As shown in FIG. 2 , the simulation system 200 may include a simulation tool 202 and a host 100 connected to the simulation tool 202 .

Simulation tool 202 is a hardware system used to simulate a design under test (DUT). The simulation tool 202 may be a prototype verification board or a hardware emulator (emulator). A design under test can include multiple modules. The design under test can be a combinational logic circuit, a sequential logic circuit, or a combination of both. Simulation tool 202 may include one or more configurable circuits (eg, FPGA) for simulating the design under test.

The simulation tool 202 may include an interface unit 2022 for communicatively coupling with the host 100 for communication between the host 100 and the simulation tool 202 . In some embodiments, interface unit 2022 may include one or more interfaces with electrical connection capabilities. For example, the interface unit 2022 may include an RS232 interface, a USB interface, a LAN port, an optical fiber interface, IEEE1394 (FireWire interface), etc. In some embodiments, interface unit 2022 may be a wireless network interface. For example, the interface unit 2022 may be a WIFI interface, a Bluetooth interface, etc.

The host 100 may transmit the compiled DUT, debugging instructions, etc. to the simulation tool 202 via the interface unit 2022. The simulation tool 202 can also transmit simulation data to the host 100 via the interface unit 2022.

The simulation tool 202 may also include a memory 2024 for storing simulation data (eg, various signal values) generated by the design under test during the simulation process. In some embodiments, signal values generated by the design under test during the simulation process can be directly read by the host 100 . It can be understood that the memory 2024 can also be independent of the simulation tool 202, for example, using an external memory.

The simulation tool 202 may also include an FPGA 2026 for hardware implementation of the logic system design onto the FPGA. It can be understood that the simulation tool 202 may include multiple FPGAs, and the figure is only an example.

In addition to connecting to the host 100, the emulation tool 202 may also be connected to one or more daughter cards 204 via the interface unit 2022.

The daughter card is used to provide peripherals to the DUT to form a complete electronic system when using the simulation tool 202 for prototype verification. Prototype verification refers to a verification method that restores the actual usage scenario of the chip as much as possible before chip tape-out and verifies whether the chip function is accurate and complete. The daughter card 204 may include a memory daughter card (for example, providing a DDR memory interface), a communication daughter card (for example, providing a variety of network interfaces or wireless network card interfaces), etc.

The host 100 can be used to configure the simulation tool 202 to simulate a design under test. The design under test may be a complete logic system design or one or more modules of a complete logic system design. In some embodiments, the host 100 may be a virtual host in a cloud computing system. Logical system designs (eg, ASIC or System-On-Chip) can be designed by hardware description languages (eg, Verilog, VHDL, System C, or System Verilog).

Host 100 can run debugging software and receive requests from users to debug designs under test. As mentioned above, a design under test may include one or more modules. The description of the design under test can be done using a hardware description language. Host 100 may perform synthesis based on the description of the design under test to generate, for example, a gate-level circuit netlist (not shown) of the design under test. The gate-level circuit netlist of the design under test can be loaded into the simulation tool 202 and run, and then a circuit structure corresponding to the design under test can be formed in the simulation tool 202 . Therefore, the circuit structure of the design under test can be obtained according to this description, and accordingly, the circuit structure of each block in the design under test can also be obtained similarly.

Figure 3 shows a schematic structural diagram of a debugging tool 300 according to an embodiment of the present application.

The debugging tool 300 may include a plurality of modules, such as an identifier identification unit 302, a log message acquisition unit 304, and a log message analysis unit 306.

The identifier identification unit 302 may be used to identify identifiers in scripts to determine target script commands that require separate analysis.

The log message obtaining unit 304 may obtain log messages generated by executing the target script command.

The log message analysis unit 306 can analyze the log message and generate analysis results.

It can be understood that the debugging tool 300 also includes a script command execution unit 303 for executing the script command.

A specific example is given below.

An example original script is shown below.

designLoad xxx

emulatorSpec yyy

createClock -sigName clk1 zzz

report_something > target/result1.rpt

The above exemplary script includes a total of 4 script commands, which respectively complete loading the logical system design xxx, configure the hardware emulator according to the yyy file, create the clock of clk1, and write the report to result1.rpt.

Since each script command generates log messages when executed, users cannot directly analyze the running results of the script in the log.

Therefore, the embodiment of the present application provides a debugging tool 300. The debugging tool 300 can support identifying specific key characters, determine a target script command based on the key characters, and extract log messages of the target script command for subsequent analysis.

Embodiments of the present application allow an identifier to be added to a single script command, and log messages generated by the identified script command to be individually analyzed.

An example script to add an identifier is shown below.

designLoad xxx

emulatorSpec yyy

#PV1:

createClock -sigName clk1 zzz

#PV1:basic_check

report_something > target/result1.rpt

In the above example script, the identifiers "#PV1:" and "#PV1:basic_check" are added. The above identifier identifies the script command "createClock -sigName clk1 zzz" as the target script command, that is, the script command whose execution results log messages are to be analyzed separately.

Accordingly, the debugging tool 300 can determine the target script command that needs to be analyzed separately based on the identifier. It is understood that the identifier may take other forms and is not limited to the above example. For example, you can use the $ symbol or other symbols, or you can add "_", "-" or "+" symbols before the target script command to identify it.

In some embodiments, the debugging tool 300 further includes a command conversion unit 305 for converting the identifier into executable script code.

In scripting languages, # usually means a comment, that is, the command in this line will not be executed. In the debugging tool 300, in order to implement new functions while being compatible with existing script compilers, the command conversion unit 305 can convert commands with identifiers into script commands that can be compiled and executed by the script compiler.

For example, "#PV1: " and "#PV1:basic_check" can be converted to "puts {#PV1:}" and "puts {#PV1:basic_check}", so that the above identifiers can be displayed on the display. It can be understood that the processing of identifiers does not affect the operation of the debugging tool 300 in the embodiment of the present application, and therefore is an optional function.

When running the script, since the target script command "createClock -sigName clk1 zzz" has been marked by the identifier, the debugging tool 300 can obtain the log message generated by executing the target script command through the log message acquisition unit 304 after executing the target script command. . For example, the log message returned when executing "createClock -sigName clk1 zzz" is "[ERROR]VCOM-888 invalid signal name clk1: cannot find fromnetlist!"

Identifiers can also have specific analytical functions.

The log message analysis unit 306 of the debugging tool 300 may analyze the returned log message according to the analysis function specified by the identifier, and generate an analysis result. For example, #PV1:basic_check indicates that the analysis function is to simply determine whether the target script command is executed successfully. Then, based on the log message returned above, a "FAILED" result can be generated and returned to the user after analysis. In some embodiments, the analysis results (eg, "FAILED") can be saved to a database; in other embodiments, the analysis results can be displayed directly on the display.

In some embodiments, the identifier includes a first identifier and a second identifier. The first identifier is used to determine the beginning of the range of script commands to be analyzed, and the second identifier is used to determine the end of the range of script commands to be analyzed. That is, multiple script commands can be parsed using the first identifier and the second identifier.

At the same time, the second identifier may also include a description of the analysis function to be performed on the log message.

For example, the above #PV1:basic_check command instructs to perform "basic check" analysis on the log message, that is, simple analysis, and returns success or failure.

As another example, given the following exemplary script command

#PV0:

design_read -netlist dut_top.vm

#PV0: diff<vcom.log> vcom.ref

"design_read -netlist dut_top.vm" is the script command identified by the identifier. dut_top.vm is the netlist of the logical system design. "#PV0: file_diff<vcom.log> vcom.ref" indicates that the analysis function of the identifier is to compare vcom.log and vcom.ref to determine whether the two files are the same. If they are the same, the analysis function is satisfied and success is returned; if they are not the same, failure is returned.

As another example, given the following exemplary script command

designLoad xxx

emulatorSpec yyy

#PV1:

createClock -sigName clk1 zzz

report_something > target/result1.rpt

#PV1: assert_string “successfully connected”

Thus, the target script commands include "createClock -sigName clk1 zzz" and "report_something > target/result1.rpt". At the same time, the second identifier uses the "assert_string" command to indicate that the analysis function needs to find whether "successfully connected" exists in the log message displayed on the screen. If it exists, the analysis function is satisfied and success is returned; if it does not exist, failure is returned.

Similarly, the following example script commands are also available.

designLoad xxx

emulatorSpec yyy

#PV2:

createClock -sigName clk1 zzz

report_something > target/result1.rpt

#PV2: count_string “successfully” == 10

The second identifier uses the "count_string" command to indicate that the analysis function needs to find whether there are 10 "successfully" characters in the generated log message. If it exists, it is judged that the analysis function is satisfied and success is returned; if it does not exist, it is judged that the analysis function is not satisfied and failure is returned.

As another example, the following exemplary script command is given.

emulatorSpec yyy

#PV3:

design_read -netlist dut_top.vm

#PV3: assert_reg_exp “LUT: (\d+) BRAM: (\d+)” “\1 > \2 + 10”

The second identifier uses the "assert_reg_exp" command to indicate that the analysis function is to analyze the number of LUTs and the number of BRAMs in the specified log message. When the above expression is satisfied (the number of LUTs > the number of BRAMs + 10), it is judged that the analysis function is satisfied and success is returned; otherwise, failure is returned.

As another example, the following exemplary script command is given.

#PV4:

echo "ABC" # This command will print ABC on the screen

echo "DEF" > file1 # This command will print DEF in file file1

#PV4:assert_string ABC

#PV4:assert_string DEF

#PV4:assert_string<file1> ABC

#PV4:assert_string<file1> DEF

In the above example code, the target script command is selected as "echo "ABC"" and "echo "DEF" > by the first identifier "#PV4:" and the plurality of second identifiers "#PV4:assert_string" file1". At the same time, the analysis functions determined according to the second identifier are respectively searching for the ABC string on the screen, searching for the DEF string on the screen, searching for the ABC string in the file1 file, and searching for the DEF string in the file1 file. Since there is the string ABC on the screen and the string DEF in the file1 file, the execution results will be success, failure, failure and success respectively.

It can be understood that the above analysis functions are only exemplary, and more analysis functions can be set according to user needs.

By using an identifier to mark the target script command and indicating the specific analysis function to be performed in the identifier, the user can analyze the log messages of the execution of one or more specified script commands and limit the analysis function, which greatly improves the efficiency of the analysis. Facilitate users’ debugging work.

The embodiment of the present application also provides a method for processing script commands.

Figure 4 shows a flow chart of a method 400 for processing script commands according to an embodiment of the present application. Method 400 may be performed by host 100 as shown in FIG. 2 . Method 400 may include the following steps.

At step 401, the script associated with the logical system design (eg, "xxx" in the above example or the netlist dut_top.vm) is read. The script may include multiple script commands.

In step 402, the identifiers included in the script (eg, #PV0, #PV1, #PV2, etc. in the above example) are obtained. The identifier includes a first identifier (eg, #PV0) and a second identifier (eg, #PV0: file_diff<vcom.log> vcom.ref). The first identifier and the second identifier may form a pair of identifiers.

The first identifier is used to determine the starting point of the range of the one or more target script commands, and the second identifier is used to determine the end point of the range of the one or more target script commands. That is, the script command between the first identifier and the second identifier is the target script command to be analyzed. The second identifier also includes a description of the analysis function to be performed on the log message.

In some embodiments, the analysis function includes determining whether the target script command is executed successfully (for example, #PV1:basic_check), the mathematical operation result of two values in the log message of the target script command (for example, #PV3:assert_regex" LUT: (\d+) BRAM: (\d+)” “\1 > \2 + 10”), comparison of two files generated by executing the target script command (for example, #PV0: file_diff<vcom.log> vcom.ref ), find the specified string (for example, #PV1: assert_string "successfully connected" and #PV4:assert_string<file1> ABC) in the target script command's log message (for example, the specified file (for example, file1) or the screen), or Determines the number of specified strings in the target script command's log message (for example, #PV2: count_string "successfully" == 10).

In step 403, one or more target script commands to be analyzed are determined among the plurality of script commands according to the identifier (for example, createClock -sigName clk1 zzz and report_something > target/result1.rpt).

In some embodiments, method 400 further includes converting the identifier into an executable script command (eg, "puts {#PV1:}").

At step 404, the script is run to obtain log messages corresponding to the one or more target script commands (eg, "[ERROR]VCOM-888 invalid signal name clk1: cannot find fromnetlist!").

At step 405, the log message is analyzed based on the identifier. More specifically, it is determined according to the analysis function determined by the second identifier whether the content of the log message satisfies the analysis function. If the analysis function is met, success is returned; if the analysis function is not met, failure is returned.

By using an identifier to mark the target script command and indicating the specific analysis function to be performed in the identifier, the user can analyze the log messages of the execution of one or more specified script commands and limit the analysis function, which greatly improves the efficiency of the analysis. Facilitate users’ debugging work.

An embodiment of the present application also provides an electronic device. The electronic device may be the host 100 of FIG. 1 . The host 100 may include 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 400 .

An embodiment of the present application also provides 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 device to perform method 400.

The above describes some embodiments of the present application. Other embodiments are within the scope of the appended 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 desired results. Additionally, the processes depicted in the figures do not necessarily require the specific order shown, or sequential order, to achieve desirable results. Multitasking and parallel processing are also possible or may be advantageous in certain implementations.

Those of ordinary skill in the art should understand that the discussion of any above embodiments is only illustrative, and is not intended to imply that the scope of the present application (including the claims) is limited to these examples; under the spirit of the present application, the above embodiments or Combinations between technical features in different embodiments are also possible, the steps can be implemented in any order, and there are many other variations of the different aspects of the application as described above, which are not provided in detail for the sake of brevity.

Although 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 of ordinary skill in the art from the foregoing description. For example, other memory architectures (eg, dynamic RAM (DRAM)) may use the discussed embodiments.

This application is intended to cover all such alternatives, 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 shall be included in the protection scope of this application.

Claims (7)

1. A method of processing script commands, comprising:

reading a script associated with a logical system design, the script comprising a plurality of script commands;

acquiring an identifier included in the script;

determining one or more target script commands to be analyzed from among the plurality of script commands according to the identifier;

running the script to obtain log messages corresponding to the one or more target script commands; and

and analyzing the log message according to the identifier.

2. The method of claim 1, wherein the identifiers comprise a first identifier for determining a start of a range of the one or more target script commands and one or more second identifiers for determining an end of the range of the one or more target script commands.

3. The method of claim 2, wherein the second identifier further comprises a description of an analysis function to be performed on the log message.

4. The method of claim 1, further comprising: the identifier is converted into an executable script command.

5. The method of claim 3, wherein the analysis function includes determining whether the one or more target script commands were executed successfully, a mathematical run result of two values in a log message of the one or more target script commands, a comparison of two files generated by executing the one or more target script commands, looking up a specified string in a log message of the one or more target script commands, or determining a number of specified strings in a log message of the one or more target script commands.

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

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