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