<@U01634FSETZ> <@U016HSALFAN> have you had any luc...
# openlane
@User @User have you had any luck updating openroad in openlane very recently? I've been struggling with a couple of DRC violations that I tried to reproduce directly in openroad, but it ran clean. So I went down the rabbit hole of updating the docker image and ended up here: https://github.com/The-OpenROAD-Project/OpenROAD/issues/567
@Anton Blanchard: Yes, working on a solution currently; not sure how good it is though... I have isolated the OpenDB history in a fork at https://github.com/ax3ghazy/OpenDB. Currently trying to re-build OpenPhySyn with it.
Disappointing the OpenROAD team don't seem to care about the python bindings for OpenDB. https://github.com/antonblanchard/openlane/tree/update-openroad Some pretty ugly hacking, but this gives me something to chase my DRC issues with. In the end I hacked the openroad openDB to write the older def format to avoid the openphysyn issue. I then avoided the python library build issues by backing the tree back to a commit where it worked. OpenROAD CTS has changed, and I made a guess at fixing the script. Hope you have better luck untangling the mess 🙂
🙂 1
I'm still seeing tap distance DRC issues, I thought they fixed that recently
@Anton Blanchard: There were some discussions about this issue but it hasn't yet been resolved. I'd say the safest solution is to move the macros to the right or to the left a little bit to allow for the appropriate tap insertion. you can also change the halo distance for the taps.
@Anton Blanchard: You can also work around it by reducing tapping distance. e.g.,
set ::env(FP_TAPCELL_DIST) 13
It's pretty useful to have a standalone version of OpenDB, so I think I will keep the fork above. I just need to bring in the logger, which is probably not expected to change much.