This presentation describes the process whereby design databases within multiple design flow environments were migrated from vendor and proprietary to OpenAccess standard for design data interoperability and cross-flow design data exchange.

1. OpenAccess Migration:
Design Environment Integration
DesignCon 2004
Timothy J. Ehrler
Senior Principal Engineer
SoC Design Technology, Design Technology Group
Philips Semiconductors
tim.ehrler@philips.com

2. Agenda
• Migration Objectives
• Design Environments
• Migration Strategy
• Migration Progress
Timothy J. Ehrler, Philips Semiconductors, DesignCon 2004, Feb. 2004 2

3. Migration Objectives (1)
- Design Data Process (within Design Environment)
• Improve designer productivity
– Reduce/eliminate design data exchange files
• Reduce storage requirements
• Reduce import/export time
• Reduce design data content and [mis-]interpretation issues
– Improve inter-task operability
• Enable more efficient tool usage
• Simplify task methodology development
• Allow refinement/optimization of current methodologies
Timothy J. Ehrler, Philips Semiconductors, DesignCon 2004, Feb. 2004 3

4. Migration Objectives (2)
- Design Data Exchange (among Design Environments)
• Improve design data exchange
– Robust interface for IP and blocks
• Provide standard, consistent database access
• Allow more appropriate/applicable tool usage
• IP generated/created independent of tool/environment
– IP & block usage independent of source environment
• IP in any DE available for use within any other
– Significantly reduce reuse requirements
• Reduce design data file requirements
• Consistent design data/information requirements for IP and blocks
Timothy J. Ehrler, Philips Semiconductors, DesignCon 2004, Feb. 2004 4

5. Design Environments (1)
- Overview
System & IP/IC Creation
Software IP Integration
Design
Environment
Design System- Analog / Radio
Data on-Chip Mixed-Signal Frequency
Process Design Design Design
Environment Environment Environment
Design
Data
Exchange
Timothy J. Ehrler, Philips Semiconductors, DesignCon 2004, Feb. 2004 5

6. Design Environments (2)
- Current Task Flow Decomposition
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
data
data
Timothy J. Ehrler, Philips Semiconductors, DesignCon 2004, Feb. 2004 6

7. Design Environments (3)
- OpenAccess Based Task Flow Decomposition
Task
Task
Flow
Flow
Design
Environment Task
Task
Flow
Flow
common
OpenAccess database
Task
Task
Flow
Flow
Task
Task
Flow
Flow
Task
Task
Flow
Flow
Timothy J. Ehrler, Philips Semiconductors, DesignCon 2004, Feb. 2004 7

8. Migration Strategy (1)
- Identification
• Determine target design environment
– Customer need
• Based on [preferred] market served
– Design environment “completeness”
• Environment, task-flow specifications
available
– Domain coverage by OpenAccess tools
• Determine task flow interfaces
– Identify OpenAccess-supported data
• LEF, DEF, floorplanning, routing, etc.
• On a per task-flow basis
– Identify common interface data
requirements
• Based on supported OpenAccess data
constructs
Timothy J. Ehrler, Philips Semiconductors, DesignCon 2004, Feb. 2004 8

9. Migration Strategy (2)
- Retargeting
• Identify OpenAccess supported tools
– Vendor supplied
• Aligned with roadmap
– Internal, proprietary
• Currently OpenAccess based
• To be available per roadmap
• Retarget data accesses
– OpenAccess replaces internal
• Wherever possible and compliant
• Includes sub- task-flows as defined
– “disconnect” primary inputs, outputs
• Persistent OpenAccess data from
previous task-flow(s)
– Re-direct [temporary] internal storage
• Use OpenAccess constructs where
possible
Timothy J. Ehrler, Philips Semiconductors, DesignCon 2004, Feb. 2004 9

10. Migration Strategy (3)
- Refinement
• Take advantage of persistent data
– Reduces, eliminates import/export
– May allow concurrent tasks
• Extent determined by static/dynamic
OpenAccess mechanism of tool
• Modify task order within task-flows
• Eliminate tasks within task-flows
• Combine tasks within task-flows
• Modify task-flow order
• Combine/merge task-flows
Timothy J. Ehrler, Philips Semiconductors, DesignCon 2004, Feb. 2004 10

11. Migration Progress (1)
- Achievements
• OpenAccess based/compliant tools identified
– Static/dynamic access methods under review
• Non-OpenAccess based tools identified
– Requires “legacy” access formats and methods
• Internal/proprietary tools identified
– Application development/migration required
– Initial OpenAccess application can serve as pilot/example
• Task-flow interfaces defined
– Based on specifications and guides
– Need to fully correlate with OA-supported data
Timothy J. Ehrler, Philips Semiconductors, DesignCon 2004, Feb. 2004 11

12. Migration Progress (2)
- Roadmap
• Initial task-flows by mid-year 2004
– Offer most productivity improvement to users
– Comprised primarily of third-party EDA vendor tools
– Exemplify migration process
• Subsequent releases
– Progressive design cycle improvements
– Reduced legacy file support requirements
– Internal/proprietary application migration/development
• Later releases of other design environments
– Similar objectives, constraints
– Provide support for IP reuse
– Enable inter-environment design data exchange
Timothy J. Ehrler, Philips Semiconductors, DesignCon 2004, Feb. 2004 12

13. Last Foil