Your SlideShare is downloading. ×
0
DATE 2005 - OpenAccess Migration within Philips Semiconductor
DATE 2005 - OpenAccess Migration within Philips Semiconductor
DATE 2005 - OpenAccess Migration within Philips Semiconductor
DATE 2005 - OpenAccess Migration within Philips Semiconductor
DATE 2005 - OpenAccess Migration within Philips Semiconductor
DATE 2005 - OpenAccess Migration within Philips Semiconductor
DATE 2005 - OpenAccess Migration within Philips Semiconductor
DATE 2005 - OpenAccess Migration within Philips Semiconductor
DATE 2005 - OpenAccess Migration within Philips Semiconductor
DATE 2005 - OpenAccess Migration within Philips Semiconductor
DATE 2005 - OpenAccess Migration within Philips Semiconductor
DATE 2005 - OpenAccess Migration within Philips Semiconductor
DATE 2005 - OpenAccess Migration within Philips Semiconductor
DATE 2005 - OpenAccess Migration within Philips Semiconductor
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

DATE 2005 - OpenAccess Migration within Philips Semiconductor

496

Published on

This presentation describes the OpenAccess design database migration strategy within multiple design flow environments for design data interoperability and cross-flow design data exchange.

This presentation describes the OpenAccess design database migration strategy within multiple design flow environments for design data interoperability and cross-flow design data exchange.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
496
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  1. DATE 2005 OpenAccess Migration within Philips Semiconductors Timothy J. Ehrler Senior Principal Engineer Design Technology Group Philips Semiconductors tim.ehrler@philips.com
  2. Participation & Involvement • Direct OpenAccess Relationships – Member of OpenAccess Coalition – Member of the OpenAccess Change Team – Vice-chair of the Golden Gate Bridge Working Group • Between OpenAccess and Synopsys MilkyWay – Chairperson of the Timing/Constraints Working Group – Conference presentations, panel discussions • Philips Activities – Training – Information distribution & education – Source/binaries downloads – Application development – Design environment migration – Timing Constraint Development & Implementation tje – DATE 2005 OpenAccess @ DATE 2005, Tim Ehrler, Mar 2005 2
  3. The State of Design Processing • Design issues now requires more effective solutions – Feature size, complexity, reuse, etc. From SSDE SPEC Screeners SDB Contents: – Individual EDA vendors Contents: Verification Design-In IP Screening Simulation RTL Simulation IP cores Debug Debug SVC Hierarchy planning LDV Verification Power EC Equivalence EC Debussy Analysis Formality Formality Checking Architectural Analysis Partitioning & Diesel Coverage focus Behavioral RTL Automatic flatten for P&R IP on particular design Design Bus interfaces Software code development Ref Libs External Netlists (Firm IP) Floorplanning Netlist Screening pre-route P/G, clock nets pre- Area estimation Verilog or VHDL Prototyping spaces (synthesis, timing, Physcial RSP platform Exploration Physical Partitioning SoCEncounte Logic Synthesis Logic DFT RTL Partitioning Design Feasibility: Performance, Area, Synthesis Constraints SoC Exploration r Synthesis Architecture Constraints Screening LDB Encounter DMS Compiler Power, Clocking, Test management routing, etc.) Verilog or VHDL RTL description Contents: Physical Physical Contents: Physical Block level synthesis Ref Libs Chip Physical Layout: Partition Partition Partition Architecture Cell and Timing P&RConstraints Netlist Block Physical Cell & Block Constraints –Library vendor Design provide the No Functional can Create top level design (CPU, DSP, analog, memory, HDLi templates, I/O & Hierarchical Timing driven extensions Synthesis Verilog or VHDL I/O, schematics) To Physical DFT “optimal” design solution Models Planning Placement Post AMSDE/ Based Placement DFT (scan insertion, MBIST, LDB Optimisation Clock Tree Optimisation RFDE JTAG, padring) Power Grid Design / Floorplanning Analysis Verilog or VHDL Contents: Optimisation – Specific design issues Layout: Routing & Structural Netlist Signal Routing Post Route AMSDE Final Contents: Ref Libs Chip Assembly Antennas Decaps/ Crosstalk padEditing Floorplan Fillers Insert core & fillers Fix RFDE IP Design Implementation Design Finishing Symbolic verification require “best-in-class” tools Library Logic & Timing Delay Calculation Static Timing Analysis Bond diagram Verification Hierarchical Verification Gate-level Simulation Gate- From Models address to Signoff STA Power Timing & Parasitic Distribution AMSDE/ Verilog or VHDL Power Estimation LDB GDS-II Extraction Analysis Verification Analysis Crosstalk RFDE Screener Lib Rules, Block Implementation Verification of specification Timing, Chip Assembly Physical Physical Physical Package Partition Contents: DRC,Partition Partition LVS, Physical Timing Power model Plots, Extraction,model model Circuit To Factory Finish IP cores Simulation, Back-annotation Back- and Mask Making Chip Physical & Timing Analysis Verification Layout Test Program Package Design Design Chip Assembly ESD Physical tje – DATE 2005 Generation Finishing Verification Finishing To Mask Shop OpenAccess @ DATE 2005, Tim Ehrler, Mar 2005 3
  4. Impact on Design Data • Design data explosion becomes significant bottleneck – Many tools require proprietary data formats – Suites often import same data between different tools – Translators must often be built to transfer data between tools – New tool evaluation / deployment implies major CAD design environment / flow integration efforts tje – DATE 2005 • Design data export / translate / import takes time … OpenAccess @ DATE 2005, Tim Ehrler, Mar 2005 4
  5. Addressing the Problem • Standardized design data model / structure • Standard, extensible interface to design data – Provides consistent access by any compliant EDA tool – Enables prototypical application / database development • Corresponding reference implementation – Provides compliant database, eliminating internal developments – Enables quick acceptance & application development Synthesis Static Timing Design for Test Standard Standard Data Reference Floorplanning API Implementation Model Place & Route tje – DATE 2005 Prototype EXT Application API OpenAccess @ DATE 2005, Tim Ehrler, Mar 2005 5
  6. Finding an Available Solution • Community effort to provide true IC design tool interoperability, not just design data storage / exchange – Employs open, standard application programming interface (API) • Built on Genesis 2 contributed by Cadence Design Systems • Includes extensible prototyping capabilities • Enables custom design data management – Provides reference database implementation supporting the API • Supports multiple platforms & operating systems • Includes additional utilities & translators (import/export) – Supported by neutral Coalition of industry leaders under Silicon Integration Initiative (SI2) bylaws tje – DATE 2005 • Directed by 12-member Change Team OpenAccess @ DATE 2005, Tim Ehrler, Mar 2005 6
  7. Where OpenAccess is Applicable System & IP/IC Creation Software IP Integration Design Environment Design Data System- Analog / Radio Processes on-Chip Mixed-Signal Frequency Design Design Design Environment Environment Environment Design Data tje – DATE 2005 Exchange OpenAccess @ DATE 2005, Tim Ehrler, Mar 2005 7
  8. Improving Design Data Processing • Reduce / eliminate design data exchange files – Reduce storage requirements – Reduce import/export time – Reduce design data content and [mis-]interpretation issues • Improve task interoperability – Enable more efficient tool usage – Simplify task methodology development tje – DATE 2005 – Allow refinement / optimization of current methodologies OpenAccess @ DATE 2005, Tim Ehrler, Mar 2005 8
  9. Enhancing Design Data Exchange • Robust interface for IP, blocks Flow A Flow B – Provide standard, consistent database access – Allow more appropriate and applicable tool usage – IP generated or created independently of tool / environment Flow A Flow B • Significantly reduce reuse requirements – Reduce design data file requirements – Consistent design data and information requirements for IP and blocks • IP & block usage independent of source environment tje – DATE 2005 – IP in any design environment available for use within any other OpenAccess @ DATE 2005, Tim Ehrler, Mar 2005 9
  10. Evolving Data-File Based Flows … data data input Task Task Flow Flow internal data Design data Environment Task Task Flow Flow data data Task Task output Flow Flow data data Task Task Flow Flow data data Task Task Flow Flow tje – DATE 2005 data data OpenAccess @ DATE 2005, Tim Ehrler, Mar 2005 10
  11. … to OpenAccess Environments Task Task Flow Flow Design Environment Task Task Flow Flow OpenAccess database common Task Task Flow Flow Task Task Flow Flow Task Task Flow Flow tje – DATE 2005 OpenAccess @ DATE 2005, Tim Ehrler, Mar 2005 11
  12. Migration Roadmap • OpenAccess 2.2 supporting tool availability at issue – Only OA 2.2 addresses release compatibility, supports needs – Production EDA tool releases occur 2nd quarter at earliest – Aligned design environments releases occur end of 3rd quarter – Too late for full evaluation and development of task flows • Develop limited OpenAccess task flows in 2005 – In parallel with current aligned design environment releases – Implement where designer can gain most productivity • DFII based flows (AMSDE, RFDE, IP blocks) replacing CDBA • Interfaces between SoCDE and AMSDE & RFDE (e.g., ICC) • Full deployment with 2006 aligned releases – Embracing OA 2.2.x with richer tool support (timing constraints, etc.) – Include internal & external DFT capabilities – Better support Philips reuse methodologies tje – DATE 2005 – Address and resolve library issues and concerns OpenAccess @ DATE 2005, Tim Ehrler, Mar 2005 12
  13. Timing Constraints Development • SDC-equivalent timing constraint capability requested – Requirements defined by workgroup from Oct. 2003 through Mar. 2004 • Persistent data representation only, not command language equivalence – Cadence lacked resources, so Philips volunteered development • Development done from Aug. 2004 through Feb. 2005 – Based on OA 2.2 beta b005, later on release 2.2.0 – Constraints classified into 5 categories for implementation – Compatibility and extensibility primary concerns • Required non-trivial re-architecture and data structure changes – Implementation turned over to Cadence for integration Mar 1. 2005 • Affected over 50K lines in over 130 new or modified source files • Full regression test cases • ‘doxygen’ API specifications tje – DATE 2005 • Will present experience at 6th OpenAccess Conference in April OpenAccess @ DATE 2005, Tim Ehrler, Mar 2005 13

×