Method, device and storage medium for constructing netlist parser

Abstract

The application discloses a method and device for constructing a netlist parser and a storage medium. The method comprises the following steps: obtaining a netlist syntax rule file; constructing a plurality of syntax modules based on the types of netlist statements of the netlist syntax rule file and a preset tree directory structure; constructing a structure configuration file in the syntax module, the structure configuration file being used for defining data structure fields of the netlist statements corresponding to the syntax module, the data structure fields being used for representing the hierarchical organization structure and parameter attributes of the netlist statements corresponding to the syntax module; constructing a syntax rule file in the syntax module, the syntax rule file being used for describing the statement format of the netlist statements corresponding to the syntax module in the netlist syntax rule file; and compiling the netlist parser based on the syntax module and an automatic construction tool under the root directory of the preset tree directory structure. The application has the technical effect of improving the construction efficiency of the netlist parser.

Description

Technical Field

[0001] This disclosure relates to the field of electronic design automation simulation technology, and in particular to a method, apparatus, and storage medium for constructing a netlist resolver. Background Technology

[0002] With the rapid development of integrated circuits, electronic design automation (EDA) tools play a crucial role in the R&D and design process. In electronic circuit design and simulation, circuit data files typically describe circuit components, control statements, and simulation analysis statements in the form of text statements. Existing syntax parsing techniques usually employ centralized syntax files, defining all syntax rules and lexical symbols in a single file. While this approach can achieve netlist parsing of circuit data files, it suffers from problems such as large parser size, complex structure, and difficult maintenance. Especially when it's necessary to extend to new statement types or modify existing rules, the entire parser often needs to be modified, easily leading to consistency issues and errors. Therefore, the construction of netlist parsers deserves attention. Summary of the Invention

[0003] In view of this, embodiments of this application provide a method, apparatus, and storage medium for constructing a netlist parser, aiming to improve the construction efficiency of the netlist parser. A first aspect provides a method for constructing a netlist parser, comprising: obtaining a netlist syntax rule file; dividing the netlist syntax rule file into multiple syntax modules based on the netlist statements and a preset tree directory structure, wherein each syntax module corresponds to a leaf directory of the preset tree directory structure, and the netlist statements include one or more of device statements, control statements, or analysis statements; constructing a structure configuration file in each syntax module, wherein the structure configuration file defines data structure fields for the netlist statements corresponding to the syntax module, and the data structure fields characterize the hierarchical organization structure and parameter attributes of the netlist statements corresponding to the syntax module; constructing a syntax rule file in each syntax module, wherein the syntax rule file describes the statement format of the netlist statements corresponding to the syntax module in the netlist syntax rule file; and compiling and generating a netlist parser in the root directory of the preset tree directory structure based on the syntax modules and an automated construction tool, wherein the netlist parser is used to parse circuit data files, and the circuit data files are determined based on the netlist syntax rule file.

[0004] The above method for constructing a netlist parser can convert netlist statements in the netlist syntax rule file into independent syntax modules, thereby reducing the coupling of syntax rules. Furthermore, organizing syntax modules through a tree-like directory makes the hierarchical relationship of syntax rules more intuitive and easier to extend. By using automated construction tools to uniformly compile and generate netlist parsers, the risks associated with manually modifying the main syntax file are avoided, thus enabling rapid parsing and subsequent processing of circuit data, thereby improving the efficiency and maintainability of netlist file parsing.

[0005] Optionally, based on syntax modules and automated build tools, a netlist parser is compiled and generated, including: reading multiple syntax modules; generating corresponding data structure code based on the structure configuration files of the syntax modules, wherein the data structure code can be represented in one of the following languages: C++, Java, or Python; merging the syntax rule files of the syntax modules into a syntax parsing file; and compiling the data structure code and the syntax parsing file to generate the netlist parser.

[0006] Optionally, the parsing file includes a lexical file and a syntax file. The syntax file is used to define the combination rules of lexical symbols in the netlist syntax rule file to characterize the statement format and hierarchical relationship of the netlist statements. The lexical file is used to define the segmentation rules of character sequences in the netlist syntax rule file to identify the identifiers, values ​​and control keywords of the netlist statements.

[0007] Optionally, the syntax rule file and the syntax parsing file have the same syntax definition format. However, the syntax rule file does not contain the declaration of lexical symbols, which are declared uniformly by the syntax parsing file.

[0008] Optionally, a preset tree-shaped directory structure is used, which is determined based on the device directory division of electronic automated design tools.

[0009] Optionally, the compilation of a netlist parser based on syntax modules and automated build tools further includes: during the incremental build process of generating the netlist parser, the automated build tools detect timestamp changes of multiple syntax modules; when a first timestamp change of the first syntax module is determined, the first syntax module is rebuilt, wherein the reconstruction includes updating the structure configuration file and updating the syntax rule file.

[0010] Optionally, it also includes: when the netlist parser adds a syntax module, using the current syntax module as a syntax template; filling in the structure configuration file and syntax rule file corresponding to the newly added netlist statement in the syntax template to generate a second syntax module; and integrating the second syntax module into the netlist parser through an automated build tool.

[0011] Optionally, it also includes: independently verifying the syntax module based on a module-level unit testing framework, which includes test input files and expected output files, used to compare the parsing results of the syntax module and determine the accuracy of the netlist parser.

[0012] Secondly, a netlist parser construction apparatus is provided, comprising: an acquisition unit for acquiring a netlist syntax rule file; a partitioning unit for partitioning the netlist syntax rule file into multiple syntax modules based on the netlist statements and a preset tree directory structure, wherein the syntax modules correspond to the leaf directories of the preset tree directory structure, and the netlist statements include one or more of device statements, control statements, or analysis statements; a first construction unit for constructing a structure configuration file in the syntax modules, wherein the structure configuration file defines the data structure fields of the netlist statements corresponding to the syntax modules, and the data structure fields characterize the hierarchical organization structure and parameter attributes of the netlist statements corresponding to the syntax modules; a second construction unit for constructing a syntax rule file in the syntax modules, wherein the syntax rule file describes the statement format of the netlist statements corresponding to the syntax modules in the netlist syntax rule file; and a compilation unit for compiling and generating a netlist parser in the root directory of the preset tree directory structure, based on the syntax modules and an automated construction tool, wherein the netlist parser is used to parse circuit data files, and the circuit data files are determined based on the netlist syntax rule file.

[0013] Thirdly, a computer-readable storage medium is provided, comprising: a memory having instructions stored thereon; and a processor configured to implement the method for constructing a netlist resolver provided in the first aspect when reading the instructions in the memory. Attached Figure Description

[0014] The accompanying drawings used in the description of the embodiments of this disclosure are briefly introduced below:

[0015] Figure 1 The diagram illustrates a flowchart of a method for constructing a netlist resolver provided in some embodiments of this application.

[0016] Figure 2 A flowchart illustrating a method for generating a netlist resolver provided in some embodiments of this application is shown.

[0017] Figure 3 A schematic diagram of the structure of a netlist resolver provided in some embodiments of this application is shown.

[0018] Figure 4 A schematic diagram of the structure of a netlist resolver construction apparatus provided in some embodiments of this application is shown. Detailed Implementation

[0019] To more clearly illustrate the technical solutions in the embodiments of this disclosure, examples of implementation methods of this disclosure will be described below with reference to the accompanying drawings. The accompanying drawings described below are merely some embodiments of this disclosure. For those skilled in the art, other drawings and other implementation methods can be obtained based on these drawings without creative effort. Adjustments and improvements made without departing from the concept of this disclosure are all within the protection scope of this disclosure.

[0020] To keep the drawings simple, each figure only schematically shows the parts relevant to the embodiment, and they do not represent the actual structure of the product. In addition, for the sake of clarity and ease of understanding, some figures only schematically show parts of components with the same structure or function, and there may actually be more or fewer components with the same structure or function.

[0021] In this disclosure, unless otherwise expressly specified and limited, ordinal numbers, such as “first”, “second”, etc., are used only to distinguish and describe related objects, and should not be construed as indicating or implying the relative importance or order between related objects; furthermore, they do not represent the quantity of related objects. “Multiple” includes two or more, and other quantifiers are similar. “ / ” is used to describe the relationship between related objects, indicating an “or” relationship between them. “And / or” is used to describe the relationship between related objects, including any combination relationship between them, such as “a and / or b” including: “a alone”, “b alone”, or “a and b”. “One or more” or “at least one” of multiple objects refers to any object or any combination of multiple objects, such as “one or more of a1, a2, a3” or “at least one of a1, a2, a3” including: “a1 alone”, “a2 alone”, “a3 alone”, “a1 and a2”, “a1 and a3”, “a2 and a3”, or “a1, a2 and a3”.

[0022] Circuit data files are a common circuit description method used in electronic design automation (EDA) tools, typically defining circuit structures and simulation settings using text statements. Taking a circuit netlist as an example, it primarily describes the data structure of components and their connections in electronic circuits, and is widely used in chip design, simulation, layout, and back-end verification. Circuit netlists are usually represented in text format, and the statements mainly include component definitions, port / pin descriptions, connection information, hierarchical structure, parameters and constraints, comments, and metadata. Examples include device statements for defining components such as resistors, capacitors, and transistors and their node connections; simulation statements for setting subcircuits, model parameters, and simulation environments; and analysis statements for specifying simulation types such as DC analysis, AC analysis, and transient analysis. In existing technologies, circuit netlist parsing often relies on parsers generated by syntax tools such as flex and bison. These parsers are centralized, monolithic files that centrally declare all lexical symbols and define all syntax rules. While this centralized design approach can meet basic parsing needs, as the scale of the circuit and the types of statements increase, the file size gradually grows, and the coupling between different statement types leads to a continuous increase in the difficulty of maintenance for technical personnel. Furthermore, adding new statement types requires modification to the entire file, which can easily lead to duplicate or conflicting token definitions. Building the parser often requires a full compilation, which is inefficient and cannot quickly respond to local modifications.

[0023] To effectively parse circuit netlists, it is typically necessary to build corresponding lexical and parsing analyzers to restore the netlist text to a structured intermediate representation for subsequent processing. In existing technologies, netlist parsing systems generally use grammar tools such as lex / yacc or Antlr to manually define lexical and grammatical rules and write a large amount of corresponding data structure code. This approach suffers from low code cohesion and high coupling, meaning that data structures and grammatical processing logic are usually maintained in one or a few files. The high coupling and lack of boundaries between functional modules makes it difficult to add unit test files and hinders collaborative parallel development. Furthermore, maintenance overhead is high. As netlist formats become increasingly complex, grammatical rules can reach thousands or even tens of thousands of lines, concentrated in a single file, easily causing readability difficulties and deterring developers. Adding or modifying features requires inserting code into the main file, affecting global stability. Moreover, the lack of automated synchronization mechanisms, coupled with the fact that grammatical rules and data structures are often manually written without a unified source, easily leads to consistency issues due to structural changes, such as missing fields, type errors, and semantic logic mismatches. In particular, the highly heterogeneous netlist formats among different manufacturers and toolchains, coupled with the continuous expansion of chip scale, have led to a sharp increase in the syntactic complexity and nested structure of circuit netlists, further burdening the construction and maintenance of netlist parsers based on netlist syntax rule files. Some advanced open-source HDL tools, such as Verilator, employ syntax tree intermediate layers and code generation mechanisms to statically analyze HDL descriptions and convert them into structured simulation models, thereby reducing the complexity of manually constructing structures and behavioral logic. However, Verilator's generation mechanism is primarily geared towards Verilog / SystemVerilog HDL and lacks the ability to extend general syntax rules, thus lacking a flexible mechanism for combining and reusing syntax modules in multi-format netlist parsing scenarios. Therefore, this application provides a method, apparatus, and storage medium for constructing a netlist parser, applicable to the parsing of circuit data files in electronic design automation tools. This application can significantly improve the flexibility and maintainability of syntax processing by combining the syntax module distribution of the electronic design automation tool's directory structure, configuration-driven structure definition, incremental construction mechanism, and automatic code generation technology, so as to support the modular organization and automatic aggregation generation of structure definitions and syntax rules, and improve the maintainability, scalability, and consistency between structure and semantics of the netlist parser.

[0024] The following description is in conjunction with the accompanying drawings:

[0025] Figure 1 The diagram illustrates a flowchart of a method for constructing a netlist resolver according to some embodiments of this application. This structured construction method includes at least the following steps:

[0026] S110: Obtain the netlist syntax rule file;

[0027] S120: Based on the types of netlist statements and the preset tree directory structure in the netlist syntax rule file, construct multiple syntax modules. The multiple syntax modules correspond to the leaf directories of the preset tree directory structure. The types of netlist statements include one or more of the following: device statements, control statements, or analysis statements.

[0028] S130: Construct a structure configuration file in the syntax module. The structure configuration file is used to define the data structure fields of the netlist statements corresponding to the syntax module. The data structure fields are used to represent the hierarchical organization structure and parameter attributes of the netlist statements corresponding to the syntax module.

[0029] S140: Construct a syntax rule file in the syntax module. The syntax rule file is used to describe the statement format of the netlist statements corresponding to the syntax module in the netlist syntax rule file.

[0030] S150: In the root directory of the preset tree directory structure, a netlist parser is compiled based on the syntax module and automated build tools. The netlist parser is used to parse the circuit data file, which is determined based on the netlist syntax rule file.

[0031] In the embodiments of the above netlist parser construction method, the netlist syntax rule file can be obtained first. The netlist syntax rule file is a specification document that defines the format, field meaning, optional elements, and value range of various statements in the circuit netlist. The circuit netlist, on the other hand, is a specific text file generated by design tools or engineers according to the syntax specifications defined in the netlist syntax rule file. It is written according to the syntax defined in the netlist syntax rule file and can be read and converted into the corresponding data structure at runtime by the netlist parser. Therefore, between the netlist syntax rule file and the circuit netlist, the former defines the rules, and the latter follows those rules. For example, a circuit netlist is a file that describes a circuit in text form, used to define the device types, connection relationships, and analysis instructions in the circuit. In the field of electronic design automation, circuit netlists can be automatically generated by circuit design software or simulation software. After obtaining the netlist syntax rule file, multiple syntax modules can be constructed based on the types of netlist statements and the preset tree directory structure in the netlist syntax rule file, and the syntax modules correspond to the leaf directories of the preset tree directory structure. Netlist statements are the basic statement units in a netlist syntax rule file. They can be used to describe different elements of a circuit. For example, netlist statements can be categorized into, but are not limited to, device statements, control statements, or analysis statements. Device statements can describe circuit devices such as resistors, capacitors, and transistors, and their connection methods. Control statements can be used to set macro definitions, subcircuit calls, or simulation control conditions in the circuit file. Analysis statements can specify the analysis type for circuit simulation, such as DC analysis, AC analysis, or transient analysis. This application forms multiple syntax modules, enabling independent management and parsing of different types of statements, thus forming a modular syntax structure. A pre-defined tree directory structure can be used to represent the hierarchical relationship between syntax modules, ensuring the clarity of the syntax rule organization. The tree directory structure is a hierarchical file organization method, which in this application can be used to organize syntax modules according to parent-child relationships. The tree directory structure can consist of a root directory, several intermediate directories, and leaf directories, with the root directory being the highest level and the leaf directories the lowest level. For example, the root directory can be used to store global build configuration files and unified build scripts, serving as the starting point for the entire structured build method; intermediate directories can be used to represent the grouping or category of syntax modules, such as the classification of device, control, and analysis statements; leaf directories can be used to store specific syntax modules, with each leaf directory corresponding to a specific circuit element or statement type, and can contain the structure configuration file and syntax rule file for that syntax module. Therefore, in the embodiments of this application, through the tree directory structure, each specific circuit element (such as a certain type of device statement) can be represented as corresponding to an independent leaf directory in the tree structure, thereby ensuring that modules do not interfere with each other and can be maintained and extended independently.Furthermore, a structure configuration file can be built within a specific syntax module to define the data structure fields of the netlist statements corresponding to that syntax module. These data structure fields can characterize the hierarchical organization and parameter attributes of the netlist statements corresponding to the syntax module. For example, these data structure fields can represent variables or attributes of the components of a circuit netlist statement in the program implementation. For instance, a resistor statement typically includes a device name, two endpoint nodes, and a resistance parameter; this information can be described using data structure fields. Additionally, nested relationships may exist between different circuit netlist statements; for example, a sub-circuit statement may contain multiple device statements. This relationship can be described using a hierarchical organization structure. Parameter attributes can represent the parameter items of devices or other content in the circuit netlist statement, such as numerical values, default parameters, and optional information. Therefore, defining data structure fields through a structure configuration file in this application provides a data model foundation for subsequent code generation and syntax parsing. On the other hand, this application can also build a syntax rule file within the syntax module to describe the statement format of the circuit netlist statements corresponding to the syntax module in the netlist syntax rule file. The syntax rule file is a text file used to define how input text (i.e., the input circuit data file) should be matched with predefined syntax production rules. The statement format specifies the composition of statements in the circuit netlist. For example, a device statement typically consists of a device name, node number, and parameter values ​​in a fixed order. The syntax rule file formalizes the text statements in the netlist syntax rule file into a recognizable syntax structure, thus corresponding to data structure fields. Finally, in the root directory of the predefined tree-structured directory, this application can compile and generate a netlist parser based on the syntax modules and automated build tools. The automated build tools can be used to uniformly organize and transform the above syntax modules into executable parsing programs, typically including build control scripts and compilation toolchains to achieve code generation, rule merging, and compilation. For example, during compilation, data structure code can first be generated based on the structure configuration file, then the syntax rule files can be merged to form a syntax parsing file; finally, the data structure code and the syntax parsing file are compiled to obtain a netlist parser capable of parsing circuit data files. The netlist parser generated by this application can read circuit data files, such as circuit netlists, at runtime and perform lexical and syntactic analysis on the circuit netlist statements. Through the above implementation method, the netlist parser construction method provided by this application analyzes the netlist syntax rule file, modularizes the netlist statements using a preset tree directory structure, independently defines and manages them using structure configuration files and syntax rule files, and then uses automated construction tools to achieve unified compilation and parser generation.Compared to the traditional method of manually maintaining complete syntax files, this application uses modular management to convert netlist statements in the netlist syntax rule file into independent syntax modules, thereby reducing the coupling of syntax rules. Furthermore, organizing syntax modules through a tree-like directory makes the hierarchical relationship of syntax rules more intuitive and easier to extend. By using an automated build tool to uniformly compile and generate a netlist parser, the risks associated with manually modifying the main syntax file are avoided. This enables the parsing and subsequent processing of circuit data files, improving the construction efficiency and maintainability of the netlist parser.

[0032] Figure 2 The diagram illustrates a flowchart of a method for generating a netlist parser according to some embodiments of this application. Step S150, based on the syntax module and automated build tools, compiles and generates a netlist parser, including:

[0033] S210: Read multiple syntax modules;

[0034] S220: Based on the structure configuration file of the syntax module, it generates the corresponding data structure code. The data structure code can be expressed in one of the following languages: C++, Java, or Python.

[0035] S230: Syntax rule files based on syntax modules are merged to form a syntax parsing file;

[0036] S240: Compiles the data structure code and syntax parsing files to generate a netlist parser.

[0037] In the above embodiments, the automated build tool can scan each syntax module under a preset tree directory structure, identify and read the structure configuration files and syntax rule files within them. The automated build tool can be implemented using build scripts and build configuration files. For example, in one embodiment, a Makefile (build configuration file) can be used to call a Python script to batch read and preprocess each syntax module. Furthermore, when generating corresponding data structure code based on the structure configuration files of the syntax modules, the automated build tool can parse the structure configuration files in each syntax module, extract the defined data structure fields, and automatically generate data structure code for program implementation, representing the program entities of circuit elements and their parameters in the netlist parser. For example, the fields in the structure configuration file support nesting and default value settings to adapt to hierarchical syntax structures such as .subckt, which can trigger the syntax rule of "entering sub-circuit definition". The implementation form of the data structure code can differ in different programming language environments. For example, in C++, the data structure code can be defined using a structure (struct), where each field corresponds to the attributes of a circuit element, such as device name, node number, and parameter value. In Java, data structure code can be defined as a class, describing the parameters and behaviors of circuit elements through fields and methods. In Python, the same data structure code can be defined as a data class or a regular class, using attributes and decorators to describe the parameter information of circuit elements and allowing default values ​​to be set. In some embodiments of this application, the structure configuration file can be described using class-based JSON syntax to support field nesting and default parameter definitions. Furthermore, when merging the syntax rule files of syntax modules to form a syntax parsing file, this application can use an automated build tool to uniformly aggregate the syntax rule files of multiple syntax modules, generating a complete syntax parsing file. The syntax rule file defines the statement format of the netlist statements corresponding to the syntax module; for example, the format of a resistor statement is "device name, node 1, node 2, resistance value". For example, this application can maintain consistency between the definition format of the syntax rule file and the complete syntax parsing file to ensure compatibility with general-purpose parsing tools. In some embodiments of this application, to avoid conflicts between different syntax modules, lexical tokens are no longer declared in the syntax rule file but are centrally declared and managed by a unified syntax parsing file. For example, rules can be written using the syntax file format supported by Bison (a syntax analysis tool), while an automated build tool generates token definitions uniformly. Finally, the automated build tool compiles the data structure code and syntax parsing file, taking the aforementioned data structure code and syntax parsing file as input, and calls the compiler to generate the final netlist parser.A netlist parser is a program module that performs lexical and syntactic analysis on circuit data files at runtime, converting input text statements into program-operable data structures. After the netlist parser is generated, it can parse the circuit data file, converting device statements, control statements, and analysis statements into circuit element objects or instruction objects in memory for subsequent simulation or circuit analysis tools to use. This application, through the above implementation method, enables automated batch reading of syntax module files by a tool during the compilation and generation of the netlist parser. By uniformly merging syntax rule files and centrally managing lexical symbols, definition conflicts between modules are avoided, and the final generated netlist parser can be directly applied to the parsing of circuit data files, improving parsing efficiency and accuracy.

[0038] In some embodiments of this application, the syntax parsing file includes a lexical file and a syntax file, wherein the syntax file is used to define the combination rules of lexical symbols in the netlist syntax rule file to characterize the statement format and hierarchical relationship of the netlist statement, and the lexical file is used to define the segmentation rules of character sequences in the netlist syntax rule file to identify the identifiers, values ​​and control keywords of the netlist statement.

[0039] A grammar file is a description file that uses formalized grammar rules to specify how input lexical symbols are combined into complete statements according to production rules. It can be used to define the combination rules of lexical symbols in a netlist grammar rule file to characterize the statement format and hierarchical relationship of netlist statements. For example, a circuit netlist statement for a resistor device can use the following grammar format: Device Name-Node 1-Node 2-Resistance Value, where "Device Name," "Node," and "Resistance Value" are all lexical symbols, and the grammar file specifies that these symbols must appear in a fixed order. The grammar file can adopt a file format consistent with common parsing tools (such as Bison) to achieve compatibility with existing compiler build tools. A lexical file is a rule file used for lexical analysis, which can be used to describe how to segment the input character stream into recognizable lexical symbols (tokens). In this application, it can be used to define the segmentation rules of character sequences in a netlist grammar rule file to identify identifiers, values, and control keywords in netlist statements. For example, when "R1" appears in the input character stream, the lexical file can recognize it as a device name; when "10k" is input, it is recognized as a parameter value. The lexical file can adopt a file format consistent with common lexical analysis tools (such as Flex), defining recognition rules for different types of symbols using regular expressions. In this embodiment, the syntax file and the lexical file work together to achieve a complete transformation from the raw character sequence of the netlist syntax rule file to the structured representation of netlist statements. Specifically, the lexical file is responsible for segmenting the input text stream into basic symbols, while the syntax file is responsible for combining these symbols into statements that conform to the rules. This hierarchical definition method ensures that the grammatical structure of the netlist syntax rule file is clear and easily extensible.

[0040] In some embodiments of this application, the syntax rule file and the syntax parsing file have the same syntax definition format. The syntax rule file does not contain the declaration of lexical symbols, which are uniformly declared by the syntax parsing file.

[0041] In this embodiment, the syntax rule file does not include declarations of lexical symbols (tokens). In existing technologies, each syntax rule file may repeatedly declare the same lexical symbols, leading to inconsistencies during the merging process. However, in this embodiment, all lexical symbols are uniformly declared and managed by the syntax parsing file. When merging multiple syntax rule files, the automated build tool automatically collects the lexical symbols required by each module and defines them centrally in the unified syntax parsing file. This approach ensures compatibility in definition format between the syntax rule file and the syntax parsing file, while avoiding duplicate or conflicting token definitions in different modules. For example, if the syntax rule for resistor devices requires both IDENTIFIER and NUMBER lexical symbols, and the syntax rule for capacitor devices also requires NUMBER, the automated build tool defines the NUMBER symbol only once in the syntax parsing file, thus achieving global consistency. This approach supports flexible combination and incremental integration of multiple syntax modules, thereby improving the construction efficiency and system stability of the netlist parser.

[0042] In some embodiments of this application, a tree-shaped directory structure is preset, and the device directory is determined based on electronic automated design tools.

[0043] Electronic automation design tools, such as PSpice, HSPICE, Spectre, or OrCAD Capture, typically provide component libraries and component explorers for organizing and managing circuit components according to functional categories. Therefore, the pre-defined tree-like directory structure of this application can be designed with reference to the component directory system in such tools. For example, in one embodiment, the netlist statements in the netlist syntax rule file can be divided into different directory branches according to component categories (such as resistors, capacitors, and transistors), control statement categories (such as subcircuit definition statements and model statements), and analysis statement categories (such as DC analysis, AC analysis, and transient analysis). Each specific syntax module is stored as a leaf directory under its corresponding category. In this way, the pre-defined tree-like directory structure naturally reflects the classification relationship of circuit elements, making the hierarchical relationship between syntax modules clear and explicit. In one embodiment, taking the PSpice device as an example, the Component Explorer tool of OrCAD Capture software can divide the directory according to the device classification system shown in the software, for example, using "basic passive devices", "active devices", and "functional blocks" as the main branches of the tree directory.

[0044] In some embodiments of this application, a netlist parser is compiled based on syntax modules and an automated build tool. The method further includes: during the incremental build process of generating the netlist parser, the automated build tool detects timestamp changes of multiple syntax modules; when a first timestamp change of the first syntax module is determined, the first syntax module is reconstructed, wherein the reconstruction includes updating the structure configuration file and updating the syntax rule file.

[0045] Automated build tools can determine if a module has been modified by detecting changes in the timestamps of its syntax module files. For example, an automated build tool can call the file status interface provided by the operating system to obtain the last modification time of a syntax module and compare it with the previous build record. If a change in the timestamp of a syntax module is detected, it is determined that the syntax module has been updated. When an update is determined for the first syntax module, the automated build tool rebuilds it. During rebuilding, the structure configuration file can be updated, the data structure code corresponding to the syntax module can be re-parsed and generated to ensure that it reflects the latest hierarchical organization structure and parameter attributes; and the syntax rule file can be updated and the syntax rule file corresponding to the syntax module can be re-merged to ensure that the rule definition of the module in the syntax parsing file is consistent with the latest statement format. For example, automated build tools can implement incremental builds based on Makefiles (build control files). When the configuration file or rule file of a syntax module is modified, the Makefile will trigger the corresponding Python script or other code generation tools to rebuild only the modified modules, while the unmodified modules remain unchanged. Finally, the updated syntax module will participate in the compilation along with other unmodified modules to generate a complete netlist parser. By introducing an incremental build mechanism during the netlist parser generation process, this application effectively reduces unnecessary recompilation, rebuilding only the modified syntax modules, thereby significantly improving build efficiency. Simultaneously, the rebuilding includes both structure configuration files and syntax rule files, ensuring that the updated netlist parser can still correctly parse circuit data files, avoiding parsing errors caused by some modules not being updated synchronously. The embodiments of this application are applicable to the development and maintenance of large-scale circuit netlist files, thereby reducing system build time and resource consumption.

[0046] In some embodiments of this application, the method further includes: when the netlist parser adds a syntax module, using the current syntax module as a syntax template; filling in the structure configuration file and syntax rule file corresponding to the newly added netlist statement in the syntax template to generate a second syntax module; and integrating the second syntax module into the netlist parser through an automated construction tool.

[0047] This embodiment allows for the generation of a syntax template based on existing syntax modules after the netlist parser has been generated. The syntax template can include a basic framework of a modular directory structure and necessary file configuration formats. The syntax template can be constructed from a preset directory skeleton, including a blank structure configuration file and a syntax rule file. Based on the syntax template, developers or automated tools can fill in the content corresponding to the newly added netlist statements. For example, in the structure configuration file, the data structure fields required for the new netlist statement are defined to characterize the hierarchical organization structure and parameter attributes of the statement; in the syntax rule file, the statement format of the new netlist statement in the netlist syntax rule file is defined, such as the order of input symbols and possible parameter combinations. After completion, a second syntax module is generated and stored in the leaf directory of a preset tree-like directory structure, maintaining the same directory organization as the original module. Subsequently, the second syntax module is integrated into the netlist parser using an automated build tool. This embodiment allows for the flexible addition of new syntax modules to the netlist parser, enabling rapid support for new netlist statements. By utilizing a syntax template mechanism, developers can generate new syntax modules simply by adding necessary configuration information to the template, significantly simplifying the module expansion process. Simultaneously, thanks to the integration mechanism of automated build tools, newly added syntax modules can automatically participate in the generation of the netlist parser, avoiding manual modifications to the main syntax file, reducing the probability of errors, and improving the system's scalability and maintenance efficiency.

[0048] In some embodiments of this application, the method further includes: independently verifying the syntax module based on a module-level unit testing framework, which includes a test input file and an expected output file, for comparing the parsing results of the syntax module and determining the accuracy of the netlist parser.

[0049] The module-level unit testing framework can perform functional verification within a single syntax module. Each syntax module is treated as an independent unit for input-output comparison, thus ensuring module-level correctness. The test input file stores sample netlist statements for a specific syntax module. For example, the test input file for a resistor module can contain several resistor device statements, covering normal input, abnormal input, and boundary conditions. The expected output file stores the structured results that the test input file should produce under correct parsing, such as the corresponding data structure for the resistor device name, node number, and resistance parameters. During verification, the actual output after parsing the syntax module can be compared with the expected output file. If the comparison results are consistent, it indicates that the syntax module's parsing function is correct; if there are differences, it indicates a problem in the syntax module's implementation, requiring further adjustment. In some implementations, the module-level unit testing framework can also support batch execution, used to verify multiple syntax modules at once, thereby improving testing efficiency. Therefore, this application can achieve independent verification of each syntax module, ensuring its correctness before being added to the overall parser. This approach can effectively locate problematic modules, shorten debugging time, and improve the overall stability and maintainability of the system. Meanwhile, by comparing the input file with the expected output file, automated testing can be achieved, improving the coverage and accuracy of verification.

[0050] Figure 3This diagram illustrates the structure of a netlist parser provided in some embodiments of this application. The directory structure of the netlist parser is divided into three main directories: device statement directory, control statement directory, and analysis statement directory. Each main directory further contains multiple statement modules, such as syntax modules stmta, stmtb, and stmtc. Each syntax module directory stores files corresponding to specific netlist statements. Within each syntax module stm, there is a .def file (structure configuration file) used to define the data structure fields of the statement; the content is concise and clear, containing only core fields. There is also a .yac file (grammar rule file) used to define the statement format and its lexical rule fragments in the netlist. Finally, there is a .test file (unit test file) used to provide input samples and expected output results for the statement module to support module-level unit testing. During the build process, automated build tools process these files; for example, they can expand the .def file into a .h file (C++ header file), where the .h file is more complete than the .def file, containing more fields and declarations. Multiple .yac files are aggregated to generate a unified lexical file (.l) and syntax file (.y). These are then processed by the lexical analyzer lex and the syntax analyzer yacc to form executable parsing logic. Subsequently, all .h files derived from the .def files are compiled by the compiler gcc to finally generate the main program. In application, for example, consider a resistor statement. The manual specifies the format as "resistor name, anode node name, cathode node name, resistance value." If the circuit netlist contains the text "R1 net1 net2 10", the lexical analyzer lex first segments the text into "R1", "net1", "net2", and "10", assigning each word a category. Next, the syntax analyzer yacc matches the segmented words to the resistor statement, thus determining that this line represents a resistor, not a voltage or capacitor, or other device. Finally, a structure is created in the resistor.h file, filling "R1" into the resistor name field, "net1" and "net2" into the node name fields, and "10" into the value field. Through the above process, developers only need to maintain .def and .yac files in their daily development work, without having to directly modify the global .h, .l, and .y files, reducing repetitive work and lowering the risk of errors. Meanwhile, the .test file enables independent verification of individual statement modules, thus ensuring the correctness of the module before it is added to the overall parser.

[0051] Figure 4The diagram illustrates a structural schematic of a netlist parser construction apparatus provided in some embodiments of this application. The structured construction apparatus 400 includes: an acquisition unit 410 for acquiring a netlist syntax rule file; a partitioning unit 420 for constructing multiple syntax modules based on the types of netlist statements in the netlist syntax rule file and a preset tree directory structure, wherein each syntax module corresponds to a leaf directory of the preset tree directory structure, and the types of netlist statements include one or more of device statements, control statements, or analysis statements; a first construction unit 430 for constructing a structure configuration file in each syntax module, wherein the structure configuration file defines the data structure fields of the netlist statements corresponding to the syntax module, and the data structure fields characterize the hierarchical organization structure and parameter attributes of the netlist statements corresponding to the syntax module; a second construction unit 440 for constructing a syntax rule file in each syntax module, wherein the syntax rule file describes the statement format of the netlist statements corresponding to the syntax module in the netlist syntax rule file; and a compilation unit 450 for compiling and generating a netlist parser in the root directory of the preset tree directory structure, based on the syntax modules and an automated construction tool, wherein the netlist parser is used to parse circuit data files, and the circuit data files are determined based on the netlist syntax rule file.

[0052] Based on the same technical concept, this application also provides a computer-readable storage medium, including: a memory storing instructions thereon, and a processor configured to implement the method for constructing the netlist resolver provided in the above embodiments when reading the instructions in the memory.

[0053] In the above embodiments, the descriptions of each embodiment have their own emphasis. Parts not described in detail or in a particular embodiment can be referred to in the relevant descriptions of other embodiments. Furthermore, the above embodiments can be freely combined as needed.

Claims

1. A method for constructing a netlist resolver, characterized in that, include: Obtain the netlist syntax rule file; Based on the types of netlist statements and the preset tree directory structure in the netlist syntax rule file, multiple syntax modules are constructed. The multiple syntax modules correspond to the leaf directories of the preset tree directory structure. The types of netlist statements include one or more of the following: device statements, control statements, and analysis statements. A structure configuration file is constructed in the syntax module. The structure configuration file is used to define the data structure fields of the netlist statement corresponding to the syntax module. The data structure fields are used to characterize the hierarchical organization structure and parameter attributes of the netlist statement corresponding to the syntax module. A syntax rule file is constructed in the syntax module, and the syntax rule file is used to describe the statement format of the netlist statement corresponding to the syntax module in the netlist syntax rule file; In the root directory of the preset tree-shaped directory structure, a netlist parser is compiled and generated based on the syntax modules and the automated build tool, including: reading multiple syntax modules; generating corresponding data structure code based on the structure configuration file of the syntax modules, wherein the data structure code is represented in one of the following languages: C++, Java, or Python; merging the syntax rule files of the syntax modules to form a syntax parsing file; and compiling the data structure code and the syntax parsing file to generate the netlist parser. The netlist parser is used to parse circuit data files, which are determined based on the netlist syntax rule file.

2. The method for constructing a netlist resolver according to claim 1, characterized in that, The syntax parsing file includes a lexical file and a syntax file. The syntax file is used to define the combination rules of lexical symbols in the netlist syntax rule file to characterize the statement format and hierarchical relationship of the netlist statements. The lexical file is used to define the character sequence segmentation rules in the netlist syntax rule file to identify the identifiers, values ​​and control keywords of the netlist statements.

3. The method for constructing a netlist resolver according to claim 2, characterized in that, The syntax rule file and the syntax parsing file have the same syntax definition format. However, the syntax rule file does not contain declarations of lexical symbols, which are declared uniformly by the syntax parsing file.

4. The method for constructing a netlist resolver according to claim 3, characterized in that, The preset tree-shaped directory structure is determined based on the device directory division of electronic automated design tools.

5. The method for constructing a netlist resolver according to claim 1, characterized in that, The process of compiling and generating a netlist parser based on the syntax module and the automated build tool also includes: During the incremental construction process of generating the netlist parser, the automated construction tool detects timestamp changes of multiple syntax modules; When a first timestamp change is determined in the first syntax module, the first syntax module is rebuilt, wherein the reconstruction includes updating the structure configuration file and updating the syntax rule file.

6. The method for constructing a netlist resolver according to claim 5, characterized in that, Also includes: When the netlist parser adds the syntax module, it uses the current syntax module as the syntax template. Fill in the structure configuration file and the syntax rule file corresponding to the newly added netlist statement in the syntax template to generate the second syntax module; The second syntax module is integrated into the netlist parser using the automated build tool.

7. The method for constructing a netlist resolver according to any one of claims 1 to 6, characterized in that, Also includes: The syntax module is independently verified based on a module-level unit testing framework, which includes a test input file and an expected output file, used to compare the parsing results of the syntax module and determine the accuracy of the netlist parser.

8. An apparatus for constructing a netlist resolver, characterized in that, include: The acquisition unit is used to acquire the netlist syntax rule file; The partitioning unit is used to construct multiple syntax modules based on the types of netlist statements and the preset tree directory structure in the netlist syntax rule file. The multiple syntax modules correspond to the leaf directories of the preset tree directory structure. The types of netlist statements include one or more of the following: device statements, control statements, and analysis statements. The first construction unit is used to construct a structure configuration file in the syntax module. The structure configuration file is used to define the data structure fields of the netlist statement corresponding to the syntax module. The data structure fields are used to characterize the hierarchical organization structure and parameter attributes of the netlist statement corresponding to the syntax module. The second construction unit is used to construct a syntax rule file in the syntax module, wherein the syntax rule file is used to describe the statement format of the netlist statement corresponding to the syntax module in the netlist syntax rule file; The compilation unit, located in the root directory of the preset tree-structured directory, compiles and generates a netlist parser based on the syntax modules and automated build tools. The compilation unit includes: reading multiple syntax modules; generating corresponding data structure code based on the structure configuration files of the syntax modules, wherein the data structure code is expressed in one of the following languages: C++, Java, or Python; merging the syntax rule files of the syntax modules to form a syntax parsing file; and compiling the data structure code and the syntax parsing file to generate the netlist parser. The netlist parser is used to parse circuit data files, wherein the circuit data files are determined based on the netlist syntax rule files.

9. A computer-readable storage medium, characterized in that, include: A memory having instructions stored thereon, and a processor configured to implement the method of constructing a netlist resolver according to any one of claims 1 to 7 when reading the instructions in the memory.

Images