DRVerify: Verifying DRC decks and design rule specifications


DRVerify is mainly used to verify design rule check runsets for 3rd party DRC tools, and ensure that they correctly represent the design rule specification. In addition, DRVerify can be used to clarify, visualize and validate the exact meaning of a complex design rule description, as well as to ensure design rule consistency and prevent potential conflicts between different rules.

DRVerify uses the DRM (Design Rule Manual) rule definition to systematically generates variations of the design rule and to create a comprehensive set of layout test cases that manifest all meaningful combinations of the design rule parameters that can make it pass or fail. It is then used by DRC deck programmers as they run their DRC code on the generate gds file to check that it found and flagged all fail cases and did not flag any of the passing ones.

Design rule manual teams use DRVerify to visualize their design rule expressions and check its boundary conditions to ensure the formal expression accurately reflects their intent. DRVerify can also indicate possible conflict with other design rules.

Verifying DRC Runset (DRC Decks)

Coding a complex design rule runset where all checks are correct and accurate is close to impossible. The probability of having errors in any complex code is high, and here it is compounded by the common ambiguity of design rule descriptions, the difficulty to fully cover all possible situations and the complexity of evaluating each situation and determining its legality with respect to the design rule specifications.

Clear and formal design rule description in iDRM generates hundreds of DRC test cases

The Fundamental challenge is that there is no formal way or methodology to verify the DRC code against the design rule definition or any other golden reference, and ensure its correctness. To minimize the risk and release higher quality runsets, PDK teams create QA test cases for each design rule. These test cases are layout snippets that manifest both violating (fail) and legal (pass) configurations. The DRC code is then run on these test cases and the coders check that the code flags an error for each of the "fail" test cases, and that it does not flag any of the "pass" cases.

DRVerify offers a formal and automated methodology to generate such test cases. Starting from the source, the design rule specification DRM, the DRVerify geometry engine exercises both topological properties of the design rule pattern and the numerical values of its logical expression, and does it in a comprehensive manner. The result is an exhaustive set of layout test cases that manifest all meaningful combinations of the design rule parameters that can make it pass or fail. The entire collection is written to a gds file, where all the violating (failing) test cases are grouped and placed on the left side of a dividing line and all legal (passing) cases are placed on the right side it, to clearly distinguish between them.

 DRC runset flags all instances on the left and none on the right

The DRC deck under test is then run on this gds file. A correct DRC deck must flag as errors all the test cases in the left hand side, and should not flag any of the passing test cases on the right hand side. Any other result indicates a discrepancy between the deck and the design rule specification, and needs to be further evaluated and possibly corrected.

Validating Design Rule Descriptions

Design rule descriptions are written today in various forms using drawings, tables and free form text. Advanced technology design rules have become so complex that it is very hard to verify that such a description completely and accurately represents the design rule intent.

To address this problem iDRM automatically imports design rule descriptions from the DRM and enforces clear and consistent syntax. Users can also enter design rule definitions manually, using iDRM’s design rule editor. DRVerify then uses these design rule descriptions and automatically creates layout embodiment snippets of how each rule can manifest itself given the specified topology and logical conditions. DRVerify acts like an animator, acting out the written spec and creates a set of design rule instances that visualize the design rule expression and highlight the possible corner cases and boundary conditions that can flip each case from pass to fail and vice versa.

Design Rules Consistency

Advanced technology DRMs hold thousands of design rules, with many being very complex. Most layout configurations are subject to multiple design rules which can be overlapping, meaning that certain objects or distances in the layout need to satisfy different conditions that are specified in multiple design rules. All these rules need to be consistent and one design rule cannot conflict with other rules. Without the use of a formal automated system, this is almost humanly impossible to verify.

DRVerify addresses this problem: When a design rule is being exercised to generate fail and pass test cases, DRVerify enforces all other relevant design rules. If a specific layout instance uses rule values that conflict with any of the other rules, DRVerify will issue a warning indicating such conflict. The user can then review the conflicting conditions between the rules and determine how to resolve them. Note that conflicting conditions might also exist within a single complex design rule.


DRVerify is part of the iDRM platform. iDRM uses a formal and clear design rule description as a single source for all representations and deliverable: a visual design rule specification, a DRC checker and the QA test structures. With iDRM a design rule is defined only once, and all its other facets and derivative products are generated automatically, correct by construction and always in sync.

DRVerify enables the development of higher quality DRC decks, much faster and with less effort. In addition it can also be used to develop clear, unambiguous and consistent design rule specifications.


Download DRVerify Whitepaper