Architectural Boundary Crossings
Architectures are organized into super logic regions (SLRs), and each SLR contains vertical columns of fabric resources such as logic, BRAMs, DSPs, and other features. When a datapath net crosses from one SLR to another, the design incurs a timing penalty. The SLR crossing value in the report indicates how many SLR boundaries the net crosses.
In addition to SLRs, a datapath net might cross non-slice columns. These crossings also add delay to the path and can contribute to routing detours, especially in congested regions. You can identify these crossings using property fields such as:
- I/O Crossings
- RAM Crossings
- DSP Crossings
- NOC Crossings
- CONFIG Crossings
- OTHER Crossings
Each value shows how many columns of that type the path crosses. While crossing architectural columns does not always cause timing issues, check for high net delay or large skew in combination with these crossings. If a particular module repeatedly shows timing violations across multiple runs and includes many column crossings, consider using minimal floorplanning with Pblocks to reduce the number of crossings or to localize the logic within one SLR.
Path Placement Restrictions: Pblocks
Excessive floorplanning with Pblocks can also create timing problems. When a timing path crosses multiple Pblocks, review their locations and assess whether the floorplan is limiting placement flexibility. If the Pblocks are adjacent, try combining them into one larger Pblock to reduce placement restrictions. If physical separation is required between the Pblocks, consider pipelining between them to improve timing.
Placement Box: Bounding Box Size, Clock Region Distance, Combined LUT Pairs
The bounding box size and clock region distance of a timing path also affect timing.
If either metric is too large, try applying additional directives in the
place_design step. In UltraScale devices, clock
region distance has a greater impact and can contribute to increased clock skew.
Net Fanout and Detour
The report shows both High Fanout and Cumulative Fanout values. High fanout typically leads to routing delays and can explain setup failures. If physical optimization does not reduce fanout, check whether MARK_DEBUG or DONT_TOUCH constraints are blocking replication.
If you want to apply replication before implementation, you can use the
MAX_FANOUT constraint in synthesis. Add this constraint in your
RTL or in the XDC file. However, synthesis replication is not always effective for
high-fanout nets because the placement has a strong influence on timing. Instead,
rely on physical optimization after placement. To increase effort during
implementation, use directives such as Explore, AggressiveExplore, or
AggressiveFanoutOpt.
phys_opt_design -force_replication_on_nets <netName>