Why am I getting a Hold Path violation when I used the FROM:TO:DATAPATHONLY keyword?
Timing constraint: TS_config = MAXDELAY FROM TIMEGRP "config_group" TO TIMEGRP
"HSIOS" TS_hsec_rxusrclk_out * 4 DATAPATHONLY;
For more information, see From:To (Multicycle) Analysis in the Timing Closure User Guide (UG612).
779 paths analyzed, 779 endpoints analyzed, 2 failing endpoints
2 timing errors detected. (0 setup errors, 2 hold errors)
..
Hold Paths: TS_config = MAXDELAY FROM TIMEGRP "config_group" TO TIMEGRP "HSIOS" TS_hsec_rxusrclk_out * 4 DATAPATHONLY;
--------------------------------------------------------------------------------
Paths for end point i_serdes_20l_32s_5156m_v6_hxt_wrapper/SERDES_20L_32S_5156M_V6_HXT_i/gtx15_serdes_20l_32s_5156m_v6_hxt_i/gtxe1_i (GTXE1_X1Y19.DFETAPOVRD), 1 path
--------------------------------------------------------------------------------
Slack (hold path): -0.063ns (requirement - (clock path skew + uncertainty - data path))
Source: i_hseib_core_wrapper/i_CORE/i_reg_if/proc_hsec_serdes15_configuration0_r[0] (FF)
Destination: i_serdes_20l_32s_5156m_v6_hxt_wrapper/SERDES_20L_32S_5156M_V6_HXT_i/gtx15_serdes_20l_32s_5156m_v6_hxt_i/gtxe1_i (HSIO)
Requirement: 0.000ns
Data Path Delay: -0.063ns (Levels of Logic = 0)
Positive Clock Path Skew: 0.000ns
Source Clock: proc_clk rising
Destination Clock: hsec_rx_serdes_clk<0> rising
Clock Uncertainty: 0.000ns
Minimum Data Path at Slow Process Corner: i_hseib_core_wrapper/i_CORE/i_reg_if/proc_hsec_serdes15_configuration0_r[0] to i_serdes_20l_32s_5156m_v6_hxt_wrapper/SERDES_20L_32S_5156M_V6_HXT_i/gtx15_serdes_20l_32s_5156m_v6_hxt_i/gtxe1_i
Location Delay type Delay(ns) Physical Resource
Logical Resource(s)
--------------------------------------------------- -------------------
SLICE_X169Y196.AQ Tcko 0.228 hsec_15_dfetapovrd
i_hseib_core_wrapper/i_CORE/i_reg_if/proc_hsec_serdes15_configuration0_r[0]
GTXE1_X1Y19.DFETAPOVRD net (fanout=2) 0.511 hsec_15_dfetapovrd
GTXE1_X1Y19.RXUSRCLK2 Tgtxcko_DFETAP(-Th) 0.802 i_serdes_20l_32s_5156m_v6_hxt_wrapper/SERDES_20L_32S_5156M_V6_HXT_i/gtx15_serdes_20l_32s_5156m_v6_hxt_i/gtxe1_i
i_serdes_20l_32s_5156m_v6_hxt_wrapper/SERDES_20L_32S_5156M_V6_HXT_i/gtx15_serdes_20l_32s_5156m_v6_hxt_i/gtxe1_i
--------------------------------------------------- ---------------------------
Total -0.063ns (-0.574ns logic, 0.511ns route)
(911.1% logic, -811.1% route)
Why do I receive a hold violation?
The DATAPATHONLY option on the FROM:TO constraint truncates the Clock Skew to zero. Since the data path is a negative value, which is less than zero, there is a hold violation. Although it would seem that this is not possible, in this case, we have a hold time requirement (denoted in the timing report below by a (-Th)) that is greaterthan thedata path delay. As a result, the tools are interpreting this to be a negative data path delay.
Location Delay type Delay(ns) Physical Resource
Logical Resource(s)
--------------------------------------------------- -------------------
SLICE_X169Y196.AQ Tcko 0.228 hsec_15_dfetapovrd
i_hseib_core_wrapper/i_CORE/i_reg_if/proc_hsec_serdes15_configuration0_r[0]
GTXE1_X1Y19.DFETAPOVRD net (fanout=2) 0.511 hsec_15_dfetapovrd
GTXE1_X1Y19.RXUSRCLK2 Tgtxcko_DFETAP(-Th) 0.802i_serdes_20l_32s_5156m_v6_hxt_wrapper/SERDES_20L_32S_5156M_V6_HXT_i/gtx15_serdes_20l_32s_5156m_v6_hxt_i/gtxe1_i
i_serdes_20l_32s_5156m_v6_hxt_wrapper/SERDES_20L_32S_5156M_V6_HXT_i/gtx15_serdes_20l_32s_5156m_v6_hxt_i/gtxe1_i
--------------------------------------------------- ---------------------------
Total -0.063ns (-0.574ns logic, 0.511ns route)
(911.1% logic, -811.1% route)
To work around this issue, you can either ignore the hold violation, or place this path in a FROM:TO:TIG constraint.
AR# 52190 | |
---|---|
Date | 01/24/2013 |
Status | Active |
Type | Known Issues |
Tools |