With a set of RMs defined within block designs, Configurations can be declared. Each Configuration is a combination of the static logic plus one RM per RP; each Configuration is a full design image.
While each Configuration can be created manually, the simplest path is to let
Vivado create the minimum set of Configurations automatically. This
is done by selecting the automatically create
configurations link in the middle of this screen. This will create as
many Configurations as necessary to ensure that all RMs are included at least once.
Tip: This option is
only available if no Configurations have been defined yet.
Figure 1. Edit Configurations before Creating Any Configurations
If one BDC has more RMs than another, a greybox RM will automatically be used for any RP that has all its RMs covered by prior Configurations. These default Configurations can be modified or renamed, and additional Configurations can be created if desired.
Tip: Greybox modules are different than
black box modules, because they are not truly empty. Greybox RM shave tie-off LUTs
inserted to complete legal design connectivity in the absence of an RM and they ensure
outputs do not float during operation. To complete legal connectivity, registers can be
inserted at clock input ports and clock buffers can be inserted at output ports to drive
clock loads. The Vivado tools create these by calling
update_design -buffer_ports on selected modules.
Greybox RMs cannot be used in parent runs, because they can lead to sub-optimal results
for the static design implementation and/or issues with NoC configuration.Figure 2. Edit Configurations After Automatic Generation of
Configurations
Note: If one RM is used in more than
one configuration, the implementation results might be different, because place and
route is performed each time, but only if the RM was initially implemented in a child
run. RM implementation results are reused if they were originally done in the parent
configuration. The
lock_design -level routing command
is set on this reused, implemented RM to lock placement and routing for all subsequent
usage in child runs. This allows the Vivado project to
track dependencies between parent and child.