@Matt Liberty Is there are issue around Hold fix algorithm?, I see couple of DELAY element is path with setup violation . First path violated by 1ns and i see around 4 DELAY element in the path 0.23 0.25 3.36 ^ mprj/u_riscv_top.i_core_top_0/_28161_/X (sky130_fd_sc_hd__dlymetal6s2s_1) 0.14 0.25 4.19 v mprj/u_riscv_top.i_core_top_0/_28284_/X (sky130_fd_sc_hd__dlymetal6s2s_1) 0.13 0.26 4.45 v mprj/u_riscv_top.i_core_top_0/_28427_/X (sky130_fd_sc_hd__dlymetal6s2s_1) 0.24 0.28 11.24 ^ mprj/u_riscv_top.i_core_top_0/_29003_/X (sky130_fd_sc_hd__dlymetal6s2s_1)

I'm not sure if a hold time fixing algorithm would work on such a long path. Besides that, it's a max path report, right ? I see in MY designs runs, that buffer chains are converted to delay cells, which are usually faster than the buffer chains they replace. (But since I want the delays, I remove delay cells from the library). May I ask a question. Just out of curiosity, the interesting part for me is, do you have buffer chains in the post synthesis file, and if so, where are they coming from (the default tool yosys ?) ?

Previous Openlane/OpenRoad version, this block does not had any timing violation (Also recently I have not changed any logic in this block). When I change these delay cell with buf using OpenSta <replace_cell> I see these path timing are meting. I see this is a issue in Hold Fix algorithm to correctly identify the location to fix hold violation without disturbing setup path.

I haven't checked where hold time fixing is done in the flow (would be intersting to know) and I'm not familiar with "replace_cell". But I see the delay cells you are refering to are in the middle of nowhere in the logic path, and I thought it is more related to a buffer-chain to delay cell conversion than with a hold time fixing issue. It was just a thought. Interesting that yosys inserts these buffer chains (or delay cells) anyway. Cheers.

My understanding following env impact the design/timing optimization set ::env(GLB_RESIZER_TIMING_OPTIMIZATIONS) {1} set ::env(PL_RESIZER_TIMING_OPTIMIZATIONS) {1} set ::env(PL_RESIZER_DESIGN_OPTIMIZATIONS) {1}

I'm not sure if the current (or older) flow inserts buffers or delays to slow down paths, which would be a way to fix hold time issues. Nor does it down-sizing gates to make paths slower. (I also guess it does not modifiy the logic cone by changing gate logic.) I think the flow only does resizing (and as a special feature replaces buffer chains with delay cells), but this is done to make paths faster, which is not what you want, when you try to fix hold time issues. IMHO hold time is handled by optimizing clock skew during clock tree insertion. But I could also be totally wrong on this. Maybe s.o. with knowledge of that matter should reply. I was just wondering where the (suspected) buffer chains are coming from and why yosys would implement them. It would be intersting to cross-check the post-synthesis netlist.

In Post Synthesis these instance are buffer cells

Repair_hold will insert buffers and should try to avoid making setup worse. It would be best to provide a test case in a GH issue