Step 9: Generating Bitstreams - 2020.2 English

Vivado Design Suite Tutorial: Dynamic Function eXchange
Document ID
UG947
Release Date
2021-02-23
Version
2020.2 English

Verifying Configurations

Recommended: Before generating bitstreams, verify all configurations to ensure that the static portion of each configuration match identically, so the resulting bitstreams are safe to use in silicon. The PR Verify feature examines the complete static design up to and including the partition pins, confirming that they are identical. Placement and routing within the Reconfigurable Modules is not checked, as different module results are expected here.
  1. Run the pr_verify command from the Tcl Console:
    pr_verify Implement/Config_shift_right_count_up_implement/top_route_design.dcp Implement/Config_shift_left_count_down_import/top_route_design.dcp

    If successful, this command returns the following message.

    INFO: [Vivado 12-3253] PR_VERIFY: check points Implement/Config_shift_right_count_up/
top_route_design.dcp and Implement/Config_shift_left_count_down/top_route_design.dcp are compatible

    By default, only the first mismatch (if any) is reported. To see all mismatches, use the -full_check option.

  2. Close the project:
    close_project

Generating Bitstreams

Now that the configurations have been verified, you can generate bitstreams and use them to target your selected demonstration board.

Note: The first configuration implements shift_right and count_up. The second configuration implements shift_left and count_down.
  1. First, read the first configuration into memory:
    open_checkpoint Implement/Config_shift_right_count_up_implement/top_route_design.dcp
  2. Generate full and partial bitstreams for this design. Be sure to keep the bit files in a unique directory related to the full design checkpoint from which they were created.
    write_bitstream -force -file Bitstreams/Config_RightUp.bit
    close_project

    Notice that three bitstreams have been created:

    • Config_RightUp.bit

      This is the power-up, full design bitstream.The four shift LEDs on the right will shift right and the four count LEDs on the left will count up.

    • Config_RightUp_Pblock_inst_shift_partial.bit

      This is the partial bit file for the shift_right module.

    • Config_RightUp_Pblock_inst_count_partial.bit

      This is the partial bit file for the count_up module that causes the count LEDs to count up.

    Important: When generated by a single call to write_bitstream, the names of the bit files currently do not reflect the name of the Reconfigurable Module variant to clarify which image is loaded. The current solution uses the base name given by the -file option and appends the Pblock name of the reconfigurable cell. It is critical to provide enough description in the base name to be able to identify the reconfigurable bit files clearly. All partial bit files have the _partial postfix.
    Using run_dfx.tcl to process the entire design through bitstream generation uses a different technique for generating the bitstreams. Opening a routed design checkpoint issues multiple calls to write_bitstream, which gives you more control over naming bitstreams and allows for different options (such a bitstream compression) to be applied to full versus partial bitstreams. For example, the names configured in the advanced_settings.tcl script are:
    • Config_shift_right_count_up_implement_full.bit

      This is the power-up, full design bitstream.

    • pblock_shift_shift_right_partial.bit

      This is the partial bit file for the shift_right module.

    • pblock_count_count_up_partial.bit

      This is the partial bit file for the count_up module.

  3. Generate full and partial bitstreams for the second configuration, again keeping the resulting bit files in the appropriate folder.
    open_checkpoint Implement/Config_shift_left_count_down_import/top_route_design.dcp
write_bitstream -force -file Bitstreams/Config_LeftDown.bit
close_project

    Similarly, you see three bitstreams created, this time with a different base name.

  4. Generate a full bitstream with grey boxes, plus blanking bitstreams for the Reconfigurable Modules. Blanking bitstreams can be used to “erase” an existing configuration to reduce power consumption.
    open_checkpoint Checkpoint/static_route_design.dcp
update_design -cell inst_count -buffer_ports
update_design -cell inst_shift -buffer_ports
place_design
route_design
write_checkpoint -force Checkpoint/Config_greybox.dcp
write_bitstream -force -file Bitstreams/config_greybox.bit
close_project

    The base configuration bitstream has no logic for either reconfigurable partition. The update_design commands here insert constant drivers (ground) for all outputs of the Reconfigurable Partitions, so these outputs do not float. The term grey box indicates that the modules are not completely empty with these LUTs inserted, as opposed to black boxes, which would have dangling nets in and out of this region. The place_design and route_design commands ensure they are completely implemented.