PDK Automation An IBM Perspective

Transcription

1 PDK utomation n IBM Perspective Matthew Graf, OPDKC James Culp, ODFMC Si2 Con Oct. 20 th, 2011

2 IBM s PDK Development History Timeline OpenPDK OpenDFM Chip Design groups develop their own PDK Enablement Org formed. Develops a unified PDK for multiple design groups Enablement Organization develops unified multi vendor PDK Few common standards PDK was process centric Mostly IP Test validated Many of today s 200mm kits evolved from the GR s and process specs from these PDKs One Common PDK Multi Vendor Decks Multiple Extraction Flows Design Rule standards Formal test regressions Investment in automation Litho Rules appear DFM initiatives Device Scaling Issues Common multi vendor PDK Engineered ctive Devices DFM Matures Sub Resolution Patterning Continue: utomation Investment Multiple Extraction Flows Design rule standards Formal test regressions

3 Today s IBM s 300mm PDK creating standards for automation Goundrules & Process ssumptions LVS Truth Table Design Manual Database Matrix of # s XML Semi auto Supporting uto/man Function. Test SKILL SKILL TVF Tools PERL ICV TCL PERL DIT 1 Design Manual 10/24/2011

4 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 ssumptions, 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.

5 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 uto Testcase generation code & Test Results Summary software utomation 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.

6 Return on Investment? ~75-80% code reuse from one technology to the next up thru 28nm. Goundrules & Process ssumptions LVS Truth Table Design Manual Database Tech Skill TVF ICV TCL PERL Tools Test ~75 80% reuse Reuse examples: Same GR wording (less #s), Same deck code (less #s), Same testcase gencode (less #s) Technology s #s come from DMDB DIT 1 Design Manual Design Manual B Tech B Skill TVF ICV TCL PERL Tools Test B 1 DIT: is an XML architecture for designing, writing, managing, and publishing information. 10/24/2011

7 DMDB Consistency Checks n On Going Focus Goal: ssure content correctness of the Design Manual DataBase. Examples of inconsistencies: o New DRC rule conflicts with an existing rule o Typo errors in Database o New Layer requirements not fully specified ddressed by stack holder prereviews and new consistency check tools Stack holder review (Pre DMDB update) DMDB update uto DMDB Consistency Checking PDK Development PDK Test PDK Release

8 Historical DRC, Library, PEX Code Reuse 90% 80% 70% % Reuse of code 60% 50% 40% 30% 20% 10% Reasons for trend change? Lithography: Pitch Constraints MOL Changes Sub resolution Patterning Engineered ctive Devices: Thin Film Devices Fin FETS Estimate 0% 90nm 65nm 45nm 32/28nm 22/20nm 14nm

9 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 # changes Testchip PDK Production PDK But: Newer PDKs (beyond 28nm) require increased startup development.

10 Next step in this PDK Development process? Industry Issue: Escalating cost in developing multi vendor PDKs Our nswer: Industry Standards for PDK Development Why we chose to work thru Si2! solid Legal umbrella for collaboration joint ownership. Responsible, responsive standard s body ccepted by the ED Vendors that we work with. Si2 Goal is to gain an Industry Consensus!

11 OpenPDK Coalition ctivities Strategy: Targeted Workgroups Gilles Namur & Barry Nelson OPS Open Process Specification Mission: 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 ugment Si2 Symbol library with additional symbols, parameters, and properties Symbols Chair: Rich Morse Parameter Definition Chair: Li Chien Ting Simulation Interface Chair: Kristin Liu Parameter Checking and Relationships Chair: Ted Paone

12 Proposed OPDK utomation Flow WG Owners / rchitects Si2 STNDRD Schemas (XSD) MODULR OPS Technology OPS (XML) XML 2 Internal Format Convertor Internal Format Enhanced Symbols SCP WG Callbacks Parameters SPICE Netlist Flow DFMC Layers & Constraints* DRC/DFM LVS/PEX(LPE) Ty Targeting OPS WG Test Harness OPS Format Tech Input Type Model E.g., Fake edrm Data Flow SPECS DT CODE * P O C not complete Data In/Out Spec Validation Plug into OPS Spec Component OPS Standard Format OPS Consumer Format Vendor written

13 Next Step in PDK Development..OpenPDK "single source" for multi-vendor PDK development OPS SCP Input Once... Design Manual Database Content & Output Format XSD Schema XML Language Tools/Test Tech Vendor specific PDKs ED Vendor ED Vendor B ED Vendor C Design Manual ED Vendor D Innovation Through Collaboration 10/24/