Implementation Design Flow - 2021.2 English

The steps in this lab are managed by a set of Tcl scripts that walk through the commands used to implement each configuration of the Nested DFX design. Examine each script before running to see what each does. Most commands (link_design, route_design, pr_verify, write_bitstream, etc.) will look familiar, and others (pr_subdivide, pr_recombine) are new. The key detail is the order in which they are run, as later scripts are dependent on earlier ones.

After scripts have completed, open checkpoints (for example top_route_design.dcp or top_count_up_up_route_design.dcp) to examine the results, noting the implications of the DFX attributes and commands used to create them.

The first implementation design run establishes the static design and the first-order Reconfigurable Partition. At this point, the flow is no different than a standard DFX design flow – “inst_RP” is the lone RP in the design, and the shifter modules that reside below that level are implemented with the rest of the inst_RP logic. Second-order Reconfigurable Partitions do not exist yet.

1. Implement the parent configuration by sourcing its run script:

   source implement_parent_config.tcl -notrace

   The resulting checkpoint (top_route_design.dcp) is a full design image with the single RP. No additional DFX steps such as carving the RP into a black box or locking the static design have been done at this point. This checkpoint will only be used to establish the locked static design image which is common to all design iterations that follow.

   Figure 1. First-Order Implementation
   
   
   Open top_route_design.dcp that has been written to the Implement/top_static folder to see that this is a standard DFX design. inst_RP has the HD.RECONFIGURABLE property and an associated pblock for the Reconfigurable Partition.

   Figure 2. inst_RP is the Only Reconfigurable Partition After the First-Order Implementation
   
   
2. Create the second-order Reconfigurable Partitions by sourcing this script:

   source subdivide_shifters.tcl

   This script subdivides the inst_rp module into second-order Reconfigurable Partitions. The pr_subdivide command removes the HD.RECONFIGURABLE property from inst_RP and applies it to both inst_shift_upper and inst_shift_lower. inst_RP is then tagged with the HD.RECONFIGURABLE_CONTAINER property, noting that it was once an RP. This can be seen by examining the top_static_shifters.dcp checkpoint.

   Figure 3. Design After pr_subdivide for Shifter Functions
   
   
   Figure 4. inst_RP with the HD.RECONFIGURABLE_CONTAINER Property
   
   
3. Implement the shifter submodules in second order Reconfigurable Partitions.

   source implement_sub_shifters.tcl -notrace

   This walks through two implementation flows to place and route shift_right and shift_left functions in the second-order RPs. The commands used here are identical to a standard DFX flow with one difference: The starting point of the first configuration includes the locked top-level static design. Implementation treats the logical design in the inst_RP level (reconfig_shifters) as static; this is the level of hierarchy that is locked by the lock_design -level routing command after the first configuration completes.

   Figure 5. Two Second-Order Runs Implementing shift_right and then shift_left in the Two RPs
   
   

   This script finishes with a call to pr_recombine to create a routed design checkpoint of the shift_right-shift_right combination, moving the HD.RECONFIGURABLE property back to the inst_RP level. Examining the hierarchy of top_shift_right_right_recombined.dcp you can see this property has returned to the inst_RP instance.

   Figure 6. Design Hierarchy and Properties of the Recombined Shifter Configuration
   
   
4. Create another set of second-order Reconfigurable Partitions sourcing this script:

   source subdivide_counters.tcl

   Just like the first subdivide script, this starts with the initial configuration (top_route_design.dcp) and subdivides the inst_RP level, but this time into two counter functions. The top-level static for this design version is identical to the version used for the shifters.

   Figure 7. Design After pr_subdivide for Counter Functions
   
   
5. Implement the counter submodules in second order Reconfigurable Partitions.

   source implement_sub_counters.tcl -notrace

   Again, like with the shifters path, a standard DFX flow is used to process two counter modules (count_up, count_down) in each second-order Reconfigurable Partition. Also like the shifters, a recombined design checkpoint is created from the first pass through the second-order flow.

   Note that the two second-order implementation scripts (as well as the subdivide scripts that precede them) can be run in parallel in two unique Vivado sessions. Both rely on the same locked top static design but are unique from the inst_RP level on down. This version has slightly different floorplans for the second-order RPs, but could also vary in number.

   Figure 8. Two Second-Order Runs Implementing count_up and then count_down in the Two RPs