Create as many configurations as necessary to implement all RMs at least once. The
first configuration loads in synthesis results for top and the first RM. You must then
mark the module as being reconfigurable, then run implementation. Write out a checkpoint
for the complete routed configuration, and optionally for the RM so it can be reused
later if desired. Finally, remove the RM from the design (
update_design -cell -black_box) and write out a checkpoint for the locked
static design alone.
open_checkpoint top_synth.dcp read_xdc top_impl.xdc set_property HD.RECONFIGURABLE true [get_cells rp1] read_checkpoint -cell rp1 rp1_a_synth.dcp opt_design place_design route_design write_checkpoint config1_routed.dcp write_checkpoint -cell rp1 rp1_a_route_design.dcp update_design -cell rp1 -black_box lock_design -level routing write_checkpoint static_routed.dcp
For the second configuration, load the placed and routed checkpoint for static (if it was closed), which currently has a black box for the RM. Then load in the synthesis results for the second RM and implement the design. Finally write out an implementation checkpoint for the second version of the RM.
open_checkpoint static_routed.dcp read_checkpoint -cell rp1 rp1_b_synth.dcp opt_design place_design route_design write_checkpoint config2_routed.dcp write_checkpoint -cell rp1 rp1_b_route_design.dcp
If multiple RPs exist, then other configurations may be required. Additional configurations can also be created by importing previously implemented RM to create full designs that exist in hardware. This can be useful for creating full bitstreams with a desired combination for power-up, or for performing static timing analysis, power analysis, or simulation.
Full place and route results for each RM checkpoint is preserved completely, so
creating new configurations is easily done by loading a collection of routed
checkpoints. However, there are limitations to be aware of when using the flow. Using
write_checkpoint -cell to save the RM
implementation results does not preserve constraints local to this module. For RMs with
internal clock constraints or timing exceptions starting and/or ending within the RM,
these constraints need to be reapplied for timing analysis after creating the new
configuration. RMs with Xilinx or third party IP are
good examples of modules that might be exposed to this limitation.