Method and device for quickly establishing post-simulation environment of digital chip and simulation method and device

Abstract

The invention discloses a method and a device for quickly establishing a post-simulation environment of a digital chip and a simulation method and device. The method comprises the following steps of: establishing a basic file structure; putting a script to be executed in the basic file structure, creating a shortcut key of the script to be executed, and determining a hierarchical structure of a moduleA folder in the basic file structure; the method comprises the following steps of: searching a related file in a fixed directory tree through a script to be executed, generating a file list netlist.f file, and distinguishing an SDF (Software Definition Function) anti-standard command through macro definition to obtain an anti-standard file; according to the key word sdrange and the anti-standard file, the anti-standard content of the testbench file is updated; the method comprises the following steps: accessing a makefile through a script to be executed, extracting case information, and generating a rear imitation folder vcsend in combination with the extracted information; simulation is carried out based on the post-simulation folder, the simulation result is analyzed, and the simulation report is generated, so that one-button post-simulation environment automatic construction is realized, and the efficiency and accuracy of post-simulation process construction are improved.

Description

Technical Field

[0001] This application relates to the field of simulation technology, and more specifically, to a method and apparatus for rapidly building a digital chip post-simulation environment. Background Technology

[0002] With the continuous advancement of integrated circuit technology, design scale is increasing daily, and complexity is growing exponentially. Post-simulation has become an indispensable and crucial step in the digital chip design process to ensure successful tape-out. Post-simulation requires verifying the gate-level netlist and standard delay format (SDF) with delay information generated after placement and routing in simulation tools.

[0003] Currently, engineers typically use the following two methods for post-simulation: (1) Manually operating the graphical user interface (GUI) of commercial EDA tools: Engineers need to manually click on the interface to load various library files, gate-level netlists, testbench, and SDF files in sequence, and configure complex simulation parameters. This method has the disadvantages of being cumbersome, prone to errors, heavily reliant on personal experience, and not reusable. Every time the simulation environment changes slightly (such as netlist or SDF file updates), the above manual process must be repeated, which is extremely inefficient and makes it difficult to ensure the consistency of each configuration. (2) Using the command-line scripts or simple Shell scripts that come with the simulation tools: Although some simulation tools support command-line mode, engineers still need to write and maintain complex scripts themselves. These scripts are usually loosely structured, lack a unified error handling mechanism, and have poor readability and maintainability. When a project needs to manage a large number of files, handle SDF back-annotations for multiple process corners, and multiple simulation cases, the existing script solutions are inadequate and prone to configuration omissions and errors, resulting in unreliable simulation results. (3) The simulation process was done step by step, without fully utilizing the multi-threaded performance of the server, resulting in each round of simulation taking too long. Summary of the Invention

[0004] This invention provides a method and apparatus for rapidly building a digital chip post-simulation environment, thereby solving the technical problems of the prior art as described in the background section. The method includes: Construct a basic file structure and determine the directory tree of the basic file structure; Place the script to be executed in a fixed directory of the basic file structure, create a shortcut key for the script to be executed, and determine the hierarchical structure of the moduleA folder in the basic file structure; The script to be executed searches for relevant files in the directory tree and generates the file_list_netlist.f file; SDF back-annotation commands are generated based on the basic file structure, and the SDF back-annotation commands are distinguished through macro definitions to obtain back-annotation files; Update the annotated content of the testbench file using the keyword sdf_annotate and the annotated file; The script to be executed accesses the Makefile, extracts case information, and combines it with the information already extracted above to generate the simulated folder vcs_end. Simulation is performed based on the simulated folder, the simulation results are analyzed, and a simulation report is generated. Specifically, the basic file structure is a project folder, which includes rtl files and vcs files. The rtl files include test files, the vcs files include makefile files, and the test files include testbench files.

[0005] In some specific embodiments, the rtl file also includes an ana file, a dig file, an flist file, a standcell file, and a moduleA file.

[0006] In some specific embodiments, the script to be executed is placed in a fixed directory of the basic file structure, a shortcut key for the script to be executed is created, and the hierarchical structure of the moduleA folder in the basic file structure is determined, specifically as follows: Place the script to be executed in the fixed directory, and create a shortcut key for the script to be executed by setting the cshrc file; Execute the script to be executed in the project folder using the shortcut key, and enter the name of the module to be verified later; The name of the module that needs to be verified in the post-simulation process is compared with the name of the moduleA folder to ensure that the name of the module that needs to be verified in the post-simulation process matches the name of the moduleA folder. Based on the script to be executed, the contents of all files are traversed through the file paths in the file_list.f file, and the hierarchical structure of the moduleA folder in the basic file structure is determined by combining the name of the moduleA folder.

[0007] In some specific embodiments, the script to be executed searches for relevant files in the directory tree and generates a file_list_netlist.f file, specifically as follows: The file_list.f file is identified by the file extension of the relevant files; The source file paths of all moduleA files are obtained by identifying keywords, and these source file paths are replaced with the file paths of the subsequent netlist, while a new file file file_list_netlist.f is generated.

[0008] In some specific embodiments, the back-annotation content of the testbench file is updated using the keyword `sdf_annotate` and the back-annotation file, specifically as follows: Use the keyword `sdf_annotate` to determine if there are any annotated contents in the testbench; If no anti-annotation content exists, the anti-annotation file will be added automatically. If back-annotation content exists, extract the back-annotation hierarchy of moduleA in the back-annotation file based on the characteristics of the function $sdf_annotate; When the original and new anti-annotation hierarchies are inconsistent, the original anti-annotation content will be updated to the latest anti-annotation content.

[0009] In some specific embodiments, the post-simulation folder vcs_end includes a makefile and multiple case folders, each of which contains multiple corner folders.

[0010] In some specific embodiments, simulation is performed based on the post-simulation folder, the simulation results are parsed, and a simulation report is generated, specifically as follows: The `make all` command is executed on the simulated folder, and multiple corner folders under each case folder are automatically simulated. Generate a makefile in each case folder, and generate a pseudo-target log based on the makefile in the case folder; Use the egrep command to extract the simulation results of each corner file into a result file to obtain the result content; The simulation results are analyzed based on the result content, and a simulation report is generated.

[0011] Accordingly, this invention also proposes a rapid setup of a digital chip simulation environment and simulation device, the device comprising: A building module is used to construct the basic file structure and determine the directory tree of the basic file structure; The module is defined to place the script to be executed into a fixed directory of the basic file structure, create a shortcut key for the script to be executed, and determine the hierarchical structure of the moduleA folder in the basic file structure. The first generation module is used to search for relevant files in the directory tree using the script to be executed, and generate the file_list_netlist.f file; The back-annotation module is used to generate SDF back-annotation commands based on the basic file structure, and to distinguish the SDF back-annotation commands through macro definitions to obtain back-annotation files; The update module is used to update the back-annotation content of the testbench file using the keyword sdf_annotate and the back-annotation file; The second generation module is used to access the Makefile file through the script to be executed, extract case information, and combine it with the information already extracted above to generate the folder vcs_end. The parsing module is used to perform simulation based on the post-simulation folder, parse the simulation results, and generate a simulation report; Specifically, the basic file structure is a project folder, which includes rtl files and vcs files. The rtl files include test files, the vcs files include makefile files, and the test files include testbench files.

[0012] One embodiment of the present invention also provides a computing device, including: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, wherein when the computer-executable instructions are executed by the processor, the steps of rapidly building a digital chip post-simulation environment and simulation method as described above are implemented.

[0013] One embodiment of the present invention also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the steps of rapidly building a digital chip post-simulation environment and simulation method as described in any of the above.

[0014] By applying the above technical solutions, a method for rapidly building a digital chip post-simulation environment is proposed. The method includes: constructing a basic file structure and determining its directory tree; placing the script to be executed in a fixed directory of the basic file structure, creating a shortcut key for the script, and determining the hierarchical structure of the moduleA folder within the basic file structure; searching for relevant files in the directory tree using the script to be executed and generating a file named file_list_netlist.f; generating SDF back-annotation commands based on the basic file structure, and distinguishing these commands using macro definitions to obtain back-annotation files; updating the back-annotation content of the testbench file using the keyword sdf_annotate and the back-annotation files; accessing the makefile file using the script to be executed, extracting case information, and combining this information with the extracted information to generate a post-simulation folder named vcs_end; performing simulation based on the post-simulation folder, parsing the simulation results, and generating a simulation report. This achieves one-click automated construction of the post-simulation environment, improving the efficiency and accuracy of the post-simulation process. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a flowchart illustrating a method for rapidly building a digital chip simulation environment and simulation techniques, as provided in an embodiment of this application. Figure 2 This is a schematic diagram of the basic file structure provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of a simulation environment and simulation device for quickly building a digital chip, provided in an embodiment of this application; Figure 4 This is a structural block diagram of a computing device provided in an embodiment of this application. Detailed Implementation

[0017] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0018] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0019] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0020] In summary, existing post-simulation workflow construction methods suffer from low efficiency, poor accuracy, low repeatability, and high maintenance costs. This has become a technical bottleneck affecting chip design verification cycles and final tape-out success rates. Therefore, there is an urgent need in this field for a technical solution that can automate, standardize, and reliably complete the post-simulation workflow construction.

[0021] To address the shortcomings of the existing technologies, this invention provides a method for rapidly building a digital chip post-simulation environment.

[0022] Specifically, such as Figures 1-2 As shown, this application proposes a method for rapidly building a digital chip post-simulation environment, the method comprising the following steps: Step S101: Construct a basic file structure and determine the directory tree of the basic file structure; Specifically, the basic file structure is a project folder, which includes rtl files and vcs files. The rtl files include test files, the vcs files include makefile files, and the test files include testbench files.

[0023] In one possible implementation, the rtl file also includes an ana file, a dig file, an flist file, a standcell file, and a moduleA file.

[0024] Specifically, this script relies on a fixed file structure, allowing for targeted modification or addition of files. The basic file structure is as follows: Figure 2 As shown, the RTL files mainly store the source code files, which are further divided into ana, dig, flist, standcell, test, and module ana for post-simulation verification. Taking module A as an example, the ana folder contains the simulation model; the dig folder contains all the source code for module A; the flist folder contains the file_list.f file, which mainly contains all the files that need to be compiled during the simulation; the standcell folder links to the process plant's standcell; the test folder contains the files related to the simulation testbench; module A contains two linked folders, net and sdf, which contain the netlist and sdf files provided after the digital back-end winding, respectively. Then there are the vcs folders, which only contain the makefile, which mainly contains the commands and parameters of the relevant tools used in the simulation, as well as information on different cases during the simulation. Both the RTL and vcs folders are stored in the project folder.

[0025] Step S102: Place the script to be executed into a fixed directory of the basic file structure, create a shortcut key for the script to be executed, and determine the hierarchical structure of the moduleA folder in the basic file structure.

[0026] In one possible implementation, the script to be executed is placed in a fixed directory of the basic file structure, a shortcut key for the script to be executed is created, and the hierarchical structure of the moduleA folder in the basic file structure is determined, specifically as follows: Place the script to be executed in the fixed directory, and create a shortcut key for the script to be executed by setting the cshrc file; Execute the script to be executed in the project folder using the shortcut key, and enter the name of the module to be verified later; The name of the module that needs to be verified in the post-simulation process is compared with the name of the moduleA folder to ensure that the name of the module that needs to be verified in the post-simulation process matches the name of the moduleA folder. Based on the script to be executed, the contents of all files are traversed through the file paths in the file_list.f file, and the hierarchical structure of the moduleA folder in the basic file structure is determined by combining the name of the moduleA folder.

[0027] In this embodiment, the script is placed in a fixed directory. By setting a shortcut key for executing the script in the cshrc (Linux system user configuration file) file, the script can be executed from any folder. Executing the script in the project folder will automatically prompt the user to enter the name of the module to be verified. By comparing the entered name with the name of the moduleA folder, the script will automatically detect whether the entered name is correct. If there are multiple modules, the user can continue to enter until an empty Enter key is detected, proceeding to the next step. At this point, the script will traverse all file contents using the file paths in the file_list.f file, and automatically analyze the hierarchical structure of moduleA by combining it with the name of moduleA. After the analysis is completed, the result is printed for the user to confirm. If the user believes the result is incorrect, they can manually enter the module hierarchical structure (this hierarchical structure is a necessary condition for correctly back-annotating the SDF).

[0028] Step S103: The script to be executed searches for relevant files in the directory tree and generates the file_list_netlist.f file.

[0029] In one possible implementation, the script to be executed searches for relevant files in the directory tree and generates a file_list_netlist.f file, specifically as follows: The file_list.f file is identified by the file extension of the relevant files; The source file paths of all moduleA files are obtained by identifying keywords, and these source file paths are replaced with the file paths of the subsequent netlist, while a new file file file_list_netlist.f is generated.

[0030] In this embodiment, the script automatically searches for all relevant files in a fixed directory tree. Specifically, relevant files refer to all files that need to be compiled, generally .v or .sv files. The File_list_netlist.f file is a compilation of .v and .sv file paths, extracted by the script without requiring manual searching. These files are all stored in the rtl folder. The script automatically identifies files by their file extensions (.f, .v, .sv, .sdf, etc.). After identifying the file_list.f file, it analyzes the source file paths of all modulesA using the keyword "\dig\", replaces these paths with the file paths of the post-simulation netlist, and generates a new file_list_netlist.f file. The contents of this file are then compiled during post-simulation.

[0031] Step S104: Generate SDF back-annotation commands based on the basic file structure, and distinguish the SDF back-annotation commands through macro definitions to obtain back-annotation files.

[0032] In this embodiment, the correct SDF back-annotation commands are automatically generated by combining the hierarchical structure information obtained in the first step. A series of macro definitions are obtained by extracting the corner information from the SDF file name. The back-annotated SDF commands are then distinguished one by one through macro definitions. In this way, during the subsequent simulation, the corresponding macros can be defined through the command parameters of the Makefile to realize SDF back-annotation and simulation for different corners.

[0033] Step S105: Update the back-annotation content of the testbench file using the keyword sdf_annotate and the back-annotation file.

[0034] In one possible implementation, the annotated content of the testbench file is updated using the keyword `sdf_annotate` and the annotated file itself. Specifically: Use the keyword `sdf_annotate` to determine if there are any annotated contents in the testbench; If no anti-annotation content exists, the anti-annotation file will be added automatically. If back-annotation content exists, extract the back-annotation hierarchy of moduleA in the back-annotation file based on the characteristics of the function $sdf_annotate; When the original and new anti-annotation hierarchies are inconsistent, the original anti-annotation content will be updated to the latest anti-annotation content.

[0035] In this embodiment, the keyword `sdf_annotate` is used to determine if there is any back-annotation content in the testbench. If not, the back-annotation file mentioned in point 4 is automatically added; if a back-annotation file already exists, the hierarchical structure of `moduleA` in the back-annotation file is extracted based on the characteristics of the function `$sdf_annotate`. If it is inconsistent with the new back-annotation hierarchy, the original back-annotation information is updated with the latest back-annotation content.

[0036] Specifically, the back-annotation file, generally called the SDF timing back-annotation file, is a file provided by the digital back-end engineer and usually has the .sdf extension. This file is divided into many files depending on the technology corner, which is also the source of the corner_name folder name. During post-simulation verification, the timing information from each file is back-annotated onto the post-simulation netlist for post-simulation. This file is stored in the attached... Figure 2 It is located in the modelA / sdf / path.

[0037] Specifically, the Testbench typically doesn't contain any back-annotation content, meaning the back-annotation function `$sdf_annotate` isn't called. The script determines whether the back-annotation function is used by capturing the presence or absence of the keyword `sdf_annotate`. Since this might be a second environment setup, and the first setup already generated a testbench calling `$sdf_annotate`, the second setup needs to check if the previously called function is correct. This is because calling this function requires clearly specifying the hierarchical structure of the back-annotated files, specifically the hierarchy of `moduleA`.

[0038] Step S106: Access the Makefile file through the script to be executed, extract the case information, and combine it with the information already extracted above to generate the rear imitation folder vcs_end.

[0039] In one possible implementation, the post-implementation folder vcs_end includes a makefile and multiple case folders, each containing multiple corner folders.

[0040] In this embodiment, after the above steps are completed, the script will also access the Makefile to extract case information. Then, combined with the information already extracted, it generates the post-simulation folder `vcs_end`. This folder will contain a Makefile and multiple case folders. Each case folder will further contain multiple corner folders (information obtained from extracting the SDF file names, consistent with macro definition information), all used for executing simulations and storing simulation results. The generated Makefile contains the following parts to implement multi-threaded parallel simulation: 1. The Makefile directly copies the Makefile used in the previous simulation and adds new commands and pseudo-targets. 2. It generates the variable `corner_list`, separating all corner information with spaces and assigning values. 3. It generates the variable `corner_define`, whose content mainly includes relevant macro definition information, and also nests the variables `corner_name` and `case_name`. 4. It defines the variable `dir_name`, whose content is a combination of the variables `case_name` and `corner_name`. 5. Generate the pseudo-target `run_back`, which mainly contains the commands and parameters required for post-simulation by the simulation tool. It also embeds the variables `dir_name` and `corner_define`, which facilitate parameter passing during parallel simulation. The file path is accessed by reading the `file_list_netlisg.f` file. 6. Generate the pseudo-target `com_all`. It iterates through the variable `corner_list` using a `foreach` loop, passing parameters to the variable `x`. Then, it creates a background subshell using the command `bash -c`, executing the pseudo-target `run_back` within the subshell and passing `x` as a parameter to the variable `corner_name`. 7. Generate the pseudo-target `run_all`. Iterates through the variable `corner_list` using a `foreach` loop, passing parameters to the variable `x`. Then, it creates a background subshell using the command `bash -c`, executing `cd . / $(case_name) / $x` within the subshell, and then executes the simulation. 8. Generate the pseudo-target case0_all, under which the pseudo-targets com_all and run_all are executed. When executing com_all, the parameters required by the variables case_num and case_name need to be passed. The parameters passed to case_num are mainly macro definitions, which can change the simulation case. The parameters passed to case_name are the name of this case, which is the parameter needed to find the path. 9. In the same way, generate case1, 2, 3_all respectively. 10. Generate the pseudo-target all: its content is to execute the pseudo-target caseN_all, where N=0, 1, 2…11. Generate a pseudo-target `clean_a` to clean up files. During subsequent simulations, execute the `make all` command. Simulations for all corners under case 0 will begin. After the simulation ends, automatically simulate all corners under case 1 until the simulation concludes.

[0041] Step S107: Perform simulation based on the post-simulation folder, parse the simulation results and generate a simulation report.

[0042] In one possible implementation, simulation is performed based on the post-simulation folder, the simulation results are parsed, and a simulation report is generated, specifically as follows: The `make all` command is executed on the simulated folder, and multiple corner folders under each case folder are automatically simulated. Generate a makefile in each case folder, and generate a pseudo-target log based on the makefile in the case folder; Use the egrep command to extract the simulation results of each corner file into a result file to obtain the result content; The simulation results are analyzed based on the result content, and a simulation report is generated.

[0043] In this embodiment, a makefile is generated in each case_name folder. Its main content is to generate a pseudo target log and use the egrep command to quickly extract the simulation result information of all corners to the result file. The simulation status such as whether the SDF back-annotation was successful, whether there are warning messages, and whether there are timing violations can be quickly checked based on the content of the result.

[0044] Specifically, the makefile and corner_name are in the same folder, which integrates the relevant commands for the target log. It can extract the contents of all simulation reports under corner_name and generate a total result file, in which you can quickly check the contents you want to check.

[0045] Specifically, all simulation log information is placed in the case_name / corner_name folder. The makefile in the case_name folder contains commands to extract all simulation log information, which can extract important information from the simulation report and store it in the result file.

[0046] Based on the above solution, this application has the following advantages: 1. Provides a one-click automated setup solution for post-simulation environments, reducing manual intervention, avoiding manual errors, and improving work efficiency.

[0047] 2. Through keyboard shortcuts and a human-computer interaction-based script design, scripts can be executed quickly from any path.

[0048] 3. Through modular and parameterized script design, rapid adaptation and reuse of different projects and simulation configurations can be achieved.

[0049] 4. Integrate intelligent error checking and reporting mechanisms to detect problems such as configuration errors, missing files, and SDF back-annotation path errors in the early stages of the simulation process, thereby improving the reliability of the simulation process.

[0050] 5. Generate execution commands that can be simulated in parallel. By generating a Makefile, execution commands for multiple corners can be simulated simultaneously, making full use of the server's multi-threaded performance to achieve the goal of fast simulation.

[0051] 6. Generate standardized simulation reports and logs to facilitate result traceability and problem localization, and quickly complete the inspection of simulation results.

[0052] In summary, this invention proposes a rapid method for building a digital chip post-simulation environment. The method includes: constructing a basic file structure and determining its directory tree; placing the script to be executed in a fixed directory of the basic file structure, creating a shortcut key for the script, and determining the hierarchical structure of the `moduleA` folder within the basic file structure; searching for relevant files in the directory tree using the script to be executed and generating a `file_list_netlist.f` file; generating SDF back-annotation commands based on the basic file structure and differentiating these commands using macro definitions to obtain back-annotation files; updating the back-annotation content of the `testbench` file using the keyword `sdf_annotate` and the back-annotation files; accessing the `makefile` file using the script to be executed, extracting case information, and combining this extracted information to generate a post-simulation folder `vcs_end`; performing simulation based on the post-simulation folder, parsing the simulation results, and generating a simulation report. This achieves one-click automated construction of the post-simulation environment, improving the efficiency and accuracy of the post-simulation process.

[0053] This application also proposes a method for rapidly building a digital chip post-simulation environment and simulation device, such as... Figure 3 As shown, the device includes: A building module is used to construct the basic file structure and determine the directory tree of the basic file structure; The module is defined to place the script to be executed into a fixed directory of the basic file structure, create a shortcut key for the script to be executed, and determine the hierarchical structure of the moduleA folder in the basic file structure. The first generation module is used to search for relevant files in the directory tree using the script to be executed, and generate the file_list_netlist.f file; The back-annotation module is used to generate SDF back-annotation commands based on the basic file structure, and to distinguish the SDF back-annotation commands through macro definitions to obtain back-annotation files; The update module is used to update the back-annotation content of the testbench file using the keyword sdf_annotate and the back-annotation file; The second generation module is used to access the Makefile file through the script to be executed, extract case information, and combine it with the information already extracted above to generate the folder vcs_end. The parsing module is used to perform simulation based on the post-simulation folder, parse the simulation results, and generate a simulation report.

[0054] Figure 4 A structural block diagram of a computing device 400 according to one embodiment of this specification is shown. The components of the computing device 400 include, but are not limited to, a memory 410 and a processor 420. The processor 420 is connected to the memory 410 via a bus 430, and a database 450 is used to store data.

[0055] The computing device 400 also includes an access device 440, which enables the computing device 400 to communicate via one or more networks 460. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 440 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0056] In one embodiment of this specification, the aforementioned components of the computing device 400 and Figure 4 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 4 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0057] The computing device 400 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 400 can also be a mobile or stationary server.

[0058] The processor 420 executes the following computer-executable instructions, which, when executed by the processor, implement the steps of the aforementioned rapid digital chip simulation environment and simulation method. The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the aforementioned rapid digital chip simulation environment and simulation method belong to the same concept. Details not described in detail in the technical solution of the computing device can be found in the description of the aforementioned technical solution of the rapid digital chip simulation environment and simulation method.

[0059] An embodiment of this specification also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the above-described rapid digital chip post-simulation environment and simulation method.

[0060] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium belongs to the same concept as the technical solution of the above-described rapid digital chip simulation environment and simulation method. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the above-described rapid digital chip simulation environment and simulation method.

[0061] An embodiment of this specification also provides a computer program, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the above-described rapid construction of a digital chip post-simulation environment and simulation method.

[0062] The above is an illustrative scheme of a computer program according to this embodiment. It should be noted that the technical solution of this computer program belongs to the same concept as the technical solution of the above-described rapid digital chip simulation environment and simulation method. For details not described in detail in the technical solution of the computer program, please refer to the description of the technical solution of the above-described rapid digital chip simulation environment and simulation method.

[0063] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0064] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added to or subtracted according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0065] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0066] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0067] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A method for rapidly building a digital chip simulation environment, characterized in that, The method includes: Construct a basic file structure and determine the directory tree of the basic file structure; Place the script to be executed into the above, create a shortcut key for the script to be executed, and determine the hierarchical structure of the moduleA folder in the basic file structure; The script to be executed searches for relevant files in the directory tree and generates the file_list_netlist.f file; The SDF back-annotation commands are then distinguished using macro definitions to obtain the back-annotation file; Update the annotated content of the testbench file using the keyword sdf_annotate and the annotated file; Extract the case information and combine it with the information already extracted above to generate the simulated folder vcs_end; Simulation is performed based on the simulated folder, the simulation results are analyzed, and a simulation report is generated. Specifically, the basic file structure is a project folder, which includes rtl files and vcs files. The rtl files include test files, the vcs files include makefile files, and the test files include testbench files.

2. The method according to claim 1, characterized in that, The RTL file also includes the ANA file, DIG file, FList file, StandCell file, and ModuleA file.

3. The method according to claim 1, characterized in that, The script to be executed is placed in the above-mentioned structure, a shortcut key for the script to be executed is created, and the hierarchical structure of the moduleA folder in the basic file structure is determined, specifically as follows: Place the script to be executed in the fixed directory, and create a shortcut key for the script to be executed by setting the cshrc file; Execute the script to be executed in the project folder using the shortcut key, and enter the name of the module to be verified later; The name of the module that needs to be verified in the post-simulation process is compared with the name of the moduleA folder to ensure that the name of the module that needs to be verified in the post-simulation process matches the name of the moduleA folder. Based on the script to be executed, the contents of all files are traversed through the file paths in the file_list.f file, and the hierarchical structure of the moduleA folder in the basic file structure is determined by combining the name of the moduleA folder.

4. The method according to claim 3, characterized in that, The script to be executed searches for relevant files in the directory tree and generates the file_list_netlist.f file, specifically as follows: The file_list.f file is identified by the file extension of the relevant files; The source file paths of all moduleA files are obtained by identifying keywords, and these source file paths are replaced with the file paths of the subsequent netlist, while a new file file file_list_netlist.f is generated.

5. The method according to claim 4, characterized in that, Update the annotated content of the testbench file using the keyword `sdf_annotate` and the annotated file itself, specifically as follows: Use the keyword `sdf_annotate` to determine if there are any annotated contents in the testbench; If no anti-annotation content exists, the anti-annotation file will be added automatically. If back-annotation content exists, extract the back-annotation hierarchy of moduleA in the back-annotation file based on the characteristics of the function $sdf_annotate; When the original and new anti-annotation hierarchies are inconsistent, the original anti-annotation content will be updated to the latest anti-annotation content.

6. The method according to claim 5, characterized in that, The post-simulation folder vcs_end includes a makefile and multiple case folders, each containing multiple corner folders.

7. The method according to claim 1, characterized in that, The simulation is performed based on the aforementioned simulated folder. The simulation results are analyzed and a simulation report is generated, specifically as follows: The `make all` command is executed on the simulated folder, and multiple corner folders under each case folder are automatically simulated. Generate a makefile in each case folder, and generate a pseudo-target log based on the makefile in the case folder; Use the egrep command to extract the simulation results of each corner file into a result file to obtain the result content; The simulation results are analyzed based on the result content, and a simulation report is generated.

8. A simulation environment and device for rapidly building a digital chip, characterized in that, The device includes: A building module is used to construct the basic file structure and determine the directory tree of the basic file structure; The module is defined to place the script to be executed into it, create a shortcut key for the script to be executed, and determine the hierarchical structure of the moduleA folder in the basic file structure. The first generation module is used to search for relevant files in the directory tree using the script to be executed, and generate the file_list_netlist.f file; The anti-annotation module is used to distinguish the SDF anti-annotation commands through macro definitions and obtain anti-annotation files; The update module is used to update the back-annotation content of the testbench file using the keyword sdf_annotate and the back-annotation file; The second generation module is used to access the Makefile file through the script to be executed, extract case information, and combine it with the information already extracted above to generate the folder vcs_end. The parsing module is used to perform simulation based on the post-simulation folder, parse the simulation results, and generate a simulation report; Specifically, the basic file structure is a project folder, which includes rtl files and vcs files. The rtl files include test files, the vcs files include makefile files, and the test files include testbench files.

9. A computing device, characterized in that, include: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions. When the computer-executable instructions are executed by the processor, they implement the steps of the rapid construction of digital chip post-simulation environment and simulation method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores computer-executable instructions, which, when executed by a processor, implement the steps of rapidly building a digital chip post-simulation environment and simulation method as described in any one of claims 1 to 7.

Images