CN115857890A - Method, apparatus and storage medium for generating script command - Google Patents
Method, apparatus and storage medium for generating script command Download PDFInfo
- Publication number
- CN115857890A CN115857890A CN202211414470.3A CN202211414470A CN115857890A CN 115857890 A CN115857890 A CN 115857890A CN 202211414470 A CN202211414470 A CN 202211414470A CN 115857890 A CN115857890 A CN 115857890A
- Authority
- CN
- China
- Prior art keywords
- script command
- script
- user interface
- graphical user
- electronic device
- 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.)
- Pending
Links
- 238000013515 script Methods 0.000 title claims abstract description 224
- 238000000034 method Methods 0.000 title claims abstract description 40
- 238000010801 machine learning Methods 0.000 claims description 7
- 230000004044 response Effects 0.000 claims description 5
- 238000013461 design Methods 0.000 description 116
- 238000004088 simulation Methods 0.000 description 32
- 238000012795 verification Methods 0.000 description 30
- 238000012360 testing method Methods 0.000 description 19
- 238000010586 diagram Methods 0.000 description 12
- 230000002093 peripheral effect Effects 0.000 description 8
- 230000008569 process Effects 0.000 description 8
- 238000004422 calculation algorithm Methods 0.000 description 4
- 238000004891 communication Methods 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012706 support-vector machine Methods 0.000 description 3
- 230000001413 cellular effect Effects 0.000 description 2
- 238000003066 decision tree Methods 0.000 description 2
- 238000000611 regression analysis Methods 0.000 description 2
- 241000543370 Galax Species 0.000 description 1
- 241000699670 Mus sp. Species 0.000 description 1
- 238000013528 artificial neural network Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 238000013468 resource allocation Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012549 training Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Images
Abstract
The application provides a method, equipment and storage medium for generating script commands. The method comprises the following steps: receiving a first script command input by a user; generating a graphical user interface according to the first script command, wherein the graphical user interface comprises a second dialogue box corresponding to a second script command; receiving parameters of the second script command via the second dialog box; and generating the second script command file according to the parameters from the second dialog box.
Description
Technical Field
The present application relates to the field of computer software technologies, and in particular, to a method, an apparatus, and a storage medium for generating a script command.
Background
Scripts (scripts) are executable files written in a certain format using a particular descriptive language. A scripting language, also known as a build-out language, or dynamic language, is a programming language used to control software applications, and scripts are usually saved as text and are only interpreted or compiled when called.
In the field of verification of integrated circuits, users (e.g., verification engineers) often need to interactively use script commands to configure various verification resources (e.g., FPGA resources and daughter card resources, etc.) and verification procedures. However, the script commands required to make the configuration typically require manual writing by the user. Furthermore, the script command has the problems of complicated script syntax, complicated input content and the like.
How to generate script commands quickly and avoid excessive manpower consumption is an urgent problem to be solved.
Disclosure of Invention
A first aspect of the present application provides a method of generating a script command, the method comprising: receiving a first script command input by a user; generating a graphical user interface according to the first script command, wherein the graphical user interface comprises a second dialogue box corresponding to a second script command; receiving parameters of the second script command via the second dialog box; and generating the second script command file according to the parameters from the second dialog box.
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 to cause the electronic device to perform the method according to the first aspect.
A third aspect of the application provides a non-transitory computer readable storage medium storing a set of instructions of a computer for, when executed, causing the computer to perform the method of the first aspect.
The application provides a method, equipment and a storage medium for generating script commands. The electronic equipment can automatically generate a graphical user interface according to the information of the input script command, and correspondingly display the multiple associated script commands on the graphical user interface so that a user can intuitively and conveniently fill information in the graphical user interface without manually inputting the script command for multiple times. The electronic equipment can automatically generate a corresponding script command file according to the filled parameter information for direct execution or copying by a user. The electronic device may also store the generated graphical user interface for reuse in subsequent verification tasks.
Drawings
In order to more clearly illustrate the technical solutions in the present application or the related art, the drawings needed to be used in the description of the embodiments or the related art will be briefly introduced below, and it is obvious that the drawings in the following description are only embodiments of the present application, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without creative efforts.
Fig. 1 shows a schematic structural diagram of an exemplary electronic device according to an embodiment of the present application.
FIG. 2 shows a schematic diagram of a simulation system according to an embodiment of the application.
FIG. 3A shows a schematic diagram of an exemplary graphical user interface according to an embodiment of the present application.
FIG. 3B illustrates a schematic diagram of another exemplary graphical user interface, according to an embodiment of the present application.
FIG. 3C illustrates a schematic diagram of an exemplary script command file generated in accordance with an embodiment of the present application.
FIG. 3D illustrates a schematic diagram of yet another exemplary graphical user interface, in accordance with an embodiment of the present application.
FIG. 4 sets forth a flow chart illustrating an exemplary method of generating script commands according to embodiments of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is further described in detail below with reference to the accompanying drawings in combination with specific embodiments.
It is to be noted that, unless otherwise defined, technical or scientific terms used herein shall have the ordinary meaning as understood by those of ordinary skill in the art to which this application belongs. As used in this application, the terms "first," "second," and the like do not denote any order, quantity, or importance, but rather are used to distinguish one element from another. The word "comprising" and similar words are intended to mean that the elements or items listed before the word cover the elements or items listed after the word and their equivalents, without excluding other elements or items. "connected," and like terms, are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect.
Fig. 1 shows a schematic structural diagram of an electronic device 100 according to an embodiment of the present application. The electronic device 100 may be an electronic device running a simulation tool. As shown in fig. 1, the electronic device 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 (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 associated with the techniques described herein. In some embodiments, processor 102 may also include multiple processors integrated into a single logic component. As shown in FIG. 1, the processor 102 may include a plurality of processors 102a, 102b, and 102c.
The memory 104 may be configured to store data (e.g., instruction sets, computer code, intermediate data, etc.). In some embodiments, the simulation test system for simulating a test design may be a computer program stored in memory 104. As shown in fig. 1, the data stored by the memory may include program instructions (e.g., for implementing the method of generating 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 memory stored program instructions and data and execute the program instructions to operate on the data to be processed. The memory 104 may include volatile memory devices or non-volatile memory devices. In some embodiments, the memory 104 may include Random Access Memory (RAM), read Only Memory (ROM), optical disks, magnetic disks, hard disks, solid State Disks (SSDs), flash memory, memory sticks, and the like.
The network interface 106 may be configured to provide communications with other external devices to the electronic device 100 via a network. The network may be any wired or wireless network capable of transmitting and receiving data. For example, the network may be a wired network, a local wireless network (e.g., bluetooth, wiFi, near Field Communication (NFC), etc.), a cellular network, the internet, or a combination of the above. It is to be understood that the type of network is not limited to the specific examples described above. In some embodiments, network interface 106 may include any combination of any number of Network Interface Controllers (NICs), radio frequency modules, transceivers, modems, routers, gateways, adapters, cellular network chips, and the like.
The peripheral interface 108 may be configured to connect the electronic device 100 with one or more peripheral devices to enable input and output of information. For example, the peripheral devices may include input devices such as keyboards, mice, touch pads, touch screens, microphones, various sensors, and output devices such as displays, speakers, vibrators, indicator lights, and the like.
The bus 110 may be configured to transfer information between various components of the electronic device 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 (a USB port, a PCI-E bus), and so forth.
It should be noted that although the electronic device architecture described above 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 normal operation. In addition, those skilled in the art will appreciate that the above-described electronic device architecture may also include only the components necessary to implement the embodiments of the present application, and need not include all of the components shown in the figures.
FIG. 2 shows a schematic diagram of a simulation system 200 according to an embodiment of the application.
As shown in FIG. 2, simulation system 200 may include a simulation tool 202 and electronic device 100 coupled to simulation tool 202.
The simulation tool 202, being a hardware system, may comprise an interface unit 2022 for communicatively coupling with the electronic device 100 for communication between the electronic device 100 and the simulation tool 202. In some embodiments, the 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), or 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 electronic device 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 or the like to the electronic device 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 may be read directly by electronic device 100. It is understood that the memory 2024 may also be independent of the simulation tool 202, e.g., using an external memory.
In addition to connecting to electronic device 100, simulation tool 202 may also connect to one or more daughter cards 204 via interface unit 2022.
The daughter card is used to provide peripherals to the DUT to complete the complete electronic system when prototype verification is performed using the simulation tool 202. Prototype verification refers to a verification method for restoring the actual use scene of a chip as much as possible before chip production and verifying whether the function of the chip is accurate and complete. The daughter cards 204 may include memory daughter cards (e.g., providing a DDR memory interface), communications daughter cards (e.g., providing various network interfaces or wireless network card interfaces), and so forth.
In some embodiments, unlike fig. 2, the simulation tool 202 may also be a digital simulation software system for simulating a design to be tested, such as a GalaxSim simulation tool available from china chapter technologies, inc. It is understood that the digital simulation software system at this time may be running on the electronic device 100.
In the field of verification of integrated circuits, in order to verify whether a logic system design is correct, a verification environment needs to be designed for verifying the logic system design. The verification environment may be run on a computer or simulation tool after compilation to perform simulation testing on various functions of the logic system design to verify that the logic system design is correct. To build a verification environment for verifying a logic system design, a user (e.g., a verification engineer) needs to configure various verification resources (e.g., a prototype verification board or a hardware simulator) and verification flows using script commands. For example, a user may select to use one of the FPGAs on the prototype verification board for his own verification project via script commands, and configure one or more daughter cards to connect to the FPGA. The user can also select his own authentication item and configure the corresponding parameters by script commands.
As described above, script commands usually need to be written manually by a user, and there are problems of complicated script syntax, cumbersome input contents, and the like. In view of the above problem, the present application introduces a Graphical User Interface (GUI) to provide a method for generating a script command. The graphical user interface is a computer operation user interface displayed in a graphical mode, is visual, and can directly enable a user to know which contents need to be filled and at which positions the contents need to be filled.
In some embodiments, electronic device 100 may receive user-entered script commands to generate a graphical user interface. The entered script commands may be, for example: "design _ load-gui". The script command may include a script command name "design _ load" and a parameter "gui". Wherein the script command name 'design _ load' represents a script command related to loading design; the parameter "gui" represents the generation of a graphical user interface for the flow "design _ load". It is understood that the parameter "gui" is merely an example, and that other parameters may be defined by the user to instruct the electronic device 100 to generate the graphical user interface.
The electronic apparatus 100 may determine a plurality of script commands associated with the script command according to the script command "design _ load-gui". The script command associated with the script command "design _ load-gui" may be, for example, "design _ load-work". Script command "design _ load-work" may be used to instruct electronic device 100 to configure a work catalog. The electronic apparatus 100 may determine a constraint condition of a parameter "work" of the script command "design _ load-work" as the description information. The description information may be an access path of the working directory. The electronic device 100 may generate a graphical user interface according to the constraint conditions of the script command "design _ load-work" and the parameter "work". When the user selects the parameter "work," the electronic device 100 may display the descriptive information in the graphical user interface 300.
As described above, the script command name "design _ load" may be matched with different parameters to generate different script commands. These parameters may be one or more parameters associated with loading the design, such as the source file of the design, top module (top module), working directory, verification environment (uvm) loaded on the design, storage path storing verification result log (log), and the like. The electronic device 100 typically needs to complete the process of loading the design by obtaining the values of these parameters.
In view of one or more parameters associated with the script command name "design _ load", FIG. 3A illustrates a schematic diagram of an exemplary graphical user interface 300 according to an embodiment of the application.
The graphic user interface 300 may include a dialog area 301 for presenting a dialog corresponding to the script command "design _ load-gui". The dialog region 301 may be a dialog box including one or more parameters (a plurality of parameters are shown in fig. 3A) corresponding to the script command name "design _ load". The dialog region 301 may include a dialog 3011 corresponding to the script command "design _ load-work". Dialog 3011 may include a parameter name "work" and a blank box for the user to fill in parameter values. In response to the value of the parameter "work" being selectable (i.e., the access path to "work" being available by selection), dialog 3011 may also include a customization component: a "Browse" button. The user can directly call out the folder where the value of the parameter work is located by clicking the Browse button, and fill in the parameter value by directly selecting the value in the folder.
Before receiving the script command "design _ load-gui" input by the user, the electronic device 100 may also receive other script commands. From these prior script commands, electronic device 100 may train to obtain a machine learning model. Commonly used machine learning models may include: naive Bayes models, decision tree models, nearest neighbor (KNN) algorithms, support Vector Machine (SVM) algorithms, regression analysis models, and the like.
By training the obtained machine learning model, the electronic apparatus 100 may determine, according to the script command "design _ load-gui", a plurality of script commands associated with the script command "design _ load-gui". For example, the electronic device 100 may determine a plurality of parameters associated with the script command name "design _ load" from a previous plurality of script commands. The plurality of parameters may include: "work", "top", "add _ file", "add _ directory", "source _ file", "log", "uvm", and the like. Wherein, the parameter "top" may represent loading a preset environment variable; the parameter "add _ file" may represent an add file; the parameter "add _ directory" may indicate that a directory is added; the parameter "source _ file" may represent the load source file; the parameter "log" may indicate that the results from the run are output to a specified log file; the parameter "uvm" may represent configuring the uvm verification environment for the design to be verified.
Thus, after determining the parameter associated with the script command name "design _ load", electronic device 100 may determine that the plurality of script commands associated with the script command "design _ load-gui" may include: "design _ load-work", "design _ load-top", "design _ load-add _ file", "design _ load-add _ direction", "design _ load-source _ file", "design _ load-log", and "design _ load-uvm", etc.
The electronic device 100 may determine constraints for the parameters described above. The constraint may be a requirement that the parameter needs to meet. For example, the constraint of the parameter "top" may be a string type, i.e., the value of the parameter "top" is a string, but not other forms of values. In some embodiments, the electronic device 100 may determine whether a constraint for a parameter, such as the parameter "top," is necessary. Depending on whether this constraint is necessary, the electronic device 100 may set the dialog box to fill or not. The electronic device 100 may prompt the user in a gray or star marked manner whether the dialog box is a mandatory item. The electronic device 100 may further determine the constraint condition of the parameter as a value range, for example, the value range of the parameter representing the voltage value applied to the chip may be 0-6V. According to the value range of the voltage parameter, the electronic device 100 may limit the filling range of the value in the dialog box. If the voltage value filled in by the user exceeds 6V (e.g., 7V), the electronic device 100 may automatically rewrite the value in the dialog box to 6V. The electronic device 100 may also determine whether the constraints of the parameters are applicable to the customized component. For example, the value of the parameter may be one of several fixed values (e.g., 1, 2, 3). From these fixed values, electronic device 100 may generate a custom component in the dialog, as illustrated by dialog 3014 in FIG. 3A: drop down the menu box for the user to select a value directly from the drop down menu box. The specific content of the constraints may be determined by the needs of the verification task and the nature of the parameters.
As shown in fig. 3A, according to the parameters "top", "add _ file", "add _ directory", "source _ file", "log", "uvm", and the constraints of the parameters, the electronic device 100 may generate dialog boxes corresponding to the parameters in the graphical user interface 300. For example, a dialog 3012 corresponding to the parameter "top", a dialog 3013 corresponding to the parameter "uvm", and the like. Dialog box 3012 may include a parameter name "top," as well as a blank box for the user to fill in parameter values. In response to the uvm environment parameters for configuration may include "uvm1.1" and "uvm1.2," the electronic device 100 may generate a dialog 3013 including the parameter name "uvm1.1" and another dialog including the parameter name "uvm 1.2. The constraint of the parameter "uvm" may be whether necessary or not. The electronic device 100 may generate a customized component according to the constraint of the parameter "uvm": and selecting a frame. The user can indicate whether to apply the uvm verification environment by checking a selection box. That is, the presentation form of the dialog box can be flexibly configured according to the constraint conditions of the parameters.
For different verification tasks, the user may need to add a parameter associated with the script command "design _ load-gui" but not yet shown in the dialog area 301. Accordingly, the graphical user interface 300 further may include a button "Add" to Add a dialog box for the script command. The electronic device 100 may Add a line of dialog box in the dialog box area 301 by receiving an indication that the user clicks the Add button "Add" for the user to input the parameter name and the parameter value by himself. Similarly, the user may need to delete parameters (or dialogs) that are not relevant to this authentication task, but that have been presented in the dialog area 301. Accordingly, the graphic user interface 300 may further include a button "Delete" of the dialog box for deleting the script command. The electronic device 100 may Delete the selected line of dialog in the dialog area 301 to Delete the superfluous parameters by receiving an indication that the user selected a certain parameter and clicked the Delete button "Delete".
The electronic device 100 may receive values of parameters of each script command associated with the script command "design _ load-gui" via a plurality of dialog boxes in the dialog box area 301. For example, electronic device 100 may receive that the value of the parameter "work" of the script command "design _ load-work" is "work" via dialog 3011. As shown in fig. 3A, if the other parameters are not parameters necessary for the verification task, the electronic device 100 may not receive parameter values of the other parameters.
In some embodiments, to assist the user in clarifying the meaning of the parameters in the dialog area 301, the graphical user interface 300 may display help information 303. The help information 303 may include descriptive information of the parameters in the dialog area 301. The help information 303 may also be hidden.
In some embodiments, to facilitate the user's use of the generated script command "design _ load-work", the graphical user interface 300 may further include an Execute button "Execute" and a Copy button "Copy". The electronic apparatus 100 may directly Execute the generated script command file by receiving an instruction that the user clicks the execution button "Execute". The electronic device 100 may directly Copy the generated script command by receiving an indication that the user clicks the Copy button "Copy" for the user to paste into a desired file.
Since the processes of resource allocation have high similarity when performing verification projects, script commands input by users usually have a relatively similar fixed pattern (pattern). For example, a user always needs to read a netlist (netlist) of a design, source code of the design, determine a top-level module (top module), configure a system clock, configure hardware simulation tool (e.g., hardware simulator) resources, configure daughter card resources, configure the connection of daughter cards to the hardware simulation tool, and so on. Therefore, when the user inputs a script command of any link in the above flow, it usually means that the user needs to input a series of other script commands associated with the script command.
In view of this, fig. 3B illustrates a schematic diagram of another exemplary graphical user interface 310 according to an embodiment of the present application.
In some embodiments, the user may enter a script command "design _ read-netlist" to cause electronic device 100 to read the netlist of the design. The electronic device 100 may determine, from the previous plurality of script commands, a plurality of script command names associated with the script command "design _ read-netlist". The plurality of script command names may include: "design _ load", "estimator _ spec", and "create _ clock", etc. Wherein the script command 'design _ read' may represent reading a design; the script command "emulator _ spec" may represent configuring hardware emulator resources; the script command "create _ clock" may represent a configuration clock signal. Further, the electronic device 100 may determine parameters corresponding to a plurality of script command names to determine a plurality of script commands. The plurality of script commands may include, for example: "design _ load-work", "design _ load-top", "estimator _ spec-add", "create _ clock-sig _ name", "create _ clock-frequency", and the like.
As shown in fig. 3B, the electronic device 100 may generate a dialog box corresponding to the script command in a dialog box region 311 of the graphical user interface 310 according to the script command and the condition that the parameter in the script command needs to satisfy (i.e., the constraint condition of the parameter). For example, the electronic apparatus 100 may generate the dialog 3111 according to the script command "design _ load-work".
The electronic device 100 may receive values for parameters in the script commands via the dialogs. For example, the value of the parameter "netlist" in the script command "design _ read-netlist" may be "$ env (CASE NAME). Vm"; the value of a parameter 'work' in a script command 'design _ load-work' can be 'work'; the value of a parameter "top" in the script command "design _ load-top" can be "$ env (CASE NAME)"; the value of the parameter "add" in the script command "emulate _ spec-add" may be "file hw-config.hdf"; the value of a parameter sig _ name in the script command create _ clock-sig _ name can be 'pci _ clk _ i'; the value of the parameter "frequency" in the script command "create _ clock-frequency" may be "100MHz"; the value of a parameter sig _ name in another script command create _ clock-sig _ name can be 'wb _ clk _ i'; the value of the parameter "frequency" in the script command "create _ clock-frequency" may be "120MHz".
The user may need to add or delete script commands for different authentication tasks. Similar to FIG. 3A, the graphical user interface 320 may include a button "Add" to Add a dialog box for a script command and a button "Delete" to Delete a dialog box for a script command.
To assist the user in clarifying the meaning of each script command in the dialog region 311, the graphical user interface 310 may display help information 313. The help information 313 may also be hidden.
FIG. 3C illustrates a schematic diagram of an exemplary script command file 320 generated in accordance with an embodiment of the present application.
The electronic device 100 may generate a script command file 320 in the script command display area 312 based on the parameters from each dialog box in the dialog box area 311.
Returning to fig. 3B, similar to graphical user interface 300, script command display area 312 in graphical user interface 310 may also include an Execute button "Execute" and a Copy button "Copy" for user processing of script command file 320.
In some embodiments, due to limitations of the display size of the graphical user interface, the electronic device 100 cannot show multiple dialog boxes corresponding to all script commands in one graphical user interface.
In view of this, fig. 3D shows a schematic view of a further exemplary graphical user interface 330 according to an embodiment of the present application.
The dialog area 331 in the graphical user interface 330 may include a plurality of tab pages. Each tab corresponds to a script command name. As shown in fig. 3D, the first tab page may correspond to the script command name "design _ load", and the second tab page may correspond to the script command name "create _ clock". The first tab page may also multiplex a plurality of dialog boxes in the dialog box area 301 of the graphical user interface 300 shown in fig. 3A. It will be appreciated that more tab pages may be included in the dialog region 331.
The electronic device 100 may generate a script command file in the script command display area according to the parameters from each dialog box in the plurality of tab pages.
The above process describes a process in which the electronic device 100 generates the graphical user interface 300 or 310 and generates the script command file "design _ load-work word" or the script command file 320 according to the parameters in the graphical user interface. However, if the electronic device 100 receives a script command to generate a new graphical user interface each time, it is very resource consuming. And it is understood that the graphical user interface generated by the electronic device 100 may be the same or highly similar for the same script command (e.g., "design _ load-gui"). Therefore, the electronic device 100 may store the generated graphical user interface for reuse the stored graphical user interface the next time the same script command is received.
In some embodiments, a database storing the generated graphical user interface may be provided in the electronic device 100. The electronic device 100 may store the aforementioned generated graphic user interface 300, 310, or 330 in a database. The graphic user interface 300, 310, or 330 may have a correspondence relationship with the script command "design _ load-work". When the electronic apparatus 100 receives a new script command, which may be, for example, "design _ read-gui", a plurality of script commands associated with the script command "design _ read-gui" may be determined. The plurality of script commands may include, for example: "design _ read-network", "design _ load-work", "design _ load-top", "estimator _ spec-add", "create _ clock-design _ name", "create _ clock-frequency", and the like. In response to the script command including "design _ load-work", the electronic device 100 may obtain the graphical user interface 300, 310, or 330 corresponding to the script command "design _ load-work" directly from the database. The user may directly fill in the values of the respective parameters in the acquired graphic user interface 300, 310, or 330, or perform further processing by adding a button "Add" (or "Delete") of a dialog box of a script command (or a Delete command) on the basis of the graphic user interface 300, 310, or 330. Which graphical user interface is specifically used may be determined by the user based on the actual verification task.
In this way, even if the electronic device 100 receives a new script command, when it is determined that the plurality of script commands associated with the new script command include a script command that has been generated corresponding to a graphical user interface, the electronic device 100 may also retrieve a stored graphical user interface from the database and multiplex the graphical user interface.
Through the above process, the electronic device 100 may automatically generate a graphical user interface according to the information of the input script command, and correspondingly display the information of the plurality of associated script commands on the graphical user interface. In this way, the user can intuitively and conveniently fill information in the graphical user interface without manually inputting script commands for multiple times. The electronic equipment can automatically generate a corresponding script command file according to the filled information for direct execution or copying by a user. Electronic device 100 may also store the generated graphical user interface for reuse in subsequent verification tasks.
FIG. 4 illustrates a flow diagram of an exemplary method 400 of generating a script command in accordance with embodiments of the present application. The method 400 may be implemented by the electronic device 100 shown in fig. 1. The method 400 may include the following steps.
At step 402, the electronic device 100 may receive a first script command (e.g., script command "design _ load-gui" corresponding to fig. 3A, or script command "design _ read-netlist" corresponding to fig. 3B or fig. 3D) input by a user.
At step 404, the electronic device 100 may generate a graphical user interface (e.g., graphical user interface 300 in fig. 3A, or graphical user interface 310 in fig. 3B, or graphical user interface 330 in fig. 3D) according to the first script command. Wherein the graphical user interface may include a second dialog box (e.g., dialog box 3011 in fig. 3A or dialog box 3111 in fig. 3B) corresponding to a second script command (e.g., script command "design _ load-work").
In some embodiments, the electronic device 100 may determine, according to the first script command, a plurality of script commands (e.g., "design _ load-work", design _ load-top, design _ load-add _ file, design _ load-add _ direct, design _ load-source _ file, design _ load-log, design _ load-uvm ", or" design _ load-work ", design _ load-top, equation _ spec-add, create _ clock-name, create _ clock-frequency", etc.) associated with the first script command, and the plurality of script commands may include the second script command (e.g., "design _ load-work").
In some embodiments, the electronic device 100, via a pre-trained machine learning model (e.g., a na iotave bayes model, a decision tree model, a KNN algorithm, an SVM algorithm, a regression analysis model, etc.) according to the first script command, can determine script commands associated with the first script command. The machine learning model may be pre-trained by the electronic device 100 based on a plurality of prior script commands input by the user.
In some embodiments, the graphical user interface may further include buttons to Add or Delete dialog boxes for script commands (e.g., "Add" button and "Delete" button in fig. 3A, 3B, or 3D).
In some embodiments, the graphical user interface may display or hide "help information" (e.g., help information 303 in fig. 3A or help information 313 in fig. 3B) that explains the parameter.
In some embodiments, electronic device 100 may store the graphical user interface (e.g., graphical user interface 300 of fig. 3A, graphical user interface 310 of fig. 3B, or graphical user interface 330 of fig. 3D) to a database. The electronic apparatus 100 may receive a third script command (e.g., script command "design _ read-gui") input by the user. In response to a plurality of script commands (e.g., "design _ read-list", "design _ load-work", "design _ load-top", "estimator _ spec-add", "create _ clock-name", "create _ clock-frequency", etc.) associated with the third script command may include the second script command (e.g., "design _ load-work"), electronic device 100 may retrieve the stored graphical user interface (e.g., graphical user interface 300 in fig. 3A, graphical user interface 310 in fig. 3B, or graphical user interface 330 in fig. 3D) from the database.
At step 406, electronic device 100 may receive a parameter (e.g., parameter "work") of the second script command via the second dialog box (e.g., dialog box 3011 in fig. 3A or dialog box 3111 in fig. 3B). The parameter received here may be a value of the parameter (for example, the value of the parameter "work" is "work").
In step 408, the electronic device 100 may generate the second script command file (e.g., the script command file "design _ load-work work" shown in the script command display area 302 in fig. 3A) according to the parameter from the second dialog box.
In some embodiments, the plurality of script commands may include a fourth script command (e.g., script command "design _ load-top"). The graphical user interface (e.g., graphical user interface 300 in fig. 3A) may include a fourth dialog box (e.g., dialog box 3012 in fig. 3A) corresponding to the fourth script command. The electronic device 100 via the fourth dialog box may receive a parameter of the fourth script command (e.g., a value of the parameter "top"). According to the second script command (e.g., script command "design _ load-work"), the fourth script command (e.g., script command "design _ load-top"), the parameter of the second script command (e.g., the parameter "work" takes a value of "work"), and the parameter of the fourth script command (e.g., the parameter "top" takes a value of "empty"), the electronic device 100 may generate the script command file (e.g., script command file "design _ load-work" shown in script command display area 302 in fig. 3A).
In some embodiments, the graphical user interface (e.g., graphical user interface 300 in fig. 3A or graphical user interface 310 in fig. 3B) may further include an Execute button "Execute" and a Copy button "Copy". The electronic device 100 may directly Execute the generated script command file (e.g., the script command file "design _ load-work" in fig. 3A or the script command file 320 in fig. 3C) by receiving an indication that the user clicks the Execute button "Execute". The electronic device 100 may directly Copy the script command file by receiving an indication that the user clicks the Copy button "Copy" for the user to paste into a desired file.
The embodiment of the application also provides the electronic equipment. The electronic device may be the electronic device 100 of fig. 1. The electronic device 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 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 for causing the electronic device to perform the method 400 when executed.
Some embodiments of the present application are described above. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
Those of ordinary skill in the art will understand that: the discussion of any embodiment above is meant to be exemplary only, and is not intended to intimate that the scope of the disclosure, including the claims, is limited to these examples; within the context of the present application, features from the above embodiments or from different embodiments may also be combined, steps may be implemented in any order, and there are many other variations of the different aspects of the present application as described above, which are not provided in detail for the sake of brevity.
While the present application has been described in conjunction with specific embodiments thereof, many alternatives, modifications, and variations of these embodiments will be apparent to those of ordinary skill in the art in light of the foregoing description. For example, other memory architectures, such as Dynamic RAM (DRAM), may use the discussed embodiments.
The present application is intended to embrace all such alternatives, modifications and variances which fall within the broad scope of the appended claims. Therefore, any omissions, modifications, substitutions, improvements, and the like that may be made without departing from the spirit and principles of the application are intended to be included within the scope of the application.
Claims (10)
1. A method of generating a script command, comprising:
receiving a first script command input by a user;
generating a graphical user interface according to the first script command, wherein the graphical user interface comprises a second dialogue box corresponding to a second script command;
receiving parameters of the second script command via the second dialog box; and
and generating the second script command file according to the parameters from the second dialog box.
2. The method of claim 1, wherein generating a graphical user interface in accordance with the first script command further comprises:
determining a plurality of script commands associated with the first script command according to the first script command, the plurality of script commands including the second script command;
determining constraints of parameters of the second script command;
and generating the graphical user interface according to the script commands and the constraint conditions.
3. The method of claim 2, further comprising:
storing the graphical user interface to a database;
receiving a third script command input by a user;
in response to the plurality of script commands associated with the third script command including the second script command, retrieving the stored graphical user interface from the database.
4. The method of claim 2, wherein the constraints further comprise:
at least one of a data type, a necessity, a value range, whether a custom component applies, or descriptive information.
5. The method of claim 1, wherein the graphical user interface further comprises a button to add or delete a dialog box of a script command.
6. The method of claim 2, wherein determining, from the first script command, a plurality of script commands associated with the first script command further comprises:
determining, from the first script command, a plurality of script commands associated with the first script command via a pre-trained machine learning model, the machine learning model being pre-trained from a plurality of prior script commands input by a user.
7. The method of claim 2, wherein the plurality of script commands includes a fourth script command, the graphical user interface includes a fourth dialog box corresponding to the fourth script command, the method further comprising:
receiving parameters of the fourth script command via the fourth dialog box; and
and generating the script command file according to the second script command, the fourth script command, the parameters of the second script command and the parameters of the fourth script command.
8. The method of claim 5, wherein the graphical user interface further comprises an execute button and a copy button.
9. 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-8.
10. A non-transitory computer readable storage medium storing a set of instructions of an electronic device, which when executed, cause the electronic device to perform the method of any of claims 1 to 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211414470.3A CN115857890A (en) | 2022-11-11 | 2022-11-11 | Method, apparatus and storage medium for generating script command |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211414470.3A CN115857890A (en) | 2022-11-11 | 2022-11-11 | Method, apparatus and storage medium for generating script command |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115857890A true CN115857890A (en) | 2023-03-28 |
Family
ID=85663250
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211414470.3A Pending CN115857890A (en) | 2022-11-11 | 2022-11-11 | Method, apparatus and storage medium for generating script command |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115857890A (en) |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6311320B1 (en) * | 1998-12-07 | 2001-10-30 | Lsi Logic Corporation | Alterable scripting tool and method |
| CN101000545A (en) * | 2006-01-12 | 2007-07-18 | 国际商业机器公司 | Graphical assistant method and system for generating object setup scripts |
| US20120311471A1 (en) * | 2011-05-31 | 2012-12-06 | International Business Machines Corporation | Automatic generation of user interfaces |
| US20160366248A1 (en) * | 2015-06-09 | 2016-12-15 | Alibaba Group Holding Limited | System, method, and device for remotely operating a server |
| US20170300403A1 (en) * | 2016-04-15 | 2017-10-19 | Red Hat Israel, Ltd. | Recordation of user interface events for script generation |
| CN109542539A (en) * | 2018-11-22 | 2019-03-29 | 郑州云海信息技术有限公司 | The method and system of script argument in a kind of configuration Web system |
| CN110837500A (en) * | 2019-10-12 | 2020-02-25 | 中国平安财产保险股份有限公司 | Data screening method and device based on local embedded window and computer equipment |
-
2022
- 2022-11-11 CN CN202211414470.3A patent/CN115857890A/en active Pending
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6311320B1 (en) * | 1998-12-07 | 2001-10-30 | Lsi Logic Corporation | Alterable scripting tool and method |
| CN101000545A (en) * | 2006-01-12 | 2007-07-18 | 国际商业机器公司 | Graphical assistant method and system for generating object setup scripts |
| US20120311471A1 (en) * | 2011-05-31 | 2012-12-06 | International Business Machines Corporation | Automatic generation of user interfaces |
| US20160366248A1 (en) * | 2015-06-09 | 2016-12-15 | Alibaba Group Holding Limited | System, method, and device for remotely operating a server |
| US20170300403A1 (en) * | 2016-04-15 | 2017-10-19 | Red Hat Israel, Ltd. | Recordation of user interface events for script generation |
| CN109542539A (en) * | 2018-11-22 | 2019-03-29 | 郑州云海信息技术有限公司 | The method and system of script argument in a kind of configuration Web system |
| CN110837500A (en) * | 2019-10-12 | 2020-02-25 | 中国平安财产保险股份有限公司 | Data screening method and device based on local embedded window and computer equipment |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113312879B (en) | Chip circuit function verification system, method, device and storage medium | |
| CN107451663B (en) | Algorithm componentization, modeling method and device based on algorithm components and electronic equipment | |
| US8984496B2 (en) | Extensible internal representation of systems with parallel and sequential implementations | |
| WO2021109928A1 (en) | Creation method, usage method and apparatus for machine learning scheme template | |
| CN112949233B (en) | Automatic development method and device of FPGA chip and electronic equipment | |
| CN113795843A (en) | Generation of dynamic design flow for integrated circuits | |
| CN112100949A (en) | Automatic development method and device of integrated circuit chip and electronic equipment | |
| JPH11513512A (en) | Method of manufacturing digital signal processor | |
| CN113835945A (en) | Chip testing method, device, equipment and system | |
| CN112560401A (en) | Verilog file conversion method, device, storage medium and equipment | |
| CN114662427B (en) | Debugging method and device for logic system design | |
| CN111624475B (en) | Method and system for testing large-scale integrated circuit | |
| US10192013B1 (en) | Test logic at register transfer level in an integrated circuit design | |
| JP6265788B2 (en) | Simulation device, interface module generation device, and program | |
| CN115470125B (en) | Log file-based debugging method, device and storage medium | |
| Huggi et al. | Design and verification of memory elements using python | |
| CN115857890A (en) | Method, apparatus and storage medium for generating script command | |
| US10095822B1 (en) | Memory built-in self-test logic in an integrated circuit design | |
| CN115906730A (en) | Method, apparatus and storage medium for verifying logic system design | |
| US10936776B1 (en) | Analyzing waveform data generated for simulated circuit design | |
| CN108334313A (en) | Continuous integrating method, apparatus and code management system for large-scale SOC research and development | |
| CN110312990A (en) | Configuration method and system | |
| CN117077616B (en) | Circuit generation method, device, equipment and medium based on structure guidance | |
| US9710581B1 (en) | VIP assisted method and apparatus to enable SOC integration and software development | |
| CN115455877B (en) | Verification platform generation device, method, medium and electronic equipment |
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 |