I'm encountering a huge negative slack (wns and tns) violation at the end of synthesis as reported by OpenSTA. When I checked the timing reports generated, it was clearly evident that the timing paths (max : recovery check) starting from the RST_N port caused the violations. One such example is as shown below: Startpoint: RST_N (input port clocked by vclk) Endpoint: 320257 (recovery check against rising-edge clock vclk) Path Group: async_default Path Type: max Delay Time Description --------------------------------------------------------- 0.00 0.00 clock vclk (rise edge) 0.00 0.00 clock network delay (ideal) 6.00 6.00 ^ input external delay 19.26 25.26 ^ RST_N (in) 0.00 25.26 ^ _320257_/RESET_B (sky130_fd_sc_hd__dfrtp_4) 25.26 data arrival time 12.00 12.00 clock vclk (rise edge) 0.00 12.00 clock network delay (ideal) 0.00 12.00 clock reconvergence pessimism 12.00 ^ _320257_/CLK (sky130_fd_sc_hd__dfrtp_4) -10.71 1.29 library recovery time 1.29 data required time --------------------------------------------------------- 1.29 data required time -25.26 data arrival time --------------------------------------------------------- -23.97 slack (VIOLATED) One possible way to fix the issue is by increasing the period of 'vclk'. I would like to know whether this is legal or should the period of vclk be fixed? Correct me if I'm wrong.

Well, by setting CLOCK_PERIOD, you control the "vclk" period at which the STA is done; nothing illegal with that.

@Ahmed Ghazy But the 'vclk' period is set to 12ns by default in the base.sdc file. It seems to be independent of the ::env(CLOCK_PERIOD) set in the config.tcl file. Should I change the base.sdc file such that 'vclk' period equals the CLOCK_PERIOD?

Oh, I see; this was fixed in the develop branch, so either update to develop or use this base.sdc from it https://github.com/efabless/openlane/blob/develop/scripts/base.sdc.

Thanks @Ahmed Ghazy. I'll update the file accordingly.