With all the necessary Configuration Runs defined, the design can be synthesized and implemented. The Flow Navigator can be used to pull through any steps of synthesis, place and route, and even bitstream generation. The Flow Navigator works on the active run just like a standard flow, but it will launch all child runs in addition to the active parent.
One detail that is required for Dynamic Function eXchange designs is a Pblock for
each RP. Without a Pblock defined, the following error is issued in
ERROR: [DRC 23-20] Rule violation (HDPR-30) Missing PBLOCK On Reconfigurable Cell
If this necessary floorplan is present in a top-level design constraints file, you can pull all the way from synthesis to bitstream generation. If not, the easiest way to create one is to stop and open the design after top-level synthesis. In the Netlist hierarchy view, right-click on the module that corresponds to the RP and select.
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.
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
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.
Everything shown in the different windows, as shown in Implementing the DFX Design, 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.