{"id":13831305,"url":"https://github.com/The-OpenROAD-Project/OpenDB","last_synced_at":"2025-07-09T13:33:23.199Z","repository":{"id":47788679,"uuid":"212851744","full_name":"The-OpenROAD-Project/OpenDB","owner":"The-OpenROAD-Project","description":"Database and Tool Framework for EDA","archived":true,"fork":false,"pushed_at":"2021-01-25T16:25:30.000Z","size":10502,"stargazers_count":100,"open_issues_count":7,"forks_count":44,"subscribers_count":12,"default_branch":"master","last_synced_at":"2024-08-05T10:16:49.363Z","etag":null,"topics":["database","eda"],"latest_commit_sha":null,"homepage":"","language":"C++","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"bsd-3-clause","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/The-OpenROAD-Project.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2019-10-04T15:52:08.000Z","updated_at":"2024-07-31T02:47:20.000Z","dependencies_parsed_at":"2022-09-23T20:01:14.223Z","dependency_job_id":null,"html_url":"https://github.com/The-OpenROAD-Project/OpenDB","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/The-OpenROAD-Project%2FOpenDB","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/The-OpenROAD-Project%2FOpenDB/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/The-OpenROAD-Project%2FOpenDB/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/The-OpenROAD-Project%2FOpenDB/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/The-OpenROAD-Project","download_url":"https://codeload.github.com/The-OpenROAD-Project/OpenDB/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":225553371,"owners_count":17487293,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["database","eda"],"created_at":"2024-08-04T10:01:24.192Z","updated_at":"2024-11-20T12:31:39.089Z","avatar_url":"https://github.com/The-OpenROAD-Project.png","language":"C++","funding_links":[],"categories":["C++"],"sub_categories":[],"readme":"# Introduction\n\nOpenDB is a design database to support tools for physical chip\ndesign. It was originally developed by Athena Design Systems. Nefelus,\nInc acquired the rights to the code and open sourced it in 2019 to\nsupport the DARPA OpenROAD project.\n\nThe structure of OpenDB is based on the Cadence Design Systems text\nfile formats LEF (library) and DEF (design) formats version 5.6.\nOpenDB supports a binary file format to save and load the design much\nfaster than using LEF and DEF.\n\nOpenDB is written in C++ 98 with standard library style iterators.\nThe classes are designed to be fast enough to base an application\non without having to copy them into application specific structures.\n\n\n## Installation\n\n```\ngit clone https://github.com/The-OpenROAD-Project/OpenDB.git\ncd OpenDB\nmkdir build\ncd build\ncmake ..\nmake\n```\n\nThe original Athena code found in /zrouter is built using Makefiles.\nSee zrouter/src/BUILD/compilation_package_dependencies.\n\n## Directory structure\n\n```\ninclude/opendb/db.h - public header for all database classes\nsrc/db - private/internal database representations\nsrc/lefin - LEF reader\nsrc/lefout - LEF writer\nsrc/defin - DEF reader\nsrc/defout - DEF writer\n```\n\n## Database API\n\n:bangbang: We are still working on documenting the APIs. \nWe have over 1,800 objects and functions that we are still documenting (for both TCL and Python). \n**Contributions are very welcome in this effort**. Find starting points below.\n\n### TCL\nAfter building successfully, run OpenDB tcl shell using `./build/src/swig/tcl/opendbtcl`. An example usage:\n\n```\nset db [dbDatabase_create]\nset lef_parser [new_lefin $db true]\nset tech [lefin_createTech $lef_parser ./OpenDB/tests/data/gscl45nm.lef]\n```\n\nYou can find examples on using the API from TCL under `tests/tcl/` directory.\n\nThe full set of the tcl commands exposed can be found under `./build/src/swig/tcl/opendb_wrapper.cpp`. Search for `SWIG_prefix`.\n\n\n### Python\nAfter building successfully, run a Python shell using `python3`. Load `opendbpy module using:\n\n```\nimport importlib.util\nspec = importlib.util.spec_from_file_location(\"opendbpy\", \"./build/src/swig/python/opendbpy.py\")\nodb = importlib.util.module_from_spec(spec)\nspec.loader.exec_module(odb)\n\n# use it as following\nodb.[class_name]\n```\nYou can find examples on using the API from Python under `tests/python/` directory.\n\nThe full set of the Python classes exposed can be found under `./build/src/swig/python/opendbpy.py`.\n\n### C++\n\nAll public database classes are defined in `db.h`. These class\ndefinitions provide all functions for examining and modifying the\ndatabase objects. The database is an object itself so multiple\ndatabase objects can exist simultaineously (no global state).\n\n`dbTypes.h` defines types returned by database class member functions.\n\nAll database objects are in the `odb` namespace.\n\n`dbChip`\n`dbBlock`\n`dbTech`\n`dbLib`\n\nAll database objects have a 32bit object identifier accessed with the\ndbObject::getOID base class member function that returns a\n`uint`. This identifier is preserved across save/restores of the\ndatabase so it should be used to reference database object by data\nstructures instead of pointers if the reference lifetime is across\ndatabase save/restores. OIDs allow the database to have exactly the\nsame layout across save/restores.\n\nThe database distance units are **nanometers** and use the type `uint`.\n\n## Tests\nThere are a set of regression tests in /tests.\n\n```\n./tests/regression-tcl.sh\n./tests/regression-py.sh\n```\n\n## Database Internals\n\nThe internal description included here is paraphrased from Lukas van\nGinneken by James Cherry.\n\nThe database separates the implementation from the interface, and as a\nresult, each class becomes two classes, a public one and a private\none. For instance, `dbInst` has the public API functions, while class\n`_dbInst` has the private data fields.\n\nThe objects allocated in dynamically resizable tables the\nimplementation of which is in `dbTable.hpp`. Each table consists of a\nnumber of pages, each containing 128 objects. The table contains the\nbody of the struct, not a set of pointers. This eliminates most of the\npointer overhead while iteration is accomplished by stepping through\nthe table. Thus grouping these objects does not require a double\nlinked list and saves 16 bytes per object (at the cost of some table\noverhead). Each object has an id, which is the index into the\ntable. The lowest 7 bits are the index in the page, while the higher\nbits are the page number. Object id's are persistent when saving and\nreading the datamodel to disk, even as pointer addresses may change.\n\nEverything in the data model can be stored on disk and restored from\ndisk exactly the way it was. An extensive set of equality tests and\ndiff functions make it possible to check for even the smallest\ndeviation. The capability to save an exact copy of the state of the\nsystem makes it possible to create a checkpoint. This is a necessary\ncapability for debugging complex systems.\n\nThe code follows the definition of LEF and DEF closely and reflects\nmany of the idiosyncrasies of LEF and DEF. The code defines many types\nof objects to reflect LEF and DEF constructs although it sometimes\nuses different terminology, for instance, the object to represent a\nlibrary cell is called dbMaster while the LEF keyword is MACRO.\n\nThe data model supports the EEQ and LEQ keywords, (electrically\nequivalent and logically equivalent Masters) which could be used for\nsizing. However, it does not support any logic function\nrepresentation. In general, there is very limited support for\nsynthesis specific information: no way to represent busses, no way to\nrepresent logic function, very limited understanding of signal flow,\nlimited support of timing information, no support for high level\nsynthesis or test insertion.\n\nThe db represents routing as in DEF, representing a trace from point\nto point with a given width. The layout for a net is stored in a class\nnamed dbWire and it requires a special dbWireDecoder (which works like\nan iterator) to unpack the data and another dbWireEncoder to pack\nit. The data model does not support a region query and objects that\nare in the same layer are scattered about the data model and are of\ndifferent classes.\n\nThis means that whatever tool is using the layout information will\nhave to build it's own data structures that are suitable to the layout\noperations of that tool. For instance, the router, the extractor, and\nthe DRC engine would each have to build their unique data\nstructures. This encourages batch mode operation (route the whole\nchip, extract the whole chip, run DRC on the whole chip).\n\n\n# LICENSE\n\nBSD 3-Clause License. See [LICENSE](LICENSE) file","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FThe-OpenROAD-Project%2FOpenDB","html_url":"https://awesome.ecosyste.ms/projects/github.com%2FThe-OpenROAD-Project%2FOpenDB","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FThe-OpenROAD-Project%2FOpenDB/lists"}