Using OpenAccess to Replace a Proprietary EDA Database

1
Using OpenAccess to Replace a Proprietary EDA
Database

• Mark Bales
• EDP 2006
• 13 April 2006

2
Introduction

• Use Models
• Translation vs. Synchronization vs. Emulation
• Determining if Emulation Makes Sense
• Emulation Goals
• Steps for Constructing Emulator
• Expected Problems
• Time and Effort Expectations

3
Notes

• Using OA notation throughout
• Presentation is sparse
• Paper has more info, but this topic could be a
  book
• A Cookbook for using OA in an existing system
• Wont work if youre a recipe cook
• If you do this, use experienced developers
• Experts on your existing database
• At least a good familiarity with OA

4
Use Models Data Translation
My System
My Program(s)

• OA data translated to internal format
• Unchanged programs use internal data
• If I/O time short compared to program run time,
  can be OK
• May lose data in round-trip depending on
  OA/Other data models
• Fails miserably in multi-vendor flow which
  requires frequent switching to/from OA data
  format
• Generally favorable to application groups

My Data
X
OA Data
5
Use Models Data Synchronization
My System

• OA data read into VM and then synchronized with
  internal format
• Unchanged programs use internal data
• Makes system appear to use OA data natively
• Can greatly reduce capacity and/or performance if
  care is not taken
• May lose data in round-trip
• Can work well if OA VM Data can be mostly paged
  out
• Fails miserably if combined system has engines
  that use OA VM data natively

My Engine(s)
My Engine
My New OA Engine
My VM Data
OA VM Data
S
OA Data I/O
OA Data
6
Use Models Emulation
My System
My Engine(s)
My Engine
My New OA Engine

• OA data read into VM and preserved as is
• Emulation layer provides older API on new data
• Single copy of data raises capacity and
  performance
• Works great as new engines are written to use OA
  data natively
• Allows migration of product engines in piecemeal
  fashion

Emulator
OA Data Subsystem
OA VM Data
OA Data
7
Investigation

• Does emulation make sense?
• API (mis)match
• Benchmark OA vs. current
• size (both VM and disk)
• open/save speed
• traversal speed
• Data translation can work
• If I/O time small percentage it will work
• Stay away from data synchronization if at all
  possible
• System will be too complex, and artificially
  limit capacity

8
Goals

• Build an emulation layer
• Save translation or synchronization for some
  other project
• Little or no state in emulation layer
• Layer as thin as possible
• Use as few extensions as possible
• Maintain the greatest interoperability
• Make as maintainable as possible

9
Steps in Constructing Emulation Layer

• Analyze/compare data models
• Do first-level mapping
• Identify API issues
• Modify existing APIs
• Start API construction
• Core Functionality (program shown to work)
• Flow Functionality (full flow works w/one
  example)
• Flow Complete (full flow works w/most examples)
• Full Functionality (production quality)

10
Analyze/Compare Data Models

• Match objects and class members
• Look first for commonality
• Drives thickness of emulation layer
• Look second for differences
• Drives extensions that will be needed, both
  extensions to existing objects and new objects
• Look lastly for differences among commonalities
• For example, a physical connection of shapes
• May uncover fundamental incompatibilities

11
Do First-Level Mapping

• Map objects as is possible
• Look from multiple perspectives
• Basic object and class members
• Inter-object relationships
• Access and traversal
• Creation and deletion (including side-effects)
• Identify objects that only exist on one side
• Be sure to distinguish non- and persistent data
• Mostly an issue within OA relative to
  applications
• Above all, dont spend too long on this!

12
Example API Mapping
13
Identify API Issues/Modify as Needed

• Current APIs may be incompatible with OA
• Returning pointers to objects
• Returning char instead of string
• Change other API items to bring closer to OA
• Change current defines/enums to match OA to
  reduce mapping in layer
• Add new OA objects to existing APIs to allow apps
  to change to accommodate new objects (e.g.,
  routes)
• Do as much or as little of this as you want to
  and can
• Practical considerations enter at this point
• Resistance of application groups to changes
• Performance or capacity limitations in existing
  system

14
Start API Work

• Start with mydb.h
• Build stubs for all functions
• Fill out, starting with open/close/create
• Choose an ordering among basic function classes
• Shapes
• Instances
• Nets/Connectivity
• Properties/Groups
• Technology Info
• Move quickly through APIs
• Try to get to 80 ASAP
• If stuck on function, put it aside and move on

• Advanced Items
• Parasitics
• Timing
• Module/Occurrence Info
• Scan Chain
• Floorplanning
• Extensions
• To existing objects
• New objects

15
Milestones of Completion

• Core Functionality
• System shows life
• Best if use small test program
• Cant get hung up on testing at this point
• Flow Functionality
• One or more major tasks able to complete
• May require restrictions on data
• Flow Complete
• All major tasks able to complete
• May not work for all designs
• Full Functionality
• Production quality
• Works at least as well as old system, with higher
  capacity

16
Expected Problems (1)

• Prep
• Resistance to needed changes
• Changes difficult to design
• Core Functionality
• Compiler mismatch
• First major bugs
• C object hierarchies
• Unanticipated API changes needed
• All APIs related to library, tech, view
  manipulation
• May need extensions

17
Expected Problems (2)

• Flow Functionality
• Definitely need extensions
• More complex functions
• Unanticipated complex interactions
• Performance issues
• Full Functionality
• Last 10 is hard!
• May not get to 100
• This may be perfectly OK
• Final bugs
• The project can seem to take forever, but

18
Expected Problems (3)
There Is Light At the End of the Tunnel!
you get the idea -)
19
Expectations of Effort

• Development Stage Effort
• Prep Work Indeterminate
• Analysis/Mapping
• Current API Update
• CoreFlow Functionality (80) 1 2 months
• Flow Complete (90) 1 2 months
• Full Functionality (100) 2 4 months

20
Performance

• OA API may be slower than old API
• Direct use of data structures and pointers
• Use of macros or inline methods
• If old API uses no macros, performance will be OK
• Emulation layer slows system even more
• Thicker layers generally have worse performance
• More state in layer usually ? worse performance
• Exception is functions to decrease
  traversal/lookup time
• If you have two or more APIs, state can be fatal

21
Good News

• Reduced performance offset by
• Greatly-reduced memory
• Reduced working-set size
• Open/Save usually much faster
• DB speed often a small fraction of time
• Most long-running algorithms translate data into
  a different internal view, run, then update
• Halving DB performance ? 2 4 drop in overall
  performance

22
Summary

• Almost always possible to do so
• Can take a short or long time, depending on how
  well models match, personnel, effort levels
• Drives evolution towards new model
• New engines written natively on OA
• Doesnt require everything to change at once
• Old engines persist as long as needed
• Best performance and capacity as long as OA is
  better than old model -)