XF-Board: Prototype Platform for Recongurable Hardware Operating System

Herbert Walder, Samuel Nobs, and Marco Platzner Computer Engineering & Networks Laboratory (TIK) Swiss Federal Institute of Technology (ETH) Zurich, Switzerland
Abstract We present the XF-B OARD, a prototyping platform for recongurable hardware operating system research. The platform is based on two tightly coupled FPGAs. One FPGA implements a soft CPU core that controls the overall system; the second FPGA is used as dynamically recongurable hardware resource. The main features of the prototyping platform are fast partial reconguration and readback, advanced clock control, a multitude of memory and I/O, and support for the 1D resource model by connecting all memory and I/O to the left and right device edges. Thus, all peripherals and memories are directly accessible by the operating system.

Keywords: Recongurable hardware operating system, prototyping platform I. I NTRODUCTION Recongurable hardware operating systems (RHWOS) manage the computational resources of recongurable hardware at runtime. Interest in such systems has recently been strenghtened by the increasing logic capacities and the availability of partial reconguration techniques. Recongurable operating systems are a rather new line of research. The rst description of hardware multitasking is due to Brebner [1][2]. Recently, Wigley et al. discussed OS services including device partitioning, placement and routing [3]. Multitasking and task preemption was investigated by Simmler et al. [4], and Brebner/Diessel [5], respectively. Kuacharoen et al. presented a congurable hardware scheduler [6], that can act as a system component in a RHWOS. In [7][8][9], functional prototypes of dynamically recongurable systems, based on todays FPGA technology, were presented. Managing recongurable hardware resources at runtime allows for an efcient execution of dynamic tasks, i.e., tasks whose arrival times and execution frequencies are not known at design time. Such task sets are generated in many modern networked embedded systems, including mobile [10][8], networking [11], and wearable computing systems [12]. The main functions of a recongurable hardware operating system are task and resource management. Both functions are intertwined and deal with the assignment of recongurable resources to arriving tasks. The complexities of these functions stronlgy depend on the used task and resource models. Whereas most previous work treats tasks as rectangular areas of recongurable logic, the approaches differ in the way the recongurable surface is modelled. Resource models split into two basic groups, 1D and 2D models.

In the 1D resource model, tasks are placed along the horizontal dimension of the recongurable surface. Each placed task occupies the complete vertical dimension. Such 1D models match well the reconguration capabilities of current FPGA technology but may suffer from underutilization of the device. The 2D resource models treat tasks as rectangles to be placed at an arbitrary position inside the larger rectangle formed by the device. Although 2D models have been shown to lead to a better device utilization [13][14], their practical realization seems currently out of reach. In our previous work [9] we have demonstrated a rst prototype for a recongurable hardware operating system using a simple 1D resource model. This prototype was done on the commercial FPGA board X ESS XCV-800, which features a X ILINX V IRTEX 800 and some I/O and memory. X ILINX V IRTEX restricts reconguration to vertical, chip-spanning columns. Hence, we have used a 1D resource model where the recongurable surface is partitioned into several task slots and static operating system frames at the left and right device edges. This partitioning is shown in Figure 1. All memory and I/O is controlled by the operating system; tasks communciate with operating system objects such as drivers or FIFO queues to access these resources. Memory and I/O connected to pins at the top and bottom edges of the FPGA cannot be efciently made available to the operating system, as the corresponding FPGA I/O blocks undergo a reconguration whenever a new task is loaded (see Figure 1). Experiments with our previous prototype [9] revealed a number of weaknesses, which motivated us to develop an own prototyping board tailored to the specic needs of recongurable hardware operating systems. This paper presents the XF-B OARD which has unique hardware capabilities. The XF-B OARD allows for very fast partial reconguration and readback and sophisticated clock control. Further, it is rich in memory and I/O connected to the left and right edges of the recongurable device to support efcient implementations of 1D resource models. The paper is structured as follows: In Section II we review the main requirements for the prototyping platform. The design decisions and specics of the XF-B OARD are discussed in Section III. The supporting rmware is presented in Section IV. Section V shows briey how recongurable hardware operating systems are prototyped on the XF-B OARD. Finally, Section VI concludes the paper and outlines further work.

I/O

affected by reconfiguration

I/O

external components

configuration frames

external components

C static region

C static region

operating system circuitry (static)

Fig. 1 L OCATION OF FPGA I/O S AND MEMORY SUITABLE FOR RHWOS, USING THE 1D RESOURCE MODEL

II. R EQUIREMENTS The XF-B OARD was designed to act as demonstration and evaluation platform for recongurable hardware operating systems. As typical application domain for such a system, we envision networked embedded systems [8][11][12] that execute computationally intense, data-streaming oriented dynamic task sets. These task sets include include networking (eg. packet processing), multimedia (eg. streaming of audio and video data), cryptography, but also control functions[15]. This application domain led to following requirements: Networked standalone system with a hybrid architecture The platform should logically consist of an FPGA coupled with an CPU for two reasons. First, the CPU is required as a conguration controller for the FPGA. Second, a hybrid architecture allows for software/hardware partitioning. This partitioning affects the operating system, where some functions will run in hardware and others in software, as well as the user tasks that will eventually be scheduled to run in either software or hardware, depending on the current system state [16][17]. The system must be able to operate in a stand-alone mode, i.e., without being attached to a PC or workstation. Both data and conguration bitstreams should either be received via a network interface or stored on the system. Rich in I/O and memory A prototyping platform for an embedded device must include a multitude on I/O peripherals. The XF-BOARD should feature RS-232 and Ethernet interfaces, an audio codec, a video D/A converter, and additional expansion slots for interfacing. The envisioned application tasks and the required full and partial conguration bitstreams demand for large amounts of memory, exceeding by far the capabilities of the FPGA internal RAM blocks. Further, as standalone system the XF-BOARD must feature nonvolatile memory to be bootable without network access. Besides this general requirements, there are further requirements very specic to prototyping recongurable hardware

operating systems and the 1D resource model we have chosen for our implementation: Support for fast full and partial reconguration To allow for maximum speed full and partial conguration and readback, a fast bidirectional access to the FPGAs conguration port is needed. The systems memory should be fast enough to allow for high-speed reconguration. Hardware/software partitioning A sufciently high number of general purpose wires are required running directly between the CPU and the FPGA. The resulting high commmunication bandwidth enables efcient partitioning of operating system functions and user tasks between software and hardware. Support for the 1D resource model In the 1D resource model, the FPGA surface is vertically partitioned into a number of (variable-sized) slots [18]. Some slots accommodate user tasks, while others constitute a part of the operating system. The latter will be recongured rather infrequently and include drivers for the I/O devices and memory access circuitry. Due to fact that the targeted X ILINX V IRTEX technology limits recongurability to vertical chip-spanning columns, all I/O and memory is best connected to pins on the left and the right device edge. Thus, reconguration of user tasks will not effect I/O and memory access. Clock control The user task residing in the task slots might run at different clock speeds, depending on the circuit they implement. The FPGA on the XF-BOARD should have several clock inputs where the clock can be halted and single-stepped for debugging purposes. III. XF-B OARD D ESIGN A. Overview The XF-B OARD is shown in Figure 3. The board has been fabricated as a 6-layer PCB with dimensions of 160 mm 175 mm. Except for the clock lines, no impedance matching has been performed because no signals with overly fast transients are present on the board. Power can be fed using either a standard PC power supply attached to the boards ATX connector or a single +5 V supply. All additional voltages are derived on-board. On both FPGAs, we have installed temperature sensors to monitor the core temperature of the devices. Figure 2 presents a block diagram of the XF-B OARD. The different components and design decisions are discussed in the following paragraphs. B. FPGAs Instead of using a dedicated standard processor (e.g., ARM, PIC, MC ORE), we decided to use a soft core for the implementation of the systems CPU. Although inferior in performance, a soft CPU offers a much higher exibility than a dedicated CPU. A soft CPU can be adapted to varying needs, and its

Power VGA

JTAG

BootPROM

CLK

P-Buttons Eth. PHY RS-232 (2x) PS/2 (2x)

GP I/O

C-FPGA Xilinx Virtex-II

(XC2V1000)

SRAM (1Mx32bit)
SDRAM (16Mx32bit)

MicroBlaze
CLK C/R CLK

FlashRAM (4Mx32bit)
GP I/O

SRAM (1Mx16bit) SDRAM (16Mx16bit) Video DAC RS-232

SelectMAP

SRAM (1Mx16bit) SDRAM (16Mx16bit) Eth. PHY Audio Cdc.

R-FPGA Xilinx mm 88 Virtex-II

(XC2V3000)

Fig. 2 B LOCK DIAGRAM OF THE XF-B OARD ( POWER SUPPLY OMITTED )

detailed implementation may well evolve during the lifetime of the XF-B OARD. We selected the 32 bit RISC processor core X ILINX M ICRO B LAZE, which can be customized with the X ILINX E MBEDDED D EVELOPMENT K IT (EDK). The FPGA implementing the M ICRO B LAZE is denoted as C-FPGA (CPU FPGA). The logic area consumed by the M I CRO B LAZE core and the number of I/O pins used by the CPUs peripherals dictate the minimum size and package of the CFPGA. We have chosen a X ILINX V IRTEX -II XC2V1000 (1280 CLBs) in the FG456 package (324 I/O pins) with a rather fast -5 speed grade to boost the CPUs performance. The C-FPGA is fed with a 50 MHz clock which is internally multiplied by an integer fraction using the V IRTEX -II built-in digital clock managers (DCM). For the recongurable FPGA (R-FPGA), the number of I/Os used by the peripherals governs the package size. We have chosen a Xilinx V IRTEX -II XC2V3000(3584 CLBs) in the FG676 package (484 I/O pins) with a -4 speed grade. From the high number of I/O pins, we only use the ones located at the devices left and right edge (see Section II). The RFPGA receives four clock signals from the C-FPGAs Clock Manager (see Figure 4) plus an additional 50 MHz clock from an external oscillator. C. Peripherals The XF-B OARD is equipped with two 10/100Mbps FastEthernet transceivers (I NTEL LXT970A) with an RJ45 connector. One connector is routed to the C-FPGA and is intended for communication with an external host computer and transmission of conguration data. The second connector is routed to the R-FPGA for streaming and networking applications.

The R-FPGA connects to a high speed video DAC (I NTERSIL HI1178) being capable of displaying 24 bit truecolor on a VGA monitor and an audio codec (A SAHI K A SEI AK4563A) featuring two inputs and one output, all in 44.1kHz, 16 bit stereo CD quality. The R-FPGA is further connected to a 36 pin header to extend the R-FPGA by custom peripherals. The C-FPGA and the R-FPGA are connected by two buses, the main general-purpose I/O bus (GPIO) and an optional general-purpose I/O bus (OGPIO). The GPIO bus is provided to enable communication between the two FPGAs. It is 40 bits wide, e.g., 32 bit data and 8 control signals. The OGPIO bus is 32 bits wide and may only be used if no RHWOS is in service, because the I/O pins are located in the non-static area of the R-FPGA (see Figure 1). Moreover, two 16 pin expansion headers are connected to the OGPIO bus. These expansion ports can be used by the C-FPGA even if the R-FPGA is in RHWOS mode. An 8-LED bar monitors the signal levels of 8 out of the 40 GPIO signals. For primitive I/O and debugging, the XF-B OARD includes two push-buttons and two LEDs attached to each FPGA. Improved I/O and debugging is supported by two PS/2 connectors (e.g., for mouse and keyboard) and an 8-color VGA output that are connected to the C-FPGA. Debugging using an external host computer is enabled by two RS-232 ports attached to the C-FPGA, and one additional RS-232 port attached to the R-FPGA.

Fig. 3 P HOTOGRAPH OF THE XF-B OARD

D. Memory We decided to provide various memory types on the XFB OARD, because the user hardware tasks and the CPU functions can lead to quite different memory requirements and there exists a signicant trade-off between memory speed an cost per bit. The fastest memory available on the board is the FPGAs built-in S ELECT RAM. Although the amount of S ELECT RAM memory is rather limited, the C-FPGA can accommodate a simple hardware operating system with its basic services. The R-FPGAs built-in memory is sufcient to serve a few highspeed, but not overly memory-consuming tasks. To allow for tasks with higher memory requirements, the RFPGA connects to 4 MB of 16 bit wide SRAM memory with 15 ns access time. To store larger amounts of data, 64 MB of 16 bit wide SDRAM memory (7.5 ns cycle time, burst mode) is present. A memory width of 16 bits is consistent with most signal processing applications. The C-FPGA is equipped with the same amounts of SRAM and SDRAM memory, as for some prototypes we expect the need to store additional program code and various bitstreams in RAM. The C-FPGAs external RAM is organized in 32 bits due to the M ICRO B LAZE architecture. 16 MB FlashRAM, 150 ns access time, is present as nonvolatile storage. IV. F IRMWARE The rmware of the XF-B OARD provides basic system functions needed for any operating system prototype. In the following, we describe the rmware which mainly consists of hardware and software running on the C-FPGA, the basic bootstrapping process that loads the rmware, and support for test and debugging. A. C-FPGA The C-FPGA implements a congurable system on chip based on X ILINX M ICRO B LAZE. We have written a lean operating system kernel for the soft CPU core that supports basic task scheduling to facilitate the implementation of functions that constitute parts of the recongurable hardware operating system. The X ILINX M ICRO B LAZE system comprises the CPU core and a number of peripheral cores connected to the system bus: Memory controller and protection cores The memory controller handles the CPUs access to external memory and abstracts from the various storage types present on the board. As the M ICRO B LAZE does not implement a memory management unit (MMU), simple memory protection is implemented in a peripheral core. This protection includes monitoring of stack overows and access to prohibited memory sections, i.e., program code and read-only data. Interrupt controller core The interrupt controller combines the various interrupt signals present in the system into one single signal

C-FPGA

BRAM
ext. Memory Controllers I/O, RS232, Keyb., VGA Ethernet

LMB

CPU Interrupt

Interrupt Controller

MicroBlaze
(32bit RISC CPU)

Memory Protection Timer

OPB

OS-Bridge

DMA Task-Loader

Clock Manager

R-FPGA

Config. Port
(SelectMAP)

Clock Inputs

OS-Bridge

Fig. 4 C OMPONENTS OF THE XF-B OARD F IRMWARE

forwarded to the CPU and sets a status register containing a bit mask according to the interrupts being triggered. That register can be read by the CPU. I/O cores Additional cores are included, offering support for data transfer using the Ethernet and RS-232, text display on a VGA monitor, and keyboard input. Timer core This core provides a system timer that generates periodic interrupts. The timer is required for the systems roundrobin scheduler. DMA task loader core To download the conguration data (full and partial bitstreams) to the R-FPGA whithout bothering the soft CPU, we use a direct memory access (DMA) controller attached to the system bus. OS bridge core The operating system bridge is a simple yet powerful peripheral core used for data transfer from and to the R-FPGA using a set of customized functions. These functions include communication with and control of operating system functions residing in recongurable hardware, checking the systems state (e.g., ll levels of FIFOs), setting run-time parameters of operating system objects (e.g., FIFO sizes), control of user tasks, and debugging functions. Clock manager core The clock manager is responsible to generate various clock signals according to the needs of the user tasks in the R-FPGA.

B. Bootstrapping There exist several ways to start up the XF-B OARD which are shown in Figure 5 and described by the following sequence of steps: 1. The C-FPGA conguration including the M ICRO BLAZE soft CPU core together with a boot loader is

2
SRAM Prg.code

task communication bus

partial reconfiguration

1
BootPROM
JTAG

R-FPGA

C-FPGA
FlashRAM SDRAM

Ethernet

4
R-FPGA

external components

T1

T2
user task area

T3

Tx

C task Tx to be configured

OS frame

Fig. 5 XF-B OARD STARTUP PROCEDURE Fig. 6 PARTITIONING OF THE R-FPGA INTO OS- FRAME AND USER TASK AREA

written to the BootPROM via JTAG. The boot loader includes drivers for basic functions, as external memory controllers, UART, VGA, and Ethernet. 2. The conguration data from the BootPROM is automatically congured into the C-FPGA on power-up which starts the M ICRO B LAZE core that performs a basic system check. This process gets reinitiated whenever the reset button is hit. 3. Now, additional program code for the soft CPU can be received via the Ethernet interface. The basic boot loader receives IP packets and stores their contents into the SRAM. 4. As soon as the last IP packet with program code is received, the basic boot loader sets the cores program counter to the beginning of the received program, and the soft CPU starts executing its main rmware. C. Test and Debugging We have developed a test application to check the components of the XF-B OARD for defects. The application consists of a soft CPU core plus corresponding software and is downloaded and started from an external computer. We can run the test either automatically or in an interactive version, which also allows to test displays and input devices. Debugging the circuits mapped to FPGAs is naturally more complex. Besides primitive debugging aids such as switches, LEDs, and signal headers on the board, we support the X ILINX C HIP S COPE tool which either uses JTAG or RS-232 connectors as debugging channel. V. P ROTOTYPING O PERATING S YSTEMS The XF-B OARD and its rmware are designed to enable a wide range of prototypes for recongurable hardware operating systems. Such an operating system will consist of functions that run in recongurable hardware (on the R-FPGA) and of functions that run in software (on the C-FPGA). In our prototypes, the software functions are added to the rmware functions on the M ICRO B LAZE core. The functions on the R-FPGA are placed into the so-called OS frame [9]. Figure 6

displays the generic layout of the R-FPGA. The recongurable area of the R-FPGA splits into two regions, the OS frame and the user task area. The two OS frame segments are located at the left and right sides of the R-FGPA which allows direct control of all external components such as memory and I/O. Further, the OS frame accommodates circuits which need to reside permanently in the system, i.e., device drivers. Altough typically the OS frame remains unchanged during system operation, we conceive its reconguration in order to adapt the operating system to different application scenarios. The user task area accommodates the dynamically loaded hardware tasks. In [9], we presented a xed-size 1D resource model where the user task area was pre-partitioned into a xed number of task slots of given size. With the XFB OARD prototype we intend to demonstrate variable-sized 1D resource models as shown in Figure 6. To support different prototypes, the XF-B OARD provides versatile full and partial reconguration and readback capabilities for the R-FPGA. At system startup, the entire RFPGA needs to be initialized with the OS frame by loading a full bitstream. A full bitstream for the Virtex-II 3000 holds a total of 1311796 bits. Using the DMA task loader core (see Section IV), the download of a full conguration takes approximately 24ms @ 50MHz. The partial reconguration times for the user tasks range from 1.5ms to 15ms, depending on their size and bitstream compression ratio. Full and partial readback functions are supported to retrieve the current state of the circuits. The following sequence of steps demonstrates the main conguration procedure for the R-FPGA (shown in Figure 7): 1. The full and partial conguration bitstreams for the R-FPGA are received via Ethernet and stored in the FlashRAM. Storing these bitstreams in non-volatile memory is important to support the standalone operation of the XF-B OARD. 2. The full and partial congurations can be transferred to SDRAM for a fast conguration of the R-FPGA. This

SRAM Prg.code

BootPROM

C-FPGA
FlashRAM bitstr1 bitstr2 bitstr3 bitstr n SDRAM bitstr1 bitstr2 bitstr3 bitstr n

1
Ethernet

3
R-FPGA

2
Fig. 7 B ITSTREAM TRANSFER AND R-FPGA RECONFIGURATION

is done automatically when the system is restarted or, alternatively, on an explicit command. When triggered by a command, either every conguration or only a subset is transferred. 3. The R-FPGA can be fully or partially recongured with bistreams from the SDRAM at maximum speed. The XF-B OARD has primarily been developed for conducting research in RHWOS. However, since a multitude of different I/O devices and memory is available, the XF-B OARD is an adequate and powerful platform for many other purposes, e.g. for implementaton of computational intensive realtime signal processing applications, as multimedia encoding/decoding, audio processing, etc. The board provides standard expansion headers (I/O and power supplied) to allow for connecting tailored add-on boards. VI. C ONCLUSION AND F URTHER W ORK We have presented the XF-B OARD, a prototyping platform for recongurable hardware operating systems. The platform is targeted towards networked embedded systems and specialized to the 1D recongurable resource model. We have surveyed the main components and rmware functions of the XF-B OARD. We are convinced that the presented prototyping platform will help us in demonstrating more advanced operating system prototypes that what has been shown to date. The next step is the implementation of the variable-sized 1D resource model which will lead to an improved resource utilization over the presently used xed-size model. Consequently, we will evalutate the OS functions and services by executing multimedia and networking applications. VII. ACKNOWLEDGEMENTS This work was supported by the Swiss National Science Foundation (SNF) under grant number 2100-59274.99 and by Xilinx Inc. with hardware donations. R EFERENCES
[1] Gordon Brebner. A Virtual Hardware Operating System for the Xilinx XC6200. In Proc. 6th Intl Workshop on Field-Programmable Logic and Applications (FPL), pages 327336, 1996.

[2] Gordon Brebner. The Swappable Logic Unit: a Paradigm for Virtual Hardware. In Proceedings of the IEEE Symposium on FPGAs for Custom Computing Machines (FCCM). IEEE CS Press, 1997. [3] Grant Wigley and David Kearney. Research Issues in Operating Systems for Recongurable Computing. In Proceedings of the International Conference on Engineering of Recongurable System and Algorithms(ERSA), pages 1016. CSREA Press, Juni 2002. [4] H. Simmler, L. Levinson, and R. M nner. Multitasking on FPGA a Coprocessors. In Proceedings of the 10th International Workshop on Field Programmable Gate Arrays (FPL), pages 121130. Springer, 2000. [5] Gordon Brebner and Oliver Diessel. Chip-Based Recongurable Task Management. In Proceedings of the 11th International Workshop on Field Programmable Gate Arrays (FPL), pages 182191. Springer, 2001. [6] Pramote Kuacharoen, Mohamed A. Shalan, and Vincent J. Mooney III. A Congurable Hardware Schedulder for Real-Time Systems. In Proceedings of the 3rd International Conference on Engineering of Recongurable Systems and Architectures (ERSA), pages 95101. CSREA Press, June 2003. [7] Matthias Dyer, Christian Plessl, and Marco Platzner. Partially Recongurable Cores for Xilinx Virtex. In Proceedings of the 12th International Workshop on Field Programmable Gate Arrays (FPL), pages 292301. Springer, September 2002. [8] IMEC Interuniversity Micro Electronic Center, T-ReCS Gecko: Hardware / Software multitasking on a recongurable platform, http://www.imec.be. [9] Herbert Walder and Marco Platzner. Recongurable Hardware Operating Systems: From Design Concepts to Realizations. In Proceedings of the 3rd International Conference on Engineering of Recongurable Systems and Architectures (ERSA), pages 284287. CSREA Press, June 2003. [10] J rgen Becker and Manfred Glesner. A Parallel Dynamically Reu congurable Architecture Desigend for Flexible Application-Tailored Hardware/Software Systems in Future Mobile Communication. The Journal of Supercomputing, 19(1):105127, 2001. [11] Gordon Brebner. Single-chip Gigabit Mixed-version IP Router on Virtex-II Pro. In Proceedings of the IEEE Symposium on FPGAs for Custom Computing Machines (FCCM), pages 3544. IEEE Computer Socitey, 2002. [12] Christian Plessl, Rolf Enzler, Herbert Walder, Jan Beutel, Marco Platzner, Lothar Thiele, and Gerhard Tr ster. The case for recongurable o hardware in wearable computing. Personal and Ubiquitous Computing, 7(5):299308, October 2003. [13] Herbert Walder, Christoph Steiger, and Marco Platzner. Fast Online Task Placement on FPGAs: Free Space Partitioning and 2D-Hashing. In Proceedings of the 17th International Parallel and Distributed Processing Symposium (IPDPS) / Recongurable Architectures Workshop (RAW), page 178. IEEE Computer Society, April 2003. [14] Christoph Steiger, Herbert Walder, and Marco Platzner. Heuristics for Online Scheduling Real-time Tasks to Partially Recongurable Devices. In Proceedings of the 13rd International Conference on Field Programmable Logic and Application (FPL), pages 575584. Springer, September 2003. [15] Santanu Dutta, Rune Jensen, and Alf Rieckmann. Viper: A Multiprocessor SoC for Advanced Set-Top Box and Digital TV Systems. IEEE Design and Test of Computers, September-October:2131, 2001. [16] V. Nollet, J.-Y. Mignolet, T.A. Bartic, D. Verkest, S. Vernalde, and R. Lauwereins. Hierarchical Run-Time Reconguration Managed by an Operating System for Recongurable Systems. In Proceedings of the 3rd International Conference on Engineering of Recongurable Systems and Architectures (ERSA), pages 8187. CSREA Press, June 2003. [17] T. Marescaux, J.-Y. Mignolet, A. Bartic, W. Moffat, D. Verkest, R. Vernalde, and R. Lauwereins. Networks on Chip as Hardware Components af am OS for Recongurable Systems. In Proceedings of the 13th International Conference on Field Programmable Gate Arrays (FPL), volume LNCS 2778, pages 595605. Springer, September 2003. [18] Herbert Walder and Marco Platzner. Online Scheduling for Blockpartitioned Recongurable Devices. In Proceedings of the International Conference on Design, Automation and Test in Europe (DATE), pages 290295. IEEE Computer Society, March 2003.