Professional Documents
Culture Documents
Most bachelor and master students have a sound basis of set theory and know how to apply it for
computational problems. In this paper we will introduce a theoretical RTR model based on set theory that is
suitable for teaching as well as research purposes. In contrast with the classic RC hardware models, this
model is not based purely on the structural aspects of an RC system. The model approaches a system as a
set of related conceptual parts. The advantage of that approach is that we have now a basis to reflect on one
hand what kind of requirements are needed to implement a certain computing model and on the other hand,
whether a certain RC system has the potential to implement that computing model.
1. Introduction
In many classes reconfigurable computing is approached as a flexible way to implement
(embedded) digital systems to solve a particular computing problem. The main focus is then put
on the available technology and basic or advanced digital design techniques.
Although this is a good and practical way to introduce reconfigurable computing, we believe that
a broader view on the possibilities of reconfigurable computing should be created by means of
theoretical concepts. Hence we’ve defined a theoretical model of reconfigurable computing
systems using set theory. In this paper we will give an informal definition of reconfigurable
computing which is then formalized.
A reconfigurable computing system extends the concept of a fixed architecture computing system
by adding reconfigurable logic elements and a structure reconfiguration function that provides the
possibility to change the architectural setup of the system. This includes the change of
interconnect, the reconfiguration of hardware and the activation or deactivation of reconfigurable
computing elements. In the given informal description of a RC system, we can distinguish three
fundamental elements that form its conceptual parts.
1. The first conceptual element in a RC system is the set of programmable computing elements
that can be divided into two categories: structurally fixed and structurally variable. We will
group those elements together into one set called the computing
resources: CR = {CR F , CR R }.
• CR F is a subset that contains all the fixed structure computing elements found in the
system. For example, a system that is composed of two RISC processors and one
DSP processor is represented by a set: CR F = {RISC1 , RISC 2 , DSP1 } .
• CR R is the subset of all the structurally reconfigurable elements that are part of the
RC system. For example a system that contains two FPGAs is represented by a set
CR R = {FPGA1 , FPGA2 } .
3. The third conceptual element is the reconfiguration controller. This element provides the
flexibility to set up - and even change - the behavior of a RC system by changing the
configuration of the computing elements and by changing the interconnect setup. Since the
system status and behavior is completely contained in the information set M , it becomes
possible to conceptualize a change in the system setup and behavior by giving the
reconfiguration controller write-access to the complete set or a subset of the information
elements. The reconfiguration controller can be seen as a “hardware scheduler” that changes
the behavior of the system by scheduling other process behavior codes and structures.
The conceptual elements together with an interconnect function specify how a RC system is
conceptualized in its entirety. With this, we have a base to define formally how RC systems are
build conceptually.
•
P = { p1 , p 2 ,..., pi } : is the set of process behaviors, which are implemented as
configurations in the case of reconfigurable logic elements and as program sequences in
the case of fixed architecture elements.
•
D = {D1 , D2 ,..., Di }: is the set of data-sets for process behaviors p1 .. pi with i the
number of behaviors.
•
Q = {Q1 , Q2 ,..., Qi }: Contains the state information for the processes p1 ... pi with i the
number of processes.
• I ⊆ P × P : is the set of possible interconnection setups of the behavior elements.
R ⊆ {(cei , ce j ) ∈ CE × CE with cei ≠ ce j }
• : is the conceptual parts connect function.
The following notations are introduced to shorten the notation of the conceptual parts connect
function elements.
Notations 1:
1. ( X , Y ), (Y , X ) ≡ ( X ↔ Y )
2.
( X ↔ Y1 ), ( X ↔ Y2 ),..., ( X ↔ Yn ) ≡ ( X ↔ Y1 , Y2 ,..., Yn )
3.
( X , Y1 ), ( X , Y2 ),..., ( X , Yn ) ≡ ( X → Y1 , Y2 ,..., Yn )
4.
( X 1 , Y ), ( X 2 , Y ),..., ( X n , Y ) ≡ ( X 1 , X 2 ,..., X n → Y )
In the diagram we find the following blocks that are equivalent with the elements found in the
formal definition:
• The Reconfiguration controller block: represents C and is pictorially represented as a
reconfiguration engine block and a reconfiguration program block.
• The Computing resources block: represents CR and is divided into two blocks, one
representing the fixed architecture elements and a second one representing the reconfigurable
architecture elements.
• The Memory Space block: represents M and is subdivided into four blocks each one
representing a specific information set.
• A fourth block in the diagram, the “Access Parameters” is used only for a clear representation
of the conceptual relation between the three conceptual parts. The access parameter block can
be seen as a relations grouper and distributer between the reconfiguration controller, the
computing resources and the memory space.
• The relations between the conceptual elements are represented by directed arrows that are the
couples found in the ‘conceptual parts interconnect function’. The interpretation of the
couples (arrows) depends on the nature of the interconnected elements. In that respect, we
make a difference between active and passive elements. The computing resources and the
reconfiguration controller are active elements while the memory is a passive element that can
not initiate a read or a write operation. An interconnection between two active elements is
equivalent with communication in the arrows direction. Without specifying what element of
the two is the initiator of the communication. For example, the couple (C , CR R ) is the arrow
that goes from the reconfiguration controller block to the block with reconfigurable
computing elements. Hence, the reconfiguration controller can send information to the
reconfigurable logic elements. The opposite couple (CR R , C ) means that the computing
elements can send information to the reconfiguration controller. A couple that consists of a
passive component followed by an active component (i.e. arrow from passive to active
component) means that the active component can read from the passive component. The
inverse couple setup means that the active component can write data into the passive
component. For example, (CR R , D ) means that the reconfigurable architecture elements
have write access to all the application-data elements while (D, CR R ) means that the
reconfigurable logic elements have read access from all the application-data elements.
Computing Resources CR
Reconfiguration Controller C
Reconfiguration
program
Fixed reconfigurable
architecture structure
computing computing
Reconfiguration Engine elements elements
Access parameters
M
Application data state variables of Process behaviors Interconnect
processes: information of behaviors
D Q P I
Figure 1: Diagram of conceptual parts found in a generic RC system and their mutual relations
• Three kinds of arrows are used to represent the relations between the conceptual elements.
Dark arrows are used for the relation between the reconfiguration controller and the other
elements of the RC model. Dotted arrows are used for connections between the
reconfigurable architecture elements and the other conceptual elements. Gray arrows are used
to represent connections between the fixed architecture elements and the other conceptual RC
elements.
The task of the reconfiguration controller is to deal with the change of the structural relation
between the reconfigurable processing elements. Since there is a direct relation between the
information elements and the system setup, the reconfiguration controller can change the
structure by changing the contents of the memory space.
• The computing resources reflect the physical implementation of the structural and behavioral
information in the memory space and perform computation tasks on the application data.
• The memory space is a conceptual representation of the memory in the reconfigurable
computing system that is applied to store the application data, the state information of the
different circuits, the behavior of the circuits (i.e. how the processing elements are
programmed) and the structural information. All the elements that are represented in the
memory space can be changed.
4. Conceptual RC systems
Based on the formal definition of RC systems we can specify how a RC system is conceptually
build. We can also compare two RC systems on the conceptual level and on the architectural
level. RC systems that are implemented to serve the same objectives will be conceptually equal
but may differ in their architectural setup.
Definition 2: Two RC systems are said to be conceptually different if their conceptual parts interconnect
function R is different.
Definition 3: Two RC systems are said to be architecturally different if their interconnect function R is
the same but there is a difference in the definition of the reconfiguration controller, the definition of the
memory setup or the definition of the computing resources.
The given definitions are illustrated by two examples of conceptually different RC systems. The
first kind of RC system discussed is the static Hybrid RC system that is now a state of the art
system-architecture. The second kind of conceptual RC system discussed, is the self
reconfiguring RC system that is used in evolvable systems.
The fourth term states that the reconfigurable part can read from - and write to the application
data memory and the local state memory. The same is defined for the fixed architecture elements
in the fifth term.
Remark, that the application-data memories of the reconfigurable architecture elements and the
fixed architecture elements are separated and that there is no possibility to access the others
memory directly. Data exchange is hence only possible through the defined interconnection
between the two computing elements and not by memory sharing.
Now that all the elements of the RC system have been defined, we can specify the behavior of the
reconfiguration controller.
1. Cbeh {
2.
p
rlocal := p
rext ; Q
rlocal := Q
rext //setup the reconfigurable logic elements
From the interconnect function it becomes clear that the reconfiguration controller can not
directly interact with the computing resources. This is one of the main characteristics for this
conceptual RC system. We can also derive the conceptual element relations and the
communication directions.
Variations on the element definition of this RC system are possible and represent architectural
differences rather than conceptual differences. For example, differences in the definition of the
reconfigurable structure elements like the amount and their type, lead to the same conceptual
system although they have a completely different architectural setup. As an example we can
compare the DEC-PeRLe RC system [2] which is a multi-FPGA system that is loosely coupled to
a host station, with a RISC processor that has an integrated reconfigurable logic area closely
coupled with the RISC’s I/O bus [3]. The systems are architecturally completely different, but
they are both based on the same conceptual setup.
The operation model of a self-reconfiguring RC system consists of at least two parts as shown in
Figure 2 . The first part is the application part that receives a set of input data and generates a set
of output data. The second part is the configuration re-calculation part that monitors the INPUT-
OUTPUT relation and eventually other environmental inputs. Depending on the given inputs and
the state of the configuration re-calculator a new (better) system setup is calculated. The system is
first setup with an initial configuration after which it enhances its configuration until a certain
goal-functionality or efficiency is achieved.
IN Configuration OUT
(application)
New
Configuration
Configuration
Re-calculator
That this system is conceptually different from the static RC system follows from its conceptual
parts interconnect-function.
Rather than giving the whole detailed formal definition of self reconfiguring RC systems, we will
restrict ourselves to a discussion of the conceptual diagram representation (Figure 3), since it
contains all necessary information to explain the differences.
Computing Resources CR
Reconfiguration Controller C
Reconfiguration
program
reconfigurable
Reconfiguration Engine structure
elements
Access parameters
M
Dr {Qrlocal,Qrext} {prlocal , prext} I
Q P
5 Conclusions
This paper introduces a simple and straightforward way to model Reconfigurable computing
systems using Set Theory notations. This approach has proven to be an acceptable way to explain
the very broad field of reconfigurable computing in a unified model that is built up from three
conceptual parts. The conceptual parts are the programmable computing elements, the
information elements and the reconfiguration controller. As example two conceptually different
systems have been specified.
References:
[1] Karam S. Chatha and Ranga Vermuri. Hardware-Software Codesign for Dynamically
Reconfigurable Architectures. 9’th International Workshop on Field Programmable Logic
and Applications(FPL’99), September 1999.
[2] O. Mencer, M. Morf, and M.J. Flynn. PAM-Blox: High performance FPGA design for
adaptive computing. In K. Pocek and J. Arnold, editors, Proceedings of IEEE Workshop
on FPGAs for Custom Computing Machines, pages 167–174, Napa, CA, April 1998.
IEEE Computer Society, IEEE Computer Society Press.
[3] S. Hauck, T. W. Fry, M. M. Hosler, and J. P. Kao. The Chimaera reconfigurable
functional unit. In IEEE Symposium on FPGAs for Custom Computing Machines
(FCCM ’97), pages 87–96, April 1997.
[4] French,P. C., and Taylor, R. W. A self-reconfiguring processor. In Proceedings of IEEE
Workshop on FPGAs for Custom Computing Machines (Napa, CA, Apr. 1993), D. A.
Buell and K. L. Pocek, Eds., pages 50–59.