Netlist export method, server and storage medium for device functional simulation

Abstract

The present disclosure provides a netlist export method, server, and storage medium for device functional simulation. The netlist export method includes: confirming the netlist content and format to be exported for a target device model during functional simulation based on a spice model; defining a simulation function for the netlist and a CDF file for the target device model based on the confirmed information in the spice model; traversing the CDF file using the simulation function for the netlist, reading information about the netlist definition during simulation, and generating and exporting a netlist file based on the read information. This method allows for rapid and accurate definition and modification of the device model's netlist file, facilitating simulation, thereby accelerating project progress and improving work efficiency.

Description

Technical Field

[0001] The present disclosure relates to the technical field of integrated circuits, and in particular to a netlist exporting method, a server, and a storage medium for device functional simulation. Background Art

[0002] Integrated circuit (IC) layouts are an essential link between the circuit system and IC manufacturing processes. Layout design is a physical implementation step, a crucial transition from symbolic circuit diagrams to actual physical layers. Through IC layout design, a three-dimensional circuit system can be transformed into a two-dimensional graphic, which can then be restored to a three-dimensional silicon-based structure through processing.

[0003] As microelectronics manufacturing technology advances toward deep submicron technology, the integration of digital integrated circuits is increasing. This can introduce various failures into semiconductor processes. Furthermore, material defects and process variations can lead to problems such as short circuits, open circuits, and device junction punch-through in chip circuit connections. Such physical failures inevitably lead to functional or performance issues in the circuits. To ensure design accuracy, chips must be tested during manufacturing and use. Currently, the most effective approach is to employ Design for Testability (DFT) techniques, ensuring circuit testability during design.

[0004] Testing digital logic circuits involves both functional and structural testing. Functional testing verifies the module's common functions within the system and checks its interface connectivity with the system. However, due to the module's complexity, exhaustively testing all functions within a limited timeframe is often impossible. Structural testing comprehensively tests the internal circuit structure to ensure the correct functionality of the circuit. Structural testing first requires modeling the circuit's physical defects, establishing a fault model, and generating test stimuli. The test stimuli are then introduced from the original input to the fault point, and the test response from the fault point is propagated to the circuit's original output. Finally, the test response is compared with the normal response to determine if the circuit is faulty. The basic testing strategy involves using a traversal approach to test the connectivity between the pins of multiple integrated circuits on a development board. Once connectivity is confirmed, the test stimuli are introduced to determine if the circuit has the corresponding output response. The key element in this process is to extract the pin connections of the integrated circuits under test by parsing the development board's netlist file.

[0005] Verifying the logical functionality of an entire device chip or circuit requires extensive verification. However, the larger the circuit, the larger the netlist file, which can reach up to 700MB. Using simulation tools based on Candence's NCVerilog and Synosys's VCS, functional simulations of large circuits can take up to a week. If errors are discovered, re-verification takes the same amount of time. Furthermore, this consumes significant server resources. Therefore, a method for obtaining an optimal netlist is needed that conserves simulation resources while increasing simulator speed and verification efficiency. Summary of the Invention

[0006] In order to solve the above technical problems, the present disclosure provides a netlist export method, a server and a storage medium for device functional simulation.

[0007] In one aspect, the present disclosure provides a netlist export method for device functional simulation, comprising:

[0008] Confirm the netlist content and format that needs to be exported in functional simulation based on the spice model;

[0009] Define the simulation function of the aforementioned netlist and the CDF file of the target device model according to the confirmation information in the spice model;

[0010] The CDF file is traversed using the simulation function of the aforementioned netlist, the information about the netlist definition in the simulation is read, and the netlist file is generated and exported according to the classification of the read information.

[0011] Preferably, the aforementioned netlist content and format include:

[0012] The type and name of the target device, the name of the target device model and its parameters displayed on the schematic diagram, the parameter information back-annotated after simulation, and the correspondence between the stimulus and response of the target device model under the process design specifications.

[0013] Preferably, the step of defining the simulation function of the netlist and the CDF file of the target device model according to the confirmation information in the spice model includes:

[0014] Classifying the various parameters of the target device model and the port information of the target device model, and naming and marking each classification;

[0015] Setting corresponding connection interfaces for the ports of the target device model, and storing the marking information and interface setting information in the CDF file of the target device model;

[0016] The simulation function of the netlist is defined according to the aforementioned netlist content and interface setting information.

[0017] Preferably, the aforementioned simulation function for defining the netlist includes: defining the combination description format parameters and parameter call relationship function of the aforementioned target device model.

[0018] Preferably, the steps of traversing the CDF file using the simulation function of the netlist, reading information about the netlist definition in the simulation, generating a netlist file based on the read information and exporting it include:

[0019] Traversing the CDF file of the target device model through the simulation function of the defined netlist, and performing cross-validation of parameter transformation on the developed parameter unit using the interface setting information stored therein;

[0020] Generate a netlist file based on the verification result classification and export it.

[0021] Preferably, the aforementioned netlist export method further includes:

[0022] During subsequent modification iterations of the device functional simulation, the content of the netlist file can be updated by modifying and testing the interface classification information and setting information in the aforementioned CDF file.

[0023] Preferably, the aforementioned netlist export method further includes:

[0024] During the functional simulation of the current target device model, historical data is traversed to confirm whether a defined device format exists. If a defined device format exists, the defined device format is called and the CDF file of the device model is redefined.

[0025] On the other hand, the present disclosure further provides a server, comprising:

[0026] processor;

[0027] a memory for storing one or more programs;

[0028] When the aforementioned one or more programs are executed by the aforementioned processor, the processor implements the aforementioned netlist export method for device functional simulation.

[0029] On the other hand, the present disclosure further provides a computer-readable storage medium having a computer program stored thereon, wherein when the program is executed by a processor, the netlist exporting method for device functional simulation as described above is implemented.

[0030] The beneficial effects of the present disclosure are as follows: the present disclosure provides a netlist export method, server, and storage medium for device functional simulation, wherein the netlist export method includes: confirming the netlist content and format to be exported for a target device model in functional simulation based on a spice model; defining a simulation function for the netlist and a CDF file for the target device model based on the confirmed information in the spice model; traversing the CDF file using the simulation function for the netlist, reading information about the netlist definition in simulation, and generating and exporting a netlist file based on the read information. This method allows for quick and accurate definition and modification of the device model's netlist file, facilitating simulation, thereby accelerating project progress and improving work efficiency.

[0031] At the same time, this netlist export method is also beneficial for utilizing the netlist file content in the subsequent device simulation modification iteration, and making rapid modifications and tests on the interface classification information and interface setting information in the CDF, thereby improving the efficiency of verification and modification detection. When the simulation netlist format of other devices is the same as the format of the previously defined device, only the CDF file of the device needs to be redefined, further improving the efficiency of batch simulation verification and saving simulation resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] The above and other objects, features and advantages of the present disclosure will become more apparent through the following description of the embodiments of the present disclosure with reference to the accompanying drawings.

[0033] Figure 1 A schematic diagram illustrating a flow chart of a netlist export method for device functional simulation provided in the first embodiment of the present disclosure is shown;

[0034] Figure 2 Show Figure 1 Schematic diagram of the sub-steps of step S120 in the netlist export method;

[0035] Figure 3 A schematic diagram of the structure of a server provided in the second embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0036] To facilitate understanding of the present disclosure, a more comprehensive description of the present disclosure will be provided below with reference to the accompanying drawings. The accompanying drawings illustrate preferred embodiments of the present disclosure. However, the present disclosure may be implemented in various forms and is not limited to the embodiments described herein. Rather, these embodiments are provided to facilitate a more thorough and comprehensive understanding of the present disclosure.

[0037] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art in the art of the present disclosure. The terms used in the specification of the present disclosure are only for the purpose of describing specific embodiments and are not intended to limit the present disclosure.

[0038] With the advancement of integrated circuit technology, chip feature sizes are shrinking, the integration density of individual chips is increasing, and the structures and processes are becoming increasingly complex, leading to an exponential increase in the size of layout databases. As the layout size expands, the number of design rules that need to be verified at each stage of integrated circuit design continues to increase. Among these, design rule checking (DRC) for integrated circuit layouts and layout versus schematics (LVS) consistency checking for integrated circuit layouts are becoming increasingly important, playing a vital role in reducing design errors, lowering design costs, and relieving the risk of design failure. In the design of very large-scale integrated circuits (VLSIs), the layout size is rapidly expanding, and how to quickly locate problems within the layout has become another challenge facing integrated circuit design.

[0039] According to the syntax of the EDA tool, develop the corresponding verification files (DRC, LVS, RCX runset) and cross-validate the developed Pcell. Among them, the DRC verification file includes: run setting selection control options, process layer processing commands (used to generate the layers to be applied in the rule file, including original layers and derived layers), and the logic definition commands of each process rule (the width of each process layer, the spacing of the same layer and different layers, and the inclusion relationship of different layers, etc.); the LVS verification file includes: the definition of the process original layer, identification layer, device port layer and the connection relationship of each layer, the definition of device extraction in the layout, and the rules for device size measurement to ensure consistency in circuit schematic design and layout design; the RCX file includes: corresponding process parameters (metal thickness, square resistance value of the metal layer, thickness of the dielectric layer, dielectric constant of the dielectric layer, etc.), process effect coefficients (such as line width increase effect, temperature coefficient, etc.), and lookup tables for process parasitic resistance and capacitance parameters.

[0040] The parameters used in device simulation can be automatically generated into a corresponding netlist through CDF parameter settings, thus simplifying the simulation verification process. In addition, the layout can well inherit the connection relationships and parameter settings of the circuit schematic design, avoiding the problem of inconsistency between layout and schematic inspection during later verification, which makes it difficult to locate errors.

[0041] However, a large amount of verification work must be done to verify the correctness of the logical functions of the entire device chip or circuit chip. As the scale of the circuit increases, the data in the netlist file becomes more complex and the data volume is also very large. When using simulation tools to run functional simulations of large-capacity circuits, the verification time is long. After errors are found, re-verification takes the same amount of time and occupies a large amount of server resources. This is very disadvantageous in actual production applications.

[0042] Based on this, the present disclosure provides a method for obtaining an optimal netlist, which not only saves simulation resources but also increases the running speed of the simulator, thereby improving verification efficiency.

[0043] Explanation of terms:

[0044] CDF: The full name is Component Description Format, which is translated as component description file format. In this article, CDF file refers to the device attribute description file, which defines the device type, device name, device parameters and parameter call relationship function set, device model, various device view formats, etc.

[0045] Spice model: The full name is Simulation program with integrated circuit emphasis model, which is translated as general analog circuit simulator model. It is a file provided by the foundry. Like the C simulation netlist, it is used for device simulation. The Spice model generally has the following requirements for the content in the simulation netlist: such as device name (instance name), device model name (model name), CDF parameter name and format, parameter value format, parameter arrangement order, and port arrangement and format, etc.

[0046] PDK (Process Design Kit) serves as a bridge between IC design companies, foundries, and EDA vendors. It contains essential elements of the manufacturing process: transistors, contact holes, interconnects, and more. PDK content includes design rule files, electrical rule files, layout definition files, SPICE simulation models, device layouts, and custom process parameters.

[0047] Hereinafter, the present disclosure will be described in detail with reference to the accompanying drawings.

[0048] Example 1:

[0049] Figure 1 A schematic diagram showing a flow chart of a netlist export method for device functional simulation provided in the first embodiment of the present disclosure is shown. Figure 2 Show Figure 1FIG. 1 is a flow chart of sub-steps of step S120 in the netlist exporting method.

[0050] refer to Figure 1 and Figure 2 In a first embodiment of the present disclosure, a netlist export method for device function simulation is proposed based on an electronic design automation (EDA) tool. The method can be applied in integrated circuit design and liquid crystal panel design. The simulation netlist is quickly and accurately exported using the EDA tool. In this embodiment, the netlist export method includes:

[0051] Step S110: confirming the netlist content and format that needs to be exported from the target device model in functional simulation according to the spice model.

[0052] As can be seen, constructing a device model based on the component's electrical operating characteristics allows the component to be treated as a "black box," measuring the electrical characteristics of its ports to extract the device model without considering the device's operating principle. This approach offers advantages in ease of modeling and use, resource conservation, and wide applicability. Behavioral-level models are particularly suitable for high-frequency, nonlinear, and high-power applications, where behavioral-level models are virtually the only choice. However, their disadvantages include poor accuracy and lack of consistency, influenced by test technology and accuracy. Constructing a device model based on the component's operating principle, starting from the component's mathematical equations, results in a device model and model parameters that are closely related to the device's physical operating principle. SPICE models are the most widely used of this type, offering the advantage of high accuracy. In practical applications, the analytical accuracy of SPICE models depends primarily on the accuracy of the data used to generate the model parameters, as well as the applicable scope of the model equations.

[0053] In step S110 of this embodiment, a target device model is first established based on the acquired target device, and the netlist content and format to be exported are determined in the functional simulation of the target device model. The netlist content and format may include, for example: the type and name of the target device, the name of the target device model and the parameters displayed on the schematic diagram, the parameter information back-annotated after simulation, and the correspondence between the stimulus and response of the target device model under the process design specification.

[0054] Preferably, before implementing step S110, this embodiment may further include the following steps: designing a combination device of at least one specification (combination devices of different width (W) / length (L)) and using it to test the TFT characteristics of the device. During the test, an accurate analog simulation model of the combination device is extracted. In this step, the device test layout can first be designed according to process rules and customer requirements. During the tape-out process, the parameters are segmented to obtain different process angles. After tape-out, IV, CV tests, high and low temperature tests, etc. are performed on the devices at different positions on the wafer. Finally, the raw test data is imported into the model extraction software, and the basic processing information is input. The software completes the parameter extraction and outputs the spice model. A model that satisfies the accurate simulation of devices with different width / length ratios in the integrated circuit design is extracted.

[0055] Step S120: defining the simulation function of the aforementioned netlist and the CDF file of the target device model according to the confirmation information in the spice model.

[0056] To ensure the correctness of the design, chips must be tested during manufacturing and use. Currently, the most effective approach is to employ Design for Testability (DFT), which ensures the testability of the circuit during design. Existing functional testing employs a traversal approach to detect the connectivity between the different pins of multiple integrated devices on a development board. Once connectivity is ensured, test stimuli are introduced to determine whether the circuit has a corresponding response output. The most critical element is extracting the pin connections of the integrated device to be tested by parsing the development board netlist file. This allows the data in the cadence netlist file to be read line by line, and then semantically parsed for each line of data.

[0057] In step S120, the following sub-steps may be specifically included:

[0058] Sub-step S121: Classify the various parameters of the target device model and the port information of the target device model, and name and mark each classification.

[0059] Sub-step S122: setting corresponding connection interfaces for the ports of the target device model, and storing the marking information and the interface setting information in the CDF file of the target device model.

[0060] Sub-step S123: defining the simulation function of the netlist according to the aforementioned netlist content and interface setting information.

[0061] The aforementioned simulation function for defining the netlist includes: defining the combination description format parameters and parameter call relationship function of the aforementioned target device model.

[0062] Step S130: traverse the CDF file using the simulation function of the aforementioned netlist, read the information about the netlist definition in the simulation, generate a netlist file based on the classification of the read information, and export it.

[0063] Specifically, in step S130, the CDF file of the target device model is traversed by the simulation function of the defined netlist, and the interface setting information stored therein is used to perform cross-validation of parameter transformation on the developed parameter unit; and

[0064] Generate a netlist file based on the verification result classification and export it.

[0065] Preferably, the aforementioned netlist exporting method may further include: classifying and marking the exported netlist file according to the device type and storing the same.

[0066] Preferably, in other alternative implementations of this embodiment, the aforementioned netlist exporting method may further include:

[0067] During subsequent modification iterations of the functional simulation of the target device model, the content of the netlist file can be updated by modifying and testing the interface classification information and setting information in the aforementioned CDF file.

[0068] Preferably, in other alternative implementations of this embodiment, the aforementioned netlist exporting method may further include:

[0069] During the functional simulation of the current target device model, historical data is traversed to confirm whether a defined device format exists. If a defined device format exists, the defined device format is called and the CDF file of the device model is redefined.

[0070] In this way, when it is determined that the type of the device model currently being tested is a device simulation netlist format that has been defined, it can be directly called for modification and detection without having to repeat the above-mentioned establishment process, effectively improving the work efficiency of the same type of devices in batch production testing.

[0071] A netlist export method for device functional simulation provided in a first embodiment of the present disclosure can quickly and accurately define and modify the netlist file of the device model to facilitate simulation, thereby accelerating project progress and improving work efficiency.

[0072] At the same time, this netlist export method is also beneficial for utilizing the netlist file content in the subsequent device simulation modification iteration, and making rapid modifications and tests on the interface classification information and interface setting information in the CDF, thereby improving the efficiency of verification and modification detection. When the simulation netlist format of other devices is the same as the format of the previously defined device, only the CDF file of the device needs to be redefined, further improving the efficiency of batch simulation verification and saving simulation resources.

[0073] Example 2:

[0074] Figure 3 A schematic diagram of the structure of a server provided in the second embodiment of the present disclosure is shown.

[0075] refer to Figure 3 , the present disclosure also proposes a block diagram of an exemplary server suitable for implementing the first embodiment of the present disclosure. It should be understood that, Figure 3 The server shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0076] like Figure 3 As shown, the server 200 is a general-purpose computing device. Components of the server 200 may include, but are not limited to, one or more processors or processing units 210, a memory 220, and a bus 201 connecting various system components (including the memory 220 and the processing unit 210).

[0077] Bus 201 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor, or a local bus using any of a variety of bus architectures. Examples of these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0078] The server 200 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by the server 200, including volatile and non-volatile media, removable and non-removable media.

[0079] System memory 220 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 221 and / or cache memory 222. Server 200 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 223 may be used to read and write non-removable, non-volatile magnetic media ( Figure 3Not shown, often called a "hard drive"). Although Figure 3 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk"), and an optical drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 201 via one or more data medium interfaces. Memory 220 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of each embodiment of the present disclosure.

[0080] A program / utility 224 having a set (at least one) of program modules 2241 may be stored, for example, in memory 220. Such program modules 2241 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may include an implementation of a network environment. Program modules 2241 generally implement the functions and / or methods described in the embodiments of the present disclosure.

[0081] Furthermore, the server 200 may also be in communication with a display 300 for displaying the netlist derived results from the device functional simulation. The display 300 may include, but is not limited to, a liquid crystal display (LCD), a light emitting diode (LED) display, and a plasma display. In some embodiments, the display 300 may also be a display screen with an input device or a touch screen.

[0082] Furthermore, the server 200 may also communicate with one or more devices that enable users to interact with the server 200, and / or with any device that enables the server 200 to communicate with one or more other computing devices (e.g., a network card, a modem, etc.). Such communication may be performed via an input / output (I / O) interface 230. Furthermore, the server 200 may also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) via a network adapter 240. As shown, the network adapter 240 communicates with other modules of the server 200 via a bus 201. It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with the server 200, including but not limited to microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0083] The processing unit 210 executes various functional applications and data processing by running programs stored in the system memory 220, such as implementing the netlist export method for device functional simulation provided in the first embodiment of the present disclosure.

[0084] Example 3

[0085] The third embodiment of the present disclosure further provides a computer-readable storage medium having a computer program (or computer-executable instructions) stored thereon. When the program is executed by a processor, the program is used to execute the netlist export method for device functional simulation provided in the first embodiment of the present disclosure. The method includes:

[0086] Confirm the netlist content and format that needs to be exported in functional simulation based on the spice model;

[0087] Define the simulation function of the aforementioned netlist and the CDF file of the target device model according to the confirmation information in the spice model;

[0088] The CDF file is traversed using the simulation function of the aforementioned netlist, the information about the netlist definition in the simulation is read, and the netlist file is generated and exported according to the classification of the read information.

[0089] The computer storage medium of the embodiment of the present disclosure may adopt any combination of one or more computer-readable media. The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or component, or any combination thereof. More specific examples (non-exhaustive list) of computer-readable storage media include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the embodiment of the present disclosure, the computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by an instruction execution system, device or device or used in combination with it.

[0090] A computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0091] The program code included in the computer-readable medium can be transmitted with any appropriate medium, including but not limited to wireless, electric wire, optical cable, RF, etc., or any suitable combination thereof. The computer program code for performing the operation of the disclosed embodiment can be written in one or more programming languages ​​or a combination thereof, and the aforementioned programming languages ​​include object-oriented programming languages ​​(such as Java, Smalltalk, C++), and also include conventional procedural programming languages ​​such as "C" language or similar programming languages. The program code can be executed completely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on the remote computer, or executed completely on the remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer by any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (such as using an Internet service provider to connect to the Internet).

[0092] It should be noted that in the description of the present disclosure, it needs to be understood that the terms "upper", "lower", "inner", etc., which indicate orientation or positional relationships, are only for the convenience of describing the present disclosure and simplifying the description, and do not indicate or imply that the components or elements referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on the present disclosure.

[0093] In addition, as used herein, the terms "comprises," "comprising," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not preclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0094] Finally, it should be noted that the above embodiments are merely examples for the purpose of illustrating the present disclosure and are not intended to limit the embodiments. Those skilled in the art will readily appreciate that other variations or modifications based on the above descriptions are possible. It is not necessary and impossible to provide an exhaustive list of all embodiments. Obvious variations or modifications arising therefrom remain within the scope of protection of the present disclosure.

Claims

1. A netlist export method for device functional simulation, wherein: include: Confirm the netlist content and format that needs to be exported in functional simulation based on the spice model; Define the simulation function of the netlist and the CDF file of the target device model according to the confirmation information in the spice model; Using the simulation function of the netlist to traverse the CDF file, read the information about the netlist definition in the simulation, generate a netlist file based on the read information and export it, In the subsequent modification and iteration of the functional simulation of the device, the content of the netlist file can be updated by modifying and detecting the interface classification information and setting information in the CDF file.

2. The netlist exporting method according to claim 1, wherein: The netlist content and format include: The type and name of the target device, the name of the target device model and the parameters displayed on the schematic diagram, the parameter information back-annotated after simulation, and the correspondence between the stimulus and response of the target device model under the process design specification.

3. The netlist exporting method according to claim 2, wherein: The step of defining the simulation function of the netlist and the CDF file of the target device model according to the confirmation information in the spice model includes: Classifying the various parameters of the target device model and the port information of the target device model, and naming and marking each classification; Setting corresponding connection interfaces for the ports of the target device model, and storing the marking information and the interface setting information in a CDF file of the target device model; A simulation function of the netlist is defined according to the netlist content and the interface setting information.

4. The netlist exporting method according to claim 3, wherein: The simulation function for defining the netlist includes defining the combination description format parameters and parameter call relationship function of the target device model.

5. The netlist exporting method according to claim 4, wherein: The steps of traversing the CDF file using the simulation function of the netlist, reading information about the netlist definition in the simulation, generating a netlist file according to the classification of the read information and exporting the netlist file include: Traversing the CDF file of the target device model through the simulation function of the defined netlist, and performing cross-validation of parameter transformation on the developed parameter unit using the interface setting information stored therein; Generate a netlist file based on the verification result classification and export it.

6. The netlist exporting method according to claim 5, wherein: Also includes: During the functional simulation of the current target device model, historical data is traversed to confirm whether a defined device format exists. If a defined device format exists, the defined device format is called and the CDF file of the device model is redefined.

7. A server comprising: processor; a memory for storing one or more programs; When the one or more programs are executed by the processor, the processor implements the netlist exporting method for device functional simulation according to any one of claims 1 to 6.

8. A computer-readable storage medium having a computer program stored thereon, wherein: When the program is executed by a processor, the netlist exporting method for device functional simulation according to any one of claims 1 to 6 is implemented.

Images