Large difference between post-route and signoff timing despite up-to-date RC scaling factors

Dear Community

I have a design whose timing is fulfilled at the post-rouote stage. If I run

setExtractRCMode -engine postRoute -effortLevel high
timeDesign -postRoute -setup -hold

I get the following result.

+--------------------+---------+---------+---------+---------+
|     Setup mode     |   all   | reg2reg |reg2cgate| default |
+--------------------+---------+---------+---------+---------+
|           WNS (ns):|  0.000  |  0.000  | 18.512  |  0.164  |
|           TNS (ns):|  0.000  |  0.000  |  0.000  |  0.000  |
|    Violating Paths:|    0    |    0    |    0    |    0    |
|          All Paths:|  20636  |  20141  |   32    |  6271   |
+--------------------+---------+---------+---------+---------+

+--------------------+---------+---------+---------+---------+
|     Hold mode      |   all   | reg2reg |reg2cgate| default |
+--------------------+---------+---------+---------+---------+
|           WNS (ns):|  0.046  |  0.046  |  0.648  |  3.356  |
|           TNS (ns):|  0.000  |  0.000  |  0.000  |  0.000  |
|    Violating Paths:|    0    |    0    |    0    |    0    |
|          All Paths:|  20636  |  20141  |   32    |  6271   |
+--------------------+---------+---------+---------+---------+


However, If I run

timeDesign -signoff -setup -hold

I get a much worse result:

+--------------------+---------+---------+---------+---------+
|     Setup mode     |   all   | reg2reg |reg2cgate| default |
+--------------------+---------+---------+---------+---------+
|           WNS (ns):| -9.366  | -9.366  | 18.545  |  0.223  |
|           TNS (ns):| -27.222 | -27.222 |  0.000  |  0.000  |
|    Violating Paths:|   31    |   31    |    0    |    0    |
|          All Paths:|  20638  |  20143  |   32    |  6271   |
+--------------------+---------+---------+---------+---------+

+--------------------+---------+---------+---------+---------+
|     Hold mode      |   all   | reg2reg |reg2cgate| default |
+--------------------+---------+---------+---------+---------+
|           WNS (ns):|  0.002  |  0.002  |  0.644  |  3.374  |
|           TNS (ns):|  0.000  |  0.000  |  0.000  |  0.000  |
|    Violating Paths:|    0    |    0    |    0    |    0    |
|          All Paths:|  20636  |  20141  |   32    |  6271   |
+--------------------+---------+---------+---------+---------+

According to the manual, this can happen due to bad correlation between the post-route RC scaling factors and the signoff extractor. Thus, I updated the RC factors with

generateRCFactor -preroute true -reference signoff -outputFile update_preRoute_RC_scale_factors.tcl
generateRCFactor -preroute false -postroute medium -reference signoff -outputFile update_postRoute_RC_scale_factors.tcl
source update_preRoute_RC_scale_factors.tcl   # At the beginning of the flow
source update_postRoute_RC_scale_factors.tcl  # After routing

and restarted the flow, but the result is almost the same.

At the sign-off stage, only two paths have a much worse timing. The other 29 violating paths have a very small negative slack of a few ps. To further debug the proble, I compared the worst path (according to the signoff timing) to the same path with post-route timing. Here is the output of said path in the signoff stage:

Path 1: VIOLATED Data To Data Setup Check with Pin i0_nv_
mem/i0_XNVR_2KX8P2016_VW01C/HS
Endpoint:   i0_nv_mem/i0_XNVR_2KX8P2016_VW01C/MEM_ALLC     
(^) checked with  leading edge of 'clk'
Beginpoint: i0_nv_mem_ctrl/i0_nv_mem_
access/mem_allc_cs_reg/Q (^) triggered by  leading edge of 'clk'
Path Groups: {clk}
Analysis View: slow_normal_mode_vtx
Other End Arrival Time          4.133
- Data Check Setup              5.000
+ Phase Shift                   0.000
+ CPPR Adjustment               1.221
- Uncertainty                   3.000
= Required Time                -2.646
- Arrival Time                  6.720
= Slack Time                   -9.366
     Clock Rise Edge                 0.000
     + Clock Network Latency (Prop)  0.830
     = Beginpoint Arrival Time       0.830

And when I use the same command (report_timing -from <startpoint> -to <endpoint>) at the post-route stage, I get:

No constrained timing paths with given description found.
Paths may be unconstrained (try '-unconstrained' option) or may not exist.

How can that be? According to this document, above's report can happen e.g. when timing checks are disabled, the path is constrained as static, etc., none of which is the case in our design (we only constrain top-level pins, no internal pins).

1. How can it happen that a path is unconstrained at the post-route stage, but constrained in the signoff stage?

2. I noticed that the RC scaling factors are quite close to 1 and even smaller than one in most cases. Intuitively, I would expect them to be larger than one. Might there be something wrong with how I generate them? Here are the generated post-route RC scaling factors:

update_rc_corner -name RC_typ_T25 -postRoute_cap {0.924 0.953 } -postRoute_res {0.997 0.969 } -postRoute_xcap {1.050 0.964 } -postRoute_clkcap {0.799 0.893 } -postRoute_clkres {0.996 0.978 }
update_rc_corner -name RC_min_Tm40 -postRoute_cap {0.925 0.969 } -postRoute_res {0.998 0.971 } -postRoute_xcap {1.032 0.966 } -postRoute_clkcap {0.800 0.909 } -postRoute_clkres {0.997 0.980 }
update_rc_corner -name RC_max_T125 -postRoute_cap {0.929 0.954 } -postRoute_res {1.006 0.964 } -postRoute_xcap {1.029 0.964 } -postRoute_clkcap {0.798 0.891 } -postRoute_clkres {0.999 0.974 }

Thank you for any suggestions.