Configuration via Protocol (CvP) is a configuration scheme supported in Arria® V, Cyclone® V, Stratix® V, and Arria® 10 device families. The CvP configuration scheme creates separate images for the periphery and core logic. You can store the periphery image in a local configuration device and the core image in the host memory, reducing system costs and increasing the security for the proprietary core image. CvP configures the FPGA fabric through the PCI Express® (PCIe) link and it is available for Endpoint variants only. CvP allows the PCIe endpoint to wake up within 200 ms.
- Reduces system costs by reducing the size of the local flash device used to store the periphery configuration data.
- Improves security for the proprietary core bitstream. CvP ensures that the PCIe host can exclusively access the FPGA core image.
- Provides a simpler software model for configuration. A smart host can use the PCIe protocol and the application topology to initialize and update the FPGA fabric.
- Facilitates hardware acceleration.
The following figure shows the required components for a CvP system.
A CvP system typically consists of an FPGA, a PCIe host, and a configuration device.
- The configuration device is connected to the FPGA using the conventional configuration interface. The configuration interface can be any of the supported schemes, such as active serial (AS), passive serial (PS), or fast passive parallel (FPP). The choice of the configuration device depends on your chosen configuration scheme.
- PCIe Hard IP block (bottom left) for CvP and other PCIe applications.
- PCIe Hard IP block only for PCIe applications and cannot be used for CvP.
Most Arria® 10 FPGAs include more than one Hard IP block for PCI Express. The CvP configuration scheme can only utilize the bottom left PCIe Hard IP block on each device. It must be configured as an Endpoint.
|Device||CvP Modes Supported|
|PCIe Gen 1||PCIe Gen 2||PCIe Gen 3|
|Arria 10||CvP initialization||CvP initialization||CvP initialization|
In CvP, you partition your design into two images: core image and periphery image.
- Periphery image (*.periph.jic) — contains general purpose I/Os (GPIOs), I/O registers, the GCLK, QCLK, and RCLK clock networks, and logic that is implemented in hard IP such as the JTAG interface, PR block, CRC block, Oscillator block, Impedance control block, Chip ID, ASMI block, Remote update block, Temperature sensor, and Hard IP for PCI Express IP Core. These components are included in the periphery image because they are controlled by I/O periphery register bits. The entire periphery image is static and cannot be reconfigured.
- Core image (*.core.rbf) —
contains logic that is programmed by configuration RAM (CRAM). This image includes LABs,
DSP, and embedded memory. The
core image may include
- Reconfigurable region — This region can be programmed in user mode while the PCIe link is up and fully enumerated. It must contain only resources that are controlled by CRAM such as LABs, embedded RAM blocks, and DSP blocks in the FPGA core image. It cannot contain any periphery components such as GPIOs, transceivers, PLL, I/O blocks, the Hard IP for PCI Express IP Core, or other components included in the periphery image.
- Static region — This region cannot be modified.
The periphery image is stored in an external configuration device and is loaded into the FPGA through the conventional configuration scheme. The core image is stored in a host memory and loaded into the FPGA through the PCIe link. All other periphery and core resources are frozen until the FPGA enters user mode.
After the periphery image configuration is complete, the CONF_DONE signal goes high and allows the FPGA to start PCIe link training. During PCIe link training, the FPGA is not in user mode. When PCIe link training is complete, the PCIe link transitions to L0 state and then through PCIe enumeration. The PCIe host then initiates the core image configuration through the PCIe link.
After the core image configuration is complete, the CvP_CONFDONE pin goes high, indicating the FPGA is fully configured.
After the FPGA is fully configured, the FPGA enters user mode. If the INIT_DONE signal is enabled, the INIT_DONE signal goes high after initialization is complete and the FPGA enters user mode.
In user mode, the PCIe links are available for normal PCIe applications. You can also use PR over PCI Express to change re-configurable regions within the single CvP core image.
You can choose to compress the core image by turning on the Generate compressed bitstream option in the Configuration page of the Device and Pin Options dialog box in the Quartus Prime software. The periphery image cannot be compressed. Compressing the core image reduces the storage requirement.
You can choose to encrypt the core image. The periphery image cannot be encrypted. To configure the FPGA with an encrypted core image, you must pre-program the FPGA with a security key. This key is then used to decrypt the incoming configuration bitstream.
|Key Types||Active Serial||Passive Serial||Fast Passive Parallel|
|External Clock||Internal Clock||External Clock||External Clock|
|Non-volatile key||No||12.5 MHz||Yes||Yes|
|Pin Name||Pin Type||Pin Description||Pin Connection|
The CvP_CONFDONE pin is driven low during configuration. When configuration via PCIe is complete, this signal is released and either actively driven high, or pulled high by an external pull-up resistor.
During FPGA configuration in CvP initialization mode, you must observe this pin after the CONF_DONE pin goes high to determine if the FPGA is successfully configured.
If you are not using the CvP modes, you can use this pin as a user I/O pin.
If this pin is set as dedicated output, the VCCPGM power supply must meet the input voltage specification of the receiving side.
If this pin is set as an open-drain output, connect the pin to an external 10-kΩ pull-up resistor to the VCCPGM power supply or a different pull-up voltage that meets the input voltage specification of the receiving side. This gives an advantage on the voltage leveling.
enable this pin, a transition from low to high at the pin indicates
the device has entered user mode. If the INIT_DONE output is enabled, the INIT_DONE pin cannot be used as a user
I/O pin after configuration.
This is a dual-purpose pin and can be used as an I/O pin when not enabled as the INIT_DONE pin.
use the optionally open-drain output dedicated INIT_DONE pin, connect this pin to an
external 10-kΩ pull-up resistor to VCCPGM.
When you use this pin in an AS or PS multi-device configuration mode, ensure you enable the INIT_DONE pin in the Quartus® Prime designs. When you do not use the dedicated INIT_DONE optionally open-drain output, and when this pin is not used as an I/O pin, connect this pin as defined in the Quartus® Prime software.
|CONF_DONE||Bidirectional||Dedicated configuration done pin.
As a status output, the CONF_DONE pin drives low before and during configuration. After all configuration data is received without error and the initialization cycle starts, CONF_DONE is released.
As a status input, the CONF_DONE pin goes high after all data is received. Then the device initializes and enters user mode. This pin is not available as a user I/O pin.
an external 10-kΩ pull-up resistors to VCCPGM. VCCPGM must be high
enough to meet the VIH specification of the I/O on the device and
the external host.
When you use passive configuration schemes, the configuration controller monitors this pin.
This pin is connected to the Hard IP for PCI Express IP Core as a dedicated fundamental reset pin for PCIe usage. If the signal is low, the transceivers and dedicated PCIe Hard IP block that you use for CvP operation are in the reset mode.
Connect the nPERST[L,R]0/nPERST[L,R]1 to the PERST# pin of the PCIe slot. This pin is powered by 1.8V supply and must be driven by 1.8V compatible I/O standards.
Only one nPERST pin is used per PCIe Hard IP. These pins have the following locations:
FPGA Power Supplies Ramp Time Requirement
For an open system, you must ensure that your design adheres to the FPGA power supplies ramp-up time requirement.
The power-on reset (POR) circuitry keeps the FPGA in the reset state until the power supply outputs are in the recommended operating range. A POR event occurs from when you power up the FPGA until the power supplies reach the recommended operating range within the maximum power supply ramp time, tRAMP . If tRAMP is not met, the device I/O pins and programming registers remain tri-stated, during which device configuration could fail.
For CvP, the total tRAMP must be less than 10 ms, from the first power supply ramp-up to the last power supply ramp-up. You must select fast POR by setting the PORSEL pin to high. The fast POR delay time is in the range of 4–12 ms, allowing sufficient time after POR for the PCIe link to start initialization and configuration.
PCIe Wake-Up Time Requirement
For an open system, you must ensure that the PCIe link meets the PCIe wake-up time requirement as defined in the PCI Express CARD Electromechanical Specification. The transition from power-on to the link active (L0) state for the PCIe wake-up timing specification must be within 200 ms. The timing from FPGA power-up until the Hard IP for PCI Express IP Core in the FPGA is ready for link training must be within 120 ms.
PCIe Wake-Up Time Requirement for CvP Initialization
For CvP initialization mode, the Hard IP for PCI Express IP core is guaranteed to meet the 120 ms requirement because the periphery image configuration time is significantly less than the full FPGA configuration time. Therefore, you can choose any of the conventional configuration schemes for the periphery image configuration.
To ensure successful configuration, all POR-monitored power supplies must ramp up monotonically to the operating range within the 10 ms ramp-up time. The PERST# signal indicates when the FPGA power supplies are within their specified voltage tolerances and the REFCLK is stable. The embedded hard reset controller triggers after the internal status signal indicates that the periphery image has been loaded. This reset does not trigger off of PERST#. For CvP initialization mode, the PCIe link supports the FPGA core image configuration and PCIe applications in user mode.
|Timing Sequence||Timing Range (ms)||Description|
|a||10||Maximum ramp-up time requirement for all POR-monitored power supplies in the FPGA to reach their respective operating range.|
|b||4–12||FPGA POR delay time.|
|c||100||Minimum PERST# signal active time from the host.|
|d||20||Minimum PERST# signal inactive time from the host before the PCIe link enters training state.|
|e||120||Maximum time from the FPGA power up to the end of periphery configuration in CvP initialization mode.|
|f||100||Maximum time PCIe device must enter L0 after PERST# is deasserted.|
CvP initialization divides the design into periphery and core images. The periphery image is stored in a local flash device on the PCB. You can program the periphery through JTAG. The core image is stored in host memory. You must download the core image to the FPGA using the PCI Express link.
Follow these steps to generate the synthesis HDL files with CvP enabled:.
- On the Tools menu, select Qsys.
- Open .qsys file of the project.
- On the System Contents tab, right-click Arria 10 Hard IP for PCI Express and select Edit.
Under System Settings, turn on Enable
Configuration via Protocol as shown in the following figure:
Figure 5. Illustrating the specified option in Systems Setting dialog box
- Click Finish.
- On the Generation tab, specify your parameters to generate RTL. Then click Generate at the bottom of the window.
Follow these steps to specify CvP parameters:
- On the Quartus Prime Assignments menu, select Device, and then click Device and Pin Options.
Under Category select General, and then enable the following
Leave all other options disabled.
- Auto-restart configuration after error, enable this option to allow automatic restart of configuration attempts if an error is detected. Any restarted configuration may exceed the required PCIe startup time to allow bus enumeration and prevent the use of quartus_cvp for core programming.
select CvP Settings, and specify the following
Parameter Value Configuration via Protocol Core initialization Enable CvP_CONFDONE pin Turn this option on. Enable open drain on CvP_CONFDONE pin Turn this option on.Figure 6. Illustrating the specified CvP parameters in Device and Pin options dialog box
Follow these steps to split your .SOF file into separate images for the periphery and core logic.
- After the .SOF file is generated, under File menu, select Convert Programming File.
Under Output programming file section, specify the
Parameter Value Programming file type JTAG Indirect Configuration File (*.jic) Configuration device EPCQL1024 Mode Active Serial File name *.jic Create Memory Map File Turn this option on. Create CvP files Turn this option on. This box is greyed out until you specify the SOF Data file under Input files to convert.
Under Input files to convert, specify the following parameters:
Parameter Value Flash Loader 10AX115S1F45I1SG SOF Data *.sof
Make sure to turn on the Create CvP files.
Note: If you do not check this box, the Quartus Prime software does not create separate files for the periphery and core images.Figure 7. Illustrating the above specified options in the Convert Programming File GUI
- Click Generate to create *.periph.jic and *.core.rbf files.
- Arria 10 FPGA Development Kit
- USB Blaster
- A DUT PC with PCI Express slot to plug in the Arria 10 FPGA Development Kit
- A host PC running the Quartus Prime software to program the periphery image, .sof or .pof file
- Navigate to <Quartus Prime installation path>\quartus\drivers\wdrvr\windows<32 or 64> .
Run the command:
- wdreg -inf windrvr6.inf install
- Copy the wdapi1021.dll file to the %windir%\system32 directory.
- Navigate to <Quartus Prime installation path>/quartus/drivers/wdrvr/linux<32 or 64> .
Run the following
- ./configure --disable-usb-support
- make install
- You can change the permissions for the device file. For example, chmod 666 /dev/windrvr6.
For 64-bit Linux
systems, set the
Quartus_64BIT environment variable before you run
quartus_cvp using the following command:
- export QUARTUS_64BIT=1
You can use the
quartus_cvp command to download
*core .rbf files to your FPGA. The following table lists the
quartus_cvp commands for all modes.
Table 5. Syntax for quartus_cvp Commands Mode quartus_cvp Command Uncompressed quartus_cvp --vid=<Vendor ID> --did=<Device ID> <Core .rbf file path> Unencrypted Compressed quartus_cvp -c --vid=<Vendor ID> --did=<Device ID> <Core .rbf file path> Encrypted quartus_cvp -e --vid=<Vendor ID> --did=<Device ID> <Core .rbf file path> Compressed and encrypted quartus_cvp -c -e --vid=<Vendor ID> --did=<Device ID> <Core .rbf file path>
|Configuration Scheme||VCCPGM (V)||Power-On Reset (POR) Delay||Valid MSEL[2..0]|
|JTAG-based configuration||—||—||Use any valid MSEL pin settings below|
|AS (x1 and x4)||1.8||Fast||010|
FPP (x8, x16, and x32)
You must program the periphery image (.periph.jic) and then download the core image (.core.rbf) using the PCIe Link. You can use JTAG to load different programming files (i.e. .sof/.jic/periph.pof) into your selected CvP initialization enabled Arria® 10 device.
After loading the periphery image via the JTAG port, the link should reach the expected data rate and link width. You can confirm the PCIe link status using the RW Utilities.Follow these steps to program and test the CvP functionality:
- Plug the Arria 10 FPGA Development Kit into the PCI Express slot of the DUT PC and power it ON. Altera recommends that you use the ATX power supply that the development kit includes.
- On the host PC, open the Quartus Prime Tools menu and select Programmer.
- Click Auto Detect to verify that the USB Blaster recognizes the Arria 10 FPGA.
Follow these steps to program the periphery image:
Figure 8. Illustrating the specified options to the program periphery image
- Select Arria 10 device, and then right click None under File column.
- Navigate to .periph.jic file and click Open.
- Under Program/Configure column, select the respective devices. For example, 10AX115S1E2 and EPCQL1024.
- Click start to program the periphery image into EPCQL1024 flash.
- After the .periph.jic is programmed, the FPGA must be powered cycle to allow the new peripheral image to load from the on-board flash into the FPGA. To force the host PC to re-enumerate the link with the new image, power cycle the DUT PC and the Arria 10 FPGA Development Kit.
- You can use RW Utilities or another system software driver to verify the link status. You can also confirm expected link speed and width.
Follow these steps to program the core image:
- Copy the .core.rbf file to appropriate Quartus Prime bin install directory. Depending on the 32-bit or 64-bit system, the folder is …./quartus/bin32 or …./quartus/bin64.
- Open a Command Prompt in Windows, change the directory to the same mentioned above where the file is copied.
Type the following command to program the core
quartus_cvp --vid=<Vendor ID> --did=<Device ID> xxx.core.rbf
where the value of Vendor ID and Device ID are in hexadecimal and specified in the Hard IP for PCI Express dialog box. For example, quartus_cvp --vid=1172 --did=e003 xxx.core.rbf.
The figure below shows the results of a successful CvP
Figure 9. Command Prompt Console
You can develop your own custom CvP driver for Linux using the sample Linux driver source code provided by Altera. The sample driver is written in C and can be downloaded from the Configuration via Protocol webpage.
You can also develop your own CvP driver using the Jungo WinDriver tool. You need to purchase a WinDriver license for this purpose.
The following figure shows the flow of the provided CvP driver. The flow assumes that the FPGA is powered up and the control block has already configured the FPGA with the periphery image, which is indicated by the CVP_EN bit in the CvP status register.
As this figure indicates, the third step of the Start Teardown Flow requires 244 dummy configuration writes to the CVP DATA register or 244 memory writes to an address defined by a memory space BAR for this device. Memory writes are preferred because they are higher throughput than configuration writes. The dummy writes cause a 2 ms delay, allowing the control block to complete required operations.
For high density devices such as Arria 10, it may be necessary to wait up to 500 ms for the CvP status register bit assertion.
The Vendor Specific Extended Capability (VSEC) registers occupy byte offset 0x200 to 0x240 in the PCIe Configuration Space. The PCIe host uses these registers to communicate with the FPGA control block. The following table shows the VSEC register map. Subsequent tables provide the fields and descriptions of each register.
|Byte Offset||Register Name|
|0x200||Altera-defined Vendor Specific Capability Header|
|0x204||Altera-defined Vendor Specific Header|
|0x220||CvP Mode Control|
|0x224||CvP Data 2|
|0x22C||CvP Programming Control|
|0x234||Uncorrectable Internal Error Status Register|
|0x238||Uncorrectable Internal Error Mask Register|
|0x23C||Correctable Internal Error Status Register|
|0x240||Correctable Internal Error Mask Register|
|[15:0]||PCI Express Extended Capability ID||0x000B||RO||PCIe specification defined value for VSEC Capability ID.|
|[19:16]||Version||0x1||RO||PCIe specification defined value for VSEC version.|
|[31:20]||Next Capability Offset||Variable||RO||Starting address of the next Capability Structure implemented, if any.|
|[15:0]||VSEC ID||0x1172||RO||A user configurable VSEC ID.|
|[19:16]||VSEC Revision||0||RO||A user configurable VSEC revision.|
|[31:20]||VSEC Length||0x044||RO||Total length of this structure in bytes.|
|[31:0]||Altera Marker||Device Value||RO||An additional marker. If you use the standard Altera Programmer software to configure the device with CvP, this marker provides a value that the programming software reads to ensure that it is operating with the correct VSEC.|
|||PLD_CORE_READY||Variable||RO||From FPGA fabric. This status bit is provided for debug.|
|||PLD_CLK_IN_USE||Variable||RO||From clock switch module to fabric. This status bit is provided for debug.|
|||CVP_CONFIG_DONE||Variable||RO||Indicates that the FPGA control block has completed the device configuration via CvP and there were no errors.|
|||USERMODE||Variable||RO||Indicates if the configurable FPGA fabric is in user mode.|
|||CVP_EN||Variable||RO||Indicates if the FPGA control block has enabled CvP mode.|
|||CVP_CONFIG_ERROR||Variable||RO||Reflects the value of this signal from the FPGA control block, checked by software to determine if there was an error during configuration.|
|||CVP_CONFIG_READY||Variable||RO||Reflects the value of this signal from the FPGA control block, checked by software during programming algorithm.|
This is the number of clocks to send for every CvP data write. This is also known as CDRATIO (clock to data ratio).
Set this field to one of the values below depending on your configuration image:
|||CVP_FULLCONFIG||1'b0||RW||A value of 1 indicates a request to the control block to reconfigure the entire FPGA including the Hard IP for PCI Express and bring the PCIe link down.|
|||HIP_CLK_SEL||1'b0||RW||Selects between PMA and fabric clock
when USER_MODE = 1 and PLD_CORE_READY = 1. The following encodings are
|||CVP_MODE||1'b0||RW||Controls whether the Hard IP for PCI
Express is in CVP_MODE or normal mode. The following encodings are
|[31:0]||CVP_DATA2||0x00000000||RW||Contains the upper 32 bits of a 64-bit configuration data. Software must ensure that all Bytes in both dwords are enabled. Use of 64-bit configuration data is optional.|
|[31:0]||CVP_DATA||0x00000000||RW||Write the configuration data to this
register. The data is transferred to the FPGA control block to configure
Every write to this register sets the data output to the FPGA control block and generates <n> clock cycles to the FPGA control block as specified by the CVP_NUM_CLKS field in the CvP Mode Control register. Software must ensure that all bytes in the memory write dword are enabled.You can access this register using configuration writes. Alternatively, when in CvP mode, this register can also be written by a memory write to any address defined by a memory space BAR for this device. Using memory writes are higher throughput than configuration writes.
|||START_XFER||1'b0||RW||Sets the CvP output to the FPGA control block indicating the start of a transfer.|
|||CVP_CONFIG||1'b0||RW||When set to 1, the FPGA control block begins a transfer via CvP.|
This register reports the status of the internally checked errors that are uncorrectable. When specific errors are enabled by the Uncorrectable Internal Error Mask register, they are handled as Uncorrectable Internal Errors as defined in the PCI Express Base Specification 3.0. This register is for debug only. Use this register to observe behavior, not to drive custom logic.
|||1'b0||RW1CS||A value of 1 indicates an RX buffer overflow condition in a posted request or Completion segment.|
|||1'b0||RW1CS||A value of 1 indicates a parity error was detected on the R2CSEB interface.|
|||1'b0||RW1CS||A value of 1 indicates a parity error was detected on the Configuration Space to TX bus interface.|
|||1'b0||RW1CS||A value of 1 indicates a parity error was detected on the TX to Configuration Space bus interface.|
|||1'b0||RW1CS||A value of 1 indicates a parity error was detected in a TX TLP and the TLP is not sent.|
|||1'b0||RW1CS||A value of 1 indicates that the Application Layer has detected an uncorrectable internal error.|
|||1'b0||RW1CS||A value of 1 indicates a configuration error has been detected in CvP mode which is reported as uncorrectable. This CVP_CONFIG_ERROR_LATCHED bit is set whenever a CVP_CONFIG_ERROR is asserted while in CVP_MODE.|
|||1'b0||RW1CS||A value of 1 indicates a parity error was detected by the TX Data Link Layer.|
|||1'b0||RW1CS||A value of 1 indicates a parity error has been detected on the RX to Configuration Space bus interface.|
|||1'b0||RW1CS||A value of 1 indicates a parity error was detected at input to the RX Buffer.|
|||1'b0||RW1CS||A value of 1 indicates a retry buffer uncorrectable ECC error.|
|||1'b0||RW1CS||A value of 1 indicates a RX buffer uncorrectable ECC error.|
This register controls which errors are forwarded as internal uncorrectable errors. With the exception of the configuration errors detected in CvP mode, all of the errors are severe and may place the device or PCIe link in an inconsistent state. The configuration error detected in CvP mode may be correctable depending on the design of the programming software.
|||1'b1||RWS||Mask for RX buffer posted and completion overflow error.|
|||1'b1||RWS||Mask for parity error on the R2CSEB interface.|
|||1'b1||RWS||Mask for parity error on the Configuration Space to TX bus interface.|
|||1'b1||RWS||Mask for parity error on the TX to Configuration Space bus interface.|
|||1'b1||RWS||Mask for parity error in the transaction layer packet.|
|||1'b1||RWS||Mask for parity error in the application layer.|
|||1'b0||RWS||Mask for configuration error in CvP mode.|
|||1'b1||RWS||Mask for data parity errors detected during TX Data Link LCRC generation.|
|||1'b1||RWS||Mask for data parity errors detected on the RX to Configuration Space Bus interface.|
|||1'b1||RWS||Mask for data parity error detected at the input to the RX Buffer.|
|||1'b1||RWS||Mask for the retry buffer uncorrectable ECC error.|
|||1'b1||RWS||Mask for the RX buffer uncorrectable ECC error.|
This register reports the status of the internally checked errors that are correctable. When these specific errors are enabled by the Correctable Internal Error Mask register, they are forwarded as Correctable Internal Errors as defined in the PCI Express Base Specification 3.0. This register is for debug only. Use this register to observe behavior, not to drive custom logic.
|||1'b0||RW1CS||A value of 1 indicates that the Application Layer has detected a correctable internal error.|
|||1'b0||RW1CS||A value of 1 indicates a configuration error has been detected in CvP mode, which is reported as correctable. This bit is set whenever a CVP_CONFIG_ERROR occurs while in CVP_MODE.|
|||1'b0||RW1CS||A value of 1 indicates a retry buffer correctable ECC error.|
|||1'b0||RW1CS||A value of 1 indicates an RX buffer correctable ECC error.|
This register controls which errors are forwarded as Internal Correctable Errors. This register is for debug only.
|||1'b0||RWS||Mask for corrected internal error reported by the Application Layer.|
|||1'b0||RWS||Mask for configuration error detected in CvP mode.|
|||1'b0||RWS||Mask for retry buffer correctable ECC error.|
|||1'b0||RWS||Mask for RX buffer correctable ECC error.|
- Enables dynamic updates to portions of the FPGA design’s core such as LAB, MLAB, DSP and RAM while the rest of the design continues to run.
- Facilitates hardware acceleration.
- Design protection: PR over PCIe ensures the PCIe host can exclusively access the FPGA fabric image which provides protection against unauthorized design tampering or copying.
- Image update without system down time: Allows a portion of the FPGA fabric to be updated through the PCIe link without a host reboot or FPGA full chip re-initialization.
- Unlike Configuration via Protocol (CvP) which requires the bottom left PCIe Hard IP block be used, any Hard IP for PCI Express IP Core can be used for PR over PCIe. The Hard IP Core must be configured as an Endpoint.
As shown in the diagram, a PCIe card with Altera FPGA plugged in a host PC. The host PC sends the PR bit-stream to the Hard IP for PCIe in the form of packets using the application software. The packets are then received by the PR IP core through Avalon MM slave interface. The PR IP core acts as the master to the hard PR control block. It controls the flow of control and data bits to the PR control block as well as sends back the status from the PR control block to the host PC through the PCIe endpoint.
The PR design flow requires initial planning. This planning involves setting up the design partition(s), and determining the placement assignments in the floorplan. Well-planned PR partitions improve design area utilization and performance. Your design can include the PR control block, which involves implementing the internal or external PR host.
The PR design flow uses the project revisions feature in the 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.
Partial reconfiguration is based on the use of revisions in the Quartus Prime Pro edition software. Your initial design is the base revision, where you define the boundaries of the static region and reconfigurable regions on the FPGA. From the base revision, you create multiple revisions, which contain the static region and describe the differences in the reconfigurable regions.
The PR design flow requires more initial planning than a standard design flow. Planning requires setting up the design logic for partitioning, and determining placement assignments to create a floorplan. You should have well-planned partitions to improve the design area utilization and performance, and make timing closure easier.