pdk automation - an ibm perspective - confprojects.si2.org/events_dir/2011/si2con/7.pdf · pdk...
Post on 18-Mar-2020
12 Views
Preview:
TRANSCRIPT
PDK AutomationAn IBM Perspective
Matthew Graf, OPDKCJames Culp, ODFMC
Si2 ConOct. 20th, 2011
Chip Design groupsdevelop their own PDK
Enablement Org formed.Develops a unified PDKfor multiple design groups
Enablement Organization develops unified multi‐vendorPDK
1998
Few common standardsPDK was process centricMostly IP Test validated
One Common PDKMulti‐Vendor DecksMultiple Extraction FlowsDesign Rule standardsFormal test regressionsInvestment in automationLitho Rules appear ‐ DFM initiativesDevice Scaling Issues
Common multi‐vendor PDKEngineered Active DevicesDFM MaturesSub‐Resolution PatterningContinue:‐ Automation Investment ‐Multiple Extraction Flows ‐ Design rule standards‐ Formal test regressions
2009OpenPDKOpenDFM
IBM’s PDK Development History Timeline
Many of today’s 200mm kitsevolved from the GR’s and process specs from thesePDKs
10/24/2011
Today’s IBM’s 300mm PDKcreating standards for automation
Design ManualDatabaseMatrix of #’s
Design Manual
SKILLTVFICVTCLPERL
A
DITA1
Tools
Auto/ManTest
Goundrules &Process AssumptionsLVS Truth Table
SupportingFunction.
SKILLPERL
XMLSemi‐auto
Creating PDK Standards to support Reuse ‐ examples
• DRC: Groundrule (name, wording, supporting code), and Testcases
• Device Library: Parameters (definition, shape name, function, format), units, symbols.
• LVS: Device Name, Parameters, Pins, Code, and Testcases
• PEX: Process Assumptions, PEX function, Translators from base to vendor specific input file formats, and Testcases.
• IP Test procedures: Obj: Consistent DRC & LVS results for multiple vendor decks.Focus on types of IP used, methods of reporting errors.
Resulting in:
• Common functional code: (some examples are) • DRC: Connectivity, Space, Width, Enclosure, Memory Exceptions• LVS: Compare, Merge, Connect, Stress Calculator• Library : Range Checks, Max & Min Checks, Grid Snapping
• Auto‐Testcase generation code & Test Results Summary software
• Automation of Extraction Flow comparisons • Exercised various Netlisters, LVS & PEX decks, Simulators• Comparing simulation results for defined benchmark layouts
• Improved Development focus on New PDK additions
• Improved Kit Quality and, on average, faster response time.
10/24/2011
Return on Investment?
~75-80% code reuse from one technologyto the next up thru 28nm.
Design ManualDatabase
Design Manual
A
SkillTVFICVTCLPERL
A
~75‐80% reuse
SkillTVFICVTCLPERL
Goundrules &Process AssumptionsLVS Truth Table
DITA1
B
Design Manual
B
1 DITA: is an XML architecture for designing, writing, managing, and publishing information.
Reuse examples: Same GR wording (less #s),Same deck code (less #s),Same testcase gencode (less #s)Technology’s #s come from DMDB
Tools Test
Tools Test
Tech A
Tech B
DMDB Consistency ChecksAn On‐Going Focus
• Goal: Assure content correctness of the Design Manual DataBase.
• Examples of inconsistencies: o New DRC rule conflicts with
an existing ruleo Typo errors in Databaseo New Layer requirements not
fully specified
• Addressed by “stack‐holder pre‐reviews” and new “consistency check tools”
DMDB update
PDKDevelopment
PDKTest
PDKRelease
Auto‐ DMDB ConsistencyChecking
Stack‐holder review(Pre‐DMDB update)
Historical DRC, Library, PEX Code Reuse% Reu
se of cod
e
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
90nm 65nm 45nm 32/28nm 22/20nm 14nm
Estimate
Reasons for trend change?Lithography:
Pitch ConstraintsMOL ChangesSub‐resolution Patterning
Engineered Active Devices:Thin Film DevicesFin FETS
With so much post 28nm technology change,should we still invest in standards?
The simple answer, we believe, is yes!
• Most of the change in post 28nm technologies are additions.We are still using much of the base rules & code from previous.
• Many of the new changes are applied similarly to multiple layers/devices. Substantial reuse of code within the newer technologies.
• Many of the GR modifications thru process development are still # changesTestchip PDK Production PDK
• But: Newer PDKs (beyond 28nm) require increased startup development.
Industry Issue:• Escalating cost in developing multi‐vendor PDKs
Our Answer:• Industry Standards for PDK Development
Why we chose to work thru Si2!• A solid Legal umbrella for collaboration – joint ownership.• Responsible, responsive standard’s body• Accepted by the EDA Vendors that we work with.• Si2 Goal is to gain an Industry Consensus!
Next step in this PDK Development process?
OpenPDK Coalition ActivitiesGilles Namur & Barry Nelson
Strategy: “Targeted Workgroups”
OPS – Open Process SpecificationMission: Develop industry standard specifications producing a electronic document describing all the objects needed to generate a complete PDK. Chair: Flavien Delauche
SCP – Symbol, Callback, Parameters (encompassing 4 sub‐workgroups)Mission: Develop device parameter & Callback standard specifications Augment Si2 Symbol library with additional symbols, parameters,
and properties
Symbols – Chair: Rich Morse Parameter Definition – Chair: Li‐Chien TingSimulation Interface – Chair: Kristin LiuParameter Checking and Relationships – Chair: Ted Paone
Ty
Proposed OPDK Automation Flow
Flow
Internal Format
MODULAR OPS
Si2 STANDARDWG
Owners / Architects
DFMC
Vendor‐written
OPS Consumer Format
OPS Standard Format
DATA CODESPECSPlug into OPS
Spec Component
Technology OPS(XML)
Spec Validation
Data FlowData In/Out
Type Model
Schemas (XSD)XML‐2‐Internal
Format Convertor
Tech Input
Enhanced Symbols
Callbacks
Parameters
Layers & Constraints*
DRC/DFM
LVS/PEX(LPE)
Targeting
Test Harness
SPICE Netlist
SCP WG
OPS WG
* P‐O‐C not complete
E.g., “Fake eDRM”
OPS Format
10/24/2011Innovation Through Collaboration 13
Next Step in PDK Development ……..OpenPDK
A "single source" for multi-vendor PDK development
Input Once...
Design ManualDatabase Content& Output Format
Design Manual
A
XSD SchemaXML Language
Vendor‐specific PDKs
Tools/TestEDA Vendor A
EDA Vendor B
EDA Vendor D
EDA Vendor C
Tech A
OPS SCP
A
A
AA
top related