Jan 29 2010

What is the big deal with foundry supplied PV runsets?

Published by at 12:11 am under Uncategorized

Recently there have been several blogs, emails and articles from people talking about benchmarks in DRC/LVS/RCE/Appl Rules (general class of Physical Verification or PV tools) and some of those were run using runsets from vendor A on tools from vendor B.  These benchmarks were created to show “whose’s tool is the biggest and best” in the continued posturing war between EDA vendors.   As a result of this ritualistic posturing and “fanning of their plumage (benchmarks)” a large portion of the design community cannot correctly identify use models or selection criteria for these tools.
To help out in this situation, here are some basic information to understand and some questions to ask when reviewing information or statistics on PV tools.  For the sake of simplicity, I will be discussing issues with respect to Design Rule Checking (DRC), there are similar but different guidlines for LVS, ERC, RCE, and Application Rules Checking.
The first thing to understand is that there are several categories of design rules available from a wafer fab – (A) the basic structure rules, (B) yield and reliability rules, ( C) device operation rules, (D) suggested design rules, (E) optional design rules, (F) I/O rules, (G) power rules and (H) DFM/Litho rules.  Design rule sets for larger geometry processes (>0.35um)could typically be described in under 250 rules, most modern processes have upwards of 2000 rules a large portion of which are context based.  Signoff qualification for the right to release a design to a wafer fab usually includes passing ALL of the rules (A-H) being released by the fab.  The runset(s) are qualified on test data & real designs, validated for a specific version and mode of BOTH the parser and code, and released for specific minimum hardware platforms/configurations and operating systems.
To put the qualification effort into practical terms, based on the creation of several hundred PV runsets I have created/been involved with the creation of: for a typical layer on a 40nm process (e.g. diffusion or Metal 1) the basic design rules include minimum width and size, if bends are allowed, and parallel line spacing to the same layer or adjacent layers and use only simple boolean operations and “generation 1″ verification rules.  These “generation 1″ rules have existed since Maskcap/GPL days (1970′s) and are supported by pretty much every tool on the market.  These rules take about 4 hours each to validate between the creation of the test case, running it on the software, verifying the results as only errors being flagged, and getting signoff from CAD / design / process engineering and moving the code to a releasable area.,
The balance of the rules tend to be coded with syntax that is described in the EDA companies documentation about the function inside of their tool, but the implementation and algorithms used are different in each tool.  Hence the operation, flag location and aspects of checked objects (projections, vertices, edges) may be different in different modes (flat, hierarchical, dynamic) as well as in different tools.  These rules tend to have test cases that are in blocks cut from real designs, rather than created from standalone test cases.  Hence, these rules as coded in the complete runset take about 6 hours each for the validation loop.  For a typical 40nm process the 2000 rules consume about 11,200 man hours to validate for wafer release/signoff quality approval for the first software tool, and about 60% of that (6,720 man hours) for subsequent tools, as the test cases are already done.
With this extent of an effort behind the release of a runset for use, for a particular tool, implies there is a certain degree of difficulty and subtlety in the coding and construction of the runsets and also the mode of the PV tool, at runtime. [The complexity of this task is what is prompting the “unified  parser” methodology of TSMC’s iDRC program.  This is a vendor independent description language for the topological rules in the process.  At this time, the iDRC runsets do not provide for vendor optimized operation, and currently produce different results (number of real and false errors being flagged) from different tools when the results are compared in both flat and hierarchical modes.] This effort for the qualification of runsets, has led most EDA companies to run benchmarks for customers on their “preferred process” and existing designs, using “golden runsets” that are already qualified for the process, but area typically for other vendors tools.
When the runsets are used, the PV tools have a first step which is a parser that identifies where the input and output files are placed, which cell and level of hierarchy to start on, and verifies that commands in the runset have the right syntax and are interpretable by the core PV program.  It is in this step, that the vendors “run” each other’s files.  The results of the parser are a runset and associated files that guide the executable portion of the PV tool to do its job.  Lines of code in the runset that are not compatible with the PV tool are flagged with “warnings” and “non-fatal errors” and ignored at runtime.  In the “cross running” of runsets it is not unusual for a 2000 rule check file to have less than 750 “equivalent” checks that preformed in the other vendors tool.  The parser will also indicate issues such as which mode the tool is run in, and if associated support files are present.  In the absence of these files in the proper syntax/format, most of the PV tools default back to FLAT mode.  In flat mode, every polygon in the design is checked uniquely, rather then being checked inside of a cell so “2 input nand gate” is checked over and over for every instance, rather than being checked just once.  For a typical 65nm to 40nm design with 100M+ devices, it is guaranteed to crash any single CPU computer with up to 64G of memory, due to file size when checked in FLAT mode.
The parser also sets up the parallel processing and distributed computing modes for the PV tool.  As each vendors tool tends to launch differently and access the license server differently, when you run someone else’s runset, then the PV tools usually default back to a single machine (1 -2 CPU, and up to 8 cores/threads, license availability permiting) under an SMP environment.
When you compare the benchmarks or run runsets from one tool on another, you have make sure of the following:
(A) how many rules are being checked.
(B) if the parser and the warnings CHANGED any rules or options by substituting items that may change the context and intent of the rules.
( C) what mode the tool is running and on what cells the checks are being performed.
(D) what the IT infrastructure for the PV tools is set for when operated in recommended mode (how many CPUs, how much RAM, local or remote disk store, interactive or non-graphic display mode, licensing access and job submit methodology, etc)
(E) that the input file format is the same (launched from inside a tool on an internal database format vs from a GDSII or OA file)
(F) format and number of output files created.
These constitute the majority of the issues in comparing the runtime benchmark numbers between vendor tools.  The useful information for a design release is actually NOT the runtime numbers, as they tend to be less than 10% of the Physical Verification cycle.  The key issues on comparing the tools should be: (1) what is the signoff criteria from the FAB for release of a design to manufacturing – This is the main criteria, and (2) which has the most interpretable error flags for identifying not only what is wrong, but leads to how it should be fixed. Having a tool that is fast at generating lots of flags, both REAL and FALSE and having to weed through them, is actually worse than a tool with 10% longer runtime, that has NO or MINIMUM False errors, and the context description of the rule so a fix can be determined.
PC

Recently there have been several blogs, emails and articles from people talking about benchmarks in DRC/LVS/RCE/Appl Rules (general class of Physical Verification or PV tools) and some of those were run using runsets from vendor A on tools from vendor B.  These benchmarks were created to show “whose’s tool is the biggest and best” in the continued posturing war between EDA vendors.   As a result of this ritualistic posturing and “fanning of their plumage (benchmarks)” a large portion of the design community cannot correctly identify use models or selection criteria for these tools.

To help out in this situation, here are some basic information to understand and some questions to ask when reviewing information or statistics on PV tools.  For the sake of simplicity, I will be discussing issues with respect to Design Rule Checking (DRC), there are similar but different guidlines for LVS, ERC, RCE, and Application Rules Checking.

The first thing to understand is that there are several categories of design rules available from a wafer fab – (A) the basic structure rules, (B) yield and reliability rules, ( C) device operation rules, (D) suggested design rules, (E) optional design rules, (F) I/O rules, (G) power rules and (H) DFM/Litho rules.  Design rule sets for larger geometry processes (>0.35um)could typically be described in under 250 rules, most modern processes have upwards of 2000 rules a large portion of which are context based.  Signoff qualification for the right to release a design to a wafer fab usually includes passing ALL of the rules (A-H) being released by the fab.  The runset(s) are qualified on test data & real designs, validated for a specific version and mode of BOTH the parser and code, and released for specific minimum hardware platforms/configurations and operating systems.

To put the qualification effort into practical terms, based on the creation of several hundred PV runsets I have created/been involved with the creation of: for a typical layer on a 40nm process (e.g. diffusion or Metal 1) the basic design rules include minimum width and size, if bends are allowed, and parallel line spacing to the same layer or adjacent layers and use only simple boolean operations and “generation 1″ verification rules.  These “generation 1″ rules have existed since Maskcap/GPL days (1970′s) and are supported by pretty much every tool on the market.  These rules take about 4 hours each to validate between the creation of the test case, running it on the software, verifying the results as only errors being flagged, and getting signoff from CAD / design / process engineering and moving the code to a releasable area.,

The balance of the rules tend to be coded with syntax that is described in the EDA companies documentation about the function inside of their tool, but the implementation and algorithms used are different in each tool.  Hence the operation, flag location and aspects of checked objects (projections, vertices, edges) may be different in different modes (flat, hierarchical, dynamic) as well as in different tools.  These rules tend to have test cases that are in blocks cut from real designs, rather than created from standalone test cases.  Hence, these rules as coded in the complete runset take about 6 hours each for the validation loop.  For a typical 40nm process the 2000 rules consume about 11,200 man hours to validate for wafer release/signoff quality approval for the first software tool, and about 60% of that (6,720 man hours) for subsequent tools, as the test cases are already done.

With this extent of an effort behind the release of a runset for use, for a particular tool, implies there is a certain degree of difficulty and subtlety in the coding and construction of the runsets and also the mode of the PV tool, at runtime. [The complexity of this task is what is prompting the “unified  parser” methodology of TSMC’s iDRC program.  This is a vendor independent description language for the topological rules in the process.  At this time, the iDRC runsets do not provide for vendor optimized operation, and currently produce different results (number of real and false errors being flagged) from different tools when the results are compared in both flat and hierarchical modes.] This effort for the qualification of runsets, has led most EDA companies to run benchmarks for customers on their “preferred process” and existing designs, using “golden runsets” that are already qualified for the process, but area typically for other vendors tools.

When the runsets are used, the PV tools have a first step which is a parser that identifies where the input and output files are placed, which cell and level of hierarchy to start on, and verifies that commands in the runset have the right syntax and are interpretable by the core PV program.  It is in this step, that the vendors “run” each other’s files.  The results of the parser are a runset and associated files that guide the executable portion of the PV tool to do its job.  Lines of code in the runset that are not compatible with the PV tool are flagged with “warnings” and “non-fatal errors” and ignored at runtime.  In the “cross running” of runsets it is not unusual for a 2000 rule check file to have less than 750 “equivalent” checks that preformed in the other vendors tool.  The parser will also indicate issues such as which mode the tool is run in, and if associated support files are present.  In the absence of these files in the proper syntax/format, most of the PV tools default back to FLAT mode.  In flat mode, every polygon in the design is checked uniquely, rather then being checked inside of a cell so “2 input nand gate” is checked over and over for every instance, rather than being checked just once.  For a typical 65nm to 40nm design with 100M+ devices, it is guaranteed to crash any single CPU computer with up to 64G of memory, due to file size when checked in FLAT mode.

The parser also sets up the parallel processing and distributed computing modes for the PV tool.  As each vendors tool tends to launch differently and access the license server differently, when you run someone else’s runset, then the PV tools usually default back to a single machine (1 -2 CPU, and up to 8 cores/threads, license availability permiting) under an SMP environment.

When you compare the benchmarks or run runsets from one tool on another, you have make sure of the following:

(A) how many rules are being checked.

(B) if the parser and the warnings CHANGED any rules or options by substituting items that may change the context and intent of the rules.

( C) what mode the tool is running and on what cells the checks are being performed.

(D) what the IT infrastructure for the PV tools is set for when operated in recommended mode (how many CPUs, how much RAM, local or remote disk store, interactive or non-graphic display mode, licensing access and job submit methodology, etc)

(E) that the input file format is the same (launched from inside a tool on an internal database format vs from a GDSII or OA file)

(F) format and number of output files created.

These constitute the majority of the issues in comparing the runtime benchmark numbers between vendor tools.  The useful information for a design release is actually NOT the runtime numbers, as they tend to be less than 10% of the Physical Verification cycle.  The key issues on comparing the tools should be: (1) what is the signoff criteria from the FAB for release of a design to manufacturing – This is the main criteria, and (2) which has the most interpretable error flags for identifying not only what is wrong, but leads to how it should be fixed.

Having a tool that is fast at generating lots of flags, both REAL and FALSE and having to weed through them, is actually worse than a tool with 10% longer runtime, that has NO or MINIMUM False errors, and the context description of the rule so a fix can be determined.

PC

No responses yet

Trackback URI | Comments RSS

Leave a Reply