Intel® Quartus® Prime Standard Edition User Guide: Partial Reconfiguration

Download PDF
ID 683499
Date 9/24/2018
Public
Document Table of Contents
Document Table of Contents x
1. Design Planning for Partial Reconfiguration A. Intel® Quartus® Prime Standard Edition User Guides
1. Design Planning for Partial Reconfiguration x
1.1. Terminology 1.2. An Example of a Partial Reconfiguration Design 1.3. Partial Reconfiguration Modes 1.4. Partial Reconfiguration Design Flow 1.5. Freeze Logic for PR Regions 1.6. Implementation Details for Partial Reconfiguration 1.7. Example of a Partial Reconfiguration Design with an External Host 1.8. Example Partial Reconfiguration with an Internal Host 1.9. Partial Reconfiguration Project Management 1.10. Programming Files for a Partial Reconfiguration Project 1.11. On-Chip Debug for PR Designs 1.12. Partial Reconfiguration Known Limitations 1.13. Document Revision History
1.1. Terminology x
1.1.1. Determining Resources for Partial Reconfiguration
1.3. Partial Reconfiguration Modes x
1.3.1. SCRUB Mode 1.3.2. AND/OR Mode 1.3.3. Programming File Sizes for a Partial Reconfiguration Project
1.4. Partial Reconfiguration Design Flow x
1.4.1. Design Partitions for Partial Reconfiguration 1.4.2. Incremental Compilation Partitions for Partial Reconfiguration 1.4.3. Partial Reconfiguration Controller Instantiation in the Design 1.4.4. Wrapper Logic for PR Regions
1.4.3. Partial Reconfiguration Controller Instantiation in the Design x
1.4.3.1. Component Declaration of the PR Control Block and CRC Block in VHDL 1.4.3.2. Instantiating the PR Control Block and CRC Block in VHDL 1.4.3.3. Instantiating the PR Control Block and CRC Block in Verilog HDL
1.5. Freeze Logic for PR Regions x
1.5.1. Clocks and Other Global Signals for a PR Design 1.5.2. Floorplan Assignments for PR Designs
1.6. Implementation Details for Partial Reconfiguration x
1.6.1. Interface with the PR Control Block through a PR Host 1.6.2. Partial Reconfiguration Pins 1.6.3. PR Control Signals Interface 1.6.4. Reconfiguring a PR Region 1.6.5. Partial Reconfiguration Cycle Waveform
1.7. Example of a Partial Reconfiguration Design with an External Host x
1.7.1. Example of Using an External Host with Multiple Devices
1.9. Partial Reconfiguration Project Management x
1.9.1. Create Reconfigurable Revisions 1.9.2. Compiling Reconfigurable Revisions 1.9.3. Timing Closure for a Partial Reconfiguration Project 1.9.4. PR Bitstream Compression and Encryption ( Intel® Arria® 10 Designs)
1.10. Programming Files for a Partial Reconfiguration Project x
1.10.1. Generating Required Programming Files 1.10.2. Generate PR Programming Files with the Convert Programming Files Dialog Box
1.10.2. Generate PR Programming Files with the Convert Programming Files Dialog Box x
1.10.2.1. Generating a .pmsf File from a .msf and .sof Input File 1.10.2.2. Generating a .rbf File from a .pmsf Input File 1.10.2.3. Create a Merged .msf File from Multiple .msf Files 1.10.2.4. Generating a Merged .pmsf File from Multiple .pmsf Files 1.10.2.5. Enable Partial Reconfiguration Bitstream Decompression when Configuring Base Design SOF file in JTAG mode 1.10.2.6. Enable Bitstream Decryption Option
1.12. Partial Reconfiguration Known Limitations x
1.12.1. Memory Blocks Initialization Requirement for PR Designs 1.12.2. M20K RAM Blocks in PR Designs 1.12.3. MLAB Blocks in PR designs 1.12.4. Implementing Memories with Initialized Content 1.12.5. Initializing M20K Blocks with a Double PR Cycle
1.12.2. M20K RAM Blocks in PR Designs x
1.12.2.1. Limitations When Using Stratix V Production Devices
1. Design Planning for Partial Reconfiguration
A. Intel® Quartus® Prime Standard Edition User Guides

1.6.4. Reconfiguring a PR Region

The figure below shows an internal host for PR, where the PR IP core is implemented inside the FPGA. However, these principles are also applicable for partial reconfiguration with an external host.

The PR control block (CB) represents the Stratix® V PR controller inside the FPGA. PR1 and PR2 are two PR regions in a user design. In addition to the four control signals (PR_REQUEST, PR_READY, PR_DONE, PR _ERROR) and the data/clock signals interfacing with the PR control block, your PR Control IP should also send a control signal (PR_CONTROL) to each PR region. This signal implements the freezing and unfreezing of the PR Interface signals. This is necessary to avoid contention on the FPGA routing fabric. In a case such as this, you need to add some decoding logic in the design, in addition to instantiating the PR IP core.

Figure 12. Example of a PR System with Two PR Regions

Implementation of PR Control logic in the FPGA.

After the FPGA device has been configured with a full chip configuration at least once, the INIT_DONE signal is released, and the signal is asserted high due to the external resistor on this pin. The INIT_DONE signal must be assigned to a pin to monitor it externally. When a full chip configuration is complete, and the device is in user mode, the following steps describe the PR sequence:

  1. Begin a partial reconfiguration process from your PR Control logic, which initiates the PR process for one or more of the PR regions (asserting PR1_Control or PR2_Control in the figure). The wrapper HDL described earlier freezes (pulls high) all non-global inputs of the PR region before the PR process.
  2. If you are using the PR IP core, use the PR_START signal to start reconfiguring the PR region. When you are not using the PR IP core, your control logic should send the PR_REQUEST signal from your control logic to the PR Control Block (CB). If your design uses an external controller, monitor INIT_DONE to verify that the chip is in user mode before asserting the PR_START or PR_REQUEST signal. The CB initializes itself to accept the PR data and clock stream. After that, the CB asserts a PR_READY signal to indicate it can accept PR data. If you are using the PR IP, the timing relationsips between the control and data signals is managed by the IP core. Data and clock signals are sent to the PR control block to partially reconfigure the PR region interface.
    Note: If you write your own controller logic, specify that exactly four clock-cycles must occur before sending the PR data to make sure the PR process progresses correctly.
    • When there are multiple PR personas for the PR region, your control logic must determine the programming file data for partial reconfiguration and specify the correct file.
    • When there are multiple PR regions in the design, then your control logic determines which regions require reconfiguration based on system requirements.
    • At the end of the PR process, the PR control block asserts a PR_DONE signal and deasserts the PR_READY signal. The Altera PR IP core further processes these signals to assert a 3-bit status signal. If you are not using the Altera PR IP, your design must take approcpriate action as defined by the timing diagrams when PR_DONE is asserted.
    • If you want to suspend sending data, you can implement logic to pause the clock at any point.
  3. When you are not using the PR IP core, your custom control logic must deassert the PR_REQUEST signal within eight clock cycles after the PR_DONE signal goes high. If your logic does not deassert the PR_REQUEST signal within eight clock cycles, a new PR cycle starts.
  4. If your design includes additional PR regions, repeat steps 2 – 3 for each region. Otherwise, proceed to step 5.
  5. When you are not using the PR IP core, your custom control logic must deassert the PR_CONTROL signal(s) to the PR region. The freeze wrapper releases all input signals of the PR region, thus the PR region is ready for normal user operation.
  6. You must perform a reset cycle to the PR region to bring all logic in the region to a known state. After partial reconfiguration is complete for a PR region, the states in which the logic in the region come up is unknown.

The PR event is now complete, and you can resume operation of the FPGA with the newly configured PR region.

At any time after the start of a partial reconfiguration cycle, the PR host can suspend sending the PR_DATA, but the host must suspend sending the PR_CLK at the same time. If the PR_CLK is suspended after a PR process, there must be at least 20 clock cycles after the PR_DONE or PR_ERROR signal is asserted to prevent incorrect behavior.

For an overview of different reset schemes in Altera devices, refer to the Recommended Design Practices chapter in the Intel® Quartus® Prime Handbook.

Related Information
Level Two Title