FIGARO - AN AUTOMATIC TOOL FLOW FOR DESIGNS WITH DYNAMIC RECONFIGURATION Kelly Nasi, Theodore Karoubalis

Martin Danˇek, Zdenˇek Pohl

Atmel - Hellas, S.A.

Institute of Information Theory and Automation Czech Academy of Sciences Pod vod´arenskou vˇezˇ´ı 4 182 08 Praha 8, Czech Republic email: [email protected]

Papazachariou 48 GR 17342 Ag. Dimitros - Athens, Greece email: [email protected] ABSTRACT Although runtime partial dynamic reconfiguration of FPGAs has been researched for many years and there has been a few FPGAs equipped with the required architectural features, it has yet to achieve general recognition by the commercial design community. This is mainly due to the lack of a professional CAD tool support. This paper presents extended concepts from [1],[2],[3] implemented in a placement and routing tool. The tool supports creation of partially dynamically reconfigurable designs from input EDIF files and user-specified reconfiguration schedule down to bitstream generation for FPGAs that support this technology, such as the Atmel AT40K and AT94K series. 1. INTRODUCTION Designs that use partial dynamic reconfiguration can benefit from an increased functional density [4], which can result in using a cheaper part or decreased power consumption. The maturity of the FPGA technology adds further support by facilitating the integration of more and more system-level functions on a single chip, while higher levels of system integration increase the number of cases where functions that are active only for short periods of time can be implemented through reconfiguration. What is not generally available is a set of CAD tools and a simple design methodology for partial dynamic reconfiguration that would take designers from a concept to a solution in a straightforward, familiar fashion. This paper presents extended concepts of a dynamic reconfiguration described in [1],[2],[3] and a software tool that can implement designs with dynamic reconfiguration on the Atmel AT40K and AT94K family FPGAs [5]. The tool can be run in an automatic mode without user intervention, or THIS WORK HAS BEEN CARRIED OUT IN THE FRAME OF THE IST-2001-34016-RECONF2 PROJECT FUNDED BY THE EUROPEAN COMMISSION, AND THE GA102/04/2137 PROJECT FUNDED BY THE CZECH SCIENCE FOUNDATION. FOR MORE INFORMATION SEE HTTP://RECONF.ORG

0-7803-9362-7/05/$20.00 ©2005 IEEE

in a manual mode, where the user can specify or modify the placement of several logic blocks. The tool uses industrystandard design entry formats such as VHDL, Verilog, or schematic capture. It frees designers from FPGA-specific considerations, and allows them to focus on system-level issues. No special knowledge on the FPGA architecture or the so-called cache logic feature of the Atmel FPGAs [6] is required. The tool ensures that the physical implementation of the design is correct, it does not violate any electrical rules in the target device, and it protects against run-time contention of FPGA resources. The paper is structured as follows. Section 2 describes the general concepts used in the tool, section 3 presents the tool flow, section 4 discusses strong points and restrictions of the tool, and section 5 concludes the paper. 2. DESIGN ISSUES Partial dynamic reconfiguration means that the FPGA holds only those parts of user logic that are required at a given time to fulfil the desired function. The parts of logic that are not always required are usually denoted as the dynamic part (or dynamic tasks in [3]); this logic can be loaded to or unloaded from the FPGA as needed. The part of user logic that must always be present and running is denoted as the static part (or static tasks in [3]). The static part is handled in the same way as current designs that do not use dynamic reconfiguration, and it requires no special coding style or other treatment. The dynamic part usually consists of several so-called dynamic modules (or d-modules, or DHPs in [1], or dynamic tasks in [3]) that are declared as VHDL entities and specified as VHDL instances in the static part. Each instance corresponds to one d-module and is represented by one EDIF file. A dynamic module represents a portion of user logic that can be missing in certain FPGA configurations. On the level of placement and routing this translates to alleviation of the

590

placement and routing constraints, since certain blocks can remain unplaced and nets unrouted without yielding an invalid placement and routing of the design. A special case of dynamic logic is a design that contains several dynamic modules with the same input and output ports (interface), and that are used exclusively at different design contexts (FPGA configurations). Since such groups of logic can be viewed as a user macro (VHDL instance) with different logic functions at different contexts, we denote them as supermacros (or smacros). A supermacro can be viewed as several dynamic modules with inputs connected in parallel and outputs connected through a multiplexer, a similar concept to a mutex set in [3]. Each supermacro is specified by one VHDL instance and represented by several EDIF files (i.e. VHDL entities) that have identical input and output ports. 3. DESCRIPTION OF THE TOOL The implementation of the tool is based on an existing place & route tool that has been modified and enriched to support this new technology. The tool requires that the designer partitions the design to the static part and the dynamic part (dynamic modules or supermacros). This can be done automatically by an automatic partitioning tool [7], or manually by the designer. The design partitioning and reconfiguration schedule is specified in a so-called dynamic constraints file (DCF) [8] based on the Berkeley logic interchange format (BLIF). The tool reads the DCF file and EDIF netlists that correspond to the top-level design file that corresponds to the static part with dynamic modules instantiated as blackboxes, one netlist for each dynamic module. Next it organizes the design library that will hold all the dynamic modules, processes the design in order to place the static part, and finds one fixed placement position and orientation for each dynamic module. The outputs of the tool are a number of bitstream files, one for the static part, and two for each dynamic module used - one used for loading and the other for unloading the module. 3.1. Dynamic logic The main concept of the reconfiguration technology is the use of dynamic logic organized in modules that are not always present on the FPGA, but they are loaded and unloaded in time according to the design needs. The tool supports two types of dynamic logic: modules with the same interface that use the same FPGA area - supermacros, and modules that are unloaded and the area that was occupied before can be reclaimed for other logic - dynamic modules or d-modules. The loading and unloading of d-modules follows timing constraints that are specified in a so-called dynamic constraints file (DCF) [8]. These conditions or constraints mainly

Fig. 1. Figaro-Temporal System Planner. use clock cycles or signal controls. The grammar of this file is based on the Berkeley logic interchange format (BLIF). Dynamic modules are treated as regular macros with a novel characteristic. They can be loaded or unloaded at fixed locations on the FPGA without disturbing the rest of the design. Supermacros have one extra property: although the functions of the different modules that form one supermacro is different, their interface is the same, and they are placed over the same area on the dynamically reconfigurable FPGA. Supermacros are basically multiple macros instantiated as one blackbox that implements multiple functions through multiple contexts. At a given time only one supermacro function (or module) can be present on the FPGA and instead of loading and unloading modules, swapping between macro contexts is performed. The advanges of supermacro use instead of d-modules (when possible) is that the placer needs to search for the appropriate area to place the supermacro only once, for its first context and just reserve it for the next ones. While when using d-modules the placer needs to search for placement area once for each d-module consuming more time. Moreover only one blackbox will represent the whole supermacro at the top-level design. This simplifies top-level design issues. 3.2. Design configurations The basic operation that the tool performs is the placement and routing of the reconfigurable design on the FPGA, based on the information held in the DCF file. In order to do so the tool can determine all different configurations that the design will actually take in time. The tool decodes the information in the DCF file in order to form all the different maximum groups of the d-modules that will coexist in time. When these groups are combined with the static part, they form the design configurations. The tool must identify the design configurations in order to determine if the device chosen is sufficient to implement the design at all times, i.e. the device must be large enough to implement the largest of the design configurations. To perform effective placement of the d-modules the placer of the tool works by combining information on the modules

591

that are going to be placed on the device. 3.3. Placement & routing techniques The modular placement step is responsible for the placement of the d-modules. As the whole reconfigurable design cannot fit in the chosen device, the placement & routing procedures cannot be implemented in one step as in the classical flow. The technique that is used by the new tool is to place (& route) one design configuration at a time. The static part of the design is placed as a part of the first design configuration. This approach leads to better-placed designs as the placer takes into account at least some of the d- modules that will accompany the static part. In order to get a better placement of d-modules, the modular placement is not performed on one d-module at a time, but on groups of d-modules when this is possible. When a d-module is placed for the first time, it is assigned a fixed location that it will hold until the end of the process. When all design configurations are placed, each d-module is locked to a fixed location. At the end of this stage, the loading of single d-modules at fixed locations has been implemented. Modular placement also refers to loading a d-module to a fixed location using a fixed orientation, unloading a d-module by clearing the area that the module occupied, and swapping between two d-modules inside the bounding box of a super macro. A net is functional when at least one source and one destination port is present in the active context. Whenever a new configuration is processed, some nets become functional, while others lose their functionality. This is due to loading and unloading d-modules when changing the FPGA context. The tool routes nets that become functional without corrupting nets that have already been processed as static nets. Moreover, the tool unroutes nets that lose their functionality. The tool is also in charge of routing all new contexts of the supermacros; routing means both the macro routing (nets inside the macro) as well as preserving the routing between the supermacro and the static part of the design, or even between other dynamic structures while the macro is loaded. The nets between the dynamic macro interface ports and the static design remain unchanged at least up to the bounding box of the dynamic macro. The first time a d-module is unloaded the modular placer records its fixed location and orientation on the FPGA for future use upon a d-module load request. At the same time the modular router records all the routing data of any nets that are related to the particular d-module. These records of routing data will be used in any request to load the d-module again in order for the nets related to the d-module to be reconstructed in exactly the same way. This is important for acquiring one global bitstream file for the loading of the dmodule and one for unloading it. Basically if we think about

Fig. 2. Dynamic routing for FP coprocessor: ADD (left), MUL (right). cases where a d-module belongs to more than one design configurations, the d-module will be loaded more than once on the device in different surroundings. The first time it will acquire a fixed location and orientation and its related nets will be routed following specific paths, later on it will be unloaded and all this data will be stored. On its second loading the stored data will be used in order to give the d-module the same layout on the device. This guarantees that the timing properties of the d-module will remain unchanged and that one global bitstream file for loading (unloading) the dmodule can be used. This situation leads to another need: we must ensure that the resources that the d-module will require upon its second loading are free and can be used. When performing modular placement and routing, the tool marks the resources of the FPGA that have been used by d-modules, and when another d-module wishes to use them, it is only allowed to do so if it cannot coexist with the one that has already used them. This is to prevent cases where two d-modules compete for the same resource. An example of a processed design that uses dynamic reconfiguration is given in Figure 2, which shows an implementation of a reconfigurable 24-bit FP adder / multiplier in AT94K. 3.4. Bitstream generation The task of generating the bitstream files for a reconfigurable design is more complicated than the corresponding task for a classical design because of the existence of the reconfigurable areas on the FPGA. The process steps that the tool follows are: 1. Unload all the d-modules so that only the static part of the design is present on the FPGA. 2. Generate the initial bitstream file for the static part. 3. Load all the d-modules that belong to the first design configuration and generate the bitstream of this configuration.

592

4. For each d-module in this FPGA configuration do: (a) Compare the bitstreams for the configuration without the d-module with the one for the whole configuration. The resulting differences define the bitstream for loading the d-module. (b) Compare the same bitstream files in the reverse order to generate the bitstream for unloading the d-module. 5. Unload all d-modules that belong to the design configuration and repeat steps 3 to 5 for the remaining configurations. This process generates all bitstreams required to implement a design with dynamic reconfiguration: the initial bitstream for the static part, and the bitstreams for loading and unloading each d-module. The initial bitstream can be loaded as a regular configuration bitstream, while the bitstreams for the d-modules can be loaded into the FPGA configuration memory. 4. EVALUATION Advantages The tool can be used for any type of application. It offers an easy handling of d-modules, and it implements a modular design with minimum user interactions. It poses no restrictions on the interconnections between the dynamic and static parts, except that it does not allow any nets that have destination ports both in the static part and in a d-module. Even if a d-module can exist in very different contexts, it can be loaded on the device using the same bitstream file, and in each case it has the same timing properties. The different configurations of the design are used for verifying that the device chosen is large enough to implement the modular design at all times. There are no restrictions regarding the size of the d-modules as long as the device is large enough to contain the different design configurations. The user can select the first configuration that will be placed; this leads to variations of the static part placement. Disadvantages Not every ordering of the design configurations guarantees success. In tight cases the static part might not be placed in an acceptable manner for all configurations. Such cases require to reorder the configurations and repeat the procedure. In such tight cases the designer might also need to intervene by manually placing or routing some small parts of the design in order to help the placer and router of the tool avoid contentions. Another disadvantage is that the designer is required to identify before runtime which dmodules can coexist on the device and which cannot and write this information in the DCF file. If the designer is not able to do so, the tool will have to examine all possible combinations and in the worst case consider that all d-modules can coexist leading to one big design configuration.

5. CONCLUSION This paper has presented a new approach to implementing designs with dynamic reconfiguration. Sample analysis and data have been provided for its implementation in a new extension of the existing Placement & Routing Tool, Atmel Figaro IDS 7.6.7. When combined with Atmel’s dynamically reconfigurable FPGAs, this new tool offers the designer an efficient means to exploit and profit from the advantages of reconfiguration techniques. The tool provides the designer with an easy way of placing and routing reconfigurable designs on FPGAs that support partial dynamic reconfiguration, leading to the generation of the required bitstream files. The tool has an extremely simple and user-friendly interface that requires minimum user interaction. The function of the tool has been verified in hardware on a couple of complex real-world designs (one example has been shown). 6. REFERENCES [1] E. L. Horta, J. W. Lockwood, and D. Parlour, “Dynamic hardware plugins in an FPGA with partial runtime reconfiguration,” in Proceedings of the 39th Design Automation Conference, B. Ackland, Ed. ACM Press, 2002, pp. 343–348. [2] Xilinx Application Note 290 - Two flows for partial reconfiguration: Module based and Difference based. Xilinx, 2004. [3] I. Robertson, J. Irvine, P. Lysaght, and D. Robinson, “Timing verification of dynamically reconfigurable logic for the Xilinx Virtex FPGA series.” in Proceedings of the 10th International Symposium on Field-Programmable Gate Arrays, M. Schlag and S. Trimberger, Eds. ACM Press, 2002, pp. 127–132. [4] M. J. Wirthlin and B. L. Hutchings, “Improving functional density using run-time circuit reconfiguration,” IEEE Trans. VLSI Syst., vol. 6, no. 2, pp. 247–256, Feb. 2002. [5] AT94K - 5K to 40K Gates of AT40K FPGA with 8-bit AVR Microcontroller. Atmel, 2002. [6] AT40K Series Cache Logic Configuration.

Atmel, 1998.

[7] R. Kielblik, J. M. Moreno, A. Napieralski, G. Jablonski, and T. Szymanski, “High-level partitioning of digital systems based on dynamically reconfigurable devices.” in Proceedings of the 12th International Conference on Field-Programmable Logic and Applications, M. Glesner, P. Zipf, and M. Renovell, Eds. Springer, 2002, pp. 271–280. [8] The RECONF2 project web page - http://reconf.org. The RECONF2 consorcium, 2002.

593