Automatic development closed-loop method and system for sign-off level layout rule checking

Abstract

The application discloses an automatic development closed loop method and system for signature level layout rule checking, and belongs to the technical field of integrated circuit layout automatic checking. The method obtains a process design kit, rule description data and reference results, analyzes the rule description data and extracts candidate rule parameters, establishes a corresponding relationship between the candidate rule parameters and rule configuration items, rule detection instructions or rule detection codes, generates initial design rule configurations and / or rule detection codes, obtains test layout containing existing design layout, automatically generated layout and / or supplementary graphics, respectively performs rapid checking and final checking, normalizes two types of checking results into a unified record format, performs rule level and position level difference analysis on the reference results, iteratively updates the rule configurations, rule detection codes and test layout according to the analysis results, and enters the next rule development until the generated results and the reference results converge and are consistent. The method improves the automation degree and efficiency of rule development.

Description

Technical Field

[0001] This invention belongs to the field of automatic integrated circuit layout inspection technology, specifically relating to an automated development closed-loop method and system for inspection of layout rules at the approval level. Background Technology

[0002] Design Rule Check (DRC) is a crucial step in verifying whether the integrated circuit layout conforms to process constraints before chip manufacturing. As process nodes continue to shrink, the number and complexity of design rules increase dramatically. A single advanced process can have thousands of design rules, which are interconnected and influence each other. The quality of rule development directly determines chip yield and time-to-market.

[0003] The existing layout rule development process typically consists of several independent steps. Designers prepare the Process Design Kit (PDK), rule documents, and test layouts; developers understand the meaning of the rules based on the rule documents, manually extract parameters, and write checking programs; verification personnel run the checking process and manually review the result reports to determine if the rule implementation is correct; finally, they modify the rule configuration or supplement test samples based on experience. Because there is a lack of unified closed-loop management between rule parameter extraction, rule configuration generation, checking execution, result verification, and iterative correction, problems such as missing rule configurations, mismatched parameters, misuse of constraints, and failure to converge results are prone to occur.

[0004] Specifically, the existing process has the following shortcomings:

[0005] (1) Process design kits, rule descriptions, rule parameters, rule detection codes, test layouts and inspection results are usually processed separately, lacking a complete correlation from the source of the rule to the output conclusion.

[0006] (2) The rule parameters rely heavily on manual reading and input, making it difficult to reliably identify the rule objects, applicable conditions, geometric relationships, hierarchical requirements and parameter values.

[0007] (3) The scope of application of the rules is not accurately identified, which may result in rules that are only applicable to specific devices, regions, layer combinations or process options being mistakenly written into the general configuration.

[0008] (4) The lack of a unified expression of status such as failure to check, rule not being implemented, parameter uncertainty and result difference makes it easy to mistake unverified content for completed content.

[0009] (5) Differences after each round of verification usually rely on manual recording and cannot be automatically converted into rule configuration revision, rule detection code revision, sample supplementation or re-execution of tasks. Summary of the Invention

[0010] To address the aforementioned technical issues, this invention proposes an automated development closed-loop method and system for signing-level layout rule checks. This system integrates rule parameter extraction, rule configuration generation, test layout preparation, check execution, result analysis, and iterative correction into a unified closed loop, thereby reducing manual intervention and improving rule development efficiency and accuracy.

[0011] To achieve the above objectives, the present invention adopts the following technical solution:

[0012] In a first aspect, the present invention provides an automated development closed-loop method for checking layout rules at the approval level, including:

[0013] Obtain process design kits, rules to be developed, rule description data, process environment information, and reference results;

[0014] Parse the rule description data and extract candidate rule parameters, establish the correspondence between the candidate rule parameters and rule configuration items, rule detection instructions or rule detection codes, and generate initial design rule configuration and / or initial rule detection code;

[0015] Obtain a test layout, which includes an existing design layout, a layout automatically generated according to the inspection requirements, supplementary graphics, or a combination thereof. Perform an automatic quick inspection on the test layout according to the initialization design rule configuration and / or initialization rule detection code to obtain a quick inspection result, and perform a final inspection to obtain a final inspection result. The quick inspection is used to provide feedback on intermediate verification during the iteration process, and the final inspection is used to form a formal verification basis.

[0016] The rapid inspection results and the final inspection results are normalized and converted into a unified record format. Rule-level analysis, location-level analysis and result verification are performed on the reference results and the normalized generated results to determine whether the results are consistent, inconsistent or incomplete.

[0017] Update the rule configuration items, rule detection instructions or rule detection codes, test layout and task status based on the results of the review;

[0018] If the generated result does not converge with the reference result, the iteration continues. When the generated result converges, the development of the next rule begins, until the development of the predetermined rule set is completed, and the converged rule configuration, rule detection instructions or rule detection code and quality evaluation results are output.

[0019] Preferably, the process environment information includes one or more of the following: target process, layout layer information, design object, layout data expression relationship, and check operation conditions, which are used to extract, instantiate, and interpret the results of constraint candidate rule parameters.

[0020] Preferably, the candidate rule parameters are obtained by parsing natural language rule text, structured rule tables, existing rule descriptions, rule examples, or combinations thereof, and are associated with and stored with rule objects, applicable conditions, geometric relationships, hierarchical requirements, parameter values, and expected results.

[0021] Preferably, when establishing the correspondence, the mapping relationship between candidate rule parameters and rule configuration items, rule detection instructions or rule detection codes is determined based on rule semantics, process environment information, rule configuration templates and reference results; when the reference results are inconsistent with the generated results or the generated results are not completed, the corresponding rule configuration items, rule detection instructions or rule detection codes are modified according to the result review conclusion, and the check is re-executed.

[0022] Preferably, the rule description data includes the applicable conditions of the rule, and the rule configuration items, rule detection instructions or rule detection codes are generated based on the applicable conditions and the corresponding rule content, so that the generated rules are executed only under the corresponding layout, layer combination, device or process conditions.

[0023] Preferably, the automatically generated layout includes expected trigger samples, boundary samples, and legal comparison samples; the supplementary graphics are graphics inserted in a specified area of ​​the existing design layout to supplement the coverage of specific rules.

[0024] Preferably, the normalization process includes converting the quick check results and the final check results into a unified record. The unified record includes task number, rule identifier, layout file, hierarchical path, result location, result type, result quantity, and log location. The rule-level analysis and location-level analysis include rule-level difference analysis, location-level difference analysis, and difference source classification, and the results are divided into three categories: consistent results, inconsistent results, and incomplete results.

[0025] Preferably, the task status is divided into three categories: pending execution, in execution, and completed; when the results are inconsistent or incomplete, a rule configuration item revision task, a rule detection instruction or rule detection code revision task, a test layout supplement task, a result review task, or a re-execution task is generated.

[0026] Preferably, the convergence consistency includes the reference result and the generated result being consistent within a predetermined rule range, a predetermined map range, or a predetermined location range, or being confirmed by result verification to meet a predetermined verification target.

[0027] The steps involved in the above methods, such as natural language parsing, parameter extraction, semantic mapping, and code generation, can be executed by rule parsing models, generative models, programmatic parsers, template generators, or combinations thereof.

[0028] Secondly, this invention provides an automated development closed-loop system for approval-level layout rule checking, including:

[0029] The process design kit input module is used to obtain the process design kit, rules to be developed, rule description data, and reference results;

[0030] The process environment information acquisition module is used to acquire process environment information;

[0031] The rule description parsing module is connected to the process design kit input module and the process environment information acquisition module, respectively, and receives the rule description data and the process environment information, and parses the rule description data;

[0032] The candidate rule parameter extraction module is connected to the rule description parsing module and extracts candidate rule parameters from the parsing results.

[0033] The parameter mapping module is connected to the candidate rule parameter extraction module, and establishes the correspondence between the candidate rule parameters and rule configuration items, rule detection instructions or rule detection codes based on the process environment information and the reference results;

[0034] The rule configuration and code generation module is connected to the parameter mapping module and generates initialization design rule configuration and / or initialization rule detection code according to the correspondence.

[0035] The layout preparation module is connected to the rule configuration and code generation module. It obtains a test layout based on the initialization design rule configuration and / or initialization rule detection code. The test layout includes one or more of the following: an existing design layout, an automatically generated layout, and supplementary graphics.

[0036] An automatic quick check module is connected to the layout preparation module to perform a quick check on the test layout and obtain the quick check result.

[0037] The final inspection module is connected to the layout preparation module, performs a final inspection on the test layout, and obtains the final inspection result.

[0038] The result unification module is connected to the automatic rapid inspection module, the final inspection module, and the process design kit input module, respectively, to convert the rapid inspection results and the final inspection results into a unified record format, and to receive the reference results;

[0039] The difference analysis module, connected to the result unification module, performs rule-level and position-level analysis on the generated results of the unified record format and the reference results to determine whether the results are consistent, inconsistent, or incomplete.

[0040] The convergence judgment module is connected to the difference analysis module to determine whether the generated result is consistent with the reference result in terms of convergence.

[0041] The task scheduling module is connected to the convergence judgment module, the rule configuration and code generation module, and the layout preparation module, respectively. When convergence fails, it triggers the rule configuration and code generation module to update the rule configuration and / or rule detection code based on the difference analysis results, and / or triggers the layout preparation module to update the test layout and reschedules the inspection task. When convergence occurs, the current rule task ends and the next rule task is started.

[0042] The status management module is connected to the task scheduling module and each inspection module to maintain the working status of each task.

[0043] Compared with the prior art, the beneficial effects of the present invention are:

[0044] This invention organizes process design kits, rule description data, candidate rule parameters, rule configurations, rule detection codes, test layouts, and inspection results into a unified task management system. It establishes a complete correlation between rule sources and verification conclusions within each task, reducing the workload of manual transmission and repetitive registration. Simultaneously, it receives real, complex layouts and automatically generates supplementary samples, balancing the complexity and interpretability of testing. This allows rule verification to be tested in real design scenarios and also to be targeted at specific rules. Through unified result recording and two-level difference analysis at the rule and location levels, it reduces the workload of manually comparing reference and generated results and improves the accuracy of difference location. Status and result record management clearly distinguishes between executed, verified, pending review, and incomplete tasks, preventing unverified content from being mistakenly considered completed. Through rule scope identification and result review mechanisms, it reduces the risk of incorrect extraction and writing of rule parameters into general configurations. Through difference feedback, it automatically generates the next round of rule configuration revision, rule detection code revision, or sample supplementation tasks, creating a continuous closed loop for rule parameterization, rule development, and test data construction, significantly improving the iterative efficiency and quality controllability of rule development. Attached Figure Description

[0045] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments are briefly introduced below.

[0046] Figure 1 This is a schematic diagram of the automated development closed-loop framework for signing-level layout rule checking according to the present invention.

[0047] Figure 2 This is a schematic diagram of the process design suite of the present invention, including rule transformation, parameter mapping, and task generation.

[0048] Figure 3This is a schematic diagram of the test layout preparation and input inspection process for this invention.

[0049] Figure 4 This is a schematic diagram of the inspection result review and archiving process of the present invention.

[0050] Figure 5 This is a schematic diagram of the process for analyzing differences in results, revising products, and providing task feedback in this invention. Detailed Implementation

[0051] The technical solution of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments. The following embodiments are only used to more clearly illustrate the technical solution of the present invention, and are not intended to limit the scope of protection of the present invention. Those skilled in the art can adjust, replace, or combine the input source, processing order, data organization form, mapping method, convergence condition, and module combination method according to specific process nodes, layout types, rule expression methods, and execution environments, all of which belong to the embodiments of the present invention.

[0052] Example 1: Complete Closed-Loop Process

[0053] This embodiment takes the development of a minimum spacing rule for metal layers as an example to illustrate the complete closed-loop operation process of the present invention from rule parameter extraction to result convergence.

[0054] Phase 1: Project Initialization and Rule Resolution (See also) Figure 1 , Figure 2 )

[0055] The first step is to establish a task directory. The operator creates a task directory in the system, named "M1_minSpacing_001," and generates a configuration file within it. This configuration file records the basic information for this task: the input layout list points to a complex hierarchical layout containing multiple standard cells and macrocells; the rule file list points to files containing descriptions of the rules to be developed; the execution environment points to the configured runtime environment of the inspection tool; the output directory points to the location where the results are stored; and the verification target is set to ensure that the reference results and generated results are completely consistent across all test layouts. For example... Figure 1 As shown, this step corresponds to the "Configuration Setup" stage in the overall framework.

[0056] The second step is to register the original input. The system reads the process design kit, rules to be developed, rule description data, process environment information, and reference results through the process design kit input module and the process environment information acquisition module. The process design kit provides basic data such as the layer number, layer name, and minimum spacing nominal value of the metal layer. The process environment information records the design object type (interconnect), layout data expression relationship (polygon coordinate expression method), and check operating conditions (units, precision, etc.) of the metal layer. The system performs readability verification and hierarchical integrity checks on the layout file, reads metadata such as the top-level unit name, available layer list, and coordinate range, and records the file size and modification time as audit information. After successful verification, the system saves the original input along with the task number.

[0057] The third step is to organize the rule input. The rule description parsing module reads the rule description data. In this embodiment, the rule description is a piece of natural language text: "In metal layer 1 (M1), the edge spacing between patterns belonging to different electrical networks shall not be less than 0.05 micrometers." Figure 2 As shown, this step corresponds to the "Register Process Design Kit, Rules to be Developed, and Rule Description Data" stage in the rule organization process. The candidate rule parameter extraction module identifies the following candidate parameters from the description: the rule object is "Metal Layer 1 graphic", the applicable condition is "belonging to different electrical networks", the geometric relationship is "edge spacing", the parameter value is "0.05 micrometers", and the expected result is "the non-compliant graphic is marked". The system assigns a unique internal identifier "RUL_M1_SP_001" to this rule and saves the rule source, rule meaning, candidate rule parameters, applicable conditions, required inputs, expected outputs, and verification requirements. Simultaneously, the system checks whether the rule name is duplicated, whether the referenced object (Metal Layer 1) exists, and whether the parameters are complete. After confirming that everything is correct, it proceeds to the next stage.

[0058] The fourth step is to generate the rule configuration and rule detection code. For example... Figure 2As shown in the "Parameter Mapping" and "Rule Code Generation" stages, the parameter mapping module establishes a correspondence between candidate rule parameters, rule configuration items, and rule detection commands based on rule semantics, process environment information, rule configuration templates, and reference results. In this embodiment, the mapping relationship is as follows: the rule object "Metal Layer 1 Graphic" is mapped to the input layer parameter "LAYER M1" of the inspection tool; the applicable condition "Different Electrical Networks" is mapped to the connectivity constraint parameter "NET_EXCLUSIVE" of the inspection tool; the geometric relationship "Edge Spacing" is mapped to the inspection command "EXTERNAL"; and the parameter value "0.05 micrometers" is mapped to the spacing threshold "SPACING=0.05". The rule configuration and code generation module generates initial rule detection code based on the above mapping relationship, including complete rule statements and necessary context declarations. The generated code is associated with the original rule, and after syntax checking and interface format checking, it forms the initial rule task.

[0059] The fifth step is to generate rule tasks. The system establishes a task list based on rule records, parameter mapping relationships, generated rule configurations, and rule detection code, associating the input layout, execution order, output files, and verification requirements. Because the rules in this embodiment have clear semantics and complete parameters, the system marks them as directly executable, without generating additional manual review tasks.

[0060] Phase Two: Test Layout Preparation

[0061] Step 6: Prepare a sample real map. For example... Figure 3 As shown, the layout preparation module first performs "Layout Source Registration" and "Layout Hierarchical Integrity Check". The module reads the original complex layout as a background sample, which contains multiple design modules, has a complete layer structure, and possesses realistic geometric relationships. The system does not modify or redraw its natural geometric relationships. To adapt to the inspection environment, the system performs necessary format conversions (e.g., from one database format to another), but the conversion operation generates new derived files. The input files, output files, conversion parameters, and audit information before and after the conversion are recorded in the manifest. The original layout and the derived layout are saved separately.

[0062] Step 7: Generate supplementary samples. For example... Figure 3As shown in the "Supplementary Sample Generation" stage, the system scans the rule task list to determine whether relying solely on the real-world layout is sufficient to cover all test scenarios for that rule. Since real-world layouts may not necessarily contain instances where the spacing is close to the threshold, the system decides to generate supplementary samples. The supplementary sample generation module generates three sets of graphics based on the rule parameters: the first set is the expected trigger sample, with a spacing of 0.04 micrometers between the two metal lines (less than 0.05 micrometers); the second set is the boundary sample, with a spacing of 0.05 micrometers between the two metal lines (exactly equal to the threshold); and the third set is the legal control sample, with a spacing of 0.06 micrometers between the two metal lines (greater than the threshold). The three sets of supplementary samples use independent cell names, and the generation rule, geometric parameters, insertion position, expected result, and generation script version are recorded in the list.

[0063] Step 8: Merge test tasks. For example... Figure 3 As shown in the "Combining into Test Layout Task Package" stage, the system does not directly modify the original layout, but instead creates a test task layout. The test task layout uses the original complex layout as a background, adding supplementary units to the blank areas of the layout. The system records the relationship between the background layout and the supplementary graphics in the list, marking the source of each expected violation: violation graphics already existing in the natural layout are marked as "natural source," and violation graphics in the supplementary sample are marked as "construction source." In this way, when violations are subsequently discovered, the source label can be used to distinguish whether the problem is in the actual design or in the constructed sample.

[0064] Step nine: Perform input checks. For example... Figure 3 As shown in the "Input Check" phase, the system reopens the test task layout to confirm that the top-level unit exists, the layout file is readable, all required input layers are available, the coordinate range has not changed abnormally, and the supplementary unit is located in the predetermined area without unexpectedly overlapping with the background graphic. The check results are written to the checklist and task log. In this embodiment, all check items pass, and the task enters the check execution phase.

[0065] Phase 3: Dual-process inspection execution and result archiving

[0066] Step 10: Perform a quick check. For example... Figure 4 As shown, the system sends the "layout and rule inputs" to the quick check process and the final check process, respectively. The automatic quick check module generates quick check commands based on the rule task list, taking the test task layout, quick check rule file, runtime configuration, and output path as command inputs. The execution adapter records the actual executed commands, working directory, environment information, start time, and end time. The quick check uses lower precision settings and a simplified output format to shorten the runtime. After the check is completed, the system verifies the existence of the exit code and result file, and reads the basic structure of the result file. In this embodiment, the quick check completes normally, generating a preliminary result file.

[0067] Step 11: Save the quick check results. The system will save the quick check results and related logs to the task directory, recording the basic results of this check (number of violations detected, running time, exit status) and running status.

[0068] Step 12: Prepare the final check package. The system extracts the layout, original rule files, necessary runtime configurations, and task list from the quick check task to generate the final check package. The final check package contains input file checksums and version information to ensure that the input files have not been accidentally modified in subsequent execution stages.

[0069] Step 13: Perform the final check. (For example...) Figure 4 As shown in the "Final Inspection Flow," the final inspection module performs a final inspection on the test layout. In this embodiment, the final inspection is performed in the same computing environment. The module uses full precision settings and detailed result formats to generate a final result file, a run summary, and a log. The final inspection takes longer but yields more accurate results.

[0070] Step fourteen: Import the final result. For example... Figure 4 As shown in the "Results files and logs are summarized to form archived results" stage, the system verifies the final returned result files to confirm that the result files, logs, and execution summaries are complete, and checks whether the result files match the task numbers. After passing the verification, the system imports the results into the result directory.

[0071] Phase 4: Difference Analysis, Product Revision and Iterative Feedback

[0072] Step 15: Normalize the results. For example... Figure 5 As shown in the "Result Normalization" stage, the result unification module reads both the quick check results and the final check results. The quick check results use a simplified coordinate format, while the final check results use a detailed polygon coordinate list format. The normalization process converts both types of results into a unified record format. Each record includes the task number, rule identifier, layout file, hierarchical path, result location, result type, result quantity, and log location. For rule names, the system uses a rule mapping table to unify the potentially different naming conventions in the quick check and final check into an internal rule identifier. The original result files are not deleted during the normalization process; all original data is retained for future reference.

[0073] Step sixteen: Perform rule-level comparisons. For example... Figure 5As shown in the "Rule-Level Difference Analysis" stage, the difference analysis module summarizes the reference results and generated results according to internal rule identifiers. The reference results indicate that there are 5 spacing violations on metal layer 1 in this test layout; the quick check results detect 5 violations, and their locations are consistent with the reference results; the final check results detect 5 violations, and their locations are consistent with the reference results. At the rule-level, the reference results are consistent with both types of generated results. For supplementary samples, the system also checks whether the expected results are consistent with the actual results: expected triggering samples are correctly detected, expected non-triggering samples are not falsely reported, and the determination of boundary samples meets the threshold definition.

[0074] Step seventeen, perform positional comparisons. For example... Figure 5 As shown in the "Location-Level Difference Analysis" stage, since the rule-level comparison results are consistent, the location-level comparison further confirms that the location coordinates, hierarchical path, and geometric range of each violation match the reference results within the allowable error range. In this embodiment, the location information of all 5 violations matches.

[0075] Step eighteen: Explain the source of the difference. For example... Figure 5 As shown in the "Difference Source Classification" stage, since the reference result and the generated result are completely consistent, the difference source classification result is "no difference". The system records this conclusion.

[0076] Step nineteen: Update the state and rule outputs. For example... Figure 5 As shown in the "Product Revision" and "Task Feedback" phases, the convergence judgment module determines that the generated result is consistent with the reference result. The status management module marks the current rule task as completed. The rule configuration and code generation module marks the current version of the rule detection code as a verified version.

[0077] Step 20: Generate the next round of tasks. Since the current rule has converged, the task scheduling module ends the current rule task, retrieves the next rule from the list of rules to be developed, starts a new round of development, and returns. Figure 1 The overall closed-loop starting point is shown. If the list of rules to be developed is empty, proceed to the final output stage.

[0078] Step 21: Archive this closed-loop process. The system saves rule configurations, rule detection code, test layout, quick check results, final check results, result review conclusions, quality evaluation results, status changes, and task lists, forming a complete closed-loop record.

[0079] This completes the closed loop of automated development for a design rule.

[0080] Example 2: Iterative Correction Scenario

[0081] This embodiment illustrates how the system achieves convergence through automatic iteration when the generated result differs from the reference result. Taking the via enclosure rule as an example, the rule requires a minimum enclosure distance of 0.03 micrometers between the via edge and the upper metal edge. After the system completes the initial rule configuration generation, test layout preparation, and dual-process check according to the process in Embodiment 1, rule-level comparison reveals that the reference result detects three violations of insufficient via enclosure, while the generated result only detects one. Location-level comparison further pinpoints the difference: the two missed violations are both located at the edge of the via array.

[0082] The difference analysis module categorizes the source of the difference and determines that it falls under the category of "geometric relationship expression error"—the bounding distance check in the rule configuration only applies to the four directions of via (up, down, left, and right), ignoring the bounding distance requirement in the diagonal direction. Based on the review conclusion, the task scheduling module triggers a rule detection code revision task, the parameter mapping module adjusts the geometric relationship mapping, expanding the inspection direction from four directions to eight directions. The rule configuration and code generation modules update the rule detection code accordingly, the layout preparation module reuses the test layout from the previous round, and the task scheduling module reschedules the quick check and final check.

[0083] After the second iteration, three violations were detected in the generated results, which were consistent with the reference results at both the rule and location levels, leading the system to determine convergence. This iteration took approximately twenty minutes and required no manual code modification.

[0084] Example 3: Collaborative Execution in Local and Isolated Environments

[0085] This example illustrates how to perform rapid checks and final checks in different computing environments. The rule development environment of an integrated circuit design company is located on an intranet, while the final check tool runs in an isolated dedicated computing cluster; the two environments cannot be directly interconnected.

[0086] The system completes rule parameter extraction, rule configuration and code generation, test layout preparation, and input checks in the local environment. Subsequently, the automatic quick check module performs a rapid check locally to quickly obtain preliminary verification results. For the final check, the system generates an exchange package containing the layout file, rule file, configuration snapshot, and task list, and exports the exchange package to the isolated environment. The execution adapter in the isolated environment receives the exchange package and re-verifies the checksums of the input files before execution. Once confirmed to be consistent with the exchange package list, the final check program is started. After the final check is completed, the system packages the final result file, runtime summary, and logs into a result package and returns it. The local system verifies, imports, and performs discrepancy analysis on the returned result package.

[0087] In this embodiment, the rapid check provides three rounds of iterative feedback within 20 minutes. Developers utilize this rapid feedback to quickly correct two deviations in the parameter mapping, ultimately passing the final check on the first attempt in an isolated environment. This method ensures that the invention maintains closed-loop iterative efficiency even under constrained execution environments.

[0088] Example 4: Parallel Development with Multiple Rules

[0089] This embodiment illustrates an implementation method for parallel execution of multiple rule tasks. The system simultaneously registers development tasks for four rules: minimum metal layer spacing rule, minimum via size rule, minimum metal line width rule, and maximum metal layer density rule. Each rule task independently saves rule records, candidate rule parameters, rule configuration / code, test layout, and intermediate results.

[0090] For the test layout, some rules share the same real-world layout background, but each is supplemented with targeted additional samples. Each task performs quick and final checks independently, without interference. The merging module aggregates results according to rule and sample identifiers.

[0091] The state management module maintains the status of four tasks: the minimum spacing rule for metal layers converged after the third iteration and is marked as completed; the minimum via size rule converged in the first iteration and is marked as completed; the minimum width rule for metal lines is undergoing its fifth iteration and is marked as running; and the maximum density rule for metal layers is blocked due to the lack of a specific graphic type in the input layout and is marked as needing supplementary samples. The task scheduling module allocates computing resources to running tasks based on their status and priority, and simultaneously generates supplementary sample tasks for blocked tasks.

[0092] In this embodiment, the total development time for the four rules is reduced by approximately 60% compared to sequential development. The system can prioritize handling rules with high-frequency differences, lacking result records, and representative complex layouts according to task priority, further shortening the overall closed-loop feedback time.

[0093] Example 5: Selection of Candidate Multi-Parameter Configuration

[0094] This embodiment illustrates how the system determines the optimal configuration from multiple candidate parameter configurations when the meaning of a rule has multiple possible interpretations. Taking the rule of "minimum distance between the edge of the well and the edge of the active region" as an example, the rule description data does not specify whether "distance" refers to the shortest distance between the boundary of the well and the boundary of the active region or the distance from the boundary of the well to the boundary of the active region, nor does it specify whether it includes the corner region of the well.

[0095] The rule description parsing module extracts two possible parameter interpretations from the same rule description. The parameter mapping module generates two sets of candidate rule configurations based on these two interpretations. The system prepares test layouts for each set of candidate configurations and performs checks and difference analyses. The first set of candidate configurations (shortest distance) passes all samples and is consistent with the reference result; the second set of candidate configurations (orthogonal directions only) is inconsistent with the reference result in corner region samples. Based on the coverage and iterative stability of the reference result, the system determines the first set of candidate configurations as the preferred configuration.

[0096] When multiple candidate configurations pass some samples but fail to converge completely, the system retains all candidate configurations and their verification records, generates a manual review task, and allows experienced developers to make the final selection based on the complete context. This approach maintains automation efficiency while employing a prudent handling strategy for uncertainties.

[0097] The above embodiments demonstrate that the present invention can achieve an automated closed loop from rule parameter extraction to result convergence in different application scenarios, significantly reducing the degree of manual intervention and improving the efficiency and reliability of rule development. The specific values, layer names, rule types, etc., in each embodiment are for ease of understanding only and do not constitute a limitation on the scope of protection of the present invention.

[0098] In different implementations, the process design kit, rules to be developed, rule description data, and reference files can come from the same process platform or different controlled data sources; rule configuration, rule detection instructions, or rule detection code can be implemented using different rule languages, scripting languages, configuration languages, parameter tables, or combinations thereof; quick checks and final checks can be performed in the same computing environment or different computing environments, or can be performed once or multiple times, serially or in parallel, depending on the task requirements.

[0099] The test layout can be an existing design layout, an automatically generated layout, supplementary graphics, or a combination thereof, or other layout data that can characterize the corresponding rule triggering and non-triggering conditions; the reference result can be a pre-obtained result record, a confirmed expected result, a manual review conclusion, or a combination thereof. Any equivalent substitution, deletion, addition, or combination of candidate rule parameter extraction, parameter mapping, rule configuration generation, rule detection code generation, test layout, task parameters, and result review methods, as long as it is used to converge the generated result to the reference result, is an implementation of the technical concept of this invention.

[0100] Furthermore, the functions described in the system in the form of modules can be implemented centrally by one or more processing units, or distributedly by multiple communicating processing units; the order of each step can be adjusted according to data dependencies, and they can be executed in parallel when processing conditions are met. Any scheme that employs the closed-loop mechanism described above—including rule parameter extraction, parameter mapping, rule configuration or code generation, inspection and verification, product update, and convergence judgment—to achieve layout rule development, rule parameterization configuration, or rule verification should be considered to fall within the scope of protection claimed in this invention.

Claims

1. An automated development closed-loop method for checking approval-level layout rules, characterized in that, include: Obtain process design kits, rules to be developed, rule description data, process environment information, and reference results; Parse the rule description data and extract candidate rule parameters, establish the correspondence between the candidate rule parameters and rule configuration items, rule detection instructions or rule detection codes, and generate initial design rule configuration and / or initial rule detection code; Obtain a test layout, which includes an existing design layout, a layout automatically generated according to the inspection requirements, supplementary graphics, or a combination thereof. Perform an automatic quick inspection on the test layout according to the initialization design rule configuration and / or initialization rule detection code to obtain a quick inspection result, and perform a final inspection to obtain a final inspection result. The quick inspection is used to provide feedback on intermediate verification during the iteration process, and the final inspection is used to form a formal verification basis. The rapid inspection results and the final inspection results are normalized and converted into a unified record format. Rule-level analysis, location-level analysis and result verification are performed on the reference results and the normalized generated results to determine whether the results are consistent, inconsistent or incomplete. Update the rule configuration items, rule detection instructions or rule detection codes, test layout and task status based on the results of the review; If the generated result does not converge with the reference result, the iteration continues. When the generated result converges, the development of the next rule begins, until the development of the predetermined rule set is completed, and the converged rule configuration, rule detection instructions or rule detection code and quality evaluation results are output.

2. The automated development closed-loop method for checking approval-level layout rules according to claim 1, characterized in that, The process environment information includes one or more of the following: target process, layout layer information, design object, layout data expression relationship, and check operation conditions, which are used to extract, instantiate, and interpret the results of constraint candidate rule parameters.

3. The automated development closed-loop method for checking approval-level layout rules according to claim 1, characterized in that, The candidate rule parameters are obtained by parsing natural language rule text, structured rule tables, existing rule descriptions, rule examples, or combinations thereof, and are associated with and stored with rule objects, applicable conditions, geometric relationships, hierarchical requirements, parameter values, and expected results.

4. The automated development closed-loop method for checking approval-level layout rules according to claim 1, characterized in that, When establishing the correspondence, the mapping relationship between candidate rule parameters and rule configuration items, rule detection instructions or rule detection codes is determined based on rule semantics, process environment information, rule configuration templates and reference results. When the reference result is inconsistent with the generated result or the generated result is incomplete, modify the corresponding rule configuration items, rule detection instructions or rule detection code according to the result review conclusion, and re-execute the check.

5. The automated development closed-loop method for checking approval-level layout rules according to claim 1, characterized in that, The rule description data includes the applicable conditions of the rule. The rule configuration items, rule detection instructions or rule detection codes are generated based on the applicable conditions and the corresponding rule content, so that the generated rules are executed only under the corresponding layout, layer combination, device or process conditions.

6. The automated development closed-loop method for checking approval-level layout rules according to claim 1, characterized in that, The automatically generated layout includes expected trigger samples, boundary samples, and legal comparison samples; the supplementary graphics are graphics inserted into a specified area of ​​the existing design layout to supplement the coverage of specific rules.

7. The automated development closed-loop method for checking approval-level layout rules according to claim 1, characterized in that, The normalization process includes converting the quick check results and the final check results into a unified record. The unified record includes the task number, rule identifier, layout file, hierarchical path, result location, result type, result quantity, and log location. The rule-level analysis and location-level analysis include rule-level difference analysis, location-level difference analysis, and difference source classification, and the results are divided into three categories: consistent results, inconsistent results, and incomplete results.

8. The automated development closed-loop method for checking approval-level layout rules according to claim 1, characterized in that, The task status is divided into three categories: pending execution, in execution, and completed. When the results are inconsistent or incomplete, a task to revise the rule configuration item, a task to revise the rule detection instruction or rule detection code, a task to supplement the test layout, a task to review the results, or a task to re-execute is generated.

9. The automated development closed-loop method for checking approval-level layout rules according to claim 1, characterized in that, The convergence consistency includes the consistency between the reference result and the generated result within the predetermined rule range, predetermined layout range, or predetermined location range, or the result verification confirms that the predetermined verification target is met.

10. An automated development closed-loop system for approval-level layout rule checking, characterized in that, include: The process design kit input module is used to obtain the process design kit, rules to be developed, rule description data, and reference results; The process environment information acquisition module is used to acquire process environment information; The rule description parsing module is connected to the process design kit input module and the process environment information acquisition module, respectively, and receives the rule description data and the process environment information, and parses the rule description data; The candidate rule parameter extraction module is connected to the rule description parsing module and extracts candidate rule parameters from the parsing results. The parameter mapping module is connected to the candidate rule parameter extraction module, and establishes the correspondence between the candidate rule parameters and rule configuration items, rule detection instructions or rule detection codes based on the process environment information and the reference results; The rule configuration and code generation module is connected to the parameter mapping module and generates initialization design rule configuration and / or initialization rule detection code according to the correspondence. The layout preparation module is connected to the rule configuration and code generation module. It obtains a test layout based on the initialization design rule configuration and / or initialization rule detection code. The test layout includes one or more of the following: an existing design layout, an automatically generated layout, and supplementary graphics. An automatic quick check module is connected to the layout preparation module to perform a quick check on the test layout and obtain the quick check result. The final inspection module is connected to the layout preparation module, performs a final inspection on the test layout, and obtains the final inspection result. The result unification module is connected to the automatic rapid inspection module, the final inspection module, and the process design kit input module, respectively, to convert the rapid inspection results and the final inspection results into a unified record format, and to receive the reference results; The difference analysis module, connected to the result unification module, performs rule-level and position-level analysis on the generated results of the unified record format and the reference results to determine whether the results are consistent, inconsistent, or incomplete. The convergence judgment module is connected to the difference analysis module to determine whether the generated result is consistent with the reference result in terms of convergence. The task scheduling module is connected to the convergence judgment module, the rule configuration and code generation module, and the layout preparation module, respectively. When convergence fails, it triggers the rule configuration and code generation module to update the rule configuration and / or rule detection code based on the difference analysis results, and / or triggers the layout preparation module to update the test layout and reschedules the inspection task. When convergence occurs, the current rule task ends and the next rule task is started. The status management module is connected to the task scheduling module and each inspection module to maintain the working status of each task.

Images