@User How is the openroad update going? Worth trying? I have a couple of things that fail with the older version of openroad but look to be fixed upstream

@Anton Blanchard: I just pushed a working version to https://github.com/efabless/openlane/tree/openroad_update, but @Ahmed Ghazy managed to get it working, so perhaps give it a try! (it's still running the CI tho). The dockerhub image name is:

efabless/openlane:openroad_update

Excellent, will give it a go

@Anton Blanchard: with more experiments I found that this change is need in open_pdks https://github.com/RTimothyEdwards/open_pdks/pull/111 along with the recent commit made to openroad_update https://github.com/efabless/openlane/commit/c27c193cff7f4e22468b273ce3d850bbfd5495e4 Please, let us know if you find any issues with that branch, aside from openphysyn not working. :--)

I tried a few of my macros, and then one or two of the openlane test cases, and each time I fali around:

[ERROR DRT-0073] no ap for _35211_/S0
terminate called after throwing an instance of 'std::runtime_error'
  what():  DRT-0073
[ERROR]: during executing: "openroad -exit /openLANE_flow/scripts/openroad/or_droute.tcl |& tee >&@stdout /openLANE_flow/designs/aes/runs/18-02_05-29/logs/routing/21-tritonRoute.log"

@Anton Blanchard: I can confirm seeing this, when resizer decided to put back the

sky130_fd_sc_hd__mux4_4

:--) Solution is to add that to the drc_exclude.cells list for all libraries (for now). I will submit that as a PR to open_pdks, but I'm running a full regression run on all openlane designs to confirm that this is the only cell that has this issue first.

Oh great! Let me retest with it excluded

@Anton Blanchard: Is that cell hand instantiated or is it inserted by the tools? I ran a full regression run and only one design failed because of

sky130_fd_sc_hd_fa_4

, I'm not sure I've seen

sky130_fd_sc_hd__dlclkp_2

get used before, so maybe that's why I haven't seen that issue. But, I think we can stay on the safe side and exclude both, or do you think it should be a design by design basis?

It's hand instantiated, so not a lot we can do about it. Any ideas for the failure? I'm not seeing it using the openroad flow, but there are other issues I'm chasing there

I think the issue is mainly because of the pin access strategies used in TritonRoute, perhaps opening an issue at openroad would get this solved eventually.

I created an openroad issue: https://github.com/The-OpenROAD-Project/OpenROAD/issues/580

@Anton Blanchard: It seems TritonRoute just keeps trying to connect to the li1 pins but failing due to the mcon shapes above it. It doesn't seem to consider connecting to the met1 shapes. I would moving the met1 PORT to the front and see if TritonRoute considers it, or even removing the li and mcon ports completely.