1
you can isolate which characteristics are introducing the timing violation for each path:
High logic delay percentage (Logic Delay)
- Are there many levels of logic? (Logic Levels)
- Are there any constraints or attributes that prevent logic optimization? (Don’t Touch, Mark Debug)
- Does the path include a cell with high logic delay such as RAMB or DSP?
- Is the path requirement too tight for the current path topology? (Requirement)
High net delay percentage (Net Delay)
- Are there any high fanout nets in the path? (High Fanout, Cumulative Fanout)
- Are the cells assigned to several Pblocks that can be placed far apart? (PBlocks)
- Are the cells placed far apart? (Bounding Box Size, Clock Region Distance)
- For SSI devices, are there nets crossing SLR boundaries? (SLR Crossings)
- Are one or several net delay values a lot higher than expected while the placement seems correct?
Missing pipeline register in a RAMB or DSP cell (when present in the path)
- See the Comb DSP, MREG, PREG, DOA_REGand DOA_REGvalues
High skew (<-0.5 ns for setup and >0.5 ns for hold) (Clock Skew)
- Is it a clock domain crossing path? (Start Point Clock, End Point Clock)
- Are the clocks synchronous or asynchronous? (Clock Relationship)
- Is the path crossing I/O columns? (IO Crossings)
2
The most efficient method of identifying these long paths is to run a timing report post synthesis with the routing estimates set to none. This can be done by changing the Interconnect model to none in the Timer Settings tab of the Vivado IDE Timing Report dialog box, or by using the following Tcl command in the Tcl console or shell:
set_delay_model -interconnect none
Review the timing results to identify any failing paths. If there are paths that fail to meet timing without any routing delay, these paths will be impossible to meettiming with actual routing. These paths MUST be addressed immediately. Typically, these would have to be fixed in RTL, but the violations could also be due to missing synthesis attributes, or incorrect timing constraints.
Xilinx recommends that you drive high fanout nets with a fabric register (FD*), which is easier to replicate and relocate during physical optimization. It is important to look at the list of high fanout signals post synthesis as well as postphysical optimization. The command to identify these nets is report_high_fanout_nets.