Neurocomputing 121 (2013) 25–31

Contents lists available at ScienceDirect

Neurocomputing
journal homepage: www.elsevier.com/locate/neucom

A self-adaptive hardware architecture with fault tolerance capabilities

Javier Soto n, Juan Manuel Moreno, Joan Cabestany
Technical University of Catalunya, Electronic Engineering, Campus Nord, Building C4, c/Jordi Girona 1-3 08034 Barcelona, Spain

art ic l e i nf o a b s t r a c t

Article history: This paper describes a Fault Tolerance System (FTS) implemented in a new self-adaptive hardware architecture.
Received 25 January 2012 This architecture is based on an array of cells that implements in a distributed way self-adaptive capabilities.
Received in revised form The cell includes a configurable multiprocessor, so it can have between one and four processors working in
12 October 2012
parallel, with a programmable configuration mode that allows selecting the size of program and data
Accepted 29 October 2012
Available online 6 May 2013
memories. The self-elimination and self-replication capabilities of cell(s) are performed when the FTS detects
a failure in any of the processors that include it, so that this cell(s) will be self-discarded for future
Keywords: implementations. Other adaptive capabilities of the system are self-routing, self-placement and runtime self-
Self-adaptive configuration. Additionally, it is described as an example application and a software tool that has been
Self-placement
implemented to facilitate the development of applications to test the system.
Self-routing
& 2013 Elsevier B.V. All rights reserved.
Self-replication
MIMD
Dynamic fault tolerance

1. Introduction
In coming years adaptive systems promise to change radically our
experience, in order to provide high performance computation power
to serve the increasing need of large, complex and parallel applica-
tions. Self-adaptation is defined as the ability of a system to react to its
environment in order to optimize its performance. The system could
also change its behavior to adapt its functionality to a new mission,
with respect to the environment and the user needs [1]. Adaptive
computing systems constitute a promising technology with respect to
classical computing architectures.
Self-healing is a special feature of an adaptive system, where
hardware failures should be detected, handled and corrected by
the system automatically.
In this paper we aim to show a new hardware architecture, whose
principal characteristics are the self-adaptive capabilities implemen-
ted, that are executed autonomously and in a distributed way by the
system members (cells). Basically, this is a novel unconventional
MIMD hardware architecture with self-adaptive capabilities like self-
routing, self-placement, self-configuration, self-elimination and self-
replication, which includes a fault tolerance system that permits a
given subsystem to modify autonomously its structure in order to
achieve fault detection and fault recovery.
The architecture proposed includes two mechanisms of fault
tolerance (FT). One of these is the Dynamic Fault Tolerance Scaling
n
Corresponding author. Tel.: +34 66 035 7384.
E-mail addresses: javier.soto.vargas@upc.edu,
javiersotovargas@gmail.com (J. Soto),
joan.manuel.moreno@upc.edu (J. Manuel Moreno),
joan.cabestany@upc.edu (J. Cabestany).
Technique [2], that has the ability to create and eliminate the
redundant copies of the functional section of a specific application.
The other mechanism of fault tolerance (presented in this paper)
is a dedicated or static Fault Tolerance System (FTS). It provides
redundant processing capabilities that are working continuously.
When a failure in the execution of a program is detected, the
processors of the cell are stopped and the self-elimination and
self-replication processes starts for the cell (or cells) involved
in the failure. This cell(s) will be self-discarded for future self-
placement processes.
Other projects that propose fault tolerance on adaptive architec-
tures have been developed, like ReCoNet-platform [3] that presents
a framework for increasing fault tolerance and flexibility by solving
the problem of hardware/software codesign online. It is based on
field-programmable gate arrays (FPGAs) in combination with CPUs
that allow migrating tasks implemented in hardware or software
from one node to another. The principal difference with the platform
presented in this paper is its high scalability and that it could
provide a lot of processing units, with less processing capacities, but
where any processor could implement a fault tolerance system.
Additionally it provides self-adaptive capabilities like self-placement
and self-routing in a large array of processing units.
Reference [4] proposes a framework under which different fault
tolerant schemes can be incorporated in applications using an
adaptive method. Under this framework, applications are able to
choose near optimal fault tolerance schemes at run time according to
the specific characteristics of the platform on which the application is
executing. This framework is presented for high performance parallel
and distributed computing. Compared with this framework the
architecture proposed in this paper provides adaptive capabilities
at hardware level different from application level.

0925-2312/$ - see front matter & 2013 Elsevier B.V. All rights reserved.
http://dx.doi.org/10.1016/j.neucom.2012.10.038
26 J. Soto et al. / Neurocomputing 121 (2013) 25–31
2. Description of the architecture
Any application scheduled to the system has to be organized in
components, where each component is composed by one or more
interconnected cells. The interconnection of cells inside a compo-
nent is made at cell level, while the physical interconnections of
components are made in switch matrix level.
In the initial state, all cells are free, i.e., they do not belong to any
component. Then, the components have to be placed and connected
for data processing and information exchange. This is a sequential
process where each cell has to be placed and routed in the system.
For this purpose, the cells execute in a distributed way the self-
placement and self-routing algorithms. All cells have got a 32-bit
unique identifier called address. This field is divided into two 16-bit
words, called id_component and id_cell. The id_component is the
component unique identifier, where the value FFFFh is reserved for
special features and the value 0000h to indicate that the cell is free
and does not belong to any component. Therefore, it is possible to
instantiate up to 65534 different components. The id_cell is the cell
unique identifier in a component, so there may be up to 65536 cells
in a component and a maximum close to 232 cells in the system.
The physical implementation of this architecture is depicted in
Fig. 1, which shows the representation of a chip that includes an
array of clusters, pin interconnection matrices and a Global Con-
figuration Unit (GCU). Fig. 1(b) shows a cluster, that is composed
by a 3
3 cell array and a switch matrix.
This two-layer implementation is composed by interconnected
cells in the first level and interconnected switch and pin matrices in
the second level, which are interconnected to the GCU by means of an
Internal Network. Several chips can be interconnected by means of an
External Network connected to the GCUs. These networks have been
designed to support the system with the necessary functionality to
carry out the self-adaptive capabilities.
Fig. 1. System architecture. Composed by a cluster array, pin interconnections matrices and GCU. Cluster: 3
3 cell array and switch matrix. (a) Architecture overview and
(b) 3D view of a cluster.
Fig. 2. Cell architecture. (a) Cell block diagram and (b) block diagram of FU.
In addition to the physical implementation of the architecture
described previously, two additional layers are defined as con-
ceptual organization for the implementation of general purpose
applications: the SANE and the SANE assembly. The SANE (Self-
Adaptive Networked Entity) is composed by a group of compo-
nents. This is the basic self-adaptive computing system. It has the
ability to monitor its local environment and its internal computa-
tion process. The SANE assembly is composed by a group of
interconnected SANEs.
2.1. Cell architecture
The cell is the basic element of the proposed architecture.
Therefore, the cell has to include the necessary hardware to carry
out the basic principles of self-adaptation; dynamic and distributed
self-routing [5–7], dynamic and distributed self-placement, self-
elimination, self-replication, scalability and distributed control.
The cell consists of the Functional Unit (FU), the Cell Configuration
Unit (CCU) and multiplexers that allow the interconnection between
FU ports of two cells. The cell is interconnected with its four direct
neighbors by means of local, remote and expansion ports. The cell
architecture and port distribution is depicted in Fig. 2(a). The local and
remote ports are 9-bit wide bus (8-bit for data and 1 bit for read
enable). The read enable (RE) is set to logic ‘1’ for a clock pulse when
a processor performs a write operation over the corresponding
output port.
2.2. Functional unit (FU)
The FU is in charge of executing the processes scheduled to the
cell. The FU can be described as a configurable multicomputer
with four cores (Fig. 2(b)). The FU has four 9-bit input ports and
four 9-bit output ports. Additionally the FU includes four 9-bit FT
 J. Soto et al. / Neurocomputing 121 (2013) 25–31
input ports exclusively for FTS, if it is enabled. The FU includes an
Outputs Multiplexing System that allows the cores to write data in
the output ports, as well as direct the data flow of cores to outputs
when the FTS is enabled and any of its cores is working as a
redundant processor. The FTS is explained in detail in Section 3.
Each core has program memory, data memory and additional
hardware necessary for its functionality. The instruction set is
composed of 44 instructions, which includes arithmetic, logic, shift,
branch, conditional branch and special instruction for the execution
of microthreads [8]. All instructions can be executed in a single clock
cycle. The program memory can store up to 64 instructions. The data
memory is 8-bit wide and it is composed of eight general-purpose
registers and 14 Configuration and Status Registers.
The configuration modes of the FU consists basically in grouping
cores, where the expansion of data and program memory describes
the specific configuration mode. The data memory can be combined in
width and length, achieving combinations for data processing of 8, 16,
24 and 32 bits. The program memory can only be joined in length,
making possible to have programs of 64, 128, 192 or 256 instructions.
There are 12 different configuration modes, ranging between one and
four processors working in parallel.
2.3. Cell configuration unit (CCU)
Using a distributed working principle, the CCUs of the cells
in the array are responsible for the execution of the required
algorithms for the implementation of the self-adaptive capabilities
of the system, specifically the self-placement and self-routing
algorithms [9]. These algorithms are executed by the CCU using
the Internal Network and the expansion ports.
The self-placement algorithm is responsible for finding out the most
suitable position in the cell array to insert the new cell of a component.
For the placement of the first cell of a component, a particular pro-
cedure is used, different from other cells. In this case a good candidate
position is one where a free cell has low routing congestion and the
largest number of free neighboring cells. After inserting the compo-
nent first cell, the next cell to be inserted is placed as close as possible
to the same component cells present in the array.
The self-routing algorithm is executed since the insertion of the
second cell of a component, each time that the self-placement process
ends. The algorithm allows interconnecting the ports of the functional
unit of two cells through the local and remote cell ports.
The self-elimination and self-replication of cells allows the replica-
tion and elimination of cells that are suspect of having a hardware
failure, these are self-adaptive capabilities that are closely tied with
the FTS (see Section 3).
3. Fault Tolerance System (FTS)
The FTS enables the system to continue operating properly in
the event of the failure of some of its processors. The FTS consists
of a specific hardware that allows the comparison of two identical
processors each time that an instruction is executed, that means
each clock cycle. This involves the comparison of 2, 4, 6 or 8 cores,
depending of the configuration mode of the FTS (FT_mode).
These processors that will be compared are called primary and
redundant. They must share the same inputs, but on the other
hand, the primary processor takes over writing the output ports,
because two outputs cannot be routed to the same location.
The redundant processor may or may not be included in the
same cell where the primary processor is located, this depends on
the processor on which the FTS is to be implemented (configura-
tion mode). If the redundant processor is located in the same cell
that includes the primary processor (FT_modes 0, 1 , 2, 3 or 4), the
27
FT_input ports are not used, and the FTS only performs compar-
ison between cores of the cell.
Otherwise, when the redundant processor is located in another
cell (FT_modes 5, 6, 7 or 8), the FTS of the primary cell must
perform a comparison between cores of different cells, in this case
the Output Multiplexing System of the cell that includes the
redundant processor must drive the output of the data flow of
the core(s) to the output of the cell (RE is set to logic 1), which in
turn should be connected to the FT_input of the FU of the cell that
includes the primary processor.
When a hardware failure is detected by the FTS, the damaged
cell(s) is self-eliminated and self-replicated to another location.
The cell data registers and its processing capacity are lost (prob-
ably corrupted). However, the routing resources and some adap-
tive capabilities of the cell (included in the CCU) are still working.
This means that cell continues participating in the self-placement
(as busy cell) and self-routing algorithms. This allows the inter-
connection of two distant cells in a component using the routing
resources of a cell with damage in its functional unit.
The next steps describe the procedure for self-elimination and self-
replication of a single damaged cell, the procedure is repeated for a
second damaged cell if the redundant processor is located there:
 The cores of damaged cell are blocked, no more instructions
will be executed. This cell requests to the GCU to start the
process.
 The GCU sends a command through the Internal Network
requesting the cell array to perform a derouting process for
all connections with the damaged cell.
 The damaged cell is self-eliminated, this cell is configured
as busy cell and its address will be fixed to FFFF0001 to avoid
future use.
 The GCU starts the replication process. The GCU sends the
appropriate information to start the execution of the processes
for self-placement and self-routing the cell again. The program
memories and the appropriate configuration registers of the
new cell are configured again.
 The GCU asks the system to start the process of self-routing
at component level to route the missing connections in the
system.
When elimination and replication processes end, the proces-
sors in the system are enabled again and continue working (start
working for replicated cells). It is user's responsibility to restart the
software application scheduled to the SANE, or to recover a known
starting point.
3.1. Fault tolerance configuration modes
The FTS could be implemented in any processors available in
the system. Table 1 shows the nine FT_modes available and the
comparison performed. This table indicates the cores that are
compared in each FT_mode, which could be combined with any of
the 12 configuration modes available for the system, obtaining 108
possible combinations. It is the responsibility of the developer
to configure an appropriate combination between configuration
mode of cells (always necessary) and FT_mode (if FTS is enabled).
When a specific application needs to implement a processor
with fault tolerance capabilities, the developer has to set the
configuration mode and the FT_mode by means of the FTCSR
register, which also includes the next fields: FT_enable that enable
the FTS. If it is not enabled, the other bits of FTS are not taken into
account. The FT_error_flag indicates when the FTS has found an
error while performing a comparison between two processors, this
bit stops the execution of the programs in the cores and alerts the
CCU to start the self-elimination and self-replication processes
28 J. Soto et al. / Neurocomputing 121 (2013) 25–31
of damaged cells. The FT_redundant_cell bit indicates if the cell is
a redundant cell, it must be set in the redundant cell for the
FT_modes 5, 6, 7 and 8 only.
3.2. Example of an application that implements a FTS
Let us suppose an 8-bit sequence of data that has to be
generated by a processor with a capacity for 250 instructions,
which has to include a FTS to protect the reliability of the
sequence. The sequence has to be generated at a low speed, much
lower than the clock available, so it is necessary to implement a
delay in the sequence. This could be implemented in the processor
of another cell with a capacity for 50 instructions.
The problem can be solved in many ways, Fig. 3(a) shows a specific
solution. This SANE includes three components (AAAA, BBBB and
CCCC). The cell identified as AAAA0001 includes the primary proces-
sor, which generates the sequence, and the cell BBBB0002 includes the
redundant processor that generates the same sequence. These cells are
configured in configuration mode 4 and in FT_mode 5, that allows the
FTS of the primary cell making the comparison of 2 cores (core 0 in
primary and redundant cells). The cell CCCC0003 contains a processor
that performs the delay. This will be in mode 0, and its FTS will be
disabled (only one processor is used, the other three could be used for
future implementations).
When the primary and redundant cells generate one data of the
sequence, the OUT0 port of the primary cell is written, producing an
RE flag. This is conducted to the cell CCCC0003, which waits this RE
pulse from cell AAAA0001 to start the generation of a delay (this RE is
received by means of the special instruction called BLMOV “Blocked
Move”, which reads the port, saves the data in a memory location
and follows with the next instruction when a RE pulse is produced).
The data read is not important for the cell that produces the delay
(CCCC0003). This cell executes the delay algorithm, and then writes
any data in its OUT0 port, which produces a RE pulse that has to be
conducted to the inputs of the primary and redundant cell. When
these cells receive the RE pulse they generate the next data of the
special sequence, and so on. While the delay is performed, the primary
Table 1
Fault tolerances modes (FT_modes).
FT_mode Core comparison
0 C0⇔C1
1 C0⇔C1 & C2⇔C3
2 C2⇔C3
3 C0⇔C2
4 C0⇔C2 & C1⇔C3
5 C0⇔C0n
6 C0⇔C0n & C1⇔C1n
7 C0⇔C0n & C1⇔C1n & C2⇔C2n
8 C0⇔C0n & C1⇔C1n & C2⇔C2n & C3⇔C3n
⇔ denotes a comparison between cores. & denotes a logic AND.
n
denotes a core in the redundant cell (a connection between FUs of primary
and redundant cell is assumed).
Fig. 3. FT application example. (a) Components configuration and (b) prototype.
and redundant processors could calculate the next data of the
sequence in a parallel way.
If the primary or redundant processor have a hardware failure,
the cells AAAA0001 and BBBB0002 are self-eliminated, the address
FFFF0001 will be fixed in both cells, and they will not be used in
subsequent self-placement operations. Its routing resources continue
to be available. Next, the cells AAAA0001 and BBBB0002 start
the self-replication process, it involves the self-placement and self-
routing of these cells in another location inside the cell array. Once
this process ends, the sequence starts the generation again.
At this point of the explanation, the reader could be thinking
“and what happens if…?”, turning the sample in a more elaborated
and complex situation. Therefore, it is important to take into
account that the system should provide enough spare cells, so that
this application could be extended.
3.3. Prototype implementation
For demonstration purposes, the original architecture previously
described has been modified for the construction of a prototype,
due principally to the physical limitations in the FPGAs used for the
implementation of the system. It is important to note that cells
in prototype include and execute all the self-adaptive capabilities
described in this paper. The prototype has been developed in two
chips, each one is a Virtex4 Xilinx FPGA (XC4VLX60), with an
utilization rate close to 80% of their capacity.
Each chip consists of a cluster that was reduced to a 2
2 cell array
(this includes the switch matrix), one pin interconnection matrix,
one control microprocessor ðμPÞ and the GCU. The control micro-
processor ðμPÞ is responsible for implementing the main program for
the configuration and execution of system functionality, even during
runtime. The μP through the GCU is responsible for controlling all the
self-adaptive processes in the chips. Each chip through its μP is
connected to a computer by means of a serial communication port,
which allows to read continuously messages that indicate the internal
processes executed in the chips (see Section 5 for details). The system
can have between 8 and 32 processors working in parallel, it depends
on the configuration mode implemented.
Fig. 3(b) shows a 3D view of the prototype. Additionally, the
figure shows the location of cells after executing the self-
placement and self-routing algorithms for the application example
(Section 3.2). The cells were placed in the order AAAA0001,
BBBB0002 and CCCC0003. The figure shows only the initial SANE
configuration, and does not show details after failures, which
implies the elimination and replication of cell(s).
4. SANE developer system
One of the main inconveniences in the design phase of the
architecture was the creation of applications that allow to test
the system. This process consists in the creation of SANEs, that
includes a specific number of interconnected components, and
 J. Soto et al. / Neurocomputing 121 (2013) 25–31
interconnected cells inside each component. This functionality
involved, for each cell in the application, the creation of inputs and
outputs connection tables, the configuration of special registers,
and the generation of hexadecimal instructions code for each
processor (between one and four) from programs written in
the native assembler language created for the functional unit.
Any modification in the application implies a lot of time rewriting
the data for its configuration. Similar to any commercial general
purpose device a software tool is fundamental for improving the
capacity of a designer when developing applications.
The SANE Project Developer (SPD) is an Integrated Develop-
ment Environment (IDE) that allows generating the memory
initialization data for the control microprocessor inside the pro-
totype. The SDP allows the creation of files that describe the
configuration of a SANE assembly (SASM files). This file includes
instructions that support the next functionalities in the system:
 Create, interconnect and delete components.
 Write the Program Memories and Configuration Registers of
the cores in the Functional Unit of the cell.
 Commands for global manipulation of processors, like enable,
disable and restart processors. Including or not a special “wait”
instruction, that enables the dynamic and static fault tolerance
systems.
 Special instructions related with the dynamic fault tolerance
system.
 Special instructions related with the static fault tolerance
system.
Fig. 4. Screen capture of the SANE Project Developer (SPD).
29
The SPD allows the insertion and modification of all related
information of the SANE assembly, this involves for each cell: the
identification number (address), the configuration registers, the
connection tables for inputs and outputs, description and alias
of cell, description of component, and assignment of assembler
(ASM) or C files to processor(s) in cell. For writing the Program
Memories of the processors, assembler (ASM) or C files will be
created, this allows to execute the functionality of a processor in
the cell.
The SPD supports building of the final hexadecimal file (SHEX)
with the configuration of the SANE assembly that will be imple-
mented in the FPGA. This process includes the compilation of the
files involved in the process according to the SASM file. The SPD
generates a list of errors, warnings and information for all files
involved in the building process and guides the user to make
the appropriate corrections if required. The SPD also supports
the compilation of individual ASM files. Compilation for C files is
currently under development.
Fig. 4 shows a screen capture of the SPD, which shows the
SASM file for the problem proposed in Section 3.2. It also shows
the structure of the solution in the left tree and the output of the
building process in the bottom section.
5. Experimental results
To test the architecture we have developed some applications,
one of them is proposed in Section 3.2. In normal conditions the
sequence is executed continuously without interruption. For test
30 J. Soto et al. / Neurocomputing 121 (2013) 25–31
purposes, one data in the sequence was modified by software (in
ASM file). Therefore, when the sequence arrives to this execution
point, the FTS detects (or interprets the FTS_error as) a hardware
failure and the process for self-elimination and self-replication of
the primary and redundant cells starts. The new cells start the
execution again and by the modification in the software men-
tioned previously, the failure occurs repeatedly performing the
self-organization processes until the system runs out of resources,
in this moment the system returns the correspondent error.
Fig. 5 shows a screen capture of the messages sent by the chips
in the execution time of the application. For space reasons the
entire record of the messages is not shown. The following is a brief
description of the sequential processes running internally on the
chips:
1. Initialization and synchronization of chips (chip0 and
chip1).
2. Jump instruction ft_configuration. This instruction is only
used when a fault occurs in the system.
3. Create the component 0xAAAA. The self-placement and
self-routing processes for cell 0xAAAA0001 are executed.
A contest process determines that the cell is placed in the
chip0 by a priority order previously configured by hardware.
4. Create the component 0xBBBB. The self-placement and self-
routing processes for cell 0xBBBB0002 are executed in chip0.
5. Create the component 0xCCCC. The self-placement and self-
routing processes for cell 0xCCCC0002 are executed in chip0.
6. All processors are restarted and disabled.
7. The program memories and configuration registers of cells
0xAAAA0001, 0xBBBB0002 and 0xCCCC0003 are written.
8. The components self-routing process is executed.
Fig. 5. Screen capture of the messages read from the chips when an application is executed.
9. All processors in the cells configured are enabled. The wait
mode is enabled (The FTS waits for a fault.). The execution
of the tasks scheduled to the SANE has started.
Note 1: Steps 1–9 correspond with the program executed
by the configuration file (SASM) showed in Fig. 4.
Note 2: The next steps are executed when a hardware
failure occurs. For test purposes the failure was inten-
tionally induced by software.
10. The program jumps to the instruction ft_configuration related
with the primary cell of the fault. The FTS will start the
elimination and replication of cell(s) involved in the failure.
11. All processors are restarted and disabled.
12. The cell 0xAAAA0001 is self-eliminated. Every connection
with this cell is unrouted. The cell is self-discarded for future
self-placement, its address is configured to 0xFFFF0001 (cell
with a hardware failure). The routing resources of the cell
remain active and can participate in future self-routing
processes.
13. The cell 0xBBBB0002 is self-eliminated and self-discarded.
14. The reinsertion of cell 0xAAAA0001 is executed. The self-
placement and self-routing processes are executed in chip0
(at this moment the chip0 is full).
15. The reinsertion of cell 0xBBBB0002 is executed. The self-
placement and self-routing processes are executed in chip1.
16. The program memories and configuration registers of cells
0xAAAA0001 and 0xBBBB0002 are written.
17. The self-elimination and self-replication processes end. The
program goes back to the instruction enable_processors_wait.
All processors in the cells configured are enabled. The wait
mode is enabled (The FTS waits for a fault.). The execution of
the tasks scheduled to the SANE has started again.
 J. Soto et al. / Neurocomputing 121 (2013) 25–31
Table 2
Results of the synthesis process for the proposed prototype.
Part (Description)
FPGA: chip resources, for comparison
Cell: the routing resources of two sides were eliminated
Cluster: 2
2 cell array+switch matrix
Chip: cluster þ GCU þ μP of control+pin interconnection matrix
Note 1: Steps 10–17 are executed each time when the
induced failure occurs. The process ends when the
system generates an error indicating that the system is
full and it is not possible to place more cells in system.
The results of the usage rate for elements of the architecture
are detailed in Table 2. The Xilinx Synthesis Technology (XST) was
used for the system implementation in the device selected. This
table shows the usage rate for a cell, a cluster and a complete chip,
this allows to have an idea of the system granularity. The program
memory of the FU and the connection table have been implemen-
ted by means of the RAM blocks available in the FPGA used.
6. Conclusion and future work
A Fault Tolerance System (FTS) for a novel self-adaptive hard-
ware architecture has been reported. The FTS performs a contin-
uous comparison between primary and redundant processors, that
could be implemented in one or two cells, depending on the
configured FT_mode. The cell (or cells) that includes the primary
and redundant processors involved in the FTS will be self-
eliminated and self-replicated to other free cell(s) by the system
when the FTS detects a failure. This cell(s) will be self-discarded
for future implementations.
An example application that illustrates the functionality of the
system has been described. Also, the principal characteristics of a
software tool that allows the creation of general purpose applica-
tions has been described.
As future work for the SANE developer system, we consider the
implementation of a C-compiler (under development) to expand
the possibilities and provide an alternative solution to program-
ming in assembler for the system processors. Also we consider
the direct communication with the FPGAs in order to program and
control the execution of a SANE assembly.
References
[1] AETHER Project Home, URL: 〈http://www.aether-ist.org〉.
[2] J. Soto, J. Moreno, J. Madrenas, J. Cabestany, Implementation of a dynamic fault-
tolerance scaling technique on a self-adaptive hardware architecture, in:
Proceedings of the International Conference on Reconfigurable Computing
and FPGAs, 2009, pp. 445–450.
[3] T. Streichert, D. Koch, C. Haubelt, J. Teich, Modeling and Design of Fault-Tolerant
and Self-Adaptive Reconfigurable Networked Embedded Systems, Hindawi
Publishing Corp, New York, 2006.
[4] Z. Chen, M. Yang, G. Francia, J. Dongarra, Self adaptive application level fault
tolerance for parallel and distributed computing, in: IEEE International Parallel
and Distributed Processing Symposium, 2007. IPDPS 2007, pp. 1–8.
[5] N. Macias, L. Durbeck, Self-Assembling circuits with autonomous fault handling,
in: Proceedings of the 2002 NASA/DoD Conference on Evolvable Hardware
(EH'02), IEEE Computer Society Press, 2002, pp. 46–55.
31
Slices Slice flip flops Four input LUTs RAMB16
26,624 53,248 53,248 160
100% 100% 100% 100%
3540 992 6760 6
13% 1% 12% 3%
17,716 7881 33,801 24
66% 14% 63% 15%
19,557 9638 36,424 40
73% 18% 68% 25%
[6] J. Moreno, Y. Thoma, E. Sanchez, POEtic: a prototyping platform for bio-inspired
hardware, in: Proceedings of the 6th International Conference on Evolvable
Systems (ICES), pp. 180–182.
[7] J. Moreno, E. Sanchez, J. Cabestany, An in-system routing strategy for evolvable
hardware programmable platforms, in: Proceedings of the Third NASA/DoD Work-
shop on Evolvable Hardware, IEEE Computer Society Press, 2001. pp. 157–166.
[8] T. Vu, C. Jesshope, Formalizing SANE virtual processor in thread algebra, in:
ICFEM'07: Proceedings of the Formal Engineering Methods, 9th International
Conference on Formal methods and Software Engineering, Springer-Verlag,
Boca Raton, FL, USA, 2007, pp. 345–365.
[9] J. Soto, J.M. Moreno, J. Madrenas, J. Cabestany Communication infrastructure for
a self-Adaptive hardware architecture, in: Proceedings of the Reconfigurable
Communication-centric Systems-on-Chip workshop (ReCoSoC 08), Barcelona,
Spain, July 9–11, 2008, pp. 175–180, ISBN: 978-84-691-3603-4.
Javier Soto Vargas is an Instructor Professor at the
Electronic Engineering Department of the “Escuela
Colombiana de Ingeniería Julio Garavito” (ECI), where
he was the coordinator of the digital systems area
as well as the robotic group ECIBOT. He received his
degree in Electronic Engineering in 2000 from ECI and
the M.Sc. in Teleinformatic from the “Universidad Dis-
trital Francisco José de Caldas” in 2007. He is currently
working toward the PhD degree in Electronic Engineer-
ing from the Technical University of Catalunya. His
current research interests are in self-adaptive architec-
tures based on bio-inspired systems.
Juan Manuel Moreno received the Master and PhD
degrees in Telecommunication Engineering from the
Technical University of Catalunya (UPC) in 1991 and
1994, respectively. He is an Associate Professor at the
Electronics Engineering Department of the Technical
University of Catalunya. He has led and participated
in several research projects related to reconfigurable
architectures, SoCs, artificial neural networks and bio-
inspired systems. His research interests are in dynami-
cally reconfigurable architectures, physical implemen-
tation of bio-inspired systems and artificial neural
networks for signal processing.
Joan Cabestany is a professor at the Department of
Electronic Engineering (UPC). He received his degree in
Telecommunication Engineering in 1976, and the PhD in
1982, both from the Technical University of Catalunya.
He is the responsible of the AHA (Advanced Hardware
Architectures) research group, with expertise on reconfi-
gurable hardware, electronic system design, advanced
hardware architectures, microelectronics and VLSI design.
He is member of the CETpD staff structure since 2005.
He has been the UPC responsible several EU funded
projects, and their main interest topics are artificial
intelligence and electronic technology applied to different
topics (aging and dependent people issues, in particular).