Expansion of CONTAIN_ROUTING Area - 2025.1 English - UG909

The contained routing requirement of RP Pblocks for UltraScale and UltraScale+ devices has been relaxed to allow for improved routing and timing results. Instead of routing being confined strictly to the resources owned by the Pblock, the routing footprint is expanded. This includes resources that are within the Pblock boundary, but not necessarily owned by the Pblock, as well as resources beyond the Pblock rectangle. This means there might be RM nets and partition pins outside of the Pblock boundary. However, any partition pin or contained net is still within the expanded routing footprint.

The expanded routing footprint can be visualized by using the get_dfx_footprint Tcl utility. To see the expanded routing footprint, use this utility from the Tcl Console after opening a post-synthesis configuration or a fully routed design. This selects all tiles available to the router, and then selected tiles can be highlighted or marked as desired. In the following figure, the user-defined Pblock that bounds placement is shown in blue, and the expanded routing zone is shown in yellow. Highlight the routing footprint first, followed by placement, as the routing footprint will always be larger.

highlight_objects -color yellow [get_dfx_footprint -route -of_objects [get_cells <rm_inst>]]
highlight_objects -color blue [get_dfx_footprint -placee -of_objects [get_cells <rm_inst>]]

Figure 1. Highlighted Pblock and Expanded Routing Footprint

Any frames that are used by the RM must be contained with the partial bit files, so one effect of expanding the routing footprint is larger partial bit files. The increase in size depends on the original Pblock size and shape. Pblocks that are already rectangular can still expand. However, the expansion cannot go beyond a clock region boundary in the vertical direction; it can extend into a new clock region to the left or right. It may help the routability of the RP if the Pblock boundaries stop short of internal clock region edges, especially in the vertical direction. Pblock edges that align to the device edges, such as left or bottom edges, should not be pulled in just to allow for expanded routing. This causes placement issues if the static region now has access to small pockets of resources along the edges. AMD recommends keeping this routing expansion enabled, but if the partial bitstream size is more critical than the performance of the design, then this feature can be disabled by setting the following parameter:

set_param hd.routingContainmentAreaExpansion false

In Vivado, the algorithms that determine the device and design resources included in the expanded routing region have been updated. The expansion region is now slightly smaller than in prior tool versions, resulting in smaller partial bitstreams with minimal impact on design routability. These changes are necessary to support the Abstract Shell feature for UltraScale+ targets.

For DFX designs brought into Vivado for the purpose of generating new partial bitstreams, the original routing expansion is maintained to preserve bitstream compatibility. In other words, if the parent configuration (the run that establishes the static design results) was implemented in an earlier version of Vivado and is not reimplemented in the current version, the partial bitstreams for all new RMs continue to use the older style routing expansion, ensuring compatibility with existing deployed static platforms.

All designs that are new in the current version of Vivado or whose static designs are reimplemented in this release use the new routing expansion solution. No user intervention is required beyond simply implementing the static design through place and route. According to DFX methodology rules, all child configurations used to create results for the remaining RMs must also be implemented, maintaining compatibility for all partial bitstreams.