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. 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.
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:
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
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
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
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.