Clemson Reconfigurable Computing

PARL Home | RC Home | ACC | RCADE | ROAR

ROAR Projects

Reconfigurable Online Architectures


Reconfigurable Computing (RC) is an area of computer systems architecture that studies the use of reconfigurable logic as a computational device to be used along with other computing structures such as integer ALUs, memory management units, floating-point multipliers, disk controlers, and network interfaces. As a practical matter, today RC is usually built with FPGAs. RC is also known as ``Custom Computing Machines'' (CCMs) or just ``Configurable Computing.'' By reconfigurable logic, we are talking about programming the hardware at the gate-level rather than at the machine instruction level. That is, if we want to add two binary numbers with RC, we configure a set of Configurable Logic Blocks (CLBs) to perform the appropriate AND/OR/NOT operations and then configure routing resources to logically connect CLBs into an ``add'' circuit. In a general-purpose microprocessor, we encode the bits of a machine instruction to represent an ADD. The translation of a high-level programming language to machine language is called compiling and resulting machine language is called a binary image. Similarly, hardware circuits can be expressed in a Hardware Descripton Language (HDL). The translation to a gates and routing information is called synthesis and the resulting sequence of bits is called a configuration.

It is related to, but subtly different from, Adaptable/Dynamic Systems which, as defined by NSF (NSF Workshop on Directions for Systems Research, 1997) includes programmable engines in memory controllers, cache controllers, configurable data paths, etc. So Adaptable Systems are configurable but not necessarily built with FPGAs. In general, RC are adaptable systems and implies FPGAs.

The Reconfigurable Online Architecture Research (ROAR) Project is concerned about one particular aspect of RC called Run-Time Reconfiguration (RTR). Clearly, programming the hardware at the gate level is much more time consuming and is usually done (with great pains) long before the application is executed. Also, once the desired circuit is programmed and the application starts, that circuit is fixed until the next application reprograms it. RTR reprograms (or adapts) the circuit multiple times during execution. We make the following distinction between online and offline RTR. If the configuration is determined during run-time and the CLBs are programmed (and reprogrammed) during run-time, then it is an online RTR system. Offline RTR refers to systems where all of the possible configurations are synthesized a priori but the CLBs may be programed (and reprogrammed) during execution.

Most research in offline RTR is motivated by efficient use of the expensive CLB resources. (The CLBs are reusable so offline RTR allows large configurations to use fewer physical CLBs via a type of programmer-managed ``virtual CLBs.'' This is akin to program overlays prior to virtual memory in operating systems.) Online RTR has the same benefit but the motivation for online RTR is usually improved performance.

Since synthesis is a long, time-consuming process (usually synthesizing a configuration takes much longer than compiling a binary image), online RTR may seem like it could not possibly result in higher peformance. Indeed, with synthesis times commonly taking hours and sometimes days for big configurations, online RTR would seem completely infeasible. But, in fact, there are a number of examples of online RTR and the potential performance gains are enormous.

Thus, the primary objective of the ROAR project is to investigate and advance online RTR systems. We have a number of ongoing investigations addressing various issues related to the viability of new techniques for online RTR. The research projects available range from semester-long projects to Ph.D. dissertations in length and include both very practical projects and very theoretical projects.



  • Dr. Ron Sass
  • Srinivas Reddy Beeravolu
  • Ranjesh G Jaganathan
  • Shyamnath Harinath
  • Krishna Mohan Muriki
  • Matt Simpson
  • Brian Greskamp
  • Brian Leonard



Please mail Comments/Suggestions to Ranjesh or Srinivas at { jranjes , sbeerav } at