We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

AR# 63419

2014.4 Vivado Partial Reconfiguration - What types of bitstreams are used in Partial Reconfiguration (PR) solutions?


What types of bitstreams are used in Partial Reconfiguration (PR) solutions?


When designs are compiled for Partial Reconfiguration in Xilinx devices, different types of bitstreams are created.  

This document defines terminology and explains the details for each type of bitstream for 7 series and UltraScale devices. 

More information on all topics shown below is available in the Partial Reconfiguration User Guide (UG909).  

The types of bitstreams documented here are:

  • Full configuration bitstreams
  • Partial bitstreams
  • Blanking bitstreams
  • Clearing bitstreams


Full configuration bitstreams.  All PR designs will start with standard configuration of the full device using a full configuration bitstream.  

The format and structure here is no different than for a flat design solution.

There is no difference in how this bitstream can be used to initially program the FPGA.  

However, note that the design itself has been processed in preparation for partial reconfiguration of the device after the full programming has been done.  

All standard features, such as encryption and compression, are supported.

Reconfigurable Partitions (RP) set as black boxes are supported, so Reconfigurable Modules (RM) with no functionality can be delivered as part of the initial configuration, to be later replaced with a desired Reconfigurable Module. 

Bitstream compression can be very effective in this case, reducing bitstream size and initial configuration time.


Partial bitstreams.  Partial bitstreams are delivered during normal operation of the device to replace functionality in a pre-defined region of the device.  

These bitstreams have the same structure as full bitstreams, but are simply limited to specific address sets to program that specific portion of the device. 

Dedicated PR features such as per-frame CRC checks (to ensure bitstream integrity) and automatic initialization (so that the region starts in a known state) are available, along with full bitstream features like encryption and compression.

The size of a partial bitstream is directly proportional to the size of the region it is reconfiguring. 

For example, if the Reconfigurable Partition is composed of 20% of the device resources, that partial bitstream will be roughly 20% of the size of the full design bitstream.

Partial bitstreams are fully self-contained, so they are simply delivered to an appropriate configuration port.  

All addressing, header and footer details are contained within these bitstreams, just as for full configuration bitstreams.  

Partial bitstreams are delivered by the user to the FPGA through any external non-master configuration mode, such as JTAG, Slave Serial or Slave SelectMap. 

Internal configuration access includes the ICAP (all devices), PCAP (Zynq-7000 SoC), and MCAP (UltraScale via PCIe). 

Partial bitstreams are automatically created when write_bitstream is run on a PR configuration.  

Each partial bitstream file name references the top level design name given by the user, plus the pblock name for the Reconfigurable Partition, plus _partial.  

For example, for a full design bit file top_first.bit, a partial bit file could be named top_first_pblock_red_partial.bit.  

Note that the pblock instance will always be the same regardless of the RM contained within, so it is recommended to use a descriptive base configuration name, or rename the partial bit files to clarify which module it represents.


Blanking bitstreams.  A blanking bitstream is a specific type of partial bitstream, one that represents a black box. 

It removes the functionality of an existing Reconfigurable Module by replacing it with new functionality, which consists simply of tie-off LUTs on all appropriate module I/O.

To create a black box Reconfigurable Module, simply remove the logical and physical representation of a fully placed and routed design configuration and replace it with tie-off LUTs. 

Starting with a routed configuration (with the static design locked) in active memory, run these steps: 

update_design -cell <foo> -black_box; update_design -cell <foo> -buffer_ports; place_design; route_design

The design must be placed and routed to implement the LUTs that have been inserted into the design.  

Outputs of the black box RM are tied to ground by default, but can be set to Vcc by setting the HD.PARTPIN_TIEOFF on desired ports.

Compression can be used to greatly reduce the size of blanking bitstreams. 

Note that these bitstreams still contain not only the tie-off LUTs, but also any static routing that happens to pass through this region of the FPGA. 

Blanking bitstreams are generated and named just like standard partial bitstreams, as the black box variation is simply saved as another configuration checkpoint.


Clearing bitstreams.  Unlike the bitstream types noted above, this type is specifically for UltraScale devices only

A new requirement for this architecture is to clear an existing module before loading a new module in.  

This clearing bitstream prepares the device for delivery of any subsequent partial bitstream for that Reconfigurable Partition by establishing the global signal mask for the region to be reconfigured.

Although the existing module technically is not removed (the current logical module remains), it is easiest to think of it this way. 

Clearing bitstreams are NOT partial bitstreams. 

They are comprised of less than 10% of the frames for the target region, and therefore are about 10% of the size of the corresponding partial bitstreams. 

They do not change the functionality, but must be delivered between partial bitstreams. 

Each clearing bitstream is built for a specific Reconfigurable Module and must be applied after that module has been used, and must be sent to the configuration engine immediately before the next partial bitstream is delivered.  

For example, to transition from module A to module B, the clearing bitstream for A must be delivered just before the partial bitstream for B is delivered.  

To transition from module B back to module A, the clearing bitstream for B must be delivered just before the partial bitstream for A is delivered. 

This is the case even if any partial bitstream in question is a blanking bitstream.

Clearing bitstreams are automatically generated and have the same name as partial bitstreams with _clear at the end. 

Looking at the example above, if top_first is an UltraScale design, the clearing bit file name would be top_first_pblock_red_partial_clear.bit.

AR# 63419
Date Created 01/26/2015
Last Updated 05/12/2015
Status Active
Type General Article
  • Vivado Design Suite - 2014.4