Step 4: Synthesizing and Implementing the Current Design - 2020.2 English

With the design from above open in the Vivado IDE, examine the Design Runs window. The top-level design synthesis run (synth_1) and the parent implementation run (impl_1) are marked “active.” The Flow Navigator actions apply to these active runs and their child runs, so clicking on Run Synthesis or Run Implementation pulls the design through only these runs, as well as the OOC synthesis runs needed to complete them. You can select a specific parent or child implementation run, right-click and select Launch Runs to pull through the entire flow for that ultimate target.

1. In the Flow Navigator, click Run Synthesis > Open Synthesized Design.

   This action will synthesize all OOC modules, followed by synthesis of the top level design. This is no different than any design with OOC modules (IP or otherwise).

   In the post-synthesis design that opens, note that two Pblocks have already been defined. These were supplied in pblocks_<board>.xdc and map to the two shift instances in top. If no Pblocks had existed with the design sources, they could be created at this step in the flow. This can be done by right-clicking on an inst_shift instance in the design hierarchy to select Floorplanning > Draw Pblock. Each instance will require its own unique Pblock.

   Figure 1. Floorplan with Two Reconfigurable Partitions (KC105 shown)
   
   
2. Select one of the two Pblocks in the floorplan and note its properties. The last two properties listed are RESET_AFTER_RECONFIG (7 series only) and SNAPPING_MODE, two properties specific to DFX. Note that both of these options have been enabled in the Pblocks xdc.
3. Run DFX-specific design rule checks by selecting Reports > Report DRC. To save time, you can deselect all checkboxes other than the one for Dynamic Function eXchange.
   Figure 2. Checking DFX DRCs
   
   

   DRC checks will report no errors with the supplied sources and constraints. Advisory messages may be given for certain devices with suggestions on how to improve the quality of the given Pblocks. These can be ignored for this simple design.

   If you have created your own floorplan and DRCs have been reported, fix the issues before moving on. Note that both modules will require BRAM resources, and remember that SNAPPING_MODE will resolve any errors related to horizontal or vertical alignment.

   Tip: Run DFX Design Rule Checks early and often.
4. In the Flow Navigator, select Run Implementation to run place and route on all configurations.

   This action runs implementation first for impl_1 and then for child_0_impl_1. Behind the scenes, Vivado takes care of all the details. In addition to running place and route for the two runs with all the DFX requirements in place, it does a few more tasks specific to DFX. After impl_1 completes, Vivado automatically:

   • Writes module-level (OOC) checkpoints for each routed shift_right RM.
   • Carves out the logic in each RP to create a static-only design image for the top. This is done by calling update_design -black_box for each instance.
   • Locks all placement and routing for the static-only portion of the design. This is done by calling lock_design -level routing.
   • Saves the locked static parent image to be reused for all child runs.

   In addition, when the child run completes, module-level checkpoints are created for the routed shift_left RMs. A locked static design image would be identical to the parent, so this step is not necessary.

   If only specific configuration runs are desired, these can be individually selected within the Design Runs window. Note that a parent run must be completed successfully before a child run can be launched, as the child run starts with the locked static design from the parent.

5. When Implementation completes, click Cancel in the resulting pop-up dialog.
   CAUTION:
   Even though the design has been processed through to the child implementation run, selecting Open Implemented Design opens the parent run by default. Use the pulldown selection to choose the desired implementation run.
   Figure 3. All Configurations Routed

   At this point, there are two steps remaining. The first is running PR Verify to compare the two configurations to ensure consistency of the static part of the design images. This step is highly recommended and will occur automatically within the Vivado project. The second step is to generate the bitstreams themselves.

6. In the Flow Navigator, click Generate Bitstream. This action launches bitstream generation on the active parent run, and launches PR Verify and then bitstream generation on all implemented child runs.

   For each configuration run, both full and partial bitstreams are generated by default.

The entire Dynamic Function eXchange flow can be run in a project environment. All steps, from module-level synthesis to bitstream generation can be done without leaving the GUI.