Introduction

This design example demonstrates partial reconfiguration feature in the Arria 10 SoC environment. The purpose of this design example is to serve as a starting point for partial reconfiguration derived from the Arria 10 GSRD targetting the Arria 10 SoC 10AS066N3F40E2SG development kit. It consists of both hardware designs and software packages.

Release Contents

The Altera Arria 10 SoC Partial Reconfiguration Reference Design sources and prebuilt binaries can be downloaded here:

Folder	File	Description
bin	linux-socfpga-pr-17.1-a10-bin.tar.gz	Arria 10 Binaries Archive for Rev C board
hw	a10_soc_devkit_pr.tar.gz	GHRD - Hardware project for Rev C board

Pre-requisites

Hardware requirement

• Arria 10 SoC Development Kit - 10AS066N3F40E2SG
  • Rev C
• DDR4 Memory Card
• Micro SD Card (4GB or greater)

Software requirement

This design example is build based on Arria 10 SoC GSRD (Golden System design example) and tested with Quartus Prime Pro version 16.1 (This reference design will not work on Quartus Prime). It is recommended for user to go through below material before get started with this design example.

• Please refer this link for Arria 10 SoC Development Kit documentation and installation files.
• Please refer to Arria 10 SoC GSRD User Manual.

Hardware Architecture Overview

Architecture

The architecture is a pure superset of the A10 SoC GSRD with the addition of the Freeze Controller IP, the Freeze Bridge IP, and the PR region subsystem.For this reference design, the PR Region consist of a System ID, Avalon MM Pipeline Bridge, On-chip Memory and Clock Source. In both the base and the PR persona revision, the System ID will be configured to a defined ID value respectively to differentiate from each other before and after the PR has been performed. Both the System ID IP in base and PR persona will be using different register offset mapping in qsys subsystem. With this approach, the Linux software will be able to diagnose if the correct device tree overlay have been loaded during the PR process for both base and PR persona. In the situation when the base device tree overlay is wrongly loaded for the PR persona, the software is expected to read incorrect value of the On-chip memory content instead of the System ID as the register offset it accessed no longer refers to the System ID slave.

A10 HPS will be responsible as an external host to issue the freeze request to the Freeze Controller IP to perform freezing on the PR region prior to initiate the PR bitstream data reprogramming. All full or partial persona bitstream data will be streamed from filesystem through DDR to FPGA Manager Module which then transfers to the hard PR control block. The hard PR control block within the FPGA will be communicate to FPGA Manager module through PR interface, the PR persona bitstream data will then reprogram to the PR region via FPPx16 mode. The Altera Freeze Controller & Bridge IP handles the handshaking communication between the SoC HPS Host to the FPGA PR region logic prior to the start-off of a PR process. The Altera Freeze Controller IP is instantiated to handle all freezes, unfreeze, reset request and acknowledgement status communication updates between HPS host and the PR region. The Freeze Controller IP can be configure to control multiple Freeze Bridge IPs in a single PR region.

The A10 HPS communicates to AVMM slave interface of the Freeze Controller IP and PR region sub-system through the Freeze Bridge IP using the LWH2F Master AXI Bridge. The AVMM CSR interface in the Freeze Controller IP provides freeze request or status communication with SoC Host as well as the PR region during the whole PR process is running. Currently, the Freeze Bridge IP only supports PR handshaking for AVMM interface. For other signals such as streaming, conduit interface or interrupt, user will need to create their own custom logic to handle them during PR process.

Quartus II Design Files

Below is some of the important file in this design example:

ghrd_10as066n2.qsys	Top lovel Qsys Pro system block
pr_region.qsys	pr_region Qsys Pro subsystem
pr_region_persona.qsys	pr_region_persona Qsys Pro subsystem
ghrd_10as066n2_top.v	Top level RTL
ghrd_timing.sdc	Timing constraint file

Hardware Development Flow

High level overview

To design a PR system in FPGA, Quartus Prime Pro features such as Design Partition and LogicLock Plus Region are required.

Below is a high-level description of the basic steps on setting up the PR design flow in this reference design.

The complete design that can be downloaded at Release Contents

Setup PR Region

1. Open the Arria 10 GSRD ghrd_10as066n2.qpf project file in Quartus Prime Pro as a base PR system design.
2. Create a pr_region subsystem (pr_region.qsys) in the ghrd_10as066n2.qsys using Qsys Pro similar to the diagram below
   
3. Set the System ID to an ID value.
4. Save and generate pr_region.qsys and ghrd_10as066n2.qsys.
5. Change the revision to ghrd_10as066n2
6. Run Analysis & Synthesis in Quartus Prime Pro

Partition the Design

1. Once Analysis & Synthesis is done, expand ghrd_a10_top and soc_inst in the Project Navigator pane.
2. Find pr_region_0.
3. Right click on pr_region_0 and configure Set As Design Partition.
4. Configure pr_region_0 as Reconfigurable Design Partition in the Design Partition window or QSF assignment.

Please refer to here for more details on Design Partition usage.

Define PR Region

The pr_region subsystem is required to be fixed at a reserved region per PR requirement. This is done using LogicLock Plus Region window or QSF assignment.The height and width of the reserved region will be highly dependent based on requirement for every different personas. In this reference design, a relatively large area is reserved for the pr_region sub-system.

In order to locate a region for PR placement and routing region, LAB coordinates will be used. Chip Planner is used to select the PR Region coordinates.

1. In the Project Navigator pane, right click on pr_region_0 and from the drop down menu, choose Locate Node and choose Locate in Chip Planner.

Allocate a region for this PR Partition as these LAB coordinates will be used in the PR flow such that in every revision, only corresponding persona core will be placed in this selected reserved region.

1. For example, in this reference design as shown in the Chip Planner, the pr_region is highlighted in color Purple.
2. An area could be selected that covers this logic.
3. In this reference design, the coordinates are identified as 3 9 followed by 145 168.

Please refer to Chapter 12 in the Quartus Prime Pro Handbook for more details on LogicLock Plus Region usage.

Note:

When there are multiple personas present for a PR region in the design, user is require to ensure largest reserved area is configured in the LogicLock Plus Region in order to fulfill for all personas requirement and achieve correct PR functionality.

Update Base Revision .qpf file

The project QSF can also be manually updated to set the configurations as mentioned.

set_global_assignment -name REVISION_TYPE PR_BASE
set_instance_assignment -name PARTITION pr_partition -to soc_inst|pr_region_0
set_instance_assignment -name PARTIAL_RECONFIGURATION_PARTITION ON -to soc_inst|pr_region_0
set_instance_assignment -name GLOBAL_SIGNAL GLOBAL_CLOCK -to fpga_clk_100
set_instance_assignment -name PLACE_REGION "3 9 145 168" -to soc_inst|pr_region_0
set_instance_assignment -name ROUTE_REGION "2 8 146 169" -to soc_inst|pr_region_0
set_instance_assignment -name RESERVE_PLACE_REGION ON -to soc_inst|pr_region_0
set_instance_assignment -name CORE_ONLY_PLACE_REGION ON -to soc_inst|pr_region_0

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

Full Compilation

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

Run a full compilation to ensure that the base design meets timing before proceeding further.

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

Export root_partition at the final snapshot of the base design revision

$ quartus_cdb ghrd_10as066n2 -c ghrd_10as066n2 --export_pr_static_block root_partition --snapshot final --file base_static_region.qdb

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

Create Personas

1. The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

Create a pr_region_persona (pr_region_persona.qsys) similar to (1)

1. The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

Modify the System ID to a different ID value from the base revision.

1. The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

*Save and generate the pr_region_persona.qsys.

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.*

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

Create Revisions

1. The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

Create two revisions. One for Synthesis Revision and second for Implementation Revision.

1. The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

Include the pr_region_persona.qsys files in the Synthesis Revision and set it as the top level.

1. The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

*Close all Quartus Prime windows before proceed to the next step.

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.*

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

Synthesize and export root_partition of the synthesis revision at the synthesized snapshot

$ quartus_syn ghrd_10as066n2 -c synth_v2
$ quartus_cdb ghrd_10as066n2 -c synth_v2 --export_block root_partition --file synth_v2.qdb --snapshot synthesized

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

Fit PR Implementation Revision

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

The base revision root partition and the synthesized snapshot of the PR partition are imported to fit the PR Implementation Revision.

$ quartus_cdb ghrd_10as066n2 -c alternate_persona --import_block root_partition --file base_static_region.qdb
$ quartus_cdb ghrd_10as066n2 -c alternate_persona --import_block pr_partition --file synth_v2.qdb

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

Partial-Mask SRAM Object File

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

Run a compilation of only Fitter, Static Timing Analysis, Assembler of the PR implementation revision to obtain the Partial-Mask SRAM Object File (.pmsf) for the PR region on the alternate_persona revision

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

Convert PMSF to RBF

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

The generated pmsf can be converted to rbf using the command as shown:

$ quartus_cpf -c ./output_files/ghrd_10as066n2.pr_partition.pmsf ./output_files/persona0.rbf
$ quartus_cpf -c ./output_files/alternate_persona.pr_partition.pmsf ./output_files/persona1.rbf

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

Convert SOF to RBF

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

The sof can be converted to rbf using the command as shown:

$ quartus_cpf -c -o bitstream_compression=on output_files/ghrd_10as066n2.sof output_files/ghrd_10as066n2.rbf

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

Convert DTSO to DTBO

The persona dtso files can be converted to dtbo using the command as shown:

$ dtc -I dts -O dtb -@ -o fpga_static_region.dtbo fpga_static_region.dtso -f
$ dtc -I dts -O dtb -@ -o persona0.dtbo persona0.dtso -f
$ dtc -I dts -O dtb -@ -o persona1.dtbo persona1.dtso -f

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

Software Development Flow

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

Yocto Flow

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

The complete Yocto software flow is similar to GSRD flow.

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

Output files:

console-image-socfpga_arria10.tar.gz	Generic Angstrom Root filesystem as compressed tarball
sdimage.img.gz	Compressed bootable SD card image
socfpga.dtb	Device Tree Blob
soc_system.rbf	Compressed FPGA configuration file
u-boot-socfpga_arria10.img	U-boot image
vmlinux	Linux kernel ELF image
zImage	Compressed Linux kernel image

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

Generate U-Boot and U-Boot Device Tree

For more details about u-boot generation, please refer to GSRD - Generating Bootloader.

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

Device Tree Blobs

Static FPGA DTB

The DTB for the partial reconfiguration uses the FPGA overlay. This differs from the Arria 10 GSRD. The DTB that is used for the system is from the Angstrom build, or it can be built from the Linux kernel source (refer to Compiling Linux Kernel and Root Filesystem). The DTB can be obtained at <angstrom>/deploy/images/glibc/images/arria10/socfpga_arria10_socdk_sdmmc.dtb.

FPGA overlay DTB, Persona DTB

The FPGA overlay DTB (fpga_region.dtso, persona0.dtso, persona1.dtso) as available in the binary linux-socfpga-pr-16.1-a10-bin.tar.gz are hand coded. For more information about Linux FPGA overlay, please refer to Linux Device Tree Overlay Notes.

Compiling Linux Kernel and Root Filesystem

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

For more details about Linux kernel and root filesystem compilation, please refer to GSRD - Compiling Linux Kernel and Root Filesystem. Currently only Linux kernel 4.1.22-ltsi is officially supported, other kernel version is known to cause issues with partial reconfiguration.

Include persona0.rbf and persona1.rbf into /lib/firmware in the root filesystem.

Include fpga_static_region.dtbo, persona0.dtbo and persona1.dtbo into /boot in the root filesystem.

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

Build SD Card Image

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

Replace all required component into SD Card, or build and replace the whole image.

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

For more details about SD card image generation, please refer to GSRD - Creating and Updating SD Card.

Pre-built SD card image with Partial Reconfiguration is available here: at Release Contents

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

Demo

The routing region for the blocked section is assigned slightly bigger to provide extra flexibility for the routing enginer when it routes different personas.

Refer to this link for Arria 10 SoC Partial Reconfiguration Example Demo Testing.

References

Partial Reconfiguration online course: http://wl.altera.com/education/training/courses/OPR100

Performing Partial Reconfiguration: http://quartushelp.altera.com/15.0/mergedProjects/comp/comp/comp_pro_part_reconfig.htm

Chapter 4 Design Planning for Partial Reconfiguration: https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/qts/qts_qii5v1.pdf