ODB backwards compatibility limits

[maliberty]

Currently odb tries to be infinitely backwards compatible. It leads to complexity in the db loading code to maintain such. I propose a sliding window of one year backwards compatibility. As the tool is OSS, any old versions can be built as needed if a older db needs to be migrated in steps.

Currently this would imply removing all versions from before db_schema_update_db_power_switch

I'd like community input on this idea and duration. @gadfort @QuantamHD @rovinski @oharboe @donn or anyone else.

[oharboe]

I would be happy to trade backwards compatibility for eased maintenance burden. I cant think of relevant problems older than two months.

Could we make sure windows are overlapping and documented?

That way it is possible to convert old .odb by compiling oldest supporting version and load+save .odb from its supported version window to the next.

Though: I would forego this if it cant be automated. Perhaps keep oldest supported version in a separate file and document a git query that lists this information or a git blame with some grepping.

[donn]

For our part, we do not assume that Odb is backwards compatible at all. So yeah, we don't mind.

[oharboe]

The use case I can think of is limited to github issues reproduction archives.

We have not used or thought about using backwards comaptibility in production.

[donn]

For our part we always store our test cases as DEF/LEF, Guides, Segments, etc and generate the Odb ad-hoc

[QuantamHD]

I would say I'm strongly on the side of backwards compatibility. I think that we should try to push that window as long as possible. My kind of view of the situation is that we're trading a small amount of annoyance for us as devs, and multiplying it times the number of users who need to deal with it if we remove it. In general I feel OpenROAD should optimize for its ease of use and UX.

If we feel like the maintenance burden is too high we might consider moving to a more stable on disk format instead of just removing backwards compatibility.

That said I think 1-2 years (pushing much closer to two years) is probably long enough as long as there's sufficient documentation about how to get an odb to the latest version.

[QuantamHD]

I think that's inline with my suggestion that if gets hard to maintain the manual binary format pick something like captn proto or sqlite as an on disk format. Which obviates the need for any user level code for new new fields unless they need to be migrated from old fields.

In general this problem has been solved in the web world by database migrations. https://guides.rubyonrails.org/active_record_migrations.html

[gadfort]

I would side with preserving backwards compatibility for as long as possible. Usually for tapeouts it is rare that we need to look at the database after 1.5 - 2 years, but below 1.5 years it's likely that we would want to be able to view the file (preferably without having to go back and recompile the openroad to do so).

The text formats are great for tool compatibility, but there is a lot of meta data that the database can hold on to that there isn't a place in DEF or LEF or verilog for.

[oharboe]

What about CI?

Isn't something minimal needed to claim supported backwards compatibility?

[gadfort]

We have this: https://github.com/The-OpenROAD-Project/OpenROAD/blob/master/src/odb/test/read_db.tcl it attempts to read a database from 3 years ago
I think there are improvements we could make to the testing to ensure various dbs are tried and they have all their data populated.

[oharboe]

This does not instill me with great confidence beyond browsing for non-critical stuff. I would "trust but verify"....

Depending on what is needed, I think this is anything from perfectly adequate to insufficient.

[rovinski]

On the fence here. I don't consider odb to be a durable format - that is left to LEF/DEF/v.

Although, I will say that for prior tapeouts using proprietary tools, we do keep chip designs around for a long time, and in order to open up the files I have to use the version of the tools that generated it in the first place, or at least around the same time period, because there is no guarantees on how long the db will last before being deprecated. Which is annoying. There is likely some kind of internal db versioning which isn't exposed to the user.

It would be nice to have some kind of defined obsolescence mechanism in OR. Right now, things more or less 1) get removed right away or 2) get marked as deprecated and then sit around until someone notices and then removes it. It would be great to have a specific date when support will be removed and to have that semi or fully automatically removed.

If support for old odb versions are removed, it would be nice to 1) have a strict maintenance period and have support removed promptly, 2) inform users if their odb version is old and when support will be removed, 3) if the support has already been removed, inform users of the last OR version that supports it.

As @oharboe says, it would be extremely useful to have this upgrading phase automated if possible. And I agree with @QuantamHD that unless things start becoming overly complicated to maintain compatibility, why not just maintain support. It seems like most of the support is just wrapping the reading and writing in if statements, but I could be wrong on that.

[maliberty]

I summarize this as no strong consensus in the community (don't care; 1.5 yrs; 2 months, etc). To @QuantamHD I've considered using sqlite as the on-disk format (not the runtime model for performance reasons). Schema migrations would be a bit more natural as we wouldn't be locked into the exact byte order. I think that transition itself would be painful to make backwards compatible.

For schema migrations I like the idea in https://david.rothlis.net/declarative-schema-migration-for-sqlite/ (converted to c++ and possibly needing to handle data migrations occasionally).

[oharboe]

I care strongly about load/save performance and compressed (not disk) size. I am skeptical when I hear sqlite.