Reconfigurable Partition Interfaces - 2024.1 English

Vivado Design Suite User Guide: Dynamic Function eXchange (UG909)

Document ID
UG909
Release Date
2024-06-12
Version
2024.1 English

One of the fundamental requirements of a partially reconfigurable design is consistency between RMs. As one module is swapped for another, the connections between the static design and the RM must be identical, both logically and physically. To achieve this consistency, optimizations across the partition boundary or of the boundary itself are prohibited.

For optimal efficiency, all ports of a RP should be actively used on the static design side. For example, if static drivers of the RP are driven by constants (0 or 1), they are implemented through the creation of a LUT instance and local tie-off to a constant driver and cannot be trimmed away. Likewise, unconnected outputs remain on RP outputs, creating unnecessary waste in the overall design. These measures must be taken by the implementation tools to ensure that all RM have the same port map during design assembly.

Examine the interface of all RPs after synthesis to ensure that as few constants or unconnected ports as possible remain. By clearing out dead logic, resource utilization is reduced, and congestion and timing closure challenges easier to address.

Six different cases are possible for partition interface usage:

Both Static and Reconfigurable Module sides have active logic
(Applies to partition inputs or outputs)

This is the optimal situation. A partition pin is inserted.

If partition inputs are driven by VCC or GND, push these constants into the RM. This reduces LUT usage and allow the implementation tools to optimize these constants with the RM logic.

The Static side has an active driver but the Reconfigurable Module does not have active loads
(Applies to partition inputs)

This is acceptable because it accommodates the situation in which not every RM has the same I/O requirements. A partition pin is inserted, and the unused input ports are left unconnected.

For example, one module might require CLK_A, while a second might require CLK_B. Clock spines are pre-routed to the RP clock regions, but the module only taps into the clock source that is needed. However, if a partition input is not used by any RM, it should be removed from the partition instantiation.

The Static side has active loads but the Reconfigurable Module does not have an active driver
(Applies to partition outputs)

This is acceptable and similar to the case above. A partition pin is inserted, and it is driven by ground (logic 0) within the RM.

The Static side does not have an active driver, but the Reconfigurable Module has active loads
(Applies to partition inputs)

This results in an error that must be resolved by modifying the partition interface. The following is an example of an error that may be seen for this scenario:

ERROR: [Opt 31-65] LUT input is undriven either due to a missing connection from a design error, or a connection removed during opt_design.

This error message would be followed by a LUT instance that is within the RM.

Reconfigurable Module has an active driver, but the Static side has no active loads
(Applies to partition outputs)

This does not result in an error, but is far from optimal because the RM logic remains. No partition pin is inserted. These partition outputs should be removed.

Neither Static nor Reconfigurable Module sides have driver or loads for a partition port
(Applies to partition inputs or outputs)

Nothing is inserted or used, so there is no implementation inefficiency, but it is unnecessary in terms of the instantiation port list.

One basic requirement regarding partition interfaces is that each pin must be unidirectional. The use of bidirectional ports (type inout) on the module boundary is not supported. This requirement is due to the fact that routing resources within AMD FPGAs are fundamentally unidirectional and there are no internal tristate resources that could help manage changes in direction. Even if module ports resolve to be input or output after synthesis, Vivado will still consider the port to potentially be bidirectional. Please change any inout port to be explicitly input or output.