Bitstream generation is different for the two modes. At the end of a Standard DFX configuration run (parent and each child), a call to Generate Bitstream or Generate Device Image will produce multiple bitstreams: a full device .bit or .pdi file containing static and reconfigurable logic in that configuration, as well as one partial .bit or .pdi file for each Reconfigurable Module present in that run.
At the end of the parent run for an Abstract Shell configuration, this is also true, as the full static design is present so both full and partial .bit or .pdi files can be generated. However, at the end of an Abstract Shell child run, only a single partial .bit or .pdi file for the target Reconfigurable Module implemented in that run might be created. A full device image cannot be generated for an Abstract Shell child run simply because the entire static design is not present in that checkpoint.
Should you require a full device bitstream that contains Reconfigurable Modules
from child Abstract Shell runs together with the full static design, an in-memory design
must be assembled by using add_files and link_design (or open_checkpoint followed by read_checkpoint
-cell). These commands should be used to pull together routed design
checkpoints containing the static (from the parent run) and reconfigurable (from child
runs) results, then a call to write_bistream
-no_partial_bitfile (UltraScale+) or write_device_image
-no_partial_pdifile (Versal) can be used to generate a
full device programming image.
Just as for the Standard DFX mode, pr_verify is automatically called for
any child run to validate the implemented result compared to the locked static image it
was built from – in this case it will be the abstract shell checkpoint starting point
for child runs. Device image creation will not be run if this check fails.