Expansion of CONTAIN_ROUTING Area - 2024.2 English - UG909

Vivado Design Suite User Guide: Dynamic Function eXchange (UG909)

Document ID
UG909
Release Date
2024-12-13
Version
2024.2 English

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
Important: The expanded routing footprint is not supported for 7 series devices. The get_dfx_footprint utility is also not supported for 7 series devices.

In Vivado 2020.2, the algorithms that determine the device and design resources included in the expanded routing region were updated. The expansion region is now a bit smaller than in prior tool versions, producing smaller partial bitstreams with minimal impact on design routability. The changes made were required to support the Abstract Shell feature for UltraScale+ targets.

For DFX designs that are brought into Vivado 2020.2 for the purpose of generating only new partial bitstreams, the original routing expansion are maintained, to preserve bitstream compatibility. In other words, if the parent configuration (the run that establishes the static design results) was implemented in Vivado 2020.1 or older and are not reimplemented in Vivado 2020.2, the partial bitstreams for all new RMs continue to use the older style routing expansion so these new partial bitstreams are compatible with existing deployed static platforms.

All designs that are new in Vivado 2020.2 or whose static design were reimplemented in 2020.2 use the new routing expansion solution. No user intervention is required beyond simply implementing the static design through place and route. Per DFX methodology rules, all child configurations to create results for all remaining RMs must also be implemented. Therefore, all partial bitstreams remain compatible.

Important: The use of Abstract Shell requires the enhanced expanded routing footprint. All DFX designs that intend to use this feature must be implemented in Vivado 2020.2, the first production release for Abstract Shell, to ensure the abstract shells are generated correctly. You cannot generate abstract shells from pre-2020.2 design checkpoints.