When it comes to floorplanning, the old adage “less is more” is fitting. A design floorplan is broadly defined as a set of physical constraints used to control how logic is placed in the die. A good floorplan can help reduce routing congestion and improve the quality of timing results (QoR) that Vivado can achieve for a given design.
Conversely, a poor floorplan can have the opposite effect. Before creating any type of floorplan, designers should consult the excellent discussion on the topic found in chapter 8 of (UG906). This blog post is offered as a supplement to the information in the user guide.
Pblock Boundaries
Pblock boundaries allow you to leverage clock regions boundaries to define the size of the pblock as opposed to using ranges of SLICEs, BRAMs, DSPs, etc. This can help limit clock skew and help with overall clock placement of the design.
Below are some examples of resizing pblocks:
create_pblock pblock_cr0
resize_pblock pblock_cr0 -add CLOCKREGION_X0Y0:CLOCKREGION_X0Y0create_pblock pblock_slr1
resize_pblock pblock_slr1 -add SLR1
Users can use clock region or SLR based floorplans, even if they want to exclude certain types of sites from the pblock.
The following Tcl command demonstrates how to resize a pblock to remove the DSP sites from the clock region pblock created in the previous example.
resize_pblock pblock_cr0 -remove [get_sites DSP* -of [get_clock_regions X0Y0]]
Pblock boundaries are soft by default, which means that Vivado can move cells outside of the pblock in later placer stages if it helps with timing closure.
In some cases, it makes sense to harden the boundary to prevent this behavior. This can be accomplished by setting the IS_SOFT property of the pblock to FALSE. This can be useful when trying to control clock placement.
set_property IS_SOFT FALSE [get_pblocks pblock_slr1]
Clocking Architecture
Clocking plays a large role in determining how a design is placed and routed.
Understanding the clocking resources available in the device family that the design is targeted toward is an essential prerequisite to floorplanning.
Issues that commonly arise include:
- Re-using outdated clocking that was optimal for a previous device family, but is not the best option for the current device family (Missing out on MBUFGCE_DIV, BUFGCE_DIV, etc…)
- Using more clocking resources than are needed when fewer would suffice
- Overlooking clock uncertainty caused by jitter
Designers should always optimize the clocking architecture of their designs. To do so, it is important to have a good understanding of all the clocks used in their designs. Here is a useful Tcl command that offers a quick shortcut to visualize all of the clocks used in a design.
show_schematic [get_cells -hierarchical -filter { PRIMITIVE_TYPE =~ CLOCK.*.* } ]
A much more detailed picture of each individual clock and the distribution of loads is available in the clock utilization report (report_clock_utilization). Reviewing the load placement of each clock can help designers see how Vivado places the logic connected to each clock. Consider the device cell placement summary for a global clock below.
Note that a small number of loads (70) have been placed in SLR1 while the clock root and driver is placed adjacent to the transceiver in the upper left corner of the die denoted with (R) and (D). Further note that the horizontal programmable delay requires 7 taps to balance the clock skew.
One floorplanning approach could be to restrict the placement of the loads of the clock with a hard pblock.
For example:
create_pblock slr2_3
resize_pblock slr2_3 -add SLR2:SLR3
set_property IS_SOFT FALSE [get_pblocks slr2_3]
add_cells_to_pblock slr2_3 [set pb_cells [all_registers -clock <clock_name> ]]
One caveat to this approach is that designers need to remember that dual port BRAMs/URAMs have two clocks. As such, the all_registers command will collect memories where the clock is connected to either of the clock inputs.
However, it is a simple matter to remove any group of objects from a pblock once they have been assigned using remove_cells_from_pblocks.
Here is an example showing how to remove the BRAMs/URAMs from the pblock above.
remove_cells_from_pblock slr2_3 [filter $pb_cells {PRIMITIVE_TYPE =~ BLOCKRAM.*.*}]
Hierarchical Floorplanning
Use KEEP_HIERARCHY on sizable modules that will be floorplanned. The KEEP_HIERARCHY attribute forces the synthesis tool to retain the logical interface and prevent cell merging with other instances.
This important guidance is often overlooked, particularly when a single module is instantiated multiple times in a loop. As a result, data and control signals are often shared between instances of the same module. This leads to difficulty when trying to physically isolate modules because they are not logically isolated.
The image below shows a single module that has been instantiated twice without the use of KEEP_HIERARCHY during synthesis. Note the high degree of interconnect between the modules which serves to pull the modules closer together during placement. Even though the two modules come from the same piece of RTL, the synthesized result is not a good fit for floorplanning because of the significant interconnect between the two.
Here is what the same two modules look like when they are logically isolated with KEEP_HIERARCHY attributes.
The result is much cleaner and the two modules can now be physically isolated with hierarchical floorplanning constraints if needed. A side benefit of using KEEP_HIERARCHY is that the placer can often physically isolate the modules without the assistance of a floorplan.
It is easy to create a hierarchical floorplan of modules in a design. The required XDC constraints (or Tcl commands) are straightforward and can be accomplished in three lines.
Here is an example of constraining a module to a single clock region.
create_pblock pblock_1
resize_pblock pblock_1 -add CLOCKREGION_X0Y0:CLOCKREGION_X0Y0
add_cells_to_pblock pblock_1 [get_cells [list module_A module_B module_C]]
Some designers prefer to use the hierarchical cell property USER_SLR_ASSIGNMENT instead of using pblocks. This approach is fine, but it is important to note that the USER_SLR_ASSIGNMENT property is designed for hierarchical cells, not for leaf level cells such as flip flops, LUTs, DSPs, etc.
Users should commit to either using SLR-based pblocks *OR* USER_SLR_ASSIGNMENT properties, but not both. Mixing the two techniques only leads to confusion.
PlatoAi. Web3 Reimagined. Data Intelligence Amplified.
Click here to access.
