Design rule check (DRC) pre-detection of system design violations

Abstract

Systems and methods may support pre-DRC detection of system design violations. A method may include accessing an integrated circuit (IC) design; accessing a rule set for a circuit manufacturing process; and accessing the pre-check configuration file. The pre-check profile may include configuration data that detects system design violations in the IC design, and the system design violations include violations to rule groups that occur multiple times in the IC design and are attributable to the same root cause. The method may also include detecting an instance of a system design violation in the IC design.

Description

Background Art

[0001] Electronic circuits, such as integrated circuits, are used in nearly every aspect of modern society, from automobiles to microwaves to personal computers. The design of a circuit may involve many steps, referred to as a "design flow." The specific steps of the design flow often depend on the type of microcircuit being designed, its complexity, the design team, and the circuit manufacturer or foundry that will manufacture the circuit. Electronic Design Automation (EDA) applications support the design and verification of circuits before manufacturing. EDA applications may implement various EDA processes, such as functions, tools, or features, to analyze, test, or verify circuit designs at various stages of the design flow. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Certain examples are described in the following detailed description and with reference to the accompanying drawings.

[0003] Figure 1 An example of a computing system that supports pre-design rule check (DRC) detection of system design violations is shown.

[0004] Figure 2 An example detection of system design violations by a pre-check engine in accordance with the present invention is shown.

[0005] Figure 3 Example detection of standard cell placement violations by a pre-check engine is shown.

[0006] Figure 4 An example of annotated DRC results generated using the determined system design violations is shown.

[0007] Figure 5 An example of filtered DRC results generated using the determined system design violations is shown.

[0008] Figure 6 An example of logic that a computing system may implement to support pre-DRC detection of system design violations is shown.

[0009] Figure 7 An example of a computing system that supports pre-DRC detection of system design violations is shown. DETAILED DESCRIPTION

[0010] As modern circuit designs increase in complexity and capabilities, the verification of both circuit design and circuit manufacturing processes has become increasingly challenging. Modern chip designs may have millions of transistors, and the complexity of chip design continues to increase as integrated circuits are widely used in all aspects of modern society. As the physical size of transistors for technology nodes continues to decrease, effective and efficient chip design verification becomes increasingly necessary. Therefore, a key aspect of modern chip design flows is an effective physical verification platform for verifying the physical layout of integrated circuit (IC) designs. Physical verification can refer to the process of using electronic design automation (EDA) software tools to verify IC designs to ensure correct electrical and logical functionality and manufacturability.

[0011] DRC (Design Rule Checking) is a basic core block in the physical verification platform. In the context of physical verification, the DRC process can ensure the manufacturing feasibility of the IC design by verifying the geometric integrity of the design against the design rules of the circuit manufacturing process. Such design rules are usually formulated and provided by the chip foundry. During the DRC process, the differences between the IC design and the design rules of the foundry may lead to improper chip manufacturing, defects, non-working ICs or other common problems. Therefore, the DRC process in the EDA software can generate DRC results, which have a certain violation of the foundry's rule set and may cause violations of faulty chips. In traditional design processes, chip designers usually perform the DRC process at the beginning of the verification cycle, usually scheduled before proceeding to subsequent verifications (such as layout and schematic comparison (LVS) and other verifications).

[0012] One challenge faced in modern chip design is the large number of violations that may appear when DRC is performed on an IC design for the first time. During the early design stage, the circuit design may be in an exploration phase or a floorplanning phase, during which little or no verification is performed. Such an IC design may be referred to as a "dirty" design because violations will inevitably exist in an unverified circuit design or a circuit design that has undergone multiple design changes. Such an IC design may begin the verification process through the DRC tool of the EDA software to check whether the physical layout of the IC design complies with the predetermined rule set of the foundry or manufacturing process. Unfortunately, in the early floorplanning phase, the number of reported DRC violations may be quite large, which may result in long DRC run times and extremely large DRC result database files. Parsing such a large number of DRC violations may be a daunting task, even for experienced IC designers.

[0013] The debugging process to resolve the initial DRC result violation can be time-consuming and challenging. Due to the large number of DRC violations generated by early IC design, manual debugging of violations may require a great deal of time and user effort. Moreover, since each DRC violation corresponds to a single error, chip designers may have no choice but to resolve each DRC violation individually in the hope that the chip design meets the foundry's rule set. As another complicating factor, DRC results are presented individually, without any association with the root cause or systemic problem that caused the reported DRC violation. In some cases, hundreds, thousands or millions of DRC violations can be attributed to the same (repeated) design error. Traditional DRC processes and results cannot detect, evaluate or report such root causes, so that chip design does not know how to most effectively resolve a large number of DRC violations in DRC results. As another challenge, modern DRC processes require the execution of a full DRC process in order to generate DRC results for chip design. The full chip DRC process may have high resource requirements and long computational delays, especially for early IC design. This long delay required to detect even simple DRC violations is a time-consuming process that limits the efficiency and effectiveness of chip design and verification processes.

[0014] The disclosure herein can provide systems, methods, devices, and logic for pre-DRC detection of system design violations. As described in more detail herein, the pre-check violation detection technology of the present invention can provide an intelligent and effective mechanism to identify system design violations, with the ability to do so before any full DRC process is performed on the chip design. As used herein, a system design violation can refer to any violation of a manufacturing rule set that occurs multiple times in a chip design, but can be attributed to the same root cause. Example system design violations can include the reuse of "bad" standard cells, where each individual instance of a standard cell causes a separate DRC violation and a failure to legalize a particular cell before placement, which can result in the use of multiple such shifted cells, resulting in repeated violations. As another example of a system design violation, incorrect labeling of a network can spread the same connectivity problem throughout the chip design.

[0015] The pre-check violation detection technology disclosed in the present invention can provide different logic to detect and report system design violations in chip design, and do so independently of (or in combination with) the traditional DRC process. Therefore, the pre-check violation detection technology proposed in this article can support the detection and resolution of design problems with increased effectiveness. During the design phase, the detected system design violations can be presented to the user, and thus can be resolved before the DRC runs. Doing so can reduce the number of DRC violations in the initial DRC run, possibly significantly. Therefore, using the pre-check violation detection technology disclosed in the present invention, improved computational efficiency and reduced DRC process latency of the EDA system can be achieved. Additionally or alternatively, the detected system design violations can be used in conjunction with the full DRC process, such as by filtering out any DRC results attributable to the detected system design violations or by annotating the DRC results to explain which DRC violations can be attributed to the detected systematic design violations. This application of the detected system design violations can improve the efficiency of the debugging process because the designer can quickly identify the root cause, efficiently resolve the root cause, and easily identify the one-time DRC violations that need to be paid attention to separately.

[0016] These and other aspects of pre-inspection violation detection techniques according to the present disclosure and technical benefits of such pre-inspection violation detection techniques are described in greater detail herein.

[0017] Figure 1 An example of a computing system 100 that supports pre-DRC detection of system design violations is shown. The computing system 100 can take the form of a single or multiple computing devices (e.g., an application server, a computing node, a desktop or laptop computer, a smart phone or other mobile device, a tablet device, an embedded controller, etc.). In some implementations, the computing system 100 hosts, instantiates, executes, supports, or implements an EDA application or EDA system that supports circuit design and analysis, and can accordingly provide or implement any of the pre-check violation detection techniques described herein.

[0018] As an example implementation supporting any combination of the pre-check violation detection techniques described herein, Figure 1 The computing system 100 shown includes a pre-check engine 110. The computing system 100 can implement the pre-check engine 110 (including its components) in various ways, such as hardware and programming. The programming for the pre-check engine 110 can take the form of processor-executable instructions stored on a non-transitory machine-readable storage medium, and the hardware for the pre-check engine 110 can include a processor that executes these instructions. The processor can take the form of a single processor or a multi-processor system, and in some examples, the computing system 100 uses the same computing system features or hardware components (such as a common processor or a common storage medium) to implement multiple engines.

[0019] In operation, the pre-check engine 110 can access the IC design and access the rule set for the circuit manufacturing process. The rule set can specify the constraints that the IC design must meet for the physical manufacturing of the IC design. In operation, the pre-check engine 110 can also access the pre-check configuration file, and the pre-check configuration file can include configuration data for detecting system design violations in the IC design. System design violations can refer to violations of the rule set that occur multiple times in the IC design and can be attributed to the same root cause. The pre-check engine 110 can also detect instances of system design violations in the IC design.

[0020] These and other aspects of the pre-inspection violation detection technique according to the present invention are described in more detail below.

[0021] Figure 2 An example detection of a system design violation by the pre-check engine 110 according to the present invention is shown. Figure 2 In the example of FIG. 1 , various features of the pre-inspection detection technique are described using the pre-inspection engine 110 as an example of an implementation. Any suitable implementation of the described pre-inspection detection technique is contemplated herein.

[0022] In supporting pre-check detection of system design violations, the pre-check engine 110 may access a variety of inputs. Figure 2 In the example of , the pre-check engine 110 accesses the IC design 210, the rule group 220 and the pre-check configuration file 230. The IC design 210 can be any digital representation of an IC, a system on a chip (SOC), any other suitable circuit or any part thereof. In some examples, the IC design 210 can take the form of a design database having a design file that digitally represents the circuit design. The IC design 210 may be "dirty" because the DRC process has not been performed on the IC design 210 or the IC design 210 has triggered or will trigger a DRC violation. The rule group 220 may include any design rules applicable to the circuit manufacturing process. Therefore, the rule group 220 can take the form of a rule set (e.g., for a given technology node) provided by a foundry. In some implementations, the rule group 220 can be a selected rule subset of a complete rule set of a foundry or a technology node. In other implementations, the rule group 220 may include a complete rule set.

[0023] The pre-check configuration file 230 may take the form of any configuration data used by the pre-check engine 110 to detect system design violations. For example, the pre-check configuration file 230 may include technology node data (e.g., in addition to the rule group 220) that the pre-check engine 110 uses to configure logic to detect system design violations in the IC design. Any suitable form of configuration data that can be used to detect system design violations is contemplated, including according to the various examples presented herein.

[0024] To detect system design violations, the pre-check engine 110 may implement, include, or otherwise access system design violation logic. The system design violation logic may be customized to capture, identify, or otherwise detect specific known design issues. The pre-check engine 110 may implement different instances of the system design violation logic to detect different system design violations. For example, the pre-check engine 110 may implement multiple instances of the logic, each instance detecting a separate system design violation. Example instances of the system design violation logic are described in Figure 2 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110

[0025] The pre-check engine 110 can configure a given system design violation logic via specific design rules of the rule group 220 and specific configuration data of the pre-check configuration data file 230 applicable to the given system design violation logic. The design rules of the rule group 220 can specify specific design constraints that the IC design 210 is to satisfy, and the pre-check engine 110 can configure the given system design violation logic to apply specific constraints applicable to the specific system design violation being detected by the logic. The specific configuration data of the pre-check configuration data file 230 can include any relevant data that the given system design violation logic needs or is otherwise used to detect a given system design violation. Through the instance of the system design violation logic, the pre-check engine 110 can detect the system design violation 240 of the IC design 210.

[0026] Some examples of system design violations that the pre-check engine 110 can detect are presented next.

[0027] Figure 3An example detection of standard cell placement violations by the pre-check engine 110 is shown. Misplacement of standard cells in a circuit design may occur during the layout and routing (PnR) or clock cell insertion phase of the circuit design. For example, a clock cell (which may be a standard cell) may be inserted into an IC design and fixed in place. Due to the fixed placement of clock cells (or any standard cells) in IC designs, the layout and routing tools may not be able to properly snap or legalize the fixed cells on the placement grid, which may result in subsequent DRC violations. This error may occur because the PnR designer fails to remove the "fixed" designation of the placed standard cells (e.g., forgets to use an applicable "unlock" or "unfix" operation on the cell). As another possibility, the circuit designer performs manual placement of the cell, but is unable to perform a legalization operation on the placed cell.

[0028] Since the placed standard cells cannot be legalized, these cells may not align with the placement grid of the IC design, and DRC violations may occur. For example, when the subsequent "filler cell insertion" process is performed on the IC design, there may be gaps between the placed standard cells and the inserted filler cells because the standard cells have not been placed or moved to align with the placement grid. As another problem, fixed standard cells may overlap with other cells (which may also be fixed). Each gap in the IC design will be detected as a separate DRC violation by the DRC process. However, these problems may be attributed to the same root cause, for example, the standard cells are not aligned with the placement grid, whether due to misplacement or due to failure to legalize / unlock the placed cells.

[0029] The pre-check engine 110 may implement system design violation logic to detect misplaced standard cells. Figure 3 In an example of, the pre-check engine 110 implements standard cell placement violation logic, which can be configured to detect specific system design violations (e.g., instances thereof) in the form of standard cell placement violations. In doing so, the standard cell placement violation logic of the pre-check engine 110 can apply a constant set of criteria to identify misplaced standard cells, such as detection of common attributes / design issues that may be common across multiple technology nodes and circuit designs that present misplaced standard cell issues. As a specific implementation example, the pre-check engine 110 can be configured or implement standard cell placement violation logic to detect gaps in a circuit layer (e.g., an implant layer, sometimes referred to as a VT layer) on one side of a cell and layout overlaps on the other (e.g., opposite) side of the cell.

[0030] In operation, the standard cell placement violation logic implemented by the pre-check engine 110 can analyze the implantation layer of the IC design to determine whether the IC design has continuous standard cell and fill cell placement in the layer. To this end, the pre-check engine 110 can access the IC design 210, the rule group 220, and the pre-check configuration file 230. In order to support the configuration of the standard cell placement violation logic to appropriately detect standard cell placement violations, the accessed pre-check configuration file 230 may include configuration data in the form of identification of metal forming power rails, power rail widths, and power rail spacing (e.g., chip locations). Such configuration data values ​​can be specific to the technology node in which the IC design 210 is designed for manufacturing.

[0031] Through the standard cell placement violation logic, the pre-check engine 110 can identify areas of the circuit design where standard cells and fill cells should be placed continuously between metal power rails. Through the accessed configuration data, the metal power rails and their corresponding characteristics can be identified, and the pre-check engine 110 can configure the standard cell placement violation logic to identify the metal power rails at specific locations specified by the pre-check configuration data file 230. In the circuit area between the metal power rails on the implant layer, the standard cell placement violation logic can check any gaps in the circuit design. If such a gap occurs and is detected by the standard cell placement violation logic of the pre-check engine 110, the pre-check engine 110 can determine an instance of a standard cell placement violation.

[0032] exist Figure 3 In the example of , the pre-check engine 110 determines an instance of a standard cell placement violation 340 for the IC design 210. Since the standard cell placement violation logic can parse the entire circuit design to detect a specific type of system design violation, each instance of the violation detected by the standard cell placement violation logic can be classified as a standard cell placement violation. Therefore, for an IC design in which dozens, hundreds, thousands, or more such standard cell misplacement problems occur, the pre-check engine 110 can efficiently classify each of these violations detected by the standard cell placement violation logic as being attributable to the same root problem, which can improve debugging efficiency and the overall effectiveness of the IC design process.

[0033] The pre-check engine 110 can present the detected system design violation in various ways. In some implementations, the pre-check engine 110 can generate or visualize a marker in the IC design where the detected system design violation has been detected. For example, the pre-check engine 110 can identify Figure 3The pre-check engine 110 can detect gaps in a particular circuit portion of the circuit portion shown, and thus detect instances of standard cell placement violations at that particular circuit location. The pre-check engine 110 can visualize the detected violations by annotating or otherwise visualizing the IC design 210 with a marker where the detected violation occurred. Moreover, because the pre-check engine 110 can detect system design violations, the pre-check engine 110 can advantageously visualize detected violations that are attributable to the same system problem. In this way, the designer can quickly and efficiently identify (e.g., by visually marking) all design issues / DRC violations that are caused by the same root cause, and thus efficiently resolve the problems.

[0034] Although standard cell misplacement is only one example of a system design violation that can be detected by the pre-check engine 110, any number of additional or alternative system design violations can be detected by the pre-check violation detection techniques of the present invention. The pre-check engine 110 can be configured or implement an instance of any appropriate system design violation logic to detect any appropriate system design violation.

[0035] As another example of a system design violation, the pre-check engine 110 can detect a boundary well tap cell placement violation. Even though the number of DRC violations that may occur in an IC design due to boundary well tap cell placement may be relatively small, detecting such violations may be difficult, and the pre-check engine 110 can detect and identify such violations accordingly. To detect such system violations, the pre-check engine 110 can implement a separate or different instance of system design violation logic, for example, a boundary well tap cell placement violation logic implemented as an SVRF macro or implemented in any other suitable format.

[0036] In order to detect boundary well tap cell placement violations, the pre-check engine 110 can identify constant IC design attributes that occur in such violations, such as boundary gap cells, well tap cells, and macro cells. A boundary gap cell can refer to a subset type of a boundary cell, and a boundary cell can surround or surround a macro cell. This surrounding of a macro cell by a boundary cell can form a "halo" around the macro cell, and typically vertical, horizontal, and corner cell types are used as boundary cells surrounding a macro cell. In IC design, boundary cells are typically represented as physical cells only, because such boundary cells do not have a logical definition or function, and can be used to provide a DRC clean interface between macro cells and standard cells at the block level. A boundary gap cell can be any gap cell that is part of a boundary cell of a macro cell in an IC design.

[0037] The well tap cell can also be implemented as a physical cell only with no logical definition or function, and the tap cell can be used in IC design to connect the "n" well to V DD , connect the "p" substrate to VSS connection (e.g., within itself). In previous generations of circuit design, including the tap cell feature as part of the standard tap cell resulted in increased area consumption. Therefore, to improve area efficiency, many standard cells are designed as "tapless" standard cells. Such "tapless" standard cells do not require the inclusion of a well tap inside the standard cell, where the well tap is provided by a separate and distinct standard cell, called a well tap cell.

[0038] System design violations in the form of boundary well tap cell placement violations can be detected or occur through oxide diffusion (OD) spacing violations (e.g., violations of spacing constraints for OD layers that are particularly applicable to IC designs). Therefore, the pre-check engine 110 can configure the boundary well tap cell placement violation logic to detect boundary well tap cell placement violations when the boundary gap cell is located on top of the well tap cell, which results in a discontinuous pattern on the OD layer (which can be referred to as a discontinuous OD pattern). In other words, when the OD pattern of one cell (e.g., a boundary gap cell) protrudes into a portion of the OD pattern of another cell (e.g., a wire tap cell), then the pre-check engine 110 can detect a boundary well tap cell placement violation. Such a scenario can be a corner case, where the cell placement in the IC design is standard, but, by chance, the wire tap cell column is placed at the corner of the macro cell.

[0039] To further explain, the pre-check engine 110 can detect the border well tap cell placement by capturing the location of the target OD spacing violation. The detected OD spacing violation can be performed by utilizing the configuration data in the pre-check configuration file 230. For example, the location of the macro cell placement in the IC design is determined by a mechanism consistent with the described standard cell placement violation, which searches for the IC design area where the standard cell and the filling cell are placed. Instead of the standard cell and the filling cell placement, the border well tap cell placement violation logic can parse such an area to identify the macro cell location. Next, the border well tap cell placement violation logic can extract the halo line (e.g., composed of boundary cells) of each macro cell. Then, the border well tap cell placement violation logic can use the halo line and the technology node-specific configuration data in the form of OD spacing constraints and protruding length constraints. In doing so, the border well tap cell placement violation logic can determine the location of the target OD spacing violation, which can form the detected border well tap cell placement violation. Like any system design violation, the pre-check engine 110 can visualize the detected border well tap cell placement violation, and the user can efficiently identify and resolve the violation accordingly.

[0040] While visualization of detected system design violations (including before performing a full DRC process on a chip design) can provide tangible benefits and effects to the circuit design process, the pre-check engine 110 can implement any number of additional or alternative applications of detected system design violations. For example, the pre-check engine 110 can utilize detected system design violations in conjunction with DRC results from a full DRC run. Through this use, the pre-check engine 110 can allow for intelligent and efficient traversal of DRC results compared to traditional DRC processes that can only list the occurrence of individually detected DRC violations. Next, an example feature of DRC results annotated and filtered by detected system design violations is described.

[0041] Figure 4 An example of DRC results generated with annotations using the identified system design violations is shown. Figure 4 In the embodiment of the present invention, the pre-check engine 110 can access the DRC results 410 of the DRC process performed for the IC design. The DRC process can be a full (e.g., traditional) DRC run based on the foundry's rule set analysis and detection of DRC violations for the chip design. As described herein, the DRC results 410 for "dirty" IC designs or IC designs in the early design stages can be very large, making the DRC results difficult to handle and sometimes overwhelming. Moreover, the DRC results 410 can only list individual violations without any intelligence or insight about the cause of such detected violations, which is of little help to the debugging work and cannot sort through the thousands or millions of individual DRC violations in the DRC results 410.

[0042] The pre-check engine 110 may annotate the DRC results 410 with the detected system design violations 240 for the IC design. In doing so, the pre-check engine 110 may associate individual DRC violations with the system design violations 240 detected for the IC design. The system design violations 240 may include location markers or identifiers for detected violations that are attributable to a common root cause, and the pre-check engine 110 may cluster any DRC results with the same location as a given type of system design violation. Each cluster of DRC results grouped by the pre-check engine 110 may be attributed to a different root system design violation, and the pre-check engine 110 may annotate the DRC results 410 to indicate, cluster, classify, or otherwise represent the grouping of DRC violations with a common root cause.

[0043] exist Figure 4In the example of , the pre-check engine 110 generates annotated DRC results 420, which can decompose or group the DRC results 410 into different system design violation classifications (e.g., grouping together DRC violations that are detected boundary well tap cell placement violations, DRC violations that are standard cell placement violations, etc.). Therefore, the pre-check engine 110 can provide annotated DRC results 420 by clustering the DRC results 410 based on specific system design violations detected by the pre-check engine 110. Doing so can improve the efficiency and effectiveness of debugging IC designs through DRC results.

[0044] Figure 5 An example of generating filtered DRC results using determined system design violations is shown. As another example, the pre-check engine 110 can filter the DRC results 410 by the system design violations 240 detected for the IC design. In some implementations, the pre-check engine 110 can filter (e.g., remove) any DRC violations in the DRC results 410 that are attributable to the system design violations detected by the pre-check engine 110. Since such system design violations can be attributed to a common cause, filtering such corresponding DRC violations can allow debugging efforts to focus on non-system DRC violations, and address such issues individually to clean up the IC design to meet foundry requirements.

[0045] Since DRC results 410 may be large and cumbersome, filtering DRC violations attributable to system design violations may allow a user to quickly parse out specific issues of the IC design that need to be individually resolved. In traditional DRC results that only list a large number of individual violations, such a quick and efficient evaluation is not possible, and the user would need to wade through a very large number of DRC violations to actually resolve individual issues in the chip design.

[0046] exist Figure 5 , the pre-check engine 110 generates filtered DRC results 520 by filtering the DRC results 410 based on specific system design violations detected by the pre-check engine 110. The pre-check engine 110 can do so based on any configurable abandonment configuration, which can be user-specified or adjustable. For example, the abandonment configuration can specify specific system design violations to be filtered out from the DRC results 410, which system design violations (if any) are not to be filtered out, or any other suitable configuration. The filtered DRC violations can be stored elsewhere by the pre-check engine 110 (e.g., as separate result data), which can also be accessed and reviewed for debugging work.

[0047] In any combination described herein, the pre-check engine 110 can detect system design violations. Such detection can be performed before, in conjunction with (e.g., concurrently with), or even after the full DRC run on the IC design. In some implementations, the pre-check violation detection technology of the present invention can be implemented as part of the DRC process, for example, as a pre-check mode option for detecting system design violations instead of a full DRC run. Through the pre-check violation detection technology disclosed in the present invention, the effectiveness and efficiency of EDA system verification chip design can be improved. Especially in the early stages of the design phase, the detection of system design violations can allow cleaner chip designs and solve system problems in the early stages of verification. Compared with the DRC run on the dirty IC design without the provided pre-check violation detection technology, the full DRC run may produce (possibly significantly) fewer DRC violations. Reducing DRC calculation delays and design debugging time can improve tape-out time, allowing fast and more efficient chip design, improved resource utilization, and more efficient design processes.

[0048] Figure 6 An example of a logic 600 that a system can implement to support DRC pre-detection of system design violations is shown. For example, the computing system 100 can implement the logic 600 as hardware, executable instructions stored on a machine-readable medium, or a combination of the two. The computing system 100 can implement the logic 600 via a pre-check engine 110, through which the computing system 100 can execute or implement the logic 600 as a method for detecting a violation of the support system design according to the present invention. The following description of the logic 600 is provided using the pre-check engine 110 as an example implementation. However, other implementation options of the computing system are possible.

[0049] When implementing logic 600, the pre-check engine 110 can access the IC design (602) and access the rule set (604) for the circuit manufacturing process. The rule set can specify the constraints that the IC design must meet for the physical manufacturing of the IC design. When implementing this logic, the pre-check engine 110 can also access the pre-check configuration file (606), and the pre-check configuration file can include configuration data for detecting system design violations in the IC design. System design violations can refer to violations of the rule group that occur multiple times in the IC design and can be attributed to the same root cause. When implementing logic 600, the pre-check engine 110 can also detect instances of system design violations in the IC design (608).

[0050] Figure 6 The illustrated logic 600 provides an illustrative example of how computing system 100 can support pre-DRC detection of system design violations according to the present invention. Additional or alternative steps in logic 600 are contemplated herein, including in accordance with any of the various features described herein for pre-check engine 110.

[0051] Figure 7 An example of a computing system 700 that supports pre-DRC detection of system design violations is shown. The computing system 700 may include a processor 710, which may take the form of a single or multiple processors. The one or more processors 710 may include a central processing unit (CPU), a microprocessor, or any hardware device suitable for executing instructions stored on a machine-readable medium. The computing system 700 may include a machine-readable medium 720. The machine-readable medium 720 may take the form of any non-transitory electronic, magnetic, optical, or other physical storage device that stores executable instructions, such as Figure 7 Pre-check instructions 722 are shown. Thus, the machine-readable medium 720 may be, for example, a random access memory (RAM) such as a dynamic RAM (DRAM), a flash memory, a spin torque memory, an electrically erasable programmable read-only memory (EEPROM), a storage drive, an optical disk, or the like.

[0052] Computing system 700 may execute instructions stored on machine-readable medium 720 via processor 710. Executing instructions (eg, pre-check instructions 722) may cause computing system 700 to perform or implement any pre-check violation detection techniques described herein, including any aspects according to pre-check engine 110.

[0053] For example, the execution of the pre-check instructions 722 by the processor 710 may cause the computing system 700 to access the IC design, access the rule set for the circuit manufacturing process, and access the pre-check configuration file. As described herein, the pre-check configuration file may include configuration data for detecting system design violations in the IC design, and the system design violation may refer to a violation of the rule set that occurs multiple times in the IC design and can be attributed to the same root cause. The execution of the pre-check instructions may also cause the computing system 700 to detect instances of system design violations in the IC design, doing so in any manner described herein.

[0054] Any additional or alternative aspects of the pre-check violation detection techniques described herein may be implemented via pre-check generate instructions 722 .

[0055] The above-described systems, methods, devices, and logic including the pre-inspection engine 110 may be implemented in many different ways in many different combinations of hardware, logic, circuits, and executable instructions stored on a machine-readable medium. For example, the pre-inspection engine 110 may include circuits implemented in a controller, microprocessor, or application-specific integrated circuit (ASIC), or may be implemented using a combination of discrete logic or components or other types of analog or digital circuits that are combined on a single integrated circuit or distributed among multiple integrated circuits. A product (e.g., a computer program product) may include a storage medium and machine-readable instructions stored on the medium, which, when executed in a terminal, computer system, or other device, cause the device to perform operations according to any of the above descriptions (including any features of the pre-inspection engine 110).

[0056] The processing capabilities of the systems, devices, and engines described herein (including the pre-inspection engine 110) can be distributed among multiple system components, such as between multiple processors and memories, optionally including multiple distributed processing systems or cloud / network elements. Parameters, databases, and other data structures can be stored and managed separately, can be combined into a single memory or database, can be logically and physically organized in many different ways, and can be implemented in many ways, including data structures such as linked lists, hash tables, or implicit storage mechanisms. Programs can be parts of a single program (e.g., subroutines), separate programs, distributed across several memories and processors, or implemented in many different ways, such as in a library (e.g., a shared library).

[0057] While various examples and features are described above, many more implementations are possible.

Claims

1. A method comprising: By calculating the system (100,700): accessing (602) integrated circuit (IC) design (210); accessing (604) a rule set (220) for a circuit manufacturing process, wherein the rule set (220) specifies constraints that the IC design (210) is to satisfy for physical manufacturing of the IC design (210); accessing (606) a pre-check configuration file (230), wherein the pre-check configuration file (230) includes configuration data for detecting system design violations in the IC design (210), wherein the system design violations include violations of the rule set (220) that occur multiple times in the IC design (210) and are attributable to the same root cause; and Instances of the system design violations in the IC design (210) are detected (608).

2. The method of claim 1 , comprising detecting a plurality of system design violations in the IC design (210) via different instances of system design violation logic implemented by the computing system (100, 700), wherein: Each instance of the system design violation logic is configured to detect a different system design violation.

3. The method according to claim 1, further comprising: generating a location marker for each said instance of said system design violation detected; as well as The location markers in the IC design (210) are visualized.

4. The method of claim 1, comprising detecting the instance of the system design violation in the IC design (210) prior to performing a full design rule checking (DRC) run on the IC design (210).

5. The method according to claim 1, further comprising: accessing DRC results (410) from a full DRC run on the IC design (210); as well as Annotated DRC results (420) are generated by clustering DRC violations in the DRC results (410) based on the detected instances of the system design violations in the IC design (210).

6. The method according to claim 1, further comprising: accessing DRC results (410) from a full DRC run on the IC design (210); as well as A filtered DRC result (520) is generated by filtering out DRC violations in the DRC result (410) based on the detected instances of the system design violations in the IC design (210).

7. The method according to claim 1, wherein: The pre-check configuration file (230) includes configuration data specific to the technology node for which the IC design (210) is designed.

8. A system comprising: processor; as well as A non-transitory machine-readable medium comprising instructions that, when executed by the processor, cause a computing system (100, 700): Visit Integrated Circuit (IC) Design (210); accessing a rule set (220) for a circuit manufacturing process, wherein the rule set (220) specifies constraints that the IC design (210) is to satisfy for physical manufacturing of the IC design (210); accessing a pre-check configuration file (230), wherein the pre-check configuration file (230) includes configuration data for detecting system design violations in the IC design (210), wherein the system design violations include violations of the rule set (220) that occur multiple times in the IC design (210) and are attributable to the same root cause; and Instances of the system design violations in the IC design (210) are detected.

9. The system according to claim 8, wherein: The instructions, when executed, cause the computing system (100, 700) to detect a plurality of system design violations in the IC design (210) via different instances of system design violation logic implemented by the computing system (100, 700), wherein each instance of the system design violation logic is configured to detect a different system design violation.

10. The system according to claim 8, wherein: The instructions, when executed, cause the computing system (100, 700): generating a location marker for each said instance of said system design violation detected; as well as The location markers in the IC design (210) are visualized.

11. The system according to claim 8, wherein: The instructions, when executed, cause the computing system (100, 700) to detect the instance of the system design violation in the IC design (210) prior to performing a full design rule checking (DRC) run on the IC design (210).

12. The system according to claim 8, wherein: The instructions, when executed, cause the computing system (100, 700): accessing DRC results (410) from a full DRC run on the IC design (210); as well as Annotated DRC results (420) are generated by clustering DRC violations in the DRC results (410) based on the detected instances of the system design violations in the IC design (210).

13. The system according to claim 8, wherein: The instructions, when executed, cause the computing system (100, 700): accessing DRC results (410) from a full DRC run on the IC design (210); as well as A filtered DRC result (520) is generated by filtering out DRC violations in the DRC result (410) based on the detected instances of the system design violations in the IC design (210).

14. The system according to claim 8, wherein: The pre-check configuration file (230) includes configuration data specific to the technology node for which the IC design (210) is designed.

15. A non-transitory machine-readable medium (720) comprising instructions (722) that, when executed by a processor (710), cause a computing system (100, 700): Visit Integrated Circuit (IC) Design (210); A rule set (220) for a circuit manufacturing process is accessed, wherein: The rule set (220) specifies constraints that the IC design (210) must satisfy for physical fabrication of the IC design (210); accessing a pre-check configuration file (230), wherein the pre-check configuration file (230) includes configuration data for detecting system design violations in the IC design (210), wherein the system design violations include violations of the rule set (220) that occur multiple times in the IC design (210) and are attributable to the same root cause; and Instances of the system design violations in the IC design (210) are detected.

Images