WP_Term Object
(
    [term_id] => 54
    [name] => Sage DA
    [slug] => sage-da
    [term_group] => 0
    [term_taxonomy_id] => 54
    [taxonomy] => category
    [description] => 
    [parent] => 14433
    [count] => 12
    [filter] => raw
    [cat_ID] => 54
    [category_count] => 12
    [category_description] => 
    [cat_name] => Sage DA
    [category_nicename] => sage-da
    [category_parent] => 14433
)

Verifying DRC Decks and Design Rule Specifications

Verifying DRC Decks and Design Rule Specifications
by Daniel Nenni on 02-19-2014 at 8:00 am

DRVerify is part of the iDRM design rule compiler platform from Sage DA, something that I have been personally involved with for the past three years. DRVerify is mainly used to verify third party design rule check (DRC) decks and ensure that they correctly, completely and accurately represent the design rule specification. In addition, DRVerify can be used to clarify 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.

Using the iDRM design rule definition pattern and it’s logical expression, DRVerify systematically generates variations of the design rule and creates a comprehensive set of layout test cases that manifest all meaningful combinations of the design rule parameters that can make it pass or fail.

DRC deck programmers use DRVerify to automatically generate an exhaustive set of pass and fail test cases, and run their DRC code on the generate gds file to check that it found all fail cases and did not flag any of the passing ones. Design rule manual (DRM) teams use DRVerify to visualize their design rule expressions and check its boundary conditions to ensure the formal expression accurately reflects their intent. DRVerify also indicates any possible conflict with other existing design rules.

Verifying DRC Decks (DRC Runsets)
Creating a correct and accurate check of a complex design rule is almost impossible; The probability of making errors is so high and compounded by the ambiguity of the design rule description, 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 specification.

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 in iDRM, 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 systematic and 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. Each test case is tagged and annotated with the specific combination of parameters that make it pass or fail. The entire collection is written to a gds file, where all the violating test cases are grouped and placed under a dividing line and all passing cases are placed above it, to clearly distinguish between them.

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

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 fail group below the line, and should not flag any of the passing test cases above the line. Any other result indicates a discrepancy between the deck and the design rule specification, and needs to be further evaluated and probably corrected. The annotated specific value combination of each test case can pinpoint to the specific discrepancy and help the user to debug the DRC code and correct it.

Verifying DRC deck using the generated test cases (only error marker layer shown)

Validating Design Rule Descriptions: Design rule descriptions are written today in various forms using drawings, tables and free form text. Advanced technology (20nm and below) 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, DRVerify uses the iDRM formal design rule description and automatically creates layout embodiment snippets of how this rule can manifest itself given the specified drawing and logical conditions. DRVerify acts like an animator that acts 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 a case from pass to fail and vice versa.

This visualization shows immediately what the design rule spec actually means, which cases are passing and which are failing and where are the possible hidden ‘gotcha’ situations. The user can immediately spot unexpected aberrations, like violations that should have been legal and vice versa.

Design Rules Consistency: Advanced technology DRMs hold thousands of design rules, some of them 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, DRVerify keeps all other “fixed” design rules that are in the background. If a specific layout instance requires setting 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 everything: the design rule specification, the checker and the test structures. Using iDRM a design rule is defined only once, and all its other facets and derivative manifestations are generated automatically, correct by construction and are 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.

DRVerify is part of the iDRM Platform

Also read:

iDRM for Complex Layout Searches and IP Protection!

Analyze your physical design: avoiding layout related variability issues

iDRM Brings Design Rules to Life!

Sage Design Automation launched, with design rule compiler technology and products

More Articles by Daniel Nenni…..

lang: en_US

Share this post via:

Comments

There are no comments yet.

You must register or log in to view/post comments.