DRC design rule positive and negative example automatic generation method based on large language model and formalized verification

Abstract

The invention discloses a DRC design rule positive and negative example automatic generation method based on a large language model and formalized verification, and relates to the field of electrical digital data processing.The method comprises the following steps that firstly, a natural language rule is accurately converted into a logic expression by combining an entity library and a function library constructed through the large language model; thirdly, disassembling the logic and executing full-coverage enumeration traversal of a Boolean algebraic space; then introducing an SMT solver to construct a target optimization problem, automatically solving coordinates to generate a test layout clinging to a rule boundary, and distributing clear positive and negative example labels; and finally, through an innovative hierarchical context management mechanism, false positive and false alarm caused by multi-rule interference are eliminated, and redundant rules are intelligently identified. According to the method, the verification coverage rate and the automation level are greatly improved, and the labor cost of chip physical verification can be remarkably reduced.

Description

Technical Field

[0001] This invention relates to the field of electronic digital data processing technology, and more particularly to computer-aided design of integrated circuits and electronic design automation, specifically a method for automatically generating positive and negative examples of DRC design rules based on large language models and formal verification. Background Technology

[0002] Design Rule Check (DRC) is an indispensable core step in chip physical design. Design rules, defined by the wafer foundry, describe geometric and electrical constraints, establishing manufacturing process limits, such as specifying minimum linewidths and spacing between polygons. These rules, provided in human-readable natural language, form the foundation for ensuring chip manufacturability and design reliability. To enable EDA tools (such as Calibre) to consistently and efficiently detect violations in the layout automatically, these natural language design rules must be translated into machine-readable DRC scripts.

[0003] However, translating design rules into scripts is highly manual, a multi-step, and error-prone process. The accuracy of the scripts is paramount; any error could lead to the underreporting of real manufacturing violations or the generation of numerous false alarms, both with serious consequences. In practice, to verify the correctness of DRC scripts, foundries typically rely on engineers to manually design test layouts. Experienced engineers spend months manually creating numerous test layouts for each design rule to cover all critical boundary conditions and thoroughly validate the script. With the continuous evolution of nanoscale manufacturing processes, the number and complexity of design rules have increased significantly, further exacerbating the challenges of script verification.

[0004] To address the aforementioned issues, several methods have emerged in the industry to assist in script verification. For example, parameterized cells (PCELLs) can be used as seed test structures and manually modified to create desired variants, or generic shapes can be manually created entirely for each rule. Other research has proposed using constraint-based parameterized patterns to generate test patterns by extrapolating constraints from similar rules in mature processes. In recent years, the development of Large Language Models (LLM) technology has also provided new ideas for automated script translation. Some research attempts to utilize large models for rule-to-script translation, such as standardizing rules through preprocessing and using sequence-to-sequence models for translation.

[0005] Nevertheless, existing methods still have significant shortcomings. Methods based on parametric cells or constraint extrapolation heavily rely on existing mature process rules, limiting their applicability to rules at new process nodes. Furthermore, scripts generated by large language models still suffer from high error rates due to the extreme rigor of integrated circuit physical rules and logic; therefore, independent and rigorous testing and verification of these scripts remains an indispensable step. On the other hand, while formal verification is widely used in hardware design, a systematic solution has long been lacking for how to accurately map DRC rules written in natural language to formal logic formulas and automatically and completely generate test layouts with clearly labeled positive and negative examples using large language model co-solvers. Summary of the Invention

[0006] This invention overcomes the shortcomings of existing technologies and provides an automatic generation method for positive and negative examples of DRC design rules based on a large language model and formal verification. It utilizes a large language model to transform natural language rules into strict logical expressions, then constructs a complete test space through logical decomposition and full Boolean space enumeration, and introduces a satisfiability modular theory solver to automatically generate a test layout closely following the rule boundaries and assign positive and negative example labels. Finally, a context management mechanism is used to eliminate interference from multiple rules and identify redundant rules, thereby systematically solving the problems of low automation and incomplete test coverage in DRC script verification.

[0007] To achieve the above objectives, the technical solution adopted by this invention is as follows: Firstly, this invention provides a method for automatically generating positive and negative examples of DRC design rules based on a large language model and formal verification, comprising the following steps: S1. Using a large language model, design rules described in natural language are transformed into logical expressions based on layout geometric relationships; S2. Decompose the logical expression into several basic predicates, and perform a full-coverage enumeration of the truth value combinations of the basic predicates based on the Boolean algebra space to construct a complete test space. S3. Input the truth value combination obtained by enumeration as a constraint condition into the satisfiability modular theory solver for solving. Generate a test layout by mapping the coordinates obtained from the solution. Assign positive and negative examples that represent compliance with or violation of the rules to the test layout according to whether the corresponding truth value combination satisfies the original logical expression. S4. Introduce a context management mechanism based on layout layer information, introduce background constraints of associated rules when generating test layouts, and identify redundant rules in the design rule base.

[0008] In a preferred embodiment of the present invention, step S1 further includes the following steps: S11. Establish a solid library for defining the geometry of the layout and a function library for expressing geometric relationships; S12. Input the natural language design rules and examples into the large language model, so that it calls the entity library and function library to generate the corresponding logical expression code; S13. Perform syntax and runtime checks on the generated code, and if errors occur, feed back the error information to the large language model for correction.

[0009] In a preferred embodiment of the present invention, step S2 further includes the following steps: S21. Predicates with the same geometric meaning but different objects of action are grouped and preprocessed to control the number of predicates; S22. Based on the Boolean algebra completeness theorem, systematically enumerate all 2^n of the n basic predicates decomposed. n A combination of true and false assignments.

[0010] In a preferred embodiment of the present invention, in step S3, the satisfiability modulus solver constructs an optimization problem with the objective of minimizing the distance between the geometric parameters and the rule boundary, in order to generate a test layout that closely follows the design rule boundary.

[0011] In a preferred embodiment of the present invention, the optimization objective of the optimization problem is expressed as: ;in, lhs and rhs They represent Each arithmetic predicate The left and right sides.

[0012] In a preferred embodiment of the present invention, in step S4, the context management mechanism specifically includes: identifying the layout layers involved in each design rule, dividing rules involving the same layout layer into the same rule group; when generating a test layout for the target rule, using other rules in the same group as background constraints, and inputting them together with the truth value of the target rule into the solver; if no counterexample test layout can be generated for the target rule under the background constraints, then the rule is marked as a redundant rule.

[0013] In a preferred embodiment of the present invention, the method is also applied to the automated closed-loop correction of DRC scripts, specifically: the generated test layout and its positive and negative example labels, as well as the logical expression generated in step S1, are used as feedback information and input into the large language model used to generate DRC scripts, so as to guide it to correct the generated scripts.

[0014] In a preferred embodiment of the present invention, the logical expression generated in step S1 is formed by combining geometric conditions using logical operators; the basic predicate in step S2 is an arithmetic predicate.

[0015] In a second aspect, embodiments of the present invention provide an electronic device, comprising: at least one processor; and a memory communicatively connected to at least one of the processors; The memory stores a computer program that is executed by at least one of the processors, such that the at least one processor is able to execute the automatic generation method for positive and negative examples of DRC design rules based on a large language model and formal verification, as described above.

[0016] Thirdly, embodiments of the present invention provide a computer-readable storage medium storing computer instructions, which are used to cause a processor to execute the automatic generation method for positive and negative examples of DRC design rules based on a large language model and formal verification as described above.

[0017] This invention addresses the shortcomings of the prior art and has the following beneficial effects: (1) This invention provides an automatic generation method for positive and negative examples of DRC design rules based on a large language model and formal verification. By converting natural language design rules into strict logical expressions, the semantics of the rules can be accurately formalized. By using a large language model combined with entity libraries and function libraries, and supplemented by syntax checking and runtime verification mechanisms, the generated logical expressions are ensured to be accurate. This transforms the originally ambiguous and polysemous natural language constraints into mathematical descriptions that can be accurately processed by computers, thereby avoiding errors caused by misunderstandings when manually translating scripts. Compared with the traditional method that relies entirely on manual interpretation of rules, this invention eliminates ambiguity and provides a reliable and reusable logical foundation for subsequent automated verification.

[0018] (2) By decomposing complex logical expressions and performing full-coverage enumeration based on Boolean algebra space, the present invention decomposes logical formulas into basic arithmetic predicates and systematically enumerates all combinations of predicate truth values. This ensures that any geometric scenario that may violate or satisfy the rules is included in the test scope, thereby achieving an exhaustive traversal of the rule logic space. Compared with the existing technology that relies on engineers' experience to manually select limited boundary test cases, this invention avoids the risk of missing key test scenarios due to blind spots in thinking, thereby raising the test coverage from experience-driven to mathematically complete.

[0019] (3) This invention introduces a satisfiability modulus solver to construct a boundary optimization problem. With the goal of minimizing the distance between geometric parameters and the rule boundary, it solves the coordinate solution that satisfies a specific logical combination. It directly generates a positive and negative example test layout that is close to the rule boundary and has high discriminative power. Compared with the limitations of manual hand-drawn layout, which makes it difficult to accurately control the boundary value and is inefficient, this method can quickly and automatically generate a large number of high-precision boundary test cases. It can also automatically assign positive and negative example labels according to the consistency between the logical combination and the original rule, making the discovery of script errors more direct and efficient, thereby greatly improving the accuracy and automation of verification.

[0020] (4) This invention introduces background constraints of associated rules when generating test layouts through a context management mechanism based on layout layer information. This can effectively eliminate false positives caused by interference between multiple rules. The rules in the same layer are grouped, and other rules in the group are solved together as mandatory conditions when verifying the target rule. This ensures that the generated test layout is physically legal and valid, thereby avoiding invalid alarms caused by test cases violating unnoticed basic rules. Compared with the verification process in the prior art that is misled by the coupling relationship between rules, this method makes the verification results purer and more reliable. At the same time, it can automatically identify redundant rules that cannot generate any counterexamples, thereby optimizing the script maintenance and running efficiency of the foundry. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Figure 1 This is a flowchart illustrating the overall workflow of the present invention; Figure 2 This is a detailed architecture diagram of the design rules of this invention being converted into logical expressions; Figure 3 This is a schematic diagram of the logical expression decomposition of the present invention; Figure 4 This is a schematic diagram of the test layout generation and boundary test case annotation determination of the present invention; Figure 5 A schematic diagram of an electronic device structure that can be used to implement Embodiment 1 of the present invention is shown. Detailed Implementation

[0022] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0023] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein. Therefore, the scope of protection of the invention is not limited to the specific embodiments disclosed below.

[0024] Example 1

[0025] This embodiment provides an automatic generation method for positive and negative examples of DRC design rules based on a large language model and formal verification. It aims to address the problems of current integrated circuit physical design rule checking (DRC) script verification processes, which heavily rely on manual hand-drawn test layouts, resulting in low efficiency and difficulty in covering all boundary cases. This embodiment will elaborate on how to utilize a large language model, formal methods, and optimized solution strategies to achieve fully automated generation and verification from natural language design rules to accurate test layouts.

[0026] The method in this embodiment is applicable to DRC script verification scenarios at advanced process nodes (such as 7nm and below), especially for design rule manuals released by foundries that contain a large number of complex geometric constraints. This method can be integrated into electronic design automation (EDA) tool flows as a core module for script quality assurance. The generation method includes the following steps: S1. Using a large language model, design rules described in natural language are transformed into logical expressions based on layout geometric relationships; S2. Decompose the logical expression into several basic predicates, and perform a full-coverage enumeration of the truth value combinations of the basic predicates based on the Boolean algebra space to construct a complete test space. S3. Input the truth value combination obtained by enumeration as a constraint condition into the satisfiability modular theory solver for solving. Generate a test layout by mapping the coordinates obtained from the solution. Assign positive and negative examples that represent compliance with or violation of the rules to the test layout according to whether the corresponding truth value combination satisfies the original logical expression. S4. Introduce a context management mechanism based on layout layer information, introduce background constraints of associated rules when generating test layouts, and identify redundant rules in the design rule base.

[0027] The core concept of this invention lies in transforming the traditionally experience-dependent task of DRC script verification into an automated problem based on formal logic and mathematical optimization. For example... Figure 1 As shown, firstly, leveraging the powerful natural language understanding and code generation capabilities of Large Language Models (LLM), fuzzy natural language rules are translated into precise logical expressions, forming the semantic foundation of the entire automated process. Secondly, through logical decomposition and full Boolean space enumeration, complex rule logic is broken down into basic units that can be processed by a mathematical solver, and all possible logical scenarios are systematically enumerated, theoretically ensuring the completeness of test cases and avoiding blind spots in manual design. Then, a Satisfiability Modulus Theory (SMT) solver is introduced, transforming the test layout generation problem into a coordinate solving problem with an optimization objective. The solver finds the optimal solution closely adhering to the rule boundaries, thereby automatically generating a highly discriminative positive and negative example test layout. Finally, through an innovative context management mechanism, the problem of false positives caused by interference between multiple rules is solved, and redundant rules can be intelligently identified, further optimizing the verification process.

[0028] In this embodiment, step S1 further includes the following sub-steps: S11. Establish a solid library for defining the geometry of the layout and a function library for expressing geometric relationships; S12. Input the natural language design rules and examples into the large language model, so that it calls the entity library and function library to generate the corresponding logical expression code; S13. Perform syntax and runtime checks on the generated code, and if errors occur, feed back the error information to the large language model for correction.

[0029] In step S11, the entity library and function library serve as a bridge connecting natural language and formal logic. The entity library is used to define the geometric shapes that may appear in the layout, such as rectangles, polygons, and tori. Each shape is defined by its key coordinate points. For example, a rectangle is defined by the coordinates of its lower left corner (…). x 1, y 1) and the coordinates of the upper right corner ( x 2, y 2) To ensure uniqueness, these coordinates are declared as integer variables for subsequent mathematical calculations. To manage multiple shapes, each shape instance is identified by its respective layer name and a unique shape index.

[0030] The function library provides a series of atomic functions for expressing geometric relationships between shapes. These functions form the basic elements of logical expressions. For example, outside ( shape 1, shape2) The function is used to determine whether two shapes do not overlap completely. It is implemented by defining a series of coordinate inequality constraints: shape The right boundary of 1 is less than shape The left boundary of 2, or shape The upper boundary of 1 is less than shape The lower bound of 2, etc. Other commonly used functions include... inside () intersect () width () space These functions are designed so that their input is a shape entity and their output is a Boolean value (true or false), allowing them to be directly combined with logical operators. Furthermore, to handle more complex geometric relationships, the function library can also include functions such as... distance The function () calculates the minimum distance between two shapes and returns an integer variable that can then be compared with a constant to form an arithmetic predicate.

[0031] In step S12, for example, taking a typical DRC rule as an example: metal layer 1 ( Metal 1) The spacing between the two parallel lines must not be less than 0.05 μm. First, this natural language rule, along with a small number of handwritten rule-logic transformation examples, i.e., prompt words, is input into a large language model (such as DeepSeek-R1). These examples show the model how to call the entity library and function library built in step S11 to represent geometric constraints. For example, an example might show how to use... width The parentheses function represents the width of a line. space The () function represents the distance between lines.

[0032] Furthermore, the large language model attempts to generate Python code based on prompts and input rules. The generated code first instantiates two rectangular objects from the entity library, for example... rect 1 = Rectangle ( layer = METAL 1, x 1, y 1, x 2, y 2) and rect 2 = Rectangle ( layer = METAL 1, x 1, y 1, x 2, y 2). Then, the function library will be called. space ( rect 1, rect 2) Functions, and introduce arithmetic predicates. space( rect 1, rect 2) >= 0.05. Finally, use logical operators (such as AND) to combine the geometric conditions into a complete rule-based logical expression. In this example, since there is only one core constraint, the generated logical expression is: space ( rect 1, rect 2) >= 0.05. For complex rules containing multiple conditions, such as if two rectangles overlap vertically, then their horizontal spacing must be greater than 0.1, the model will generate a value like... Implies ( And ( overlap y ( rect 1, rect 2)), space x ( rect 1, rect 2) Expressions with a value greater than 0.1. The conversion framework from the above rules to logical expressions is as follows: Figure 2 As shown.

[0033] In step S13, to ensure the quality and executability of the logical expression code output by the large language model, this embodiment introduces a dual verification mechanism. The first step is syntax checking. The system parses the generated code and verifies whether the object names referenced (such as layer names) match the predefined list of valid layers in the DRC verification file (Deck). METAL 1, METAL 2, VIA 1) Complete match. This error will be caught if a spelling error or an undefined layer name is used.

[0034] Secondly, there are runtime checks. The system attempts to execute the generated code in a secure sandbox environment. If errors occur during execution, such as mismatched parameter types in function calls or undefined variables, the system captures detailed error messages. These error messages, along with the original rule text and the code previously generated by the model, are then fed back to the large language model as new contextual prompts, requiring it to reflect on and regenerate the corrected code. This process can be iterative until the code passes all checks or reaches a preset retry limit.

[0035] Finally, although the system undergoes automated verification, to ensure absolute accuracy, the generated logical expression is still submitted to domain experts for rapid manual review. Experts can quickly review the generated code, confirm its semantics are consistent with the original rules, and make necessary fine-tuning. After these steps, an accurate and error-free logical expression is obtained, which can be directly used in subsequent steps.

[0036] In this embodiment, step S2 further includes the following sub-steps: S21. Predicates with the same geometric meaning but different objects of action are grouped and preprocessed to control the number of predicates; S22. Based on the Boolean algebra completeness theorem, systematically enumerate all 2^n of the n basic predicates decomposed. n A combination of true and false assignments.

[0037] In step S21, a DRC rule logical expression is typically composed of multiple arithmetic predicates combined using logical operators such as And, Or, and Implies. For example, the rule And(( width r1 > 0.1), ( space r1r2 > 0.05) contains two arithmetic predicates. To exhaustively enumerate the test space, theoretically we need to enumerate all combinations of each predicate being true or false. However, as the number of predicates increases, the number of combinations (2^3) increases. n It will grow exponentially.

[0038] To effectively control complexity, this embodiment performs predicate grouping preprocessing before decomposition. Specifically, the system analyzes all arithmetic predicates, identifying those that have the same geometric meaning but only apply to objects of different shapes. For example, the requirement that the width of all rectangles on regular metal layer 1 must be greater than 0.05 μm might be converted into multiple similar predicates. Although these predicates apply to different objects, their geometric meaning (width constraint) is the same. The system groups them together, and during subsequent enumeration, treats a group as a single logical variable instead of splitting it into multiple independent predicates. This preprocessing method can significantly reduce the number of logical variables to be enumerated, making enumeration computationally feasible.

[0039] In step S22, after grouping the predicates, a set of independent basic predicates is obtained. Let the number of these predicates be n. According to the completeness theorem of Boolean algebra, the truth value of any logical expression composed of these n basic predicates can be obtained by considering the 2^n predicates. n The true / false assignment combinations are completely determined. Therefore, this embodiment systematically traverses all 2 possible true / false combinations through programming. n There are several combinations, and for each combination, a logical subexpression is generated, which is the conjunction of the specific assignments (true or false) of these predicates. Figure 3 The decomposition and enumeration process is illustrated schematically, in which complex rule formulas are broken down into basic predicates and subexpressions are generated by orthogonally traversing all true / false combinations.

[0040] For example, for rule logic expressionsR = A And B ,in A and B These are two basic predicates. Enumerate all four combinations: ( A = True , B = True ), ( A = True , B = False ), ( A = False , B = True ), ( A = False , B = False ), and generate a subexpression for each combination: ( A And B ), ( A And Not B ), (Not A And B ),(Not A And Not B These sub-expressions constitute a complete test space. Among them, the original rule... R The subexpression that is true is ( A And B This will be used to generate positive example test layouts; while the original rules... R The subexpression that is false is one of the three that will be used to generate a negative test layout. This enumeration method ensures that any combination of geometric relationships that may trigger or violate the rules is taken into account, thus theoretically achieving test completeness.

[0041] In this embodiment, in step S3, the satisfiability modulus solver constructs an optimization problem with the goal of minimizing the distance between the geometric parameters and the rule boundary, in order to generate a test layout that closely follows the design rule boundary.

[0042] Specifically, for each logical subexpression generated from step S2 We need to find a specific set of coordinate values, such as the position and size of the rectangle, so that... It is true. Essentially, it is a satisfiability problem. However, simply finding any set of solutions is not enough. In order to effectively test the behavior of the DRC script under boundary conditions, it is desirable for the generated layout to closely follow the boundaries of the rules, that is, to challenge the limits of the rules to the greatest extent possible.

[0043] Therefore, this embodiment constructs the solution process as an optimization problem. We use a Satisfiability Modulus Theory (SMT) solver (such as Z3) to find the optimal solution that simultaneously satisfies the constraints and the optimization objective. The optimization objective is defined as minimizing the sum of the absolute values ​​of the differences between the left and right sides of all arithmetic predicates involving the rule boundaries.

[0044] Specifically, for Each arithmetic predicate in It usually manifests as lhs ≥ rhs or lhs > rhs In the form of, lhs and rhs These represent the variables or constants on both sides of the equation or inequality, respectively. The mathematical expression for the optimization objective is: ; The summation operation iterates through the data. All arithmetic predicates The physical meaning of this optimization objective function is to drive the SMT solver to find a set of solutions that make each boundary constraint, such as spacing and width, as close as possible to its threshold. lhs Exactly equal to rhs When the value is 0, it means that the generated map is exactly on the rule boundary.

[0045] It should be pointed out that, lhs and rhs These may have different physical dimensions. To address the issue of inconsistent dimensions, before constructing the optimization objective, all components involved in the optimization will be evaluated. lhs and rhs Normalization is performed. For example, all length-related quantities, such as width and spacing, are divided by a baseline length, and all area-related quantities are divided by a baseline area, thereby transforming all terms into dimensionless pure numerical values, making their direct summation physically meaningful.

[0046] Furthermore, the SMT solver receives three sets of constraints simultaneously during the solution process: 1. By 1. Defined logical constraints to ensure that the assignment and composition of all predicates are consistent; 2. Geometric validity constraints introduced by shape definitions in the entity library, such as the coordinates of a rectangle must satisfy... x 1 < x 2, y 1 < y 2. The coordinate values ​​are within a certain range (e.g., 0-10μm); 3. Background constraints introduced by the context management module. The solver searches for a solution that minimizes the optimization objective within the solution space defined by these constraints. If a solution is found, a precise set of coordinate assignments is obtained.

[0047] Furthermore, the solved coordinate assignments are seamlessly converted into a specific GDSII format test layout using an entity library. The system will then use the logical sub-expression that generated this layout. Does it satisfy the original DRC rule logical expression? R Automatically assign a Boolean label to each map. If Contains R ,Right now → R If the result is true, the board is marked as a positive example, meaning it conforms to the rules; otherwise, it is marked as a negative example, meaning it violates the rules. Thus, a test board with a clear ground truth is obtained. Figure 4 It demonstrates the process of generating a test layout based on rule boundary conditions (such as height and width), and finally compares the labels with the script execution results to determine the judgment logic.

[0048] In this embodiment, the context management mechanism in step S4 specifically involves: identifying the layout layers involved in each design rule, dividing rules involving the same layout layer into the same rule group; when generating a test layout for the target rule, using other rules in the same group as background constraints, and inputting them together with the truth value of the target rule into the solver; if no counterexample test layout can be generated for the target rule under the background constraints, then the rule is marked as a redundant rule.

[0049] It's important to note that integrated circuit layouts consist of multiple physical layers, such as diffusion layers, polysilicon layers, and metal layers stacked together. The patterns on each layer must adhere to the design rules corresponding to that layer. Furthermore, there are mutual constraints between the patterns of different layers. If a test layout violates any fundamental rule, even if it happens to verify the boundary condition of another rule, it is an invalid test case because the DRC tool will first report the more fundamental and obvious violations, thus interfering with the verification of the target rule.

[0050] To address this issue, this embodiment first analyzes the design rule base. This is done through keyword matching, such as layer names appearing in the rule text. METAL 1. VIA 1. The system groups rules that relate to the same layer into a rule group. For example, all rules related to metal layer 1 (… Metal 1) Relevant rules, including width, spacing, area, and through-hole coverage, are categorized as follows: Metal 1. Rule group.

[0051] In verification MetalWhen defining a target rule within a rule group, the system treats all other rules in that group as context or background constraints. During the solution process in step S3, these background constraints are forcibly added to the SMT solver's constraints. This means that when the solver searches for coordinate solutions that satisfy a specific logical combination of the target rule, the generated layout must simultaneously comply with the constraints of all other rules within the group. This ensures that the generated test layout is physically valid, eliminating the possibility of interference from other rules.

[0052] Furthermore, the context management mechanism in this embodiment can intelligently identify redundant rules. During the verification process, if for a target rule, after applying background constraints from other rules in the same group, the SMT solver cannot find any valid counterexample test layouts—that is, all logical sub-expressions cannot find solutions while satisfying the background constraints—this means that the constraints imposed by the target rule have been implicitly covered by other rules in the group. For example, if a rule specifies a minimum area, and the product of the minimum width and minimum height specified by other rules is greater than that area, then that area rule is redundant. The system will automatically mark these rules as redundant and output them to the engineers. This helps to simplify DRC scripts, optimize the foundry's inspection process, and reduce unnecessary computational overhead.

[0053] To verify the effectiveness and superiority of the method proposed in this embodiment in practical applications, systematic experimental verification was conducted on a publicly available process design kit (PDK).

[0054] Experimental Setup: This experiment was run on a Linux workstation equipped with a 2.6GHz Intel Xeon CPU. The entire automation framework was implemented using Python 3.8. For step S1, a large language model engine such as DeepSeek-R1 was used, and prompt words containing 5 rule-logic transformation examples were designed. For step S3, the Z3 solver was integrated as a satisfiability modulo theory solver. The experimental dataset used the widely used, publicly available design rule library for advanced process nodes: FreePDK15 (15nm process), which contains 112 rules.

[0055] After the experiment, the system automatically categorized the processing results of each rule and compared them with the original DRC script provided by the foundry. The overall verification results are shown in Table 1.

[0056] Table 1: Overall Statistics of FreePDK15 Validation Results

[0057] As shown in Table 1, out of 112 rules in FreePDK15, 86 were confirmed to be correct, 18 errors were captured, and 8 redundancies were identified. The proposed method not only successfully confirmed the correctness of most rule scripts but also actively identified several undiscovered human-made script errors and screened out some redundant rules that could be optimized. The results fully demonstrate the effectiveness of this method.

[0058] Typical Error Capture Case Analysis: Through in-depth analysis of the captured errors, the framework of this invention successfully discovered several types of hidden errors that are difficult for even experienced engineers to detect.

[0059] Case A: Mathematical symbol mismatch. In several rules in FreePDK15, the rule text explicitly specifies the constraint as "greater than (>)", but the actual script incorrectly uses "greater than or equal to (>=)". This invention, because the optimization solver always seeks a test layout that closely follows the rule boundaries, can accurately generate test cases that fall on the boundary values, thus exposing this subtle discrepancy.

[0060] Case B: Incomplete script and missing conditions. In FreePDK15's linewidth check, the rule defines multiple allowed width options, but the script only checks the "minimum width," resulting in incomplete validation.

[0061] Case C: Complex geometry check error. In FreePDK15 testing, the system found that the DRC script for square vias failed to correctly identify dimensions of a × (a+1) nm. 2 The system explicitly outputs the coordinates of the non-compliant rectangles, assisting engineers in correcting the code to include strict opposition constraints in the checking logic.

[0062] Redundant rule identification case analysis: The context management mechanism of this invention can automatically screen out redundant rules. Under the constraints of other rules at the same level, the solver cannot generate any valid counterexample layouts for these rules.

[0063] Area redundancy: The minimum area specified by a certain rule is actually equal to the product of the minimum width and minimum height rules, and is implicitly satisfied.

[0064] Spacing redundancy: Under specific pitch and linewidth constraints, due to geometric locking, topology situations that violate the spacing rules are physically impossible.

[0065] Grid alignment redundancy: When the rule forces all polygon edges to be aligned to a specific underlying grid, some spacing constraints are naturally met without the need for additional computational power to check.

[0066] System operational efficiency analysis: The entire verification process demonstrated extremely high efficiency. The total time for all tests was only 2367.19 seconds. Specifically, the large language model processing in the "rule-to-logic" phase took 474.01 seconds, manual alignment and verification took 1090.54 seconds, Z3 solving to generate test cases took 194.88 seconds, and finally, Calibre execution and comparison took 607.76 seconds. Compared to the timeframe of manually hand-drawn diagrams, which can easily take months, this represents an efficiency improvement of several orders of magnitude.

[0067] In summary, this invention can not only be used for verification but also integrated into an automated DRC script generation process to provide closed-loop feedback. Taking DeepSeek-R1 as a large-scale script generation model as an example: in the task of generating center alignment rules, the initial script generated by the model encountered an error when handling test cases where two graphs did not overlap. The framework of this invention automatically feeds back the coordinates of the failed test layout and the rigorous Python logic extracted from the rule-to-logic steps as prompts to the large-scale model. After receiving the feedback, the large-scale model realizes that the alignment rule only takes effect when there is physical interaction between the two graphs, and thus automatically adds interaction filters in the second iteration, successfully generating a logically complete final script that passes all tests. This demonstrates that this invention can greatly reduce the cost of manual intervention and significantly improve the quality of automatically generated DRC scripts.

[0068] Example 2

[0069] Figure 5 A schematic diagram of an electronic device structure that can be used to implement Embodiment 1 of the present invention is shown. The electronic device 10 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0070] like Figure 5As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., which is communicatively connected to the at least one processor 11. The memory stores a computer program that can be executed by the at least one processor 11, and the computer program is executed by the at least one processor 11 to enable the at least one processor 11 to perform the method provided by the present invention.

[0071] Furthermore, the processor 11 can perform various appropriate actions and processes based on a computer program stored in the read-only memory (ROM) 12 or a computer program loaded from the storage unit 18 into the random access memory (RAM) 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0072] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0073] Furthermore, processor 11 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as methods for resource management of a database.

[0074] In some specific embodiments, the method for managing database resources can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the method for managing database resources described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to perform the method for managing database resources by any other suitable means (e.g., by means of firmware).

[0075] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard parts (ASSPs), systems-on-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0076] Computer programs used to implement the methods of the present invention can be written in any combination of one or more programming languages. These computer programs can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer programs can be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0077] In the context of this invention, a computer-readable storage medium stores computer instructions that, when executed by a processor, implement the method for resource management of a database provided by this invention. The computer-readable storage medium may be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. The computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, the computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0078] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device for displaying information to the user (e.g., a cathode ray tube (CRT) or a liquid crystal display (LCD monitor)); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0079] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0080] Optionally, the computing system may include clients and servers. Clients and servers are generally geographically separated and typically interact via a communication network. The client-server relationship is established by computer programs running on the respective computers and having a client-server relationship with each other. The server may be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system. This addresses the shortcomings of traditional physical hosts and Virtual Private Server (VPS) services, such as high management difficulty and weak business scalability.

[0081] The above description is based on the preferred embodiments of the present invention. It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered exemplary and non-limiting in all respects. The scope of the invention is defined by the appended claims rather than the foregoing description, and all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0082] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A method for automatically generating positive and negative examples of DRC design rules based on large language models and formal verification, characterized in that, Includes the following steps: S1. Using a large language model, design rules described in natural language are transformed into logical expressions based on layout geometric relationships; S2. Decompose the logical expression into several basic predicates, and perform a full-coverage enumeration of the truth value combinations of the basic predicates based on the Boolean algebra space to construct a complete test space. S3. Input the truth value combination obtained by enumeration as a constraint condition into the satisfiability modular theory solver for solving. Generate a test layout by mapping the coordinates obtained from the solution. Assign positive and negative examples that represent compliance with or violation of the rules to the test layout according to whether the corresponding truth value combination satisfies the original logical expression. S4. Introduce a context management mechanism based on layout layer information, introduce background constraints of associated rules when generating test layouts, and identify redundant rules in the design rule base.

2. The method for automatically generating positive and negative examples of DRC design rules based on large language models and formal verification as described in claim 1, characterized in that: Step S1 further includes the following steps: S11. Establish a solid library for defining the geometry of the layout and a function library for expressing geometric relationships; S12. Input the natural language design rules and examples into the large language model, so that it calls the entity library and function library to generate the corresponding logical expression code; S13. Perform syntax and runtime checks on the generated code, and if errors occur, feed back the error information to the large language model for correction.

3. The method for automatically generating positive and negative examples of DRC design rules based on large language models and formal verification as described in claim 1, characterized in that: Step S2 further includes the following steps: S21. Predicates with the same geometric meaning but different objects of action are grouped and preprocessed to control the number of predicates; S22. Based on the Boolean algebra completeness theorem, systematically enumerate all 2^n of the n basic predicates decomposed. n A combination of true and false assignments.

4. The method for automatically generating positive and negative examples of DRC design rules based on large language models and formal verification as described in claim 1, characterized in that: In step S3, the satisfiability modulus solver constructs an optimization problem with the objective of minimizing the distance between the geometric parameters and the rule boundary, in order to generate a test layout that closely follows the design rule boundary.

5. The method for automatically generating positive and negative examples of DRC design rules based on a large language model and formal verification as described in claim 4, characterized in that: The optimization objective of the optimization problem is expressed as: ;in, lhs and rhs They represent Each arithmetic predicate The left and right sides.

6. The method for automatically generating positive and negative examples of DRC design rules based on large language models and formal verification according to claim 1, characterized in that: In step S4, the context management mechanism specifically involves: identifying the page layers involved in each design rule, and grouping rules involving the same page layer into the same rule group; When generating a test layout for the target rule, other rules in the same group are used as background constraints and combined with the truth values ​​of the target rule and input into the solver. If no counterexample test layout can be generated for the target rule under the background constraints, then the rule is marked as a redundant rule.

7. The method for automatically generating positive and negative examples of DRC design rules based on large language models and formal verification as described in claim 1, characterized in that: The method is also applied to the automated closed-loop correction of DRC scripts. Specifically, the generated test layout and its positive and negative example labels, as well as the logical expression generated in step S1, are used as feedback information and input into the large language model used to generate DRC scripts to guide it to correct the generated scripts.

8. The method for automatically generating positive and negative examples of DRC design rules based on large language models and formal verification according to claim 1, characterized in that: The logical expression generated in step S1 is formed by combining geometric conditions using logical operators. The basic predicate in step S2 is an arithmetic predicate.

9. An electronic device, characterized in that, include: At least one processor; and a memory communicatively connected to at least one of the processors; The memory stores a computer program executed by at least one of the processors, which enables the at least one processor to execute the automatic generation method for positive and negative examples of DRC design rules based on a large language model and formal verification, as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the automatic generation method for positive and negative examples of DRC design rules based on a large language model and formal verification, as described in any one of claims 1-8.

Images