@Matt Liberty @Austin Rovinski who is the contact person as for the OpenDB development. There exists an idea to use a double approach in the analog flow proposed by IHP to have the data exchange not only based on tool specific format (mainly ascii) but also using a database. OpenDB seems to be a good choice for handling layout specific data but we do not know how it would perform interoperating with other tools.

It's not strongly recommended to use the OpenDB format outside of OpenROAD because it updates fairly frequently and wouldn't lead to good compatibility. I don't know of any other tools that used OpenDB outside of OpenROAD. DEF is usually preferable because it is stable and captures most of the information you would want to store. But generally the contact for ODB would be @Matt Liberty.

We could discuss such a flow but odb is mostly DEF orientated and may not meet the needs for analog. That said there is a GSoC contributor working towards GDS support in odb (whether it comes to completion is always uncertain with GSoC)

@Matt Liberty thank you for the feedback. Finally the major issue is if OpenDB would be a good candidate to extend it and workout interfaces with othher tools such as xschem, Qucs-S, ngspice, xyce, OpenEMS according to our proposed flow.

On a technical level I think it is possible to extend OpenDB for schematics and spice netlist (not sure what OpenEMS requires). We don't currently distribute OpenDB by itself but that is possible. OpenAccess is an existence proof for such a db. What other options are you exploring? I guess klayout is another alternative. There would need to be some discussion on the business side about the development cost and on-going overhead to ensure compatibility across changes. A governance model might be needed too. If you are interested to go further we should setup a time to discuss.