Open Process Spec Adoption: a Case Study

Transcription

1 Open Process Spec Adoption: a Case Study June 3 rd, 2014

2 AGENDA 2 OpenPDK & OPS Introduction What does OPS looks like? Let s do an openpdk with OPS

3 Target of OpenPDK Coalition 3 a set of open standards to allow an OpenPDK to be created once and then translated into specific EDA vendor tools and specific foundry formats. Let s Start with PDK Inputs format Open Process Specification

4 SI2 OPDK Coalition 4 OpenPDK Coalition Board Chair: Jim Culp, IBM OpenPDK Technical Steering Group (TSG) Chair : Gilles Namur, ST ESD Open Process Specification (OPS) Symbols Tools Interface Callbacks & Parameters Pcell XML Packaging Pcell Common Language Grammar Unified Layer Model (DFMC) OPS to OA TechDB OPS to opendfm OpenPDK Working Groups

5 Supplier Device Specifications WHAT IS OPS? 5 Open Process Specification (OPS) is a standardized format for exchanging all data needed to generate a complete PDK. DRM DB Layer List XSL parser script Exchange (standardized) OPS.xml <Process> <Libraries> <Devices> <Layers> <Rules> OPS.xsd parser This is the SI2 OPS standard parser parser parser parser Customer PDK DRC LVS Library PEX

6 Why OPS? 6 ST is looking for a smarter & more complete electronic PDK input format because lots of data are missing or are not easy to be extracted in traditional edrm. Open Process Specification New Format : Allow Automation for PDK generation. Eases EDA Vendor sync. with foundries Inputs. Foundries Inputs DB OPS.xml <Process> <Libraries> <Devices> <Layers> <Rules> PDK EDA Tools

7 Why OPS? 7 ST wants to have this format defined as a standard and used across the industry because what ever is the format of the Database used by the supplier to manage the PDK inputs : The PDK generation flow remains the same. FM Supplier Other DB OPS.xml <Process> <Libraries> <Devices> <Layers> <Rules> Only one Flow d i t a r t f DRC PDK PEX LVS Library

8 Why OPS? 8 ST is looking for an efficient way to generate several PDKs in parallel without a huge over cost. OPS is an answer to this target. OPDK Working Groups motto: Write once, use many, (test forever)! You can produce any kind of PDK. DRC PDK for Tool A PEX EDA Tools A EDA Tools B OPS.xml <Process> <Libraries> <Devices> <Layers> <Rules> LVS DRC Library PDK for Tool B PEX Even better, with the help of EDA Vendors : OPS could become a techfile LVS Library

9 OPS.xml What does it looks like? OPS.xml <Process> <Libraries> <Devices> <Layers> <Rules>

10 What does OPS looks like? Human Readable Layer List Machine Readable Layer Declaration in OPS.xml <ops:rootlayer name="od abbreviation="od destination="core"> <ops:toolmappingnumber number="17" tool="oa"/> </ops:rootlayer> <ops:purpose opsname="drawing name="drawing abbreviation="drg destination="core"> <ops:toolmappingnumber number="-1" tool="oa"/> </ops:purpose> <ops:cadlayer name = "OD;drawing" alias="od" opsrole="diffusion" role="diffusion" description = "Defines ACTIVE Area" destination = "core" exponumber = "1"> <ops:refrootlayername value="od"/> <ops:refpurposename value="drawing"/> <ops:streamio format="gdsii" number="1" datatype="0"/> <ops:streamio format="oasis" number="501" datatype="500"/> <ops:toolmappingnumber number="1001" tool="calibre"/> <ops:display transparencyorder="1" visible="true" selectable="true" con2chgly="true" drgenbl="true" valid="true" stipple="stipple3" linestyle="linestyle0" fill="lime" outline="lime" fillstyle=""/> </ops:cadlayer>

11 What does OPS looks like? 11 Human Readable DRM Machine Readable OPS.xml <ops:rule name="po.s.4"> <opc:documentation sectiontitle="po Design Rules (POLY)"> <opc:description>po space if at least one PO width is > µm (W) and if the parallel run length is > µm (L)</opc:Description> </opc:documentation> <ops:template name=""> <opc:parameter name="v1" value="0.120" type="float"/> <opc:parameter name="v2" value="0.140" type="float"/> <opc:parameter name="main" value="0.160" type="float"> <opc:siunit prefix="µ" siname="m"/> </opc:parameter> <ops:refcadlayeralias value="po"/> <ops:refcadlayeralias value="po"/> </ops:template> </ops:rule>

12 What does OPS looks like? XML Representation 12

13 What does OPS looks like? Library device description Parameter Pin Order Netlister 13 <edsdevice name="nfet" libname="demo45" description="regular-vt FET" symbolname="nmos3" symbolpinordermappinglist="d=d;g=g;s=s;b=b" layoutname="nfet" layouttype="pcell" > <edsdeviceparameter name="w" description="total Gate Width" defaultvalue="240n" type="string" units="lengthmetric" > <edsddfdeviceparameter callback="check_width_fet('w)" parseasnumber="1" parseascel="1" editable='cdfgdata->dimensionmode->value==\"totalwidth\"' display="1" storedefault="1" /> </edsdeviceparameter> <edsdeviceparameter name="l" description="gate Length" defaultvalue= 80n" type="string" units="lengthmetric" > <edsddfdeviceparameter editable="1" callback="check_length_fet()" parseasnumber="1" parseascel="1" display="1" storedefault="1" /> </edsdeviceparameter> <edsdevicenetlistinginfos> <edsdevicenetlistinginfo toolname="aucdl" modelname="nfet" netlistprocedure="_anscdlcompparamprim" instparameters="(w l)" componentname="mos" termorder="(d g s b)" nameprefix="m" /> </edsdevicenetlistinginfos> </edsdevice> demo45 nfet Regular-Vt FET w & l D;G;S;B CDL

14 A concrete OPS example 14 All along the process of definition of OPS, ST has contributed with several DRM examples : demo DRM 45nm. The example contains a complete DRM.pdf and its associated OPS.xml file aligned with the OPS.xsd defined by SI2 OPDKC OPS WG. OPS.xml <Process> <Libraries> <Devices> <Layers> <Rules> OPS.xsd

15 OpenPDK Let s do an openpdk with OPS

16 First edrm & PDK automation (DRC, pcell, QAcell) 40/45nm October 2009 XML edrm program start March rst phase spec frozen June rst IBM & ST discussion about edrm solution 32/28nm August 2010 SI2 OPS Working Group Creation October 2010 ST Contribution : first OPS UML description OPS History 16 March & October 2011 ST Contribution : 1 st & 2 nd OPS.xsd + «demo DRM 45nm 1.0» June 2011 DAC 1 st ST Results with OPS : «Dev. Lib generation from OPS» 20nm June 2012 SI2 DAC Demo : DRM-> XML-> OpenDFM (DRC) -> CDN/SNPS/MGC DRC > Layout Viewer 40nm August 2012 ST Contribution : «Updated demo DRM 45nm» (extended to address Multi Patterning / Local Interconnect Layers & specific rules / 3D Space) Since August 2012 used by ST to generate 20nm/14FDSOI/SI-Photonics PDK Device Library & Techfile November 2012 OPS.XSD 1.0 (semantic of the XML file) Since Q used by ST to generate 3D IC PDK Addons June 2013 DAC Demo : Rule subset from ST Demo DRM 45nm translation into OpenDFM deck November 2013 OPS.XSD 1.1 with ST Contribution : «demo DRM 45nm 1.6» Q1 & Q OPS Proof of concept Scripts : Automatic Translation OPS opendfm & OPS OpenAccess Techfile June 2014 DAC Demo & Presentation : Full ST «Demo DRM 45nm» translation into OpenDFM deck OPS translation into OpenAccess Techfile Q OPS.XSD 1.2 with ST Contribution : «Updated demo DRM 45nm» ST only OpenPDK at STMicroelectronics

17 First Step : Generate your OPS 17 ST is ready to produce their own edrm in OPS format. PDK Inputs DRM DB Layer List XSL & parser OPS.xml <Process> <Libraries> <Devices> <Layers> <Rules> Device Specifications OPS.xsd Deployed at Production level in ST PDKs 20nm (2011) / 14nm FD-SOI (2013) Silicon Photonics (SP) (2012) 3D IC Flow (SP + CMOS Sensor) (2013)

18 First Step : Generate your OPS 18 SI2 can Help you : PDK Inputs Get the ops2oatechdb translator Available on the Si2 website. Extract your Data from your OpenAccess Technology Database Bidirectional Translation Today limited to Layers description OpenAccess Technology Database OPS.xml <Process> <Libraries> <Devices> <Layers> <Rules> ops2oatechdb translator

19 First Step : Generate your OPS 19 Update your existing flows and scripts PDK Inputs DRM DB Layer List Script edrm Process Libraries Devices Layers Rules Updated Script OPS.xml <Process> <Libraries> <Devices> <Layers> <Rules> OPS.xsd This should not takes too long may be some weeks!!!

20 Then : Create your PDK 20 OPS.xml <Process> <Libraries> <Devices> <Layers> <Rules> parser parser parser Customer PDK DRC LVS Library OPS.xsd parser parser parser Pcells PEX At ST and/or SI2, Flows already exist to produce PDK Device Library, Techfile, DRC, Documentation Flows about to be released to produce Pcells

21 OPS.xml <Process> <Libraries> <Devices> <Layers> <Rules> OPS : Automation for DRC & Techfile Constraints GroundRuler 21 Techfile Coder DRC Coder Enriched OPS.xml <Process> <Libraries> <Devices> <Layers> <Rules> < Templates > New Template In-House Template DB Reference to DRM DB OPS Enriched OPS Reference to New Template opendfm Template DB New Template Generator In-House Template DB Techfile Code DRC Code New Template

22 OPS to DRC Generation 22 OpenDFM File OPS XML The Target Calibre, PVS or ICV Runsets

23 OPS to DRC Generation 23 The Result : SI2 propose a script that automatically generate an opendfm Deck from an OPS.XML file The full set of rules of the demo DRM 45nm provided by ST has been converted in opendfm through this script Current Generation & Validation Flow edrm Translation Manual Generation DRC deck For Tool A DRC deck For Tool C DRC deck For Tool B Validation Validation Report on Tool C Comparison Validation Report on Tool C Comparison OPS SI2 OPS2openDFM Automatic Script opendfm Validation Validation Report on Tool A Roadmap: opendfm Support in ST PDKs at Production Level 28nm (Q3 2014) / 14nm FD-SOI (Q4 2014) Silicon Photonics (SP) (Q3 2014)

24 OPS : Automation for Techfile Generation 24 OPS XML file <Process> <Libraries> <Devices> <Layers> <Rules> The Target Techfile All Layers Design Layers Derived Layers Via Definitions Physical Constraints Tool Directives

25 OPS To Techfile Generation 25 The Result : SI2 propose a script that automatically generate an OA techdb (openaccess techfile) with all the info relative to the layers ST current usage of OPS Coverage Layers Display GDS (Layer map side file) ST already has its own flow using OPS as input file to generate part of the techfile in some technos. Next Steps : Extend the automatic techfile generation with the process constraints through templates as decribed in previous slides. Extend the coverage of technos using this kind of automation. The Bi-Directional Translation allows to create an OPS file from an existing OA DB. Very Helpful for OPS Adoption

26 OPS to Techfile Optimisation 26 Enriched OPS.xml <Process> <Libraries> <Devices> <Layers> <Rules> < Templates > Generator Primary Techfile with «flat» constraints code Techfile Template One Rule One Template & One code / No table Techfile Optimisator Final Techfile with optimized constraints code

27 OPS : Automation for PDK device Library PDK Device Library generation push button flow from an OPS.xml as input. 27 OPS.xsd OPS XML file <Process> <Libraries> <Devices> <Layers> <Rules> OpenLibGen is an ST Internal API & Tools. ST already has its own flow using OPS as input file to generate part of the techfile in some technos. Ref Symbols Library Parameter Setup File.. Pcells Library Callbacks Directory Spiltted Techfile Directory > Next Steps : Remove as much as possible the additional set of input. Everything should be in OPS.

28 OPS : Automation for PDK documentation Device Library Documentation for End-User. 28 OPS.xsd OPS XML file <Process> <Libraries> <Devices> <Layers> <Rules> OpenLibGen is an ST Internal API & Tools. ST already has its own flow using OPS as input file to generate part of the techfile in some technos. Next Steps : Extend the doc template to enhance the full device Library documentation Device Lib Documentation Template (Word) Device Lib Documentation (Word)

29 OPDK/OPS Next Step : Open Pcells 29 Problems OpenPCell Addresses More productive programming effort Write once Pcell and Callback code Multi flow support Ease of integration into a PDK Assure high quality Expected Results are : Pcell generation productivity ++ Pcell quality enhancement One Spec Several Pcells code No flow supporting multiple language Fully supports SI2 OpenPcell Initiative Strong Link with OPS seen as added value Looking for Build-In Validation Concept OpenPDK at STMicroelectronics

30 OPDK/OPS Next Step : Open Pcells 30 Process Inputs Process Constraints Layer Definitions Devices PDK Spec Capture Tool OPS XML file <Process> <Libraries> <Devices> <Layers> <Rules> PDK Generation Tool PyCell Plugin TCL Plugin Custom Designer PDK Pyxis PDK PDK Testing Tool Models Vias Code Repository SKILL Python CLG SKILL Plugin Virtuoso PDK OPS with its PCells XML Repository solution is language agnostic and with the use of translators, the data can be adopted to any companies proprietary solution.

31 ST strongly supports PDK Standardization : Best Time-to-market PDK for IP-design flow Best PDK Development efficiency, quality Universal data store for design information (OA) Conclusion 31 EDA Vendors adoption of OPS is now a must-have to deploy across Industry within ST foundry offer. OpenPcell & opendfm Last Spec Benchmark to be done Automatic Techfile Constraints generation. Working with EDA Vendors to find a production solution ST willingness to being more involve in Open3D & Silicon Photonics TABs ST already uses OPDK in production advanced & legacy technology PDKs.

32 THANK YOU