Still with the OpenDB topic :slightly_smiling_face...
# openroad
d
Still with the OpenDB topic 🙂 is there a tool that can dump and enumerate the entire contents of all data inside OpenDB into another representation (json/XML/yaml/zip-of-such-files/similar-interop-file-formats) and then potentially rebuild an OpenDB from that alternative representation (to prove the process is reversible and complete) ? If not any recommendations on how to start this mission, is it best to study the C++ APIs first and existing OL output, I will probably look to add an additional SWIG language binding (I already have it tying to build just is mission to understand all the C++ types and resolve the handling, the approach there will start by cutting down the API subset implemented) Any use at looking to build a WASM binding while on that journey ? I notice the original OpenAPI github is archived, is the current form embedded inside OpenROAD now ? maybe it can still be lifted and built as regular library/DSO in isolation ?
a
I believe the odb format can be almost completely decomposed into the LEF, DEF, and route guide files. There may be just a few structures not captured in those, but I think they can usually be reconstructed. Look into the
write_lef
write_def
and
write_guides
commands. LEF/DEF are industry standard formats which can be read by any EDA implementation tool. The guide format is not industry standard, mostly because there is no real standard. It is derived from the format used in one of the ISPD design contests. It would be difficult to use that with any tool other than OpenROAD. The process is reversible by using the
read_lef
read_def
and
read_guides
commands. OpenROAD uses the Si2 LEF/DEF parser although with a few bug fixes. If you are looking to make a completely separate interoperable application, you could use the Si2 parser or create your own to parse the LEF/DEF format. I'd recommend neither because it'd be a massive time consumption; it's much easier to simply build the application into OpenROAD. There is some documentation on how to do that in the docs, although it's hard to keep up-to-date.
The OpenDB repository is archived because the code has been completely assimilated into OpenROAD, located at
OpenROAD/src/odb
. At some point it stopped making sense to have ODB as a separate git submodule because it was too heavily integrated, so the code was merged and the repo was archived. In general, this is true for any OpenROAD Project repository which has been archived.