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 • Won’t work if you’re a “recipe cook” • If you do this, use experienced developers • Experts on your existing database • At least a good familiarity with OA

4. 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 Use Models – Data Translation My System My Program(s) My Data X OA Data

5. 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 Use Models – Data Synchronization My System My Engine(s) My New OA Engine My Engine OA VM Data My VM Data S OA Data I/O OA Data

6. 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 Use Models – Emulation My System My Engine(s) My New OA Engine My Engine 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, don’t 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 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 Start API Work

15. Milestones of Completion • Core Functionality • System shows life • Best if use small test program • Can’t 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 StageEffort • Prep Work Indeterminate • Analysis/Mapping • Current API Update • Core+Flow 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 • Doesn’t 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 ;-)