Method for processing script commands, electronic device and storage medium

Abstract

The present application provides a method, electronic device and storage medium for processing script commands. The method includes: reading a script associated with a logic system design, the script including multiple script commands; obtaining an identifier included in the script; determining one or more target script commands to be analyzed from the multiple script commands according to the identifier; running the script to obtain log messages corresponding to the one or more target script commands; and analyzing the log messages according to the identifier.

Description

Technical Field

[0001] The present application relates to the field of chip verification technology, and in particular to a method for processing script commands, an electronic device, and a storage medium. Background Art

[0002] A hardware simulation tool (e.g., a prototype verification board or a hardware emulator) can prototype and debug a logic system design comprising one or more modules. The logic system design can be, for example, an Application Specific Integrated Circuit (ASIC) or a System-On-Chip (SOC) design for a specific application. Therefore, the logic system design tested in the simulation tool can also be referred to as a Design Under Test (DUT). The simulation tool can simulate the DUT through one or more configurable components (e.g., a Field Programmable Gate Array (FPGA)), including performing various operations of the DUT, thereby testing and verifying the functions of each module of the DUT before manufacturing. By connecting a variety of peripheral daughter cards to the simulation tool, the effect of the DUT and various peripherals running as a complete system can also be tested.

[0003] There are many softwares to match the hardware simulation tools, such as compilers, synthesizers, debuggers, etc.

[0004] The compiler compiles the source code of the logic system design, the synthesizer converts the logic system design into a netlist and burns it into the FPGA, and the debugger performs some simple debugging. It's understood that these software runs on the host computer connected to the hardware emulation tool.

[0005] Debugging of logic system designs relies heavily on analyzing the execution results of debug commands (e.g., log messages). How to better facilitate the analysis of log messages is a technical problem that needs to be solved urgently. Summary of the Invention

[0006] A first aspect of the present application provides a method for processing script commands. The method includes: reading a script associated with a logical system design, the script including multiple script commands; obtaining an identifier included in the script; determining one or more target script commands to be analyzed from the multiple script commands based on the identifier; executing the script to obtain log messages corresponding to the one or more target script commands; and analyzing the log messages based on the identifier.

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

[0008] 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 according to the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0010] Figure 1 A schematic structural diagram of an exemplary host according to an embodiment of the present application is shown.

[0011] Figure 2 A schematic diagram of a simulation system according to an embodiment of the present application is shown.

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

[0013] Figure 4 A flowchart of a method for processing script commands according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0014] In order to make the objectives, technical solutions and advantages of this application more clear, this application is further described in detail below in combination with specific embodiments and with reference to the accompanying drawings.

[0015] It should be noted that, unless otherwise defined, the technical or scientific terms used in this application should have the usual meaning understood by people with ordinary skills in the field to which this application belongs. The "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. "Include" and similar words mean that the elements or objects appearing before the word include the elements or objects listed after the word and their equivalents, without excluding other elements or objects. "Connect" and similar words are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect.

[0016] As mentioned above, debugging logical system designs relies heavily on log messages obtained after executing script commands. However, debugging often involves executing multiple script files, and each script command generates a large number of corresponding log messages. This makes it difficult for users to find the execution results of the script command they are interested in amidst the vast amount of log messages, let alone analyze them.

[0017] Therefore, how to accurately locate the script command of interest, obtain the log messages generated by executing the command, and then analyze these log messages is a technical problem that needs to be solved urgently.

[0018] To address this technical problem, the present application provides a method for processing script commands, an electronic device, and a storage medium.

[0019] Figure 1 FIG1 shows a schematic diagram of the structure of the 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 via the bus 110 within the electronic device.

[0020] 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. The processor 102 may be used to perform functions related to the technology described in this application. In some embodiments, the 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.

[0021] The memory 104 may be configured to store data (eg, instruction sets, computer code, intermediate data, etc.). In some embodiments, the simulation test system for simulating the test design may be a computer program stored in the memory 104. Figure 1As shown, the data stored in the memory may include program instructions (e.g., program instructions for implementing the method for processing script commands of the present application) and data to be processed (e.g., the memory may store temporary code 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.

[0022] 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 will be appreciated that the type of network is not limited to the above specific examples. In some embodiments, the network interface 106 can include any combination of any number of network interface controllers (NICs), radio frequency modules, transceivers, modems, routers, gateways, adapters, cellular network chips etc.

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

[0024] 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 (USB port, PCI-E bus), etc.

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

[0026] It is understandable that the above-mentioned compiler, synthesizer, and debugger, especially the debugger of the present application, are run by the host 100 .

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

[0028] like Figure 2 As shown, the simulation system 200 may include a simulation tool 202 and a host 100 connected to the simulation tool 202 .

[0029] Simulation tool 202 is a hardware system for simulating a design under test (DUT). Simulation tool 202 can be a prototype verification board or a hardware simulator (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 the two. Simulation tool 202 can include one or more configurable circuits (e.g., FPGA) for simulating the design under test.

[0030] Simulation tool 202 can comprise interface unit 2022, is used for coupling with main frame 100 communication ground, to carry out the communication between main frame 100 and the simulation tool 202.In certain embodiments, interface unit 2022 can comprise one or more interfaces with electrical connection capability.For example, interface unit 2022 can comprise RS232 interface, USB interface, LAN port, optical fiber interface, IEEE1394 (firewire interface) etc.In certain embodiments, interface unit 2022 can be a wireless network interface.For example, interface unit 2022 can be a WIFI interface, bluetooth interface etc.

[0031] 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 may also transmit simulation data, etc. to the host 100 via the interface unit 2022.

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

[0033] The simulation tool 202 may further include an FPGA 2026 for hardware-implementing the logic system design on the FPGA. It is understood that the simulation tool 202 may include multiple FPGAs, which are only examples.

[0034] In addition to being connected to the host 100 , the simulation tool 202 may also be connected to one or more daughter cards 204 via an interface unit 2022 .

[0035] The daughter card is used to provide peripherals to the DUT during prototype verification using simulation tool 202 to form a complete electronic system. Prototype verification is a verification method that verifies the accuracy and completeness of chip functions by recreating the actual chip usage scenario as much as possible before chip tape-out. Daughter card 204 can include memory daughter cards (for example, providing DDR memory interfaces), communication daughter cards (for example, providing multiple network interfaces or wireless network interfaces), etc.

[0036] Host 100 can be used to configure simulation tool 202 to simulate a design to be tested. The design to be tested can be a complete logic system design or one or more modules of a complete logic system design. In some embodiments, host 100 can be a virtual host in a cloud computing system. The logic system design (e.g., ASIC or System-On-Chip) can be designed using a hardware description language (e.g., Verilog, VHDL, System C, or System Verilog).

[0037] The host 100 can run debugging software and receive a request from the user to debug the design to be tested. As mentioned above, the design to be tested may include one or more modules. The description of the design to be tested may be completed using a hardware description language. The host 100 can synthesize based on the description of the design to be tested to generate, for example, a gate-level circuit netlist (not shown) of the design to be tested. The gate-level circuit netlist of the design to be tested can be loaded into the simulation tool 202 for operation, and then a circuit structure corresponding to the design to be tested can be formed in the simulation tool 202. Therefore, the circuit structure of the design to be tested can be obtained based on the description, and accordingly, the circuit structure of each block in the design to be tested can also be obtained similarly.

[0038] Figure 3 A schematic structural diagram of a debugging tool 300 according to an embodiment of the present application is shown.

[0039] The debugging tool 300 may include multiple modules, such as an identifier recognition unit 302 , a log message acquisition unit 304 , and a log message analysis unit 306 .

[0040] The identifier recognition unit 302 may be used to recognize identifiers in the script to determine target script commands that need to be analyzed separately.

[0041] The log message acquiring unit 304 may acquire the log message generated by executing the target script command.

[0042] The log message analysis unit 306 may analyze the log message and generate an analysis result.

[0043] It is understandable that the debugging tool 300 further includes a script command execution unit 303 for executing script commands.

[0044] The following is an explanation using a specific example.

[0045] An example raw script is shown below.

[0046] designLoad xxx

[0047] emulatorSpec yyy

[0048] createClock-sigName clk1 zzz

[0049] report_something>target / result1.rpt

[0050] The above exemplary script includes a total of 4 script commands, which respectively complete loading the logic system design xxx, configuring the hardware simulator according to the yyy file, creating the clk1 clock, and writing the report to result1.rpt.

[0051] Since each script command generates a log message when it is executed, users cannot directly analyze the script execution results in the log.

[0052] Therefore, an embodiment of the present application provides a debugging tool 300. The debugging tool 300 can support the recognition of specific key characters, determine the target script command based on the key characters, and extract the log message of the target script command for subsequent analysis.

[0053] The embodiment of the present application allows adding an identifier to a single script command and performing separate analysis on the log message generated by the identified script command.

[0054] An example script for adding an identifier is shown below.

[0055] designLoad xxx

[0056] emulatorSpec yyy

[0057] #PV1:

[0058] createClock-sigName clk1 zzz

[0059] #PV1:basic_check

[0060] report_something>target / result1.rpt

[0061] In the above exemplary script, the identifiers “#PV1:” and “#PV1:basic_check” are added. These identifiers identify the script command “createClock-sigName clk1 zzz” as the target script command, that is, the script command whose execution result log message is to be analyzed separately.

[0062] 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 can take other forms and is not limited to the above examples. For example, the $ symbol or other symbols can be used, or symbols such as "_", "-", or "+" can be added before the target script command to identify it.

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

[0064] In scripting languages, # usually means a comment, which means that the command 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.

[0065] 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 is understandable that the processing of identifiers does not affect the operation of the debugging tool 300 of the embodiment of the present application and is therefore an optional function.

[0066] When running the script, because the target script command "createClock-sigName clk1 zzz" is already marked with an identifier, the debugging tool 300 can use the log message acquisition unit 304 to acquire the log message generated by executing the target script command after executing the target script command. For example, the log message returned by executing "createClock-sigName clk1 zzz" is "[ERROR] VCOM-888 invalid signal name clk1: cannot find from netlist!"

[0067] Identifiers may also have specific analytical functions.

[0068] The log message analysis unit 306 of the debugging tool 300 can 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 above-mentioned returned log message, a "FAILED" result can be generated after analysis and returned to the user. In some embodiments, the analysis result (e.g., "FAILED") can be saved in a database; in other embodiments, the analysis result can be displayed directly on a display.

[0069] In some embodiments, the identifier includes a first identifier and a second identifier. The first identifier is used to determine the starting point of the range of script commands to be analyzed, and the second identifier is used to determine the end point of the range of script commands to be analyzed. In other words, the first identifier and the second identifier can be used to analyze multiple script commands.

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

[0071] For example, the #PV1:basic_check command indicates to perform a "basic check" analysis on the log message, that is, a simple analysis and return success or failure.

[0072] For example, the following script command is given:

[0073] #PV0:

[0074] design_read-netlist dut_top.vm

[0075] #PV0:diff<vcom.log> vcom.ref

[0076] "design_read-netlist dut_top.vm" is a script command identified by an identifier. dut_top.vm is the netlist of the logic 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 identical. If they are identical, the analysis function is satisfied and success is returned; if they are not identical, failure is returned.

[0077] For example, the following script command is given:

[0078] designLoad xxx

[0079] emulatorSpec yyy

[0080] #PV1:

[0081] createClock-sigName clk1 zzz

[0082] report_something>target / result1.rpt

[0083] #PV1:assert_string "successfully connected"

[0084] Thus, the target script commands include "createClock -sigName clk1 zzz" and "report_something>target / result1.rpt." Meanwhile, the second identifier, using the "assert_string" command, indicates to the analysis function that it needs to check whether the message "successfully connected" appears in the log message displayed on the screen. If so, the analysis function is satisfied and returns a success result; if not, a failure result is returned.

[0085] Similarly, there are also the following exemplary script commands.

[0086] designLoad xxx

[0087] emulatorSpec yyy

[0088] #PV2:

[0089] createClock-sigName clk1 zzz

[0090] report_something>target / result1.rpt

[0091] #PV2:count_string "successfully"==10

[0092] The second identifier uses the "count_string" command to indicate that the analysis function needs to find whether the generated log message contains 10 "successfully" characters. If so, the analysis function is considered to have been satisfied and a success response is returned. If not, the analysis function is considered to have been satisfied and a failure response is returned.

[0093] For another example, the following exemplary script commands are given.

[0094] emulatorSpec yyy

[0095] #PV3:

[0096] design_read-netlist dut_top.vm

[0097] #PV3:assert_reg_exp "LUT:(\d+)BRAM:(\d+)" "\1>\2+10"

[0098] 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. If the above expression (number of LUTs > number of BRAMs + 10) is met, the analysis function is judged to be satisfied and a success is returned; otherwise, a failure is returned.

[0099] For another example, the following exemplary script commands are given.

[0100] #PV4:

[0101] echo "ABC" #This command will print ABC on the screen

[0102] echo"DEF">file1#This command will print DEF in the file file1

[0103] #PV4:assert_string ABC

[0104] #PV4:assert_string DEF

[0105] #PV4:assert_string <file1>ABC

[0106] #PV4:assert_string <file1>DEF

[0107] In the above exemplary code, the target script commands are selected as "echo "ABC"" and "echo "DEF">file1" by the first identifier "#PV4:" and multiple second identifiers "#PV4:assert_string". At the same time, the analysis functions determined by the second identifiers are respectively to search for the ABC string on the screen, to search for the DEF string on the screen, to search for the ABC string in the file1 file, and to search 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.

[0108] It is understandable that the above analysis functions are merely exemplary, and more analysis functions can be provided according to user needs.

[0109] 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, thereby greatly facilitating the user's debugging work.

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

[0111] Figure 4 FIG. 4 is a flow chart showing a method 400 for processing script commands according to an embodiment of the present application. The method 400 may be performed as follows: Figure 2 The host 100 shown in FIG. 4 is executed. The method 400 may include the following steps.

[0112] In step 401, a script associated with a logic system design (eg, "xxx" or the netlist dut_top.vm in the above example) is read. The script may include multiple script commands.

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

[0114] 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. In other words, the script commands between the first identifier and the second identifier are the target script commands to be analyzed. The second identifier also includes a description of the analysis function to be performed on the log message.

[0115] In some embodiments, the analysis function includes determining whether the target script command is executed successfully (e.g., #PV1:basic_check), the mathematical operation results of two values ​​in the log message of the target script command (e.g., #PV3:assert_regex "LUT:(\d+)BRAM:(\d+)" "\1>\2+10"), and comparing two files generated by executing the target script command (e.g., #PV0:file_diff).<vcom.log> vcom.ref), searches for a specified string (e.g., #PV1:assert_string "successfully connected" and #PV4:assert_string "successfully connected") in the log messages of the target script command (e.g., a specified file (e.g., file1) or the screen). <file1>ABC), or determine the number of specified strings in the log message of the target script command (for example, #PV2:count_string "successfully" == 10).

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

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

[0118] 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 from netlist!").

[0119] In step 405, the log message is analyzed based on the identifier. More specifically, the analysis function determined by the second identifier is used to determine whether the content of the log message satisfies the analysis function. If so, a success result is returned; if not, a failure result is returned.

[0120] 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, thereby greatly facilitating the user's debugging work.

[0121] The embodiment of the present application also provides an electronic device. The electronic device can be Figure 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 enable the electronic device to perform the method 400.

[0122] The embodiment of the present application further provides a non-transitory computer-readable storage medium that stores a set of computer instructions, which are used to cause the computer device to perform method 400 when executed.

[0123] The foregoing 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 may be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0124] 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. Within the scope of the present application, the above embodiments or technical features in 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.

[0125] Although the present invention 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 based on the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may utilize the embodiments discussed.

[0126] 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 method for processing a script command, comprising: reading a script associated with a logical system design, the script comprising a plurality of script commands; Obtaining an identifier included in the script; Determine one or more target script commands to be analyzed from the plurality of script commands according to the identifier; After executing the one or more target script commands, obtaining, according to the identifier, a log message corresponding to the one or more target script commands determined by the identifier, wherein the log message is generated by executing the one or more target script commands; as well as Analyzing the log message according to the identifier; The identifier includes a first identifier and one or more second 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.

2. The method of claim 1, wherein: The second identifier also includes a description of an analysis function to be performed on the log message.

3. The method of claim 1, further comprising: Converts the identifier into an executable script command.

4. The method of claim 2, wherein: The analysis function includes determining whether the execution of the one or more target script commands is successful, the mathematical operation results of two values ​​in the log messages of the one or more target script commands, comparing two files generated by executing the one or more target script commands, searching for a specified string in the log messages of the one or more target script commands, or determining the number of specified strings in the log messages of the one or more target script commands.

5. An electronic device comprising: a memory for storing a set of instructions; as well as At least one processor is configured to execute the set of instructions so that the electronic device performs the method according to any one of claims 1 to 4.

6. A non-transitory computer-readable storage medium storing a set of instructions for a computer, the set of instructions being used to cause the computer to perform the method according to any one of claims 1 to 4 when executed.

Images