- Architectural Boundary Crossings
- The IO Crossings and SLR Crossings identify whether the path is crossing
architectural resources such as IO Columns or SLR boundaries.
The crossing of many architectural columns does not always represent a problem. Check for high net delay or large skew in conjunction with the crossing of many architectural columns. If many architectural column crossings appear to be the cause of timing issues across multiple implementation runs for a particular module, consider minimal floorplanning using Pblocks to reduce the crossings of the architectural column(s) or SLR boundary.
- Path Placement Restrictions: Pblocks
- Excessive floorplanning can sometimes prevent the tool from achieving the
optimal results. Paths that cross multiple Pblocks can sometimes experience
- If the path crosses multiple Pblocks, examine the location of the Pblocks and the impact on the timing path placement.
- If the Pblocks are adjacent, consider creating a single Pblock that is a super-set of each individual Pblock. This could potentially improve timing by being less restrictive on the placer.
If physical requirements dictate that the Pblocks are placed far apart, consider pipelining between the Pblocks to help meet timing requirements.
- Placement Box: Bounding Box Size, Clock Region Distance, Combined LUT Pairs
- If the Bounding Box Size or Clock Region Distance of the timing path is too
large, try using directives in
place_design. In UltraScale devices, be especially aware of the Clock Region Distance and its possible impact on timing path Clock Skew.
- Net Fanout and Detour
- High Fanout shows the highest fanout of all nets in the
datapath, and Cumulative Fanout corresponds to the sum of all datapath
If High Fanout and Cumulative Fanout are large, the timing violations are very likely due to the fanout impact on routing and net delay.
If physical optimization was run and did not reduce the fanout, check for
DONT_TOUCHconstraints preventing replication.
If replication is desired on the net prior to implementation, you can use the
MAX_FANOUTconstraint in synthesis, either inside the RTL or in an XDC file. Due to reliance on placement for good timing for high fanout nets, it is usually not recommended to have synthesis perform replication and it is best to rely on post-placement physical optimization (
phys_opt_design) for replication. You can also increase the physical optimization effort to also optimize paths with a small positive slack by using different directives such as
If fanout reduction is desired on a specific net during implementation, you can force the replication using the command:
phys_opt_design -force_replication_on_nets <netName>
- When the Hold Fix Detour is asserted, the routing on the
datapath is delayed to meet the path hold time requirement. If the path
is failing setup, check for excessive skew between the source and
destination clocks. Check also for proper timing constraints between the
source and destination clocks in case the hold path requirement is
positive (it should be zero or negative in most common cases).Note: The
HOLD_DETOURattribute is set during specific hold fixing stages in the router. Other phases might have an impact on hold timing but the property will not be set; for example, if there is a routing detour due to congestion.
- High Fanout shows the highest fanout of all nets in the datapath, and Cumulative Fanout corresponds to the sum of all datapath net fanouts.