Code verification method and device of parameterization unit, computer device and readable storage medium

Abstract

This application relates to a method, apparatus, computer device, and readable storage medium for verifying the code of a parameterized unit. The method involves: acquiring requirement information for writing the parameterized unit; parsing the constraint keywords in the requirement information to determine a layout constraint diagram corresponding to the requirement information; wherein the layout constraint diagram represents the topological relationships and geometric constraints of the components required by at least one functional module corresponding to the requirement information; acquiring the code to be verified and its corresponding physical layout; verifying the consistency of the layout constraints in the layout constraint diagram and the physical layout, generating a consistency verification result; and automatically correcting the code to be verified based on the consistency verification result to obtain the target code that passes the geometric consistency verification. This solves the problem of the disconnect between geometric constraints and code logic in parameterized unit development, enabling automatic verification and correction of parameterized unit code, and significantly improving development efficiency.

Description

Technical Field

[0001] This application relates to the field of integrated circuit design technology, and in particular to a method, apparatus, computer device, and readable storage medium for verifying the code of a parameterized unit. Background Technology

[0002] As semiconductor processes evolve towards advanced nodes, chip design complexity and cost continue to rise. Parameterized cells, as program scripts that dynamically generate compliant physical layouts based on preset parameters, are becoming increasingly crucial in integrated circuit design automation. Parameterized cells achieve layout reuse through abstract code logic, but their development process has long been limited by the lack of mapping between code variables and physical geometric locations. Current industrial practices generally employ manual debugging, requiring engineers to repeatedly perform cyclical operations of code editing, layout instantiation, verification, and correction.

[0003] In this process, when geometric violations occur in the physical layout, only the error coordinates can be obtained, but the code logic segment causing the problem cannot be automatically traced. This fragmented feedback mechanism forces engineers to rely on subjective experience to deduce the root cause of the error, resulting in lengthy and inefficient debugging cycles. At the same time, human intervention is prone to introducing new logical loopholes due to cognitive biases, especially when dealing with complex scenarios such as adding guard rings or adjusting hierarchical structures, making it difficult to guarantee layout quality. Although large language model technology has been attempted to be applied to code generation, its text processing nature determines that it lacks the ability to perceive the geometric spatial relationships of the layout and cannot parse physical rules such as component containment relationships or minimum spacing constraints.

[0004] While the generated code may be syntactically correct, it often leads to layout overlaps or design rule conflicts, and the model cannot make precise corrections based on geometric feedback. These shortcomings collectively cause a severe disconnect between geometric constraints and code logic in parametric cell development, hindering the design automation process. Summary of the Invention

[0005] Therefore, it is necessary to provide a method, apparatus, computer device, and readable storage medium for verifying parameterized unit code to address the aforementioned technical problems. This method can automatically verify and correct parameterized unit code, significantly improving development efficiency and layout quality.

[0006] Firstly, this application provides a code verification method for parameterized units, the method comprising:

[0007] Obtain the requirements for writing parameterized units;

[0008] The constraint keywords in the requirement information are parsed for layout constraints to determine the layout constraint diagram corresponding to the requirement information; wherein, the layout constraint diagram is used to represent the topological relationship and geometric rule constraints of the components required by at least one functional module corresponding to the requirement information.

[0009] Obtain the edit code to be verified and its corresponding physical layout; wherein, the edit code to be verified is the edit code determined according to the requirements information, and the physical layout is the layout diagram obtained by instantiating the edit code to be verified;

[0010] Verify the consistency of layout constraints in the layout constraint diagram and physical layout, and generate consistency verification results.

[0011] Based on the consistency check results, the code to be checked and edited is automatically corrected to obtain the target edit code that passes the geometric consistency check.

[0012] In one embodiment, the step of parsing the constraint keywords in the requirement information to determine the layout constraint graph corresponding to the requirement information includes:

[0013] Semantic analysis is performed on the requirement information to identify the target component, reference component, spatial constraint relationship and geometric rule value between the target component and the reference component corresponding to at least one functional module described in the requirement information.

[0014] Based on the target component, reference component, and spatial constraints, construct a layout constraint graph with the target component and reference component as vertices and the spatial constraints as edges;

[0015] Set corresponding geometric rule values ​​for each edge in the spatial constraint relationship to obtain the layout constraint diagram.

[0016] In one embodiment, the steps of obtaining the code to be verified and the corresponding physical layout include:

[0017] Obtain the edit code to be verified corresponding to the requirement information; wherein, the edit code to be verified is the edit code obtained after semantic analysis and functional reasoning of the requirement information;

[0018] The code to be verified and edited is instantiated and its coordinates are extracted to determine the geometric coordinates of each component required by at least one functional module corresponding to the requirement information.

[0019] Based on the geometric coordinates of each component, the corresponding physical layout is determined.

[0020] In one embodiment, the step of performing layout instantiation and coordinate extraction processing on the code to be verified and determined to obtain the geometric coordinate information of each component required by at least one functional module corresponding to the requirement information includes:

[0021] The layout generation engine is invoked to execute the code to be verified and edited, generating layout data.

[0022] Traverse the layout data and extract the minimum and maximum coordinates of the bounding box of each functional module involved in the layout constraint diagram in the X and Y directions to obtain the geometric coordinate information of each functional module.

[0023] In one embodiment, the step of performing a layout constraint consistency check on the geometric layout of the layout constraint diagram and the physical layout, and generating a consistency check result, includes:

[0024] Traverse every edge in the layout constraint graph;

[0025] Based on the constraint type of the target edge, the corresponding geometric relationship calculation function is called, and the geometric relationship value is calculated based on the geometric coordinate information of each functional module in the physical layout; where the target edge is any edge in the layout constraint diagram.

[0026] Compare the geometric relationship values ​​with the geometric rule values ​​recorded for the target edge in the layout constraint diagram;

[0027] If the geometric relation value is less than the geometric rule value, the target edge is determined to be a geometric violation, and the corresponding consistency verification result is obtained.

[0028] In one embodiment, the target edge includes a target component and a reference component, and the constraint type of the spatial constraint relationship between the target component and the reference component includes: a first constraint type and a second constraint type; wherein, the first constraint type is used to represent a constraint relationship of complete enclosure, and the second constraint type is used to represent a constraint relationship of non-overlapping orientation;

[0029] Based on the constraint type of the target edge, the corresponding geometric relation calculation function is called, and the geometric relation values ​​are calculated based on the geometric coordinate information of each functional module in the physical layout. The steps include:

[0030] If the constraint type of the target edge is the first constraint type, then calculate the encirclement distance of the reference component boundary to the target component boundary in different preset directions, and take the minimum value of the encirclement distance as the geometric relationship value.

[0031] If the constraint type of the target edge is the second constraint type, the actual spatial distance between the boundaries of the two components is calculated based on the coordinates of the reference component and the target component, and the actual spatial distance is used as the geometric relationship value.

[0032] In one embodiment, the step of automatically correcting the edited code to be verified based on the consistency verification result to obtain the target edited code that passes the geometric rule verification includes:

[0033] The target functional module, violation type, and numerical difference are analyzed from the consistency verification results; the target functional module is the functional module that fails the consistency verification.

[0034] Calculate the displacement correction amount required to adjust the target functional module to a compliant position based on the type of violation and the numerical difference;

[0035] Based on the relationship between components and code variables in the layout constraint diagram, the target code segment of the target functional module is located and generated.

[0036] Based on the displacement correction, the target code segment is modified at the semantic level by adjusting parameters or inserting displacement instructions to obtain the target edit code; the target edit code is the edit code that has passed geometric verification.

[0037] Secondly, this application also provides a code verification device for parameterized units, comprising:

[0038] The acquisition module is used to acquire the requirements for writing parameterized units;

[0039] The first determining module is used to perform layout constraint parsing on the constraint keywords in the requirement information to determine the layout constraint diagram corresponding to the requirement information; wherein, the layout constraint diagram is used to represent the topological relationship and geometric rule constraints of the components required by at least one functional module corresponding to the requirement information.

[0040] The acquisition module is used to acquire the code to be verified and the corresponding physical layout; wherein, the code to be verified is the code to be verified determined according to the requirements information, and the physical layout is the layout diagram obtained by instantiating the code to be verified.

[0041] The verification module is used to verify the consistency of layout constraints in the layout constraint diagram and physical layout, and generate consistency verification results.

[0042] The correction module is used to automatically correct the edited code to be verified based on the consistency verification results, so as to obtain the target edited code that passes the geometric consistency verification.

[0043] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the code verification method of the parameterized unit in the first aspect.

[0044] Fourthly, this application also provides a readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the code verification method for the parameterized unit of the first aspect.

[0045] Fifthly, this application also provides a program product, including a computer program that, when executed by a processor, implements the steps of the code verification method for the parameterized unit of the first aspect.

[0046] The aforementioned method, apparatus, computer device, and readable storage medium for verifying the code of the parameterized unit involve: acquiring requirement information for writing the parameterized unit; parsing the constraint keywords in the requirement information to determine a layout constraint diagram corresponding to the requirement information; wherein the layout constraint diagram represents the topological relationships and geometric constraints of the components required by at least one functional module corresponding to the requirement information; acquiring the code to be verified and its corresponding physical layout; wherein the code to be verified is the code determined based on the requirement information, and the physical layout is the layout diagram obtained by instantiating the code to be verified; verifying the consistency of the layout constraints in the layout constraint diagram and the physical layout, generating a consistency verification result; and automatically correcting the code to be verified based on the consistency verification result to obtain the target code that passes the geometric consistency verification. This is achieved by automatically acquiring requirement information, parsing the layout constraint diagram, and verifying the physical layout. Figure 1 It ensures consistency and automatically corrects code, solving the problem of the disconnect between geometric constraints and code logic in parametric unit development. It can realize automatic verification and correction of parametric unit code, significantly improving development efficiency and layout quality. Attached Figure Description

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

[0048] Figure 1 This is a first flowchart illustrating a code verification method for a parameterized unit in one embodiment.

[0049] Figure 2 This is a second flowchart illustrating the code verification method for a parameterized unit in one embodiment;

[0050] Figure 3 This is a schematic diagram of a specific scenario in the second process of the code verification method for a parameterized unit in one embodiment.

[0051] Figure 4 This is a schematic diagram of the third process of the code verification method for a parameterized unit in one embodiment;

[0052] Figure 5 This is a schematic diagram of a specific scenario in the third process of the code verification method for a parameterized unit in one embodiment;

[0053] Figure 6 This is a schematic diagram of another specific scenario in the third process of the code verification method for a parameterized unit in one embodiment;

[0054] Figure 7 This is a schematic diagram of the fourth process of the code verification method for a parameterized unit in one embodiment;

[0055] Figure 8 This is a schematic diagram of a specific scenario in the fourth process of the code verification method for a parameterized unit in one embodiment;

[0056] Figure 9 This is a schematic diagram of the fifth step of the code verification method for a parameterized unit in one embodiment;

[0057] Figure 10 This is a schematic diagram of a specific scenario in the fifth process of the code verification method for a parameterized unit in one embodiment;

[0058] Figure 11 This is a schematic diagram of the code verification device of a parameterized unit in one embodiment;

[0059] Figure 12 This is a schematic diagram of the internal structure of a computer device in one embodiment. Detailed Implementation

[0060] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0061] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0062] In the field of semiconductor electronic design automation (EDA), during the development of parametric cells, the code is abstract textual logic, while the resulting layout is a concrete two-dimensional geometric figure. Traditional development methods lack an intermediate layer that connects the geometric space and the code logic. This disconnect between the abstract textual logic of the geometric instance and the concrete two-dimensional geometry makes it impossible to automatically establish a precise mapping between geometric errors and code logic during verification and correction. Consequently, engineers must rely on manual experience for reverse engineering, resulting in inefficient debugging. Furthermore, when handling complex modifications to parametric logic, human error can easily introduce new logical flaws or geometric errors, impacting the reliability of the layout design and the development schedule.

[0063] For example, when adding a guard ring structure to a transistor parameterization cell in an advanced process node, engineers modified the code to add a new geometric level. Furthermore, the physical layout generated after layout instantiation was reported by a design rule checking tool as having a spacing violation between the guard ring and the source diffusion region. However, due to the lack of an automated localization mechanism, engineers could not determine whether the violation was caused by an error in the gate length parameter calculation or an improper coordinate offset instruction, and could only try to locate the problem by repeatedly running verification tools and manually checking the code logic. In this process, multiple correction attempts not only failed to resolve the original violation but also introduced additional geometric overlap errors, leading to a decrease in layout quality and an extension of the development cycle.

[0064] If the aforementioned problems are not addressed, the development of parameterized cells will remain confined to inefficient manual debugging cycles, failing to meet the increasingly complex layout design requirements of advanced semiconductor process nodes. Consequently, the high incidence of human error will result in layouts with potential design rule violations, potentially leading to functional failures during subsequent physical verification stages, thus increasing the overall cost and time risk of chip development. This situation severely restricts the potential of electronic design automation tools to improve design reusability and automation levels.

[0065] It's important to note that a parameterized cell, often referred to as a PCell, is a program script that dynamically generates a physical layout conforming to design rules based on preset parameters (such as transistor width, length, gate index, etc.). Parameterized cells are widely used in integrated circuit design to automate layout design and improve reusability.

[0066] Based on this, this embodiment proposes a code verification method for parameterized units, such as... Figure 1 As shown, the method includes steps 11 to 15, wherein:

[0067] Step 11: Obtain the requirements for writing parameterized units.

[0068] Among them, requirement information can refer to the input data or specifications on which the parameterized unit is based when writing it. Requirement information usually includes descriptions of the required functions, performance, layout, and geometric constraints, and is the standard and requirement for code development and design of the parameterized unit.

[0069] As one implementation method, requirement information can be provided in various forms. For example, it can be manually entered by the user using a text editor or filled in using a predefined template. In another implementation method, requirement information can also be obtained by manually reading and extracting from design specification documents. This requirement information forms the basis of parametric unit design and can include requirements for functionality, performance, and layout.

[0070] Step 12: Perform layout constraint parsing on the constraint keywords in the requirement information to determine the layout constraint diagram corresponding to the requirement information.

[0071] The layout constraint diagram is used to represent the topological relationships and geometric rules constraints of the components required by at least one functional module corresponding to the requirement information.

[0072] Here, constraint keywords in the requirements information can be specific words or phrases used to describe layout constraint relationships. Constraint keywords can be used to identify and extract geometric constraints, such as keywords like "contains", "spacing", and "alignment".

[0073] It should be noted that parsing the layout constraints of the constraint keywords in the requirement information can analyze and process the constraint keywords in the requirement information, and extract structured layout constraint information from the unstructured requirement description.

[0074] It should also be noted that layout constraint diagrams can be used to represent the graphical structure of topological relationships and geometric constraints between functional modules and their components. Layout constraint diagrams typically use components as nodes, spatial constraint relationships between components as edges, and set corresponding geometric rule values ​​for each edge.

[0075] It is understandable that a functional module refers to an independent unit that implements a specific function or logic in a parameterized unit. A parameterized unit can be composed of one or more functional modules, and each functional module can contain multiple components. Each component is designed to realize the basic geometric entity corresponding to the functional module, such as transistors, resistors, capacitors, metal interconnects, etc. Each component has a specific geometric shape and position in the physical layout.

[0076] Furthermore, topological relationships can be the relative spatial positions of functional modules or components, such as inclusion, adjacency, overlap, alignment, etc. Topological relationships can be used to describe how components are arranged in the layout. Geometric constraints can be specific numerical restrictions set on the geometric attributes of functional modules or components, such as size, spacing, and relative position. Geometric constraints can be used to ensure that the layout design conforms to the design rules of semiconductor processes.

[0077] One implementation method is rule-based matching, which uses pre-defined regular expressions or keyword lists to identify words describing spatial relationships from the requirement information, such as "inside," "adjacent to," and "at least at a distance from." The identified keywords and their associated values ​​are then used to construct a preliminary constraint list.

[0078] In another implementation, manual annotation can be used, where designers manually identify constraint keywords in the requirements information and convert them into structured constraint expressions.

[0079] Step 13: Obtain the code to be verified and edited, along with the corresponding physical layout.

[0080] Among them, the code to be verified is the code to be verified determined according to the requirements information, and the physical layout is the layout diagram obtained by instantiating the code to be verified.

[0081] Here, the code to be verified can be parameterized unit code initially written or modified based on requirements. After instantiation, the code to be verified can generate a corresponding physical layout. The physical layout can be the actual geometric layout diagram generated on a two-dimensional plane after the code to be verified is compiled and instantiated. The physical layout diagram can be used to visually display the shape, size, and position of each component.

[0082] It should be noted that the instantiation of the code to be verified can be the process of converting the abstract parameterized unit code into a specific physical layout. During the instantiation process, specific values ​​can be assigned to the parameters in the parameterized unit, and the corresponding geometric figures can be generated to obtain the corresponding physical layout.

[0083] It should also be noted that the code to be verified can be editable code determined based on the requirements information, and the physical layout is the layout diagram obtained by instantiating the editable code to be verified. In one implementation, the editable code to be verified can be PCell code manually written by engineers based on the requirements information. This code is then input into the layout generation tool, and by executing the code, the corresponding physical layout data is generated. In another implementation, the editable code to be verified can be an existing code template retrieved from the code library that partially matches the requirements information. This template is initially modified to form the editable code to be verified. This code is sent to the layout renderer to visually represent its geometric layout, thereby obtaining the physical layout.

[0084] Step 14: Verify the consistency of layout constraints in the layout constraint diagram and physical layout diagram, and generate consistency verification results.

[0085] Specifically, a one-to-one comparison method can be used to compare each geometric constraint defined in the layout constraint diagram with the actual geometric position and size of the corresponding component in the physical layout.

[0086] In one implementation, if the layout constraint diagram requires the spacing between two components to be greater than a certain value, the actual spacing between the two components in the physical layout is calculated and the values ​​are compared.

[0087] In another implementation, a geometry query library can be used to query specific geometric relationships between components in the physical layout by calling preset geometry query functions, such as whether they overlap or contain each other, and then the query results are compared with the expected values ​​in the layout constraint diagram.

[0088] Step 15: Based on the consistency check results, automatically correct the edit code to be checked to obtain the target edit code that passes the geometric consistency check.

[0089] When the consistency check result indicates the presence of a geometric violation, the parameters or logic related to the violating component in the code to be checked can be manually modified according to the type and severity of the violation.

[0090] As one approach, if the spacing between two components is insufficient, the coordinate parameters of one of the components can be manually adjusted to meet the spacing requirements.

[0091] Another approach is to use a pre-defined rule library for corrections. When a specific type of geometric violation is detected, correction suggestions can be automatically generated based on predefined rules. These suggestions can then be selected by the user and applied to the code, resulting in the corrected target edit code.

[0092] In the code verification method for parametric units described above, this embodiment addresses the lack of geometric spatial awareness in parametric unit design by a general-purpose large language model. It constructs a layout constraint graph to visualize abstract geometric constraints and provides a consistency verification mechanism, enabling the system to perceive and quantify the deviation between the physical layout and the design intent. This geometric spatial awareness and closed-loop correction mechanism allow the generation and optimization of parametric unit code to be based on actual physical feedback, thereby overcoming the limitations of general-purpose large language models in generating physically usable parametric unit code and improving the automation level and quality of parametric unit code development.

[0093] In one exemplary embodiment, such as Figure 2 As shown, step 12 involves parsing the constraint keywords in the requirement information to determine the layout constraint diagram corresponding to the requirement information. This specifically includes steps 121 to 123, where:

[0094] Step 121: Perform semantic analysis on the requirement information to identify the target component, reference component, spatial constraint relationship and geometric rule value between the target component and the reference component corresponding to at least one functional module described in the requirement information.

[0095] Here, natural language processing techniques can be used to analyze the demand information, including lexical analysis, syntactic analysis, and semantic role labeling, to identify the functional modules, component names, and verbs or phrases describing the relationships between them mentioned in the text.

[0096] As another implementation method, a set of rule bases and keyword dictionaries can be preset. By using pattern matching and rule reasoning, specific patterns in the requirement information can be identified, thereby extracting the required information to identify the target component, reference component, spatial constraint relationship and geometric rule value between the target component and reference component corresponding to at least one functional module described in the requirement information. This is the direct output of semantic analysis.

[0097] It should be noted that target components and reference components are the basic units constituting functional modules, which can be circuit elements, physical regions, or logic blocks, etc. Spatial constraints describe the relative positions or topological relationships of these components in the physical layout, such as "encirclement," "adjacent," "alignment," and "spacing." Furthermore, geometric rule values ​​can be quantitative descriptions of these spatial constraints, such as specific distance values, angle values, or scale values. Specifically, geometric rule values ​​can be identified based on a predefined component library and constraint type library, mapping entities identified in the text to preset component types, mapping words describing relationships to preset spatial constraint types, and extracting relevant numerical values ​​to obtain geometric rule values.

[0098] Step 122: Based on the target component, reference component, and spatial constraint relationship, construct a layout constraint graph with the target component and reference component as vertices and the spatial constraint relationship as edges.

[0099] The layout constraint graph can be a graph data structure. In the layout constraint graph, the vertices can represent the components in the functional module, and the edges can represent the spatial constraint relationships between the components.

[0100] Specifically, the construction process can use adjacency matrices or adjacency lists to represent the graph structure. For example, when a spatial constraint relationship is identified between component A and component B, two vertices A and B can be created in the graph, and an edge can be added between them to represent the constraint.

[0101] Step 123: Set the corresponding geometric rule value for each edge in the spatial constraint relationship to obtain the layout constraint diagram.

[0102] Here, each edge in the layout constraint graph not only represents the spatial constraint relationship between components, but also needs to carry the specific quantitative information of that constraint, i.e., the geometric rule value. For example, if an edge represents a "spacing" constraint, then a value will be attached to that edge, indicating the minimum or maximum spacing.

[0103] As an example, a layout constraint graph (LCG) can be defined as a directed property graph of four tuples. ,in:

[0104] The vertex set V consists of all vertices in the graph, where each vertex v∈V represents an independent physical component or geometric entity within a parameterized unit (PCell). The physical component can be a single polygon or an array of polygons; for example, in the PCell of a MIM capacitor, a vertex can represent the top metal plate, the bottom metal plate, or an array of vias. In computer memory, each vertex is associated with a unique identifier for that component and its corresponding PCell source code variable name. This explicit association between each vertex and component provides a crucial mapping for back-locating from a geometric instance to the specific line of code that generated it.

[0105] The edge set E consists of all directed edges in the graph. Each directed edge (u,v)∈E represents a direct spatial constraint relationship from the source component u to the target component v. The directionality of each edge not only represents the connection relationship, but can also be used to represent the logical direction of design rule checks.

[0106] The relation type set Σ defines a type vocabulary for edge E, used to formally describe the spatial relative positions between components. In this embodiment, Σ contains at least the following six basic spatial relation types:

[0107] (1) CONTAINS: indicates the geometric boundary of component u, where component u completely encloses component v.

[0108] (2) OVERLAPS: indicates the spatial overlap between component u and component v, where component u and component v have an intersection.

[0109] (3) LEFT_OF: indicates that component u is located on the negative X-axis side of component v (on the left side), and the two do not overlap.

[0110] (4) RIGHT_OF: indicates that component u is located on the positive X-axis side of component v (on the right side), and the two do not overlap.

[0111] (5) ABOVE: indicates that component u is located on the positive Y-axis side of component v (above), and the two do not overlap.

[0112] (6) BELOW: indicates that component u is located on the negative Y-axis side of component v (below), and the two do not overlap.

[0113] The geometric rule value δ assigns a key numerical attribute, or design rule value, to each edge in the graph. These geometric rule values ​​are derived directly from the physical verification rule file in the process design suite and represent mandatory physical manufacturing constraints. For example, for CONTAINS type edges, the attribute value represents the minimum enclosing distance; for directional edges such as ABOVE and LEFT_OF, the attribute value represents the minimum spacing requirement.

[0114] As one implementation method, please refer to the example. Figure 3 , Figure 3 This is a schematic diagram of a specific scenario in this embodiment. Specifically, after determining the layout constraint diagram, based on the target components rect_m4_l_1, rect_m4_l_2, rect_m4_r and the reference component rect_m3 in the layout constraint diagram, and the spatial constraint relationships between the components, the layout constraint diagram maps the space and design rules to determine the target components rect_m4_l_1, rect_m4_l_2, rect_m4_r and the reference component rect_m3 corresponding to the required functional module, as well as the corresponding geometric layout (spatial constraint relationships) of these components and the corresponding PCell code. Specifically, the layout constraint diagram can represent the layout constraint relationships between components. rect_m3 contains rect_m4_l_1, rect_m4_l_2 and rect_m4_r. rect_m4_l_1 is above rect_m4_l_2, rect_m4_l_1 is to the left of rect_m4_r, and rect_m4_r is to the right of rect_m4_l_1. After determining the layout constraints between components, the corresponding geometric layout and PCell code can be determined. Here, the PCell code can be obtained by mapping from the layout constraint diagram.

[0115] In this way, raw, potentially ambiguous, or unstructured requirement information is transformed into a clearly structured and complete layout constraint diagram. This transformation process, through semantic analysis, component and constraint identification, graph construction, and attribute assignment, ensures an accurate mapping from requirements to design constraints. This allows subsequent layout constraint consistency verification to be performed based on a precise and unambiguous reference standard, significantly improving the accuracy and reliability of the verification. Simultaneously, this automated parsing and graph construction process reduces errors that might be introduced by manual understanding and transformation of requirement information, and provides a solid foundation for subsequent automatic correction, thereby improving the efficiency and automation level of the entire parametric unit code verification method.

[0116] Based on this, in an exemplary embodiment, such as Figure 4 As shown, step 13 involves obtaining the code to be verified and the corresponding physical layout, specifically including steps 131 to 133, where:

[0117] Step 131: Obtain the code to be verified and edited corresponding to the requirement information.

[0118] Among them, the edit code to be verified is the edit code obtained after semantic analysis and functional reasoning of the requirement information.

[0119] Specifically, natural language processing technology can be used to parse the requirement information into text, extract key entities and relationships, and then use expert systems or rule-based reasoning engines to map these entities and relationships onto predefined code templates or functional modules, thereby generating preliminary edit code.

[0120] In addition, machine learning models, such as deep learning models, can be used to train a large amount of requirement information and corresponding code, enabling them to learn from new requirement information and predict the corresponding code structure.

[0121] Step 132: Perform layout instantiation and coordinate extraction processing on the code to be verified and edited to determine the geometric coordinate information of each component required by at least one functional module corresponding to the requirement information.

[0122] It should be noted that layout instantiation refers to converting the logic circuits or layout instructions described in the edit code into actual physical layout data using a specific layout generation tool or engine. Coordinate extraction processing can parse the coordinate values ​​of the bounding boxes, center points, or other geometric features of each component from the generated physical layout data.

[0123] As a specific implementation method, the layout generation engine in a professional integrated circuit layout design automation tool can be called to compile and render the code to be verified into graphical data. Then, using the API or script interface provided by the tool, all components in the layout can be traversed to extract their minimum / maximum coordinate values ​​on the X and Y axes.

[0124] In addition, a custom parser can be developed to directly read the layout data file, parse out the geometric elements on each layer according to the file format specifications, and calculate the overall bounding box of the geometric elements contained in each functional module, thereby obtaining their geometric coordinate information.

[0125] In one specific implementation, the steps of performing layout instantiation and coordinate extraction processing on the code to be verified and determined to identify the geometric coordinate information of each component required by at least one functional module corresponding to the requirement information include:

[0126] (1) Call the layout generation engine to execute the code to be verified and edited, and generate layout data;

[0127] A layout generation engine is a software tool or module that can convert high-level circuit descriptions into geometric data of physical layouts. This engine can be a standalone electronic design automation tool or a custom script or library integrated into a design environment.

[0128] Executing the edited code to be verified refers to the layout generation engine performing calculations and rendering based on the parameters, logic, and geometric rules defined in the edited code, thereby generating the corresponding physical layout. This process simulates the layout generation steps before actual chip manufacturing, ensuring that the generated layout data is the true physical representation of the edited code, and that the layout data is the digital representation of the physical layout obtained after executing the edited code.

[0129] It should be noted that layout data can include all the geometries that make up the circuit, layer information, and their precise locations and dimensions on a two-dimensional plane.

[0130] (2) Traverse the layout data and extract the minimum and maximum coordinates of the bounding box of each functional module involved in the layout constraint diagram in the X and Y directions to obtain the geometric coordinate information of each functional module.

[0131] Specifically, in order to identify and locate geometric entities related to functional modules in the layout, various methods can be used, such as tree structure traversal, planar scanning algorithms, or spatial index-based queries.

[0132] It should be noted that the minimum and maximum coordinates of the bounding box in the X and Y axes of each functional module involved in the layout constraint diagram are extracted. The bounding box can be the smallest rectangular area that can completely enclose one or a set of geometries. By extracting the minimum and maximum coordinates of the bounding box, such as the lower left corner coordinates (Xmin, Ymin) and the upper right corner coordinates (Xmax, Ymax), the bounding box can be used to precisely define the area occupied by the functional module on the physical layout.

[0133] Step 132: Determine the corresponding physical layout based on the geometric coordinate information of each component.

[0134] Among them, the physical layout can be a physical representation of the code to be verified and edited.

[0135] As one implementation method, the geometric coordinate information of all components can be stored in a data structure, such as a tree structure or a hash table. This data structure can completely describe the hierarchical relationship and geometric layout of the entire layout, thus forming the corresponding physical layout.

[0136] As another implementation method, the extracted geometric coordinate information can be combined with the original layout data file and rendered using visualization tools to generate a graphical physical layout view. The physical layout can include not only the geometric positions of components, but also their shapes, layer attributes, and other information, thus forming a complete physical layout.

[0137] For example, please refer to Figure 5 , Figure 5 This is a schematic diagram of a specific scenario in this embodiment. Specifically, to construct a layout constraint diagram of the actual layout, the code to be verified and edited can be instantiated into a layout instance, generating a geometric layout instance, and the geometric position information of key components can be accurately extracted from the physical layout.

[0138] Please refer to Figure 6 , Figure 6 This is a schematic diagram of another specific scenario in this embodiment. Specifically, after constructing the layout constraint diagram of the actual layout, the layout constraints of the actual layout can be checked.

[0139] Furthermore, after determining the geometric layout instance l, the geometric layout instance can be traversed, and coordinate extraction operations can be performed for each component involved in the expected layout constraint edge set ΔE. For any component comp, four key coordinate values ​​of its geometric bounding box are extracted to uniquely determine its position and extent in the two-dimensional plane, where:

[0140] xl (x-low): Represents the minimum value of component comp in the X-axis direction, i.e., its left boundary coordinate.

[0141] xh (x-high): Represents the maximum value of component comp in the X-axis direction, i.e., its right boundary coordinate.

[0142] yl (y-low): Represents the minimum value of component comp in the Y-axis direction, i.e., its lower boundary coordinate.

[0143] yh (y-high): Represents the maximum value of the component comp in the Y-axis direction, i.e., its upper boundary coordinate.

[0144] When dealing with components with complex shapes, a unified bounding box representation can be used. If the component is a complex polygon, its minimum bounding rectangle is calculated to obtain the aforementioned coordinates; if the component is an array composed of multiple instances, the coordinates of the total bounding rectangle of the entire array are calculated. Specifically, coordinate data can be extracted from the collection layout instance l through GDSII information extraction.

[0145] All extracted coordinate data is stored in a structured manner to form the geometric coordinate information of the component `comp`, thus determining the corresponding geometric layout instance. .

[0146] Therefore, this embodiment ensures that the code to be verified is obtained based on semantic analysis and functional reasoning of the requirement information, thereby improving the accuracy and automation of code generation and reducing human error. Simultaneously, by instantiating the code to be verified into a layout and extracting its coordinates, the geometric coordinate information of each functional module can be accurately obtained, and the corresponding physical layout can be determined accordingly. This provides high-quality, high-precision input data for subsequent layout constraint consistency verification, effectively avoiding deviations in verification results caused by inaccurate input data, and significantly improving the reliability and efficiency of the parametric unit code verification method.

[0147] Based on this, in an exemplary embodiment, such as Figure 7 As shown, step 14 involves verifying the consistency of layout constraints in the layout constraint diagram and physical layout, and generating a consistency verification result. This specifically includes steps 141 to 144, where:

[0148] Step 141: Traverse each edge in the layout constraint graph.

[0149] The purpose of traversing each edge in the layout constraint graph is to systematically examine all topological relationships and geometric rule constraints defined in the layout constraint graph.

[0150] As one implementation method, depth-first search or breadth-first search algorithms can be used to traverse all edges in the graph structure.

[0151] Another approach is to directly iterate over each element in the list or array if the layout constraint graph stores its edges as a list or array.

[0152] Step 142: Based on the constraint type of the target edge, call the corresponding geometric relationship calculation function, and calculate the geometric relationship value based on the geometric coordinate information of each functional module in the physical layout.

[0153] The target edge can be a specific edge that is currently being processed during the traversal of the layout constraint graph. The target edge can represent a specific constraint relationship between two functional modules in the layout constraint graph, such as minimum spacing, alignment, or enclosure relationship.

[0154] Specifically, the appropriate computational logic can be selected and executed based on the specific nature of the constraint represented by the current target edge. Different constraint types, such as those representing distance, overlap, and alignment, require different mathematical methods to quantify their actual state in the physical layout.

[0155] One implementation approach is to maintain a mapping table that associates each constraint type with a specific geometric relationship calculation function. When the constraint type of the target edge is identified, the corresponding function is called by looking up the table.

[0156] As another implementation method, a conditional judgment structure can be used to directly branch to a predefined calculation function based on the constraint type of the target edge, and calculate the geometric relationship value based on the geometric coordinate information of each functional module in the physical layout.

[0157] It should be noted that this step uses the actual position and size information of components in the physical layout to calculate the actual measured value of the geometric relationship represented by the target edge. For example, for a constraint representing minimum spacing, this step will calculate the actual spacing between two functional modules in the physical layout.

[0158] In one specific implementation, the target edge includes a target component and a reference component, and the constraint type of the spatial constraint relationship between the target component and the reference component includes: a first constraint type and a second constraint type; wherein, the first constraint type is used to represent a constraint relationship of complete enclosure, and the second constraint type is used to represent a constraint relationship of non-overlapping orientation.

[0159] Based on the constraint type of the target edge, the corresponding geometric relation calculation function is called, and the geometric relation values ​​are calculated based on the geometric coordinate information of each functional module in the physical layout. The steps include:

[0160] (1) If the constraint type of the target edge is the first constraint type, calculate the encirclement distance of the boundary of the reference component to the boundary of the target component in different preset directions, and take the minimum value of the encirclement distance as the geometric relationship value.

[0161] (2) If the constraint type of the target edge is the second constraint type, the actual spatial distance between the two component boundaries is calculated based on the coordinates of the reference component and the target component, and the actual spatial distance is used as the geometric relationship value.

[0162] The target edge is any edge in the layout constraint graph.

[0163] Spatial constraints, in the context of parameterized unit layout, represent the limitations that different functional modules (components) must satisfy in terms of spatial location. These constraints can be categorized based on their nature and form to achieve more precise verification. The first and second constraint types are two specific classification methods used to distinguish spatial constraints of different natures. For example, the first constraint type can represent a relationship where one component completely contains another, such as a guard ring completely surrounding a core circuit module; the second constraint type can represent a relationship where two components cannot overlap and must maintain a certain distance, such as two adjacent transistors not touching each other. Besides complete enclosure and non-overlapping orientations, other constraint types can be defined, such as alignment constraints and relative position constraints.

[0164] The first constraint type represents a complete enclosure relationship, where one component completely encloses another component within its boundary in all directions. This constraint is very common in integrated circuit design, such as the enclosure of sensitive circuits by power supply loops or the enclosure of core IP modules by protective structures. This relationship can require that the minimum X-coordinate of the reference component is less than the minimum X-coordinate of the target component, and the maximum X-coordinate of the reference component is greater than the maximum X-coordinate of the target component, while similar conditions are met in the Y-axis direction; alternatively, the complete enclosure relationship can be determined by calculating the area or perimeter of the two components and combining this with the relative position of their bounding boxes.

[0165] The second constraint type represents non-overlapping orientation constraints, meaning that two components cannot overlap in space and may need to maintain a certain minimum spacing. This constraint is one of the most fundamental rules in layout design, designed to avoid problems such as short circuits and signal interference. This relationship can require that the bounding boxes of two components cannot intersect in the X and Y axes, and that the minimum distance between them must be greater than or equal to a preset spacing value; alternatively, it can be determined by calculating the distance between the geometric center points of the two components and combining it with their dimensions to determine whether there is overlap or insufficient spacing.

[0166] When the constraint type of the target edge is the first constraint type, it is necessary to calculate the enclosing distances of the reference component's boundary to the target component's boundary in different preset directions, and take the minimum enclosing distance as the geometric relation value. The enclosing distance refers to the distance between the boundary of the reference component and the boundary of the target component in a specific direction. Taking the minimum value ensures that the requirements are met even in the weakest enclosing direction. For example, the distances between the left and right boundaries of the reference and target components, the top and bottom boundaries of the reference and target components can be calculated separately. Then, the minimum value from these four distances is selected as the geometric relation value. Alternatively, the minimum distance from the boundary of the target component to the inner boundary of the reference component can be calculated. For example, for a rectangular component, the perpendicular distances from the four corner points of the target component to the boundary of the reference component can be calculated, and the minimum value is taken.

[0167] When the constraint type of the target edge is type 2, the actual spatial distance between the boundaries of the two components needs to be calculated based on the coordinates of the reference and target components, and this actual spatial distance is used as the geometric relationship value. This distance will be directly compared with the preset geometric rule value. For example, for a rectangular component, the minimum distance between the two components in the X and Y axes can be calculated. If the two components do not overlap on the X axis, the distance in the X direction is the minimum value of the larger X coordinate minus the maximum value of the smaller X coordinate; the same applies to the Y direction. Then, the minimum value of the minimum distances in the X and Y directions is taken as the actual spatial distance. Alternatively, the shortest distance between the bounding boxes of the two components in the horizontal and vertical directions can be calculated, taking into account the diagonal distance, to ensure that the true minimum spatial distance is obtained.

[0168] Step 143: Compare the geometric relationship value with the geometric rule value recorded for the target edge in the layout constraint diagram.

[0169] This process involves comparing the actual geometric relationship values ​​calculated from the physical layout with the pre-defined geometric rule values ​​in the layout constraint diagram, which serve as design standards. This is a crucial step in determining whether the physical layout conforms to design specifications. For example, if the geometric rule values ​​specify a minimum spacing of 10 units, but the calculated actual spacing is 8 units, a comparison will be made accordingly.

[0170] Step 144: If the geometric relationship value is less than the geometric rule value, the target edge is determined to be a geometric violation, and the corresponding consistency verification result is obtained.

[0171] If the geometric relation value is less than the geometric rule value, the target edge is determined to be a geometric violation. When the actual calculated geometric relation value fails to meet the geometric rule value set in the layout constraint diagram, the constraint is considered to be violated.

[0172] For example, the layout constraint consistency check can accurately compare the expected constraint (ΔE) with the actual geometric coordinates, and define the verification logic for the geometric compliance of different types of edges in the layout constraint graph.

[0173] (1) Validation for constraints:

[0174] When the edge type is CONTAINS, it can be verified whether the source component comp_1 completely surrounds the target component comp_2, and whether the actual enclosure margin meets the geometric rule value defined in the edge attribute, that is, the design rule value drc_value.

[0175] Therefore, the actual encirclement distances in four directions can be calculated:

[0176] Left bounding value: dist_left = l.comp_2.xl - l.comp_1.xl;

[0177] Right bounding value: dist_right = l.comp_1.xh - l.comp_2.xh;

[0178] Bottom bounding: dist_bottom = l.comp_2.yl - l.comp_1.yl;

[0179] Top bounding size: dist_top = l.comp_1.yh - l.comp_2.yh;

[0180] The minimum of the above four values ​​is taken as the final actual enclosure value, resulting in the geometric relationship value `real_enclosure`. Specifically:

[0181] real_enclosure = min(dist_left, dist_right, dist_bottom, dist_top).

[0182] After determining the geometric relationship value, a verification judgment can be performed. If real_enclosure < drc_value, it is judged as a violation of the inclusion design rule, and the error information will be recorded in the consistency verification result R, for example: "Component comp_1 does not adequately enclose comp_2, requirement: drc_value, actual: real_enclosure".

[0183] (2) Verification of directional spacing constraints:

[0184] When the edge type is a directional constraint (e.g., ABOVE, BELOW, LEFT_OF, RIGHT_OF), it can be verified whether the actual spacing between two components meets the minimum spacing requirement drc_value. The formula for calculating the actual spacing, depending on the specific edge type, is as follows:

[0185] ABOVE: This indicates that component comp_1 is located above component comp_2.

[0186] The formula for calculating the actual spacing between two components is: real_space = l.comp_1.yl - l.comp_2.yh, where l.comp_1.yl is the minimum value of component comp_1 in the Y-axis direction; l.comp_2.yh is the maximum value of component comp_2 in the Y-axis direction. That is, the actual spacing between the two components is the vertical distance between the bottom edge of the upper component and the top edge of the lower component.

[0187] BELOW: This indicates that component comp_1 is located below component comp_2.

[0188] The formula for calculating the actual spacing between two components is: real_space = l.comp_2.yl - l.comp_1.yh, where l.comp_2.yl is the minimum value of comp_2 in the Y-axis direction; l.comp_1.yh is the maximum value of component comp_1 in the Y-axis direction. That is, the actual spacing between the two components is the vertical distance between the bottom edge of the lower component and the top edge of the upper component.

[0189] RIGHT_OF: Indicates that component comp_1 is located to the right of component comp_2.

[0190] The formula for calculating the actual spacing between two components is real_space = l.comp_1.xl - l.comp_2.xh, where l.comp_1.xl is the minimum value of component comp_1 in the X-axis direction, and l.comp_2.xh is the minimum value of component comp_2 in the X-axis direction. That is, the actual spacing between the two components is the horizontal distance between the left edge of the right component and the right edge of the left component.

[0191] LEFT_OF: Indicates that component comp_1 is located to the left of component comp_2.

[0192] The formula for calculating the actual spacing between two components is: real_space = l.comp_2.xl - l.comp_1.xh, where l.comp_2.xl is the minimum value of component comp_2 in the X-axis direction, and l.comp_1.xh is the minimum value of component comp_1 in the X-axis direction. That is, the actual spacing between the two components is the horizontal distance between the left edge of the left component and the right edge of the right component.

[0193] After determining the geometric relationship value, verification and determination can be carried out. Specifically: If the calculated real_space < drc_value, it is determined that the spacing design rule is violated, and an error message will be recorded in report R. In particular, if the calculation result of real_space is negative, it indicates that the two components have an unexpected overlap in space, which is a serious geometric error, and it can be recorded and reported as a violation.

[0194] Exemplarily, please refer to Figure 8 , Figure 8 which is a schematic diagram of a specific scenario of this embodiment. Specifically, the consistency verification result can be a consistency verification report R. In the case where a consistency verification report R without specific numerical differences is generated by the consistency verification module, it can be determined that the automatic repair module performs the code repair process. Specifically, the name of the violated component (for example, guard_ring_top_bar) can be identified according to the consistency verification report R. By looking up the symbol table or variable definition in the code, the specific code line where the component is generated is located. Further, according to the geometric relationship value of the sub-components in the report, and the geometric rule value calculate the required displacement correction amount . For example, for the insufficient spacing error of the ABOVE type, in order to meet the minimum spacing, the component needs to move in the positive Y-axis direction. The formula for the correction amount can be specifically as follows:

[0195]

[0196] where is a small safety redundancy that can be used to ensure that the value after repair is slightly greater than the geometric rule value.

[0197] The automatic error correction module uses a large language model or a rule engine to perform semantic-level modification on the located code. The modification methods can include: If the position of the component is defined by parameters, the parameter calculation logic can be directly modified; if the position of the component is fixed, a movement function can be inserted after the code for generating the component.

[0198] The following presents a specific algorithm for verifying the consistency of layout constraints in the layout constraint diagram and physical layout, and illustrates the specific process of generating the consistency verification result to support this example. Specifically:

[0199] for do

[0200] if then

[0201]

[0202]

[0203]

[0204] ;

[0205] if then

[0206] R ← corresponding enclosure violation;

[0207] end if

[0208] else

[0209] if then

[0210] ;

[0211] else if then

[0212] ;

[0213] else if then

[0214] ;

[0215] else if then

[0216] ;

[0217] end if

[0218] if then

[0219] R ← corresponding minimal spacing violation;

[0220] end if

[0221] end if

[0222] end for

[0223] It should be noted that this algorithm is an exemplary step of traversing the layout constraint graph and performing consistency checks based on the layout constraint graph. It determines the consistency check report R by judging the spatial relationships between each edge in the layout constraint graph. Furthermore, the layout constraint graph can include at least one edge, i.e., a set ΔE. For example, a layout instance l containing the coordinate information of all components, extracted from the actual layout, can be used to check whether each expected constraint edge is satisfied in the actual geometric layout.

[0224] For each edge in set ΔE, its data format is {comp1, edge_type, drc_value, comp2}, representing the reference component, constraint type, design rule value, and target component, respectively. The edge type is determined. If the constraint type is CONTAINS, an inclusion check is performed. The distances of the target component comp2's boundary relative to the source component comp1's boundary in the left, right, down, and up directions are calculated, and the minimum of these four distances is taken as the actual enclosure value, real_enclosure. Next, the algorithm compares this actual value with the design rule value drc_value specified in the edge. If the actual enclosure value is less than the rule requirement, it is considered an "enclosure violation," and this violation information is recorded in the inconsistency report R.

[0225] If the constraint type is not CONTAINS, it is a directional spacing constraint. The algorithm selects the corresponding geometric formula based on the specific type (ABOVE, BELOW, RIGHT_OF, or LEFT_OF) to calculate the actual spacing `real_space` between the two components. For example, for the ABOVE type, the actual spacing equals the Y-coordinate of the bottom edge of the upper component minus the Y-coordinate of the top edge of the lower component. After calculation, the algorithm also compares `real_space` with `drc_value`. If the actual spacing is less than the minimum spacing requirement, it is judged as a "spacing violation," and this violation information is appended to report R.

[0226] The algorithm terminates after iterating through all expected constraint edges, and the final output report R can include details of all detected geometric violations.

[0227] Therefore, by performing layout constraint consistency verification on the layout constraint graph and physical layout, consistency verification results are generated in a systematic and precise manner. Specifically, to ensure that all preset layout rules are verified, the verification process first traverses every edge in the layout constraint graph. During the traversal, for each target edge, a preset geometric relationship calculation function matching the specific constraint type it represents is dynamically invoked. These functions use the geometric coordinate information of each functional module extracted from the physical layout to accurately calculate the actual geometric relationship value corresponding to the target edge. Subsequently, this calculated geometric relationship value is rigorously compared with the geometric rule value preset for the target edge in the layout constraint graph. If the actual geometric relationship value fails to meet the geometric rule value, the constraint represented by the target edge is explicitly determined to be geometrically violated. This meticulous edge-by-edge and rule-by-rule verification yields a comprehensive and accurate consistency verification result. It not only identifies all geometric violations that do not conform to design specifications but also provides a clear basis for subsequent automatic correction of edited code. This effectively solves the problems of low efficiency, insufficient accuracy, and difficulty in locating specific violations that may exist in traditional verification methods under complex layout constraints, and significantly improves the reliability and automation level of parametric unit code verification.

[0228] Based on this, in one implementation, such as Figure 9 As shown, step 15, based on the consistency check result, automatically corrects the edited code to be checked, obtaining the target edited code that passes the geometric consistency check. This specifically includes steps 151 to 154, where:

[0229] Step 151: Analyze the target functional module, violation type, and numerical difference from the consistency verification results.

[0230] The target functional module is the functional module that fails the consistency check.

[0231] Specific violation information is extracted from the verification results generated during the aforementioned consistency verification process. The verification results are usually in the form of structured data, such as log files, error reports, or specific data objects.

[0232] Specifically, this may include performing pattern matching, keyword recognition, or data structure traversal on these data to identify which functional modules have geometric layout problems, i.e., the target functional modules, as well as the specific nature and quantification of these problems.

[0233] Step 152: Calculate the displacement correction amount required to adjust the target functional module to the compliant position based on the violation type and numerical difference.

[0234] After identifying the violating functional module, the type of violation, and the numerical discrepancy, it is possible to determine how to correct it. Specifically, the violation information can be converted into specific geometric displacements by applying predefined correction rules or algorithms.

[0235] For example, if the violation type is that the distance between two components is less than the specified value, the numerical difference is the missing distance. The displacement correction amount can then be this missing distance, or a certain margin can be considered on top of it. The calculation process can be implemented based on geometric principles, optimization algorithms, or lookup table methods to ensure that the calculated displacement correction amount can effectively adjust the target functional module to a compliant position that meets layout constraints.

[0236] Step 153: Based on the relationship between components and code variables in the layout constraint diagram, locate and generate the target code segment of the target functional module.

[0237] To correct the edited code, the code section corresponding to the non-compliant functional module can be found. Here, the mapping relationship between components and code variables established during the layout constraint diagram construction or code generation phase can be utilized.

[0238] The mapping between layout constraint graph components and code variables can be stored in a database, configuration files, or dynamically constructed using code analysis tools. By querying these relationships, the corresponding code segment in the code to be verified and edited can be precisely located based on the identified target functional module. For example, a functional module may be defined by a set of parameters in the code or generated by a specific function call; the location process involves finding these definitions or calls.

[0239] Step 154: Based on the displacement correction amount, adjust the parameters of the target code segment or insert semantic-level modifications of the displacement instructions to obtain the target edit code.

[0240] The target edit code is the edit code that has passed geometric verification.

[0241] After locating the target code segment, semantic-level modifications can be made to the code based on the previously calculated displacement correction.

[0242] As one implementation method, if the geometric position of a functional module is determined by coordinate parameters in the code, the values ​​of these parameters are directly modified; if the movement of a functional module requires specific instructions, corresponding displacement instructions can be inserted into the code. Semantic-level modification means that the modification is based on the meaning and function of the code, rather than simple text replacement, thereby ensuring that the corrected code is still functionally correct and can generate a physical layout that meets geometric constraints, ultimately resulting in target edit code that passes geometric verification.

[0243] For example, after receiving the consistency verification report R generated by the consistency verification module, a precise and automated closed loop can be established from geometric violations to source code correction.

[0244] The names of violating components are identified from the consistency verification report R. Then, by searching the symbol table in the code or utilizing the variable name relationships stored in the layout constraint diagram, the specific line of code that generated the component is precisely located. After location, the required displacement correction Δ_move can be calculated based on the real_space (actual geometric relationship value) and drc_value (rule value) recorded in the report. The core formula for calculating the correction is Δ_move = drc_value - real_space + margin. The introduced margin is a small safety redundancy, its function being to ensure that the corrected geometric parameters stably meet the design rules, avoiding repeated corrections due to numerical precision issues, thereby improving the robustness and convergence efficiency of the entire error correction process.

[0245] Next, a large language model or rule engine is used to perform semantic-level modifications on the located code. If the component position is defined by a parameter calculation formula, the calculation logic is directly adjusted to incorporate the correction amount; if the component position is fixed, the corresponding geometric transformation instruction is inserted after the code that generates the component, for example, executing guard_ring_top_bar.movey(correction_value), where correction_value is the calculated displacement correction amount Δ_move.

[0246] After the correction is completed, a new version of the code C_correct is generated. To ensure the effectiveness of the correction, this code will not be output directly, but will instead re-enter the instantiation and consistency verification process, initiating a new round of verification. This process iterates until the consistency verification result R is empty, indicating that all geometric constraints have been satisfied, thus forming a complete, closed-loop automated workflow from error detection, location, correction to verification.

[0247] In the above implementation, by establishing an automated closed-loop mechanism from error identification to code correction, the problem of low efficiency and error-proneness in manually correcting geometric violations discovered during parametric unit code verification is solved. Specifically, the code to be verified that does not conform to geometric constraints can be automatically converted into target code that meets all geometric constraints, realizing automation from problem discovery to problem resolution. This greatly improves the efficiency and quality of parametric unit code development and ensures that the final generated physical layout is fully compliant in terms of geometric layout.

[0248] The following is a specific example for illustration; please refer to it. Figure 10 , Figure 10 This is a schematic diagram of a specific scenario, specifically illustrating the scenario of adding an M3 layer protective ring around a MIM capacitor.

[0249] In the initial state, there exists a raw code that defines a standard MIM capacitor, which contains rect_m3 representing the bottom metal and rect_m4 representing the top metal.

[0250] The design requirement received is: "Add a protective ring to the top edge of the M3 layer, which must be located above rect_m3 with a spacing of at least 0.5 micrometers."

[0251] The code can be edited according to this requirement to generate verification code containing statements for creating the guard ring `guard_ring_top_bar` and setting its initial position. Simultaneously, an expected layout constraint edge can be derived from the design requirements: `{guard_ring_top_bar, ABOVE, 0.5, rect_m3}`. This layout constraint edge explicitly requires the guard ring to be located above the underlying metal with a minimum spacing of 0.5 micrometers.

[0252] Furthermore, the code to be verified can be run to generate a geometric layout. Assuming that due to an error in the initial position calculation, the upper edge of rect_m3 in the actual generated layout... The bottom edge of guard_ring_top_bar That is, the top edge coordinate of rect_m3 is 10.0, and the bottom edge coordinate of guard_ring_top_bar is 10.4. After extracting these key coordinates, a consistency check algorithm can be performed.

[0253] Specifically, we can determine that the type of the expected constraint edge is "ABOVE" and calculate the actual spacing (geometric relationship value). Compare this actual value with the geometrically required value of 0.5 micrometers. This indicates that the spacing is insufficient, constituting a geometric violation, and generates a verification report that clearly points out the numerical difference. Specifically, the verification report states that "the spacing between guard_ring_top_bar and rect_m3 is 0.4, which is less than the required 0.5".

[0254] Based on this verification report, an automatic error correction process is initiated. This process locates the line of code that generated the protective ring. Then, based on the difference between the rule value and the actual value, the required displacement correction is calculated to be 0.1 micrometers. Specifically, The code was then semantically modified; for example, the Y-axis movement command was changed to `guard_ring_top_bar.movey(initial_y_position + 0.1)`. The corrected code was then instantiated and validated again. At this point, the actual distance between the protective ring and the underlying metal reached 0.5 micrometers, fully meeting the design requirements, and the validation passed.

[0255] As can be seen from this embodiment, the present invention mathematically aligns abstract code logic with specific geometric and physical rules through layout constraint diagrams. By leveraging closed-loop control of coordinate extraction, constraint verification, and feedback correction, it achieves automated verification and error correction of parameterized unit code, significantly improving development efficiency and layout quality.

[0256] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0257] Based on the same inventive concept, this application also provides a code verification device for parameterized units to implement the code verification method for parameterized units described above. The solution provided by this device is similar to the implementation described in the above method. Therefore, the specific limitations in one or more embodiments of the code verification device for parameterized units provided below can be found in the limitations of the code verification method for parameterized units described above, and will not be repeated here.

[0258] In one exemplary embodiment, such as Figure 11 As shown, a code verification device for a parameterized unit is provided, comprising: a first acquisition module, a first determination module, a second acquisition module, a verification module, and a correction module, wherein:

[0259] The first acquisition module is used to acquire the requirement information for writing parameterized units;

[0260] The first determining module is used to perform layout constraint parsing on the constraint keywords in the requirement information to determine the layout constraint diagram corresponding to the requirement information; wherein, the layout constraint diagram is used to represent the topological relationship and geometric rule constraints of the components required by at least one functional module corresponding to the requirement information.

[0261] The second acquisition module is used to acquire the edit code to be verified and the corresponding physical layout; wherein, the edit code to be verified is the edit code determined according to the requirement information, and the physical layout is the layout diagram obtained by instantiating the edit code to be verified;

[0262] The verification module is used to verify the consistency of layout constraints in the layout constraint diagram and physical layout, and generate consistency verification results.

[0263] The correction module is used to automatically correct the edited code to be verified based on the consistency verification results, so as to obtain the target edited code that passes the geometric consistency verification.

[0264] In one embodiment, the first determining module includes an analysis unit, a construction unit, and a setting unit, wherein:

[0265] The analysis unit is used to perform semantic analysis on the requirement information and identify the target component, reference component, spatial constraint relationship and geometric rule value between the target component and the reference component corresponding to at least one functional module described in the requirement information.

[0266] The building unit is used to construct a layout constraint graph based on the target component, the reference component, and the spatial constraint relationship, with the target component and the reference component as vertices and the spatial constraint relationship as edges;

[0267] The setting unit is used to set the corresponding geometric rule value for each edge in the spatial constraint relationship, so as to obtain the layout constraint diagram.

[0268] In one embodiment, the second acquisition module includes a granular third acquisition unit, a processing unit, and a component unit, wherein:

[0269] The third acquisition unit is used to acquire the edit code to be verified corresponding to the requirement information; wherein, the edit code to be verified is the edit code obtained after semantic analysis and functional reasoning of the requirement information;

[0270] The processing unit is used to perform layout instantiation and coordinate extraction processing on the code to be verified and edited, and to determine the geometric coordinate information of each component required by at least one functional module corresponding to the requirement information;

[0271] The constituent units are used to determine the corresponding physical layout based on the geometric coordinate information of each component.

[0272] In one embodiment, the processing unit includes a calling subunit and an extracting subunit, wherein:

[0273] The calling sub-unit is used to invoke the layout generation engine to execute the code to be verified and edited, and to generate layout data;

[0274] Extract sub-cells to traverse the layout data and extract the minimum and maximum coordinates of the bounding box of each functional module involved in the layout constraint diagram in the X and Y directions, so as to obtain the geometric coordinate information of each functional module.

[0275] In one embodiment, the verification module includes a traversal unit, a calculation unit, a comparison unit, and a second determination unit, wherein:

[0276] Traversal cells are used to traverse each edge in the layout constraint graph;

[0277] The calculation unit is used to call the corresponding geometric relationship calculation function according to the constraint type of the target edge, and calculate the geometric relationship value based on the geometric coordinate information of each functional module in the physical layout; where the target edge is any edge in the layout constraint diagram;

[0278] The comparison unit is used to compare the geometric relation values ​​with the geometric rule values ​​recorded for the target edge in the layout constraint diagram;

[0279] The second determining unit is used to determine the target edge as a geometric violation if the geometric relationship value is less than the geometric rule value, and obtain the corresponding consistency verification result.

[0280] In one embodiment, the calculation unit includes a first constraint calculation subunit and a second constraint calculation subunit, wherein:

[0281] The first constraint calculation subunit is used to calculate the encirclement distance of the boundary of the reference component to the boundary of the target component in different preset directions if the constraint type of the target edge is the first constraint type, and take the minimum value of the encirclement distance as the geometric relationship value.

[0282] The second constraint calculation subunit is used to calculate the actual spatial distance between the boundaries of the two components based on the coordinates of the reference component and the target component if the constraint type of the target edge is the second constraint type, and to use the actual spatial distance as the geometric relationship value.

[0283] Each module in the code verification device of the aforementioned parameterized unit can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0284] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 12 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores matrix data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When executed by the processor, the computer program implements a code verification method for parameterized units.

[0285] Those skilled in the art will understand that Figure 12 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0286] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps performed by the code verification method of the parameterized unit described above.

[0287] In one embodiment, a readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps performed by the code verification method of the parameterized unit described above.

[0288] In one embodiment, a program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0289] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0290] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0291] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for verifying the code of a parameterized unit, characterized in that, The method includes: Obtain the requirements for writing parameterized units; The constraint keywords in the requirement information are parsed for layout constraints to determine the layout constraint diagram corresponding to the requirement information; wherein, the layout constraint diagram is used to represent the topological relationships and geometric rule constraints of the components required by at least one functional module corresponding to the requirement information. Obtain the edit code to be verified and its corresponding physical layout; wherein, the edit code to be verified is the edit code determined according to the requirement information, and the physical layout is the layout diagram obtained by instantiating the edit code to be verified; The consistency of the layout constraints in the layout constraint diagram and the physical layout is verified, and a consistency verification result is generated. Based on the consistency verification result, the edit code to be verified is automatically corrected to obtain the target edit code that passes the geometric consistency verification.

2. The method according to claim 1, characterized in that, The step of parsing the constraint keywords in the requirement information to determine the layout constraint graph corresponding to the requirement information includes: The requirement information is semantically analyzed to identify the target component, reference component, spatial constraint relationship and geometric rule value between the target component and the reference component corresponding to at least one functional module described in the requirement information; Based on the target component, the reference component, and the spatial constraint relationship, a layout constraint graph is constructed with the target component and the reference component as vertices and the spatial constraint relationship as edges; The corresponding geometric rule value is set for each edge in the spatial constraint relationship to obtain the layout constraint diagram.

3. The method according to claim 1, characterized in that, The steps for obtaining the code to be verified and the corresponding physical layout include: Obtain the edit code to be verified corresponding to the requirement information; wherein, the edit code to be verified is the edit code obtained after semantic analysis and functional reasoning of the requirement information; The code to be verified is instantiated and its coordinates are extracted to determine the geometric coordinates of each component required by at least one functional module corresponding to the requirement information. Based on the geometric coordinates of each component, the corresponding physical layout is determined.

4. The method according to claim 3, characterized in that, The step of performing layout instantiation and coordinate extraction processing on the code to be verified and determining the geometric coordinate information of each component required by at least one functional module corresponding to the requirement information includes: The layout generation engine is invoked to execute the edited code to be verified, generating layout data. By traversing the layout data, the minimum and maximum coordinates of the bounding box of each functional module involved in the layout constraint diagram in the X and Y directions are extracted to obtain the geometric coordinate information of each functional module.

5. The method according to claim 1, characterized in that, The step of performing a layout constraint consistency check on the geometric layout of the layout constraint diagram and the physical layout, and generating a consistency check result, includes: Traverse each edge in the layout constraint graph; Based on the constraint type of the target edge, the corresponding geometric relationship calculation function is called, and the geometric relationship value is calculated based on the geometric coordinate information of each functional module in the physical layout; wherein, the target edge is any edge in the layout constraint diagram; The geometric relationship value is compared with the geometric rule value recorded for the target edge in the layout constraint diagram; If the geometric relationship value is less than the geometric rule value, then the target edge is determined to be a geometric violation, and the corresponding consistency verification result is obtained.

6. The method according to claim 5, characterized in that, The target edge includes a target component and a reference component. The spatial constraint relationship between the target component and the reference component includes a first constraint type and a second constraint type. The first constraint type is used to represent a complete enclosing relationship, and the second constraint type is used to represent a non-overlapping orientation constraint relationship. The steps of calling the corresponding geometric relationship calculation function according to the constraint type of the target edge, and calculating the geometric relationship value based on the geometric coordinate information of each functional module in the physical layout, include: If the constraint type of the target edge is the first constraint type, then calculate the encirclement distance of the boundary of the reference component to the boundary of the target component in different preset directions, and take the minimum value of the encirclement distance as the geometric relationship value. If the constraint type of the target edge is the second constraint type, the actual spatial distance between the boundaries of the two components is calculated based on the coordinates of the reference component and the target component, and the actual spatial distance is used as the geometric relationship value.

7. The method according to claim 1, characterized in that, The step of automatically correcting the edited code to be verified based on the consistency verification result to obtain the target edited code that passes the geometric rule verification includes: The target functional module, violation type, and numerical difference are analyzed from the consistency verification results; wherein, the target functional module is the functional module that fails the consistency verification. Based on the violation type and the numerical difference, calculate the displacement correction amount required to adjust the target functional module to a compliant position; Based on the association between components and code variables in the layout constraint diagram, the target code segment of the target functional module is located and generated; Based on the displacement correction amount, the target code segment is modified at the semantic level by adjusting parameters or inserting displacement instructions to obtain the target edit code; wherein, the target edit code is edit code that has passed geometric verification.

8. A code verification device for a parameterized unit, characterized in that, The code verification device of the parameterization unit includes: The first acquisition module is used to acquire the requirement information for writing parameterized units; The first determining module is used to perform layout constraint parsing on the constraint keywords in the requirement information to determine the layout constraint diagram corresponding to the requirement information; wherein, the layout constraint diagram is used to represent the topological relationship and geometric rule constraints of the components required by at least one functional module corresponding to the requirement information. The second acquisition module is used to acquire the edit code to be verified and the corresponding physical layout; wherein, the edit code to be verified is the edit code determined according to the requirement information, and the physical layout is the layout diagram obtained by instantiating the edit code to be verified; The verification module is used to verify the consistency of the layout constraints in the layout constraint diagram and the physical layout diagram, and generate a consistency verification result. The correction module is used to automatically correct the edit code to be verified based on the consistency verification result, so as to obtain the target edit code that passes the geometric consistency verification.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images