1.5.1. Step 1: Getting Started 1.5.2. Step 2: Create Design Partitions 1.5.3. Step 3: Allocate Placement and Routing Regions 1.5.4. Step 4: Add the Partial Reconfiguration Controller IP 1.5.5. Step 5: Define Personas 1.5.6. Step 6: Create Revisions 1.5.7. Step 7: Compile the Base Revision 1.5.8. Step 8: Set Up PR Implementation Revisions 1.5.9. Step 9: Change the SUPR Logic 1.5.10. Step 10: Program the Board 1.5.11. Modifying the SUPR Partition
1.3. Static Update Region Overview
The following figure shows the block diagram for a PR design that includes a SUPR region. Block A is the Top static region. Block B is the SUPR region. Block C is the PR partition.
Figure 2. PR Design with SUPR Region
- A Top Static Region—contains design logic that does not change. Changing this region requires recompilation of all associated personas. The static region includes the portion of the design that does not change for any persona. This region can include periphery and core device resources. You must register all communication between the SUPR and PR partitions in the static region. This requirement helps to ensure timing closure for any personas, with respect to the static region.
- B SUPR Region—contains core-only logic that may possibly change for risk mitigation, but never requires runtime reconfiguration. The SUPR region has the same requirements and restrictions as the PR partition. The SUPR partition can contain only core resources. Therefore, the SUPR partition must be a child partition of the top-level root partition that contains the design periphery and clocks. Changing the SUPR region produces a SRAM Object File (.sof) that is compatible with all existing compiled Raw Binary File (.rbf) files for PR partition C.
- C PR Partition—contains arbitrary logic that you can reprogram at runtime with any design logic that fits and achieves timing closure during compilation.
Did you find the information on this page useful?