PRCs using the PCAP Firstly, requirement 1 effectively precludes a whole class of recon- figuration controllers: All PRCs that use the PCAP for bitstream delivery cannot be used due to its exclusivity to the Zynq series. Adapting such a controller to usage of the ICAP would warrant a complete re-design. Furthermore, Xilinx specifies a typical throughput of the PCAP of around 145 MB/s on the Zynq-7000 [Xil18s, p. 221] compared to a maximum of 400 MB/s for the ICAP. Experiments suggest that the realistically achievable PCAP data rates are a bit lower in practice at around 128 MB/s [VF14; RA14]. This is not enough to satisfy requirement 5. Therefore, only solutions involving the ICAP were evaluated further.
PRCs with CPU-tailored interfaces Secondly, another class of reconfiguration controllers is designed specifically for usage in combination with a CPU that provides commands and/or bitstreams. For this purpose, soft-core processors such as the MicroBlaze [Xil17d] included in the Vivado design suite can be used in combination with a peripheral on the AXI bus that enables access to the ICAP. The most basic design will use the AXI Hardware Internal Configura- tion Access Port (HWICAP) IP core by Xilinx [Xil16b] (or similar) that is essentially a low-level bridge between the AXI bus and the ICAP. All control logic is implemented in software (cf. Figure 3.2).
MicroBlaze processor
Memory controller Memory
AXI_HWICAP ICAP
AXI bus
Figure 3.2: Exemplary structure of a microprocessor-based partial reconfiguration system
using the HWICAP solution by Xilinx. The MicroBlaze processor is in complete control of the reconfiguration process and responsible for fetching bitstream data from the memory and forwarding it to the ICAP. Arrows indicate conceptual flow of information and do not
necessarily match the actual port directions.
More advanced approaches like the RT-ICAP [PSS17] move some aspects of the process out of the CPU and provide additional features such as bitstream decompression, but still offer an interface that is best suited for interoperating with a processor. There are a number of similar designs along these lines; see for example [Hüb+10; Guo+17; CF15]. Furthermore, it is possible
to use the hard CPU core inside the Zynq for controlling the reconfiguration process, but send the bitstream to the ICAP instead of the PCAP for performance reasons. An example of this is the ZyCAP [VF14]. There is even a proposal by Becher et al. that “includes a hybrid reconfigu- ration approach utilizing both the [PCAP] and the [ICAP] in order to minimize reconfiguration
time and system energy consumption” [Bec+16]. Systems using the ViSARD, however, might
or might not include other CPUs. Requiring the inclusion of one only to facilitate DPR would run counter to requirement 4 due to the increased resource usage.
Xilinx PRC Thirdly, Xilinx itself offers a partial reconfiguration controller as part of their IP core library that can be used without an additional fee [Xil18f]. It supports up to 32 reconfig- urable regions that can each contain up to 128 different configurations. The basic operation is simple: When given the corresponding trigger signal to load a specific configuration into a re- configurable region, it fetches the bitstream from a user-configurable memory location on the AXI bus and pipes it to the ICAP. It offers several more advanced features such as an AXI con- trol interface and module shutdown/startup management that are not required for the ViSARD and therefore not considered here.
The number of reconfigurable regions and the memory locations and sizes of the partial bit- streams have to be specified in the parameters of the PRC IP core at design time, but they can be modified after the design has been implemented by executing special commands in the Vivado design environment. Since the size of partial bitstreams is typically determined after implementation, without this feature the whole process would have to be rerun from the top after changing a value in the configuration of the IP core.
As far as the requirements for this thesis are concerned, the Xilinx PRC directly violates con- straint 3 because its timing and speed characteristics are not specified at all. Xilinx does neither guarantee that the IP core will start and/or finish reconfiguration within a defined amount of clock cycles nor make any statement about the typically achievable reconfiguration through- put. Furthermore, the controller is essentially a black-box, contradicting requirement 2.
PRCs in the literature Fourthly, there are other existing PRCs proposed in the literature that are designed for stand-alone usage in hardware designs without any supporting processor. This includes the older ICAP-I by Lai and Diessel [LD09] as well as the newer dynamic partial reconfiguration manager (DPRM) by Tarrillo et al. [Tar+14] and a DPR scheme by Beckhoff,
Koch, and Torresen [BKT14] additionally offering relocation-aware compression. Their design files are not publicly available, so they cannot be used in the system implemented in this thesis. Additionally, none of those takes real-time constraints into account, violating requirement 3, and they do not come close to the device limits in terms of configuration speed. The scheme proposed by Beckhoff et al. for example is reported to reach a configuration throughput of 73 to 97 MB/s, while Lai and Diessel achieve 180 MB/s and Tarrillo et al. get up to 253 MB/s in measurements while theoretically reaching the device maximum of 400 MB/s when storing the bitstream completely in BRAM. The same is true for the Speed Efficient Dynamic Partial Reconfiguration Controller (SEDPRC) presented in [Bha+12] that is designed to exclusively use
Custom PRC Finally, it is possible to implement a custom reconfiguration controller that is tailored to the requirements of the work in this thesis as outlined above. This is the option that was chosen considering the significant disadvantages of the alternatives. The requirements now become the design goals of the custom PRC. As there are no goals that conflict with each other, it should be possible to fulfill all of them. The resulting VHDL entity will be called simply
prc.