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

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