To create a generic solution for the full range of permissible RM loads, boundary clock net tracks are locked after the parent implementation, and the PPLOCs of boundary clock nets are distributed to all clock regions of an RP Pblock. This acts as a physical partition between RM and static domains. However, this approach can impact RM internal clocks, especially if there is a shift with fewer boundary clock loads and increased RM internal clock demands for RMs in child configurations.
To address this challenge, you can define a bounding box for boundary clock nets using
the USER_CLOCK_EXPANSION_WINDOW property.
You can define a subset of clock regions within the RP Pblock with
USER_CLOCK_EXPANSION_WINDOW, enabling boundary clock routing to
cover only those specified in the RP. The clock tracks outside of the
USER_CLOCK_EXPANSION_WINDOW region become available for other
clocks. In the DFX flow, the USER_CLOCK_EXPANSION_WINDOW property must
be applied on boundary clock nets in the parent implementation as routing is locked in
the static design checkpoint.
The following figure shows a single RP design with the RP Pblock highlighted in blue and the BUFGCE source of a boundary clock net marked in red. The boundary clock net track highlighted in yellow is distributed to all clock regions within the RP, which is locked after the parent implementation.
When you apply USER_CLOCK_EXPANSION_WINDOW to this boundary clock net to
be contained within the range defined by the lower half of the RP Pblock, the clock
track assignment is greatly reduced. Logic using this clock is limited to placement
within this more restricted range.
set_property USER_CLOCK_EXPANSION_WINDOW
CLOCKREGION_X1Y1:CLOCKREGION_X9Y2 [get_nets clk1]