Verification Passes - 2022.1 English

Just as with a standard DFX design flow, Nested DFX design images should be checked using pr_verify to confirm all images are in sync. Like the core implementation tools (opt_design, etc.), pr_verify will act upon the design based on the current cells marked reconfigurable. With this in mind, perform apples-to-apples comparisons with the same current static design present. Verify all compatible configurations by sourcing this script:

source verify_configurations.tcl

This script compares three pairs of routed designs. Each does a pairwise comparison of checkpoints with static logic expected to be identical. This section describes the comparisons done and the compatible bitstreams that will be created in the next step.

1. The first call to pr_verify compares the two recombined checkpoints. These should each have identical static implementation results top only, with a single Reconfigurable Partition, inst_RP. These checkpoints represent standard DFX designs with no nesting, even though each could receive appropriate second-order partial bitstreams.

   If other checkpoints are created with second-order modules (for example shift_left, count_down) and then recombined, they could be compared via pr_verify and have their “inst_RP” partial bitstreams added to this compatibility list. This would also be true for any other RMs for inst_RP even without any subdivided second-order RPs.

2. The second call to pr_verify compares the shift_right and shift_left second level checkpoints. These have static locked down to the upper and lower submodules, so the comparison is between this static logic for the top and reconfig_shifters levels of hierarchy.
3. Much like the second, the third call to pr_verify compares the count_up and count down second level checkpoints. These have static locked for top and reconfig_counters, so the comparison is between this static logic down to the upper and lower Reconfigurable Partitions.