AMD highly recommends contiguous floorplanning for static regions and reconfigurable Pblocks for many reasons, including the following:
- Disjoint Pblocks for either a reconfigurable partition or the static region can result in related logic being placed in separate areas, which will have a negative impact on routability and timing closure. Without additional guidance, it is possible for the placer to create a situation that is unroutable if related logic is not kept together.
- Although static nets can cross through reconfigurable Pblocks to allow communication between two static islands, it is best to limit this approach, because locked static nets can block routing during subsequent reconfigurable module implementations. Building contiguous regions and minimizing overlap is the best layout strategy for DFX designs.
The Vivado tools determine that two
portions of a Pblock are disjoint if the corresponding expanded routing footprint for a
collection of resources has a gap between it and another routing footprint section for
the same Pblock. The reconfigurable Pblock does not own general routing resources within
this gap. This means that finding a solution that connects these disjoint sections is
either difficult or impossible, depending on how the Pblock is created. Use hd_visual scripts (e.g., <pblock>_Routing_AllTiles.tcl) to see the routing footprint of a
reconfigurable partition Pblock.
There are some cases in which contiguous Pblocks cannot be used, and disjoint Pblocks must be used instead. The most common case is to accommodate clocking resources in Versal devices due to the layout of the silicon. Clocking resources such as BUFGCE, MMCM, DPLL and XPLL are located along the bottom (or sides) of the device and therefore are physically separated from a dynamic region that must be placed on a different area of the die. If a reconfigurable partition must contain clocking resources and be situated in the device in a location away from the bottom (or sides) of the device, the Pblock for the reconfigurable partition must have two or more disjoint sections. The only routing permitted between the disjoint sections is clock routing, because these resources are not part of the general routing domain. The following figure shows an example:
Following is the constraint syntax for the Pblock in this example:
create_pblock pblock_rp1rm1
add_cells_to_pblock [get_pblocks pblock_rp1rm1] [get_cells -quiet [list design_1_i/rp1rm1]]
resize_pblock [get_pblocks pblock_rp1rm1] -add {CLOCKREGION_X5Y2:CLOCKREGION_X6Y3}
resize_pblock [get_pblocks pblock_rp1rm1] -add {BUFGCE_X0Y0:BUFGCE_X0Y23}
resize_pblock [get_pblocks pblock_rp1rm1] -add {MMCM_X0Y0:MMCM_X0Y0}
The BUFGCE and MMCM instances selected are located in the lower-left corner of the device. Only the reconfigurable partitions with areas that occupy the Y1 row of the device are able to have a contiguous region that includes these clocking resources.
If design rule checks (e.g., HDPR-131 or HDPR-132) indicate that resources such as SLICEs near the clocking site are also required, add these to your primary Pblock. If the required sites are currently occupied by a different reconfigurable partition Pblock, the listed sites must also be removed from that Pblock before adding them to the target Pblock. The DRC messages provide the syntax required. For example:
WARNING: [DRC HDPR-131] DFX pblock blocks MMCM: MMCM tile 'CMT_MMCM_X47Y0' from reconfigurable pblock 'pblock_rp1rm1' requires BLI tiles and its respective frame and PU tiles which are already ranged in by other reconfigurable pblock 'pblock_rp2rm1'. There are two possible resolutions - a) Use other MMCM that will not create overlaps or b) Update the floorplan by using this suggestion:
resize_pblock pblock_rp1rm1 -add {SLICE_X148Y0:SLICE_X151Y43}
resize_pblock pblock_rp2rm1 -remove {BLI_A_GRP0_X64Y0:BLI_A_GRP0_X65Y0 ... SLICE_X148Y0:SLICE_X151Y43}