OpenPDK Symbol, Callbacks and Parameters Working Group

Transcription

1 OpenPDK Symbol, Callbacks and Parameters Working Group Rich Morse Marketing & EDA Alliances Mgr. SpringSoft October 20, 2011

2 Overview The SCP working group is focused on developing specifications for a standard symbol set; parameter checking and relationships (callbacks); and parameter definition including the simulation and verification interface Includes members from Cadence, IBM, Intel, Mentor, Springsoft, ST, and Synopsys Last January, the working group divided into 4 sub-groups to focus on spec development 2

3 Leadership Chairman - Barry Nelson, Cadence Symbols Rich Morse, SpringSoft Parameters - Li-Chien Ting, Cadence Simulation TBD Callbacks Ted Paone, Cadence Standard of Standards Dave Mallis, Si2 3

4 XSD/XML - OPDK Standard Format Define a common format/look/framework for all OPDK standards One wrapper referencing all normative and nonnormative components Maximize machine-sensibility Minimize need for written specifications Automated transformation to PDF, HTML, RTF, etc. Maximize reuse of individual semantic components in presentations, tutorials, documents

5 High-Level Vision of opdk Electronic design rule file (edrm) OPS XML file Call Back Others: OpenDFM OPEX Cell description Symbols SCP Para met ers Sim inter face PDK A PDK B PDK C

6 Proof-of-Concept Tool Testing PRESENTATION XML XSD CSS SEMANTICS vi emacs eclipse XmlMind Serna Altova AUTHOR, EDIT Alphabet soup! XSL CSS XML XSD Free Free + Pay Pay Xalan Saxon expat XmlMind text+gui text+gui Serna Altova XFORM text (color+indent) FO LEGEND HTML PDF doc odt text UML SQL BNF YAML normative format browser Acrobat Word Office topcased ArgoUML MySQL PUBLISH

7 SYMBOLS 7

8 Symbols Working Group Objectives Create a method and specification whereby symbols can be portable among EDA tools, design databases and technologies Symbol elements will appear and function the same in all tools when the specification is followed (i.e. Symbol graphic, pin locations, origin, symbol boundary) Use OA symbols as the reference implementation Expand the existing symbol library 8

9 Taking Inventory 66 existing symbols in the Si2 library Retain legacy library 23 source symbols donated by SpringSoft Planned ESD symbol donation from IBM Symbol donation from (your name here) 9

10 Flow Initial assumption: Specification Non OA Library YAML, XML or EDIF Description Non OA Library Non OA Library OA Reference Library 10

11 Symbol opdk Flow Existing OA Library + Contributions Rules HTML SVG XML Generation Scripts OA Reference Library Normative XSD XML Non normative Validation Non OA Library Non OA Library OA Library 11

12 OPDK Standard Format, Symbols si2s4s.xsd si2stdsym.dita <motivation> <usecases> <requirements> <models> <scope> <credits> <references> <instances> Tags Rules NORMATIVE INFORMATIVE D DITA scc.xmi scc.uml scc.xsd XML nmos3 nmos4 OA nmos3 nmos4 YAML nmos3 nmos4 Reference examples

13 Symbol Descriptions Instance boundary Symbol origin Center of pins Drawing (XML), image (SVG) & coordinates (HTML) stored in the XML database Rules (limitations) are part of XSD 13

14 Symbol Descriptions Symbol drawings are well known & don t need further standardization XSD can allow the drawing and/or image to vary Interoperability & portability depend on 3 basic elements: Pin locations Symbol origin Instance bounding box XSD can restrict alternate coordinates for a symbol of the same name NMOS4 14

15 What Remains to Be Done Convert the OA Symbol library to XML Establish the rules in XSD Test symbol generation in a non-oa environment Targeting the end of the year for submission 15

16 PARAMETERS 16

17 Parameter Working Group Objectives Standardize parameter data organization & inheritance Standardize parameter description attributes Standardize parameter UI attributes Using XSD/XML to express the parameter description 17

18 Component Description Format (CDF) Container for parameters, callbacks and simulation interface information Can be specified at different design data levels Defined precedence order produces effective CDF 18

19 CDF Container CDF container refers to the full specification of a CDF at the library or cell level It contains specification for Data callback for init and done UI field sizes Parameter and callback Simulation interface Parameter mapping User property CDF Container 19

20 Parameter Definition Key attributes of a parameter name type int, float, string, boolean, net-set, user default value choices Discrete set of possible values for the given type parse-as Built in parser for number, float, int, point list, layerpurpose-list Custom parser for user type parameter store-default dont-save use 20

21 Parameter UI Attributes Parameter attributes for a UI based environment prompt unit resistance, capacitance, inductance, conductance, time, frequency, power, power-db, length-metric, length-english, angle, voltage, current, temperature, area-metric, area-english ui-type int, float, string, toggle, radio, cyclic, button editable display 21

22 SIMULATION 22

23 Simulation Information Working Group Objectives Provide flexible and consistent mechanism to transfer device properties to netlist Standardize simulation information attributes Use XML description for simulation information Simplify user netlist procedure creation and evaluation Allow callbacks to manipulate simulation information 23

24 Simulation Information Definition Simulation information contained in CDF Represents the device parameters and properties Set determined by the target EDA simulation netlister Defined by the master CDF Information can be specified and stored at different design data levels Information executed with effective CDF Information attributes to be standardized in the opdk standard using XSD 24

25 Simulation Information Content Standardized simulation information attributes and arguments Simulation Information Simulation Information <netlistprocedure> Simulation Information <netlistprocedure> <terminalorder> <netlist procedure> <terminalorder> <nameprefix> <terminal order> <nameprefix> <terminalmapping> <name prefix> <terminalmapping> <parameterlist> <terminal mapping> <parameterlist> <propertymapping> <parameter list> <propertymapping> <parameterexpressionlist> <property mapping> <parameterexpressionlist> <> <parameter expression list> <> < > OPDK Standard: XSD Key attributes Translation Device netlist Device netlist Device netlist 25

26 Simulation Information Syntax Description for simulation information - XML Simulation Information <netlist procedure> <terminal order> <name prefix> <terminal mapping> <parameter list> <property mapping> <parameter expression list> < > Simulation Information Input Files XSD simulator: tool1 procedure: none param-list:[w l finger m] term-order: [D G S B] prop-map: {w: weff} simulator: tool3 procedure: none param-list:[w l finger m] term-order: [D G S B] term-map: {D:d,G:g,S:s,B:b} XML XML simulator: tool2 procedure: none param-list:[w l finger m] term-order: [D G S B] name-prefix: X simulator: tool4 procedure: lvsproc param-list:[w l finger m] term-order: [D G S B] callbacl: moscb Parameter Property View Info Simulation Info XML CDF Container 26

27 CALLBACKS 27

28 Callback Working Group Objectives Define callback format to meet 20nm callback requirements Many more simulation callbacks Create a method and specification so that a single callback description can be portable among EDA tools, and design databases Support for interactive and non-interactive callback evaluation Simplify callback creation by specifying standard automatic callbacks for common data validation Standardize user callback creation and evaluation Provide robust error handling 28

29 Callback Evaluation Automatic callback evaluation on any changes to parameter values Standardized invocation and actions Standard arguments Access to attributes and values Batch mode support User defined order Support for non-interactive error handling User control for callback evaluation Attributes control automatic checks and user callbacks 29

30 Automatic Validation Checks Eliminate need to write standard checking callbacks Constraints are stored as attributes on parameter (XSD) No need for secondary support files min/minexl max/maxexl epsilon range Verilog AMS support grid snapping grid offset 30

31 Support for User Callbacks Standardized callback arguments Example API support for CDF access Get/set parameters and values Access attributes and properties Consistent error handling On a CDF On individual parameters 31

32 Status Proposal accepted by group Additional functionality proposed by ST Adding to non-normative specification Creation of XSD standard started Target is mid-november

33 THANK YOU! 33