Intel® Quartus® Prime Pro Edition User Guide: Partial Reconfiguration

ID 683834
Date 8/26/2022
Public

A newer version of this document is available. Customers should click here to go to the newest version.

Document Table of Contents

2.6.3. Step 3: Floorplan the Design

Use Logic Lock floorplan constraints in your PR design to physically partition the device. Each PR partition in your design must have a corresponding, exclusive physical partition.
You create Logic Lock regions to define the physical partition for your PR region. This partitioning ensures that the resources available to the PR region are the same for any persona that you implement.
PR Region Floorplan

Your PR region must include only core logic, such as LABs, RAMs, ROMs, and DSPs in a PR region. Intel® Agilex™ and Intel® Stratix® 10 designs can also include Hyper-Registers in the PR partition. Instantiate all periphery design elements, such as transceivers, external memory interfaces, and clock networks in the static region of the design. The Logic Lock regions you create can cross periphery locations, such as the I/O columns and the HPS, because the constraint is core-only.

There are two region types:
  • Place regions—use these regions to constrain logic to a specific area of the device. The Fitter places the logic in the region you specify. The Fitter can also place other logic in the region unless you designate the region as Reserved.
  • Route regions—use these regions to constrain routing to a specific area. The routing region must fully enclose the placement region. Additionally, the routing regions for the PR regions cannot overlap.
Figure 8. Floorplanning your PR Design

Follow these guidelines when floorplanning your PR design:

  • Complete the periphery and clock floorplan before core floorplanning. You can use Interface Planner (Tools > Interface Planner) to create periphery floorplan assignments for your design.
  • Define a routing region that is at least 1 unit larger than the placement region in all directions. In defining this region, avoid any overlapping routing regions between the static and PR regions.
  • Do not overlap the routing regions of multiple PR regions.
  • Select the PR region row-wise for least bitstream overhead. In Intel® Arria® 10 and Intel® Cyclone® 10 GX devices, short, wider regions generate smaller bitstreams than tall, narrower regions. Intel® Agilex™ and Intel® Stratix® 10 configuration occurs on sectors. For the least bitstream overhead, ensure that you align the PR region to sector boundaries. Refer to "Analyzing and Optimizing the Design Floorplan," in Intel® Quartus® Prime Pro Edition User Guide: Design Optimization.
  • For Intel® Arria® 10 and Intel® Cyclone® 10 GX devices, the height of your PR region affects the reconfiguration time. A PR region larger in the Y direction takes longer to reconfigure. This condition does not apply to Intel® Agilex™ or Intel® Stratix® 10 devices because they configure according to sectors. The reconfiguration time of Intel® Agilex™ and Intel® Stratix® 10 devices depends on the number of sectors the PR region covers. This reconfiguration time can also be affected by other factors, such as interleaving or the presence of other Logic Lock regions.
  • To reduce programming files size for Intel® Agilex™ and Intel® Stratix® 10 devices, target only the necessary number of sectors for PR. Also, ensure that the routing region of your PR region is 1 block (1 LAB row/column) inset from the edges of the clock sector boundaries.
  • Define sub Logic Lock regions within PR regions to improve timing closure.
  • If your design includes HPR parent and child partitions, the placement region of the parent region must fully enclose the routing and placement region of its child region. Also, the parent wire LUTs must be in an area outside the child PR region. This requirement is because the child PR region is exclusive to all other logic, which includes the parent and the static region.
  • The base revision .qdb provides the only effective pin assignments for the implementation revision. Even if you subsequently change the pin assignments to the implementation revisions, those changes do not take effect.