Archive for January, 2010

Jan 29 2010

What is the big deal with foundry supplied PV runsets?

Published by 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

Jan 21 2010

CES 2010 – TVs and Connectivity

Published by under Uncategorized

The CES big product trends were focused on 3D and tablet devices.  There were several component and design trends that were driving these devices.   Most of the products on the show floor were using standard products as components with customization either with programmable logic devices (e.g. FPGAs) or through specialized firmware/software.  There were very few new custom chips or ASICs in this year’s products.
On the TV side, there were a number of design changes to the 2D products.  The biggest feature changes were the shift to higher scan rates – 120hz and 240hz for LCDs, 600Hz for Plasma, a shift to LED and low power back light, and also adding internet connectivity with embedded application.  In order to support the higher scan rates, the drivers are utilizing smaller process geometries and more memory, To support the new backlight schemes, there are new standard product control chips which have been designed to target the new Energy Star requirements on the sets/ The addition of internet connectivity and the resulting application capability (VOD movies, You Tube, Photo sites, web search, Hulu, etc)   This requires both an operating system (Linux derivatives ) and a local compute engine.  These processors are dominated by the ARM, ARC and MIPS cores which are being embedded into the control electronics.  So far, none of the new 2D sets have incorporated higher speed connectivity that is found in HDMI 1.4 or higher capacity/bandwidth storage that is found in USB3.0 or SD XC interfaces.
Increased reliability, reduced power and cost was also featured in both TV and radio products.  Imagination Technology showed several IP products based on their META processor and thier frequency agile radio technology.  These appears in new radio products from PURE, and support over the air radio in the format for several countries as well as internet radio with search and apps such as facebook/twitter access.  On the TV side, ESS Technology has introduced their first full silicon Multi-standard CMOS TV tuner called the Radix.  The tuner is a monolithic replacement for traditional can tuners.  The product is price competitive with those tuners due to advanced design methods that eliminate the need for manual or post assembly calibration of the tuners and by using low cost foundry processes.  Their new format agile tuner, features fast channel selection and  employs a number of  patented circuit techniques for handling the continuous time signal path, and not having data dependent signal corruption.  The part features SNR specs on the same level as the can tuners while the packaging and power profiles provide increased immunity to interference from the back light and remote control circuitry.  The parts are available in Q1 ‘10 and feature a 400mW operating power over 48-10005MHz when using a 40-QFN package.
Continuing the embedded processors for apps trend, connectivity is now making its way into health care products (such as the TABSAFE) and the Mommy Tech (locator) products.  The Continua health alliance is promoting (along with Freescale) the Zigbee protocol for data between as base station/pc and a mobile medical device such as the Nonin Pulse-oximeter, or a blood pressure cuff.  The Tabsafe product is an evolution of an existing product from the clinical community that is now being made available for the home marketplace with data logging to a computer and/or your doctor on daily medication dispensing and dosage.  With the new connectivity, the physician can now modify a dose rate and pattern automatically to insure conformance on the dispensing of the medication.

The CES big product trends were focused on 3D and tablet devices.  There were several component and design trends that were driving these devices.   Most of the products on the show floor were using standard products as components with customization either with programmable logic devices (e.g. FPGAs) or through specialized firmware/software.  There were very few new custom chips or ASICs in this year’s products.

On the TV side, there were a number of design changes to the 2D products.  The biggest feature changes were the shift to higher scan rates – 120hz and 240hz for LCDs, 600Hz for Plasma, a shift to LED and low power back light, and also adding internet connectivity with embedded application.  In order to support the higher scan rates, the drivers are utilizing smaller process geometries and more memory, To support the new backlight schemes, there are new standard product control chips which have been designed to target the new Energy Star requirements on the sets/ The addition of internet connectivity and the resulting application capability (VOD movies, You Tube, Photo sites, web search, Hulu, etc)   This requires both an operating system (Linux derivatives ) and a local compute engine.  These processors are dominated by the ARM, ARC and MIPS cores which are being embedded into the control electronics.  So far, none of the new 2D sets have incorporated higher speed connectivity that is found in HDMI 1.4 or higher capacity/bandwidth storage that is found in USB3.0 or SD XC interfaces.

Increased reliability, reduced power and cost was also featured in both TV and radio products.  Imagination Technology showed several IP products based on their META processor and thier frequency agile radio technology.  These appears in new radio products from PURE, and support over the air radio in the format for several countries as well as internet radio with search and apps such as facebook/twitter access.  On the TV side, ESS Technology has introduced their first full silicon Multi-standard CMOS TV tuner called the Radix.  The tuner is a monolithic replacement for traditional can tuners.  The product is price competitive with those tuners due to advanced design methods that eliminate the need for manual or post assembly calibration of the tuners and by using low cost foundry processes.  Their new format agile tuner, features fast channel selection and  employs a number of  patented circuit techniques for handling the continuous time signal path, and not having data dependent signal corruption.  The part features SNR specs on the same level as the can tuners while the packaging and power profiles provide increased immunity to interference from the back light and remote control circuitry.  The parts are available in Q1 ‘10 and feature a 400mW operating power over 48-10005MHz when using a 40-QFN package.

Continuing the embedded processors for apps trend, connectivity is now making its way into health care products (such as the TABSAFE) and the Mommy Tech (locator) products.  The Continua health alliance is promoting (along with Freescale) the Zigbee protocol for data between as base station/pc and a mobile medical device such as the Nonin Pulse-oximeter, or a blood pressure cuff.  The Tabsafe product is an evolution of an existing product from the clinical community that is now being made available for the home marketplace with data logging to a computer and/or your doctor on daily medication dispensing and dosage.  With the new connectivity, the physician can now modify a dose rate and pattern automatically to insure conformance on the dispensing of the medication.

No responses yet