A python class-based circuit intermediate representation method and system
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHANGHAI YUANSI INTELLIGENT TECHNOLOGY CO LTD
- Filing Date
- 2026-04-23
- Publication Date
- 2026-08-07
AI Technical Summary
上述六类关键设计信息在SPICE网表中完全缺失,导致后端设计人员需要通过人工沟通获取这些信息,极大地降低了设计效率并引入了人为错误
[0020]综上所述,本申请提供了一种面向AI辅助模拟集成电路设计流程的电路中间表示方法及系统。在当前大语言模型直接生成SPICE网表的新设计趋势下,本申请以Python类作为电路描述的唯一真实信息源,将SPICE网表和原理图均作为由该Python类自动生成、且内容严格一致的派生产物。通过在单一Python类中完整表达电路连接关系、器件角色、匹配约束、对称性约束、屏蔽约束、版图提示以及优化目标等七类设计信息,本申请既解决了人类工程师难以阅读和理解AI生成网表的问题,能够自动输出直观的可视化原理图,又填补了AI生成网表与后端物理实现之间的信息空缺,向版图工具、优化工具无损传递完整的约束与设计意图。本申请实现了AI生成文本到人类可读图形、再到后端物理信息的同源表达,为基于人工智能的模拟电路全流程自动化设计奠定了基础。
Smart Images

Figure CN122528792A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the fields of integrated circuit design automation and software engineering technology, specifically to a circuit intermediate representation method and system based on Python classes. Background Technology
[0002] In the current analog integrated circuit design flow, SPICE netlists are the de facto standard format for circuit description. Engineers draw circuits in schematic editors, export SPICE netlists, and then use them for simulation, optimization, and layout design. However, this design paradigm centered on SPICE netlists has the following prominent problems: First, there is the issue of information loss. SPICE netlists only describe the connections between circuits (i.e., the connections between device ports and network nodes), failing to express device role information (e.g., whether a transistor is a differential input or a load transistor), matching constraint information (e.g., differential pairs require strict matching), symmetry constraint information (e.g., differential signal paths require symmetrical layout), shielding constraint information (e.g., sensitive signal lines require shielding protection), layout hints (e.g., the preferred placement orientation and location of devices), and optimization target information (e.g., which parameters need optimization and their target values). These six types of critical design information are completely missing from SPICE netlists, forcing backend designers to obtain this information through manual communication, significantly reducing design efficiency and introducing human error.
[0003] Second, there is the problem of information transmission gaps. In the complete process from circuit design to layout implementation, the design intent needs to undergo multiple format conversions and tool switches. Each conversion results in the loss of some design information, creating a significant gap between the design intent of the front-end designer and the actual information obtained by the back-end layout engineer. Statistics show that traditional SPICE netlists can only transmit about 1 / 7 of the complete design information, with the remaining 6 / 7 of critical information lost during transmission.
[0004] Third, there's the issue of human-computer interaction and information consistency in the AI-assisted design process. Unlike the traditional model where human engineers manually draw schematics in graphical interfaces, large language models excel at processing structured text, typically generating circuit netlist files that conform to SPICE syntax. However, SPICE netlists, as a plain text description of connections, have poor readability. Human engineers struggle to quickly understand circuit architecture, signal flow, and functional module divisions simply by reading the netlist, hindering the design review, debugging, and iterative optimization of AI-generated circuits.
[0005] Furthermore, the original netlist generated by AI only has connection relationships and lacks the design intent such as matching constraints, symmetry constraints, and layout hints necessary for layout implementation, resulting in an information gap between the AI-generated netlist and the backend physical implementation.
[0006] Fourth, there is a lack of automated verification mechanisms. SPICE netlists are essentially flat text formats, lacking structured semantic information, making it difficult to automatically verify the correctness of circuit connections. For example, SPICE netlists cannot automatically detect common design errors such as incorrect connections at device ports, floating nodes, and short-circuit loops. Therefore, with the trend of AI-assisted analog circuit design, a unified description mechanism is needed to solve the information gap between AI-generated text netlists and human-readable graphical interfaces, while simultaneously and losslessly transmitting constraint information to backend physical design tools. This requires that the schematic and netlist must be derived from the same source, rather than being two independent entities prone to version separation in traditional workflows.
[0007] To address the above problems, the following solutions exist in the existing technology, but all of them have shortcomings: Option 1: Add annotations to the SPICE netlist to indicate additional information. This option adds matching constraints and other information in the form of annotations in the netlist file. However, the annotation information lacks structured semantics and cannot be automatically parsed and utilized by the toolchain. Essentially, it is still a human-readable rather than machine-readable way of transmitting information.
[0008] Option 2: Use proprietary formats to describe additional constraints. Some commercial EDA tools define proprietary constraint file formats for describing constraints such as matching and symmetry. However, these formats are separate from the circuit description, require additional maintenance, and are incompatible with different tools, increasing the complexity of the design process.
[0009] Option 3: Use a Hardware Description Language (HDL) to describe the analog circuit. VHDL-AMS and Verilog-AMS are examples. While analog hardware description languages possess certain structured description capabilities, their syntax is verbose, the learning curve is steep, and they lack built-in support for layout-related information such as matching constraints, symmetry, and masking, making them unsuitable as a complete intermediate representation of analog circuits. Summary of the Invention
[0010] To help solve the above-mentioned technical problems, this application provides a circuit intermediate representation method and system based on Python classes, adopting the following technical solution: Firstly, this application provides a circuit intermediate representation method based on Python classes, which includes the following steps: S1: Create a Python class for the target circuit by inheriting a predefined circuit base class. In the Python class, declare the circuit connection relationship in an object-oriented manner, and declare at least one design information among device roles, matching constraints, symmetry constraints, masking constraints, layout hints, and optimization targets. Use the Python class as the only real information source to carry the design information. S2: Extract the circuit connection relationship from the unique real information source, perform deterministic mapping according to SPICE syntax rules, and generate a standard format SPICE netlist file as a derivative product; S3: Extract the circuit connection relationship, the device role, and the layout hints from the unique real information source, and generate a circuit schematic as a derivative product; S4: Automated verification of the circuit is performed using the structured semantics of the design information in the unique real information source; S5: Through a standardized information query interface, the design information carried in the unique real information source is transmitted to the downstream design stage without loss.
[0011] In S1, the device role is used to describe the functional role of the device in the circuit, including input_pair, load, tail_current, cascode, and mirror_base, which are used to represent differential input pair transistors, load transistors, tail current source transistors, cascode transistors, and mirror base transistors, respectively.
[0012] In step S1, the circuit base class automatically collects the design information declared in the subclasses through a class attribute interception and collection mechanism; the mathematical expression of the matching constraint is: for matching device groups Any two devices D in i and D j ,satisfy ,in Due to differences in device parameters, This is the matching accuracy threshold.
[0013] In step S3, when generating the circuit schematic, the extracted device roles are used to identify the circuit module type of current mirror, differential pair, or load transistor to achieve intelligent layout. The specific rules of the intelligent layout are as follows: devices marked as differential input pair transistors are placed in the center of the circuit, devices marked as load transistors are placed on the power supply side, devices marked as tail current source transistors are placed on the ground side, and devices marked as common source cascode transistors are placed above the corresponding main transistors.
[0014] In S4, the automated verification includes connection integrity verification, electrical rule checking, constraint consistency verification, and role consistency verification; wherein, the connection integrity verification includes detecting unconnected device ports and network nodes connected to only one device port, and the electrical rule checking includes detecting power short-circuit paths and direct connections from the gate to the power rail.
[0015] In step S1, the layout hints include preferred placement areas for devices, device orientation, and routing priorities; the symmetry constraints include symmetry axis definitions and a list of symmetrical device pairs; the circuit connection relationships are established by connecting device ports to the same network node instance; the shielding constraints include the shielded object, shielding layer type, and shielding spacing requirements; the optimization objective includes objective parameter names, objective directions, objective values, and weights to support multi-objective optimization, and its weighted objective function is: Where K is the number of optimization targets, w k f is the weight of the k-th objective. k (x) is the normalized objective function for the k-th objective, and x is the vector of parameters to be optimized.
[0016] In step S3, a YAML file or JSON file containing layout suggestions and instructions is generated based on the identified circuit module type, so that the backend can perform layout based on the information in the YAML file or the JSON file.
[0017] In step S4, the role consistency verification includes: detecting device pairs labeled as input_pair and verifying whether their gates are connected to different input network nodes; detecting devices labeled as tail_current and verifying whether their sources are connected to the ground network and whether their drains are connected to the common source node of the differential pair circuit; detecting devices labeled as load and verifying whether their sources are connected to the power network node; and issuing a warning or error message when the device role is found to be inconsistent with the actual network connection relationship.
[0018] In step S4, the constraint consistency verification includes: obtaining the matching constraint and the symmetry constraint declared in the unique true information source; detecting whether there is a device group that declares the symmetry constraint but does not declare the matching constraint; if so, issuing a warning; detecting whether there is a logical conflict between the symmetric device pair defined in the symmetry constraint and the matching device group defined in the matching constraint; if there is a conflict, issuing an error message.
[0019] Secondly, this application provides a Python-based circuit intermediate representation system, wherein the system is used to execute the Python-based circuit intermediate representation method as described in any one of the first aspects, and the system includes the following modules: A Python class definition module is used to execute S1; The SPICE netlist generation module is used to execute S2; The schematic generation module is used to execute S3; The verification module is used to execute S4; The information transmission module is used to execute S5.
[0020] In summary, this application provides a circuit intermediate representation method and system for AI-assisted analog integrated circuit design. In the current design trend of directly generating SPICE netlists from large language models, this application uses a Python class as the sole source of real information for circuit description, treating both the SPICE netlist and schematic as automatically generated derivatives of this Python class with strictly consistent content. By fully expressing seven types of design information—circuit connection relationships, device roles, matching constraints, symmetry constraints, shielding constraints, layout hints, and optimization objectives—within a single Python class, this application not only solves the problem of human engineers struggling to read and understand AI-generated netlists, automatically outputting intuitive and visual schematics, but also fills the information gap between AI-generated netlists and backend physical implementation, seamlessly transmitting complete constraints and design intent to layout and optimization tools. This application achieves a homogeneous representation from AI-generated text to human-readable graphics and then to backend physical information, laying the foundation for fully automated analog circuit design based on artificial intelligence. Attached Figure Description
[0021] Figure 1 This is a schematic diagram of the overall architecture of the Python-based intermediate circuit representation system provided in the embodiments of this application.
[0022] Figure 2 This is a schematic diagram comparing the design information flow provided in the embodiments of this application.
[0023] Figure reference numerals: 200-Circuit intermediate representation system based on Python classes; 210-Python class definition module; 211-Circuit base class submodule; 212-Device class submodule; 213-Network class submodule; 214-Constraint class submodule; 220-SPICE netlist generation module; 230-Schematic generation module; 240-Verification module; 250-Information transmission module. Detailed Implementation
[0024] The present application will be further described below with reference to the accompanying drawings. The principles of the present application are very clear to those skilled in the art. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.
[0025] Figure 1 This is a schematic diagram of the overall architecture of a Python-based intermediate circuit representation system 200 provided in an embodiment of this application. As shown in the figure, the system mainly consists of a Python class definition module 210, a SPICE netlist generation module 220, a schematic diagram generation module 230, a verification module 240, and an information transmission module 250.
[0026] 1. Python class definition module 210.
[0027] The Python class definition module 210 is the core module of this system, responsible for providing the basic framework for the intermediate representation of the circuit. This module specifically includes the following sub-modules: (1) Circuit Base Class Submodule 211: The circuit base class submodule 211 defines an abstract base class CircuitBase, which serves as the parent class for all circuit Python classes. This base class provides the following core interfaces: a device declaration interface, used to declare the required device instances in the circuit class; a network connection interface, used to define the connection relationships between device ports; a constraint declaration interface, used to declare various design constraints; and a parameter definition interface, used to define adjustable parameters and their value ranges. All specific circuits complete their circuit description by inheriting from this base class and implementing the above interfaces. The base class uses a metaclass mechanism to automatically collect device, network, and constraint information declared in subclasses, without the need for explicit registration.
[0028] (2) Device Class Submodule 212: The device class submodule 212 defines Python class representations of various devices commonly used in analog integrated circuits. Taking a MOSFET device as an example, its Python class includes the following attributes: device type (NMOS or PMOS), channel width W, channel length L, parallel index M, gate port, drain port, source port, body port, and device role label. The device role label is one of the key innovations of this application, used to describe the functional role of the device in the circuit. For example, "input_pair" represents a differential input pair, "load" represents a load transistor, "tail_current" represents a tail current source, and "cascode" represents a common source common gate transistor. For resistor devices, its Python class includes resistance value R, two ports, and role label; for capacitor devices, its Python class includes capacitance value C, two ports, and role label. Each device class implements a serialization method to SPICE syntax, which can automatically generate the corresponding SPICE device description line.
[0029] (3) Network Class Submodule 213: The network class submodule 213 defines the Python class Net for circuit network nodes. Each Net instance represents an electrical network node in the circuit, including the network name, a list of connected device ports, and network attributes (such as signal type, voltage domain, etc.). Electrical connections between devices can be established by connecting device ports to the same Net instance. The network class also supports hierarchical naming; when the circuit contains sub-circuits, the network name is automatically prefixed with a hierarchical prefix to avoid naming conflicts.
[0030] (4) Constraint Class Submodule 214: The constraint class submodule 214 defines the Python class representations of the following five types of design constraints: The MatchConstraint class is used to declare a group of devices that require strict matching, including a list of matching devices and matching accuracy requirements. For example, the two input transistors of a differential pair need to be strictly matched in terms of their aspect ratio, threshold voltage, and channel current. The mathematical expression of the matching constraint is: for a group of matching devices... Any two devices D in i and D j ,Require ,in Due to differences in device parameters, This is the matching accuracy threshold.
[0031] The SymmetryConstraint class is used to declare devices or signal paths that require symmetrical layout. It includes a definition of the symmetry axis and a list of symmetrical device pairs. For example, the positive and negative branches of a differential signal path need to be strictly symmetrical about the central axis.
[0032] The ShieldConstraint class is used to declare sensitive signal lines or devices that require shielding protection, including the object to be shielded, the type of shielding layer, and the required shielding spacing. For example, high-sensitivity input signal lines require protection with a metal shielding ring to reduce crosstalk interference.
[0033] LayoutHints provide suggestions for device placement and routing, including preferred placement areas, device orientation, spacing recommendations, and routing priorities. Unlike hard constraints, layout hints are suggestions that layout tools can adjust based on actual conditions.
[0034] The `OptimizationTarget` class is used to declare the optimization objectives of a circuit. It includes the objective parameter name, objective direction (maximization or minimization), objective value, and weights. For example, multiple optimization objectives can be declared for an operational amplifier, such as maximizing gain, minimizing power consumption, and maximizing bandwidth, with corresponding weights assigned to each objective to support multi-objective optimization. The weighted objective function for multi-objective optimization is: Where K is the number of optimization targets, w k f is the weight of the k-th objective. k (x) is the normalized objective function for the k-th objective, and x is the vector of parameters to be optimized.
[0035] 2. SPICE netlist generation module 220.
[0036] The SPICE netlist generation module 220 is responsible for automatically converting Python class instances into standard SPICE netlist files. Its workflow is as follows: First, iterate through all device instances declared in the circuit Python class instance, collecting device type, parameters, and port connection information. Second, iterate through all network nodes to build a complete network connection table. Then, following SPICE syntax rules, generate the netlist header comments, sub-circuit definition statements, device instantiation statements, and closing statements in sequence. Finally, output a standard-format SPICE netlist file.
[0037] During the generation process, the SPICE netlist generation module 220 executes the following format conversion rules: MOSFET devices are mapped to M statement lines, in the format "Mxxx drain gate source body model W=w L=l M=m"; resistors are mapped to R statement lines; capacitors are mapped to C statement lines; and inductors are mapped to L statement lines. Network node names directly use the Net names defined in the Python class. The generation process guarantees determinism, meaning that the same Python class instance will generate identical SPICE netlists multiple times.
[0038] It should be noted that the generated SPICE netlist only contains connectivity relationships and device parameters, and does not include device roles, matching constraints, symmetry constraints, masking constraints, layout hints, and optimization objectives. This information exists only in the Python class, the sole true source of information, reflecting the essential nature of the SPICE netlist as a derivative product.
[0039] 3. Schematic generation module 230.
[0040] The schematic generation module 230 is responsible for automatically generating circuit schematics based on Python class instances. Unlike traditional manual schematic drawing, the generation of schematics in this application is fully automated and utilizes the rich semantic information in Python classes to achieve intelligent layout.
[0041] The workflow of the schematic generation module 230 is as follows: First, read the device role label information from the Python class instance and determine its logical position in the schematic based on the device role. The specific rules are as follows: differential input transistors labeled "input_pair" are placed in the center of the circuit; load transistors labeled "load" are placed above the circuit (power supply side); tail current sources labeled "tail_current" are placed below the circuit (ground side); and cascode transistors labeled "cascode" are placed above the corresponding main transistor.
[0042] Secondly, read the symmetry constraint information to ensure that symmetrical devices are also symmetrically arranged in the schematic diagram, thereby enhancing the readability of the schematic diagram.
[0043] Finally, the connections are automatically drawn based on the network relationships to complete the generation of the full schematic diagram.
[0044] 4. Verification module 240.
[0045] The verification module 240 utilizes the structured semantic information of Python classes to perform multi-level automated verification of the circuit description. Because Python classes provide richer structured information than SPICE netlists, they enable in-depth verification that SPICE netlists cannot support.
[0046] The verification module 240 performs the following verification checks: (1) Connection integrity verification: Check whether all device ports are connected to network nodes, and detect whether there are dangling ports (unconnected device ports) and isolated nodes (network nodes connected to only one device port). Assume there are N devices in the circuit, and each device has p... i If there are [number] ports, then the total number of ports that need to be verified is [number]. The verification condition is that each port is connected to at least one network node, and each network node is connected to at least two device ports.
[0047] (2) Electrical rule check: detect common electrical errors such as power supply short circuit (VDD directly connected to GND), signal floating (output port not connected to load) and gate short circuit (MOSFET gate directly connected to power supply or ground).
[0048] (3) Constraint consistency verification: Check whether there are contradictions in the declared constraints. For example, check whether the same device is declared as a member of two different matching groups at the same time, or whether the symmetry constraint contradicts the placement position in the layout hint.
[0049] (4) Role Consistency Verification: Check whether the role label of the device is consistent with its actual connection relationship in the circuit. For example, two transistors labeled "input_pair" should have the same gate signal type (differential input), and the source of the transistor labeled "tail_current" should be connected to the power rail.
[0050] 5. Information transmission module 250.
[0051] The information transmission module 250 is a bridge connecting the front-end design and the back-end implementation, such as... Figure 2 As shown, this module is responsible for seamlessly transferring all seven types of design information carried in the Python class—connection relationships, device roles, matching constraints, symmetry constraints, shielding constraints, layout hints, and optimization goals—to the downstream design stage.
[0052] In the traditional design process, the information transfer chain from front-end to back-end is as follows: the designer draws the schematic diagram, exports the SPICE netlist, and the SPICE netlist is passed to the simulation engine and layout engineer. In this process, only the connection relationships are preserved, while the other six types of information must be transmitted through unstructured methods such as design documents and verbal communication, resulting in an information loss rate as high as 6 / 7.
[0053] In the information transmission method of this application, the information transmission module 250 provides a standardized information query interface, allowing downstream tools to directly query any type of information in Python class instances. Specifically: the simulation engine can query connection relationships and optimization objectives for automatically configuring simulation and optimization processes; the layout tool can query matching constraints, symmetry constraints, masking constraints, and layout hints for automated layout planning and placement / routing; and the design review tool can query device role information for automated design rule checks.
[0054] The information transmission module 250 also supports incremental updates of information. When a piece of information in the Python class is modified, the module automatically notifies all downstream processes to update accordingly, ensuring real-time consistency of information throughout the entire process.
[0055] The technical solution of this application will be further described below with reference to specific embodiments.
[0056] Example 1: Python Class Representation of Differential Pair Circuits Taking the most basic differential pair circuit as an example, this application illustrates the Python class intermediate representation method.
[0057] First, a differential pair circuit class, DifferentialPair, is created by inheriting from the circuit base class CircuitBase. Within this class, five MOSFET device instances are declared: two PMOS load transistors, M1 and M2, labeled "load"; two NMOS differential input transistors, M3 and M4, labeled "input_pair"; and one NMOS tail current source transistor, M5, labeled "tail_current".
[0058] Next, define the network connections. Create the input positive terminal network inp, the input negative terminal network inn, the output positive terminal network outp, the output negative terminal network outn, the power supply network vdd, the ground network gnd, and the tail node network tail. Connect the gate of M3 to inp, the gate of M4 to inn, the drains of M1 and M3 to outn, the drains of M2 and M4 to outp, the sources of M1 and M2 to vdd, the gates of M1 and M2 to each other (diode connection or bias), the sources of M3 and M4 to tail, the drain of M5 to tail, and the source of M5 to gnd.
[0059] Next, declare the design constraints. Add matching constraints: M3 and M4 must match strictly, with a matching precision of... ≤0.1%; M1 and M2 must be strictly matched. Add symmetry constraints: M3 and M4 are symmetrical about the circuit center axis, and M1 and M2 are symmetrical about the same central axis. Add shielding constraints: Differential input lines inp and inn need to be protected with metal shielding. Add layout hints: Differential input transistors M3 and M4 are placed in the center, load transistors M1 and M2 are placed above, and tail current source M5 is placed below. Add optimization objectives: Maximize gain, weight 0.4; Minimize input offset voltage, weight 0.3; Maximize bandwidth, weight 0.3.
[0060] After completing the above circuit definition, calling the SPICE netlist generation module 220 can automatically generate a SPICE netlist with the following structure: the sub-circuit definition line contains the port list inp, inn, outp, outn, vdd, and gnd; the device lines M1 to M5 are generated according to the SPICE syntax format of MOSFET, including the network connections of the drain, gate, source, and body ports, as well as the aspect ratio parameters.
[0061] It is important to emphasize that the automatically generated SPICE netlist mentioned above only contains information such as connection relationships and device parameters. The six types of information declared in the Python class—device roles ("load", "input_pair", "tail_current"), matching constraints (M3 and M4 matching, M1 and M2 matching), symmetry constraints, masking constraints, layout hints, and optimization objectives—are not present in the SPICE netlist. This fully demonstrates the necessity of the Python class as the sole source of true information—the SPICE netlist, as a derivative, only carries about 1 / 7 of the design information.
[0062] Example 2: Python class representation of current mirror circuit. Taking the common source cascode current mirror circuit as an example, the technical solution of this application is further illustrated.
[0063] Create a cascodedCurrentMirror class, inheriting from the CircuitBase class. Declare four NMOS device instances: base mirror transistors M1 and M2, labeled "mirror_base"; and cascoded transistors M3 and M4, labeled "cascode". M1 is the base transistor of the reference branch, M2 is the base transistor of the mirror branch, M3 is the cascoded transistor of the reference branch, and M4 is the cascoded transistor of the mirror branch.
[0064] Define the network connections: input current network iref, output current network iout, power bias network vbias, ground network gnd, and internal intermediate node networks mid1 and mid2. The drain and gate of M1 and the gate of M2 are connected to the same bias node (the diode-connected M1 provides the gate bias); the source of M1 and the source of M2 are connected to gnd; the source of M3 is connected to the intermediate node mid1 corresponding to the drain of M1; the source of M4 is connected to the intermediate node mid2 corresponding to the drain of M2; the drain of M3 is connected to iref; the drain of M4 is connected to iout; the gate of M3 and the gate of M4 are connected to vbias.
[0065] Design constraints are declared as follows: Regarding matching constraints, M1 and M2 must be strictly matched to ensure current mirror accuracy, and M3 and M4 must be strictly matched to ensure output impedance symmetry. Regarding symmetry constraints, the reference branch (M1, M3) and the mirror branch (M2, M4) are symmetrical about the central axis. Regarding layout hints, M1 and M2 are interdigitated to reduce mismatch, and M3 and M4 are also interdigitated. Regarding optimization objectives, the goals are to maximize mirror accuracy (i.e., minimize the deviation of the ratio of output current to reference current) and maximize output impedance.
[0066] The mirroring accuracy of the current mirror circuit can be described by the following mathematical relationship: Ideally, the output current I... out With reference current I ref The relationship between them satisfies I out / I ref =(W2 / L2) / (W1 / L1), where W and L are the channel width and length of the transistor, respectively. The matching constraint requires that I0 be implemented when W1 / L1 = W2 / L2. out =I ref A precise mirror image.
[0067] The SPICE netlist automatically generated by the SPICE netlist generation module 220 only contains the connection relationship and aspect ratio parameters of the four MOSFET devices. The device roles ("mirror_base" and "cascode"), matching constraints (M1 matches M2, M3 matches M4), symmetry constraints, layout hints for cross arrangement, and optimization targets for mirror accuracy and output impedance declared in the Python class are not present in the SPICE netlist.
[0068] Example 3: Comparative analysis of information transmission volume.
[0069] To quantitatively illustrate the advantages of this application in information transmission, a typical two-stage operational amplifier circuit is used as an example for comparative analysis.
[0070] This two-stage operational amplifier contains approximately 15 devices, 8 external ports, and 12 internal network nodes. In the traditional SPICE netlist method, the information that can be transmitted includes: the type and parameters of the 15 devices (approximately 15 entries), the connection relationships of the 20 ports (approximately 20 entries), totaling approximately 35 entries.
[0071] In the Python-based approach of this application, the information that can be transmitted includes: (a) approximately 35 connection relationships, identical to the SPICE netlist; (b) 15 device role labels, including differential input pairs, first-stage loads, second-stage gain transistors, tail current sources, compensation networks, etc.; (c) approximately 6 sets of matching constraints, including differential pair transistor matching, load transistor matching, current mirror matching, etc.; (d) approximately 4 symmetry constraints, including differential signal path symmetry, load symmetry, etc.; (e) approximately 3 shielding constraints, including differential input shielding, compensation network shielding, etc.; (f) approximately 15 layout hints, including the preferred location and orientation of each device; and (g) approximately 5 optimization objectives, including gain, bandwidth, phase margin, power consumption, area, etc. In total, there are approximately 83 pieces of information.
[0072] Information delivery rate comparison: The information delivery rate of the traditional SPICE netlist method is 35 / 83≈42%, while the information delivery rate of the Python-based method in this application is 83 / 83=100%, representing an increase of approximately 2.4 times (83 / 35≈). If we consider information categories, the traditional method only delivers information (connections) for 1 / 7 of the categories, while this application delivers complete information for 7 / 7 of the categories, resulting in a 7-fold increase in information category coverage.
[0073] Example 4: Specific process of automatic verification.
[0074] Taking the differential pair circuit in Example 1 as an example, the automatic verification process of the verification module 240 is explained.
[0075] Step 1: Connection Integrity Verification. The verification module 240 iterates through the 20 ports (4 ports per MOSFET) of the 5 devices declared in the differential pair circuit class, checking if each port is connected to a Net instance. Simultaneously, it checks all Net instances to confirm that each network node is connected to at least two device ports. If the body port of M5 is not connected to any network node, an error is reported: "The body port of device M5 is not connected; connection to the gnd network is recommended."
[0076] Step 2: Electrical Rule Check. The verification module 240 uses a graph traversal algorithm to detect the existence of a direct short-circuit path from VDD to GND. It also checks for direct connections (potentially dangerous connections that could lead to gate oxide breakdown) to the gate ports of all MOSFETs.
[0077] Step 3: Constraint Consistency Verification. The verification module 240 checks whether the matching constraints of M3 and M4 and the matching constraints of M1 and M2 are consistent with the symmetry constraints. For example, if the symmetry constraints require M3 and M4 to be symmetric but the matching constraints do not include M3 and M4, a warning is displayed: "M3 and M4 have declared symmetry constraints but have not declared matching constraints. It is recommended to add matching constraints at the same time."
[0078] Step 4: Role Consistency Verification. Verification module 240 checks whether M3 and M4, labeled "input_pair", actually receive the differential input signal (i.e., their gates are connected to different input networks). It also checks whether the drain of M5, labeled "tail_current", is connected to the common source node of the differential pair.
[0079] Through the above four-step automatic verification, the verification module 240 can detect potential design errors at the circuit description stage, avoiding these errors from being discovered only at the simulation and layout stages, thus significantly saving design and debugging time.
[0080] Example 5: YAML / JSON structured representation of a five-tube OTA circuit.
[0081] In addition to directly describing the circuit using Python class code, this implementation also supports carrying the same seven types of design information through structured data files such as YAML or JSON. After the Python class reads and parses the file, it is instantiated into a circuit object in memory, thus achieving a unique source of real information. The following uses a five-tube OTA circuit as an example to illustrate the organization of this data format.
[0082] (a) YAML format example.
[0083] Taking YAML format as an example, design information is organized into the following fields: The ports field declares the name, direction, signal type, typical range, and layout orientation of each port.
[0084] The parameters field defines the design parameters that can be optimized, including the parameter name, typical value, unit, value range, and whether it can be optimized.
[0085] The devices field instantiates each device, specifies its type, model, and connection relationships, and marks its functional role through the role field.
[0086] The matching_groups field defines the matching groups, including the group name, device list, shared parameters, matching type, and layout style.
[0087] The signal_flow field divides the signal processing stages and describes the input stage, load stage, bias stage, and their input / output networks.
[0088] The `layout_hints` field specifies the overall layout style, such as the signal flow direction from left to right and the axis of symmetry.
[0089] (ii) Explanation of JSON format equivalence.
[0090] This implementation also supports JSON format, whose content is completely equivalent to the YAML described above, differing only in syntax. The JSON file contains the same fields such as ports, parameters, devices, matching_groups, signal_flow, and layout_hints, and may additionally include a blocks field to group devices by functional blocks, facilitating identification by layout tools. Designers can choose between YAML or JSON according to their preference. This implementation does not limit the specific data format; as long as it can carry the above seven types of design information and can be parsed by Python, it falls within the scope of protection of this application.
[0091] This application establishes a novel intermediate circuit representation paradigm using Python classes as the sole source of real information through the aforementioned architecture. It downgrades SPICE netlists and schematics to automatically generated derivatives, achieving complete carrying and lossless transmission of design information throughout the entire process. Compared to traditional SPICE netlist methods, this application increases information category coverage from 1 / 7 to 7 / 7, eliminating the problem of information fragmentation between the front-end and back-end. Furthermore, it achieves deep automated verification capabilities through structured Python class semantic information, laying a solid information foundation for the full-process automation of analog integrated circuit design.
[0092] The technical scope of this application is not limited to the contents of the above specification. Those skilled in the art can make various modifications and variations to the above embodiments without departing from the technical concept of this application, and all such modifications and variations should fall within the scope of this application.
Claims
1. A circuit intermediate representation method based on Python classes, characterized in that, Includes the following steps: S1: Create a Python class for the target circuit by inheriting a predefined circuit base class. In the Python class, declare the circuit connection relationship in an object-oriented manner, and declare at least one design information among device roles, matching constraints, symmetry constraints, masking constraints, layout hints, and optimization targets. Use the Python class as the only real information source to carry the design information. S2: Extract the circuit connection relationship from the unique real information source, perform deterministic mapping according to SPICE syntax rules, and generate a standard format SPICE netlist file as a derivative product; S3: Extract the circuit connection relationship, the device role, and the layout hints from the unique real information source, and generate a circuit schematic as a derivative product; S4: Automated verification of the circuit is performed using the structured semantics of the design information in the unique real information source; S5: Through a standardized information query interface, the design information carried in the unique real information source is transmitted to the downstream design stage without loss.
2. The method according to claim 1, characterized in that, In S1, the device role is used to describe the functional role of the device in the circuit, including input_pair, load, tail_current, cascode, and mirror_base, which are used to represent differential input pair transistors, load transistors, tail current source transistors, cascode transistors, and mirror base transistors, respectively.
3. The method according to claim 1, characterized in that, In step S1, the circuit base class automatically collects the design information declared in the subclasses through a class attribute interception and collection mechanism; the mathematical expression of the matching constraint is: for matching device groups Any two devices D in i and D j ,satisfy ,in Due to differences in device parameters, This is the matching accuracy threshold.
4. The method according to claim 1, characterized in that, In step S3, when generating the circuit schematic, the extracted device roles are used to identify the circuit module type of current mirror, differential pair, or load transistor to achieve intelligent layout. The specific rules of the intelligent layout are as follows: devices marked as differential input pair transistors are placed in the center of the circuit, devices marked as load transistors are placed on the power supply side, devices marked as tail current source transistors are placed on the ground side, and devices marked as common source cascode transistors are placed above the corresponding main transistors.
5. The method according to claim 1, characterized in that, In S4, the automated verification includes connection integrity verification, electrical rule checking, constraint consistency verification, and role consistency verification; wherein, the connection integrity verification includes detecting unconnected device ports and network nodes connected to only one device port, and the electrical rule checking includes detecting power short-circuit paths and direct connections from the gate to the power rail.
6. The method according to claim 1, characterized in that, In step S1, the layout hints include preferred placement areas for devices, device orientation, and routing priorities; the symmetry constraints include symmetry axis definitions and a list of symmetrical device pairs; the circuit connection relationships are established by connecting device ports to the same network node instance; the shielding constraints include the shielded object, shielding layer type, and shielding spacing requirements; the optimization objective includes objective parameter names, objective directions, objective values, and weights to support multi-objective optimization, and its weighted objective function is: Where K is the number of optimization targets, w k f is the weight of the k-th objective. k (x) is the normalized objective function for the k-th objective, and x is the vector of parameters to be optimized.
7. The method according to claim 4, characterized in that, In step S3, a YAML file or JSON file containing layout suggestions and instructions is generated based on the identified circuit module type, so that the backend can perform layout based on the information in the YAML file or the JSON file.
8. The method according to claim 5, characterized in that, In step S4, the role consistency verification includes: detecting device pairs labeled as input_pair and verifying whether their gates are connected to different input network nodes; detecting devices labeled as tail_current and verifying whether their sources are connected to the ground network and whether their drains are connected to the common source node of the differential pair circuit; detecting devices labeled as load and verifying whether their sources are connected to the power network node; and issuing a warning or error message when the device role is found to be inconsistent with the actual network connection relationship.
9. The method according to claim 5, characterized in that, In step S4, the constraint consistency verification includes: obtaining the matching constraint and the symmetry constraint declared in the unique true information source; detecting whether there is a device group that declares the symmetry constraint but does not declare the matching constraint; if so, issuing a warning; detecting whether there is a logical conflict between the symmetric device pair defined in the symmetry constraint and the matching device group defined in the matching constraint; if there is a conflict, issuing an error message.
10. A circuit intermediate representation system based on Python classes, characterized in that, The system for executing the Python-based intermediate circuit representation method as described in any one of claims 1 to 9 includes the following modules: A Python class definition module is used to execute S1; The SPICE netlist generation module is used to execute S2; The schematic generation module is used to execute S3; The verification module is used to execute S4; The information transmission module is used to execute S5.