Opening Post-synthesis Configurations - 2024.2 English - UG909

Vivado Design Suite User Guide: Dynamic Function eXchange (UG909)

Document ID
UG909
Release Date
2024-12-13
Version
2024.2 English

After all the module-level and top-level synthesis runs, any configuration of the design can be opened to define physical or timing constraints. In the flow navigator, a left-click on Open Synthesized Design opens the configuration used in the active parent run. However, a right-click on Open Synthesized Design presents additional options, including Open DFX Configuration. This selection is followed by a list of all valid configurations that have been declared in the DFX wizard and whose reconfigurable modules have completed synthesis.

Figure 1. Open DFX Configurations Generated by Your Tool
Selecting any of these configurations opens the combination of static design with the reconfigurable modules defined in that configuration.
Important: Even though different constraint sets might be available, or that RM-level constraint files might be defined within the partition definitions, all constraints that are added or modified during an interactive session in the Vivado IDE is saved to the target constraint file in the active constraint set.
Any constraints that are unique to a specific reconfigurable module should be manually moved to a constraint file associated with that RM within the partition definition and then scoped to that hierarchical instance. The only exception to this behavior is the use of Set Up Debug to define the details for ChipScopeā„¢ . See the Debugging Versal Device DFX Designs section for more information.

With a post-synthesis design configuration open, in the Netlist hierarchy view, right-click the module that corresponds to the RP, and select Floorplanning > Draw Pblock.

After you draw the Pblock for a RP, its properties can be seen in the Pblock Properties window under the Properties view. Available here are two options unique to RPs: RESET_AFTER_RECONFIG (7 series only) and SNAPPING_MODE. The Statistics view reports the resources available and used for the currently loaded RM, so it is important to consider the needs for the other RMs as well.

Figure 2. Dynamic Function eXchange Properties on a Pblock (7 series)

Once a Pblock has been created for each RP, each Configuration can be implemented. The Run Implementation button in the Flow Navigator launches place and route on the active parent run first. Upon completion, all child runs will be launched in parallel, using the static design results of the parent as a starting point.

The Vivado project takes care of the underlying details of the DFX solution. Database management is one of these details. Upon completion of the parent run, the routed database for the entire design is saved, as well as a cell-level checkpoint for each RM. Then Vivado calls update_design -black_box to carve out each RM, resulting in a static-only design checkpoint, which is the basis for all of its child runs. When child implementations runs are launched, Vivado assembles the configuration from the static-only routed parent checkpoint and post-synthesis checkpoints for each RM. At this time, only routed module checkpoints from the parent run can be reused in child Configurations; if the same RM is selected for one RP in multiple child runs, the results will be different.

Figure 3. Implementing Multiple Configurations in Parallel

Just as with a standard project, Vivado tracks dependencies between runs. When design sources, constraints, options or settings are modified, any synthesis or implementation run that depends on them are marked out-of-date. One example: if an RTL design source for one RM is updated, that out-of-context module run will be marked out-of-date, and any Configuration Runs that include that RM will also be marked out-of-date. Another example: if any implementation option for a parent Configuration Run is changed, it and all child runs will be marked out-of-date.

Only parent Configuration Runs can be set as active. The Flow Navigator acts upon the active run, but in the DFX flow, all child runs are also included in whatever action is requested. Pop-up messages (completed run, error, etc.) can relate to multiple runs but default to the parent run. Use the pull down selection to choose the desired implementation run.

Figure 4. Implementation Completed Dialog Box

Everything shown in the different windows relate to the active parent run. In order to see details about a child implementation run, select that run and look at the Implementation Run Properties window to see all the inputs (properties, options) and outputs (log, reports, messages) for that specific run.

Figure 5. Implementation Run Properties Window for a Child Run