Making hardware more like software
Software flowTo take full advantage of the proposed architecture, the design software must have two critical components: a method to describe the joint software/hardware system, and the ability to incrementally recompile the FPGA regions for partial reconfiguration.
To break down the tools depending on the need for creating such a system, a tool that would allow the user to carve out different regions for partial reconfiguration and managing compile time is needed. The other is to have the ability to describe the entire system (SoC) on the device connecting the required peripherals to the processor. Having these two tools at their disposal, designers make the task relatively simple and are allowed to meet the demands of creating different personas or flavors for the device such that it can perform different functions as well as meet time to market demands.
Using partial reconfiguration on the device would have to follow a strict methodology, where the partial block and static blocks in the design are first identified and the user must adhere to the following guidelines:
- Follow synthesis and hierarchy guidelines when designing the blocks.
- Identify the partial blocks and assign them to a fixed location in the device floorplan using the incremental compilation methodology and floorplan region constraints.
- Ensure the port definitions and hierarchy boundaries of all the partial blocks and their variants do not change, or the entire device may have to be reconfigured.
- Ensure that reset signals between partial blocks and static blocks are not shared.
- Add handshaking signals to deal with the availability and non-availability of the logic in the partial blocks, if there is logic within the static blocks that depends on the state of the partial block.
The proposed flow for the FPGA on is called the design partition-based flow: once a region is reserved the device and the region can be reconfigured with new logic while the remainder of the design is left running. Figure 5 shows a high-level description of a system designed for the proposed architecture.

Click on image to enlarge.
FPGA design portion
There are two top level FPGA images shown in Figure 5. Image 1 “Top 1” has a static region composed of hierarchy modules A, C, E and two modules B and D. B has two different implementations calls B1 and B2. Each of those, call a persona of B. Similarly D has three personas. Image 2 “Top 2” has a static region composed of hierarchies G and H. F and I have two personas each.
Each FPGA image communicates with the processor through a well-defined bus architecture. Similarly all personas have a common interface to that static region. Each persona will map to a specific partial image loaded into the FPGA. For the high-level example shown, the compilation process will generate two full images of the FPGAs. Full image one will have five partial images (B1, B2, D1, D2, D3) while full image 2 will have four partial images (F1, F2, I1, I2).
To compile all the FPGA images efficiently, two concepts are needed by the FPGA design software: a design partition, and a locked FPGA region. A “design partition” is a hierarchy of the designs that are marked to be a partition. All changes to the design are limited within that partition for compilation purposes. A “locked FPGA region” is a physical portion of the FPGA that is reserved for a specific persona. A persona is assigned to a “locked FPGA region” by floorplanning the design. The FPGA design software compiles the static region and then successively compiles each persona incrementally to generate all full and partial images. Figure 6 shows a floorplan of the FPGA for the design Top 1 above. B and D are "locked FPGA regions."

Click on image to enlarge.
Figure 7 shows the compilation flow for the Top 1 portion of the design described above. Essentially all personas can be compiled in parallel incrementally and across multiple machines.

Click on image to enlarge.
Such a flow allows the static regions to be locked down and focus on the partial region and the respective personas. Focusing on the smaller portion of the design allows the user to take advantage of the incremental nature of this tool and reduce compile time, preserve performance and also in the case of partial reconfiguration, since only a small area of the chip is being programmed, reduce configuration time.


Loading comments... Write a comment