Intel Quartus Prime Pro Edition User Guide: Partial Reconfiguration

RSS

UG-20136 | 2019.04.22

Creating a Partial Reconfiguration Design

Partial reconfiguration (PR) allows you to reconfigure a portion of the FPGA dynamically, while the remaining FPGA design continues to function. You can define multiple personas for a particular region in your design, without impacting operation in areas outside this region. This methodology is effective in systems with multiple functions that time-share the same FPGA device resources. PR enables the implementation of more complex FPGA systems.

The Intel^® Quartus^® Prime Pro Edition software supports the PR feature for the Intel^® Arria^® 10, Intel^® Arria^® 10, and Intel^® Cyclone^® 10 GX device families.

Figure 1. Partial Reconfiguration Design

PR provides the following advancements over a flat design:

Allows run-time design reconfiguration
Increases scalability of the design through time-multiplexing
Lowers cost and power consumption through efficient use of board space
Supports dynamic time-multiplexing functions in the design
Improves initial programming time through smaller bitstreams
Reduces system down-time through line upgrades
Enables easy system update by allowing remote hardware change
A simplified compilation flow for partial reconfiguration

Hierarchical Partial Reconfiguration

Intel^® Quartus^® Prime Pro Edition software also supports hierarchical partial reconfiguration (HPR), with multiple parent and child design partitions, or multiple levels of partitions in a design. In HPR designs, a static region instantiates a parent PR region, and a parent PR region instantiates a child PR region. The same PR region reprogramming is possible for the child and parent partitions. Refer to the Partial Reconfiguration Tutorials for detailed HPR instructions.

Static Update Partial Reconfiguration

Static update partial reconfiguration (SUPR) allows you to define and modify a specialized static region, without requiring recompilation of all personas. This technique is useful for a portion of a design that you may possibly want to change for risk mitigation, but that never requires runtime reconfiguration. In PR without an SUPR partition, you must recompile all personas for any change to the static region. Refer to the Partial Reconfiguration Tutorials for detailed SUPR instructions.

Partial Reconfiguration Design Simulation

The Intel^® Quartus^® Prime Pro Edition software supports simulation of PR persona transitions through use of simulation multiplexers. You use the simulation multiplexers to change which persona drives logic inside the PR region during simulation. This simulation allows you to observe the resulting change and the intermediate effect in a reconfigurable partition. Refer to Partial Reconfiguration Design Simulation for details.

Partial Reconfiguration Terminology

This document refers to the following terms to explain partial reconfiguration:

Table 1. Partial Reconfiguration Terminology
Term	Description
Floorplan	The layout of physical resources on the device. Creating a design floorplan, or floorplanning, is the process of mapping the logical design hierarchy to physical regions in the device.
Hierarchical Partial Reconfiguration	Partial reconfiguration that includes multiple parent and child design partitions, or nesting of partitions in the same design.
PR control block	A dedicated block in Intel^® Arria^® 10 FPGAs. The PR control block processes the PR requests, handshake protocols, and verifies the cyclic redundancy check (CRC).
PR host	The system for coordinating PR. The PR host communicates with the PR control block ( Intel^® Arria^® 10 designs) or Secure Device Manager ( Intel^® Stratix^® 10 designs). Implement the PR host within the FPGA (internal PR host) or in a chip or microprocessor.
PR partition	Design partition that you designate as Reconfigurable. A PR project can contain one or more PR partitions.
PR Solutions Intel^® FPGA IP	Suite of Intel^® FPGA IP that simplify implementation of PR handshaking and freeze logic.
PR region	A physical portion of FPGA device that is subject to partial reconfiguration. You full define a PR region in the base configuration design.A device can contain more than one PR region. A PR region can be core-only, such as LAB, RAM, or DSP. The green bitstream configures the PR region.
PR persona	A specific PR partition implementation in a PR region. A PR region can contain multiple personas. Static regions contain only one persona.
Revision	A collection of settings and constraints for one version of your project. An Intel^® Quartus^® Prime Settings File (.qsf) preserves each revision of your project. Your Intel^® Quartus^® Prime project can contain several revisions. Revisions allow you to organize several versions of your design within a single project.
Secure Device Manager (SDM)	A triple-redundant processor-based Intel^® Stratix^® 10 FPGA block that performs authentication, decryption, and decompression on the configuration data the block receives, before sending the data over to the configurable nodes through the configuration network.
Snapshot	The output of a Compiler stage. You can export the synthesis or final compilation results snapshot.
Static region	All areas not occupied by PR regions in your project. You associate the static region with the top-level partition of the design. The static region contains both the core and periphery locations of the device. The blue bitstream configures the static region.
Static update partial reconfiguration	A static region that allows change, without requiring the recompilation of all personas. This technique is useful for a portion of a design that you may possibly want to change for risk mitigation, but that never requires runtime reconfiguration.

Partial Reconfiguration Process Sequence

Your partial reconfiguration design must initiate the PR operation and deliver the configuration file to the PR control block ( Intel^® Arria^® 10 designs) or SDM ( Intel^® Stratix^® 10 designs). Before partial reconfiguration, you must ensure that the FPGA device is in user mode, and in a functional state. The following steps describe the partial reconfiguration sequence:

Send the stop_req signal to the PR region from the sequential PR control logic to prepare for the PR operation. Upon receiving this signal, the PR regions complete any pending transactions and stop accepting new transactions.
Wait for the stop_ack signal to indicate that the PR region is ready for partial reconfiguration.
Use PR control logic to freeze all necessary outputs of the PR regions. Additionally, drive the clock enable for any initialized RAMs to disabled state.
Send the PR bitstream to the PR control block ( Intel^® Arria^® 10 designs) or SDM ( Intel^® Stratix^® 10 designs) to initiate the PR process for the PR region. When using any of the Partial Reconfiguration Controller Intel^® FPGA IP, the Avalon^® -MM or Avalon^® -ST interface on the IP core provides this functionality. When directly instantiating the PR control block for Intel^® Arria^® 10 designs, refer to Intel Arria 10 PR Control Block Signal Timing Diagrams
On successful completion of the PR operation, reset the PR region.
Signal the start of PR operation by asserting the start_req signal, and deasserting the freeze signal.
Wait for the start_ack signal to indicate that the PR region is ready for operation.
Resume operation of the FPGA with the newly reconfigured PR region.

Figure 2. PR Process Sequence Timing Diagram

Internal Host Partial Reconfiguration

In internal host control, an internal controller, a Nios^® II processor, or an interface such as PCI Express* ( PCIe* ) or Ethernet, communicates directly with the Intel^® Arria^® 10 PR control block, or with the Intel^® Stratix^® 10 SDM.

To transfer the PR bitstream into the PR control block or SDM, you use the Avalon^® -MM interface on the Intel^® Arria^® 10 or Intel^® Stratix^® 10 Partial Reconfiguration IP core. When the device enters user mode, you initiate partial reconfiguration through the FPGA core fabric using the PR internal host.

Note: If you create your own control logic for the PR host, the logic must meet the PR interface requirements.

Figure 3. Internal Host PR

When performing partial reconfiguration with an internal host, use the dedicated PR pins (PR_REQUEST, PR_READY, PR_DONE, and PR_ERROR) as regular I/Os. Implement your static region logic to retrieve the PR programming bitstreams from an external memory, for processing by the internal host.

Figure 4. Intel^® Arria^® 10 FPGA System Using an Internal PR Host

Send the programming bitstreams for partial reconfiguration through the PCI Express* link. Then, you process the bitstreams with your PR control logic and send the bitstreams to the PR IP core for programming. nCONFIG moves the device out of the user mode into the device configuration mode.

¹ nCONFIG can lock the device and force a power-cycle. PR programming may corrupt the static logic, due to improper use, causing disconnection of the core clock input to configuration block and unresponsive configuration. You must reset the PR IP before toggling nCONFIG.

External Host Partial Reconfiguration

In external host control, an external FPGA or CPU controls the PR configuration using external dedicated PR pins on the target device. When using an external host, you must implement the control logic for transmission of the bitstream to the hard FPGA programming pins.

Figure 5. PR System Using an External Host ( Intel^® Arria^® 10 Example)

Partial Reconfiguration Design Considerations

Partial reconfiguration is an advanced design flow in the Intel^® Quartus^® Prime Pro Edition software. Creating a partial reconfiguration design requires an understanding of how the PR design guidelines apply to your design. When designing for partial reconfiguration, you must consider the entire system-level behavior initial conditions to maintain the integrity and correctness of the static region operation.

For example, during PR programming, you must ensure that other parts of the system do not read or write to the PR region. You must also freeze the write enable output from the PR region into the static region, to avoid interference with static region operation. If all personas for your design do not have identical top-level interfaces, you must create the wrapper logic to ensure that all the personas appear similar to the static region. Upon partial reconfiguration of a PR region, you must bring the registers in the PR region to a known state by applying a reset sequence. There are specific guidelines for global signals and on-chip memories. The following sections provide design considerations and guidelines to help you create design files for a PR design.

FPGA Device and Software Considerations

Only Intel^® Arria^® 10 devices in -1, -2 and -3 speed grade support partial reconfiguration. All Intel^® Stratix^® 10 devices support PR.
Use the nominal VCC of 0.9V or 0.95V as per the datasheet, including VID enabled devices.
To minimize Intel^® Arria^® 10 programming files size, ensure that the PR regions are short and wide. For Intel^® Stratix^® 10 designs, use sector-aligned PR regions.
The Intel^® Quartus^® Prime Standard Edition software does not support partial reconfiguration for Intel^® Arria^® 10 devices, nor provide any support for Intel^® Stratix^® 10 devices.
The current version of the Intel^® Quartus^® Prime Pro Edition software supports only one Signal Tap File (.stp) per revision.

Design Partition Considerations

Reconfigurable partitions can only contain core resources, such as LABs, RAMs, and DSPs. All periphery resources, such as the transceivers, external memory interface, HPS, and clocks must be in the static portion of the design.
To physically partition the device between static and individual PR regions, floorplan each PR region into exclusive, core-only, placement regions, with associated routing regions.
A reconfiguration partition must contain the super-set of all ports that you use across all PR personas.

Clocking, Reset, and Freeze Signal Considerations

The maximum number of clocks or other global signals for any Intel^® Arria^® 10 PR region is 33. The maximum number of clocks or other global signals for any Intel^® Stratix^® 10 PR region is 32. In the current version of the Intel^® Quartus^® Prime Pro Edition software, no two PR regions can share a row-clock.
PR regions do not require any input freeze logic. However, you must freeze all the outputs of each PR region to a known constant value to avoid unknown data during partial reconfiguration.
Increase the reset length by 1 cycle to account for register duplication in the Fitter.
Ensure that all low-skew global signals (clocks and resets) driving into PR region in base revision compilations have destinations.

Partial Reconfiguration Design Guidelines

The following table lists important design guidelines at various steps in the PR design flow:

Table 2. Partial Reconfiguration Design Guidelines
PR Design Step	Guideline	Reason
Designing for partial reconfiguration	Do not assume initial states in registers inside PR region. After PR is complete, ensure that you reset all the control path registers to a known state, but omit the data path registers.	Registers inside the PR region contain undefined values after reconfiguration. Omitting data path registers reduces congestion on reset signals.
Designing for partial reconfiguration	You cannot define synchronous reset as a global signal for Intel^® Arria^® 10 partial reconfiguration.	PR regions do not support synchronous reset of registers as a global signal, because the Intel^® Arria^® 10 LAB does not support synchronous clear (`sclr`) signal on a global buffer. The LAB supports the asynchronous clear (`aclr`) signal driven from a local input, or from a global network row clock. As a result, only the `aclr` can be a global signal, feeding registers in a PR region.
Partitioning the design	Register all the inputs and outputs for your PR region.	Improves timing closure and time budgeting.
	Reduce the number of signals interfacing the PR region with the static region in your design.	Reduces the wire LUT count.
	Create a wrapper for your PR region.	The wrapper creates common footprint to static region.
	Drive all the PR region output ports to inactive state when the PR region is held in reset and the freeze bit is asserted for the PR region.	Prevents the static region logic from receiving random data during the partial reconfiguration operation.
	PR boundary I/O interface must be a superset of all the PR persona I/O interfaces.	Ensures that each PR partition implements the same ports.
Preparing for partial reconfiguration	Complete all pending transactions.	Ensures that the static region is not in a wait state.
Maintaining a partially working system during partial reconfiguration	Hold all outputs to known constant values.	Ensures that the undefined values the PR region receives during and after the reconfiguration do not affect the PR control logic.
Initializing after partial reconfiguration	Initialize after reset.	Retrieves state from memory or other device resources.
Debugging the design using Signal Tap Logic Analyzer	Do not tap signals in the default personas. Store all the tapped signals from a persona in one .stp file.	The current version of the Intel^® Quartus^® Prime software supports only one .stp (Signal Tap file) per revision. This limitation requires you to select partitions, one at a time, to tap.
	Do not tap across regions in the same .stp file.	Ensures consistent interface (boundary) across all personas.
	Tap only the pre-synthesis signals. In the Node Finder, filter for Signal Tap: pre-synthesis.	Ensures that the signal tapping of PR personas start from synthesis.

PR File Management

You can simplify the management of PR personas and their corresponding source files by observing one of the following PR project file management methods.

Method 1 (Preferred): Specify Unique Entity and File Names for Each Persona

To illustrate these methods, consider a design that includes two PR regions, each with the possible apple, orange, and banana personas.

Figure 6. Example Design with Two PR Regions and Three Personas

In PR file management method 1, you specify unique entity and file name pairs for each persona in the project. For example:

Define the apple persona in the apple.sv file
Define the orange persona in the orange.sv file
Define the banana persona in the banana.sv file

Note: For successful compilation and PR operation, all personas must have the exact same port names and widths defined in each .sv file.

In the base PR revision RTL, you specify "apple" as the PR persona for both PR regions:

Figure 7. Setting the Base PR Persona to "apple"

When you set the base persona to [apple, apple] by setting u_fruit_0 and u_fruit_1 as the PR partition and regions, you can easily change the persona occupying the PR region using the Entity Rebinding (ENTITY_REBINDING) option in the Design Partitions Window, or by editing the .qsf directly, as the following examples show:

To specify the orange persona for the PR implementation (impl) revision:

set_instance_assignment -name ENTITY_REBINDING orange -to u_fruit_0
set_instance_assignment -name ENTITY_REBINDING orange -to u_fruit_1

To specify the banana persona for the PR implementation (impl) revision:

set_instance_assignment -name ENTITY_REBINDING banana -to u_fruit_0
set_instance_assignment -name ENTITY_REBINDING banana -to u_fruit_1

To specify the different personas for each PR region:

set_instance_assignment -name ENTITY_REBINDING orange -to u_fruit_0
set_instance_assignment -name ENTITY_REBINDING banana -to u_fruit_1

For each implementation revision, you must ensure that you include the corresponding source file in the project (Project > Add/Remove Files in Project).

Method 2: Parametrize a Single File as PR Persona

In PR file management method 2, you use a wrapper file and parameters to parameterize a single file that defines all personas. For example, consider the same design that method 1 describes with two PR regions, each with three possible personas for each PR region.

Figure 8. Wrapper and Parameters in Single File

In the following example, u_fruit_0 and u_fruit_1 are set as the PR partitions and regions in the base compile. The FRUIT_TYPE parameter of 0 generates the apple entity for both PR personas.

You can then change the parameter values to change the personas. For example, to specify the orange persona for both PR regions, set the FRUIT_TYPE parameter to 1:

(FRUIT_TYPE=1)

In addition to these changes to RTL, you must also follow these additional steps when using method 2 to update the .qsf:

Create a copy of your fruit.sv file. Name the file with a unique name, such as x_fruit.sv. Also rename the entity to match the .sv file.
Set the default parameter of FRUIT_TYPE to a Verilog macro, in this case, `X_FRUIT_TYPE.
Figure 9. Copy of fruit.sv Saved as x_fruit.sv
Add x_fruit.sv to the project (Project > Add/Remove Files in Project).
Specify the following in the PR implementation revision's .qsf file:
1. Add the following line to set the `X_FRUIT_TYPE Verilog macro to 1, and to specify the proper parameter for "fruit" that instantiates the correct FRUIT_TYPE:
```
set_global_assignment -name VERILOG_MACRO "X_FRUIT_TYPE=1"
```
2. Specify the entity rebinding assignment to associate the new x_fruit entity with instances of u_fruit_0 and u_fruit_1:
```
set_instance_assignment -name ENTITY_REBINDING x_fruit -to u_fruit_0
set_instance_assignment -name ENTITY_REBINDING x_fruit -to u_fruit_1
```
  These .qsf changes set orange as the new persona for both PR regions.
One downside of method 2 is that the Verilog macro set in the .qsf file is global. Therefore, every instance of `X_FRUIT_TYPE in the project defaults to a value of 1. This result may be suitable if you want both PR personas to be of the same type. However, if you want to specify “orange” for one persona and “banana” for another persona in one PR implementation compile, you must create another copy of the fruit.sv file with a unique name and Verilog macro:
Figure 10. Copy of x_fruit.sv Saved as y_fruit.sv
Specify the following in the PR implementation revision's .qsf file:
1. Add the following line to set the `X_FRUIT_TYPE Verilog macro to 1, and to specify the proper parameter for "fruit" that instantiates the correct FRUIT_TYPE:
```
set_global_assignment -name VERILOG_MACRO "X_FRUIT_TYPE=1"
set_global_assignment -name VERILOG_MACRO "Y_FRUIT_TYPE=2"
```
2. Specify the entity rebinding assignment to associate the new x_fruit entity with instances of u_fruit_0 and the new y_fruit entity with u_fruit_1:
```
set_instance_assignment -name ENTITY_REBINDING x_fruit -to u_fruit_0
set_instance_assignment -name ENTITY_REBINDING y_fruit -to u_fruit_1
```
  These .qsf changes specify orange as the persona for the first PR region, and banana as the persona for the second PR region.

Evaluating PR Region Initial Conditions

Unintended initial conditions in a PR region can lead to errors during partial reconfiguration. Your design may include unintended initial conditions, especially if you port a design not originally intended for partial reconfiguration. The Intel^® Quartus^® Prime Pro Edition software reports any initial conditions in the PR partitions for your evaluation following synthesis.

After running synthesis on an implementation partition, you can view the Registers with Explicit Power-Up Settings report for the partition to identify, locate, and correct any unintended initial conditions. The Messages window also generates a warning or error message about any initial conditions during synthesis processing. After evaluating the initial condition, you can determine whether the condition is correct for design functionality, or change the design to remove dependence on an initial condition that is incompatible with partial reconfiguration.

Figure 11. Registers with Explicit Power-Up Settings Report

Creating Wrapper Logic for PR Regions

If all personas for your design do not have identical top-level interfaces, you must create the wrapper logic to ensure that all the personas appear similar to the static region. Define a wrapper for each persona, and instantiate the persona logic within the wrapper. If all personas have identical top-level interfaces, the personas do not require wrapper logic. In this wrapper, you can create dummy ports to ensure that all the personas of a PR region have the same connection to the static region.

During the PR compilation, the Compiler converts each of the non-global ports on interfaces of the PR region into boundary port wire LUTS. The naming convention for boundary port wire LUTs are <input_port>~IPORT for input ports, and <output_port>~OPORT for output ports. For example, the instance name of the wire LUT for an input port with the name my_input, on a PR region with the name my_region, is my_region|my_input~IPORT.

Manually floorplan the boundary ports using Logic Lock region assignments, or place the boundary ports automatically using the Fitter. The Fitter places the boundary ports during the base revision compile. The boundary LUTs are invariant locations the Fitter derives from the persona you compile. These LUTs represent the boundaries between the static region and the PR routing and logic. The placement remains stationary regardless of the underlying persona, because the routing from the static logic does not vary with a different persona implementation.
To constrain all boundary ports within a given region, use a wildcard assignment. For example:
```
set_instance_assignment -name PLACE_REGION "65 59 65 85" -to \
     u_my_top|design_inst|pr_inst|pr_inputs.data_in*~IPORT
```
This assignment constrains all the wire LUTS corresponding to the IPORTS that you specify within the place region, between the coordinates (65 59) and (65 85).

Figure 12. Wire-LUTs at the PR Region Boundary

Optionally, floorplan the boundary ports down to the LAB level, or individual LUT level. To floorplan to the LAB level, create a 1x1 Logic Lock PLACE_REGION constraint (single LAB tall and a single LAB wide). Optionally, specify a range constraint by creating a Logic Lock placement region that spans the range. For more information about floorplan assignments, refer to Floorplan the Partial Reconfiguration Design.

Creating Freeze Logic for PR Regions

When partially reconfiguring a design, freeze all the outputs of each PR region to a known constant value. This freezing prevents the signal receivers in the static region from receiving undefined signals during the partial reconfiguration process.

The PR region cannot drive valid data until the partial reconfiguration process is complete, and the PR region is reset. Freezing is important for control signals that you drive from the PR region.

The freeze technique that you choose is optional, depending on the particular characteristics of your design. The freeze logic must reside in the static region of your design. A common freeze technique is to instantiate 2-to-1 multiplexers on each output of the PR region, to hold the output constant during partial reconfiguration.

Figure 13. Freeze Technique #1

An alternative freeze technique is to register all outputs of the PR region in the static region. Then, use an enable signal to hold the output of these registers constant during partial reconfiguration.

Figure 14. Freeze Technique #2

The Partial Reconfiguration Region Controller IP core includes a freeze port for the region that it controls. Include this IP component with your system-level control logic to freeze the PR region output. For designs with multiple PR regions, instantiate one PR Region Controller IP core for each PR region in the design. The Intel^® Quartus^® Prime software includes the Avalon^® -MM Freeze Bridge and Avalon^® -ST Freeze Bridge Intel^® FPGA IP cores. You can use these IP cores to implement freeze logic, or design your own freeze logic for these standard interface types.

The static region logic must be independent of all the outputs from the PR regions for a continuous operation. Control the outputs of the PR regions by adding the appropriate freeze logic for your design.

Note: There is no requirement to freeze the global and non-global inputs of a PR region for Intel^® Arria^® 10 or Intel^® Stratix^® 10 devices.

Resetting the PR Region Registers

Upon partial reconfiguration of a PR region, the status of the PR region registers become indeterminate. Bring the registers in the PR region to a known state by applying a reset sequence for the PR region. This reset ensures that the system behaves to your specifications. Simply reset the control path of the PR region, if the datapath eventually flushes out within a finite number of cycles.

Use active-high local reset instead of active-low, wherever applicable. This technique allows you to automatically hold the PR region in reset, by virtue of the boundary port wire LUT.

Supported PR Reset Implementation Guideline
PR Reset Type	Active-High Synchronous Reset	Active-High Asynchronous Reset	Active-Low Synchronous Reset	Active-Low Asynchronous Reset
On local signal	Yes	Yes	Yes	Yes
On global signal	No ( Intel^® Arria^® 10) Yes ( Intel^® Stratix^® 10)	Yes	No ( Intel^® Arria^® 10) Yes ( Intel^® Stratix^® 10)	Yes

Promoting Global Signals in a PR Region

In non-PR designs, the Intel^® Quartus^® Prime software automatically promotes high fan-out signals onto dedicated global networks. The global promotion occurs in the Plan stage of design compilation.

In PR designs, the Compiler disables global promotion for signals originating within the logic of a PR region. Instantiate the clock control blocks only in the static region, because the clock floorplan and the clock buffers must be a part of the static region of the design. Manually instantiating a clock control block in a PR region, or assigning a signal in a PR region with the GLOBAL_SIGNAL assignment, results in compilation error. To drive a signal originating from the PR region onto a global network:

Expose the signal from the PR region.
Drive the signal onto the global network from the static region.
Drive the signal back into the PR region.

You can drive a maximum of 33 clocks (for Intel^® Arria^® 10 devices) or 32 clocks (for Intel^® Stratix^® 10 devices) into any PR region, but you cannot share a row clock between two PR regions.

When promoting global signals, the Compiler allows only certain signals to be global inside the PR regions. Use only global signals to route certain secondary signals into a PR region. The following table lists the restriction for each block:

Table 3. Supported Signal Types for Driving Clock Networks in a PR Region
Block Type	Supported Global Network Signals
LAB, MLAB	Clock, ACLR, SCLR²
RAM, ROM (M20K)	Clock, ACLR, Write Enable (WE), Read Enable (RE), SCLR
DSP	Clock, ACLR, SCLR

² Only Intel^® Stratix^® 10 designs support global SCLR.

Viewing Row Clock Region Boundaries

You can use the Chip Planner to visualize the row clock region boundaries, and to ensure that no two PR regions share a row clock region.

Right-click a PR partition name in the Design Partitions Window and click Locate Node > Locate in Chip Planner.

Figure 15. Row Clock Region Boundaries in Chip Planner
In Chip Planner, click the Layers tab and select the Basic layer. The Chip Planner overlays the row clock region boundaries. Adjust the Basic layer settings to display specific items.

Planning Clocks and other Global Routing

There are special PR considerations for the planning for clocks and other global routing. For Intel^® Stratix^® 10 designs, you can use the low skew networks (globals) for clocks or resets.

During the base revision compile, you must route any global signal that any PR persona requires into a destination in the PR region. For clocks signals, this destination is a register or other synchronous element and the signal entering the clock input. For a reset, the destination should be fed into the appropriate input.

This requirement occurs because PR only reconfigures the last part of the low skew network. If you do not route the root and middle sections of the network during the base compile, you cannot use that revision for the PR.

Consider an example with a super-set of signals for a PR region that consists of:

Three clocks—clk_1, clk_2, and clk_3.
Two resets—rst_1 and rst_2.
Base PR persona—uses clk_1, clk_2, and rst_1 only.
Other personas—use clk_3 and rst_2 only.

In this example, the base persona must have a proper destination for the "unused" clk_3 and rst_2. You can accomplish this by driving a single register with a (*no prune*) directive inside the base PR persona, with clk_3 and reset using rst_2.

Omitting these destinations results in an error during compilation of the PR implementation second persona.

Implementing Clock Enable for On-Chip Memories with Initialized Contents

Follow these guidelines to implement clock enable for on-chip memories with initialized contents:

To avoid spurious writes during PR programming for memories with initialized contents, implement the clock enable circuit in the same PR region as the M20K or MLAB RAM. This circuit depends on an active-high clear signal from the static region.
Before you begin the PR programming, assert this signal to disable the memory’s clock enable. Your system PR controller must deassert the clear signal on PR programming completion. You can use the freeze signal for this purpose.
Use the Intel^® Quartus^® Prime IP Catalog or Platform Designer to instantiate the On-Chip Memory and RAM Intel^® FPGA IP cores that include an option to automatically add this circuitry.

Figure 16. RAM Clock Enable Circuit for PR Region

Verilog RTL for Clock Enable

   reg ce_reg;
    reg [1:0] ce_delay;

    always @(posedge clock, posedge freeze) begin
        if (freeze) begin
            ce_delay <= 2'b0;
        end
        else begin
            ce_delay <= {ce_delay[0], 1'b1};
        end
    end

    always @(posedge clock, negedge ce_delay[1]) begin
        if (~ce_delay[1]) begin
            ce_reg <= 1'b0;
        end
        else begin
            ce_reg <= clken_in;
        end
    end

    wire ram_wrclocken;
    assign ram_wrclocken = ce_reg;

VHDL RTL for Clock Enable

ENTITY mem_enable_vhd IS PORT(
        clock      : in  std_logic;
        freeze  : in  std_logic;
		clken_in : in std_logic;
        ram_wrclocken : out std_logic);
END mem_enable_vhd;

ARCHITECTURE behave OF mem_enable_vhd is
	SIGNAL ce_reg: std_logic;
	SIGNAL ce_delay: std_logic_vector(1 downto 0);
BEGIN
PROCESS (clock, freeze)
BEGIN
	IF ((clock'EVENT AND clock = '1') or (freeze'EVENT AND freeze = '1')) THEN
		IF (freeze = '1') THEN
			ce_delay <= "00";
		ELSE
			ce_delay <= ce_delay(0) & '1';
		END IF;
	END IF;
	
END PROCESS;

PROCESS (clock, ce_delay(1))
BEGIN
	IF ((clock'EVENT AND clock = '1') or (ce_delay(1)'EVENT AND ce_delay(1) = '0')) THEN
		IF (ce_delay(1) = '0') THEN
			ce_reg <= '0';
		ELSE
			ce_reg <= clken_in;
		END IF;
	END IF;
	
END PROCESS;

ram_wrclocken <= ce_reg;

END ARCHITECTURE behave;

Clock Gating

An alternate method to avoid spurious writes of initialized content memories is to gate the clock feeding the memories in the static region of your design. Clock gating is logically equivalent to using clock enable on the memories. This method provides the following benefits:

Uses the enable port of the global clock buffers to disable the clock before starting the partial reconfiguration operation. Also enables the clock on PR completion.
Ensures that the clock does not switch during reconfiguration, and requires no additional logic to avoid spurious writes.

Figure 17. Global Clock Control Block

Partial Reconfiguration Design Flow

The PR design flow requires initial planning. This planning involves setting up one or more design partitions, and then determining the placement assignments in the floorplan. Well-planned PR partitions improve design area utilization and performance. The Intel^® Quartus^® Prime software also allows you to create nested PR regions as part of an HPR flow. Reprogramming a child PR region does not affect the parent or the static region. In the HPR flow, reprogramming the parent region, reprograms the associated child region with the default child persona, without affecting the static region. The HPR flow does not impose any restrictions on the number of sub-partitions you can create in your design.

The PR design flow uses the project revisions feature in the Intel^® Quartus^® Prime software. Your initial design is the base revision, where you define the static region boundaries and reconfigurable regions on the FPGA. From the base revision, you create multiple revisions. These revisions contain the different implementations for the PR regions. However, all PR implementation revisions use the same top-level placement and routing results from the base revision.

Figure 18. Partial Reconfiguration Design Flow

Step 1: Identify Partial Reconfiguration Resources

When designing for partial reconfiguration, you must first determine the logical hierarchy boundaries that you can define as reconfigurable partitions. Next, set up the design hierarchy and source code to support this partitioning.

Reconfigurable partitions can contain only core resources, such as LABs, embedded memory blocks (M20Ks and MLABs), and DSP blocks in the FPGA. All periphery resources, such as transceivers, external memory interfaces, GPIOs, I/O receivers, and hard processor system (HPS), must be in the static portion of the design. Partial reconfiguration of global network buffers for clocks and resets is not possible.

Table 4. Supported Reconfiguration Methods
Hardware Resource Block	Reconfiguration Method
Logic Block	Partial reconfiguration
Digital Signal Processing	Partial reconfiguration
Memory Block	Partial reconfiguration
Core Routing	Partial reconfiguration
Transceivers/PLL	Dynamic reconfiguration
I/O Blocks	Not supported
Clock Control Blocks	Not supported

Figure 19. Available Resource Types in Intel^® Arria^® 10 Devices

Use any Intel^® Quartus^® Prime-supported design entry method to create core-only logic for a PR partition, including Platform Designer, the Intel^® HLS Compiler, or standard SystemVerilog, Verilog HDL, and VHDL design files.

The following Intel^® FPGA IP cores support system-level debugging in the static region:

In-System Memory Content Editor
In-System Sources and Probes Editor
Virtual JTAG
Nios^® II JTAG Debug Module
Signal Tap Logic Analyzer

Step 2: Create Design Partitions

Create design partitions for each PR region that you want to partially reconfigure. You can create any number of independent partitions or PR regions in your design. Create design partitions for partial reconfiguration from the Project Navigator, or the Design Partitions Window.

A design partition is only logical partitioning of the design, and does not specify a physical area on the device. You associate a partition with a specific area of the FPGA using Logic Lock Region floorplan assignments. To avoid partitions obstructing design optimization, group the logic together within the same partition. If your design includes a hierarchical PR flow with parent and child partitions, you can define multiple parent or child partitions in your design, as well as multiple levels of PR partitions.

When you create a Reconfigurable partition, the Compiler preserves post-synthesis results for the partition and reuses the post-synthesis netlist, if you make no partition changes requiring re-synthesis. Otherwise, the Compiler resynthesizes the partition from the source files. The Compiler adds wire LUTs for each interface of a Reconfigurable partition, and performs additional checks for PR compatibility.

Follow these steps to create and modify design partitions:

To elaborate the design, click Processing > Start > Start Analysis & Elaboration. You must run elaboration before creating partitions.
In the Project Navigator, right-click an instance in the Hierarchy tab, click Design Partition > Set as Design Partition. A design partition icon appears next to each partition you create.

Figure 20. Create Design Partition
To view and edit all design partitions in the project, click Assignments > Design Partitions Window.

Specify the appropriate settings for the partition in the Design Partitions Window:

Table 5. Design Partition Settings
Option	Description
Partition Name	Specifies the partition name. Each partition name must be unique and consist of only alphanumeric characters. The Intel^® Quartus^® Prime software automatically creates a top-level (`\|`) "root_partition" for each project revision.
Hierarchy Path	Specifies the hierarchy path of the entity instance that you assign to the partition. You specify this value in the Create New Partition dialog box. The root partition hierarchy path is `\|`.
Type	Double-click to specify one of the following partition types that control how the Compiler processes and implements the partition: Default—Identifies a standard partition. The Compiler processes the partition using the associated design source files. Reconfigurable—Identifies a reconfigurable partition in a partial reconfiguration flow. Specify the Reconfigurable type to preserve synthesis results, while allowing refit of the partition in the PR flow. Reserved Core—Identifies a partition in a block-based design flow that is reserved for core development by a Consumer reusing the device periphery.
Preservation Level	Specifies one of the following preservation levels for the partition: Not Set—specifies no preservation level. The partition compiles from source files. synthesized—the partition compiles using the synthesized snapshot. final—the partition compiles using the final snapshot.
Empty	Specifies an empty partition that the Compiler skips. This setting is incompatible with the Reserved Core and Partition Database File settings for the same partition. The Preservation Level must be Not Set. An empty partition cannot have any child partitions.
Partition Database File	Specifies a Partition Database File (.qdb) that the Compiler uses during compilation of the partition. You export the .qdb for the stage of compilation that you want to reuse (synthesized or final). Assign the .qdb to a partition to reuse those results in another context.
Entity Re-binding	PR Flow—specifies the entity that replaces the default persona in each implementation revision. Root Partition Reuse Flow —specifies the entity that replaces the reserved core logic in the consumer project.
Color	Specifies the color-coding of the partition in the Chip Planner and Design Partition Planner displays.
Post Synthesis Export File	Automatically exports post-synthesis compilation results for the partition to the .qdb that you specify, each time Analysis & Synthesis runs. You can automatically export any design partition that does not have a preserved parent partition, including the root_partition.
Post Final Export File	Automatically exports post-final compilation results for the partition to the .qdb that you specify, each time the final stage of the Fitter runs. You can automatically export any design partition that does not have a preserved parent partition, including the root_partition.

Figure 21. Design Partitions Window

Step 3: Floorplan the Design

Use Logic Lock floorplan constraints in your PR design to physically partition the device. Each PR partition in your design must have a corresponding, exclusive physical partition. You create Logic Lock regions to define the physical partition for your PR region. This partitioning ensures that the resources available to the PR region are the same for any persona that you implement.

Your PR region must include only core logic, such as LABs, RAMs, ROMs, and DSPs in a PR region. Intel^® Stratix^® 10 designs can also include Hyper-Registers in the PR partition. Instantiate all periphery design elements, such as transceivers, external memory interfaces, and clock networks in the static region of the design. The Logic Lock regions you create can cross periphery locations, such as the I/O columns and the HPS, because the constraint is core-only.

Figure 22. PR Region Floorplan

There are two region types:

Place regions—use these regions to constrain logic to a specific area of the device. The Fitter places the logic in the region you specify. The Fitter can also place other logic in the region unless you designate the region as Reserved.
Route regions—use these regions to constrain routing to a specific area. The routing region must fully enclose the placement region. Additionally, the routing regions for the PR regions cannot overlap.

Figure 23. Floorplanning your PR Design

Follow these guidelines when floorplanning your PR design:

Complete the periphery and clock floorplan before core floorplanning. You can use Interface Planner (Tools > Interface Planner) to create periphery floorplan assignments for your design.
Define a routing region that is at least 1 unit larger than the placement region in all directions.
Do not overlap the routing regions of multiple PR regions.
Select the PR region row-wise for least bitstream overhead. In Intel^® Arria^® 10 devices, the short, wide regions have smaller bitstream size than tall, narrow regions. Intel^® Stratix^® 10 configuration occurs on sectors. For the least bitstream overhead, ensure that you align the PR region to sectors.
For Intel^® Arria^® 10 devices, the height of your floorplan affects the reconfiguration time. A floorplan larger in the Y direction takes longer to reconfigure. This condition does not apply to Intel^® Stratix^® 10 devices because they configure according to sectors.
Define sub Logic Lock regions within PR regions to improve timing closure.
If your design includes HPR parent and child partitions, the placement region of the parent region must fully enclose the routing and placement region of its child region. Also, the parent wire LUTs must be in an area, outside the child PR region. This requirement is because the child PR region is exclusive to all other logic, which includes the parent and the static region.

Applying Floorplan Constraints Incrementally

PR implementation requires additional constraints that identify the reconfigurable partitions of the design and device. These constraints significantly impact the Compiler's timing closure ability. You can avoid and more easily correct timing closure issues by incrementally implementing each constraint, running the Compiler, then verifying timing closure.

Note: PR designs require a more constrained floorplan, compared to a flat design. The overall density and performance of a PR design may be lower than an equivalent flat design.

The following steps describe incrementally developing the requirements for your PR design:

Implement the base revision using the most complex persona for each PR partition. This initial implementation must include the complete design with all periphery constraints, and top-level .sdc timing constraints. Do not include any Logic Lock region constraints for the PR regions with this implementation.
Create partitions by setting the region Type option to Default in the Design Partitions Window, for all the PR partitions.
Register the boundaries of each partition to ensure adequate timing margin.
Verify successful timing closure using the Timing Analyzer.
Ensure that all the desired signals are driven on global networks. Disable the Auto Global Clock option in the Fitter (Assignments > Settings > Compiler Settings > Advanced Settings (Fitter)), to avoid promoting non-global signals.
Create Logic Lock core-only placement regions for each of the partitions.
Recompile the base revision with the Logic Lock constraints, and then verify timing closure.
Enable the Reserved option for each Logic Lock region to ensure the exclusive placement of the PR partitions within the placement regions. Enabling the Reserved option avoids placing the static region logic in the placement region of the PR partition.
Recompile the base revision with the Reserved constraint, and then verify timing closure.
In the Design Partitions Window, specify the Type for each of the PR partitions as Reconfigurable. This assignment ensures that the Compiler adds wire LUTs for each interface of the PR partition, and performs additional compilation checks for partial reconfiguration.
Recompile the base revision with the Reconfigurable constraint, and then verify timing closure. You can now export the top-level partition for reuse in the PR implementation compilation of the different personas.

Step 4: Add the Partial Reconfiguration Controller Intel FPGA IP

Depending on the target device family, you can add the Partial Reconfiguration Controller Intel^® Arria^® 10/Cyclone 10 FPGA IP or the Partial Reconfiguration Controller Intel^® Stratix^® 10 FPGA IP to your design to send the partial reconfiguration bitstream to the PR control block or SDM in an internal host configuration

Adding the Partial Reconfiguration Controller Intel Stratix 10 FPGA IP

You can customize and instantiate the Partial Reconfiguration Controller Intel^® Stratix^® 10 FPGA IP from the IP Catalog (Tools > IP Catalog).

The Partial Reconfiguration Controller Intel^® Stratix^® 10 FPGA IP interfaces with the Intel^® Stratix^® 10 Secure Device Manager (SDM) to manage the bitstream source. The SDM performs authentication and decompression on the configuration data. You can use this IP core in an Intel^® Stratix^® 10 design when performing partial reconfiguration with an internal PR host, Nios^® II processor, PCI Express* , or Ethernet interface.

Figure 24. Intel^® Stratix^® 10 Partial Reconfiguration Controller ( Avalon^® -ST Interface)

The Intel^® Quartus^® Prime software supports PR over the core interface using the Intel^® Stratix^® 10 PR Controller IP core, or PR over the JTAG device pins. PR over JTAG does not require instantiation of the Partial Reconfiguration Controller Intel^® Stratix^® 10 FPGA IP.

³ Avalon-MM Interface variant also available.

Adding the Partial Reconfiguration Controller Intel Arria 10/Cyclone 10 FPGA IP

The Partial Reconfiguration Controller Intel^® Arria^® 10/Cyclone 10 FPGA IP interfaces with the Intel^® Arria^® 10 or Intel^® Cyclone^® 10 GX PR control block to manage the bitstream source.

Use this IP core in Intel^® Arria^® 10 or Intel^® Cyclone^® 10 GX designs when performing partial reconfiguration with an internal PR host, Nios^® II processor, PCI Express* , or Ethernet interface.

During partial reconfiguration, you send a PR bitstream stored outside the FPGA to the PR control block inside the FPGA. This communication enables the control block to update the CRAM bits necessary for reconfiguring the PR region in the FPGA. The PR bitstream contains the instructions (opcodes) and the configuration bits necessary for reconfiguring a specific PR region.

Figure 25. Partial Reconfiguration Controller Intel^® Arria^® 10/Cyclone 10 FPGA IP

Instantiate the IP core from the Intel^® Quartus^® Prime IP Catalog (Tools > IP Catalog) to automatically connect the IP to the Intel^® Arria^® 10 or Intel^® Cyclone^® 10 GX PR control block.

If you create your own custom logic to perform the function of the IP core, manually instantiate the control block to communicate with the FPGA system.

Step 5: Define Personas

Your partial reconfiguration design can have multiple PR partitions, each with multiple personas. You define the unique function of each persona in separate Verilog HDL, SystemVerilog HDL, or VHDL design files in the project directory. All the PR personas must use the same set of signals to interact with the static region.

Ensure that the signals interacting with the static region are a super-set of all the signals in all the personas. A PR design requires an identical I/O interface for each persona in the PR region. If all personas for your design do not have identical interfaces, you must also create wrapper logic to interface with the static region.

Note: If using the Intel^® Quartus^® Prime Text Editor, disable Add file to current project when saving the files. These persona source files should not be part of the Intel^® Quartus^® Prime project or compilations.

Step 6: Create Revisions for Personas

Create a base revision for the design, as well as PR implementation revisions for each of the personas.

When you define revisions in the GUI or at the command line, the Intel^® Quartus^® Prime software automatically adds these assignments required for PR implementation:

Entity Rebinding assignment (ENTITY_REBINDING)—for each PR partition, the software adds an entity rebinding assignment with a place holder for the entity name. Your design may not require all of the entity rebinding assignments of each PR partition, based on the design and the implementation revision. For example, in HPR designs that use the default persona for the parent partition, you add the .qdb file for PR parent, and then use entity rebinding only for the child.
QDB File Partition assignment (QDB_FILE_PARTITION)—the software adds this assignment for the static region, if you specify a .qdb file name.
Revision Type Assignment (REVISION_TYPE)

To create the PR implementation revisions:

Click Project > Revisions.
To create a new revision, double-click <<new revision>>.
Specify a unique Revision name.
Select an existing revision for the Based on revision option.
For the Revision type, select Partial Reconfiguration - Base for the base revision or Partial Reconfiguration - Persona Implementation for an implementation revision.

Figure 26. Creating Revisions
Click Apply and OK.
The following assignments in the respective revision's .qsf file correspond to specifying the revision type from the Settings dialog box:

Base Revision Assignment:
```
set_global_assignment -name REVISION_TYPE PR_BASE
```
Implementation Revision Assignment:
```
set_global_assignment -name REVISION_TYPE PR_IMPL
```
For each PR partition, the Intel^® Quartus^® Prime software also adds the entity rebinding assignment to the .qsf:
```
set_instance_assignment -name ENTITY_REBINDING <entity_name> -to <hierarchical_path>
```
If you base a new implementation revision on an existing .qdb file, The Intel^® Quartus^® Prime software also adds the .qdb file partition assignment, with a place holder for the file name:
```
set_instance_assignment -name QDB_FILE_PARTITION <QDB file name>
```
As an example, to create a new implementation revision that uses a .qdb file from a base revision, use the following command:
```
create_revision impl_new -based_on <base_revision> \
     -new_rev_type impl -root_partition_qdb_file base_static.qdb
```
- impl_new—specifies the name of a new implementation revision.
- -based_on <based_on_revision> — specifies the PR base revision that the new impl revision is based on. Some global assignments from the based_on revision are copied over to the impl revision. Placeholder entity rebinding assignments are created in the impl revision for each PR partition in the base.
- -new_rev_type <rev_type>— only useful rev-type is impl.
- root_partition_qdb_file <qdb_file>—creates a QDB_FILE_PARTITION assignment in impl revision with the specified .qdb file.

Figure 27. Partial Reconfiguration Compilation Flow

Step 7: Compile the Base Revision and Export the Static Region

After defining and floorplanning PR partitions and revisions, you compile the base revision and export the static region. You can export individual design partitions manually, or you export one or more partitions automatically each time you run the Compiler.

Follow these steps to compile and export the base and static region:

To specify the current revision, click Project > Revisions, and then select the base revision as current, or select the base revision from the main toolbar drop-down list.
For Intel^® Arria^® 10 designs, you can optionally add the following assignments to the .qsf to automatically generate the required PR bitstreams following compilation. This step is not required for Intel^® Stratix^® 10 designs.
```
set_global_assignment -name GENERATE_PR_RBF_FILE ON
set_global_assignment -name ON_CHIP_BITSTREAM_DECOMPRESSION OFF
```
To compile the base revision, click Processing > Start Compilation.

To export the static region, click Project > Export Design Partition and specify options for the partition export:

Figure 28. Export Design Partition

Table 6. Design Partition Options
Option	Setting
Partition name	Select root_partition.
Partition database file	Specify a descriptive file name.
Include entity-bound SDC files	Enable to include entity bound .sdc files with the partition export.
Snapshot	Select final snapshot.

Alternatively, follow these steps to automatically export one or more design partitions after each compilation. You can automatically export any design partition that does not have a preserved parent partition, including the root_partition.
1. To open the Design Partitions Window, click Assignments > Design Partitions Window.
2. To automatically export a partition with synthesis results after each time you run synthesis, specify the a .qdb export path and file name for the Post Synthesis Export File option for that partition. If you specify only a file name without path, the file exports to the project directory after compilation.
3. To automatically export a partition with final snapshot results each time you run the Fitter, specify a .qdb file name for the Post Final Export File option for that partition.
Figure 29. Specifying Export File in Design Partitions Window

QSF File Equivalent:
```
set_instance_assignment -name \
     EXPORT_PARTITION_SNAPSHOT_<FINAL|SYNTHESIZED> \
     <hierarchy_path> -to <file_name>.qdb
```

Step 8: Setup PR Implementation Revisions

You must prepare the PR implementation revisions before you can generate the PR bitstream for device programming. This setup includes adding the static region .qdb file as the source file for each implementation revision. In addition, you must specify the corresponding entity of the PR region.

Follow these steps to setup the PR implementation revisions:

Set an implementation revision as the Current Revision.
To specify the .qdb file as the source for root_partition, click Assignments > Design Partitions Window. Double-click the Partition Database File cell and specify the appropriate .qdb file.
For each PR implementation revision, specify the name of the entity that you want to partially reconfigure in the Entity Re-binding cell. This entity name comes from the design file for the persona you want to implement in this implementation revision.

Figure 30. Design Partitions Window
To compile the design, click Processing > Start Compilation.
Repeat steps 1 through 4 to setup and compile each implementation revision. Alternatively, use a simple Tcl script to compile all implementation revisions:
```
set_current_revision <implementation1 revision name>
execute_flow -compile
set_current_revision <implementation2 revision name>
execut_flow -compile
.
.
.
```

Step 9: Program the FPGA Device

The Intel^® Quartus^® Prime Assembler generates the PR bitstreams for your design personas. For Intel^® Arria^® 10 designs, you send the bitstreams to the PR control block. For Intel^® Stratix^® 10 designs, you send the PR bitstreams to the SDM. You must compile the PR project, including the base revision, and at least one implementation revision, before generating the PR bitstreams.

For Intel^® Stratix^® 10 designs, the Assembler generates a configuration .rbf automatically at the end of compilation. For Intel^® Arria^® 10 designs, you can add the GENERATE_PR_RBF_FILE assignment to the .qsf or use the Convert Programming Files dialog box to convert the Partial-Masked SRAM Object Files (.pmsf) to an .rbf file, as Generating PR Bitstream Files describes.

Table 7. Programming Files for PR Designs
Programming File	Description
<rev>.<pr_region>.pmsf	Contains the partial-mask bits for the PR region. The .pmsf file contains all the information for creating PR bitstreams. Note: The default file name corresponds to the partition name.
<rev>.<static_region>.msf	Contains the mask bits for the static region.
<rev>.sof	Contains configuration information for the entire device.

Programming File Generation for a Partial Reconfiguration Design

Figure 31. Programming File GenerationThis example design contains a PR region and the following revisions:

Base revision with persona A
PR revision with persona B
PR revision with persona C

Generating PR Bitstream Files

For Intel^® Stratix^® 10 designs, the Assembler generates a configuration .rbf automatically at the end of compilation. For Intel^® Arria^® 10 designs, use any of the following methods to process the PR bitstreams and generate the Raw Binary File (.rbf) file for reconfiguration.

Generating PR Bitstreams During Compilation

Follow these steps to generate the .rbf file during compilation:

Add the following assignments to the revision .qsf to automatically generate the required PR bitstreams following compilation:
```
set_global_assignment -name GENERATE_PR_RBF_FILE ON
set_global_assignment -name ON_CHIP_BITSTREAM_DECOMPRESSION OFF
```
To compile the revision and generate the .rbf, click Processing > Start Compilation.

Generating PR Bitstreams with Programming File Generator

Follow these steps to generate the .rbf for PR programming with the Programming File Generator:

Click File > Programming File Generator. The Programming File Generator appears.
Specify the target Device family and the Configuration mode for partial reconfiguration.
On the Output File tab, specify the Output directory, file name, and enable the Raw Binary File for Partial Reconfiguration (.rbf) file type.
To add the input .pmsf file to convert, click the Input Files tab, click Add Bitstream, and specify the .pmsf that you generated in the Assembler.
Figure 32. Adding Bitstream File
On the Input Files tab, select the bitstream .pmsf file and click Properties. Specify any of the following options for the .rbf:
- Enable compression—generates compressed PR bitstream files to reduce file size.
- Enable encryption—generates encrypted independent bitstreams for base image and PR image. You can encrypt the PR image even if your base image has no encryption. The PR image can have a separate encryption key file (.ekp), you can also specify other Security settings.
- If you turn on Enable encryption, you must also acknowledge the Design Security Feature Disclaimer by checking the box.
  Figure 33. Design Security Feature Disclaimer
Click OK.
In Programming File Generator, click Generate. The PR bitstream files generate according to your specifications.

Generating PR Bitstreams with Convert Programming Files Dialog Box

Follow these steps to generate the .rbf with the Convert Programming Files dialog box:

Click File > Convert Programming Files. The Convert Programming Files dialog box appears.
Specify the output file name and Programming file type as Raw Binary File for Partial Reconfiguration (.rbf).
To add the input .pmsf file to convert, click Add File.
Select the newly added .pmsf file, and click Properties.
Enable or disable any of the following options and click OK:
- Compression—enables compression on PR bitstream.
- Enhanced compression—enables enhanced compression on PR bitstream.
- Generate encrypted bitstream—generates encrypted independent bitstreams for base image and PR image. You can encrypt the PR image even if your base image has no encryption. The PR image can have a separate encryption key file (.ekp). If you enable Generate encrypted bitstream, enable or disable the Enable volatile security key, Use encryption lock file, and Generate key programming file options.
Figure 34. PMSF File Properties Bitstream Encryption
Click Generate. The PR bitstream files generate according to your specifications.

Partial Reconfiguration Bitstream Compatibility Checking

Partial reconfiguration bitstream compatibility checking verifies the compatibility of the reconfiguration bitstream to prevent configuration with an incompatible PR bitstream.

Figure 35. PR Bitstream Compatibility Checking

The following sections describe PR bitstream compatibility check support for Intel^® Stratix^® 10 and Intel^® Arria^® 10 PR designs.

Intel^® Stratix^® 10 PR Bitstream Compatibility Checking

For Intel^® Stratix^® 10 designs, PR bitstream compatibility checking is automatically enabled in the Compiler and in the Intel^® Stratix^® 10 Secure Device Manager (SDM) firmware by default. The following limitations apply to PR designs if PR bitstream compatibility checking is enabled:

The Compiler allows up to 255 PR regions.
The Compiler allows up to 15 child PR regions of any parent PR region.
The Compiler allows up to six hierarchical partial reconfiguration layers.

The Compiler generates an error if your PR design exceeds these limits when PR bitstream compatibility checking is enabled.

If you require more PR regions than this limitation allows, or otherwise want to disable PR bitstream compatibility checking for Intel^® Stratix^® 10 designs, you can add the following assignment to the .qsf file:

set_global_assignment -name ENABLE_PR_POF_ID OFF

Intel^® Arria^® 10 PR Bitstream Compatibility Checking

For Intel^® Arria^® 10 designs, you enable or disable PR bitstream compatibility checking by turning on the Enable bitstream compatibility check option when instantiating the Partial Reconfiguration Controller Intel^® Arria^® 10 /Cyclone 10 FPGA IP from the IP Catalog.

The software then verifies the partial reconfiguration PR Bitstream file (.rbf). If software detects an incompatible bitstream, the PR operation stops, and the status output reports an error. The PR .pof ID encodes as the 71st word of the PR bitstream.

When you turn on Enable bitstream compatibility check, the PR Controller IP core creates a PR bitstream ID and displays the bitstream ID in the configuration dialog box.

Raw Binary Programming File Byte Sequence Transmission Examples

The raw binary programming file (.rbf) file contains the device configuration data in little-endian raw binary format. The following example shows transmitting the .rbf byte sequence 02 1B EE 01 in x32 mode:

Table 8. Writing to the PR control block or SDM in x32 modeIn x32 mode, the first byte in the file is the least significant byte of the configuration double word, and the fourth byte is the most significant byte.
Double Word = 01EE1B02
LSB: BYTE0 = 02	BYTE1 = 1B	BYTE2 = EE	MSB: BYTE3 = 01
D[7..0]	D[15..8]	D[23..16]	D[31..24]
0000 0010	0001 1011	1110 1110	0000 0001

Generating a Merged .pmsf File from Multiple .pmsf Files

Use a single merged .rbf file to reconfigure two PR regions simultaneously. To merge two or more .pmsf files:

Open the Convert Programming Files dialog box.
Specify the output file name and programming file type as Merged Partial-Mask SRAM Object File (.pmsf).
In the Input files to convert dialog box, select PMSF Data.
To add input files, click Add File. You must specify two or more files for merging.
To generate the merged file, click Generate.

Alternatively, to merge two or more .pmsf files from the Intel^® Quartus^® Prime shell, type the following command:

quartus_cpf --merge_pmsf=<number of merged files> <pmsf_input_file_1> \ 
     <pmsf_input_file_2> <pmsf_input_file_etc> <pmsf_output_file>

For example, to merge two .pmsf files, type the following command:

quartus_cpf --merge_pmsf=<2> <pmsf_input_file_1> <pmsf_input_file_2> \
     <pmsf_output_file>

Hierarchical Partial Reconfiguration

Hierarchical partial reconfiguration (HPR) is an extension of partial reconfiguration (PR), where you contain one PR region within another PR region. You can create multiple personas for both the child and parent partitions. You nest the child partitions within their parent partitions. Reconfiguring a parent partition does not impact the operation in the static region, but replaces the child partitions of the parent region with default child partition personas.

The HPR design flow includes the following steps:

Create a base revision for the design and export the static region, as Step 7: Compile the Base Revision and Export the Static Region describes.
Create the implementation revision for each persona, as Step 8: Setup PR Implementation Revisions describes, and export the parent partitions.
Specify the .qdb file partition for the static and parent regions.
Specify the corresponding entity for the parent or child.

When compiling the implementation revision for an HPR design, you must fully floorplan the child partition, similar to planning the PR region of a base revision.

Partial Reconfiguration Design Timing Analysis

The interface between partial and static partitions remains the same for each PR implementation revision. Perform timing analysis on each PR implementation revision to ensure that there are no timing violations. To ensure timing closure of a design with multiple PR regions, you can create aggregate revisions for all possible PR region combinations for timing analysis.

Note: Logic Lock regions impose placement constraints that affect the performance and resource utilization of your PR design. Ensure that the design has additional timing allowance and available device resources. Selecting the largest and most timing-critical persona as your base persona optimizes the timing closure.

Running Timing Analysis on Aggregate Revisions

To ensure timing closure of a design with multiple PR regions, you create aggregate revisions for all possible PR region combinations and run timing analysis.

To open the Revisions dialog box, click Project > Revisions.
To create a new revision, double-click <<new revision>>.
Specify the Revision name and select the base revision for Based on Revision.
To export the post-fit database from the base compile (static partition), type the following command in the Intel^® Quartus^® Prime shell:
```
quartus_cdb <project name> <base revision> --export_block \
     "root_partition" --snapshot final --file \
     "<base revision name>.qdb"
```
Note: Ensure that you include all the .sdc and .ip files for the static and PR regions. To detect the clocks, ensure that the .sdc file for the PR Controller IP follows the entry of any .sdc file that creates the clocks that the IP core uses. You facilitate this order by ensuring the .ip file for the PR Controller IP comes after any .ip or .sdc files that you use to create these clocks in the .qsf file for the project revision. Refer to Partial Reconfiguration Solutions IP User Guide for more information.

To export the post-fit database from multiple personas (for the PR implementation revisions), type the following commands in the Intel^® Quartus^® Prime shell:

quartus_cdb <project name> -c <PR1 revision> --export_block \
     <PR1 Partition name> --snapshot final --file "pr1.qdb"
quartus_cdb <project name> -c <PR2 revision> --export_block \
     <PR2 Partition name> --snapshot final --file "pr2.qdb"

To import the post-fit databases of the static region as an aggregate revision, type the following commands in the Intel^® Quartus^® Prime shell:

quartus_cdb <project name> -c <aggr_rev> --import_block \
     "root_partition" --file "<base revision name>.qdb"
quartus_cdb <project name> -c <aggr_rev> --import_block \
     <PR1 partition name> --file "pr1.qdb" 
quartus_cdb <project name> -c <aggr_rev> --import_block \
     <PR2 Partition name> --file "pr2.qdb"

To integrate post-fit database of all the partitions, type the following command in the Intel^® Quartus^® Prime shell:
```
quartus_fit <project name> -c <aggr_rev>
```
Note: The Fitter verifies the legality of the post-fit database, and combines the netlist for timing analysis. The Fitter does not reroute the design.
To perform timing analysis on the aggregate revision, type the following command in the Intel^® Quartus^® Prime shell:
```
quartus_sta <proj name> -c <aggr_rev>
```
Run timing analysis on aggregate revision for all possible PR persona combinations. If a specific persona fails timing closure, recompile the persona and perform timing analysis again.

Partial Reconfiguration Design Simulation

Simulation verifies the behavior of your design before device programming. The Intel^® Quartus^® Prime Pro Edition software supports simulating the delivery of a partial reconfiguration bitstream to the PR control block. This simulation allows you to observe the resulting change and the intermediate effect in a reconfigurable partition.

Similar to non-PR design simulations, preparing for a PR simulation involves setting up your simulator working environment, compiling simulation model libraries, and running your simulation. The Intel^® Quartus^® Prime software provides simulation components to help simulate a PR design, and can generate the gate-level PR simulation models for each persona. Use either the behavioral RTL or the gate-level PR simulation model for simulation of the PR personas. The gate-level PR simulation model allows for accurate simulation of registers in your design, and reset sequence verification. These technology-mapped registers do not assume initial conditions.

Partial Reconfiguration Simulation Flow

At a high-level, a PR operation consists of the following steps:

System-level preparation for a PR event.
Retrieval of the partial bitstream from memory.
Transmission of the partial bitstream to the Intel^® Arria^® 10 PR control block or Intel^® Stratix^® 10 SDM.
Resulting change in the design as a new persona becomes active.
Post-PR system coordination.
Use of the new persona in the system.

You can simulate each of these process steps in isolation, or as a larger sequence depending on your verification type requirement.

Simulating PR Persona Replacement

The logical operation of the PR partition changes when a new persona loads during the partial reconfiguration process. Simulate the replacement of personas using multiplexers on the input and output of the persona under simulation. Create RTL wrapper logic to represent the top-level of the persona. The wrapper instantiates the default persona during compilation. During simulation, the wrapper allows the replacement of the active persona with another persona. Instantiate each persona as the behavioral RTL in the PR simulation model the Intel^® Quartus^® Prime EDA Netlist Writer generates. The Intel^® Quartus^® Prime software includes simulation modules to interface with your simulation testbench:

altera_pr_wrapper_mux_in
altera_pr_wrapper_mux_out
altera_pr_persona_if (SystemVerilog interface allows you to connect the wrapper multiplexers to a testbench driver)

Figure 36. Simulation of PR Persona Switching

RTL Wrapper for PR Persona Switching Simulation

The pr_activate input of the altera_pr_wrapper_mux_out module enables the MUX to output X. This functionality allows the simulation of unknown outputs from the PR persona, and also verifies the normal operation of the design’s freeze logic. The following code corresponds to the simulation of PR persona switching, shown in the above figure:

module pr_core_wrapper
(
   input wire a,
   input wire b,
   output wire o
);

localparam ENABLE_PERSONA_1 = 1;
localparam ENABLE_PERSONA_2 = 1;
localparam ENABLE_PERSONA_3 = 1;
localparam NUM_PERSONA = 3;

logic pr_activate;
int persona_select;

altera_pr_persona_if persona_bfm();
assign pr_activate = persona_bfm.pr_activate;
assign persona_select = persona_bfm.persona_select;


wire a_mux [NUM_PERSONA-1:0];
wire b_mux [NUM_PERSONA-1:0];
wire o_mux [NUM_PERSONA-1:0];

generate
   if (ENABLE_PERSONA_1) begin
      localparam persona_id = 0;

      `ifdef ALTERA_ENABLE_PR_MODEL
         assign u_persona_0.altera_sim_pr_activate = pr_activate;
      `endif

      pr_and u_persona_0
      (
         .a(a_mux[persona_id]),
         .b(b_mux[persona_id]),
         .o(o_mux[persona_id])
      );
   end
endgenerate

generate
   if (ENABLE_PERSONA_2) begin
      localparam persona_id = 1;

      `ifdef ALTERA_ENABLE_PR_MODEL
         assign u_persona_1.altera_sim_pr_activate = pr_activate;
      `endif

      pr_or u_persona_1
      (
         .a(a_mux[persona_id]),
         .b(b_mux[persona_id]),
         .o(o_mux[persona_id])
      );

   end
endgenerate

generate
   if (ENABLE_PERSONA_3) begin
      localparam persona_id = 2;

      `ifdef ALTERA ENABLE PR MODEL
         assign u_persona_2.altera_sim_pr_activate = pr_activate;
      `endif

      pr_empty u_persona_2
      (
         .a(a_mux[persona_id]),
         .b(b_mux[persona_id]),
         .o(o_mux[persona_id])
      );

   end
endgenerate


altera_pr_wrapper_mux_in #(.NUM_PERSONA(NUM_PERSONA), .WIDTH(1)) \
     u_a_mux(.sel(persona_select), .mux_in(a), .mux_out(a_mux));

altera_pr_wrapper_mux_in #(.NUM_PERSONA(NUM_PERSONA), .WIDTH(1)) \
     u_b_mux(.sel(persona_select), .mux_in(b), .mux_out(b_mux));

altera_pr_wrapper_mux_out #(.NUM_PERSONA(NUM_PERSONA), .WIDTH(1)) \
     u_o_mux(.sel(persona_select), .mux_in(o_mux), .mux_out(o), .pr_activate \
     (pr_activate));

endmodule

altera_pr_persona_if Module

Instantiate the altera_pr_persona_if SystemVerilog interface in a PR region simulation wrapper to connect to all the wrapper multiplexers. Optionally, connect pr_activate to the PR simulation model.

Connect the interface’s persona_select to the sel port of all input and output multiplexers. Connect the pr_activate to the pr_activate of all the output multiplexers. Optionally, connect the report events to the report event ports of the PR simulation model. Then, the PR region driver testbench component can drive the interface.

interface altera_pr_persona_if;
   logic pr_activate;
   int   persona_select;
   
   event report_storage_if_x_event;
   event report_storage_if_1_event;
   event report_storage_if_0_event;
   event report_storage_event;
   
   initial begin
      pr_activate <= 1'b0;
   end
endinterface : altera_pr_persona_if

The <QUARTUS_INSTALL_DIR> /eda/sim_lib/altera_lnsim.sv file defines the altera_pr_persona_if component.

altera_pr_wrapper_mux_out Module

The altera_pr_wrapper_mux_out module allows you to multiplex the outputs of all PR personas to the outputs of the PR region wrapper.

Instantiate one multiplexer per output port. Specify the active persona using the sel port of the multiplexer. The pr_activate port allows you to drive the multiplexer output to “x”, to emulate the unknown value of PR region outputs during a PR operation. Parameterize the component to specify the number of persona inputs, the multiplexer width, and the MUX output value when pr_activate asserts.

module altera_pr_wrapper_mux_out #(
   parameter NUM_PERSONA = 1,
   parameter WIDTH = 1,
   parameter [0:0] DISABLED_OUTPUT_VAL = 1'bx
) (
   input int sel,
   input wire [WIDTH-1 : 0] mux_in [NUM_PERSONA-1:0],
   output reg [WIDTH-1:0]   mux_out,
   input wire               pr_activate
);
 
   always_comb begin
      if ((sel < NUM_PERSONA) && (!pr_activate))
         mux_out = mux_in[sel];
      else
         mux_out = {WIDTH{DISABLED_OUTPUT_VAL}};
   end
 
endmodule : altera_pr_wrapper_mux_out

The <QUARTUS_INSTALL_DIR> /eda/sim_lib/altera_lnsim.sv file defines the altera_pr_wrapper_mux_out component.

altera_pr_wrapper_mux_in Module

The altera_pr_wrapper_mux_in module allows you to de-multiplex inputs to a PR partition wrapper for all PR personas.

Instantiate one multiplexer per input port. Specify the active persona using the sel port of the multiplexer. Parameterize the component to specify the number of persona outputs, the multiplexer width, and the MUX output for any disabled output. When using the altera_pr_wrapper_mux_in to mux a clock input, use the DISABLED_OUTPUT_VAL of 0, to ensure there are no simulation clock events of the disabled personas.

module altera_pr_wrapper_mux_in#(
   parameter NUM_PERSONA = 1,
   parameter WIDTH = 1,
   parameter [0:0] DISABLED_OUTPUT_VAL = 1'bx
) (
    
   input int sel,
   input wire [WIDTH-1:0] mux_in,
   output reg [WIDTH-1 : 0] mux_out [NUM_PERSONA-1:0]
);
   always_comb begin
      for (int i = 0; i < NUM_PERSONA; i++)
         if (i == sel)
            mux_out[i] = mux_in;
         else
            mux_out[i] = {WIDTH{DISABLED_OUTPUT_VAL}};
   end
 
    
endmodule : altera_pr_wrapper_mux_in

The <QUARTUS_INSTALL_DIR> /eda/sim_lib/altera_lnsim.sv file defines the altera_pr_wrapper_mux_in component.

Partial Reconfiguration Design Debugging

The Signal Tap logic analyzer allows you to debug static or PR regions of a design. If you only want to debug the static region, you can use the In-System Sources and Probes Editor, In-System Memory Content Editor, or JTAG Avalon Master Bridge.

Debugging PR Designs with Signal Tap Logic Analyzer

To use the Signal Tap logic analyzer to debug PR designs, you must create a debug bridge to extend Signal Tap debugging into the PR partition. You can then use Signal Tap to debug by connecting to the debug bridge. To use the debug bridge, you instantiate the SLD JTAG Bridge Agent Intel^® FPGA IP and SLD JTAG Bridge Host pair for each PR region in your design.

Perform the following steps during the early planning stage, to ensure you can use Signal Tap to debug your static as well as PR region:

Instantiate the SLD JTAG Bridge Agent IP in the static region.
Instantiate the SLD JTAG Bridge Host IP in the PR region of the default persona.
Instantiate the SLD JTAG Bridge Host IP for each of the personas when creating revisions for the personas.

The Signal Tap logic analyzer uses the hierarchical debug capabilities provided by Intel^® Quartus^® Prime software to tap signals in the static and PR regions simultaneously.

You can debug multiple personas present in your PR region, as well as multiple PR regions. For complete information on the debug infrastructure using hierarchical hubs, refer to Intel Quartus Prime Pro Edition User Guide: Debug Tools.

PR Bitstream Security Verification ( Intel Stratix 10 Designs)

Intel^® Stratix^® 10 devices support optional PR bitstream security verification to confirm that a PR region persona contains no threats to platform integrity or confidentiality before loading that persona into the FPGA.

When you license and enable PR bitstream security verification, the Programmer performs bit ownership, signals peek, poke, and contention checks prior to PR bitstream generation. If the Programmer cannot verify the PR persona.pmsf file against the Secure Mask Settings file (.smsf), PR bitstream generation terminates.

Note: PR bitstream security verification only supports Intel^® Stratix^® 10 devices and requires a separate license and .qsf setting to enable, as Using PR Bitstream Security Verification ( Intel Stratix 10 Designs) describes.

PR bitstream security verification enables multi-tenant FPGA usage, such as when a Platform Owner partitions a single device to host multiple third-party Clients. The Platform Owner may not trust the Clients, and the Clients may not trust each other, but the Clients trust the Platform Owner. PR bitstream security verification provides the Platform Owner and Clients protection from any party corrupting the proprietary server, Client configurations, or from initiating a peek or poke attack by a subsequent partial reconfiguration.

In such multi-tenant scenarios, PR bitstream security verification can protect against the following known threats:

Changing bits in an PR region owned by another party—a PR persona can potentially inject a change in functionality to another client’s persona and cause DOS or PDOS attack, cause an unintended function, or redirect a signal from the unowned persona.
Poke Attack—a PR persona can potentially corrupt other PR regions input data by poking on its wires.
Peek Attack—a PR persona can potentially view values on routing wires from other PR regions to snoop on their data.
Excessive Power Consumption—PR personas can potentially cause excessive FPGA power consumption due to wire contention inside the PR region.

PR Bitstream Security Use Case ( Intel Stratix 10 Designs)

In a typical use case, PR bitstream security validation allows a Platform Owner to verify a Client's third-party IP design to ensure that it contains no known threats to platform integrity and confidentiality before that PR persona can be loaded into an FPGA during partial reconfiguration. This validation is critical for Cloud Service Providers and system integrators.

A Cloud Service Provider partitions the FPGA into various PR regions to host multiple third-party clients. The Cloud Service Provider uses this partitioned design for the base device configuration. After the base configuration loads on the device, PR bitstream security allows only verified PR region persona to load into the corresponding PR region.

Figure 37. Multi-Tenancy Bitstream Security Validation

Using PR Bitstream Security Verification ( Intel Stratix 10 Designs)

PR bitstream security verification requires a separate license and .qsf setting to enable. After you license and enable PR bitstream verification, the Compiler generates both a public Secure Mask Settings File (.smsf) and private Partially Masked Settings File (.pmsf) for each PR region during the base compilation.

The .pmsf contains comprehensive information that the Programmer requires to generate the PR bitstream for a Client region, including the actual bit settings, a region mask, and all the auxiliary bit masks. The .smsf contains a region ownership mask and comprehensive information to detect a peek or poke attack by the PR region’s persona.

Thereafter, the Programmer requires both the private .pmsf and public .smsf to generate the PR bitstream for this PR region, ensuring that the PR persona can only change bits that the persona owns. The Platform Owner may or may not release .smsf files to third-party Clients as part of the PR region collateral. The Platform Owner uses the .smsf to generate the PR bitstream from Client's .pmsf for this PR region with the Programmer.

PR Bitstream Security Validation in Programmer

Follow these steps to license, enable, and use PR bitstream security verification:

Obtain the license file to enable generation of .smsf files for PR regions during base compilation, and to perform PR bitstream security verification during PR bitstream generation in the Programmer. To obtain the license, login or register for a My-Intel account, and then submit an Intel^® Premier Support case requesting the license key.
To add the license file to the Intel^® Quartus^® Prime Pro Edition software, click Tools > License Setup and specify the feature License File.
To enable PR security validation features, add the following line to the project .qsf:
```
set_global_assignment -name PR_SECURITY_VALIDATION on
```
Compile the base revision, as link/tnc1513987819990/aqm1467953816118 describes.
Following base compilation, view the Assembler reports to view the generated .smsf files required for bitstream generation for each PR region.
The Platform Owner may release .smsf files to third-party clients as part of the PR region collateral. The Client provides the private .pmsf to the Platform Owner to verify PR security of the PR Persona configuration and generate validated PR bitstream.
To validate PR security of Client's .pmsf, the Platform Owner specifies the .smsf and corresponding .pmsf files at the Programmer command line to generate the validated PR bitstreams:
```
quartus_cpf -c –-smsf=<smsf_file> <pmsf_file> <output_file>
```

PR Bitstream Compression and Encryption ( Intel Arria 10 Designs)

You can compress and encrypt the base bitstream and the PR bitstream for your PR project using options available in the Intel^® Quartus^® Prime software.

Compress the base and PR programming bitstreams independently, based on your design requirements. When encrypting only the base image, specify whether or not to encrypt the PR images. The following guidelines apply to PR bitstream compression and encryption:

You can encrypt the base and PR image independently. In addition, you can use different encryption keys in each case, For example, you can use a non-volatile encryption key for the base image, and a volatile encryption key for the PR image.
Refer to Table 9 to ensure the correct Clock-to-Data (CD) ratio setting for encryption or compression.

For partial reconfiguration with the PR Controller IP core, specify enhanced compression by turning on the Enhanced compression option when specifying the parameters in the IP Catalog or Platform Designer parameter editors.

Note: You cannot use hardware or enhanced compression together with encryption simultaneously.

Generating an Encrypted PR Bitstream

To partially reconfigure your Intel^® Arria^® 10 device with an encrypted bitstream:

Note: Intel^® Quartus^® Prime software does not support bitstream encryption and compression for Intel^® Stratix^® 10 designs.

Create a 256-bit key file (.key).

To generate the key programming file (.ekp) from the Intel^® Quartus^® Prime shell, type the following command:

quartus_cpf --key <keyfile>:<keyid> \
     <base_sof_file> <output_ekp_file>

For example:

quartus_cpf --key my_key.key:key1 base.sof key.ekp

To generate the encrypted PR bitstream (.rbf), run the following command:

quartus_cpf -c <pr_pmsf_file> <pr_rbf_file>
qcrypt -e --keyfile=<keyfile> --keyname=<keyid> –lockto=\
     <qlk file> --keystore=<battery|OTP> \
     <pr_rbf_file> <pr_encrypted_rbf_file>

lockto—specifies the encryption lock.
keystore—specifies the volatile key (battery) or the non-volatile key (OTP).

For example:

quartus_cpf -c top_v1.pr_region.pmsf top_v1.pr_region.rbf \
     qcrypt -e --keyfile=my_key.key --keyname=key1 --keystore=battery \
     top_v1.pr_region.rbf top_v1_encrypted.rbf

To program the key file as volatile key (default) into the device, type the following command:
```
quartus_pgm -m jtag -o P;<output_ekp_file>
```
For example:
```
quartus_pgm -m jtag -o P;key.ekp
```
To program the base image into the device, type the following command:
```
quartus_pgm -m jtag -o P;<base_sof_file>
```
For example:
```
quartus_pgm -m jtag -o P;base.sof
```
To partially reconfigure the device with the encrypted bitstream, type the following command:
```
quartus_pgm -m jtag --pr <output_encrypted_rbf_file>
```
For example:
```
quartus_pgm -m jtag --pr top_v1_encrypted.rbf
```

Note:

qcrypt generates an error if the Enable bitstream compatibility check parameter is enabled for an instance of the Partial Reconfiguration Controller Intel^® Arria^® 10 FPGA IP. Use one of the following methods to avoid this error:

Use the Convert Programming Files dialog box, rather than qcrypt, to generate the encrypted PR bitstream, as Generating PR Bitstream Files describes.
If you want use qcrypt with Intel^® Arria^® 10 designs, regenerate the Partial Reconfiguration Controller IP without the Enable bitstream compatibility check option enabled, and with the Enable hierarchical PR support option enabled, as Adding the Partial Reconfiguration Controller Intel^® Arria^® 10/Cyclone 10 FPGA IP describes. Recompile the design before regenerating the PR bitstream.

Clock-to-Data Ratio for Bitstream Encryption and Compression

The following table lists the valid combinations of bitstream encryption and compression. The Clock-to-Data (CD) ratio is defined as the number of clock cycles that each cycle of data must remain valid before the next clock cycle. For example, a CD ratio of 4 means that the data must remain valid for 4 clock cycles before the next cycle. Enhanced decompression uses the same CD ratio as plain bitstreams (that is, with both encryption and compression off). When enhanced compression is enabled, always refer to x16 data width. If you use compression and enhanced compression together, the CD ratio follows the compression bitstream - 4. If you use plain and enhanced compression together, the CD ratio follows the plain bitstream - 1.

Table 9. Valid Combinations and CD Ratio for Bitstream Encryption and Compression
Configuration Data Width	AES Encryption	Basic Compression	CD Ratio
`x8`	Off	Off	1
	Off	On	2
	On	Off	1
`x16`	Off	Off	1
	Off	On	4
	On	Off	2
`x32`	Off	Off	1
	Off	On	8
	On	Off	4

Use the exact CD ratio that the Valid combinations and CD Ratio for Bitstream Encryption and Compression table specifies for different bitstream types. The CD ratio for plain .rbf must be 1. The CD ratio for compressed .rbf must be 2, 4 or 8, depending on the width. Do not specify the CD ratio as the necessary minimum to support different bitstream types.

Note: Intel^® Quartus^® Prime software does not support both bitstream encryption and compression for Intel^® Stratix^® 10 designs.

Data Compression Comparison

Standard compression results in a 30-45% decrease in .rbf size. Use of the enhanced data compression algorithm results in 55-75% decrease in .rbf size. The algorithm increases the compression at the expense of additional core area required to implement the compression algorithm.

The following figure shows the compression ratio comparison across PR designs with varying degrees of Logic Element (LE):

Figure 38. Compression Ratio Comparison between Standard Compression and Enhanced Compression

Avoiding PR Programming Errors

You can use the following guidelines to avoid or resolve common PR programming errors.

Table 10. PR Programming Guidelines
PR Programming Guideline	Description
Device in project must match device on board	Confirm the target FPGA device that you specify for the project matches the device on the development kit you target. These two devices must be the same. Click Assignments > Device to view the target device.
Programmer versions must match	When using the Intel^® Quartus^® Prime Programmer for PR programming, confirm that the Programmer version matches the Intel^® Quartus^® Prime version that you use for compilation. A mismatch between the Programmer and Intel^® Quartus^® Prime software version can occur if you compile on one machine, and then program on a different machine with a different Intel^® Quartus^® Prime version. The software version match is especially critical for Intel^® Stratix^® 10 designs, because the Intel^® Stratix^® 10 PR configuration hardware has dependencies inside the Programmer.
Specify a lower JTAG clock frequency	Lower the JTAG clock frequency to 6MHz: In the Programmer window, click Hardware Setup, and then select Intel^® FPGA Download Cable II as the programming hardware. For the Hardware frequency, specify a value from 24000000 (24MHz) to 6000000 (6MHz).
Close timing for all revisions	Confirm that each project revision closes timing after design compilation: In the Compilation Report, expand the Timing Analyzer > Slow 900mV 100C Model folders, and then view the Setup Summary, Hold Summary, Recovery Summary, Removal Summary, and Minimum Pulse Width Summary reports. In each report, verify that there are no timing violations indicated by a negative Slack value in the report. Repeat step 1 to verify timing closure in the Slow 900mV 0C Model, the Fast 900mV 100C Model, and the Fast 900mV 0C Model. The design closes timing when there are no negative Slack values for any clock in the report. Repeat steps 1 and 2 for each project revision in the PR design.

Note: If an error occurs during PR operation for Intel^® Stratix^® 10 designs using Single Event Upset (SEU) detection, the PR region is frozen, becomes non-functional, and SEU disables for all sectors the PR region covers. The Avalon^® -ST status interface or the Avalon^® -MM register map of the Partial Reconfiguration Controller Intel^® Stratix^® 10 FPGA IP reflects this error status. To resolve this error and restore the SEU detection, perform another PR operation to reload a valid PR bitstream.

Migrating PR Regions to a Later Software Version

You can migrate the static region of a PR design to a later version of the Intel^® Quartus^® Prime Pro Edition software, and then compile the PR regions in the later version, without recompiling the static region. This technique is helpful when you want to change the content for one or more PR regions, and generate the PR bitstreams for the implementation revision with a later version of Intel^® Quartus^® Prime Pro Edition software.

Note: The Intel^® Quartus^® Prime Pro Edition software version 19.1 supports migration of PR regions from the following software versions and devices:

PR Region Migration Device and Software Version Support
Intel^® Quartus^® Prime Pro Edition Software Export Versions	Intel^® Quartus^® Prime Pro Edition Software Import Version	Intel^® Stratix^® 10 Devices	Intel^® Arria^® 10 Devices
18.0	19.1	No Support.	Supports all Intel^® Arria^® 10 devices.
18.1	19.1	1SG250L 1SG280H_S2 1SG280L 1SG280L_S3 1SX250L 1SX280L 1SX280L_S3 ND5REVB	Supports all Intel^® Arria^® 10 devices.

The following topics describe each use case and the steps in the PR region migration flow:

Static Region Migration with a Single PR Region

PR Migration Scenario

In migration of the static region with a single PR region, you compile the static region of the PR design in the Intel^® Quartus^® Prime software version N, and then compile the PR region in a later Intel^® Quartus^® Prime software version (N+m).

Figure 39. Static Region Migration (Single PR Region Compiled in Later Version)

PR Migration Requirements

You must compile all personas with the same version of the Intel^® Quartus^® Prime software.

Static Region Migration with Multiple PR Regions

PR Migration Scenario

In migration of the static region with multiple PR regions, you compile the static region of the PR design in the Intel^® Quartus^® Prime software version N, and then compile all of the PR regions in a later Intel^® Quartus^® Prime software version (N+m).

Figure 40. Static Region Migration (Multiple PR Regions Compiled in Later Version)

PR Migration Requirements

You must compile all PR personas with the same version of the Intel^® Quartus^® Prime software.

Static Region Migration with Single HPR Parent

PR Migration Scenario

In migration with a single hierarchical partial reconfiguration (HPR) parent region, you compile the static region of the design in the Intel^® Quartus^® Prime software version N, and then compile all of the parent and child HPR regions in a later Intel^® Quartus^® Prime software version (N+m).

Figure 41. Static Region Migration (HPR Parent and Child Regions Compiled in Later Version)

Note: all the HPR parents should be compiled with the same Quartus version.

PR Migration Scenario

You can have multiple HPR parents without limitation; however, you must compile all personas of the HPR and PR regions with the same version of the Intel^® Quartus^® Prime software.

Static Region Migration with SUPR Designs

PR Migration Scenario

In static region migration for static update partial reconfiguration (SUPR) designs, you compile the static region of the design in the Intel^® Quartus^® Prime software version N, and then compile all of the PR and SUPR regions in a later Intel^® Quartus^® Prime software version (N+m).

Figure 42. Static Region Migration (PR and SUPR Regions Compiled in Later Version)

PR Migration Requirements

You must compile all personas of the PR and SUPR regions with the same version of the Intel^® Quartus^® Prime software.

PR Migration Flow

Follow these steps for migration of the static region with PR, HPR, and SUPR designs:

Add the following line to the Intel^® Quartus^® Prime software version N quartus.ini file:
```
qhd_enable_pr_bak_export=on
```
Export the entire compiled design from the Intel^® Quartus^® Prime software version N by clicking Project > Export Design, or by command line:
```
quartus_cdb <base_revision> --export_design --snapshot final \
     --file <base_revision>.qdb
```
Import the compiled design to Intel^® Quartus^® Prime software version N+m by clicking Project > Import Design, or by command line:
```
quartus_cdb <base_proj> --import_design --file <base_BAK>.qdb
```
Note: Whenever possible, import the design into a different working directory than you use to compile the base design. If you must use the same directory for import and for compiling and the base design, make a backup copy of your compiled design by archiving that design with qdb/* included, or make a copy of the entire directory and subdirectories on disc. You must also remove the old database directory qdb/* and all the bitstream related files (*.sof *.msf *.pmsf).
Rerun the finalize stage of the Fitter in Intel^® Quartus^® Prime Pro Edition software version N+m by clicking Processing > Start > Start Fitter (Finalize), or by command line:
```
quartus_fit <base_revision> --finalize
```
Run the Assembler in Intel^® Quartus^® Prime Pro Edition software version N+m to regenerate the blue bitstream by clicking Processing > Start > Start Assembler, or by command line:
```
quartus_asm <base_revision>
```
Export the static region .qdb in Intel^® Quartus^® Prime Pro Edition software version N+m by clicking Project > Export Design Partition, or by command line:
```
quartus_cdb <base_prj> --export_block root_partition \
     --snapshot final --file <static.qdb>
```
Run compilation on each implementation revision in Intel^® Quartus^® Prime Pro Edition software version N+m, using the static revision .qdb that you export in the previous step.
```
quartus_sh –flow compile <project_name> –c <impl_rev> 
```

Creating a Partial Reconfiguration Design Revision History

Document Version	Intel^® Quartus^® Prime Version	Changes
2019.04.22	19.1.0	Indicated support for POF generation support for Intel Cyclone GX devices. Corrected code example in "PR Migration Flow" topic.
2019.04.01	19.1.0	Described migration of the static region of a PR design to a later version of the Intel^® Quartus^® Prime software. Described new "PR Bitstream Security Validation" feature. Described new location of auto export from output_files to project directory.
2018.12.30	18.1.1	Described "Partial Reconfiguration Bitstream Compatibility Check" and PR region limitations.
2018.10.24	18.1.0	Added "PR File Management" topic. Updated first guideline in "Partial Reconfiguration Design Guidelines."
2018.09.24	18.1.0	Described automated .qdb partition export in "Exporting a Design Partition." Added details about required assignments to "Step 6: Create Revisions for Personas." Removed references to placed snapshot. Only synthesized and final snapshots are supported. Corrected description of Entity Re-binding option in Design Partition Settings table. Added command line instructions for creating a revision. Stated PR compilation flow support for Intel^® Cyclone^® 10 GX devices. Updated Partial Reconfiguration Controller Intel^® Arria^® 10 FPGA IP name to Partial Reconfiguration Controller Intel^® Arria^® 10/Cyclone 10 FPGA IP. Added "Viewing Row Clock Region Boundaries." Added "Planning Clocks and other Global Routing."
2018.07.18	18.0.0	Corrected signals in Simulation of PR Persona Switching diagram.
2018.06.18	18.0.0	Corrected syntax errors and added note in Running Timing Analysis on Aggregate Revisions.
2018.05.29	18.0.0	Added description of "\|" that identifies the root partition hierarchy path in Design Partitions Window. Clarified .qsf assignment in Running Timing Analysis on Aggregate Revisions.
2018.05.07	18.0.0	Added description of new Partial Reconfiguration External Configuration Controller Intel^® Stratix^® 10 FPGA IP. Removed descriptions of obsolete synthesis-only revisions and corresponding personas. Replaced with latest simplified flow instructions. Updated names of Partial Reconfiguration Controller Intel^® Arria^® 10 FPGA IP and Partial Reconfiguration Controller Intel^® Stratix^® 10 FPGA IP. Added Design Partition Settings topic. Added Evaluating PR Partition Initial Conditions topic. Added Avoiding PR Programming Errors topic. Described qcrypt incompatibility with Enable bitstream compatibility check and workaround. Added as chapter in new Partial Reconfiguration User Guide. Updated command-line syntax in Running Timing Analysis on Aggregate Revisions topic. Removed obsolete HPR flow script information and linked to AN826: Hierarchical Partial Reconfiguration Tutorial for Intel Stratix 10 GX FPGA Development Board Added note about recovery after PR error when using SEU detection in Intel^® Stratix^® 10 designs.
2017.11.06	17.1.0	Added partial reconfiguration support for Intel^® Stratix^® 10 devices. Added descriptions of Intel^® Stratix^® 10 Partial Reconfiguration Controller IP, SUPR, HPR, and SDM to terms list. Updated for latest Intel^® branding and software user interface.
2017.05.08	17.0.0	Added information about Hierarchical Partial Reconfiguration. Added new topic Partial Reconfiguration Simulation and Verification. Added new topic 'Run Timing Analysis on a Design with Multiple PR Partitions'. Updated Freeze Logic for PR Regions. Added new topic Debugging Using Signal Tap Logic Analyzer. Other minor updates.
10.31.2016	16.1.0	Initial release.

Partial Reconfiguration Solutions IP User Guide

The Intel^® Quartus^® Prime Pro Edition software includes the following Intel^® FPGA IP cores that simplify partial reconfiguration implementation.

Instantiate one or more of these IP cores to implement handshake and freeze logic for PR functionality in your design. Alternatively, create your own PR handshake and freeze logic that interfaces with the PR region.

Table 11. Partial Reconfiguration IP Cores
Intel^® FPGA IP	Description	Usage
Partial Reconfiguration Controller Intel^® Stratix^® 10 FPGA IP	Dedicated IP component that sends the partial reconfiguration bitstream for the Intel^® Stratix^® 10 FPGA. The PR bitstream performs reconfiguration by adjusting CRAM bits in the FPGA.	One instance per FPGA
Partial Reconfiguration External Configuration Controller Intel^® Stratix^® 10 FPGA IP	IP component that supports Intel^® Stratix^® 10 FPGA partial reconfiguration via an external source over dedicated PR pins.	One instance per FPGA for external configuration
Partial Reconfiguration Controller Intel^® Arria^® 10/Cyclone 10 FPGA IP	Dedicated IP component that sends the partial reconfiguration bitstream to the Intel^® Arria^® 10 or Intel^® Cyclone^® 10 GX FPGA. The PR bitstream performs reconfiguration by adjusting CRAM bits in the FPGA.	One instance per FPGA, internal or external configuration.
Partial Reconfiguration Region Controller Intel^® FPGA IP	Provides a standard Avalon^® Memory Mapped ( Avalon^® -MM) interface to the block that controls handshaking with the PR region. Ensures that PR region stops, resets, and restarts, according to the PR handshake.	One instance per PR region.
Avalon-MM Partial Reconfiguration Freeze Bridge Intel^® FPGA IP	Provides freeze capabilities to the PR region for Avalon^® -MM interfaces.	One instance for each interface in each PR region.
Avalon-ST Partial Reconfiguration Freeze Bridge Intel^® FPGA IP	Provides freeze capabilities to the PR region for Avalon^® Streaming ( Avalon^® -ST) interfaces.	One instance for each interface in each PR region.

Internal and External PR Host Configurations

You perform PR with either an internal host residing in the core resources, or with an external host via dedicated device pins. Use of an internal host stores of all PR host logic on the FPGA device, rather than on an external device. The PR host interfaces with the control block through simple handshaking and data transfer.

Figure 43. Intel^® Arria^® 10 Partial Reconfiguration IP Components (Internal Host)

Figure 44. Intel^® Stratix^® 10 Partial Reconfiguration IP Components (Internal Host)

Figure 45. Partial Reconfiguration with Microcontroller External Host ( Intel^® Arria^® 10 device)

Figure 46. Partial Reconfiguration with HPS Internal Host ( Intel^® Arria^® 10 device)

Partial Reconfiguration Controller Intel Stratix 10 FPGA IP

The Partial Reconfiguration Controller Intel^® Stratix^® 10 FPGA IP provides partial reconfiguration functionality for Intel^® Stratix^® 10 designs. The IP core provides a standard interface to the Intel^® Stratix^® 10 FPGA secure device manager (SDM), and has a maximum clock frequency of 200 MHz.

Figure 47. Intel^® Stratix^® 10 Partial Reconfiguration Controller ( Avalon^® -ST Interface)

⁴

⁴ Avalon-MM Interface variant also available.

Memory Map

The Partial Reconfiguration Controller Intel^® Stratix^® 10 FPGA IP has the following memory map.

Table 12. Avalon^® -MM Slave Memory Map
Name	Address Offset	Width	Access	Description
`PR_DATA`	0x00	32	Write	Every data `write` to this address indicates this bitstream is sending to the IP core. Width is set by the Input data width parameter.
`PR_CSR`	0x01	32	Read or Write	Control and status registers with the following offset bits: 31 - 6: Reserved. 5: Read/Write for `irq` signal mask bit. Write `1` to this bit enable `irq` signal and `0` to disable the `irq` signal. 4: Read/Clear for `irq` signal. The `irq` signal asserts if an error occurs. The Master must read the status signal and clear the interrupt by writing `1` to this bit. 3 - 1: Read-only for `status` signal. 0: Read/Write for `pr_start` signal. To streamline the flow, the IP core automatically de-asserts to value `0`, one clock cycle after the signal asserts.
`PR_SW_VER`	0x02	32	Read	Read-only SW version register. Register is currently 0xBA500000.

Parameters

The Intel^® Stratix^® 10 Partial Reconfiguration Controller IP core supports customization of the following parameters.

Table 13. Partial Reconfiguration Controller Intel^® Stratix^® 10 FPGA IP Parameter Settings
Parameter	Value	Description
Enable Avalon-ST or Avalon-MM slave interface	Avalon-ST/Avalon-MM	Enables the controller's Avalon-ST or Avalon-MM slave interface.
Input data width	`<bits>`	Specifies the size of the controller's data conduit interface in bits. The IP supports device widths of 32 and 64.
Enable interrupt interface	Yes/No	Enables interrupt assertion for detection of incompatible bitstream, `CRC_ERROR`, `PR_ERROR`, or successful partial reconfiguration. Upon interrupt, query `PR_CSR[4:2]` for status. Write a `1` to `PR_CSR[5]` to clear the interrupt. Use only together with the Avalon^® -MM slave interface.
Enable protocol error		Reads out the error bit from the CSR register.

Figure 48. Parameter Editor

Ports

The Partial Reconfiguration Controller Intel^® Stratix^® 10 FPGA IP includes the following interface ports.

Figure 49. Avalon^® -ST Sink Interface Ports

Figure 50. Avalon^® -MM Slave Interface Ports

Table 14. Clock/Reset Ports
Port Name	Width	Direction	Function
`reset`	1	Input	Asynchronous reset for the PR Controller IP core. Resetting the PR Controller IP core during a partial reconfiguration operation can cause the device to lock up.
`clk`	1	Input	Input clock to the PR Controller IP core. The input clock must be free-running. The IP core has a maximum clock frequency of 200 MHz.

Table 15. Avalon^® -ST Slave interface PortsThese ports are available when you enable the Avalon^® -ST slave interface.
Port Name	Width	Direction	Function
`pr_start`	1	Input	A signal arriving at this port asserted high initiates a PR event. You must assert this signal high for a minimum of one clock cycle, and de-assert it low, prior to the end of the PR operation.
`avst_sink_data[]`	`32\|64`	Input	Avalon^® -ST data signal that is synchronous with the rising edge of the `clk` signal. The Input data width parameter specifies this port width.
`avst_sink_valid`	1	Input	Avalon^® -ST data valid signal that indicates the `avst_sink_data` port contains valid data.
`avst_sink_ready`	1	Output	Avalon^® -ST ready signal that indicates the device is ready to read the streaming data on the `avst_sink_data` port whenever the `avst_sink_valid` signal asserts high. Stop sending valid data when this port is low.
`status[2..0]`	3	Output	A 3-bit error output that indicates the status of a PR event. Once the outputs latch high as follow, you can only reset the outputs at the beginning of the next PR event: `3’b000 – power-up nreset asserted` `3’b001 – configuration system is busy` `3’b010 – PR operation is in progress` `3’b011 – PR operation successful` `3’b100 – PR_ERROR is triggered` `3’b101 – Reserved` `3'b110 – Reserved` `3'b111 – Reserved`
`protocol_error`	1	Output	Reads out the error bit from the CSR register.

Table 16. Avalon^® -MM Slave Interface PortsThese ports are available when you enable the Avalon^® -MM slave interface.
Port Name	Width	Direction	Function
`avmm_slave_address`	4	Input	Avalon^® -MM address bus in the unit of Word addressing.
`avmm_slave_read`	1	Input	Avalon^® -MM read control.
`avmm_slave_readdata`	32	Output	Avalon^® -MM read data bus.
`avmm_slave_write`	1	Input	Avalon^® -MM write control.
`avmm_slave_writedata`	32	Input	Avalon^® -MM write data bus.
`avmm_slave_waitrequest`	1	Output	Upon assertion, indicates that the IP is busy and the IP is unable to respond to a read or write request.
`irq`	1	Output	Interrupt signal when you enable the Enable interrupt interface parameter.

Timing Specifications

The following timing diagram illustrates a successful PR operation with the Partial Reconfiguration Controller Intel^® Stratix^® 10 FPGA IP. The status[2:0] output signal indicates whether the operations passes or fails. The PR operation initiates upon assertion of the pr_start signal. Monitor the status[] signal to detect the end of the PR operation.

Partial Reconfiguration Controller Intel^® Stratix^® 10 FPGA IP

Figure 51. Timing Specifications

Partial Reconfiguration Controller Intel Arria 10 /Cyclone 10 FPGA IP

The Partial Reconfiguration Controller Intel^® Arria^® 10/Cyclone 10 FPGA IP provides a standard interface to the partial reconfiguration functionality in the PR control block. Use this IP core to avoid manually instantiating a PR control block interface. The Partial Reconfiguration Controller Intel^® Arria^® 10/Cyclone 10 FPGA IP supports Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX PR designs with a maximum clock frequency of 100MHz.

Figure 52. Partial Reconfiguration Controller Intel^® Arria^® 10/Cyclone 10 FPGA IP

Slave Interface

The Partial Reconfiguration Controller IP core provides an Avalon^® -MM slave interface to read and write to PR configuration registers.

Table 17. Data/CSR Memory Map Format
Name	Address Offset	Access	Description
`PR_DATA`	0x00	Write	Every data `write` to this address indicates this bitstream is sent to the IP core. Performing a `read` on this address returns all 0's.
`PR_CSR`	0x01	Read or Write	Control and status registers.
`Version Register`	0x02	Read-Only	Read-only SW version register. Register is currently 0xAA500003
PR Bitstream ID	0x03	Read-Only	Read-only PR POF ID register

Table 18. PR_CSR Control and Status Registers
Bit Offset	Description
0	Read and write control register for `pr_start` signal. Refer to Ports for details on the `pr_start` signal. `pr_start = PR_CSR[0]` The IP core deasserts `PR_CSR[0]` to value 0 automatically, one clock cycle after the `PR_CSR[0]` asserts. This streamlines the flow to avoid manual assertion and de-assertion of this register to control `pr_start` signal.
1	Reserved.
2-4	Read-only status register for `status[2:0]` signal. `PR_CSR[4:2] = status[2:0]` Refer to Ports for details on the status signals.
5	Read and clear bit for interrupt. If you enable the interrupt interface, reading this bit returns the value of the `irq` signal. Writing a 1 clears the interrupt. If you disable the interrupt interface, reading this bit always returns a value of 0.
0-31	Reserved bits. Depends on the Avalon^® -MM data bus width.

Reconfiguration Sequence

Partial reconfiguration occurs through the Avalon^® -MM slave interface in the following sequence:

Avalon^® -MM master component writes 0x01 to IP address offset 0x1 to trigger PR operation.
Optionally poll the status register until PR Operation in Progress. Not polling results in waitrequest on first word.
Avalon^® -MM master component writes PR bitstream to IP address offset 0x0, until all the PR bitstream writes. When enhanced decompression is on, waitrequest activates throughout the PR operation. Ensure that your master can handle waitrequest from the slave interface.
Avalon^® -MM master component reads the data from IP address offset 0x1 to check the status[2:0] value. Optionally, the Avalon^® -MM master component reads the status[2:0] of this IP during a PR operation to detect any early failure, for example, PR_ERROR.

Interrupt Interface

If you enable the Avalon^® Memory Mapped Slave interface, you can use the optional interrupt interface of the Partial Reconfiguration Controller Intel^® Arria^® 10 /Cyclone 10 FPGA IP.

The IP core asserts irq during the following events:

Table 19. Interrupt Interface Events
Status Code	Event
3'b001	`PR_ERROR` occurred.
3'b010	`CRC_ERROR` occurred.
3'b011	The IP core detects an incompatible bitstream.
3'b101	The result of a successful PR operation.

After irq asserts, the master performs one or more of the following:

Query for the status of the PR IP core; PR_CSR[4:2].
Carry out some action, such as error reporting.
Once the interrupt is serviced, clear the interrupt by writing a "1" to PR_CSR[5].

Parameters

The Partial Reconfiguration Controller Intel^® Arria^® 10 /Cyclone 10 FPGA IP supports customization of the following parameters.

Table 20. Parameter Settings
Parameter	Value	Description
Use as partial reconfiguration internal host	On/Off	Enables the controller for use as an internal host. Enabling this option auto-instantiates `prblock` and `crcblock` WYSIWYG as part of your design. Disable this option to use the controller as an external host. Connect additional interface signals to the dedicated partial reconfiguration pins.
Enable JTAG debug mode	On/Off	Enables access to the controller by the Intel^® Quartus^® Prime Programmer for partial reconfiguration over a JTAG interface.
Enable Avalon^® -MM slave interface	On/Off	Enables the controller's Avalon^® -MM slave interface. When this setting is Off, the IP controller enables the conduit interface.
Enable interrupt interface	On/Off	Enables interrupt assertion for detection of incompatible bitstream, `CRC_ERROR`,`PR_ERROR`, or successful partial reconfiguration. Upon interrupt, query `PR_CSR[4:2]` for status. Write a `1` to `PR_CSR[5]` to clear the interrupt. Use only together with the Avalon^® -MM slave interface.
Enable freeze interface	On/Off	Enables the controller's single-bit freeze interface. This interface identifies whether any region in the design is active or frozen for partial reconfiguration operations. Leave this interface off, and use the freeze interface from the Partial Reconfiguration Region Controller IP.
Enable bitstream compatibility check	On/Off	Enables bitstream compatibility checks during partial reconfiguration operation from the external host. Bitstream compatibility check automatically enables when you use partial reconfiguration by internal host. Specify the partial reconfiguration bitstream ID value if you enable this option for partial reconfiguration by external host.
PR bitstream ID	`<32-bit integer>`	Specifies a signed, 32-bit integer value of the partial reconfiguration bitstream ID for the external host. This value must match the partial reconfiguration bitstream ID that the Compiler generates for the target partial reconfiguration design. Locate the partial reconfiguration bitstream ID of the target partial reconfiguration design in the Assembler report (.asm.rpt).
Input data width	`1\|8\|16\|32`	Specifies the size of the controller's data conduit interface in bits.
Clock-to-data ratio	`1\|4\|8`	Specifies the clock-to-data ratio that corresponds with the partial reconfiguration bitstream data type. Refer to the Valid combinations and CD Ratio for Bitstream Encryption and Compression Table.
Divide error detection frequency by	`1..256`	Specifies the divide value of the internal clock. This value determines the frequency of the error detection CRC. The divide value must be a power of two. Refer to device documentation to determine the frequency of the internal clock for the device you select.
Enable enhanced decompression	On/Off	Enable enhanced decompression of partial reconfiguration bitstreams.

Table 21. Advanced Settings
Parameter	Value	Description
Auto-instantiate partial reconfiguration control block	On/Off	Automatically includes the partial reconfiguration control block in the controller. When using the controller as an internal host, disable this option to share the partial reconfiguration block with other IP cores. Rather, manually instantiate the partial reconfiguration control block, and connect the relevant signals to the controller.
Auto-instantiate CRC block	On/Off	Automatically includes the CRC block within the controller. Leave this option enabled unless you plan to use single event upset (SEU) IP in the same PR design. If you disable this option, IP generation exports the `crc_error_pin` for manual connection to an external CRC block that you manually instantiate. If you disable this option and then subsequently leave the exported `crc_error_pin` floating, the PR operation is undetermined due to unexpected `crc_error_pin`.
Generate timing constraints file	On/Off	Automatically generates an appropriate Synopsys Design Constraints (`.sdc`) file to constrain the timing of the controller. Disable this option when providing timing constraints in another file.

Figure 53. Partial Reconfiguration Controller Intel^® Arria^® 10/Cyclone 10 FPGA IP Parameter Editor

Ports

The Partial Reconfiguration Controller Intel^® Arria^® 10 /Cyclone 10 FPGA IP includes the following interface ports.

Figure 54. Partial Reconfiguration Controller Interface Ports (Internal Host)

Figure 55. Partial Reconfiguration Controller Interface Ports (External Host)

Table 22. Clock/Reset Ports
Port Name	Width	Direction	Function
`nreset`	1	Input	Asynchronous reset for the PR Controller IP core. Resetting the PR Controller IP core during a partial reconfiguration operation initiates the withdrawal sequence.
`clk`	1	Input	User input clock to the PR Controller IP core. The IP core has a maximum clock frequency of 100MHz. The IP core ignores this signal during JTAG debug operations.

Table 23. Freeze Interface Port
Port Name	Width	Direction	Function
`freeze`	1	Output	Active high signal that freezes the PR interface signals of any region undergoing partial reconfiguration. De-assertion of this signal indicates the end of PR operation. Use the Partial Reconfiguration Region Controller IP rather than the Partial Reconfiguration Controller IP `freeze` signal.

Table 24. Conduit Interface PortsThese ports are available when Enable Avalon^® -MM slave interface is Off.
Port Name	Width	Direction	Function
`pr_start`	1	Input	A `0` to `1` transition on this port initiates a PR event. You must assert this signal high for a minimum of one clock cycle, and de-assert the signal low prior to the end of the PR operation. This operation ensures the PR Controller IP core is ready to accept the next `pr_start` trigger event when the `freeze` signal is low. The PR Controller IP core ignores this signal during JTAG debug operations.
`data[]`	1, 8, 16, or 32	Input	Selectable input PR data bus width, either x1, x8, x16, or x32. Once a PR event triggers, the PR event is synchronous with the rising edge of the `clk` signal, whenever the `data_valid` signal is high, and the `data_ready` signal is high. The PR Controller IP core ignores this signal during JTAG debug operations.
`data_valid`	1	Input	A `0` to `1` transition on this port indicates the `data[]` port contains valid data. The PR Controller IP core ignores this signal during JTAG debug operations.
`data_ready`	1	Output	A `0` to `1` transition on this port indicates the PR Controller IP core is ready to read the valid data on the `data[]` port, whenever the `data_valid` signal asserts high. The data sender must stop sending valid data if this port is low. This signal deasserts low during JTAG debug operations.
`status[2..0]`	1	Output	A 3-bit output that indicates the status of PR events. When the IP detects an error (`PR_ERROR`, `CRC_ERROR`, or incompatible bitstream error), this signal latches high. This signal only resets at the beginning of the next PR event, when `pr_start` is high, and `freeze` is low. For example: `3’b000 – power-up or nreset asserts` `3’b001 – PR_ERROR triggers` `3’b010 – CRC_ERROR triggers` `3’b011 – Incompatible bitstream error detection` `3’b100 – PR operation in progress` `3’b101 – PR operation passes` `3'b110 – Reserved bit` `3'b111 – Reserved bit`

Table 25. Avalon^® -MM Slave Interface PortsThese signals are available when Enable Avalon^® -MM slave interface is On.
Port Name	Width	Direction	Function
`avmm_slave_address`	4	Input	Avalon^® -MM address bus. The address bus is in the unit of Word addressing. The PR Controller IP core ignores this signal during JTAG debug operations.
`avmm_slave_read`	1	Input	Avalon^® -MM read control. The PR Controller IP core ignores this signal during JTAG debug operations.
`avmm_slave_readdata`	32	Output	Avalon^® -MM read data bus. The PR Controller IP core ignores this signal during JTAG debug operations.
`avmm_slave_write`	1	Input	Avalon^® -MM write control. The PR Controller IP core ignores this signal during JTAG debug operations.
`avmm_slave_writedata`	32	Input	Avalon^® -MM write data bus. The PR Controller IP core ignores this signal during JTAG debug operations.
`avmm_slave_waitrequest`	1	Output	Indicates that the IP is busy. Also indicates that the IP core is unable to respond to a read or write request. The IP core pulls this signal high during JTAG debug operations.

Table 26. Interrupt Interface PortsThese ports are available when Enable interrupt interface is On.
Port Name	Width	Direction	Function
`irq`	1	Output	The interrupt signal.

Table 27. CRC BLOCK InterfaceThese ports are available when Use as Partial Reconfiguration Internal Host is Off, or when you instantiate the `CRCBLOCK` manually for an internal host.
Port Name	Width	Direction	Function
`crc_error_pin`	1	Input	Available when you use the PR Controller IP core as an External Host. Connect this port to the dedicated `CRC_ERROR` pin of the FPGA undergoing partial reconfiguration.

Table 28. PR Block InterfaceThese options are available when Use as Partial Reconfiguration Internal Host is Off, or when you instantiate the `PRBLOCK` manually for an internal host.
Port Name	Width	Direction	Function
`pr_ready_pin`	1	Input	Connect this port to the dedicated `PR_READY` pin of the FPGA undergoing partial reconfiguration.
`pr_error_pin`	1	Input	Connect this port to the dedicated `PR_ERROR` pin of the FPGA undergoing partial reconfiguration.
`pr_done_pin`	1	Input	Connect this port to the dedicated `PR_DONE` pin of the FPGA undergoing partial reconfiguration.
`pr_request_pin`	1	Output	Connect this port to the dedicated `PR_REQUEST` pin of the FPGA undergoing partial reconfiguration.
`pr_clk_pin`	1	Output	Connect this port to the dedicated `DCLK` of the FPGA undergoing partial reconfiguration.
`pr_data_pin[31..0]`	16\|32	Output	Connect this port to the dedicated`DATA[31..0]` pins of the FPGA undergoing partial reconfiguration.

Timing Specifications

The following timing diagram illustrates a successful PR operation with Partial Reconfiguration Controller Intel^® Arria^® 10 /Cyclone 10 FPGA IP. The status[2:0] output signal indicates whether the operations passes or fails. The PR operation initiates upon assertion of the pr_start signal. Monitor the status[] signal to detect the end of the PR operation.

Figure 56. Partial Reconfiguration Controller Intel^® Arria^® 10/Cyclone 10 FPGA IP Timing Specifications

The following notes correspond to locations (1) through (7) in the timing diagram:

Assert pr_start signal high for a minimum of one clock cycle to initiate PR. Deassert pr_start before sending the last data.
status[] signal updates after pr_start is acknowledged. This signal changes during a PR operation if CRC_ERROR, PR_ERROR, or bitstream incompatibility error occurs.
status[] signal changes after a PR operation if CRC_ERROR asserts and no error occurs during the previous PR operation.
There is no requirement to assert the data_valid signal at the same time as the pr_start signal. Provide the data[], and assert data_valid, when appropriate.
Either drive the data_valid signal low after sending the last data, or continue to assert data_valid high with dummy data on data[] until the IP reads the end of PR from status[].
data[] transfers only when data_valid and data_ready assert on the same cycle. Do not drive new data on the data bus, when both data_valid and data_ready are not high.
The data_ready signal drives low after the PR IP Controller core receives the last data, or when the PR IP Controller cannot accept data.

PR Control Block and CRC Block Verilog HDL Manual Instantiation

The Partial Reconfiguration Controller Intel^® Arria^® 10 /Cyclone 10 IP includes the PR control block. However, if you create your own custom logic to perform the function of the IP core, you can manually instantiate the control block to communicate with the FPGA system.

The following example instantiates a PR control block inside a top-level Intel^® Arria^® 10 PR project, Chip_Top, in Verilog HDL:

Chip_Top:
module Chip_Top (
 //User I/O signals (excluding PR related signals)
..
..
//PR interface and configuration signals declaration
 wire pr_request;
 wire pr_ready;
 wire pr_done;
 wire crc_error;
 wire dclk;
 wire [31:0] pr_data;

twentynm_prblock m_pr
 (
 .clk (dclk),
 .corectl (1'b1),
 .prrequest(pr_request),
 .data (pr_data),
 .error (pr_error),
 .ready (pr_ready),
 .done (pr_done)
 );

twentynm_crcblock m_crc
 (
 .clk (clk),
 .shiftnld (1'b1),
 .crcerror (crc_error)
 );
endmodule

For more information about port connectivity for reading the Error Message Register (EMR), refer to the AN539: Test Methodology of Error Detection and Recovery using CRC.

PR Control Block and CRC Block VHDL Manual Instantiation

The following example shows manual instantiation of a PR control block inside your top-level Intel^® Arria^® 10 project, Chip_Top, in VHDL:

module Chip_Top is port (
 --User I/O signals (excluding signals that relate to PR)
 ..
 ..
 )
-- Following shows the connectivity within the Chip_Top module
Core_Top : Core_Top
 port_map (
 ..
 ..
 );
m_pr : twentynm_prblock
 port map(
clk => dclk,
 corectl =>'1', --1 - when using PR from inside
 --0 - for PR from pins; You must also enable
 -- the appropriate option in Quartus Prime settings
 prrequest => pr_request,
 data => pr_data,
 error => pr_error,
 ready => pr_ready,
 done => pr_done
 );
m_crc : twentynm_crcblock
 port map(
 shiftnld => '1', --If you want to read the EMR register when
 clk => dummy_clk, --error occurrs, refer to AN539 for the
 --connectivity for this signal. If you only want
 --to detect CRC errors, but plan to take no
 --further action, you can tie the shiftnld
 --signal to logical high.
 crcerror => crc_error
 );

PR Control Block and CRC Block VHDL Component Declaration

The following example shows manual instantiation of the PR control block and the CRC block in your Intel^® Arria^® 10 PR design:

Use the code sample below, containing the component declaration in VHDL. This code performs the PR function from within the core (code block within Core_Top).

module Chip_Top is port (
	--User I/O signals (excluding signals that relate to PR)
	..
	..
)
-- Following shows the connectivity within the Chip_Top module
Core_Top : Core_Top
port_map (
	..
	..
);

m_pr : twentynm_prblock
port map(
	clk => dclk,
	corectl =>'1', --1 - when using PR from inside
	--0 - for PR from pins; You must also enable
	-- the appropriate option in Quartus Prime settings
	prrequest => pr_request,
	data => pr_data,
	error => pr_error,
	ready => pr_ready,
	done => pr_done
);

m_crc : twentynm_crcblock
port map(
	shiftnld => '1', --If you want to read the EMR register when
	clk => dummy_clk, --error occurrs, refer to AN539 for the
	--connectivity forthis signal. If you only want
	--to detect CRC errors, but plan to take no
	--further action, you can tie the shiftnld
	--signal to logical high.
	crcerror => crc_error
);

Note: This VHDL example is adaptable for Verilog HDL instantiation.

Add additional ports to Core_Top to connect to both components.
Follow these rules when connecting the PR control block to the rest of your design:
- Set the corectl signal to ‘1’ (when using partial reconfiguration from core) or to ‘0’ (when using partial reconfiguration from pins).
- The corectl signal must match the Enable PR pins option setting in the Device and Pin Options dialog box (Assignments > Device > Device and Pin Options).
- When performing partial reconfiguration from pins, the Fitter automatically assigns the PR unassigned pins. Assign all the dedicated PR pins using Pin Planner ( Assignments > Pin Planner) or Assignment Editor (Assignments > Assignment Editor).
- When performing partial reconfiguration from the core logic, connect the prblock signals to either core logic or I/O pins, excluding the dedicated programming pin, such as DCLK.

Control Block Signals

The following table lists the partial reconfiguration control block interface signals for the Partial Reconfiguration Controller Intel^® Arria^® 10 /Cyclone 10 FPGA IP:

Table 29. PR Control Block Interface Signals
Signal	Width	Direction	Description
`pr_data`	[31:0]	Input	Carries the configuration bitstream.
`pr_done`	1	Output	Indicates that the PR process is complete.
`pr_ready`	1	Output	Indicates that the control block is ready to accept PR data from the control logic.
`pr_error`	1	Output	Indicates a partial reconfiguration error.
`pr_request`	1	Input	Indicates that the PR process is ready to begin.
`corectl`	1	Input	Determines whether you are performing the partial reconfiguration internally, or through pins.

Note:

You can specify a configuration width of 8, 16, or 32 bits, but the interface always uses 32 pins.
All the inputs and outputs are asynchronous to the PR clock (clk), except data signal. data signal is synchronous to clk signal.
PR clock must be free-running.
data signal must be 0 while waiting for ready signal.

Intel Arria 10 PR Control Block Signal Timing Diagrams

Successful PR Session ( Intel Arria 10 Example)

The following flow describes a successful Intel^® Arria^® 10 PR session:

Assert PR_REQUEST and wait for PR_READY; drive PR_DATA to 0.
The PR control block asserts PR_READY, asynchronous to clk.
Start sending Raw Binary File (.rbf) to the PR control block, with 1 valid word per clock cycle. On .rbf file transfer completion, drive PR_DATA to 0. The PR control block asynchronously asserts PR_DONE when the control block completes the reconfiguration operation. The PR control block deasserts PR_READY on configuration completion.
Deassert PR_REQUEST. The PR control block acknowledges the end of PR_REQUEST, and deasserts PR_DONE. The host can now initiate another PR session.

Figure 57. Timing Diagram for Successful Intel^® Arria^® 10 PR Session

Unsuccessful PR Session with Configuration Frame Readback Error ( Intel Arria 10 Example)

The following flow describes an Intel^® Arria^® 10 PR session with error in the EDCRC verification of a configuration frame readback:

The PR control block internally detects a CRC error.
The CRC control block then asserts CRC_ERROR.
The PR control block asserts the PR_ERROR.
The PR control block deasserts PR_READY, so that the host can withdraw the PR_REQUEST.
The PR control block deasserts CRC_ERROR and clears the internal CRC_ERROR signal to get ready for a new PR session. The host can now initiate another PR session.

Figure 58. Timing Diagram for Unsuccessful Intel^® Arria^® 10 PR Session with Configuration Frame Readback Error

Unsuccessful PR Session with PR_ERROR ( Intel Arria 10 Example)

The following flow describes an Intel^® Arria^® 10 PR session with transmission error or configuration CRC error:

The PR control block asserts PR_ERROR.
The PR control block deasserts PR_READY, so that the host can withdraw PR_REQUEST.
The PR control block deasserts PR_ERROR to get ready for a new PR session. The host can now initiate another PR session.

Figure 59. Timing Diagram for Unsuccessful Intel^® Arria^® 10 PR Session with PR_ERROR

Late Withdrawal PR Session ( Intel Arria 10 Example)

The following flow describes a late withdrawal Intel^® Arria^® 10 PR session:

The PR host can withdraw the request after the PR control block asserts PR_READY.
The PR control block deasserts PR_READY. The host can now initiate another PR session.

Figure 60. Timing Diagram for Late Withdrawal Intel^® Arria^® 10 PR Session

Note: The PR host can withdraw the request any time before the PR controller asserts PR_READY. Therefore, the PR host must not return until the PR control block asserts PR_READY. Provide at least 10 PR_CLK cycles after deassertion of PR_REQUEST, before requesting a new PR session.

Configuring an External Host for Intel Arria 10 Designs

When using external host configuration, the external host initiates partial reconfiguration, and monitors the PR status using the external PR dedicated pins during user mode. In this mode, the external host must respond appropriately to the handshake signals for successful partial reconfiguration. The external host writes the partial bitstream data from external memory into the Intel^® Arria^® 10 device. Co-ordinate system-level partial reconfiguration by ensuring that you prepare the correct PR region for partial reconfiguration. After reconfiguration, return the PR region into operating state.

To use an external host for your design:

Click Assignments > Device > Device & Pin Options.
Select the Enable PR Pins option in the Device & Pin Options dialog box. This option automatically creates the special partial reconfiguration pins, and defines the pins in the device pin-out. This option also automatically connects the pins to PR control block internal path.
Note: If you do not select this option, you must use an internal or HPS host. You do not need to define pins in your design top-level entity.
Connect these top-level pins to the specific ports in the PR control block.

The following table lists the PR pins that automatically constrain when you turn on Enable PR Pins, and the specific PR control block port connection to the pin:

Table 30. Partial Reconfiguration Dedicated Pins
Pin Name	Type	PR Control Block Port Name	Description
`PR_REQUEST`	Input	`prrequest`	Logic high on this pin indicates that the PR host is requesting partial reconfiguration.
`PR_READY`	Output	`ready`	Logic high on this pin indicates that the PR control block is ready to begin partial reconfiguration.
`PR_DONE`	Output	`done`	Logic high on this pin indicates that the partial reconfiguration is complete.
`PR_ERROR`	Output	`error`	Logic high on this pin indicates an error in the device during partial reconfiguration.
`DATA[31:0]`	Input	`data`	These pins provide connectivity for `PR_DATA` to transfer the PR bitstream to the PR controller.
`DCLK`	Input	`clk`	Receives synchronous `PR_DATA`.

Note:

PR_DATA can be 8, 16, or 32-bits in width.
Ensure that you connect the corectl port of the PR control block to 0.

Verilog RTL for External Host PR

module top(
     // PR control block signals
     input  logic        pr_clk,
     input  logic        pr_request,
     input  logic [31:0] pr_data,
     output logic        pr_error,
     output logic        pr_ready,
     output logic        pr_done,

     // User signals
     input  logic i1_main,
     input  logic i2_main,
     output logic o1
);

// Instantiate the PR control block
twentynm_prblock m_prblock
(
    .clk(pr_clk),
    .corectl(1'b0),
    .prrequest(pr_request),
    .data(pr_data),
    .error(pr_error),
    .ready(pr_ready),
    .done(pr_done)
);


// PR Interface partition
pr_v1 pr_inst(
   .i1(i1_main),
   .i2(i2_main),
   .o1(o1)
);

endmodule

VHDL RTL for External Host PR

library ieee;
use ieee.std_logic_1164.all;

entity top is
port(
      -- PR control block signals
      pr_clk: in std_logic;
      pr_request: in std_logic;
      pr_data: in std_logic_vector(31 downto 0);
                
      pr_error: out std_logic;
      pr_ready: out std_logic;
      pr_done: out std_logic;
                
      -- User signals
      i1_main: in std_logic;
      i2_main: in std_logic;
      o1: out std_logic
);
end top;

architecture behav of top is

component twentynm_prblock is
port(      
      clk: in std_logic;
      corectl: in std_logic;
      prrequest: in std_logic;
      data: in std_logic_vector(31 downto 0);
      error: out std_logic;
      ready: out std_logic;
      done: out std_logic
);
end component;

component pr_v1 is
port(     
      i1: in std_logic;
      i2: in std_logic;
      o1: out std_logic
);
end component;

signal pr_gnd : std_logic;

begin

pr_gnd <= '0';

-- Instantiate the PR control block
m_prblock: twentynm_prblock port map
(
    pr_clk,
    pr_gnd,
    pr_request,
    pr_data,
    pr_error,
    pr_ready,
    pr_done
);


-- PR Interface partition
pr_inst : pr_v1 port map
(
   i1_main,
   i2_main,
   o1
);

end behav;

Partial Reconfiguration External Configuration Controller Intel Stratix 10 FPGA IP

The Partial Reconfiguration External Configuration Controller Intel^® Stratix^® 10 FPGA IP supports partial reconfiguration via an external source.

When using external configuration, you must connect all the top-level ports of the Partial Reconfiguration External Configuration Controller Intel^® Stratix^® 10 FPGA IP to the pr_request and status pins, to allow the handshaking of the host with SDM from the Intel^® Stratix^® 10 core. The SDM determines which types of configuration pins to use, according your MSEL setting.

Figure 61. Partial Reconfiguration External Configuration Controller Intel^® Stratix^® 10 FPGA IP

Parameters

The Partial Reconfiguration External Configuration Controller Intel^® Stratix^® 10 FPGA IP supports customization of the following parameters.

Table 31. Partial Reconfiguration External Configuration Controller Parameter Settings
Parameter	Value	Description
Enable Busy Interface	On/Off	Allows you to Enable or Disable the Busy interface, which asserts a signal to indicate that PR processing is in progress during external configuration.

Figure 62. Parameter Editor

Ports

The Partial Reconfiguration External Configuration Controller Intel^® Stratix^® 10 FPGA IP includes the following interface ports.

Table 32. Ports
Port Name	Width	Direction	Function
`pr_request`	1	Input	Indicates that the PR process is ready to begin. The signal is a conduit not synchronous to any clock signal.
`pr_error`	1	Output	Indicates a partial reconfiguration error. The signal is a conduit not synchronous to any clock signal.
`pr_done`	1	Output	Indicates that the PR process is complete. The signal is a conduit not synchronous to any clock signal.
`start_addr`	1	Input	Specifies the start address of PR data in Active Serial Flash. You enable this signal by selecting either Avalon^® -ST or Active Serial for the Enable Avalon-ST Pins or Active Serial Pins parameter. The signal is a conduit not synchronous to any clock signal.
`reset`	1	Input	Active high, synchronous reset signal.
`out_clock`	1	Output	Clock source that generates from an internal oscillator.
`busy`	1	Output	The IP asserts this signal to indicate PR data transfer in progress. You enable this signal by selecting Enable for the Enable busy interface parameter.

Configuring an External Host for Intel Stratix 10 Designs

You can optionally use an external host to write the partial bitstream data from external memory into the Intel^® Stratix^® 10 device. When using external host configuration, the external host initiates partial reconfiguration by asserting the pr_request signal. The external host monitors the PR status through the pr_done and pr_error signals.

The external host must respond appropriately to the handshake signals for successful partial reconfiguration. Co-ordinate system-level partial reconfiguration by ensuring that you prepare the correct PR region for partial reconfiguration. After reconfiguration, return the PR region into operating state.

To configure an external host for Intel^® Stratix^® 10 designs, follow these steps:

Parameterize and generate the Partial Reconfiguration External Configuration Controller Intel^® Stratix^® 10 FPGA IP, as Generating IP Cores ( Intel Quartus Prime Pro Edition) describes.
Connect the Partial Reconfiguration External Configuration Controller pr_request, pr_done, and pr_error signals to top-level pins for control and monitor by the external host. You can assign the pin location by clicking Assignments > Pin Planner.
Click Assignments > Device, and then click the Device & Pin Options button.
In the Category list, click Configuration.
For the Configuration scheme, select the scheme that matches with your full device configuration. For example, if your full device configuration uses the AVSTx32 scheme, the PR configuration must use AVSTx32.This option automatically reserves dedicated Avalon^® -ST configuration pins for partial reconfiguration during user mode. The pins are exactly same as the Avalon^® -ST pins that you use for full device configuration.

The following table describes the PR pins that the external host uses. The PR streaming to Avalon^® -ST pins must conform to the Avalon^® -ST specification for data transfer with backpressure.

Table 33. Partial Reconfiguration External Configuration Pins
Pin Name	Type	Description
`pr_request`	Input	User-assigned port connected to Partial Reconfiguration External Configuration Controller IP. Logic high on this pin indicates that the PR host is requesting partial reconfiguration.
`pr_done`	Output	User-assigned port connected to Partial Reconfiguration External Configuration Controller IP. Logic high on this pin indicates that the partial reconfiguration is complete.
`pr_error`	Output	User-assigned port connected to Partial Reconfiguration External Configuration Controller IP. Logic high on this pin indicates an error in the device during partial reconfiguration.
avst_data: avstx8 - [7:0] avstx16 - [15:0] avstx32 - [31:0]	Input	These pins provide connectivity for the external host to transfer the PR bitstream to the SDM. The `avstx8` data pins are part of the SDM I/O. `avstx16` and `avstx32` data pins are from I/O 48 bank 3A.
`avst_clk`	Input	Clocks the Avalon^® -ST interfaces. `avst_data` and `avst_valid` are synchronous with `avst_clk`. The `avstx8` clk pin is part of the SDM I/O. `avstx16` and `avstx32` are from I/O 48 bank 3A.
`avst_valid`	Input	Logic high on this pin indicates the data in `avst_data` is valid data. The `avstx8` data pins are part of the SDM I/O. `avstx16` and `avstx32` data pins are from I/O 48 bank 3A.
`avst_ready`	Output	Logic high on this pin indicates the SDM is ready to accept data from an external host. This output is part of the SDM I/O.

Partial Reconfiguration Region Controller Intel FPGA IP

The Partial Reconfiguration Region Controller Intel^® FPGA IP provides a standard interface through the Freeze Control block that controls handshaking with the PR region. The PR handshake ensures that PR region transactions complete before freeze of the interface.

Figure 63. Partial Reconfiguration Region Controller IP Core

Table 34. PR Region Controller Sections
IP Component	Description
Freeze Control and Status Register	Freeze status register that generates the `freeze` output signal.
Freeze Control Block	Performs PR handshaking and resets the PR region.
Conduit Splitter	Connects the controller's `freeze` signal to one or more Freeze Bridge components. Receives the `freeze` signal from the Freeze Control Block, and assigns the `freeze` input signal to one or more `freeze` output signals.
Conduit Merger	Connects the `illegal_request` signal from one or more Freeze Bridge components to the PR Region Controller. The `illegal_request` is a single-bit output signal from the Freeze Bridge. Conduit Merger concatenates the single-bit signal from multiple Freeze Bridges into a multi-bit bus. The Conduit Merger then connects the bus to the Freeze Control Block.

Registers

The Partial Reconfiguration Region Controller IP core performs the following operations in a partial reconfiguration:

Figure 64. Freeze Control Block PR Handshake Timing

Figure 65. Register States and Programming Model

Table 35. Register Map
Name	Address Offset	Access	Description
`freeze_csr_status`	0x00	Read-Only	Freeze status register.
`csr_ctrl`	0x01	Read or Write	Control register to enable and disable freeze.
`freeze_illegal_req`	0x02	Read or Write	High on any bit indicates an illegal request during the freeze state.
`freeze_reg_version`	0x03	Read-Only	Read-only version register. This register is currently 0xAD000003.

Table 36. freeze_csr_status
Bit	Fields	Access	Default Value	Description
31:2	Reserved	N/A	0x0	Reserved bits. Reading these bits always returns zeros.
1	unfreeze_status	R	0	Hardware sets this bit to 1 after the PR region returns `start_ack` to indicate successful start of the persona. Hardware clears this bit to 0 when the `unfreeze_req` bit is low. This bit is 1 when bridges and other PR region outputs release from reset.
0	freeze_status	R	0	Hardware sets this bit to 1 after the PR region returns the `stop_ack` signal to indicate that the PR region is ready to enter the frozen state Hardware clears this bit to 0 when the `freeze_req` bit is low. This bit is 0 when bridges and other PR region outputs release from reset.

Table 37. freeze_csr_ctrl
Bit	Fields	Access	Default Value	Description
31:3	Reserved	N/A	0x0	Reserved bits. Reading these bits always returns zeros.
2	unfreeze_req	R/W	0	Write 1 to this bit to request unfreezing the PR region interfaces. Hardware clears this bit after `unfreeze_status` is high. Write 0 to this bit to terminate the unfreeze request. Do not assert this bit and the `freeze_req` bit at the same time. If both `freeze_req` and `unfreeze_req` assert at the same time, it is an invalid operation.
1	reset_req	R/W	0	Write 1 to start resetting the PR persona. Write 0 to stop resetting the PR persona.
0	freeze_req	R/W	0	Write 1 to this bit to start freezing the PR region interfaces. Hardware clears this bit after `freeze_status` is high. Write 0 to this bit to terminate the freeze request if the PR region never returns `stop_ack` after this bit asserts. Do not assert this bit and the `unfreeze_req` bit at the same time. Asserting `freeze_req` and `unfreeze_req` simultaneously is an invalid operation.

Table 38. freeze_illegal_request
Bit	Fields	Access	Default Value	Description
31:n	Reserved	N/A	0x0	Reserved bits. Reading these bits always returns zeros.
n-1:0	illegal_request	R/W	0	High on any bit of this bus indicates a read or write issue by a static region master when an Avalon^® -MM slave freeze bridge is in the freeze state. Identify which freeze bridge has an illegal request by checking each bit on the bus. For example, when `illegal_request` bit 2 is high, an illegal request occurred in the freeze bridge that connects to interface `freeze_conduit_in2` This bus triggers the interrupt signal. Write 1 to clear this bit. n is the number of bridges.

Table 39. freeze_reg_version
Bit	Fields	Access	Default Value	Description
31:0	Version Register	Read-Only	AD000003	This register bit indicates the CSR register version number. Currently the CSR register is version 0xAD000003.

Parameters

The Partial Reconfiguration Region Controller IP core supports customization of the following parameters.

Table 40. Partial Reconfiguration Region Controller Parameter Settings
Parameter	Value	Default	Description
Enable Avalon^® -MM CSR register	On/Off	On	Enables Avalon^® -MM CSR registers in the PR region controller. Disable this option to expose a conduit interface and not instantiate the CSR block.
Enable interrupt port for illegal request	On/Off	On	Enables the interrupt port for illegal operations in the PR region controller.
Number of freeze interfaces	`number`		Specifies the number of freeze interfaces for freeze operations. You can connect each freeze interface to a freeze bridge or you can use the interface to control other freeze logic.
Enable freeze interface without illegal request port	On/Off	Off	Enables creation of additional freeze interface, without the illegal request port.
Specify the number of freeze interfaces without illegal request port	`number`		Specifies the number of freeze interfaces without an illegal request port for freeze operations. Only available when you turn on Enable freeze interface without illegal request port.

Figure 66. Partial Reconfiguration Region Controller Parameter Editor

Ports

The Partial Reconfiguration Region Controller IP has the following ports.

Table 41. Freeze CSR Block PortsThese ports are available when Enable Avalon^® -MM CSR Register is On.
Port	Width	Direction	Description
`clock_clk`	1	Input	IP core input clock.
Reset
`reset_reset`	1	Input	Synchronous reset.
`avl_csr_addr`	2	Input	Avalon^® -MM address bus. The address bus is in word addressing.
`avl_csr_read`	1	Input	Avalon^® -MM read control to CSR block.
`avl_csr_write`	1	Input	Avalon^® -MM write control to CSR.
`avl_csr_writedata`	32	Input	Avalon^® -MM write data bus to CSR.
`avl_csr_readdata`	32	Output	Avalon^® -MM read data bus from CSR.
`interrupt_sender_irq`	1	output	Trigger by illegal read or illegal write.

Table 42. Freeze Control Block Ports
Port	Width	Direction	Description
`pr_handshake_stop_req`	1	Output	An assertion on this output requests that the PR persona stop executing.
`pr_handshake_stop_ack`	1	Input	A value of 1 on this input acknowledges that the executing PR persona stops executing and a new persona can replace it.
`pr_handshake_start_req`	1	Output	An assertion on this output requests that the new PR persona starts executing.
`pr_handshake_start_ack`	1	Input	A value of 1 on this input acknowledges that the new PR persona starts executing and can stop executing on a `pr_handshake_stop_req`.
`conduit_control_freeze_req`	1	Input	Write 1 on this bit to start freezing the PR region interfaces.
`conduit_control_unfreeze_req`	1	Input	Write 1 on this bit to stop freezing the PR region interfaces.
`conduit_control_freeze_status`	1	Output	High on this bit indicates that the PR region is successfully goes into freezing state.
`conduit_control_reset`	1	Input	Write 1 on this bit to reset the PR region.
`conduit_control_unfreeze_status`	1	Output	High on this bit indicates that the PR region successfully leaves freezing state.
`conduit_control_illegal_req`	n	Output	High on this bit indicates illegal data transactions occurring through a Freeze Bridge IP when freeze is active.

Table 43. Conduit Splitter and Merger Interface Ports
Signal	Width	Direction	Description
`bridge_freeze0_freeze`	1	Output	This output connects to the freeze input signal of a freeze bridge IP or to control other freeze logic. (Multiple interfaces generate according to the number of freeze interfaces)
`bridge_freeze0_illegal_request`	1	Input	This input connects to the `illegal_request` output signal from an instance of the Freeze Bridge IP.

Figure 67. Partial Reconfiguration Region Controller Interface Ports (Control and Status Register Block Enabled)

Figure 68. Partial Reconfiguration Region Controller Interface Ports (Control and Status Register Block Disabled)

Avalon-MM Partial Reconfiguration Freeze Bridge Intel FPGA IP

The Avalon-MM Partial Reconfiguration Freeze Bridge IP freezes a PR region Avalon-MM interface when the freeze input signal is high. It is recommended that each Avalon-MM interface to a PR region use an instance of the Freeze Bridge IP.

Figure 69. Avalon-MM Partial Reconfiguration Freeze Bridge

Table 44. Read and Write Request to PR Region Avalon^® -MM Slave InterfaceThe Freeze Bridge handles read and write transactions differently for each of the following possible interface configurations. The Freeze Bridge is in the freeze state until the PR region or PR region controller asserts the `freeze` signal.
Interface Connection	Behavior
Read request to Avalon^® -MM slave interface in PR region	During the `freeze` state, any read transaction responds with bogus data `<h'DEADBEEF>`. The corresponding `freeze_illegal_request` register bit sets. During the `freeze` state, `readrequest`, `writerequest`, `waitrequest`, `beginbursttransfer`, `lock`, and `debugaccess` signals in the PR region interface tie low. The Avalon^® -MM slave response signal constantly returns 2’b10, to indicate an unsuccessful transaction from an endpoint slave. If you disable Enable Freeze port from PR region, the IP generates no responses.
Write request to slave interface in PR region	The Freeze Bridge ignores any write transactions during the `freeze` state. The Freeze Bridge pulls the `waitrequest`, `beginbursttransfer`, `lock` and `debugaccess` signals low. The IP sets the corresponding `freeze_illegal_request` register bit. The Avalon^® -MM slave response signal updates with 2’b10 to indicate an unsuccessful transaction from an endpoint slave. If you disable Enable Freeze port from PR region, the IP generates no responses.

Table 45. Read and Write Request from PR Region Avalon^® -MM Master Interface
Interface Connection	Behavior
Read/Write request from Avalon^® -MM master interface in PR region (old or new persona)	During the `freeze` state the IP ignores the read and write signals from the PR region. The read and write signals to the static region deassert.

Table 46. Avalon-MM Partial Reconfiguration Freeze Bridge Signal BehaviorThe table below summarizes the Avalon^® interface output signal behavior when the Freeze Bridge is in a frozen state. When not frozen, all signals are just pass-through.
Signal	Avalon^® -MM Slave Bridge	Avalon^® -MM Master Bridge
`write`	‘b0 (tie low)	‘b0 (tie low)
`read`	‘b0 (tie low)	‘b0 (tie low)
`address`	Pass through	Pass through
`writedata`	Pass through	Pass through
`readdata`	Return <h’DEADBEEF> always	Pass through
`byteenable`	Pass through	Pass through
`burstcount`	Pass through	Pass through
`beginbursttransfer`	‘b0 (tie low)	‘b0 (tie low)
`debugaccess`	‘b0 (tie low)	‘b0 (tie low)
`readdatavalid`	Return ‘b1 when there is a request, else ‘b0	Pass through
`waitrequest`	Return ‘b1 when there is a request, else ‘b0	‘b0 (tie low)
`response`	Return ‘b10 always	Pass through
`lock`	‘b0 (tie low)	‘b0 (tie low)
`writeresponsevalid`	Return ‘b1 when there is a request, else ‘b0	Pass through

Parameters

The Avalon^® -MM Partial Reconfiguration Freeze Bridge IP core supports customization of the following parameters.

Table 47. Parameters
Parameter	Values	Description
PR region interface Type	Avalon-MM Slave/Avalon-MM Master	Specifies the interface type for interfacing the PR region with the Freeze Bridge.
Enable Freeze port from PR region	On/Off	Enables the `freeze` port that freezes all the outputs of each PR region to a known constant value. Freezing prevents the signal receivers in the static region from receiving undefined signals during the partial reconfiguration process. The freeze of a bridge is the logical OR of this signal from the PR region, and the freeze from the PR region controller.
Enable the bridge to track unfinished transaction	On/Off	Enables the bridge to track unfinished transactions before freezing the Avalon^® interface. Turn on this option when there is no custom logic to stop the Avalon^® transaction between the PR region and the static region. If you do not need this feature, disable this option to reduce the size of the IP.
Enabled Avalon^® Interface Signal	Yes/No	Enable (Yes) or disable (No) specific optional Freeze Bridge interface ports.
Address width	`<1-64>`	Address width in bits.
Symbol width	`<number>`	Data symbol width in bits. The symbol width should be 8 for byte-oriented interfaces.
Number of symbols	`<number>`	Number of symbols per word.
Burstcount width	`<number>`	The width of the burst count in bits.
Linewrap burst	On/Off	When On, the address for bursts wraps instead of incrementing. With a wrapping burst, when the address reaches a burst boundary, the address wraps back to the previous burst boundary. Consequently, the IP uses only the low order bits for addressing.
Constant burst behavior	On/Off	When On, memory bursts are constant.
Burst on burst boundaries only	On/Off	When On, memory bursts are aligned to the address size.
Maximum pending reads	`<number>`	The maximum number of pending reads that the slave can queue.
Maximum pending writes	`<number>`	The maximum number of pending writes that the slave can queue.
Fixed read latency (cycles)	`<number>`	Sets the read latency for fixed-latency slaves. Not useful on interfaces that include the `readdatavalid` signal.
Fixed read wait time (cycles)	`<number>`	For master interfaces that do not use the `waitrequest` signal. The read wait time indicates the number of cycles before the master responds to a read. The timing is as if the master asserted `waitrequest` for this number of cycles.
Fixed write wait time (cycles)	`<number>`	For master interfaces that do not use the `waitrequest` signal. The write wait time indicates the number of cycles before the master accepts a write.
Address type	WORDS/SYMBOLS	Sets slave interface address type to symbols or words.

Figure 70. Parameter Editor

Interface Ports

Table 48. Interface Ports
Port	Width	Direction	Description
`clock`	1	Input	Input clock for the IP.
`reset_n`	1	Input	Synchronous reset for the IP.
`freeze_conduit_freeze`	1	Input	When this signal is high, the bridge handles any current transaction properly then freezes the Avalon-MM PR interfaces.
`freeze_conduit_illegal_request`	1	Output	High on this bus indicates that an illegal request was issued to the bridge during the freeze state.
`pr_freeze_pr_freeze`	1	Input	Enabled `freeze` port coming from the PR region.

Table 49. Avalon^® -MM Slave to PR Region Master Interface Ports
Port	Width	Direction	Description
`slv_bridge_to_pr_read`	1	Output	Optional Avalon^® -MM slave bridge to PR region `read` port.
`slv_bridge_to_pr_waitrequest`	1	Input	Optional Avalon^® -MM slave bridge to PR region `waitrequest` port.
`slv_bridge_to_pr_write`	1	Output	Optional Avalon^® -MM slave bridge to PR region `write` port.
`slv_bridge_to_pr_address`	32	Output	Optional Avalon^® -MM slave bridge to PR region `address` port.
`slv_bridge_to_pr_byteenable`	4	Output	Optional Avalon^® -MM slave bridge to PR region `byteenable` port.
`slv_bridge_to_pr_writedata`	32	Output	Optional Avalon^® -MM slave bridge to PR region `writedata` port.
`slv_bridge_to_pr_readdata`	32	Input	Optional Avalon^® -MM slave bridge to PR region `readdata` port.
`slv_bridge_to_pr_burstcount`	3	Output	Optional Avalon^® -MM slave bridge to PR region `burstcount` port.
`slv_bridge_to_pr_readdatavalid`	1	Input	Optional Avalon^® -MM slave bridge to PR region `readdatavalid` port.
`slv_bridge_to_pr_beginbursttransfer`	1	Output	Optional Avalon^® -MM slave bridge to PR region `readdatavalid` port.
`slv_bridge_to_pr_debugaccess`	1	Output	Optional Avalon^® -MM slave bridge to PR region `beginbursttransfer` port.
`slv_bridge_to_pr_response`	2	Input	Optional Avalon^® -MM slave bridge to PR region `response` port.
`slv_bridge_to_pr_lock`	1	Output	Optional Avalon^® -MM slave bridge to PR region `lock` port.
`slv_bridge_to_pr_writeresponsevalid`	1	Input	Optional Avalon^® -MM slave bridge to PR region `writeresponsevalid` port.

Table 50. Avalon^® -MM Slave to Static Region Master Interface Ports
Note: Same setting as Avalon^® -MM master to PR region slave interface.
Port	Width	Direction	Description
`slv_bridge_to_sr_read`	1	Input	Avalon^® -MM slave bridge to static region `read` port.
`slv_bridge_to_sr_waitrequest`	1	Output	Avalon^® -MM slave bridge to static region `waitrequest` port.
`slv_bridge_to_sr_write`	1	Input	Avalon^® -MM slave bridge to static region `write` port.
`slv_bridge_to_sr_address`	32	Input	Avalon^® -MM slave bridge to static region `address` port.
`slv_bridge_to_sr_byteenable`	4	Input	Avalon^® -MM slave bridge to static region `byteenable` port.
`slv_bridge_to_sr_writedata`	32	Input	Avalon^® -MM slave bridge to static region `writedata` port.
`slv_bridge_to_sr_readdata`	32	Output	Avalon^® -MM slave bridge to static region `readdata` port.
`slv_bridge_to_sr_burstcount`	3	Input	Avalon^® -MM slave bridge to static region `burstcount` port.
`slv_bridge_to_sr_beginbursttransfer`	1	Input	Avalon^® -MM slave bridge to static region `beginbursttransfer` port.
`slv_bridge_to_sr_ debugaccess`	1	Input	Avalon^® -MM slave bridge to static region `debugaccess` port.
`slv_bridge_to_sr_response`	2	Output	Avalon^® -MM slave bridge to static region `response` port.
`slv_bridge_to_sr_lock`	1	Input	Avalon^® -MM slave bridge to static region `lock` port.
`slv_bridge_to_sr_writeresponsevalid`	1	Output	Avalon^® -MM slave bridge to static region `writereponsevalid` port.

Table 51. Avalon^® -MM Master to PR Region Slave Interface Ports
Port	Width	Direction	Description
`mst_bridge_to_pr_read`	1	Input	Optional Avalon^® -MM master bridge to PR region `read` port.
`mst_bridge_to_pr_waitrequest`	1	Output	Optional Avalon^® -MM master bridge to PR region `waitrequest` port.
`mst_bridge_to_pr_write`	1	Input	Optional Avalon^® -MM master bridge to PR region `write` port.
`mst_bridge_to_pr_address`	32	Input	Optional Avalon^® -MM master bridge to PR region `address` port.
`mst_bridge_to_pr_byteenable`	4	Input	Optional Avalon^® -MM master bridge to PR region `byteenable` port.
`mst_bridge_to_pr_writedata`	32	Input	Optional Avalon^® -MM master bridge to PR region `writedata` port.
`mst_bridge_to_pr_readdata`	32	Output	Optional Avalon^® -MM master bridge to PR region `readdata` port.
`mst_bridge_to_pr_burstcount`	3	Input	Optional Avalon^® -MM master bridge to PR region `burstcount` port.
`mst_bridge_to_pr_readdatavalid`	1	Output	Optional Avalon^® -MM master bridge to PR region `readdatavalid` port.
`mst_bridge_to_pr_beginbursttransfer`	1	Input	Optional Avalon^® -MM master bridge to PR region `beginbursttransfer` port.
`mst_bridge_to_pr_debugaccess`	1	Input	Optional Avalon^® -MM master bridge to PR region `debugaccess` port.
`mst_bridge_to_pr_response`	2	Output	Optional Avalon^® -MM master bridge to PR region `response` port.
`mst_bridge_to_pr_lock`	1	Input	Optional Avalon^® -MM master bridge to PR region `lock` port.
`mst_bridge_to_pr_writeresponsevalid`	1	Output	Optional Avalon^® -MM master bridge to PR region `writeresponsevalid` port.

Table 52. Avalon^® -MM Master to Static Region Slave Interface PortsSame setting as Avalon^® -MM slave to PR region master interface.
Port	Width	Direction	Description
`mst_bridge_to_sr_read`	1	Output	Avalon^® -MM master bridge to static region `read` port.
`mst_bridge_to_sr_waitrequest`	1	Input	Avalon^® -MM master bridge to static region `read` port.
`mst_bridge_to_sr_write`	1	Output	Avalon^® -MM master bridge to static region `read` port.
`mst_bridge_to_sr_address`	32	Output	Avalon^® -MM master bridge to static region `address` port.
`mst_bridge_to_sr_byteenable`	4	Output	Avalon^® -MM master bridge to static region `byteenable` port.
`mst_bridge_to_sr_writedata`	32	Output	Avalon^® -MM master bridge to static region `writedata` port.
`mst_bridge_to_sr_readdata`	32	Input	Avalon^® -MM master bridge to static region `readdata` port.
`mst_bridge_to_sr_burstcount`	3	Output	Avalon^® -MM master bridge to static region `burstcount` port.
`mst_bridge_to_sr_readdatavalid`	1	Input	Avalon^® -MM master bridge to static region `readdatavalid` port.
`mst_bridge_to_sr_beginbursttransfer`	1	Output	Avalon^® -MM master bridge to static region `beginbursttransfer` port.
`mst_bridge_to_sr_debugaccess`	1	Output	Avalon^® -MM master bridge to static region `debugaccess` port.
`mst_bridge_to_sr_response`	2	Input	Avalon^® -MM master bridge to static region `response` port.
`mst_bridge_to_sr_lock`	1	Output	Avalon^® -MM master bridge to static region `lock` port.
`mst_bridge_to_sr_writeresponsevalid`	1	Input	Avalon^® -MM master bridge to static region `writeresponsevalid` port.

Figure 71. Avalon^® -MM Master Interface Ports

Figure 72. Avalon^® -MM Slave Interface Ports

Avalon-ST Partial Reconfiguration Freeze Bridge Intel FPGA IP

The Avalon^® -ST Freeze Bridge component freezes a PR region Avalon-ST interface when the freeze input signal is high. The Avalon^® -ST Freeze Bridge IP ensures that any transaction is complete before freezing the connected interface. It is recommended that each Avalon-ST interface to a PR region use an instance of the Freeze Bridge IP.

Figure 73. Avalon^® -ST Partial Reconfiguration Freeze Bridge

Table 53. Avalon^® -ST Source Freeze Bridge Interface Behavior
Interface Type	Behavior
Source interface in the PR region with packet transfer (old or new persona)	When the freeze signal goes high, the Freeze Bridge handles the `startofpacket`, `endofpacket`, and `empty` bits and does not send transactions to the static region. When the Freeze Bridge detects a `startofpacket` transaction without a corresponding `endofpacket` during the frozen state, this indicates an unfinished transaction. The bridge then completes the transaction by asserting `valid` and `endofpacket` high to the static region for one clock cycle. The `channel` signal remains constant, while data bits are set to `'hDEADBEEF` and error bit is set to `1’b1`. The `illegal_request` output signal triggers update of the CSR register in the Partial Reconfiguration Region Controller.
Source interface in the PR region without packet transfer (old or new persona)	When the freeze signal is high, the Freeze Bridge does not send transactions to the static region. The Freeze Bridge remains idle until the bridge leaves the frozen state.
Source interface in the PR region with max_channel > 1 (old or new persona)	When multiple channels transfer unfinished transactions, the Freeze Bridge tracks the `channel` values to ensure that all packet transactions from different channels end by asserting the `endofpacket` bit during the frozen state.
Source interface in the PR region with ready_latency > 0 (old or new persona)	When the Freeze Bridge drives `endofpacket`, `valid`, or `channel` outputs to the static region, the Freeze Bridge reads the `ready_latency` value. The `ready_latency` value defines the actual clock cycle when the sink component is ready for data.

Figure 74. Source Bridge Handling of Unfinished Packet Transaction During Freeze

Figure 75. PR Freeze Bridge Asserting valid Signal to End Packet Transactions

Table 54. Avalon^® -ST Sink Freeze Bridge Interface Behavior
Interface Type	Behavior
Sink interface in PR region	For transactions that includes packet transfers, when the `freeze` signal goes high, the Freeze Bridge holds the `ready` signal high to the static region source until any unfinished transaction completes. For transactions that do not include packet transfers, when the `freeze` signal goes high, the Freeze Bridge holds the `ready` signal low during the freeze period. The `illegal_request` signal asserts high to indicate that the current transaction is an error. Configure the design to stop sending transactions to the PR region after the `illegal_request` signal is high.
Sink interface in PR region with ready_latency > 0	When the Freeze Bridge drives `endofpacket`, `valid`, or `channel` outputs to the PR region, the Freeze Bridge must observe the `ready_latency` value. The `ready_latency` value defines the actual clock cycle when the sink component is ready for data.

Parameters

The Avalon-ST Partial Reconfiguration Freeze Bridge IP core supports customization of the following parameters.

Figure 76. Parameter Editor

Table 55. Parameters
Parameter	Values	Description
PR region Interface Type	Avalon-ST Source/Avalon-ST Sink	Specifies the interface type for interfacing the PR region with the freeze bridge.
Enable Freeze port from PR region	On/Off	Enables the freeze port to freeze all the outputs of each PR region to a known constant value. Freezing prevents the signal receivers in the static region from receiving undefined signals during the partial reconfiguration process.
Select Yes or No to enable or disable interface ports	Yes/No	Enables or disables specific optional freeze bridge interface ports.
Channel width	`<1-128>`	Specifies the width of the channel signal.
Error width	`<1-256>`	Specifies the width of the error signal.
Data bits per symbol	`<1-512>`	Specifies the number of bits per symbol.
Symbols per beat	`<1-512>`	Specifies the number of symbols that transfer on every valid clock cycle.
Error descriptors	`<text>`	Specifies one or more strings to describe the error condition for each bit of the error port on the sink interface connected to the source interface. Click the plus or minus buttons to add or remove descriptors.
Max channel number	`<0-255>`	Specifies the maximum number of output channels.
Ready latency	`<0-8>`	Specifies what ready latency to expect from the source interface connected to the sink interface. The ready latency is the number of cycles from the time `ready` asserts until valid data is driven.

Ports

The Avalon-ST Partial Reconfiguration Freeze Bridge IP has the following ports.

Figure 77. Avalon^® -ST Sink Interface Ports

Figure 78. Avalon^® -ST Source Interface Ports

Table 56. Avalon-ST Partial Reconfiguration Freeze Bridge Interface Ports
Port	Width	Direction	Description
`clock`	1	Input	Input clock for the IP.
`freeze_conduit_freeze`	1	Input	When this signal is high, the bridge handles any current transaction properly then freezes the PR interfaces.
`freeze_conduit_illegal_request`	1	Output	High on this bus indicates that an illegal request was issued to the bridge during the freeze state. `n` – number of freeze bridge
`pr_freeze_pr_freeze`	1	Input	Enabled freeze port from the PR region.
`reset_n`	1	Input	Synchronous reset for the IP.

Table 57. Avalon^® -ST Sink to Static Region Interface PortsSame setting as Avalon^® -ST sink to PR region interface.
Port	Width	Direction	Description
`sink_bridge_to_sr_channel`	1	Input	Avalon^® -ST sink bridge to static region `channel` port.
`sink_bridge_to_sr_data`	32	Input	Avalon^® -ST sink bridge to static region `data` port.
`sink_bridge_to_sr_empty`	2	Input	Avalon^® -ST sink bridge to static region `empty` port.
`sink_bridge_to_sr_error`	1	Input	Avalon^® -ST sink bridge to static region `error` port.
`sink_bridge_to_sr_ready`	1	Output	Avalon^® -ST sink bridge to static region `ready` port.
`sink_bridge_to_sr_valid`	1	Input	Avalon^® -ST sink bridge to static region `valid` port.
`sink_bridge_to_sr_endofpacket`	1	Input	Avalon^® -ST sink bridge to static region `endofpacket` port.
`sink_bridge_to_sr_startofpacket`	1	Input	Avalon^® -ST sink bridge to static region `startofpacket` port.

Table 58. Avalon^® -ST Sink to PR Region Interface Ports
Port	Width	Direction	Description
`sink_bridge_to_pr_channel`	1	Output	Optional Avalon^® -ST sink bridge to PR region `channel` port.
`sink_bridge_to_pr_data`	32	Output	Optional Avalon^® -ST sink bridge to PR region `data` port.
`sink_bridge_to_pr_empty`	2	Output	Optional Avalon^® -ST sink bridge to PR region `empty` port.
`sink_bridge_to_pr_error`	1	Output	Optional Avalon^® -ST sink bridge to PR region `error` port.
`sink_bridge_to_pr_ready`	1	Input	Optional Avalon^® -ST sink bridge to PR region `ready` port.
`sink_bridge_to_pr_valid`	1	Output	Optional Avalon^® -ST sink bridge to PR region `valid` port.
`sink_bridge_to_pr_endofpacket`	1	Output	Optional Avalon^® -ST sink bridge to PR region `endofpacket` port.
`sink_bridge_to_pr_startofpacket`	1	Output	Optional Avalon^® -ST sink bridge to PR region `startofpacket` port.

Table 59. Avalon^® -ST Source to Static Region Interface PortsSame setting as Avalon^® -ST source to PR region interface.
Port	Width	Direction	Description
`source_bridge_to_sr_channel`	1	Output	Avalon^® -ST source bridge to static region `channel` port.
`source_bridge_to_sr_data`	32	Output	Avalon^® -ST source bridge to static region `data` port.
`source_bridge_to_sr_empty`	2	Output	Avalon^® -ST source bridge to static region `empty` port.
`source_bridge_to_sr_error`	1	Output	Avalon^® -ST source bridge to static region `error` port.
`source_bridge_to_sr_ready`	1	Input	Avalon^® -ST source bridge to static region `ready` port.
`source_bridge_to_sr_valid`	1	Output	Avalon^® -ST source bridge to static region `valid` port.
`source_bridge_to_sr_endofpacket`	1	Output	Avalon^® -ST source bridge to static region `endofpacket` port.
`source_bridge_to_sr_startofpacket`	1	Output	Avalon^® -ST source bridge to static region `startofpacket` port.

Table 60. Avalon^® -ST Source to PR Region Interface Ports
Port	Width	Direction	Description
`source_bridge_to_pr_channel`	1	Input	Optional Avalon^® -ST source bridge to PR region `channel` port.
`source_bridge_to_pr_data`	32	Input	Optional Avalon^® -ST source bridge to PR region `data` port.
`source_bridge_to_pr_empty`	2	Input	Optional Avalon^® -ST source bridge to PR region `empty` port.
`source_bridge_to_pr_error`	1	Input	Optional Avalon^® -ST source bridge to PR region `error` port.
`source_bridge_to_pr_ready`	1	Output	Optional Avalon^® -ST source bridge to PR region `ready` port.
`source_bridge_to_pr_valid`	1	Input	Optional Avalon^® -ST source bridge to PR region `valid` port.
`source_bridge_to_pr_endofpacket`	1	Input	Optional Avalon^® -ST source bridge to PR region `endofpacket` port.
`source_bridge_to_pr_startofpacket`	1	Input	Optional Avalon^® -ST source bridge to PR region `startofpacket` port.

Generating and Simulating Intel FPGA IP

Use the following information to generate and simulate an IP core variation.

Generating IP Cores ( Intel Quartus Prime Pro Edition)

Quickly configure Intel^® FPGA IP cores in the Intel^® Quartus^® Prime parameter editor. Double-click any component in the IP Catalog to launch the parameter editor. The parameter editor allows you to define a custom variation of the IP core. The parameter editor generates the IP variation synthesis and optional simulation files, and adds the .ip file representing the variation to your project automatically.

Follow these steps to locate, instantiate, and customize an IP core in the parameter editor:

Create or open an Intel^® Quartus^® Prime project (.qpf) to contain the instantiated IP variation.
In the IP Catalog (Tools > IP Catalog), locate and double-click the name of the IP core to customize. To locate a specific component, type some or all of the component’s name in the IP Catalog search box. The New IP Variation window appears.
Specify a top-level name for your custom IP variation. Do not include spaces in IP variation names or paths. The parameter editor saves the IP variation settings in a file named <your_ip> .ip. Click OK. The parameter editor appears.

Figure 79. IP Parameter Editor ( Intel^® Quartus^® Prime Pro Edition)
Set the parameter values in the parameter editor and view the block diagram for the component. The Parameterization Messages tab at the bottom displays any errors in IP parameters:
- Optionally, select preset parameter values if provided for your IP core. Presets specify initial parameter values for specific applications.
- Specify parameters defining the IP core functionality, port configurations, and device-specific features.
- Specify options for processing the IP core files in other EDA tools.
Note: Refer to your IP core user guide for information about specific IP core parameters.
Click Generate HDL. The Generation dialog box appears.
Specify output file generation options, and then click Generate. The synthesis and simulation files generate according to your specifications.
To generate a simulation testbench, click Generate > Generate Testbench System. Specify testbench generation options, and then click Generate.
To generate an HDL instantiation template that you can copy and paste into your text editor, click Generate > Show Instantiation Template.
Click Finish. Click Yes if prompted to add files representing the IP variation to your project.
After generating and instantiating your IP variation, make appropriate pin assignments to connect ports.

Note: Some IP cores generate different HDL implementations according to the IP core parameters. The underlying RTL of these IP cores contains a unique hash code that prevents module name collisions between different variations of the IP core. This unique code remains consistent, given the same IP settings and software version during IP generation. This unique code can change if you edit the IP core's parameters or upgrade the IP core version. To avoid dependency on these unique codes in your simulation environment, refer to Generating a Combined Simulator Setup Script.

Running the Freeze Bridge Update script

When instantiating the Freeze Bridge as a Platform Designer system component, the interface connections between the Freeze Bridge and the PR region must match, so that Platform Designer inserts no extra interconnect during system generation.

Rather than manually matching the Avalon^® interface properties individually in the parameter editor, you can run the provided Update Freeze Bridge Parameters script to update Freeze Bridge Avalon^® interface properties automatically.

Running this script updates the master and slave interfaces or the sink and source interfaces of the Freeze Bridge, according to the Avalon^® property settings of the connecting PR region component.

To run the Update Freeze Bridge Parameters script:

Open a Platform Designer system containing one or more instances of the Freeze Bridge component.
In Platform Designer, click View > System Scripting. The System Scripting tab displays Platform Designer Built-in Scripts.
To update all freeze bridges in your Platform Designer system, set update_all_freeze_bridges to 1 in the Additional Commands section of the script. To update only a single freeze bridge, click the freeze bridge instance.
Click Run Script. The script runs and updates the freeze bridge parameters.

Figure 80. Platform Designer System Scripting Tab

IP Core Generation Output ( Intel Quartus Prime Pro Edition)

The Intel^® Quartus^® Prime software generates the following output file structure for individual IP cores that are not part of a Platform Designer system.

Figure 81. Individual IP Core Generation Output ( Intel^® Quartus^® Prime Pro Edition)

Table 61. Output Files of Intel^® FPGA IP Generation
File Name	Description
<`your_ip`>.ip	Top-level IP variation file that contains the parameterization of an IP core in your project. If the IP variation is part of a Platform Designer system, the parameter editor also generates a .qsys file.
<`your_ip`>.cmp	The VHDL Component Declaration (.cmp) file is a text file that contains local generic and port definitions that you use in VHDL design files.
<`your_ip`>_generation.rpt	IP or Platform Designer generation log file. Displays a summary of the messages during IP generation.
<`your_ip`>.qgsimc (Platform Designer systems only)	Simulation caching file that compares the .qsys and .ip files with the current parameterization of the Platform Designer system and IP core. This comparison determines if Platform Designer can skip regeneration of the HDL.
<`your_ip`>.qgsynth (Platform Designer systems only)	Synthesis caching file that compares the .qsys and .ip files with the current parameterization of the Platform Designer system and IP core. This comparison determines if Platform Designer can skip regeneration of the HDL.
<`your_ip`>.csv	Contains information about the upgrade status of the IP component.
`<your_ip>`.bsf	A symbol representation of the IP variation for use in Block Diagram Files (.bdf).
<`your_ip`>.spd	Input file that `ip-make-simscript` requires to generate simulation scripts. The .spd file contains a list of files you generate for simulation, along with information about memories that you initialize.
<`your_ip`>.ppf	The Pin Planner File (.ppf) stores the port and node assignments for IP components you create for use with the Pin Planner.
<`your_ip`>_bb.v	Use the Verilog blackbox (_bb.v) file as an empty module declaration for use as a blackbox.
<`your_ip`>_inst.v or _inst.vhd	HDL example instantiation template. Copy and paste the contents of this file into your HDL file to instantiate the IP variation.
<`your_ip`>.regmap	If the IP contains register information, the Intel^® Quartus^® Prime software generates the .regmap file. The .regmap file describes the register map information of master and slave interfaces. This file complements the .sopcinfo file by providing more detailed register information about the system. This file enables register display views and user customizable statistics in System Console.
<`your_ip`>.svd	Allows HPS System Debug tools to view the register maps of peripherals that connect to HPS within a Platform Designer system. During synthesis, the Intel^® Quartus^® Prime software stores the .svd files for slave interface visible to the System Console masters in the .sof file in the debug session. System Console reads this section, which Platform Designer queries for register map information. For system slaves, Platform Designer accesses the registers by name.
<`your_ip`>.v <`your_ip`>.vhd	HDL files that instantiate each submodule or child IP core for synthesis or simulation.
mentor/	Contains a msim_setup.tcl script to set up and run a ModelSim* simulation.
aldec/	Contains a Riviera-PRO* script rivierapro_setup.tcl to setup and run a simulation.
/synopsys/vcs /synopsys/vcsmx	Contains a shell script vcs_setup.sh to set up and run a VCS* simulation. Contains a shell script vcsmx_setup.sh and synopsys_sim.setup file to set up and run a VCS* MX simulation.
/cadence	Contains a shell script ncsim_setup.sh and other setup files to set up and run an NCSim simulation.
/xcelium	Contains an Xcelium* Parallel simulator shell script xcelium_setup.sh and other setup files to set up and run a simulation.
/submodules	Contains HDL files for the IP core submodule.
<`IP submodule`>/	Platform Designer generates /synth and /sim sub-directories for each IP submodule directory that Platform Designer generates.

Intel Arria 10 PR Control Block Simulation Model

The Intel^® Quartus^® Prime Pro Edition software supports simulating the delivery of a partial reconfiguration bitstream to the PR control block. This simulation allows you to observe the resulting change and the intermediate effect in a reconfigurable partition.

The Intel^® Arria^® 10 PR control block supports PR simulation. Sending a simulation RBF (PR bitstream) allows the PR control block to behave accordingly, to PR simulation success or PR simulation failure. To activate simulation of a specific PR persona in your PR region simulation wrapper, use a PR ID encoded in the simulation RBF, in conjunction with the PR control block. Simulate the PR control block either as standalone, or as part of the simulation file set for the Intel^® Arria^® 10 Partial Reconfiguration Controller IP core.

Figure 82. Intel^® Arria^® 10 PR Control Block Simulation Model

The Intel^® Arria^® 10 PR control block simulation model contains two additional simulation-only ports—sim_state and sim_pr_id. Connect these simulation ports, and the other ports, to the twentynm_prblock_if SystemVerilog interface. This connection allows monitoring of the PR control block using your testbench’s PR control block monitor. The Intel^® Quartus^® Prime software automatically instantiates the twentynm_prblock_if interface when generating the simulation file set of the Intel^® Arria^® 10 Partial Reconfiguration IP core. Obtain a reference to the twentynm_prblock_if that the IP instantiates by using the alt_pr_test_pkg::twentynm_prblock_if_mgr singleton, as shown in the following example:

virtual twentynm_prblock_if prblock_if;

alt_pr_test_pkg::twentynm_prblock_if_mgr cb_mgr;

// Get the PR control block from the prblock manager
cb_mgr = alt_pr_test_pkg::twentynm_prblock_if_mgr::get();
prblock_if = cb_mgr.if_ref;

The code for the twentynm_prblock_if interface is as follows:

interface twentynm_prblock_if(input logic pr_clk, input logic clk);

    logic prrequest;
    logic [31:0] data;
    wire error;
    wire ready;
    wire done;
    logic [31:0] sim_only_state;
    wire [31:0] sim_only_pr_id;

    // All signals are async except data
	clocking cb1 @(posedge pr_clk);
        output data;
    endclocking
    
endinterface : twentynm_prblock_if

For more information on the twentynm_prblock_if interface, refer to the <installation directory> /eda/sim_lib/altera_lnsim.sv file.

The simulation state of the Intel^® Arria^® 10 PR control block simulation model represents the PR_EVENT_TYPE enumeration state of the control block. The twentynm_prblock_test_pkg SystemVerilog package defines these enumerations. These states represent the different allowed states for the control block. The defined control block enumerations are:

package twentynm_prblock_test_pkg;
    typedef enum logic [31:0] {
        NONE,
        IDLE,
        PR_REQUEST,
        PR_IN_PROGRESS,
        PR_COMPLETE_SUCCESS,
        PR_COMPLETE_ERROR,
        PR_INCOMPLETE_EARLY_WITHDRAWL,
        PR_INCOMPLETE_LATE_WITHDRAWL
    } PR_EVENT_TYPE;

When the simulation state is PR_IN_PROGRESS, the affected PR region must have its simulation output multiplexes driven to X, by asserting the pr_activate signal. This action simulates the unknown outputs of the PR region during partial reconfiguration. In addition, you must assert the pr_activate signal in the PR simulation model to load all registers in the PR model with the PR activation value.

Once the simulation state reaches PR_COMPLETE_SUCCESS, activate the appropriate PR persona using the appropriate PR region simulation wrapper mux sel signals. You can decode the region, as well as the specific select signal from the sim_only_pr_id signal of the PR control block. This ID corresponds to the encoded ID in the simulation RBF.

Table 62. Required Sequence of Words in Simulation RBFStep 1 writes zero or more of the following words. All other steps write only 1 word.
1	zero padding blocks	0x00000000
2	`PR_HEADER_WORD`	0x0000A65C
3	`PR_ID`	32-bit user ID
4	`PRDATA_COUNT_0`	0x01234567
5	`PRDATA_COUNT_1`	0x89ABCDEF
6	`PRDATA_COUNT_2`	0x02468ACE
7	`PRDATA_COUNT_3`	0x13579BDF

Note: The PR_ID word is output on the sim_only_pr_id word, starting at PRDATA_COUNT_0. Using a different value for the header or data count results in PR simulation errors.

Generating the PR Persona Simulation Model

Use the Intel^® Quartus^® Prime EDA Netlist Writer to create the simulation model for a PR persona. The simulation model represents the post-synthesis, gate-level netlist for the persona.

When using the PR simulation model for the persona, the netlist includes a new altera_sim_pr_activate top-level signal for the model. You can asynchronously drive this signal to load all registers in the model with X. This feature allows you to verify the reset sequence of the new persona on PR event completion. Verify the reset sequence through inspection, using SystemVerilog assertions, or using other checkers.

By default, the PR simulation model asynchronously loads X into the register’s storage element on pr_activate signal assertion. You can parameterize this behavior on a per register basis, or on a simulation-wide default basis. The simulation model supports four built-in modes:

load X
load 1
load 0
load rand

Specify these modes using the SystemVerilog classes:

dffeas_pr_load_x
dffeas_load_1
dffeas_load_0
dffeas_load_rand

Optionally, you can create your own PR activation class, where your class must define the pr_load variable to specify the PR activation value.

Follow these steps to generate the simulation model for a PR design:

Open the base revision of a PR project in Intel^® Quartus^® Prime Pro Edition, and then click Processing > Start > Start Analysis & Synthesis. Alternatively, run this command-line equivalent:
```
quartus_syn <project name> -c <base revision name>
```
After synthesis is complete, click Project > Export Design Partition, and then select the root partition for the Partition name, and select synthesized for the Snapshot. Click OK. Alternatively, run this command-line equivalent:
```
quartus_cdb <project name> -c <base revision name> \
     "--export_block root_partition --snapshot synthesized \
     --file <static qdb name>
```
Click Project > Revisions and switch the current revision to that of the persona you want to export.
Click Processing > Start > Start Analysis & Synthesis. Alternatively, run this command-line equivalent:
```
quartus_syn <project name> -c <persona revision name>
```

After synthesis of the persona revision completes, execute the following at the command line to generate the PR simulation model:

quartus_eda <project name> –c <persona revision name> "--pr --simulation \
     --tool=modelsim --format=verilog --partition=<pr partition name> \
     --module=<partition name>=<persona module name>

Repeat steps 3 through 5 for all personas that you want to simulate.

Complete PR Simulation Model Generation Script

quartus_syn <project name> -c <base revision name>
quartus_cdb <project name> -c <base revision name> \
     "--export_block root_partition --snapshot synthesized \
     --file <static qdb name>
quartus_syn <project name> -c <persona revision name>
quartus_eda <project name> –c <persona revision name> \
     "--pr --simulation --tool=modelsim --format=verilog \
     --partition=<pr partition name> --module=<partition name>=\
     <persona module name>

Intel Quartus Prime Pro Edition User Guide: Partial Reconfiguration Archive

If the table does not list a software version, the user guide for the previous software version applies.

Intel^® Quartus^® Prime Version	User Guide
18.1	Intel^® Quartus^® Prime Pro Edition User Guide: Partial Reconfiguration
18.0	Intel^® Quartus^® Prime Pro Edition User Guide: Partial Reconfiguration

Partial Reconfiguration Solutions IP User Guide Revision History

Document Version	Intel^® Quartus^® Prime Version	Changes
2019.04.22	19.1.0	Indicated support for POF generation support for Intel Cyclone GX devices.
2019.01.04	18.1.0	Clarified statement about configuration width in "Control Block Signals" topic.
2018.12.07	18.1.0	Corrected typographical error in "Partial Reconfiguration IP Cores" table. Corrected typographical error in " Avalon^® -MM Slave to PR Region Master Interface Ports" table.
2018.09.24	18.1.0	Updated specification for Partial Reconfiguration Controller Intel^® Stratix^® 10 FPGA IP from 250 MHz to 200 MHz. Stated PR compilation flow support for Intel^® Cyclone^® 10 GX devices. Updated Partial Reconfiguration Controller Intel^® Arria^® 10 FPGA IP name to Partial Reconfiguration Controller Intel^® Arria^® 10/Cyclone 10 FPGA IP.
2018.06.27	18.0.0	Updated `freeze_status` signal description in Registers: Partial Reconfiguration Region Controller .
2018.06.18	18.0.0	Corrected syntax error in Generating the PR Persona Simulation Model.
2018.05.07	18.0.0	Added description of new Partial Reconfiguration External Configuration Controller Intel^® Stratix^® 10 FPGA IP. Updated names of Partial Reconfiguration Controller Intel^® Arria^® 10 FPGA IP and Partial Reconfiguration Controller Intel^® Stratix^® 10 FPGA IP. Enhanced explanation of Auto-instantiate CRC block Partial Reconfiguration Controller Intel^® Arria^® 10 parameter. Added as chapter in new Partial Reconfiguration User Guide. Added note about recovery after PR error when using SEU detection in Intel^® Stratix^® 10 designs.
2017.11.06	17.1.0	Added support for Intel^® Stratix^® 10 Partial Reconfiguration Controller IP core. Updated for latest Intel^® product naming conventions.
2017.05.08	17.0.0	Initial public release.

Intel Quartus Prime Pro Edition User Guides

Refer to the following user guides for comprehensive information on all phases of the Intel^® Quartus^® Prime Pro Edition FPGA design flow.

Hierarchical Partial Reconfiguration

Static Update Partial Reconfiguration

Partial Reconfiguration Design Simulation

FPGA Device and Software Considerations

Design Partition Considerations

Clocking, Reset, and Freeze Signal Considerations

Method 1 (Preferred): Specify Unique Entity and File Names for Each Persona

Method 2: Parametrize a Single File as PR Persona

Verilog RTL for Clock Enable

VHDL RTL for Clock Enable

Programming File Generation for a Partial Reconfiguration Design

Generating PR Bitstreams During Compilation

Generating PR Bitstreams with Programming File Generator

Generating PR Bitstreams with Convert Programming Files Dialog Box

Intel® Stratix® 10 PR Bitstream Compatibility Checking

Intel® Arria® 10 PR Bitstream Compatibility Checking

RTL Wrapper for PR Persona Switching Simulation

PR Migration Scenario

PR Migration Requirements

PR Migration Scenario

PR Migration Requirements

PR Migration Scenario

PR Migration Scenario

PR Migration Scenario

PR Migration Requirements

Partial Reconfiguration Controller Intel® Stratix® 10 FPGA IP

Successful PR Session ( Intel Arria 10 Example)

Unsuccessful PR Session with Configuration Frame Readback Error ( Intel Arria 10 Example)

Unsuccessful PR Session with PR_ERROR ( Intel Arria 10 Example)

Late Withdrawal PR Session ( Intel Arria 10 Example)

Verilog RTL for External Host PR

VHDL RTL for External Host PR

Complete PR Simulation Model Generation Script

Intel^® Stratix^® 10 PR Bitstream Compatibility Checking

Intel^® Arria^® 10 PR Bitstream Compatibility Checking

Partial Reconfiguration Controller Intel^® Stratix^® 10 FPGA IP