Partial Reconfi guration

FPGA technology provides the flfl exibility of programming and reprogramming a  device with a modififi ed design in the fifi eld without the need to go through refabrication. Partial Reconfifi guration takes this one step further, allowing the dynamic  modififi cation of part of an operating FPGA design without impacting the rest of the  design.

Applications

Any system with functions that can be time-multiplexed stands to benefifi t from taking advantage of Partial Reconfifi guration . Using Partial Reconfifi guration allows  functions to be switched on hardware, similar to a microprocessor’s ability to switch  between tasks in software.

Multi-protocol Networking

In optical transport network ( OTN ), client side ports need to support multiple  interface protocols. To ensure this, every possible interface protocol has to be  independently implemented for each port. This is resource intensive and ineffificient, especially considering that only one protocol will be used per port at any  one time. Partial Reconfifi guration allows the different protocols for each port to be  dynamically loaded on demand. This removes redundant logic and provides a  more effifi cient use of resource to implement the same functionality. Figure 19.1 shows the same 100G Muxponder system implemented with and without Partial  Reconfifi guration.

SW-Controlled HW Coprocessing

Hardware coprocessing is achieved by off-loading compute-intensive functions  from the central processor to a coprocessor or dedicated hardware, which executes  the function with lower power and latency. Image and video coprocessing is a typical example of this approach.

Having dedicated hardware for each function is an ineffifi cient use of resources.   Partial Reconfifi guration allows a library of hardware functions to be partially  reconfifi gured onto the same set of FPGA resources as and when required.  Figure 19.2 gives an example of a processor system, with an array of dedicated  hardware coprocessing functions, implemented with and without the use of Partial  Reconfifi guration.

Security and Encryption

Encryption and public-private asymmetric key cryptography are widely used as a  means of protecting sensitive or proprietary data. Partial Reconfifi guration can be  combined with asymmetric key cryptography to provide secure encrypted bitstream  or data transfer. The encryption key generation and/or decryption engine on the  FPGA is part of the initial or static part of the design. The encrypted partial bitstream containing the proprietary data is then sent to the decryption engine,  decrypted inside the FPGA, and programmed via the internal confifi guration access  port ( ICAP ), thus ensuring that the partial bitstream is never unencrypted outside  the FPGA.

Figure 19.3 gives an example of how a decryption engine can be used in conjunction with Partial Reconfifi guration

Key Concepts

All Partial Reconfifi guration designs consist of three basic parts. The Static is the  portion of the design that does not change and is expected to continue to function at  all times. The Reconfifi gurable Partition is the instance or level of hierarchy within  which multiple Reconfifi gurable Modules are defifi ned and implemented. Each  Reconfifi gurable Module represents one of the time-multiplexed functions that will  be switched in and out of the FPGA (Fig. 19.4 ).

Partial Reconfifi guration designs can contain one or more Reconfifi gurable Partitions ,  each of which must occupy a mutually exclusive physical area of the FPGA. The  physical area for a given Reconfifi gurable Partition must contain the aggregated  resources required to individually implement each of the Reconfifi gurable Modules associated with it. The resource types and granularity of the physical area within the  FPGA that can be reconfifi gured at any given time vary by device family.

Both the Static and the interface points between the Static and the Reconfifi gurable  Partition need to be identical for all the Reconfifi gurable Modules in the design.

Vivado achieves this by preserving the Static implementation and reusing it to  implement subsequent Reconfifi gurable Modules . An additional innovation in Vivado  is the creation of virtual I/O for each of the interface port called a Partition Pin .  Partition Pins can be locked to specififi c anchor points within the routing tiles and  maintained across Reconfifi gurable Modules . This consumes no LUTs or flfl ip-flfl ops,  thus reducing resource overhead and timing delays at the interface.

Vivado generates a partial bitstream fifi le for each Reconfifi gurable Module in each  Reconfifi gurable Partition as well as a full bitstream which contains the data for both  the Static and the Reconfifi gurable Module(s) being implemented. The full bitstream is used for initial confifi guration of the FPGA, while the partial bitstreams are used  for switching in and out the various Reconfifi gurable Modules . Loading of partial  bitstreams into the FPGA is generally performed via the FPGA’s standard external  confifi guration ports or via the internal confifi guration ports which can be incorporated  into the Static portion of the design.

Partial Reconfifi guration takes advantage of the FPGA’s addressable confifi guration  infrastructure which allows specififi c areas of the FPGA to be reconfifi gured. The  smallest addressable segment of the FPGA is known as a Confifi guration Frame .  Each frame typically corresponds to a single column of resources which is a clock  region in height. As such each frame contains a single resource type, for example,  DSP, block RAM, CLB, or routing interconnect; the actual number of resources in  each frame depends on the resource type and varies by device family.  

Design Considerations

In order to take full advantage of the potential benefifi ts of Partial Reconfifi guration for  a given application, you need to take on board a number of considerations prior to  starting the design. These are divided into three different categories:

• FPGA device family  

• Design structure  

• Support functions for Partial Reconfifi guration

FPGA Device Family

Vivado currently supports Partial Reconfifi guration for all production devices for all  families starting with 7-Series.

Starting with the UltraScale device family, all resources except the confifi guration  block can be partially reconfifi gured, while support in 7-Series is limited to CLBs,  DSPs, and block RAMs. As UltraScale devices allow IOs, BUFGs, MMCMs, and  other clocking components to reside inside the Reconfifi gurable Partition , different  clocking structures can now be supported inside any Reconfifi gurable Module . It  should be noted that clocks sourced from within the Reconfifi gurable Module may

only be used to clock logic inside that same Reconfifi gurable Module. Reconfifi gurable  Module clocks cannot be used to clock logic in Static . The addition in UltraScale  silicon of more granular control of global reset after Partial Reconfifi guration has  removed the 7-Series requirement for clock-region alignment for Reconfifi gurable  Partition flfl oorplans. It is, however, still recommended that the Reconfifi gurable  Partition flfl oorplan be a regular rectangle which aligns to device clock regions. With  changes in the stacked silicon interconnect ( SSI ) in UltraScale, Reconfifi gurable  Partitions and Reconfifi gurable Modules are now able to span multiple super logic  regions ( SLRs) and are no longer restricted to a single die as is the case with 7-Series  SSI devices.

Design Structure

The most important design consideration is the choice of an appropriate instance on  which a Reconfifi gurable Partition is set. This instance should be defifi ned to incorporate the full functionality that is being reconfifi gured at a given time under a single  hierarchical block. If the function being reconfifi gured is made up of several hierarchical blocks, these must all be merged under a single hierarchical block.

Ensure that the resources required by all the Reconfifi gurable Modules are reconfifi gurable for the device family being used. Therefore, the design should be structured in a way—such that resources that cannot be reconfifi gured reside in the Static portion of the design—outside the Reconfifi gurable Partition .

Partial Reconfifi guration is designed to support unconnected input and output  Partition Pins . Unconnected output Partition Pins will be tied high by default. If  you need to tie them to the ground , you need to do so explicitly in the Reconfifi gurable  Module . However, it is worth noting that explicitly tying to the ground is resource  ineffifi cient. Creating a Reconfifi gurable Module where all inputs and outputs are  unconnected results in a black-box module which can be used to turn off functionality inside the Reconfifi gurable Partition .

Optimization across the Reconfifi gurable Partition boundary is prohibited in order  to avoid optimization of Static to suit one Reconfifi gurable Module at the expense of  another. Therefore, ensure that the design does not rely on optimizations across  Reconfifi gurable Partition boundary. In addition, logic upstream and downstream of  unconnected Partition Pins does not get optimized away by Vivado.

As with any FPGA design, achieving timing closure is key, it is recommended  that registers are inserted on both sides of each Partition Pin . Registers on both  sides of the Reconfifi gurable Partition boundary allow the Vivado tools to maximize  the timing budget when implementing the Static and each of the Reconfifi gurable  Modules .

Support Functions for Partial Reconfifi guration

In order to allow the Partial Reconfifi guration process to operate correctly, a number  of support functions need to be added to the design. These can reside in the Static design, the board or with the system in which the FPGA is being used. These include  storing of partial bitstreams, triggering the Partial Reconfifi guration process, delivering of the partial bitstreams to the FPGA’s confifi guration memory, as well as decoupling the Static design from the Reconfifi gurable Partition during the Partial  Reconfifi guration process.

Xilinx provides a Partial Reconfifi guration Decoupler IP which can be used to  decouple the Static from the Reconfifi gurable Partitions and can be driven by the  user’s Static design. An alternative is to use an enable signal on the timing registers  on the Static side of the design to decouple the design during Partial Reconfifi guration.

The more Reconfifi gurable Partitions and Reconfifi gurable Modules a design contains, the more storage would be required to store the partial bitstreams generated  by Vivado. Partial bitstreams can be stored in on-board nonvolatile memory or offboard on an external storage location. Regardless of where it is stored, the design  requires a means of transferring these partial bitstreams from their storage location  into FPGA’s confifi guration memory.

The Xilinx Partial Reconfifi guration Controller IP can be used to help manage the  transfer of partial bitstreams into the FPGA’s confifi guration memory. Section 19.1.5 gives more insight into partial bitstream handling, the FPGA’s internal and external  confifi guration ports, and the means by which the FPGA can be confifi gured.

Design Tool Flow

The Vivado Partial Reconfifi guration tool flfl ow involves a number of simple steps:

1. Synthesize the Static with Reconfifi gurable Partitions as black boxes .

2. Synthesize each of the Reconfifi gurable Modules separately in out-of-context mode. Out-of-context mode synthesis results in a design being synthesized  without IOB insertion, which allows it to be stitched into the rest of the design  at a later stage. If IOBs are required inside a Reconfifi gurable Module , then these  must be explicitly instantiated.   

3. Create a physical area constraint or pblock to defifi ne the Reconfifi gurable Region for each Reconfifi gurable Partition . This area should contain all the resources  required for each of the Reconfifi gurable Modules and will be used to contain all  Reconfifi gurable Module routing. Static logic is excluded, while Static routing  can enter this area.  

4. Set HD.RECONFIGURABLE property on each Reconfifi gurable Partition .  

5. Implement the Static with one Reconfifi gurable Module per Reconfifi gurable  Partition . Save a copy of the fully routed design.

6. Remove Reconfifi gurable Modules from this design and save a static-only copy  of the design. This copy will allow black-box partial bitstreams to be generated  and used to remove logic from the Reconfifi gurable Partitions on the FPGA.   

7. Lock the static placement and routing.   

8. Add a different Reconfifi gurable Module to static-only design to each  Reconfifi gurable Partition , implement, and save the fully routed design.   

9. Repeat Step 8 until all Reconfifi gurable Modules are implemented.   

10. Run Partial Reconfifi guration verififi cation utility on all routed designs.   

11. Generate bitstreams for each routed design; this generates Full Bitstreams and  partial bitstreams for each Reconfifi gurable Module .

Any of the Full Bitstreams generated can be used to initially confifi gure the FPGA;  the choice should be determined by the functionality required at the start of the  system. The partial bitstreams for the Reconfifi gurable Modules that are generated  are compatible across confifi gurations; therefore, the partial bitstreams generated  can be used with any full bitstream even if they were not generated as part of the  same confifi guration.

Confifi guration Management

Storing and managing partial bitstreams is key to the success of Partial Reconfiguration in a design. Storage of partial bitstreams is typically outside the FPGA,  either on a nonvolatile flfl ash memory on the board or on another remote medium,  and accessible to the FPGA via PCIe, Ethernet, or other data transfer protocol.  Managing these partial bitstreams can be done using an external processor or an  internal state machine or processor within the Static region of the FPGA. The processor or state machine determines which Reconfifi gurable Module should be loaded,  where the partial bitstream for that Reconfifi gurable Module resides as well as when  and how it will be downloaded into the FPGA’s confifi guration memory. The Xilinx  Partial Reconfifi guration Controller IP can also be used to help manage partial bitstream confifi guration.  

Depending on the location of the partial bitstreams and the management engine  used, various confifi guration ports can be used to confifi gure the FPGA. The following  are the available confifi guration ports:

• ICAP ( internal confifi guration access port ): The primary choice where confifi guration management is being done internally to the FPGA. This requires a controller  as well as logic to drive the ICAP interface.  

• MCAP ( media confifi guration access port ): Provides access to confifi guration  memory from one specififi c PCIe block only in UltraScale devices.  

• PCAP ( processor confifi guration access port ): The primary confifi guration mechanism for Zynq-7000 SoC designs.  

• JTAG : Test and debug port. Mainly driven by the Vivado Hardware Manager.

• Slave SelectMAP or slave serial : A good choice to perform full and partial reconfifi guration, especially when using an external processor.