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
)

How Good is Your DRC Deck?

How Good is Your DRC Deck?
by Daniel Nenni on 05-24-2015 at 4:30 pm

Design Rule Check (DRC) is the #1 foundry sign-off check. Fabless companies receive the DRC deck from the foundry; it’s a file comprising thousands of commands in a proprietary checker language for a specific DRC tool. In advanced technologies such a deck executes tens of thousands of geometric operations on the physical design data as it tries to detect violations of the foundry design rules.

Design rule compliance is a very big deal. Today’s advanced technologies require single-digit nanometer precision and don’t leave any wiggle room for deviations. A design that goes to tape-out represents a cost of $30M to $100M and an error could cost millions more in new masks and wafers, not to mention the cost of missing the product schedule. We would therefore expect that there is enough design automation in place to ensure that the DRC deck is an accurate derivative of the design rule specification.

The reality in this corner of EDA is quite different though:
[LIST=1]

  • The first astonishing fact is that until recently there has not been an EDA solution for design rule specification. The closest thing to a spec that designers had access to was the design rule manual (DRM) that holds free format description of design rules. These descriptions are informal and sometimes unclear but most importantly, are not machine readable. There is no automated system that can read these descriptions and process them for downstream tools.
  • This brings us to the main problem: lacking such an EDA solution, the DRC deck is programmed manually based on human interpretation of the rule. To validate this complex piece of code we would want the DRC deck to be verified against the rule spec but if there is no spec – how do we know that the deck is correct and represents the true, accurate, and complete intent of the design rule?

    A very good question. Lacking an EDA solution, what usually happens is that the newly developed DRC deck is run on test chips and preliminary design blocks and the results are compared against process simulation or actual silicon to ensure that manufacturing errors are detected by the DRC and that no false errors are flagged. If incompatibilities are found, the DRC deck has to be modified and hopefully the DRM is updated as well. This practice is very cumbersome, expensive, and slow, but the biggest problem is that it relies on these few test chips and blocks that cannot represent all possible errors that can and will be made by designers. This is one of the reasons early DRC decks are changed and updated as more and more designs are being taped out. Eventually, when the DRC deck has “seen” enough designs, and updated accordingly, we consider it mature.

    Getting back to: How Good is Your DRC Deck?

    It’s hard to tell. What we really want is a rule-by-rule validation report produced by a system that runs the DRC deck and validates it against a formal design rule specification.

    Well, Sage-DAaddresses this very problem and offers such a solution. Their iDRM platform enables engineers to capture design rule specifications graphically – quickly creating a clear and formal description. These rule specs are also executables – they can immediately run a check for the captured design rule.

    Sage-DA recently went a step further with their new DRVerify tool that generates a systematic and exhaustive set of test cases from that rule specification. The generated test-suite accurately represents the design rule intent and provides an input test pattern to the DRC deck under development verifying they catch all possible rule violations without false errors.

    Check out #52DAC booth 1924 and have a chat with my good friends at Sage Design Automation!

    Share this post via:

  • Comments

    There are no comments yet.

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