CN117172203B - Method for processing script commands, electronic device and storage medium - Google Patents
Method for processing script commands, electronic device and storage medium Download PDFInfo
- Publication number
- CN117172203B CN117172203B CN202311153895.8A CN202311153895A CN117172203B CN 117172203 B CN117172203 B CN 117172203B CN 202311153895 A CN202311153895 A CN 202311153895A CN 117172203 B CN117172203 B CN 117172203B
- Authority
- CN
- China
- Prior art keywords
- identifier
- script
- script commands
- commands
- target
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Debugging And Monitoring (AREA)
Abstract
The application provides a method for processing script commands, electronic equipment and a storage medium. 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, determining one or more target script commands to analyze from the plurality of script commands based on the identifier, running the script to obtain log messages corresponding to the one or more target script commands, and analyzing the log messages based on the identifier.
Description
Technical Field
The present application relates to the field of chip verification technologies, and in particular, to a method for processing a script command, an electronic device, and a storage medium.
Background
A hardware simulation tool (e.g., a prototype verification board or hardware simulator (emulator)) may prototype (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 (ASIC) or System-On-Chip (SOC) for a specific Application. Thus, the logic system design being tested in the simulation tool may also be referred to as a design under test (Design Under Test, DUT for short). The simulation tool may simulate the design under test by one or more configurable components, such as a field programmable gate array (Field Programmable GATE ARRAY, abbreviated FPGA), including performing various operations on the design under test to test and verify the functionality of the various modules of the design under test prior to fabrication. The design to be tested and various peripherals can be tested to be used as a complete system to run by externally connecting various peripheral daughter cards on the simulation tool.
There are also many software such as compilers, synthesizers, debuggers, etc. that are matched with the hardware simulation tools.
The compiler is used for compiling source codes of the logic system design, the synthesizer is used for synthesizing the logic system design into a netlist form and burning the logic system design into the FPGA, and the debugger is used for realizing some simple debugging functions. It will be appreciated that the software described above runs on a host to which the hardware simulation tool is connected.
Debugging of a logical system design relies in large part on analysis of the results of execution of a debug command (e.g. log messages). How to better facilitate the analysis of log messages is a technical problem to be solved.
Disclosure of 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, determining one or more target script commands to analyze from the plurality of script commands based on the identifier, running the script to obtain log messages corresponding to the one or more target script commands, and analyzing the log messages based on the identifier.
A second aspect of the 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 to cause the electronic device to perform the method of the first aspect.
A third aspect of the application provides a non-transitory computer readable storage medium storing a set of instructions of a computer for, when executed, causing the computer to perform the method of the first aspect.
Drawings
In order to more clearly illustrate the technical solutions of the present application or related art, the drawings that are required to be used in the description of the embodiments or related art will be briefly described below, and it is apparent that the drawings in the following description are only embodiments of the present application, and other drawings may be obtained according to the drawings without inventive effort to those of ordinary skill in the art.
Fig. 1 shows a schematic diagram of an exemplary host according to an embodiment of the present application.
FIG. 2 shows a schematic diagram of a simulation system in accordance with an embodiment of the present application.
FIG. 3 shows a schematic diagram of the structure of a debug tool according to an embodiment of the present application.
FIG. 4 illustrates a flow chart of a method of processing script commands, according to an embodiment of the present application.
Detailed Description
The present application will be further described in detail below with reference to specific embodiments and with reference to the accompanying drawings, in order to make the objects, technical solutions and advantages of the present application more apparent.
It is to be noted that unless otherwise defined, technical or scientific terms used herein should be taken in a general sense as understood by one of ordinary skill in the art to which the present application belongs. The terms "first," "second," and the like, as used herein, do not denote any order, quantity, or importance, but rather are used to distinguish one element from another. The word "comprising" and the like means that elements or items preceding the word are included in the element or item listed after the word and equivalents thereof without precluding other elements or items. The term "coupled" and the like are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect.
As described above, debugging of a logical system design is largely dependent on log messages acquired after execution of script commands. However, there are typically many script files that are executed during debugging, and a corresponding large number of log messages are generated after each script command is executed. This makes it difficult for the user to find the execution result of that script command of interest to himself in a large number of log messages, let alone to analyze.
Therefore, how to precisely locate the concerned script command, acquire the log messages generated by executing the command, and further analyze the log messages is a technical problem to be solved.
The application provides a method for processing script commands, electronic equipment and a storage medium.
Fig. 1 shows a schematic structure of a host 100 according to an embodiment of the present application. The host 100 may be an electronic device running an emulation system. As shown in FIG. 1, host 100 may include a processor 102, a memory 104, a network interface 106, a peripheral interface 108, and a bus 110. Wherein the processor 102, the memory 104, the network interface 106, and the peripheral interface 108 are communicatively coupled to each other within the electronic device via a bus 110.
The processor 102 may be a central processing unit (Central Processing Unit, CPU), an image processor, a neural Network Processor (NPU), a Microcontroller (MCU), a programmable logic device, a Digital Signal Processor (DSP), an Application SPECIFIC INTEGRATED Circuit (ASIC), or one or more integrated circuits. The processor 102 may be used to perform functions related to the techniques described herein. In some embodiments, processor 102 may also include multiple processors integrated as a single logical component. As shown in fig. 1, the processor 102 may include a plurality of processors 102a, 102b, and 102c.
The memory 104 may be configured to store data (e.g., instruction sets, computer code, intermediate data, etc.). In some embodiments, the simulation test system used to simulate the test design may be a computer program stored in memory 104. As shown in fig. 1, the data stored in the memory may include program instructions (e.g., program instructions for implementing the method of processing script commands of the present application) as well as data to be processed (e.g., the memory may store temporary code generated during compilation). The processor 102 may also access program instructions and data stored in the memory and execute the program instructions to perform operations on the data to be processed. The memory 104 may include volatile storage or nonvolatile storage. In some embodiments, memory 104 may include Random Access Memory (RAM), read Only Memory (ROM), optical disks, magnetic disks, hard disks, solid State Disks (SSD), flash memory, memory sticks, and the like.
The network interface 106 may be configured to provide communication with other external devices to the host 100 via a network. The network may be any wired or wireless network capable of transmitting and receiving data. For example, the network may be a wired network, a local wireless network (e.g., bluetooth, wiFi, near Field Communication (NFC), etc.), a cellular network, the internet, or a combination of the foregoing. It will be appreciated that the type of network is not limited to the specific examples described above. In some embodiments, network interface 106 may include any combination of any number of Network Interface Controllers (NICs), radio frequency modules, receivers, modems, routers, gateways, adapters, cellular network chips, etc.
The peripheral interface 108 may be configured to connect the host 100 with one or more peripheral devices to enable information input and output. For example, the peripheral devices may include input devices such as keyboards, mice, touchpads, touch screens, microphones, various types of sensors, and output devices such as displays, speakers, vibrators, and indicators.
Bus 110 may be configured to transfer information between the various components of host 100 (e.g., processor 102, memory 104, network interface 106, and peripheral interface 108), such as an internal bus (e.g., processor-memory bus), an external bus (USB port, PCI-E bus), etc.
It should be noted that, although the above electronic device architecture only shows the processor 102, the memory 104, the network interface 106, the peripheral interface 108, and the bus 110, in a specific implementation, the electronic device architecture may also include other components necessary to achieve proper operation. Furthermore, it will be understood by those skilled in the art that the electronic device architecture may include only the components necessary for implementing the embodiments of the present application, and not all the components shown in the drawings.
It will be appreciated that the compiler, synthesizer, debugger described above, and particularly the debugger of the present application, is run by host 100.
FIG. 2 shows a schematic diagram of a simulation system 200 according to an embodiment of the application.
As shown in FIG. 2, the simulation system 200 may include a simulation tool 202 and a host 100 coupled to the simulation tool 202.
Simulation tool 202 is a hardware system for simulating a Design Under Test (DUT). Simulation tool 202 may be a prototype verification board or a hardware simulator (emulator). One design under test may include multiple modules. The design under test may be combinational logic, sequential logic, or a combination of the two. The simulation tool 202 may include one or more configurable circuits (e.g., FPGAs) for simulating a 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 interface, an optical fiber interface, IEEE1394 (firewire interface), and the like. In some embodiments, the interface unit 2022 may be a wireless network interface. For example, the interface unit 2022 may be a WIFI interface, a bluetooth interface, or the like.
The host 100 may transmit compiled DUTs, debug instructions, etc. to the simulation tool 202 via the interface unit 2022. The simulation tool 202 may also transmit simulation data or the like to the host 100 via the interface unit 2022.
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 may be directly read by the host 100. It will be appreciated that the memory 2024 may also be provided by the stand-alone 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 is understood that the simulation tool 202 may include a plurality of FPGAs, which are only examples.
In addition to being connected to the host 100, the emulation tool 202 can also be connected to one or more daughter cards 204 via an interface unit 2022.
The daughter card is used to provide peripherals to the DUT to build a complete electronic system when prototype verification is performed using simulation tool 202. Prototype verification refers to a verification mode for restoring the actual use scene of a chip as far as possible before chip streaming, and verifying whether the chip functions are accurate and complete. The daughter cards 204 may include memory daughter cards (e.g., providing DDR memory interfaces), communication daughter cards (e.g., providing various network interfaces or wireless network card interfaces), and the like.
The host 100 may 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, host 100 may be a virtual host in a cloud computing system. The logic System design (e.g., ASIC or System-On-Chip) may be designed by a hardware description language (e.g., verilog, VHDL, system C, or System Verilog).
Host 100 may run debugging software and receive a request from a user to debug a design under test. As described above, the design under test may include one or more modules. Description of the design under test may be accomplished in a hardware description language. The host 100 may synthesize based on the description of the design under test to generate, for example, a gate level netlist (not shown) of the design under test. The gate level circuit netlist of the design under test may be loaded into simulation tool 202 for operation, which in turn may form a circuit structure corresponding to the design under test in simulation tool 202. Accordingly, the circuit structure of the design under test can be obtained from this description, and accordingly, the circuit structure of each block in the design under test can also be obtained similarly.
Fig. 3 shows a schematic structural diagram of a debugging tool 300 according to an embodiment of the application.
Debug 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 recognition unit 302 may be used to recognize identifiers in scripts to determine target script commands that need to be analyzed separately.
The log message acquiring unit 304 may acquire the log message generated by executing the target script command.
The log message analyzing unit 306 may analyze the log message and generate an analysis result.
It is understood that the debug tool 300 further comprises an execution unit 303 for script commands for executing script commands.
The following is a specific example.
An exemplary original script is shown below.
designLoad xxx
emulatorSpec yyy
createClock-sigName clk1 zzz
report_something>target/result1.rpt
The above exemplary script includes 4 script commands in total, respectively completing the loading of the logical system design xxx, configuring the hardware simulator according to the yyy file, creating the clock of clk1, and writing the report into result1.rpt.
Because each script command generates a log message when executed, the user cannot directly analyze the running result of the script in the log.
Accordingly, embodiments of the present application provide a debug tool 300. The debug tool 300 may support recognition of specific key characters and determine target script commands from the key characters and extract log messages of the target script commands for subsequent analysis.
Embodiments of the present application allow for the addition of identifiers to individual script commands and the separate analysis of log messages generated by identified script commands.
An exemplary script for adding identifiers is shown below.
designLoad xxx
emulatorSpec yyy
#PV1:
createClock-sigName clk1 zzz
#PV1:basic_check
report_something>target/result1.rpt
In the above exemplary script, the identifiers "#PV1:" and "#PV1: basic_check" are added. The above identifier identifies script command "createClock-SIGNAME CLK1 zz" as a target script command, i.e., a script command whose execution results are to be analyzed separately for log messages.
Accordingly, debug tool 300 may determine the target script commands that need to be analyzed separately based on the identifiers. It will be appreciated that the identifier may take other forms and is not limited to the examples described above. For example, a $symbol or other symbol may be used, or a symbol such as "_", "-" or "+" may be added to the target script command to identify it.
In some embodiments, debug tool 300 also includes a command conversion unit 305 for converting identifiers into script code that may be executable.
In scripting languages, typically # is the meaning of an annotation, i.e., the line command will not be executed. In the debug tool 300, in order to realize a new function in a case of being compatible with an existing script compiler, a command having an identifier may be converted into a script command that the script compiler can compile and execute by the command converting unit 305.
For example, "#PV1:" and "#PV1: basic_check" may be converted into "puts { #PV1: }" and "puts { #PV1: basic_check }", so that the above-mentioned identifiers may be displayed on the display. It will be appreciated that the processing of the identifier does not affect the operation of the debug tool 300 of embodiments of the present application and is therefore an optional feature.
At the time of running the script, since the target script command "createClock-SIGNAME CLK1 zz" has been marked by an identifier, the debugging tool 300 can acquire a log message generated by executing the target script command by the log message acquisition unit 304 after the target script command is executed. For example, the journal message returned in executing "createClock-SIGNAME CLK1 zzz" is "[ ERROR ] VCOM-888invalid signal name clk1:cannot find from netlist-"
The identifier may also have a specific analysis function.
The log message analyzing unit 306 of the debug 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 simply determines whether the target script command was executed successfully. Then, based on the returned log message, a result of "FAILED" may be generated after analysis and returned to the user. In some embodiments, the analysis results (e.g., "FAILED") may be saved to a database, and in other embodiments, the analysis results may be displayed directly on a display.
In some embodiments, the identifier comprises a first identifier and a second identifier. The first identifier is used to determine a start point of a range of script commands to be analyzed and the second identifier is used to determine an end point of the range of script commands to be analyzed. That is, the plurality of script commands may be analyzed using the first identifier and the second identifier.
Meanwhile, the second identifier may further include a description of an analysis function to be performed on the log message.
For example, the above #PV1:basic_check command indicates that a "basic check" analysis, i.e., a simple analysis, is performed on the log message, returning success or failure.
As another example, the following exemplary script commands are given
#PV0:
design_read-netlist dut_top.vm
#PV0:diff<vcom.log>vcom.ref
"Design_read-netlist det_top.vm" is a script command determined by an identifier. The det_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 if the two files are identical. If the results are the same, the analysis function is satisfied and success is returned, and if the results are not the same, failure is returned.
As another example, the following exemplary script commands are given
designLoad xxx
emulatorSpec yyy
#PV1:
createClock-sigName clk1 zzz
report_something>target/result1.rpt
#PV1:assert_string“successfully connected”
Thus, the target script command includes "createClock-SIGNAME CLK1 zzz" and "report_ something > target/result1.Rpt". Meanwhile, the second identifier indicates to the analysis function, using an "assast_string" command, whether "successfully connected" is present in the log message displayed on the screen or not. If so, the analysis function is satisfied and success is returned, and if not, failure is returned.
Similarly, there may also be the following exemplary script commands.
designLoad xxx
emulatorSpec yyy
#PV2:
createClock-sigName clk1 zzz
report_something>target/result1.rpt
#PV2:count_string“successfully”==10
The second identifier then indicates, using a "count_string" command, that the analysis function is to find whether there are 10 "successfully" characters in the generated log message. If yes, judging that the analysis function is met and returning success; if not, the analysis function is judged not to be satisfied and failure is returned.
For another example, the following exemplary script commands are given.
emulatorSpec yyy
#PV3:
design_read-netlist dut_top.vm
#PV3:assert_reg_exp“LUT:(\d+)BRAM:(\d+)”“\1>\2+10”
The second identifier indicates, using an "asslay regexp" command, that the analysis function is to analyze the number of LUTs and the number of BRAMs in a specified log message. If the above expression (LUT number > BRAM number +10) is satisfied, then the analysis function is judged to be satisfied and success is returned, otherwise failure is returned.
For another example, the following exemplary script commands are given.
#PV4:
Echo "ABC" # this command will print ABC on the screen
Echo "DEF" > file1# this command will print DEF in file1
#PV4:assert_string ABC
#PV4:assert_string DEF
#PV4:assert_string<file1>ABC
#PV4:assert_string<file1>DEF
In the above exemplary code, the target script command is selected to be "echo" ABC "and" echo "DEF" > file1 "by a first identifier" #PV4: "and a plurality of second identifiers" #PV4: asert_string ". Meanwhile, the analysis function determined according to the second identifier is to search for an ABC character string on the screen, search for a DEF character string on the screen, search for an ABC character string in the file1 file and search for a DEF character string in the file1 file respectively. Since there is a string ABC on the screen and a string DEF in the file1 file, the execution results will be success, failure and success, respectively.
It will be appreciated that the above described analysis functions are merely exemplary and that many more analysis functions may be provided as desired by the user.
By marking the target script command with an identifier and indicating the specific analysis function to be performed in the identifier, the user can analyze the log message for executing the specified script command or commands and can define the analysis function, thereby greatly facilitating the user's debugging work.
The embodiment of the application also provides a method for processing the script command.
FIG. 4 illustrates a flow chart of a method 400 of processing script commands, according to an embodiment of the application. The method 400 may be performed by a host 100 as shown in fig. 2. The method 400 may include the following steps.
At step 401, a script associated with a logical system design (e.g., "xxx" or netlist det_top. Vm in the above example) is read. The script may include a plurality of script commands.
At step 402, identifiers (e.g., # PV0, # PV1, # PV2, etc., in the above example) included in the script are obtained. The identifiers include a first identifier (e.g., # PV 0) and a second identifier (e.g., # 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 a start point of a range of the one or more target script commands and the second identifier is used to determine an 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 further comprises a description of an analysis function to be performed on the log message.
In some embodiments, the analysis function includes determining whether the target script command execution was successful (e.g., # PV1:basic_check), a mathematical run result of two values in a log message of the target script command (e.g., # PV3:aset_regex "LUT: (\d+) BRAM: (\d+)" \1> \2+10), performing a comparison of two files resulting from the target script command (e.g., # PV0:file_diff < vcom.log > vcom.ref), looking up a specified string in a log message of the target script command (e.g., a specified file (e.g., file 1) or screen) (e.g., # PV1:aset_string "successfully connected" and #PV4:aset_string < file1> ABC), or determining the number of specified strings in a log message of the target script command (e.g., # PV2:count_string "successfully" = 10).
In step 403, one or more target script commands to be analyzed (e.g., createClock-SIGNAME CLK1 zz and report something > target/result1. Rpt) are determined from the plurality of script commands based on the identifier.
In some embodiments, the method 400 further includes converting the identifier into an executable script command (e.g., "puts { #PV1: }).
At step 404, the script is run to obtain log messages (e.g., "[ ERROR ] VCOM-888invalid signal name clk1:cannot find from netlist ].
In step 405, the log message is analyzed based on the identifier. More specifically, the analysis function determined from the second identifier determines whether the content of the log message satisfies the analysis function. If the analysis function is satisfied, a success is returned, and if the analysis function is not satisfied, a failure is returned.
By marking the target script command with an identifier and indicating the specific analysis function to be performed in the identifier, the user can analyze the log message for executing the specified script command or commands and can define the analysis function, thereby greatly facilitating the user's debugging work.
The embodiment of the application also provides electronic equipment. 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.
Embodiments of the present application also provide a non-transitory computer readable storage medium. The non-transitory computer readable storage medium stores a set of instructions of a computer that, when executed, are to cause the computer apparatus to perform the method 400.
The foregoing describes some embodiments of the present application. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
It will be appreciated by persons skilled in the art that the foregoing discussion of any embodiment is merely exemplary and is not intended to imply that the scope of the application (including the claims) is limited to these examples, that combinations of technical features in the foregoing embodiments or in different embodiments may be implemented in any order and that many other variations of the different aspects of the application as described above may exist within the spirit of the application, and that they are not provided in detail for clarity.
While the application has been described in conjunction with specific embodiments thereof, many alternatives, modifications, and variations of those embodiments will be apparent to those skilled in the art in light of the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may use the embodiments discussed.
The present application is intended to embrace all such alternatives, modifications and variances which fall within the broad scope of the appended claims. Therefore, any omission, modification, equivalent replacement, improvement, etc. of the present application should be included in the scope of the present application.
Claims (6)
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;
after execution of the one or more target script commands, retrieving, based on the identifier, a log message corresponding to the one or more target script commands determined by the identifier, the log message generated by execution of the one or more target script commands, and
Analyzing the log message according to the identifier;
Wherein the identifiers include a first identifier for determining a start point of a range of the one or more target script commands and one or more second identifiers for determining an end point of the range of the one or more target script commands.
2. The method of claim 1, wherein the second identifier further comprises a description of an analysis function to be performed on the log message.
3. The method of claim 1, further comprising converting the identifier into an executable script command.
4. The method of claim 2, wherein the analysis function comprises determining whether execution of the one or more target script commands was successful, 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 execution of the one or more target script commands, a lookup of a specified string in a log message of the one or more target script commands, or a determination of a number of specified strings in a log message of the one or more target script commands.
5. 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 of claims 1-4.
6. 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-4 when executed.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311153895.8A CN117172203B (en) | 2023-09-07 | 2023-09-07 | Method for processing script commands, electronic device and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311153895.8A CN117172203B (en) | 2023-09-07 | 2023-09-07 | Method for processing script commands, electronic device and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN117172203A CN117172203A (en) | 2023-12-05 |
| CN117172203B true CN117172203B (en) | 2025-01-28 |
Family
ID=88935130
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311153895.8A Active CN117172203B (en) | 2023-09-07 | 2023-09-07 | Method for processing script commands, electronic device and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117172203B (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109041051A (en) * | 2018-06-27 | 2018-12-18 | 深圳市共进电子股份有限公司 | Test method, system and computer equipment based on WPA encryption |
| CN112433876A (en) * | 2020-11-23 | 2021-03-02 | 中国建设银行股份有限公司 | Method and device for processing job error information and storage medium |
| CN115951868A (en) * | 2022-11-11 | 2023-04-11 | 芯华章科技(北京)有限公司 | Method, apparatus and storage medium for executing script command |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104536797B (en) * | 2015-01-14 | 2017-10-27 | 大唐微电子技术有限公司 | A kind of java applet precompile method and pre compiler |
| US10642712B2 (en) * | 2016-10-24 | 2020-05-05 | YScope Inc. | Log processing and analysis |
| CN112732563A (en) * | 2020-12-31 | 2021-04-30 | 深圳赛安特技术服务有限公司 | Interface script test log extraction method and device, terminal and storage medium |
| CN113050953A (en) * | 2021-04-21 | 2021-06-29 | 平安普惠企业管理有限公司 | Method, device and storage medium for generating code based on annotation |
| CN113391942B (en) * | 2021-06-18 | 2024-10-29 | 华云数据控股集团有限公司 | Shell script printing log method and device, electronic equipment and storage medium |
| CN115470125B (en) * | 2022-09-02 | 2023-07-25 | 芯华章科技(北京)有限公司 | Log file-based debugging method, device and storage medium |
| CN115374077A (en) * | 2022-09-15 | 2022-11-22 | 长城汽车股份有限公司 | Request log storage method and device, terminal equipment and readable storage medium |
| CN115857890A (en) * | 2022-11-11 | 2023-03-28 | 芯华章科技(北京)有限公司 | Method, apparatus and storage medium for generating script command |
-
2023
- 2023-09-07 CN CN202311153895.8A patent/CN117172203B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109041051A (en) * | 2018-06-27 | 2018-12-18 | 深圳市共进电子股份有限公司 | Test method, system and computer equipment based on WPA encryption |
| CN112433876A (en) * | 2020-11-23 | 2021-03-02 | 中国建设银行股份有限公司 | Method and device for processing job error information and storage medium |
| CN115951868A (en) * | 2022-11-11 | 2023-04-11 | 芯华章科技(北京)有限公司 | Method, apparatus and storage medium for executing script command |
Also Published As
| Publication number | Publication date |
|---|---|
| CN117172203A (en) | 2023-12-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN105468797A (en) | Information processing method and apparatus | |
| CN112100957B (en) | Method, emulator, storage medium for debugging a logic system design | |
| CN117787155B (en) | Chip testability code dynamic simulation test system and test method | |
| CN114662427A (en) | Debugging method and device for logic system design | |
| CN115827568B (en) | Method for acquiring data of logic system design, electronic equipment and storage medium | |
| CN115827636A (en) | Method for storing and reading simulation data of logic system design from waveform database | |
| CN115422866A (en) | Method for simulating logic system design on simulator and related equipment | |
| CN117910398A (en) | Method for simulating logic system design, electronic device and storage medium | |
| CN115470125B (en) | Log file-based debugging method, device and storage medium | |
| CN117172203B (en) | Method for processing script commands, electronic device and storage medium | |
| CN112506806B (en) | Method for debugging program, electronic device and storage medium | |
| CN116911219A (en) | Method, electronic device and storage medium for simulation of logic system design | |
| CN115857890A (en) | Method, apparatus and storage medium for generating script command | |
| CN112580282B (en) | Method, apparatus, device and storage medium for integrated circuit design verification | |
| CN115828805A (en) | Method, apparatus and storage medium for split logic system design | |
| CN116861829B (en) | Method for locating errors in logic system design and electronic equipment | |
| CN118504478B (en) | Method, electronic device and storage medium for designing simulation logic system | |
| CN114169287B (en) | Method for generating connection schematic diagram of verification environment, electronic equipment and storage medium | |
| CN117332733B (en) | A method, device and storage medium for locating errors in logic system design | |
| CN117313596B (en) | Method, equipment and storage medium for positioning errors of logic system design | |
| CN117172168B (en) | Method for realizing callback in simulation, electronic equipment and storage medium | |
| US20240241809A1 (en) | Methods, electronic devices and storage media for executing assertions | |
| CN117454835B (en) | Method for storing and reading waveform data, electronic device and storage medium | |
| US12271669B1 (en) | Executing instruction sequences generated from software interactions as part of formal verification of a design under test | |
| CN118428312B (en) | A method for processing random constraint problems, an electronic device and a storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |