Description

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?

Solution

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.