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 sourcing one of the hd_visual Tcl scripts. These are scripts that are generated automatically during the Dynamic Function eXchange flow, and can be found in the ./hd_visual subdirectory within the current working directory. The visualization script that shows the expanded routing footprint is named ./hd_visual/<pblock_name>_Routing_AllTiles.tcl. The expanded routing footprint is actually determined during routing, so this file is not be available until route_design completes. To see the expanded routing footprint, source this file from the Tcl Console after opening a routed design. This selects all tiles available to the router, and then selected tiles can be highlighted or marked as desired. In the figure below, the user-defined Pblock that bounds placement is shown in blue, and the expanded routing zone is shown in yellow.
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 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 will be 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 will not be reimplemented in Vivado 2020.2, the partial bitstreams for all new RMs will continue to use the older style routing expansion so these new partial bitstreams will be compatible with existing deployed static platforms.
All designs that are new in Vivado 2020.2 or whose static design will be reimplemented in 2020.2 will 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 will remain compatible.