Using OpenAccess to Replace a Proprietary EDA Database - PowerPoint PPT Presentation

Loading...

PPT – Using OpenAccess to Replace a Proprietary EDA Database PowerPoint presentation | free to download - id: 241adc-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Using OpenAccess to Replace a Proprietary EDA Database

Description:

My New OA Engine. Emulator 2004 Synopsys, Inc. ( 7 ) ... Identify objects that only exist on one side. Be sure to distinguish non- and persistent data ... – PowerPoint PPT presentation

Number of Views:22
Avg rating:3.0/5.0
Slides: 23
Provided by: eda90
Learn more at: http://www.eda.org
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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 -)
About PowerShow.com