A set-theory based approach of Runtime Reconfigurable

systems suitable for education purposes.

Abdellah touhafi (1), Erik Dikx (2)
atouhafi@info.vub.ac.be, efdirkx@info.vub.ac.be
(1) Nijverheidskaai 170, B1070 Brussels, Belgium
(2) Pleinlaan 2, B1050 Brussels, Belgium

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.

Informally we can define a generalized Reconfigurable Computing system as follows:

Definition 1: A reconfigurable computing system is a network of programmable computing

elements in which the network structure can be changed pre runtime, at runtime and post runtime.
The system can contain programmable fixed-structure computing elements and configurable
variable-structure computing elements together with a reconfiguration controller that has the
ability to change the system’s structure. The computing elements are interconnected and
exchange data and control information according to the needs of the application.

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 } .

2. The second conceptual RC element is the set of information elements:

A RC system has several kinds of memory to store different kinds of information. Four kinds
of information can be distinguished.
• Application data: under application data we group all kinds of input data for the
system as well as intermediate results that must be stored and final results that are
stored.
• Process behavior code: This is the information necessary to program the computing
elements such that they follow a given behavior. This can be a configuration for an
FPGA or object code for a RISC.
• State information: The state information is the set of data used to characterize the
state of a process and is located in a set of storage-elements or is a set of signal
values.
• Structure information: The structure data represents how the processes that are
implemented as configurations or object code elements, are related. By changing the
structure information, it is possible to change the communication structure among the
processes.

We will hence represent the different kinds of information by a set M = {P, D, Q, I }

In which P is the processes behavior code memory, D is the application data memory, Q is
the state memory and I is the structure memory. The definition of the data formats for the
different elements depend on the used computing model.

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.

2. Formal RC systems Model

(
Definition 1: A conceptual RC system is a tuple: CE, R
)
with CE = {C , CR , M } is the set of conceptual elements in which
• C is the reconfiguration controller.
• CR = {CR F , CR R } is the set of computing resources in which CR is the set of fixed
F
architecture computing elements and CRR is the set of reconfigurable architecture computing
elements.
• M = {P, D, Q, I } is the memory space which contains information elements.

•
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 )

3. Conceptual Diagram Representation

The formal definition can be represented as a conceptual diagram in which the different
conceptual parts of a reconfigurable computing machine and their mutual relations are shown. In
Figure 1 a diagram that contains all the conceptual elements of the generic RC model definition is
demonstrated.

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

Coupling C with access Coupling CR with

parameters information elements and
reconfiguration controller

Access parameters

Data Bus Access to Access to Access to

state memory Behavior structure

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.

Example 1: Static Hybrid RC System:

The Static Hybrid RC system architecture is an often-used architecture because of its simplicity
and straightforward computing model. This type of RC system can be implemented in many
ways. A frequently used approach is the combination of a workstation with an extension board
that contains reconfigurable logic resources and memory. This architecture is used to speedup
applications that can benefit from hardware-software (HW/SW) co-design techniques [1]. That
technique tries to come to efficient implementations by implementing dedicated co-processors for
the computational hard parts into the reconfigurable logic while the control intensive parts of the
application are implemented in software on a general purpose processor. Architecturally there are
several implementations possible but they all have the same conceptual system architecture. The
used computing model is based on the principle of communicating processes. The software part
implements one process or a set of processes that communicate with the process(es) implemented
onto the reconfigurable logic.
Let us consider the following example of a static RC system:
The Static RC system is formally defined as: (CE , R )
In which the system elements are defined as follows:
• The reconfiguration controller C is defined such that it configures the reconfigurable
elements at system-setup before it starts computing. The reconfigurable part is generally used
as a generic co-processor that can be configured with a custom accelerator circuit for an
application. The controller has only access to the configuration data in order to setup the
reconfigurable parts. Before we can formally define how the controller operates, we first
have to define the other elements of the static RC system.
• The computing resources set CR = {CR F , CR R } contains both fixed structure elements and
reconfigurable structure elements; that’s why the system is called hybrid.
• The elements of the memory space M = {D, P, Q, I } are defined as follows:
P = {p , p ,p }
• The behavior memory f r ext rlocal
defines the memory regions in which the
different behaviors are located. For static hybrid RC’s we suppose that there is a memory
p
region for the software code of the application denoted by f and two memory regions to
store the configuration of the reconfigurable logic. The memory regions of the latter
p
contain a part rlocal that is the local memory region of the reconfigurable logic.
Whatever is written in that region has a direct impact on the behavior of the
p
reconfigurable computing elements. The second memory region rext is an external
memory region dedicated to the storage of reconfigurable logic configuration(s). This is
done to make a distinction between the local memory used to program the reconfigurable
logic elements and the external memory from which the controller loads the desired
configuration. Remark that the external memory size can be a multiple of the local
memory size. This is the case when the reconfigurable logic must support more than one
application. Depending on the application running on the RC system, the reconfigurable
logic will be configured differently at system startup. For simplification, we don’t
represent eventual external storage for the fixed architecture logic in the model.
D = {D f , Dr } Df
• The data memory set contains two subsets in which is the memory region
p p
for the data set of f and Dr is the memory region for the data set associated with rlocal .
Remark that there is no explicitly defined data region for the configurations located in the
external behavior memory of the reconfigurable logic. Defining a memory for those
behaviors is of no sense since they are inactive and hence, don’t require any data-memory.
Only the activated behavior has a data region for the storage of its application data.
Q = {Q f , Qrlocal , Qrext } Qf
• The state set consists of three subsets in which is the state
information related to the processes running on the fixed logic elements,
Qrlocal is memory
Q
space for the state information related to the configuration that is activated and rext is
memory related to the configurations located in the external memory of the reconfigurable
logic. Remark that in contrast with the data set memory there is memory foreseen for the non-
active configurations. This because the state information is necessary to setup a behavior into
its initial state.
• The behavior interconnect data I ⊆ P×P in its most generic way is:
I = {( p f , pr local ), ( prlocal , p f )}
. This means that the process that runs on the general-purpose
processor can send data to the process that runs on the reconfigurable logic and vice versa.
The interconnect function also states explicitly that the configuration located in the external
memory can’t interact with the running processes.
• The conceptual parts interconnect function is defined as:
⎧(C ↔ p rlocal , Qrlocal ), ( p rext , Qrext , I → C ),⎫
⎪ ⎪
R = ⎨(CR F ↔ CR R ), ⎬
rlocal ), (CR F ↔ D f , Q f ) ⎭
⎪(CR ↔ D , Q ⎪
⎩ R r

The interconnect function is to be interpreted as follows:

The first term in line 1 states that the reconfiguration controller has read and write access to the
local storage space of the reconfigurable logic. While the second term states that the
reconfiguration controller has only read access from the external memory space. The read access
from - and write access to the local configuration memory of the reconfigurable logic is necessary
in order to program the reconfigurable elements.
The third term states that the reconfigurable logic elements and the fixed architecture elements
mutually exchange data. In most implementations, this means that the system provides a bi-
directional communication bus between the reconfigurable - and fixed architecture elements.

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

3. connect( pf,prlocal) ; connect(prlocal ,pf) // setup bi-dir. Comm. channel

4. }

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.

Example2: Self Reconfiguring RC Systems

To show the functional contrast with a conceptually different system we will discuss self
reconfiguring RC systems briefly.
This conceptual RC system is used as a computational platform in evolvable systems [4]. We
have chosen this example because of its enormous conceptual differences with the static RC
system.
The evolvable-hardware computing paradigm tries to come to a computing principle in which the
computing resources them-self re-compute their architectural setup. The idea behind this is that
such a system will be able to change its architectural setup to specialize itself for a temporal
computing need or to configure itself to achieve a wanted behavior.

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

Figure 2: General setup of evolvable system based on reconfigurable logic

That this system is conceptually different from the static RC system follows from its conceptual
parts interconnect-function.

R = {(C ↔ p rlocal , p rext , Qrlocal , Qrext , I ), (Dr → C ), (CR R ↔ Dr , Q )}

Formula 0-1

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

Figure 3: Conceptual diagram of evolvable RC system

• The reconfiguration controller

A major difference with the static Hybrid RC system is in first instance the increased importance
of the reconfiguration controller. The reconfiguration controller is no longer an isolated element
with a highly restricted access to the sets of information elements. In contrast with the static RC-
system, we notice that the conceptual diagram provides write access to all the information
elements that have an influence to the systems behavior. In addition, the controller has also read
access to the application data. Consequently, we can expect that this reconfiguration controller
requires a much higher operation complexity than the reconfiguration controller of the static RC
system. We can also deduct from the computation model that the controller is active at runtime
since it monitors the information elements and computes configurations based on that
information. In order to reconfigure the system the reconfiguration controller writes the new
p Q
configuration into rlocal and rlocal which causes the computing elements to change their
behavior. The second term in R (Formula 0-1) means that the controller has read access to the
data memory. We can hence come to a physical implementation of the described computing
model since the reconfiguration controller can monitor the data-elements and can change the
p ,Q ,I
contents of the configuration memory (i.e. rext rext ) in which the newly computed
configurations are stored. Once a reconfiguration must be accomplished, the reconfiguration
controller copies (a part of) the external configuration setup into the local configuration memory
p ,Q
(i.e. rlocal rlocal ).
The third term of R (Formula 0-1) provides the necessary interconnections such that the
computing elements can be evaluated on their behavior.

• The computing resources

The computing resources are in this case only reconfigurable structure elements. The computing
elements do not change themselves, they are used as a mean to evaluate the newly generated
configuration.
• Information set
Concerning the information set, there are no important differences. A possible difference which is
not necessary, is the size of the external configuration space. It is possible that a much larger
external reconfiguration space is foreseen, in order to store several configurations among which
the reconfiguration controller can choose.

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.