AR# 32648: 11.1 Known Issue Timing - I see Set/Reset to out paths being analyzed by default
AR# 32648
11.1 Known Issue Timing - I see Set/Reset to out paths being analyzed by default
説明
I see Set/Reset to out paths being analyzed by default. Is this the expected behavior?
Here is an example of what I see: ================================================================================ Timing constraint: TS_P2P = MAXDELAY FROM TIMEGRP "PADS" TO TIMEGRP "PADS" 20 ns;
16 paths analyzed, 16 endpoints analyzed, 0 failing endpoints 0 timing errors detected. (0 setup errors, 0 hold errors) Maximum delay is 14.859ns. -------------------------------------------------------------------------------- Slack: 5.141ns (requirement - data path) Source: reset (PAD) Destination: dataout[9] (PAD) Requirement: 20.000ns Data Path Delay: 14.859ns (Levels of Logic = 3)
Maximum Data Path: reset to dataout[9] Location Delay type Delay(ns) Physical Resource Logical Resource(s) ------------------------------------------------- ------------------- A6.I Tiopi 1.140 reset reset reset_IBUF ProtoComp1.IMUX.3 ILOGIC_X9Y60.SR net (fanout=6) 4.691 reset_IBUF ILOGIC_X9Y60.Q2 Tisco_RST 1.834 iserdes_dsb iserdes_dsb B2.O net (fanout=1) 4.224 dataout_9_OBUF B2.PAD Tioop 2.970 dataout[9] dataout_9_OBUF dataout[9] ------------------------------------------------- --------------------------- Total 14.859ns (5.944ns logic, 8.915ns route) (40.0% logic, 60.0% route)
Set/Reset to out paths are not always critical paths, and in the majority of designs they will not be critical. We are expected to be turning this analysis off by default in a later release. Currently, you will see this analysis performed by default.
To prevent this analysis, uncheck the reg_sr_o in the Path Tracing Control options. This will prevent the Set/Reset to out analysis from being performed.
This analysis is used to check clock to out times, and it is important for a design that requires Set/Reset values to propagate to a downstream device in a specified amount of time.