Step 2: Customizing the Dynamic Function eXchange (DFX) Controller IP - 2022.1 English

Vivado Design Suite Tutorial: Dynamic Function eXchange (UG947)

Document ID
UG947
Release Date
2022-05-31
Version
2022.1 English

The DFX Controller IP requires a few details to be entered during the customization process. Identifying all information regarding each Reconfigurable Partition (RP) and Reconfigurable Module (RM) creates a fully populated controller that understands the entirety of the reconfiguration needs of the target FPGA. Within this IP, reconfigurable portions of the design are referred to as Virtual Sockets, which encompasses the RP along with all associated static logic used to manage it, such as decoupling or handshaking logic. While the core parameters are customizable during operation, the more that can be entered during this step, the better. This allows the front-end design description to more accurately match the final implemented design.

  1. Open the VivadoĀ® IDE and in the Tasks section click the Manage IP task, select New IP Location and click Next. Enter the following details and click Finish:
    • Part: Click Boards to select the VCU108
    • IP Location: <Extract_Dir>/Sources/ip
    Note: The KCU105 development board is not supported, as the boot flash on this board is a QSPI device. QSPI and sync-mode BPI configuration schemes are not supported for Dynamic Function eXchange on UltraScaleā„¢ devices. See Table 8-1 in this link of Vivado Design Suite User Guide: Dynamic Function eXchange (UG909).
  2. In the IP Catalog, expand the Dynamic Function eXchange category to double-click the DFX Controller IP.
    Figure 1. The Dynamic Function eXchange Controller in the IP catalog

    The DFX Controller IP GUI has four tabs on the left side, providing feedback on the current configuration of the IP. The Validation tab shows any errors that might arise as the core parameters are entered. The core does not compile if errors exist.

    There are two tabs on the right side of the GUI where all customization is done. Most of the information is entered on the Virtual Socket Manager Options tab.

  3. Leave the component name as dfx_controller_0. The version of the DFX Controller used in the final design will be automatically compiled in Step 3: Compiling the Design.
  4. On the Global Options tab, make three changes:
    1. Set the Polarity of reset and icap_reset = 1
    2. Specify the CAP arbitration protocol = 1) Latency has not been added to arbiter signals
    3. Set the number of Clock domain crossing stages = 2

    Make sure that the Managed device type is set to The DFX CONTROLLER will manage Virtual Sockets on an UltraScale device. The DFX Controller GUI should now look like this:

    Figure 2. Component Name and Global Options Completed

    Note that this DFX Controller can manage Virtual Sockets on 7 series, UltraScale, or UltraScale+ devices. This IP is not limited to managing reconfiguration on the same device on which it resides. It can connect to an ICAP on another device to manage its reconfiguration. An example of a multi-chip solution using the DFX Controller follows.

    Figure 3. Example of a Multi-Chip Solution Using the DFX Controller

  5. Switch to the Virtual Socket Manager Options tab to define information about the Virtual Sockets and their Reconfigurable Modules.

    The DFX Controller IP is preloaded with one Virtual Socket with one Reconfigurable Module to get you started.

    First, define the Virtual Socket Manager (VSM) for the Shift functionality.

  6. Rename the current VSM from VS_0 to vs_shift.
  7. Rename the current RM from RM_0 to rm_shift_left.
    CAUTION:
    • Underscores are not visible in the Virtual Socket Manager to configure and Reconfigurable Module to configure pull-down menus. The Virtual Socket Name and Reconfigurable Module Name fields below the pull-down menus show this more accurately.

    To accept a new value in any field in the GUI, simply click in any other field in the GUI or press the Tab key. Do NOT press Enter, as this will trigger compilation of the IP.

  8. Click the New Reconfigurable Module button to create a new RM for this VSM. Name it rm_shift_right in the Reconfigurable Module Name field.
    Tip: Up to 128 Reconfigurable Modules can be managed by a single Virtual Socket Manager.
  9. Configure the vs_shift VSM to have the following properties:
    • Has Status Channel = checked
    • Has PoR RM = rm_shift_right
    • Number of RMs allocated = 4

    The PoR RM indicates which RM is contained within the initial full-design configuration file, so the VSM knows which triggers and events are appropriate upon startup of the FPGA. The VSM tracks the current active Reconfigurable Module in its socket.

    Even through you have only defined two RMs for this Virtual Socket, you have set aside space for four in total. This allows for expansion later on. Additional Reconfigurable Modules can be identified using the AXI4-Lite interface, but only if spaces have been reserved for them.

  10. For each of these RMs, enter the following values. Use the Reconfigurable Module to configure pull-down to switch between the two RMs.
    • For rm_shift_left:
      • Reset type = Active High
      • Duration of Reset = 3
    • For rm_shift_right:
      • Reset type = Active High
      • Duration of Reset = 10
    Note: The different reset durations are given to show that these can be independently assigned, as each RM may have different requirements. Reset durations are measured in clock cycles.
  11. For each RM, assign a bitstream size and location to identify where it will reside in the BPI flash device.
    • For rm_shift_left:
      • Bitstream 0 address = 0x00B00000
      • Bitstream 0 size (bytes) = 375996
      • Bitstream 0 is a clearing bitstream = unchecked
      • Bitstream 1 address = 0x00B5C000
      • Bitstream 1 size (bytes) = 26036
      • Bitstream 1 is a clearing bitstream = checked
    • For rm_shift_right:
      • Bitstream 0 address = 0x00B62800
      • Bitstream 0 size (bytes) = 375996
      • Bitstream 0 is a clearing bitstream = unchecked
      • Bitstream 1 address = 0x00BBE800
      • Bitstream 1 size (bytes) = 26036
      • Bitstream 1 is a clearing bitstream = checked

    This information is typically not known early in design cycles, as bitstream size is based on the size and composition of the Reconfigurable Partition Pblock, and bitstream address is based on storage details. Until the design is to be tested on silicon, these can be set to 0. As the design settles and hardware testing with the DFX Controller is set to begin, this information can be added. The bitstream address information must match the information passed during PROM file generation. Certain bitstream generation options, most notably bitstream compression, can lead to variations in the final bitstream size for different configurations, even for the same Reconfigurable Partition.

  12. Define the Trigger Options for the Shift functionality:
    • Number of Hardware Triggers = 4
    • Number of Triggers allocated = 4

    The four trigger assignments are done automatically. These can be modified during device operation using AXI4-Lite, which is especially useful when you have added a new RM through the same mechanism during a field system upgrade.

    At this point, the IP GUI should look like this (showing rm_shift_left here):

    Figure 4. VSM vs_shift Completed

    Next, you will create and populate the Count Virtual Socket following the same basic steps, with slightly different options here and there.

  13. Click the New Virtual Socket Manager button to create a new VSM.
  14. Add two RMs with these names and properties:
    • Reconfigurable Module Name = rm_count_up
      • Reset type = Active High
      • Duration of Reset = 12
    • Reconfigurable Module Name = rm_count_down
      • Reset type = Active-High
      • Duration of Reset = 16

    For this Virtual Socket, leave the bitstream address and size information at the default of 0, but set bitstream 1 to be a clearing bitstream In addition to being defined here, bitstream size information can be added to a routed configuration checkpoint via the DFX Controller Tcl API, or can be added in an active design using the AXI4-Lite interface. For the Count Virtual Socket, the bitstream address and size information is added using the Tcl commands after place and route, but before bitstream generation.

    Tip: For more information about how to use the DFX Controller Tcl API, see this link in the Dynamic Function eXchange Controller IP LogiCORE IP Product Guide (PG374).

    Examine the Tcl scripts in the <Extract_Dir>/Sources/scripts directory. The update_dfxc_vcu108.tcl uses the DFX Controller Tcl API to update the bitstream address and bitstream size, which is stored in dfx_info_vcu108.tcl. This file is sourced later in the lab from <Extract_Dir>/design.tcl.

  15. On the Virtual Socket Manager Options tab, modify these VSM settings from their default values:
    • Virtual Socket Name = vs_count
    • Start in Shutdown = checked
    • Shutdown on error = unchecked
    • Has PoR RM = checked, rm_count_up
  16. Define the Trigger Options for the Count functionality:
    • Number of Hardware Triggers = 4
    • Number of Triggers allocated = 4

    This completes the planned customization of the DFX Controller IP for this tutorial.

  17. Click OK and then Generate to begin core compilation and out-of-context synthesis.
Figure 5. Final DFX Controller Symbol