Full Text 01

Cognitive and Self-Adaptive SoCs with
Self-Healing Run-Time-Reconfigurable RecoBlocks
BYRON R. NAVAS V.
Doctoral Thesis in Electronic and Computer Systems

Stockholm, Sweden 2015
School of Information and
TRITA-ICT/ECS AVH 15:22 Communication Technology
ISSN 1653-6363 KTH Royal Institute of Technology
ISRN KTH/ICT/ECS/AVH-15/22-SE SE-164 40 Kista
ISBN 978-91-7595-768-5 SWEDEN
Akademisk avhandling som med tillstånd av Kungl Tekniska högskolan framlägges

till offentlig granskning för avläggande av teknologie doktorsexamen torsdagen den
17 dec 2015 klockan 13.00 i Sal C, Electrum, Kista.
© Byron R. Navas V., Dec 2015
Tryck: Universitetsservice US AB
iii
Abstract
In contrast to classical Field-Programmable Gate Arrays (FPGAs), par-

tial and run-time reconfigurable (RTR) FPGAs can selectively reconfigure
partitions of its hardware almost immediately while it is still powered and op-
erative. In this way, RTR FPGAs combine the flexibility of software with the
high efficiency of hardware. However, their potential cannot be fully exploited
due to the increased complexity of the design process, and the intricacy to
generate partial reconfigurations. FPGAs are often seen as a single auxiliary
area to accelerate algorithms for specific problems. However, when several
RTR partitions are implemented and combined with a processor system, new
opportunities and challenges appear due to the creation of a heterogeneous
RTR embedded system-on-chip (SoC).
The aim of this thesis is to investigate how the flexibility, reusability, and
productivity in the design process of partial and RTR embedded SoCs can
be improved to enable research and development of novel applications in ar-
eas such as hardware acceleration, dynamic fault-tolerance, self-healing, self-
awareness, and self-adaptation. To address this question, this thesis proposes
a solution based on modular reconfigurable IP-cores and design-and-reuse
principles to reduce the design complexity and maximize the productivity of
such FPGA-based SoCs. The research presented in this thesis found inspi-
ration in several related topics and sciences such as reconfigurable comput-
ing, dependability and fault-tolerance, complex adaptive systems, bio-inspired
hardware, organic and autonomic computing, psychology, and machine learn-
ing.
The outcome of this thesis demonstrates that the proposed solution ad-
dressed the research question and enabled investigation in initially unexpected
fields. The particular contributions of this thesis are: (1) the RecoBlock SoC
concept and platform with its flexible and reusable array of RTR IP-cores.
(2) a simplified method to transform complex algorithms modeled in Matlab
into relocatable partial reconfigurations adapted to an improved RecoBlock
IP-core architecture. (3) the self-healing RTR fault-tolerant (FT) schemes,
especially the Upset-Fault-Observer (UFO) that reuse available RTR IP-cores
to self-assemble hardware redundancy during runtime, (4) the concept of
Cognitive Reconfigurable Hardware (CRH) that defines a development path
to achieve self-adaptation and cognitive development, (5) an adaptive self-
aware and fault-tolerant RTR SoC that learns to adapt the RTR FT schemes
to performance goals under uncertainty using rule-based decision making.
(6) a method based on online and model-free reinforcement learning that
uses a Q-algorithm to self-optimize the activation of dynamic FT schemes in
performance-aware RecoBlock SoCs.
The vision of this thesis proposes a new class of self-adaptive and cognitive
hardware systems consisting of arrays of modular RTR IP-cores. Such a sys-
tem becomes self-aware of its internal performance and learns to self-optimize
the decisions that trigger the adequate self-organization of these RTR cores,
i.e., to create dynamic hardware redundancy and self-healing, particularly
while working in uncertain environments.
iv
Sammanfattning
Partiell och run-time rekonfigurering (RTR) betyder att en del av en in-

tegrerad krets kan konfigureras om, medan den resterande delens operation
kan fortlöpa. Moderna Field Programmable Gate Array (FPGA) kretsar är
ofta partiell och run-time rekonfigurerbara och kombinerar därmed mjukva-
rans flexibilitet med hårdvarans effektivitet. Tyvärr hindrar dock den ökade
designkomplexiteten att utnyttja dess fulla potential. Idag ses FPGAer mest
som hårdvaruacceleratorer, men helt nya möjligheter uppstår genom att kom-
binera ett multiprocessorsystem med flera rekonfigurerbara partitioner som
oberoende av varandra kan omkonfigureras under systemoperation.
Målet med avhandlingen är att undersöka hur utvecklingsprocessen för
partiella och run-time rekonfigurerbara FPGAer kan förbättras för att möj-
liggöra forskning och utveckling av nya tillämpningar i områden som hård-
varuacceleration, själv-läkande och själv-adaptiva system. I avhandlingen fö-
reslås att en lösning baserad på modulära rekonfigurerbara hårdvarukärnor
kombinerad med principer för återanvändbarhet kan förenkla komplexiteten
av utvecklingsprocessen och leda till en högre produktivitet vid utvecklingen
av inbyggda run-time rekonfigurerbara system. Forskningen i avhandlingen
inspirerades av flera relaterade områden, så som rekonfigurerbarhet, tillför-
litlighet och feltolerans, komplexa adaptiva system, bio-inspirerad hårdvara,
organiska och autonoma system, psykologi och maskininlärning.
Avhandlingens resultat visar att den föreslagna lösningen har potential
inom olika tillämpningsområden. Avhandlingen har följande bidrag: (1) Re-
coBlock system-på-kisel plattformen bestående av flera rekonfigurerbara hård-
varukärnor, (2) en förenklad metod för att implementera Matlab modeller i
rekonfigurerbara partitioner, (3) metoder för själv-läkande RTR feltoleran-
ta system, t. ex. Upset-Fault-Observer, som själv-skapar hårdvaruredundans
under operation, (4) utvecklandet av konceptet för kognitiv rekonfigurerbar
hårdvara, (5) användningen av konceptet och plattformen för att implemen-
tera kretsar som kan användas i en okänd omgivning på grund av förmågan
att fatta regel-baserade beslut, och (6) en förstärkande inlärnings-metod som
använder en Q-algoritm för dynamisk feltolerans i prestanda-medvetna Re-
coBlock SoCs.
Avhandlingens vision är en ny klass av själv-adaptiva och kognitiva hård-
varusystem bestående av modulära run-time rekonfigurerbara hårdvarukär-
nor. Dessa system blir själv-medvetna om sin interna prestanda och kan
genom inlärning optimera sina beslut för själv-organisation av de rekonfi-
gurerbara kärnorna. Därmed skapas dynamisk hårdvaruredundans och själv-
läkande system som har bättre förutsättningar att kunna operera i en okänd
omgivning.
To my parents
Angelita y Raulito
Acknowledgements
A journey to explore unique fields, to seek out new challenges and new solutions.
Ph.D. studies are a rewarding experience full of constant self-healing and self-
adaptation. Therefore, I would like to thank the persons that guided me and
shared this travel.
First and foremost, I would like to express the depth of my gratitude to my
two advisers Doc. Ingo Sander and Doc. Johnny Öberg. Both have significantly
contributed to my growth in different ways and styles. They supported me with
their valuable advise and knowledge in academic research and life. Moreover, I
learned to appreciate the best of both German and Swedish working approaches.
Thanks for their precious time and for letting me explore my unconventional ideas.
I would also like to thank Prof. Elena Dubrova for her insights about writing
and life. My thanks to Doc. Zhonghai Lu for his feedback, particularly on this
thesis draft. I am also thankful to Prof. Ana Rusu for her concern for the quality
of studies, and also to Prof. Ahmed Hemani and Prof. Axel Jantsch. My thanks are
also to the personnel in the administration and technical support for their readiness
to help, in particular to Susy Mathew, Alina Munteanu, May-Britt Eklund-Larsson,
Amanda Stråle, Yunus Eriksson and Hans Larsson.
I am also thankful to all the colleagues that I met at KTH, especially to Mo-
hammad Badawi, Fernando Herrera, Sandro Penolazzi, Christian Menne, Shaoteng
Liu, Yuan Yao, Jian Wang, Saul Rodriguez, Nasim Farahini. My thanks to Hosein
Attarzadeh for his knowledge and support.
I am very grateful to Kathrin Rosvall, Nima Dokoohaki, and Painda Nowshad
who made me remember that human beings are made of great hearts, without
distinctions of nationalities. Thanks for your words of appreciation. I am also
grateful to Dimitrios Brachos for his lasting friendship.
I am also thankful to ESPE for funding my doctoral studies, in particular to
Grab. Carlos Rodríguez, Grab. Roque Moreira, and Professors. Rubén León, Hugo
Ortiz, Gonzalo Olmedo, and Evelio Granizo.
I am profoundly grateful to my parents who gave the gift of life, education, and
love. To my siblings Raul, Elizabeth, and particularly to Sandra for her support
at home. To my siblings in law Wilfrido and Maria Isabel. And to the young
generation because this work is for them as well. Similarly, my great gratitude to
my parents in law and relatives in law for their sincere good wishes.
Last but not least, my truly and deepest gratitude is to Helen, my wife, friend
and angel who unconditionally has shared the darkest and brightest hours of this
dream. Her presence gave me strength and motivation towards the goal.
Byron R. Navas V.
December 2015
Contents
Contents ix
List of Figures xi
List of Acronyms xiii
I Introduction 1
1 Introduction 3
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 Problem Description and Challenges . . . . . . . . . . . . . . 8
1.1.2 Research Question . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Research Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3 Research Contributions . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.1 Research Map . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.2 List of Publications . . . . . . . . . . . . . . . . . . . . . . . 15
1.4 Thesis Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2 Background 21
2.1 Reconfigurable Computing . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 Programmable Logic, FPGA . . . . . . . . . . . . . . . . . . . . . . 22
2.3 Dependability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4 Adaptive Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5 Autonomic and Organic Computing . . . . . . . . . . . . . . . . . . 27
2.5.1 Autonomic Computing . . . . . . . . . . . . . . . . . . . . . . 27
2.5.2 Organic Computing . . . . . . . . . . . . . . . . . . . . . . . 28
3 The RecoBlock Concept 31

3.1 RecoBlock: A Flexible Array of Reusable Run-time Reconfigurable
IP-blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.2 Idea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
ix
x CONTENTS
3.1.3 The Reconfigurable-Block IP-core (RecoBlock) Concept . . . 33

3.1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2 RecoBlock Design Flow for Algorithm Modeling and Acceleration in
a Standard RTR IP-core . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.2 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2.3 Idea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4 Self-healing Run-time Reconfigurable Fault-tolerance 53

4.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3 Solution Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.4 Implementing RTR FT Shemes and Self-healing Adaptivity . . . . . 58
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5 Adaptation, Self-awareness and Learning 63

5.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.2 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.3 Solution Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.4 Implementation Summary . . . . . . . . . . . . . . . . . . . . . . . . 68
5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6 Conclusion and Outlook 75

6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2 Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Bibliography 79
II Included Papers 85
List of Figures
1.1 The Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2 Research Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1 Abstract view of a Field-Programmable Gate Array (FPGA) internal

structure and design flow . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2 Partial and run-time reconfigurable (RTR) Reconfiguration. . . . . . . . 24
2.3 Hardware Redundancy Schemes . . . . . . . . . . . . . . . . . . . . . . . 25
2.4 Autonomic Computing Manager . . . . . . . . . . . . . . . . . . . . . . 28
2.5 Organic Computing Architecture . . . . . . . . . . . . . . . . . . . . . . 29
3.1 The system-level design and reconfigurable computing gap. . . . . . . . 33

3.2 The RecoBlock Concept. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3 The basic RecoBlock platform . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4 The RecoBlock RTR IP-core. . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5 Abstraction layer stack (software, hardware, configware) . . . . . . . . 38
3.6 Basic RecoBlock design flow. . . . . . . . . . . . . . . . . . . . . . . . . 39
3.7 Case study: A function adaptivity model implemented on RecoBlock. . 40
3.8 The future of Heterogeneous Computing . . . . . . . . . . . . . . . . . . 42
3.9 The importance of a universal IP-core . . . . . . . . . . . . . . . . . . . 43
3.10 Challenges regarding algorithm development, a one-fit-all RecoBlock IP-
core architecture, and performance analysis . . . . . . . . . . . . . . . . 44
3.11 Unconnected flows in RTR SoC design. . . . . . . . . . . . . . . . . . . 45
3.12 Simplified flow for algorithm and reconfiguration development in RTR
RecoBlock IP-core. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.13 The RecoBlock IP-core as an universal function container . . . . . . . . 48
3.14 Abstract view of the RTR RecoBlock SoC as reconfigurable computing
architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.1 Issues in fault-tolerant approaches that combine hardware redundancy

and run-time reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2 Reconfigurable Triple-Modular Redundancy (TMR) schemes based on
RTR IP-cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
xi
xii List of Figures
4.3 Overview of run-time reconfigurable (RTR) fault-tolerant (FT) schemes

based on RecoBlock IP-cores. . . . . . . . . . . . . . . . . . . . . . . . . 57
4.4 The Upset-Fault-Observer (UFO) explained. . . . . . . . . . . . . . . . . 59
5.1 A problem of self-optimization in future run-time reconfigurable (RTR)

embedded systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.2 Cognitive Reconfigurable Hardware (CRH) and its relationship with hu-
man development in psychology . . . . . . . . . . . . . . . . . . . . . . . 67
5.3 The self-aware RecoBlock platform . . . . . . . . . . . . . . . . . . . . . 69
5.4 Self-monitored performance metrics observed in the RecoBlock SoC . . 70
5.5 Q-algorithm applied to learn an optimal policy to select dynamic FT
schemes according to memory transactions performance (Matlab simu-
lation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
List of Acronyms
AC: Autonomic Computing

AE: Autonomic Element
API: application programming interface
APM: (Xilinx) AXI Logicore IP Performance Monitor
ASIC: Application Specific Integrated Circuits
ASIP: Application Specific Instruction Set Processor
AXI: Advanced eXtensible Interface
BSP: (Xilinx) Board Support Package
CAS: Complex Adaptive Systems
CF: Compact Flash
CM: Configuration Memory
COTS: commercial off the shelf
CPU: Central Processing Unit
CRH: Cognitive Reconfigurable Hardware
CS: Complex Systems
CW: configware
DDR3: double data rate type three SDRAM
DMA: Direct Memory Access
DPU: Data Processing Unit
dynFT: dynamic fault-tolerance
EPROM: Erasable Programmable Reand Only Memory
eRC: embedded Reconfigurable Computing
FIFO: first input first output
FPGA: Field-Programmable Gate Array
FPLA: Field Programmable Logic Array
FT: fault-tolerant
FT: fault-tolerance
HIPEAC: High Performance and Embedded Architecture and Compilation
HLS: High-level Synthesis
HPC: high performance computing
HPRC: high performance reconfigurable computing
ICAP: Internal Configuration Access Port
IP: intellectual-property
ITRS: International Technology Roadmap for Semiconductors
LUT: Look-Up Table
MDP: Markov decision process
xiii
xiv LIST OF ACRONYMS
MPSoC: multi-processor system-on- chip

OC: Organic Computing
OS: operating system
OSMF: Operating-System Management-Function
RAM: random access memory
RecoBlock: Reconfigurable-Block IP-core
RC: Reconfigurable Computing
RL: reinforcement learning
RM: Reconfiguration Module
RP: Reconfigurable Partition
RTL: register transfer level
RTR: run-time reconfigurable
RTR: run-time reconfiguration
SDK: (Xilinx) Software Development Kit
SDRAM: Synchronous Dynamic Random Access Memory
SEU: single-event upset
SoC: system-on-chip
SPI: Serial Peripheral Interface
SRAM: static random-access-memory
SW: software
TMR: Triple-Modular Redundancy
UFO: Upset-Fault-Observer
USB: Universal Serial Bus
VHDL: VHSIC (Very High Speed Integrated Circuit) Hardware Description Lan-
guage
XPS: (Xilinx) Xilinx Platform Studio
Part I
Introduction
1
Chapter 1
Introduction
Although octopuses and other invertebrate animals can change the color
and pattern of their skin for camouflage or signaling, no one had ever
described a vertebrate species that changes its skin texture until 2015.
In [16], authors describe a new species of frog named Pristimantis mu-
tabilis. The “individuals of the new species from the Andes rain forest
are remarkable for their ability to change skin texture within few min-
utes (330 s), between two discrete states. This mutable rain frog is the
first documented vertebrate to show such dramatic and rapid phenotypic
plasticity” [16].
Hopefully, this discovery among biological organisms may help us to
visualize how unique and transcendent the possibility of having a non-
living organism exhibiting similar traits is. A solid-state integrated cir-
cuit whose hardware functions can be changed almost immediately while
it is still powered and operative. This integrated circuit is known as
Field-Programmable Gate Array (FPGA). Moreover, this type of hard-
ware plasticity, known as "partial and run-time reconfiguration (RTR)",
is arguably the current most promising characteristic of FPGAs that
has ignited considerable interest in several fields, generally as a func-
tion switching mechanism that accelerates computations in hardware.
However, RTR is also becoming useful in new realms since it enables
self-reconfiguration, a fundamental characteristic that allows hardware
adaptation. In turn, this can allow other bioinspired properties such as
self-healing, self-repairing, self-optimization, and self-adaptation. How-
ever, compared to animal species where morphing is used for camouflage
or mating purposes, and there is a brain or intelligence controlling this
activation, in FPGAs the application of these bio-inspired properties
enabled by RTR are ready to be explored and the cognitive mechanisms
3
4 CHAPTER 1. INTRODUCTION
to trigger them are yet to be developed. Therefore, we have a species

of hardware circuits waiting for us to dream about the purpose of its
morphing mechanism, which makes our research interesting and also
challenging since it increases the already complex design of embedded
SoCs. Hence, in this work we envision new types of self-adaptive and
cognitive hardware systems consisting of arrays of modular RTR slots,
which become self-aware of its internal performance and learn to self-
optimize the decisions that trigger the adequate self-organization of these
RTR slots to self-heal or self-repair even while working in uncertain en-
vironments.
1.1 Motivation
This thesis presents the research that started by the need to find a simplified and
reusable approach to developing reconfigurable embedded SoCs and explore the
applications of RTR. However, the final result went beyond that goal.
FPGAs provided with partial and RTR combine the flexibility of software with
the high efficiency of hardware. But, their potential can not be fully exploited
due to the increased complexity of the design process, and the intricacy to gen-
erate partial reconfigurations. During this thesis investigation several challenges,
inspiration sources, and answers were consolidated at every stage. This section
motivates the reader by briefly introducing topics and sources of inspiration, such
as reconfigurable computing, field-programmable logic, dependability, adaptation,
bio-inspired hardware, organic computing, and machine learning. Then, problem
statements and objectives are summarized. Finally, the contributions based on
publications are reviewed.
Reconfigurable Computing (RC) is the second random access memory (RAM)-
based machine paradigm [19] that offer a drastic reduction in energy consumption
and speedup factors by up to several orders of magnitude compared to the von
Neumann paradigm, which, according to Hartenstein [19], is beginning to lose its
dominance. This new paradigm brings a disruptive new horizon for affordable high-
performance computing and also changes to the practice of scientific and embedded
system applications. Heterogeneous systems, including both paradigms, will need
innovation in parallel programming of manycore architectures and structural pro-
gramming, i.e.,configware, of Reconfigurable Computing. For that, designers need
to think out of the box [19].
Current research in Reconfigurable Computing has shown considerable speedup
and low power consumption, in addition to its capability to increase dependability.
However, the superior design complexity over traditional technologies has impeded
its dominance in strategic areas like personal, embedded and high-performance
computing. Therefore, to support the new revolution of reconfigurable computers
new methods, architectures, and tools are needed, but most importantly flexible,
economical, simplified, and reusable approaches so that the community can start
using and taking advantage of its benefits.
1.1. MOTIVATION 5
Technologically speaking, FPGAs are arguably less efficient than microproces-

sors [19] due to lower clock speeds and huge area overhead of reconfigurable wiring.
Nevertheless, the performance of a FPGA is better by several orders of magnitude.
How data are moved is the reason for this paradigm. A Central Processing Unit
(CPU) usually moves data between memories requiring instruction streams. There-
fore, the movement of data is evoked by execution of instructions due to the von-
Neumann paradigm. Besides, the execution of operations inside a CPU requires
reading and decoding of the instruction. Contrarily, in Reconfigurable Comput-
ing an algorithm is run by data streams only. Instead of a hardwired program
counter, reconfigurable data counters are used, which do not require instruction se-
quences for address computation. Then execution in Data Processing Unit (DPU)
is transport-triggered [19][9].
In a survey of heterogeneous computing, Brodtkorb et al. [8] conclude that sym-
metric multiprocessing has no future in the long term, as it is hard to envision
the efficient use of hundreds of traditional CPU cores”. Consequently, hundreds
of accelerator cores combined with a handful of traditional CPU cores seem to be
a more sustainable scenario [8]. Hence, finding solutions for developing systems
with several accelerator cores combined with a couple of soft or hard processors in
a single SoC becomes essential. In such a scenario, RTR will provide additional
advantages.
In contrast to early years of reconfigurable computing, where typically a full
reconfiguration was loaded at a time into a FPGA, the challenge is nowadays dif-
ferent. The introduction of partial and run-time reconfiguration technology allows
the reconfiguration of specific sections without re-starting the embedded processor
[Paper V]. The advances in the scale of integration lets a multi-processor system-
on- chip (MPSoC) and programmable logic coexist in a single FPGA. Thus, this
heterogeneous system must be able to reprogram logic partitions selectively while
the software in the processor is still running. This characteristic is what makes
partial and run-time reconfiguration (RTR) extremely attractive and challenging
[Paper IV].
Reconfigurable computing witnessed the first steps towards this type of het-
erogeneous RTR MPSoC, which is now already a mainstream trend leading by
industry solutions such as the Xilinx Zynq All Programmable SoC platforms [2]. In
these SoC environments, the importance of flexibility through intellectual-property
(IP)-core design-and-reuse [33] is more evident than before. Therefore, modular
and flexible solutions based on IP-cores that are also run-time reconfigurable (RTR
IP-cores) will likely become predominant in the following years [Paper IV].
Dependability is the capacity of a system to convey its intended level of service
in the presence of faults [11], which is measured in terms of probabilistic relia-
bility, availability or safety. Fault-tolerance is a group of design techniques that
increases the dependability of systems. Among those techniques, hardware redun-
dancy schemes are used to mask the presence of faults or to detect them. Both
partial or full reconfiguration are ordinarily used to recover FPGA-based systems
from a faulty state.
The significance of building dependable computer systems has increased pro-

foundly. Today, the industry can integrate silicon devices at nano-scales and provide
sufficient logic density to synthesize complex systems such as multi-core heteroge-
neous SoCs. However, it additionally increases the likelihood of fabrication defects,
lifetime faults, sensitivity to single-event upsets (SEUs), and other issues. Cos-
mic rays, atmospheric neutrons or electromagnetic radiation can generate SEUs in
the configuration memory of static random-access-memory (SRAM)-based FPGAs,
where their logic and interconnections are defined. In consequence, to fully exploit
these novel technologies, paradigm shifts are necessary. For instance, post fabri-
cation customization, embedded lifetime test and configuration, continuous on-line
monitoring, or in system repair [10] [Paper IV].
On the other hand, the dependability of heterogeneous many-core systems has
become an imperative issue due to the high failure rates originated by disruptive
scales of integration, increased design complexity, and radiation sensitivity. FP-
GAs are particularly sensitive to cosmic and another sort of radiations since they
produce bit-fluctuations in configuration and internal memories, which are known
as SEU. Design diversity, e.g., Triple-Modular Redundancy and reconfiguration are
traditional FT techniques used to increase dependability. Notwithstanding, hard-
ware redundancy is costly, and most methodologies have poor scalability, flexibility,
and programmability [39]. In this context, as it was early recognized by the project
named Reliability Obtained by Adaptive Reconfiguration (ROAR) [50], reconfig-
urable systems (and even more partial and RTR systems), can empower innovative
techniques to enhance dependability. However, innovative solutions are required to
reduce the redundancy cost while keeping appropriated levels of dependability.
Adaptation is a remarkable property that increases the likelihood of success
of systems. Living organisms are complex systems exhibiting a range of desirable
characteristics, such as evolution, adaptation, and fault tolerance, which are difficult
to realize in engineering systems [56]. However, the occurrence of partial and RTR
FPGAs has become an enabler for the growing interest in adaptive systems, since
now adaptation can not only be implemented in software but even more efficiently
in hardware [48] [7]. The concepts of adaptation are widely used but are relative
to the application field. In classical control theory, adaptation may be seen as
coping with disturbances and keeping system parameters around a set-point, with
a strong emphasis on feedback. Successful adaptation means to return to the same
pre-perturbation state since radical changes are usually not allowed [32]. However,
for the interests of this thesis, a more interesting scenario is where systems are
highly adaptive and can cope with difficult and unexpected situations that they
can encounter, for that they are allowed and encouraged to reconfigure and repair
themselves. In that sense, according to Gamrat et al. [14] self-adaptation can
be described as the ability of a system to react to external changes by modifying
its behavior based on local policy. Adaptivity is also an important and natural
property in Complex Systems (CS) where numerous interacting components work
cooperatively towards a common goal. Complex Adaptive Systems (CAS) represent
a particular category of complex systems [29].
1.1. MOTIVATION 7
RTR has also found potential application in the Autonomic Computing (AC)
Initiative and the Organic Computing (OC) Initiative. Both initiatives envision
systems with enough degrees of freedom to adapt dynamically to changing re-
quirements of execution environments. Those systems exhibit lifelike character-
istics or the so called self-x properties, such as self-configuration, self-healing, self-
optimization, and self-protection.
Computing systems’ complexity appears to be approaching the limits of human
capability, yet the demand for increased interconnectivity and integration of in-
dependent computing devices seems unstoppable. This situation could become a
critical threat that creates a problem of controllability [27]. Therefore, they must
be built as robust, safe, flexible and trustworthy as possible [37]. The AC Initiative,
inspired by biological principles, proposes that the only solution may be to create
computing systems that can manage themselves given high-level objectives from
administrators [27]. This self-management property should be supported by the so-
called self-x properties, that is as self-configuration, self-healing, self-optimization,
and self-protection. Among them, self-configuration may be the most important
enabler for other properties. On the other hand, a similar proposal was developed
by the OC Initiative, who is not interested in fully autonomous systems, but in the
search for concepts to achieve controlled self-organization as a new design paradigm
[51]. In 2004, they addressed the need for fundamental research on the effects of
emergence due to self-organization and the need for a paradigm shift in system de-
sign and tools [36]. They stated that “It is not the question whether self-organized
and adaptive systems will arise, but how they will be designed and controlled” [51].
A number of surveys and technical reports remark the relevance of research fields
converging in this thesis, for which RTR becomes a critical enabler. For instance,
the High Performance and Embedded Architecture and Compilation (HIPEAC)
European Network of Excellence presented the expected vision for advanced com-
puting for the year 2020 [22]. Here, they identify three strategic areas: embedded,
mobile, and data center and three crosscutting challenges: energy efficiency, sys-
tem complexity, and dependability. They suggest that to overcome the complexity
and cost of heterogeneous system development, we need tools and techniques that
provide power and performance portability. As described by HIPEAC: ”Run-time
adaptation and machine learning has demonstrated a high potential to improve
performance, power consumption, and other relevant metrics. However, these tech-
niques are still far from widespread” [22]. Similarly, another report from the In-
ternational Technology Roadmap for Semiconductors (ITRS) in 2012 [1], considers
that the overall design technology challenges are: design productivity, power con-
sumption, manufacturability, interference, and reliability and resilience. For the
last challenge, ITRS remarks autonomic computing, robust design, and software
(SW) reliability as the main issues for technologies beyond 22 nm and soft-error
correction for Ø 22 nm. Among other challenges and trends, they identify fault
tolerant architectures and protocols, and re-use of solutions for test and system
reliability.
1.1.1 Problem Description and Challenges
The following paragraphs summarize some gaps that we progressively identified

during this research, and are addressed in each publication. Starting from the
lack of flexible and economic approaches that could facilitate the design and ex-
ploitation of FPGA-based reconfigurable systems and its applications, the need for
innovative approaches to increase the system’s dependability and the scalability of
hardware redundancy, until the need for self-awareness and decision making based
on reinforcement learning to improve self-adaptivity.
The first motivation for this research emerged from the realization that existed
and arguably still exist a lack of adequate, flexible, reusable, modular and economic
approaches, methods, designs in reconfigurable computing. The attention seemed
to be directed to solve particular problems or get an architecture with better per-
formance. Apparently, to start advanced research in RC, researchers needed fancy,
complicated, and expensive coarse-grained architectures based on Application Spe-
cific Integrated Circuits (ASIC) or Application Specific Instruction Set Processor
(ASIP). Besides, an increased gap between high-level designers and reconfigurable
computing implementation dissuaded researchers. To sum up, this situation lim-
ited the utilization of FPGA-based systems to perform research and minimized the
productivity of run-time reconfigurable systems to investigate the applications in
other unexplored fields.
Despite that partial and RTR enable new opportunities, FPGAs are still seen
as a vast auxiliary area to accelerate algorithms for particular problems. Some-
times, new systems are designed for each new application. In the best case, a
single reconfigurable partition is used to switch between reconfigurations, which is
sometimes known as mode adaptivity [48] or time multiplexed [55] reconfiguration,
which solves concrete solutions but does not maximize productivity.
When several reconfigurable partitions are created and combined with a proces-
sor system, new challenges appear as a consequence of the creation of a heteroge-
neous multicore system. In contrast to typical current approaches, these multiple
cores could be seen as a group of artificial organisms working cooperatively toward
common goals, probably exhibiting emergence phenomena as a school of fishes or
flock of birds. For instance, they could organize to provide redundancy and fault
tolerance. However, the next question is how to manage, optimize, and maximize
the benefits of the new approach. With such complex systems, the hardware, and
configware (CW) must be supported by advanced software architectures, i.e., ab-
straction layers, API functions, in order to schedule, manage, organize, or optimize
the usage of those cores, mainly to handle dependability, self-x properties, and
adaptivity. Furthermore, in order to cope with uncertainty and complexity of an
autonomous self-adaptive system, other techniques such as machine learning was
considered. But it will bring challenges such as how to increase FT without us-
ing existing mechanisms e.g., Xilinx SEU protection, ECC/CRC, Lockstep, SEM
Controller [5] [64], without investing significant effort in typical fine-grain redun-
dancy methods. How to organize and manage the new array of RTR cores e.g.,
1.1. MOTIVATION 9
management of the dynamic FT schemes)? How to optimize area and power when
using dynamic fault-tolerance (dynFT)? How to make such a system adapt to real
environments that produce highly unpredictable situations? How to complete the
observe and decide phases of an adaptation system so that the whole system be-
comes self-adaptive exhibiting cognitive development, such as self-awareness and
learning so that it can cope with uncertain situations and keep acceptable levels
of performance while using their resources to maintain fault tolerance? So far,
to the best of this thesis investigation, this kind of research that explore the self-
organization of groups of cognitive reconfigurable cores towards self-adaptation may
have not been conducted or is partially explored as in [25] [28] [44] [45] [53] [3] [31].
In the last years, the community in RC has been focused on improving reconfig-
uration methods, architectures, applications. But RTR embedded SoCs are ideal
for adaptive embedded applications. However, what is still missing is the adapta-
tion capability, that is, the observe and decide phases that complement the already
developed act phase of the adaptive cycle. Moreover, advances in technology and
consumer’s demand lead to a world flooded with interconnected devices required to
work without human intervention, such as delivery drones or self-driven vehicles.
Here, autonomic, self-adaptation and cognitive properties are mandatory.
Nevertheless, most of the design methodologies that exist today are mainly
focused on generating the entire system directly. They fail to consider that a partial
reconfiguration can be used to reduce cost and power consumption, by loading
critical parts of the design at run-time. However, adoption of partial reconfiguration
is limited by the intricacy of the process to generate configurations, which implies
time and recursive effort during the layout and physical synthesis stages [Paper I].
FPGAs may be an empty canvas waiting to be imprinted by the designer’s cre-
ativity. However, by devising the right approach, we would get greater productivity
and a range of today unthinkable applications. Otherwise, we would just be using
another device that computes a bit faster with low power consumption.
1.1.2 Research Question
The global research question that motivated the investigation that is addressed
in this thesis is How can the flexibility, reusability, and productivity in the design
process of FPGA-based partial and run-time reconfigurable embedded systems-on-
chip be improved to enable research and development of novel applications in the
areas of hardware acceleration, dynamic fault-tolerance, self-healing, self-awareness,
and self-adaptation?
Essentially, to address the general research question, the author proposes that
by adopting a modular approach i.e., hardware, software, and configware, applying
principles of SoC design-and-reuse principles, and it is possible to alleviate and
speed up the design process of reconfigurations and maximize the productivity in
other advanced topics.
Self-repair
HW/SW/CW
- Flexible
d e
- Reusable
- Maintainable
THE VISION
n-Board-Computer (OBC)
A motivation example:
A long-range mission cosmic
loses contact with Earth. radiation
The FPGA based on-
board computer Uncertainty
may become faulty due
to radiation or nano-
scale integration effects.
It then must optimize
resources and self-adapt
to unpredictable
situations HPC
-speed-up
-computation
CPU M
If link I/O
gets broken High performance in a SoC The ideal Flexible and Reusable
Small-footprint, low area and power, high embedded FPGA HW, SW, and CW is SoC
integration, hardware acceleration flexible, reusable, and maintainable. - Smal
- High
Self-assembly Deals with uncertainty - Smal
Self-assembles the adequate hardware Takes optimal and non-programmed - Low
The embedded system (OBC) should : fault-tolerant scheme decisions
• Fit in a SoC (small-footprint) Self-healing Cognitive and self-adaptive

assemble the adequate dynamic FT scheme Self-repairs faulty modules or Is self-aware, learns by experience,
l and adaptively applies the best FT strategy self-replicates in spare modules and adapts itself
to current mission performance state (fault-
tolerance, optimization)
thout human interaction (autonomic: self-*) Figure 1.1: The Vision. A new type of self-adaptive and cognitive embedded systems consisting
eals with uncertainty (learns by experience) of arrays of modular RTR slots, which become self-aware of its internal performance and learn to
self-optimize the decisions that trigger the adequate self-organization of these RTR slots in order
SoC to self-heal, even while working in uncertain environments.
- Small factor
- High Integration
- Small area
- Low power
1.2 Research Objective
The current interest in reconfigurable computing and the availability of RTR tech-
nologies opens a broad spectrum of potential applications related to dependability,
adaptation, autonomic computing, and other emerging fields. Our aim is to ex-
ploit this opportunity and bring new approaches and solutions to current research
challenges, supported by a modular IP-core based approach that simplifies and
maximize the productivity of partial and run-time reconfigurable embedded SoCs.
The main objective is to devise and implement novel approaches that increase
the flexibility, reusability, and productivity in the design of partial and run-time
reconfigurable systems-on-chip in order to enable and implement self-healing, self-
awareness, and self-adaptive FPGA-based embedded systems.
The main objective can be decomposed in to specific objectives:
• To conceive, design, and implement a flexible and reusable solution based on

custom RTR IP-cores in order to overcome the design-complexity in FPGA-
based SoCs.
1.3. RESEARCH CONTRIBUTIONS 11
• To investigate and develop a solution to accelerate software functions in RTR

IP-Cores focused on flexibility and controllability via software.
• To investigate and implement alternative ways of reusing RTR IP-cores in
order to provide economical and scalable modular fault-tolerance in RTR
FPGA-based SoCs
• To conceptualize and develop a solution to implement self-monitoring, self-
awareness and self-optimization to a FPGA based RTR SoC. The results will
enable self-adaptation.
1.3 Research Contributions

1.3.1 Research Map
The research presented in this work is illustrated in Figure 1.2. The abstract
research map helps to visualize the relationship among publications, outcomes, re-
search areas or sources of inspiration, and thesis structure chronologically. The
research areas become involved at different stages and remain active for the fol-
lowing publications, which shows the consolidated and progressive approach in this
work.
For explanatory purposes, the outcome of this research is divided into three
stages or chapters as Figure 1.2. These stages can be characterized by the following
questions. Stage 1: How to improve the flexibility, reusability, and productivity in
the state-of-the-art design flow of RTR systems?. Stage 2: How the new RecoBlock
Concept can be used to increase dependability (fault-tolerance)?, Stage 3: How to
control, optimize, organize and maximize the benefits of the set of RTR RecoBlock
cores working as a fault-tolerant, autonomic, adaptive and cognitive embedded
system?.
The first outcome is the RecoBlock SoC concept [Paper I]. This original and
innovative work includes a platform and design methodology that exploits the
flexibility, reusability, and scalability of a modular RTR SoC approach based on
RTR IP-cores. Among other contributions, the platform has gradually improved
so that the current state can implement up to ten RecoBlock IP-cores in a single
SoC [Paper IV]. This enhancement allowed the investigation in alternative ways of
improving hardware acceleration [Paper II], dependability [Paper III] [Paper IV],
self-awareness, self-adaptation, and cognitive hardware development [Paper V] [Pa-
per VI].
Reinforcement
Learn ing Based Self-
goal Opti mi zation
PAPER 6
of Dynamic Fault-
Learn ing-based policy ? Tolerant Sc hemes in
VI
Self- Performance-Aware
Optimization RecoBlock SoCs.
Kno w what KTH/ICT/ESY’15
I know
Towards Cogniti ve
Reconfigurable
Hardware: Self-
PAPER 5
Machine Learning Aware Learning in
Reinforcement Learning V RTR Faul t-Tolerant
Cognitive Science Self-Awareness SoCs.
Psychology ReCoSoC’15
LE ARN
TMR-cycle
On Providing
Sc al abl e
PAPER 4 Self-Healing
Adapti ve Faul t-
The Ups et Fault IV tolerance to RTR
Observer SoCs.
ReConFi g’14
The Ups et-Fault-

F Observer: A Concept
PAPER 3 F V for Self-Healing
F Adaptive Faul t
Dynamic III
Tolerance.
Self-Healing NASA/ESA AHS’14
AC
DEP. Towards the Generic
Reconfigurable
Dependability AD AP. Ac celerator:
Fault-tolerance Algorithm
PAPER 2
Development,
Hardware Au tonomic Computing II Core D es ign, and
Ac celeration Organ ic Computing Performance
Self-x An al ysi s.
ReConFig’13
Hardware The RecoBl oc k
HPC
Ac celeration SoC Platform: A
High Performance Flexibl e Array of
Computi ng PAPER 1
Reus abl e
Run-time
The RecoBloc k
I Reconfigurable
IP-blocks.
DATE’13
SoC IDEA
Embedded
Heterogeneous
FPGA
RTR
Run-time
Reconfiguration
Reconfigurable
Computi ng
BN
Figure 1.2: Research Map. Illustrates the research timeline and the relationship between areas,
sources of inspiration, publications, and contributions.
Summary of Contributions
The following list summarizes the main contributions derived from the conducted
research and the scientific publications (Part II). The research is an accumulative,
and related work developed around the first publication and progressively extended
to answer new challenges in different related areas. It is an original work that does
not build-up on previous work at KTH
• Stage 1 (Chapter 3): The RecoBlock Platform and Hardware Acceleration

– RecoBlock SoC IP-core and platform: Conceptualized, designed, and im-
plemented the RecoBlock SoC Platform characterized by the RTR Re-
coBlock IP-core, flexible inter-block communication, and built-in buffers
with burst-control [Paper I]. Improved universal IP-core architecture to
hold bitstreams corresponding to algorithms modeled in Matlab [Pa-
per II]. Redesigned and implemented the platform containing ten Re-
coBlock IP-cores [Paper IV]. Integrated a hardware-counter based per-
formance monitor to enable self-awareness [Paper V]. Improved the Re-
coBlock IP-Core (i.e., a wrapper that includes a function container and
a fire-generator) to enable synchronization and execution controlled by
software, and to facilitate the relocation of configurations almost inde-
pendently of the accelerated algorithm [Paper II].
– RecoBlock software stack: Developed the custom software stack that
includes a unified set of drivers and API functions to manage any in-
stance of RecoBlock IP-core. It handles hardware, software and con-
figware features of the whole platform. In summary, they provide soft-
ware management of inter-block and memory transactions, and RTR of
RecoBlock IP-cores [Paper I]. Timing and triggering of algorithm exe-
cution, DRAM-based pre-fetch reconfiguration [Paper II]. Self-assembly,
self-healing, self-repairing, voting, check-pointing, and service-map pro-
cesses that control the dynFT schemes and particularly the UFO [Pa-
per IV]. Time-stamp and performance functions for acceleration metrics
[Paper II] and FT metrics [Paper IV]. Self-monitoring, training, and rule-
based or learning based decision making for performance optimization
[Paper V] [Paper VI]
– Design recommendations: Proposed a set of requirements and recom-
mendations to increase flexibility and reusability in RTR systems design
which were adopted for the implementation of the RecoBlock platform
and IP-core [Paper I]. Extended the recommendations to facilitate relo-
cation of reconfigurations and code maintainability [Paper II].
– Platform characterization: Characterized the platform performance as a
RC architecture by analyzing the phases and paths involved in the algo-
rithm execution, and evaluating the performance metrics of the acceler-
ation mechanisms included in the RecoBlock platform, i.e., the IP-core
accelerator, burst I/O transfers, and RTR pre-fetch [Paper II]. Char-
acterized the FT metrics and scalability of the novel dynFT schemes
[Paper IV].
– Design methodology: Devised a design methodology to develop complex
algorithms modeled in Matlab to be accelerated in the RecoBlock RTR
IP-core, using existing commercial off the shelf (COTS) applications that
have not been linked [Paper II].
– RTR technique: Improved the RTR method used in the RecoBlock plat-
form by pre-fetching reconfigurations from non-volatile Compact Flash
(CF) memory into double data rate type three SDRAM (DDR3) memory
[Paper II].
• Stage 2 (Chapter 4): Dependability and Self-*
– RTR FT schemes: Introduced the concept and guidelines for the im-
plementation of reconfigurable IP-core based TMR schemes (dynamic
fault-tolerance) based on the RecoBlock IP-core. These are FT schemes
based on hardware redundancy, RTR, and modular IP-cores that can be
reconfigured (self-assembled) during run-time. They allow to self-repair
(run-time reconfiguration in the same core) and to self-replicate (run-
time relocation and reconfiguration in another core). Implemented the
RTR FT schemes [Paper IV].
– Upset-Fault-Observer (UFO): Conceptualized [Paper III] and implemented
[Paper IV] the UFO. An innovative dynamic TMR-with-spare scheme,
which multiplexes redundancy in time to maximize the number of fault-
tolerant cores and minimize the scalability cost of hardware redundancy.
– Organic Computing (OC) Management Functions: Conceptualized [Pa-
per III] and implemented [Paper IV] the adaptive self-x SW model.
A software organization structure based on OC and AC that handles
strategies, schemes, and self-x features e.g., self-monitoring, service-map,
adaptive, strategy. It complements the underlying hardware and soft-
ware to observe and control the system so that it can adapt and exhibit
lifelike properties [Paper IV].
– RTR FT schemes 1 metrics: Characterized, evaluated experimentally,
and analyzed the trade-off of FT metrics involved in the self-healing
RTR FT schemes i.e., recovery time, detection and assembly latency,
throughput reduction, and scalability analysis [Paper IV].
– Proof of concept: Verified the functionalities and presented detailed
guidelines about how the RTR FT schemes and UFO are implemented
[Paper IV].
1 dynamic fault-tolerance (dynFT) or RTR FT schemes.
– 10 x RecoBlock IP-core platform: Improved to the RecoBlock platform

to support an increased amount of IP-cores, that is a total number of ten
RecoBlock IP-core accelerators were added to the standard RecoBlock
SoC platform template and relocatable bitstreams were generated [Pa-
per IV].
• Stage 3 (Chapter 5): Self-adaptation and Cognitive Hardware
– Self-aware and adaptive RecoBlock platform: Implemented the Adap-
tive Self-aware Fault-tolerant RTR SoC, building-up from the work in
[Paper IV] and implementing the missing first two phases of the observe-
decide-act cycle of adaptation (i.e., self-monitoring, self-awareness, and
rule-based decision-making). Details of hardware and software organi-
zation and implementation were presented in detail in [Paper V]
– Self-optimization and uncertainty simulation: Presented and implemented
methods to simulate uncertainty and to adapt or optimize performance
based on reinforcement rule-based algorithms [Paper V]
– Self-awareness: Implemented self-awareness based on hardware perfor-
mance counters. Provided a detailed implementation using a Xilinx core
[Paper V].
– Cognitive Reconfigurable Hardware (CRH): Introduced the basis of the
CRH concept and demonstrated it by implementing an FPGA-based
RTR SoC that becomes conscious of its monitored hardware and learns
to make decisions that maintain the desired system performance, particu-
larly when triggering hardware acceleration and dynFT schemes on RTR
cores [Paper V]. The Cognitive Reconfigurable Hardware (CRH) model
defines a path for cognitive development in hardware and reconfigurable
systems, following the cognitive development in human beings. In this
case, cognitive implies not only machine learning, but a whole process
composed of five phases: self-monitoring, self-awareness, self-evaluation,
learning, and self-adaptation.
– Learning based self-optimization: The design of a a FPGA-based SoC
that is self-aware of its monitored hardware and utilizes an online RL
method to self-optimize the decisions that maintain the desired system
performance, particularly when triggering hardware acceleration and dy-
namic FT schemes on RTR IP-cores. This contribution includes an
overview of the RL theory, Q-learning algorithm adapted for the dy-
namic fault-tolerance optimization problem, modeling and simulation in
Matlab.
1.3.2 List of Publications

This thesis is based on a collection of peer-reviewed papers published in leading
conferences of the area, and a journal article submitted for evaluation. These pub-
lications and main outcomes are organized according to the three stages identified
in Figure 1.2 and reviewed in Chapters 3, 4, and 5. Additional details are found in
the actual papers reprinted in Part II. The following list offers a brief summary of
each enclosed paper and highlights the author’s contributions.
Paper I: Byron Navas, Ingo Sander, and Johnny Öberg. The RecoBlock SoC Plat-
form: A Flexible Array of Reusable Run-Time-Reconfigurable IP-Blocks. In De-
sign, Automation & Test in Europe Conference & Exhibition (DATE), pages
833–838, New Jersey, 2013. IEEE Conference Publications
This paper proposes principles to increase the flexibility and reusability of

FPGA-based RTR architectures. These recommendations are applied to de-
sign and implement the RecoBlock SoC platform and a simplified design flow.
The platform is mainly characterized by (a) the RecoBlock, a RTR plug-and-
play IP-core whose functionalities are reconfigured at run-time from a library
of reconfigurations, (b) a flexible inter-block communication configured via
software, and (c) built-in buffers to support data-driven streams, inter-process
communication, and context-switching. Experiments show the benefits by
map a classical adaptive streaming application into a number reconfigurable
arrays and schedules, which are configured at run-time via software with-
out any hardware regeneration. Independent API functions provide support
for transactions and configurations. The platform balances efficiently design
time, cost, and performance. This RecoBlock concept is not based on any
previous work at KTH.
Author’s Contribution: The main author performed the investigation, concep-
tualization of the RecoBlock concept, design, implementation, experiments,
and writing of the manuscript. The coauthors provided important feedback,
revision of drafts, and corrections to the final manuscript.
Paper II: Byron Navas, Johnny Öberg, and Ingo Sander. Towards the generic re-
configurable accelerator: Algorithm development, core design, and performance
analysis. In Reconfigurable Computing and FPGAs (ReConFig), International
Conference on, pages 1–6, dec 2013
This paper investigates how good the RecoBlock SoC Platform can be as
a hardware accelerator in terms of speedup and bandwidth. For that pur-
pose, it first improves the IP-core architecture and design method to generate
configurations from complex algorithms described and verified in high-level
models, which must comply with the architectural specifications of the Re-
coBlock IP-core, particularly with the RP interface to facilitate relocation.
This work also enhances the synchronization and execution mechanism of the
IP-core architecture, so that high-level languages can trigger its execution and
control its periodicity. The method uses available modeling and high-level
synthesis COTS tools to reduce the gap between high-level design approaches
and reconfigurable computing technology. Experiments conduct performance
analysis of the platform and its built-in acceleration mechanism (i.e., the core
itself, burst I/O transfers, and reconfiguration pre-fetch in dynamic memory)
Author’s Contribution: The main author performed the problem formulation,
solution, design, implementation, experiments, and wrote the manuscript.
The coauthors provided important feedback, revision of drafts, and correc-
tions to the final manuscript.
Paper III: Byron Navas, Johnny Öberg, and Ingo Sander. The Upset-Fault-Observer
: A Concept for Self-healing Adaptive Fault Tolerance. In 2014 NASA/ESA Con-
ference on Adaptive Hardware and Systems (AHS-2014), 2014
This paper introduces a new perspective on the dependability improvement

in FPGA-based systems by exploiting the flexibility and scalability of existing
RTR IP-cores of a system to assemble TMR schemes during run-time. This
group of cores behaves cooperatively to make hardware accelerated functions
fault tolerant, for that they can self-assemble, self-test, self-heal (repair or
replace)
A first citizen of this approach is the novel Upset-fault-observer (UFO), a run-
time fault detection, self-testing, and self-healing (repair or replace) strategy
that delivers FT on request over several function cores, but saves the scala-
bility cost of hardware redundancy by running periodic reconfigurable TMR
scan-cycles. The system can adaptively trigger the UFO or another TMR
scheme and self-healing strategy, according to execution environment met-
rics and user-defined goals. This vision overcomes the scalability problem of
hardware redundancy and adaptively optimizes resource consumption. This
approach borrows concepts from emerging fields such as bio-inspired hardware
and organic computing. It describes an appropriate software structure that
complements the underlying hardware, manage the proposed FT schemes,
and enables the proposed self-x properties and adaptivity.
Author’s Contribution: The author conceived the concept of Self-healing RTR
FT schemes based on RTR IP-cores, and particularly the UFO. Presented
implementation guidelines, projected issues and solutions, and wrote the
manuscript. The coauthors provided important feedback, revision of drafts,
and corrections to the final manuscript.
Paper IV: Byron Navas, Johnny Öberg, and Ingo Sander. On providing scalable
self-healing adaptive fault-tolerance to RTR SoCs. In 2014 International Confer-
ence on ReConFigurable Computing and FPGAs (ReConFig14), pages 1–6. IEEE,
dec 2014
This paper implements demonstrates and evaluates the concepts introduced in

Paper III. Mainly, it presents the implementation of the self-healing adaptive
fault-tolerant SoC that reuses RTR IP-cores to self- assemble different TMR
schemes during run-time. It demonstrates the feasibility of the Upset-Fault-
Observer concept, which provides a run-time self-test and recovery strategy
that delivers fault-tolerance over functions accelerated in RTR cores, at the
same time reducing the redundancy scalability cost by running periodic re-
configurable TMR scan-cycles. This work also optimizes the interconnection
system and manage to synthesize a total number of ten RecoBlock IP-core to
the standard RecoBlock platform template. This extension provides enough
number of cores to assemble and experiment with the TMR schemes. Thus,
experiments evaluate the scalability trade-off of each reconfigurable TMR
scheme. Besides, this paper characterize and measures metrics relevant for
fault-tolerance (i.e., recovery time for self- repair and self-replicate, detection
latency, self-assembly latency, throughput reduction, and scalability).
Author’s Contribution: The investigation, conceptualization, design, imple-
mentation, case study, the manuscript was performed entirely by the main
author of this paper. The coauthors provided important feedback, revision of
drafts, and corrections to the final manuscript.
Paper V: Byron Navas, Ingo Sander, and Johnny Öberg. Towards Cognitive Re-
configurable Hardware : Self-Aware Learning in RTR Fault-Tolerant SoCs. In
Reconfigurable and Communication-Centric Systems-on-Chip (ReCoSoC), 2015
10th International Symposium on, 2015
This paper investigates how to know when and which dynamic FT-scheme
can be launched without critically affecting the overall performance of a sys-
tem that works under uncertainty. Thus, this paper proposes the concept
of cognitive reconfigurable hardware as an approach to overcome the com-
plexity of reconfigurable multicore embedded systems operating in uncertain
environments, assuming that software execution branches are unpredictable.
This concept outlines a model for cognitive development in hardware consist-
ing of five phases, with a strong emphasis on reconfigurable hardware, i.e.,
self-monitor, self-awareness, self-evaluation, self-learning, and self-adaptation.
Consequently, this paper presents the design of a FPGA-based RTR SoC
that it becomes conscious of its monitored hardware and learns to make
decisions that maintain the desired system performance, particularly when
triggering hardware acceleration and dynamic fault-tolerant (FT) schemes on
RTR cores. This work also describes how to achieve self-awareness based
on hardware self-monitoring using hardware performance counters. Experi-
ments propose and implement methods to simulate uncertainty and to adapt
performance based on reinforcement rule-based algorithms and a set of the
most meaningful self-monitored metrics. Existing research on self-awareness
has been concentrated on workstations but is rapidly growing on embedded
1.4. THESIS ORGANIZATION 19
SoCs. The cognitive processes defined in this work mark the path for addi-
tional research.
Author’s Contribution: The main author identified the problem, defined the
CRH concept, implemented the system, conducted experiments, and wrote
the manuscript. The coauthors provided important feedback, revision of
drafts, and corrections to the final manuscript.
Paper VI: Byron Navas, Ingo Sander, and Johnny Öberg. Reinforcement Learning
Based Self-Optimization of Dynamic Fault-Tolerant Schemes in Performance-
Aware RecoBlock SoCs. Technical report, KTH Royal Institute of Technology,
School of Information and Communication Technology, Stockholm, Sweden, 2015
This paper realizes that embedded systems need to make autonomous deci-
sions, develop cognitive properties and finally become self-adaptive so that
they can be deployed in the real world. However, classic off-line modeling
and programming methods are inadequate to cope with uncertainty in real
world environments. Therefore, this paper complements de decision phase of
an adaptive system by introducing a reinforcement learning based approach.
This article presents a FPGA-based SoC that is self-aware of its monitored
hardware and utilizes an online RL method to self-optimize the decisions that
maintain the desired system performance, particularly when triggering hard-
ware acceleration and dynamic FT schemes on RTR IP-cores. Moreover, this
article describes the main features of the RecoBlock SoC concept, overviews
the RL theory, shows the Q-learning algorithm adapted for the dynamic fault-
tolerance optimization problem, and presents its simulation in Matlab. Based
on this investigation, the Q-learning algorithm will be implemented and ver-
ified in the RecoBlock SoC platform.
Author’s Contribution: The investigation, conceptualization, design, imple-
mentation, experiments, and writing the manuscript was conducted by the
main author of this paper. The coauthors provided important feedback, re-
vision of drafts, and corrections to the final manuscript.
1.4 Thesis Organization

The thesis is organized into six chapters as follows.
Chapter 1 presents a brief motivation to this work, the problem statement, a
summary of the original research contributions and the thesis outline. Chapter
2 provides a brief background of the topics and sources of inspiration. Chapter 3
discusses the research in Paper I and Paper II. Chapter 4 is devoted to introduce the
research conducted in Paper III and Paper IV. Chapter 5 is dedicated to overview
the investigation performed in Paper V and Paper VI. Finally, Chapter 6 presents
thesis conclusions, and suggest future research directions.
Chapter 2
Background
This chapter reinforces and briefly extends the introductory background presented
in Section 1. It provides some additional concepts needed to unerstand the following
chapters, particularly for readers not familiar with basic concepts of reconfigurable
computing (Section 2.1), FPGA technology (Section 2.2), dependability and fault
tolerance (Section 2.3), adaptive systems (Section 2.4), autonomic and organic com-
puting including the self-x properties (Section 2.5).
2.1 Reconfigurable Computing

The history of Reconfigurable Computing (RC) may be seen as driven by two
acts that are still active and playing in parallel. First, the race for new powerful
computing architectures competing against the classical but considered obsolete
von-Neumann inheritance, and secondly the rise of the less powerful but promising
FPGA. Inserted in the second act, the emergence of RTR technologies supposed
a major change in the way of thinking about reconfigurability and enabled new
directions in research and new challenges as well.
RC is the second RAM-based machine paradigm that offers a drastic reduction
in energy consumption and speedup factors by up to several orders of magnitude
compared to the von-Neumann paradigm, which, according to R. Hartenstein, is
beginning to loose its dominance [19]. This new paradigm brings a disruptive
new horizon for affordable, very high-performance computing and also changes
to the practice of scientific and embedded system applications. Heterogeneous
systems including both paradigms will need innovation for parallel programming
(software) of manycore architectures and structural programming (configware) of
RC architectures. For that, innovative solutions are required [19].
21
22 CHAPTER 2. BACKGROUND
Research and industrial applications in RC using FPGAs have moved into two
major fields, high performance reconfigurable computing (HPRC) and embedded
Reconfigurable Computing (eRC). Due to low power consumption and high den-
sity available in current FPGA technology, HPRC uses FPGAs as accelerators for
supercomputers, providing additional increase in performance. Large high per-
formance computing (HPC) vendors are already supplying machines with FPGAs
ready-fitted. However, the programmer productivity is a problem yet to be solved
[19]. On the other hand, a growing trend is the use of FPGAs in embedded sys-
tems. Originally there has been a feeling that FPGAs are too slow, power-hungry
and expensive for many embedded applications. Now, the situation has changed
due to the availability of low power and a wide range of small packages. FPGAs can
be found in the latest handheld portable devices, including smartphones, cameras,
medical devices, industrial scanners, military radios [19].
The performance of FPGAs, and most RC architectures is better than micropro-
cessors or CPUs by several orders of magnitude [18], despite the fact that FPGAs
have lower clock speeds and huge area overhead product of reconfigurable wiring
fabrics. The reason for this paradigm is the way that data is moved. CPUs usually
move data between memories commanded by the execution of instructions due to
the von Neumann approach. Besides, reading and decoding is required before the
execution inside the CPU. In contrast, in RC, an algorithm is run by data streams
only. No hardwired program counter or instructions sequences are required. In-
stead, reconfigurable data counters are used, and the execution in the reconfigurable
architecture or DPU is transport-triggered [19]. This is a major difference between
RC and classical CPU.
Hardware acceleration, as a subsystem that supports CPU, is a classical appli-
cation for RC implemented either in a hardwired logic device e.g., ASIC or in a
field-programmable logic, e.g., FPGA.
2.2 Programmable Logic, FPGA

FPGA evolution has been driven by major events such as, the first conception of
reconfigurable computing by G.Estrin in 1960 [12], the feasibility of actual imple-
mentation of RCwith the introduction of commercial FPGAs around 1985 [47], the
introduction of the idea of time-multiplexed FPGAs to load entire configurations
stored in memory by Trimberger et al. [55]. Along this road, FPGAs gradually be-
came more attractive to several application sectors. Thus, RC systems implemented
on programmable-logic-devices have evolved into today’s complex heterogeneous
and multicore SoCs [Paper V].
The term "field-programmable" shows that the functionality can also be changed
at the users site by receiving new configuration code from some memory, or even
over the web [19]. First field-programmable blocks from the early 1980s have
been so-called Field Programmable Logic Arrays (FPLAs) featuring a very area-
efficient layout similar as known from Erasable Programmable Reand Only Memory
2.2. PROGRAMMABLE LOGIC, FPGA 23
HDL DESIGN
DESCRITPION
LOGIC
SYNTHESIS
TECHNOLOGY
MAPPING
PLACEMENT
IOB
IOB
IOB
IOB
IOB
IOB
Configurable
Interconnect
IOB PLACEMENT
Block IOB
CLB CLB DSP CLB
RAM
IOB IOB
ROUTING
IOB IOB
CLB CLB Block CLB
IOB DSP IOB
RAM BITSTREAM
GENERATION
bn
IOB
IOB
IOB
IOB
IOB
IOB
*.BIT
FILE
(a) Abstract Block Diagram of an FPGA (b) Simplified FPGA Design Flow
Figure 2.1: Abstract view of a FPGA internal structure and design flow. (a) Abstract block
diagram of a modern FPGA integrated circuit with typical blocks such as CLB, input-output
blocks (IOB), and digital-clock-manager (DCM), and specialized blocks such as BRAM and DSP.
(b) Simplified design flow from design entry as HDL description until generation of the equivalent
bitstream file which is loaded in the FPGA configuration memory
(EPROM) at the cost of being able to compute only Boolean functions in sum-of-
product form. In fact, FPGAs feature much more flexibility by introducing CLBs
and routable wiring fabrics for interconnecting between CLBs (Figure 2.1). As
opposed to FPLAs, the CLB in FPGAs allows for instance to select one of 16
logic functions from simple Look-Up Tables (LUTs). In any case, FPLAs are not
routable and permit just to implement Boolean functions in sum-of-product form.
The kind of reconfiguration in FPGAs has improved from full to partial-and-
RTR. In contrast to early years of reconfigurable computing where a full reconfigu-
ration was loaded at a time in an FPGA, partial reconfiguration allows the partition
of the FPGA into reconfigurable regions that can be independently reconfigured.
Besides, run-time reconfiguration permits to reconfigure any of those regions with-
out any global reset allowing the other regions remain operative. Therefore, the
challenge is different nowadays since a multicore MPSoC and programmable logic
can coexist in the same FPGA. Thus, the system itself must be able to selectively
reprogram logic partitions while the software in the processor is still running. This
property makes partial and RTR extremely attractive and challenging [Paper IV].
Regarding adaptivity, the improved speed-up, power consumption, reduced size,
and flexibility given by reconfiguration makes heterogeneous FPGA-based SoCs
with reconfigurable cores the ideal vehicle for adaptive embedded systems [Pa-
static reconfigurable
STATIC
Functionality unnaffected,
according to initial full
configuration .bit file
RM-1.bit
RM-2.bit
RM-3.bit
Reconfig.
Partition
Reconfigurable Modules (RM)

FPGA
RECONFIGURABLE
reprogrammed according to
partial .bit file(s)
(a) Partial reconfiguration concept. (b) Generation flow of partial reconfigurations
Figure 2.2: Partial and run-time reconfigurable (RTR) Reconfiguration. (a) Main concept. The
logic is divided in static and reconfigurable regions (partitions). Reconfigurable modules (partial
reconfigurations) can be programmed into the reconfigurable partition (RP) while the static region
remains unnafected. (b) Simplified partial reconfiguration design flow. The bitstream generation
is repeated to obtain each partial reconfiguration bitstream. The static region remains constant
so it is copied (promoted) between designs (Source: Xilinx [63])
per V]. For instance, today researchers can implement on hardware, previously
unthinkable properties such as self-reconfiguration, self-repairing, self-healing, or
dynamic hardware redundancy for on-line fault mitigation with low area overhead
[6] [57] [39].
Research in RC witnessed the first steps towards heterogeneous RTR MPSoC,
however, they are now becoming a mainstream trend due to industry solutions such
as the Xilinx Zynq All Programmable SoC platform [2]. In these environments, the
importance of flexibility through IP-core design-and-reuse [33] is now more evident
than before. Therefore, modular and flexible solutions based on IP-cores that are
also RTR (RTR IP-cores) will become paramount in the next years [Paper IV].
2.3 Dependability
The importance of building dependable computer systems has increased radically.
Today, the industry can integrate silicon devices at nano-scales and provide suffi-
cient logic density to synthesize complex systems such as multicore heterogeneous
SoCs. However, it also increases the probability of fabrication defects, lifetime
faults, and other issues.
Dependability is the ability of a system to deliver its intended level of service
in the presence of faults [11], which is measured in terms of probabilistic Reliabil-
2.3. DEPENDABILITY 25
ity, Availability or Safety. Fault Tolerance provide design techniques that increase
the dependability of systems. Among those FT techniques, hardware redundancy
schemes are used to mask the presence of faults or to detect them. For instance,
the TMR is a widely accepted scheme that coalesce three replicas of a module and
a majority voter. TMR is the most elementary scheme able to mask one fault [Pa-
per IV]. Partial or full reconfiguration are typically used to recover FPGA-based
systems from a faulty state.
F
F F V
F F
F V V F V C
F F
F F V
S
Triple-Modular Redundancy with Triple-Modular Redundancy

Triple-Modular Redun dancy Duplication with Comparison
Spare with Three Voters
Figure 2.3: Hardware Redundancy Schemes.
Another concern is that SRAM-based FPGAs are more susceptible to several

types of radiation that produce bit fluctuations in the configuration memory. Cos-
mic rays, atmospheric neutrons, or electromagnetic radiation generate SEUs in the
configuration memory of SRAM-based FPGAs, where their logic and interconnec-
tions are defined. These events are frequent in space, but also in atmospheric and
terrestrial applications. SEUs are not considered a permanent fault and is usually
mitigated by reprogramming the FPGA, but represents an issue of dependability
for critical applications that must be addressed [Paper III].
Advances in integration technology close to nano-scales increases density that
makes space for bigger designs, but also increase sensitivity to SEUs. Due to dis-
ruptive integration scales reaching atomic-scale, soft errors will be more frequent.
Components will be profoundly defective, and will expose unsteady properties dur-
ing operational lifetime. In other words, it is paramount to increase the dependabil-
ity of FPGA-based systems, particularly in extreme radiation environments such
as space missions, military applications, or even consumer critical applications that
will be progressively immersed into mobile wireless and magnetic radiations [Pa-
per IV]. Hence, according to Dehon [10], to fully exploit these novel technologies,
paradigm shifts are necessary. For instance, post fabrication customization, em-
bedded lifetime test and configuration, continuous on-line monitoring, or in system
repair [Paper III] [Paper IV].
Programmable logic companies produce FPGAs that are well tested, highly
reliable. They even provide built-in mechanisms to mitigate SEUs. However, a
fault can still occur. Hence the importance of implementing additional mechanisms
to tolerate those faults, that is to monitor, detect, locate, isolate, repair, or lead to
a graceful degradation state.
2.4 Adaptive Systems

Adaptation is a remarkable property that increase the success of living beings and
systems.The concepts of adaptation and adaptivity are widely used, and its defini-
tion depend on the application field. During the last few years, computer scientists,
inspired by certain biological processes, have given birth to domains such as artificial
neural networks and evolutionary computation [56]. Living organisms are complex
systems exhibiting a range of desirable characteristics, such as evolution, adapta-
tion, and fault tolerance, which have proved difficult to realize using traditional
engineering methodologies [56]. However, the occurrence of partially reconfigurable
FPGAs has been a driver for the growing interest in adaptive systems, since now
adaptivity cannot only be implemented in software but even more efficiently in
hardware [48] [7].
When defining adaptation, according to the conclusion in [32], the ”relativity
of the term adaptation” forces us to specify the frames of reference. It does not
matter knowing if a system is adaptive or not, but about what is it adaptive. This
relativity in the definition of adaptation is exemplified in the following paragraph.
Adaptation is first observed in living systems and was documented at least
since Ch. Darwin in the 19th century [32]. Since then, humans have been trying to
emulate adaptation in different fields such as psychology, social sciences, economy
or engineering, among others. In evolution theory, adaptation is a process where
the variation of existing individuals is generated and followed by selection and
elimination of the less fit ones. This definition is acceptable in several fields and
leads to the notion of a fitness function. In a general context, Zadeh [66] proposes
that ”a system is adaptive with respect to a set of operating conditions and a
class of performance values. Its performance in those conditions stays inside that
class”. Regarding the similar terms adaptive and adaptable, according to Schmeck
et al. [51], a system is adaptive if it is capable of moving into acceptable states
without needing external control. Whereas, an adaptable system, explicit external
actions are possible and necessary to reach the acceptable states. In classical control
theory, adaptation is seen as coping with disturbances and keeping the main system
parameters close to a set-point, with a strong emphasis on feedback. Successful
adaptation means to return to the same pre-perturbation state since radical changes
of the system are usually not considered acceptable [32].
A more interesting scenario for the scope of this thesis is the capability of self-
adaptation, where systems are highly adaptive and can cope with difficult and
unexpected situations that they can encounter, for that they are allowed and en-
couraged to reconfigure and repair themselves. In that sense, according to Gamrat
et al. [14], self-adaptation can be defined as the ability of a system to react to ex-
ternal changes by modifying its behavior based on local policy. Such system needs
to exhibit adaptability as the result of a reactive process modeled by a feedback
loop or loops. The “self” of a system is entirely described by its local policy. The
“self” is the local behavior of the system, and it is the knowledge that needs to be
maintained locally and that provides the autonomous (or local) behavior [9].
2.5. AUTONOMIC AND ORGANIC COMPUTING 27
Adaptivity is also an important and natural property in CS where a large num-

ber of interacting components work cooperatively to achieve a common goal. In
turn, Complex Adaptive Systems (CAS) represent a special category of complex
systems, where in addition to being complex, systems are also adaptive, in the
sense that they modify themselves in response to changes in their environments and
potentially learn based on experience. CAS examples include ecosystems, social in-
sects and ant colonies, brains and immune systems, cells and developing embryos,
financial systems and stock markets and political and cultural communities [29].
2.5 Autonomic and Organic Computing

The progress in computing technology, from supercomputers to embedded devices,
is leading to the world with interconnected intelligent devices that start becoming
systems too complex to be controlled, managed, or maintained. The designers and
even less the users will not have neither the capacity nor the time to handle their
creation. Aware of this issue, new research areas, such as Autonomic Computing
and Organic Computing, have appeared during last years. They are bio-inspired
solutions aiming to release the control of the system to itself. However, how this
can be achieved is still an ongoing research topic.
2.5.1 Autonomic Computing

The complexity of computing systems may be approaching the limits of human
capability. However, the demand for increased interconnectivity and integration of
independent computing devices seems unstoppable, which in turn could become a
frightening threat that rises the problem of controllability [27]. Since we increasingly
depend on these systems, we must construct them as robust, safe, flexible and
trustworthy as possible [37].
Inspired by the biological principle of the autonomic (nervous) system as a
paradigm for system design [36], in 2001, IBM suggested that the only solution to
handle this threat may be to create computing systems that can manage them-
selves given high-level objectives from administrators. They called this initiative
Autonomic Computing (AC) [27].
When introducing AC, IBM was mainly concerned with enterprise systems [29].
In that context. IBM described ideal behaviors of an AC system. For instance,
it should be able to maintain itself, adjust their operation and workloads, monitor
itself, check for upgrades, install them, reconfigure itself as necessary, run regression
test, detects errors, revert to the older version, and isolate the source of errors, all in
the face of changing components, external conditions, or hardware or software fail-
ures [27]. Similar challenges and visions have been addressed in other interrelated
fields such as dependable computing systems, pervasive and ubiquitous systems,
smart buildings, smart grids, mobile networks, and cluster infrastructures [29].
The essential property of AC systems is self-management [27], which can be
achieved by enabling four fundamental features called self-x properties, which define
an autonomic system. These self-x properties are described as follows. (1) Self-
configuration: the system sets or resets its internal parameters so as to conform
to initial deployment conditions or to adapt to dynamic environmental conditions,
respectively. In this way, the system continuously meets a set of business objec-
tives. (2) Self-healing: the system detects, isolates and repairs failed components
so as to maximize its availability. (3) Self-optimisation: the system pro-actively
strives to optimize its operation so as to improve efficiency on predefined goals.
(4) Self-protection: the system anticipates, identifies and prevents various types
of threats to preserve its integrity and security [27]. Later, an extended list has
been progressively added to some other enabling properties such as self-adapting,
self-adjusting, self-aware, self-diagnosis. It most be noted that self-configuration
may be the most important enabler for the other fundamental properties, e.g.,
self-optimization, self-healing, and self-protection.
Figure 2.4: Autonomic Computing Manager. The MAPE-K model or autonomic manager refer-
ence architecture. (Source: from Lalanda et al. Autonomic Computing [29])
Regarding the implementation, AC systems rely on the notion of an Autonomic

Element (AE) which is an executable software unit that exhibits self-x properties.
It implements a control loop to constantly meet high-level goals set by authorized
entities [29]. An AE contains two types of modules. The managed-artifacts are
the software or hardware entities that are automatically administered, and the
autonomic-manager is the entity in charge of the runtime administration of the
managed-artefacts [29].
2.5.2 Organic Computing

The priority research programme OC of the German Research Foundation proposed
an initiative similar to AC. However, they are not interested in fully autonomous
systems, but in the search for concepts to achieve controlled self-organization as
a new design paradigm [51]. In 2004, they addressed the need for fundamental
research on the effects of emergence due to self-organization and the need for a
paradigm shift in system design and tools [36]. As stated there: “It is not the
2.5. AUTONOMIC AND ORGANIC COMPUTING 29
question whether self-organized and adaptive systems will arise but how they will be
designed and controlled” [51].
Similarly, OC also devise technical systems that act more independently, flex-
ibly and autonomously, adapting dynamically to the current conditions of its en-
vironment. The organic systems are self-organizing, self-configuring, self-healing,
self-protecting, self- explaining and context-aware [37]. However, endowing techni-
cal systems with the property of self-organization in order to be adaptive changing
environmental conditions and external goals, may result in a phenomenon known
as emergent behavior (e.g., a flock of birds, school of fish) exhibiting higher de-
grees of order. This emergent behavior may be unanticipated or undesired, with
positive or negative effects [37] [51]. Therefore, the vision of autonomic comput-
ing is about computing systems capable of managing themselves without (or with
limited) intervention by human beings [45].
Figure 2.5: Organic Computing Architecture. Observer/Controller architecture and different

implementations according to the distribution of the observer/controller and system under obser-
vation and control (SuOC). (Source: Schmeck et al. Adaptivity and Self-organisation in Organic
Computing Systems [51])
From the design perspective, OC proposes a generic Observer/Controller archi-

tecture with a regulatory feedback mechanism to achieve controlled self-organization.
This architecture has similarities in other scientific disciplines like control theory
or autonomic computing. However, the aim is not a fully autonomous element
[51]. This model contains three major components. The self-organizing SuOC,
which is the productive system and is governed by a higher level observer and a
controller. The observer monitors the underlying system and reports a description
of the currently observed situation to the controller. The controller evaluates this
description with respect to a given objective and takes appropriate control actions
to influence the underlying system and meet the system goal [51]. OC allows a sin-
gle SuOC but also encourage the distribution of computational intelligence among
large populations of smaller entities. In both cases, the SuOC needs to fulfill basic
requirements: system and environmental observability, performance measurability,
system parameters dynamic reconfigurability [54].
Chapter 3
The RecoBlock Concept
This chapter in brief introduces the RecoBlock Concept, its implementation, and
enhancements for reconfigurable hardware acceleration of complex algorithms in-
cluding performance analysis. This chapter is divided into two sections that sum-
marize the work in [Paper I] and [Paper II]. Section 3.1, presents the flexible and
reusable RecoBlock Concept, describes the research questions that motivated this
investigation, the proposed solution, and gradually discuss the reasons that moti-
vated the RecoBlock concept. It then summarizes its implementation and discuss
work in Paper I. Section 3.2 present a brief overview of the challenges, motivation,
and the solution to develop complex algorithms in Matlab and implement them
in RTR RecoBlock IP-cores. It then summarizes the RecoBlock platform charac-
terization and its performance analysis as a reconfigurable computing architecture,
with execution phases. Finally, it concludes the work in Paper II. The purpose
of this chapter is to give an abstract overview of these two papers from another
perspective and to help the reader to understand the work that supported the rest
of publications and the thesis.
"Architecture starts when you carefully put two bricks together. There
it begins."
Ludwig Mies van der Rohe, Bauhaus 1959
31
32 CHAPTER 3. THE RECOBLOCK CONCEPT
3.1 RecoBlock: A Flexible Array of Reusable Run-time

Reconfigurable IP-blocks
This section introduces the research in Paper I, which presents a particular SoC
platform; one with a set of reusable plug-and-play blocks, whose functionalities are
reconfigurable at runtime and can be easily organized in different arrays at run-time
as well. It is called “ the RecoBlock SoC Platform”.
3.1.1 Motivation
Run-time reconfigurable FPGAs combine the flexibility of software with the high
efficiency of hardware. Still, their potential cannot be fully exploited because of
the increased complexity of its design process, particularly the long and complex
generation of partial reconfigurations.
To illustrate the initial motivation for the research in this thesis, Figure 3.1
describes a scenario where a system level designer wants to explore the benefits
of RTR. One of the common strategies to cope with the SoC’s design complexity
gap [33] is to perform system-level design and design exploration at high-levels
of abstraction. Nevertheless, system-level designers may also want to try run-
time reconfiguration in their projects, attracted by the advantages in speed-up and
energy saving offered by reconfigurable computing. Then, some questions start to
come out in the designers mind such as, shall I use fine-grained, coarse-grained,
or maybe a full high-performance reconfigurable system. Frequently, the answer is
something in the middle, a virtual platform.
Thus, the problem is a new kind of design gap, the one between high-level
design approaches and reconfigurable computing technology. On one hand, system
level designers forget to consider or wrongly assume important details when they
abstract their models. Whereas on the other hand, hardware designers are not
making reconfiguration friendly enough. In this sense, the challenge is to investigate
alternative solutions to close this gap and to move people to the reconfigurable
computing revolution. Hence, to bridge this gap, this thesis devised the RecoBlock
concept.
3.1.2 Idea
The following describes the reasoning development that enabled this thesis ad-
dressing the research question presented in Chapter 1. Design-and-reuse through
IP-cores is one of the foundations of any SoC [13] [33], which even outlines an
ideal IP business model. Consequently, the author wonders if the same strategies
can be used to conquer the new system design and reconfigurable computing gap.
This presumption makes sense, particularly considering that in near future FPGAs
are expected to hold heterogeneous and multicore SoCs, which contrasts with the
old glue-logic vision of FPGA design. In this context, reconfigurable slots have to
communicate with a processor system through an interconnection fabric. For that
3.1. RECOBLOCK: A FLEXIBLE ARRAY OF REUSABLE RUN-TIME RECONFIGURABLE IP-BLOCKS 33
HIGH LEVEL OF ABSTRACTION

p0 f1 f2
p1 f3 A
A
A
p3 Matlab model A
A
p2
Process Network
SYSTEM LEVEL DESIGN – HARDWARE GAP

RECONFIGURABLE COMPUTING
MM MM MM
M M M
FPGA FPGA FPGA
FPGA FPGA FPGA

€
€€
MM MM MM
M M M
Fine Grained Coarse Grained HPR System
Figure 3.1: The system-level design and reconfigurable computing gap. System-level designers
may want to try run-time reconfiguration, attracted by the advantages in speed-up and energy
saving. Sometimes, the design time and cost of a custom implementation, or the selection between
fine-grained, coarse-grained, high-performance reconfigurable systems, or virtual platforms, will
dis-encourage the designer. System-level designers forget important implementation details when
they abstract their models, whereas hardware designers are not making reconfiguration friendly
enough.
reason, any reconfigurable function should be packed inside an IP-core with appro-
priate master and slave ports and following the interconnection fabric protocols.
In this way, the chances of reuse and maximize productivity may be higher. The
idea described above may seem evident, but as simple as it sounds, it has not been
always realized or adopted. The results, of this thesis, exemplify the advantages of
flexibility, reusability, and productivity of this approach.
3.1.3 The RecoBlock Concept

The RecoBlock Concept The RecoBlock IP-core is part of a typical SoC with
an interconnect fabric, processor, memory, and peripheral subsystems, and other
specific IP-cores. The RecoBlock IP-core becomes available from a library of IP-
cores, which is instantiated (plug-and-play ready) during design time. One or more
can be instantiated. There is a library of partial reconfigurations, also known as
Reconfiguration Module (RM), corresponding to the functions accelerated in hard-
ware and generated beforehand. These functions can be loaded during run-time.
The interconnect fabric must provide flexible inter-block and block memory links
(defined by software), so that the array architecture of RecoBlocks is not fixed and
can also be configured by software at run time. A customized interconnect fabric to
keep a small footprint approach is recommended, although a more expensive and re-
source consuming NoC could be suitable. Finally, to support a better inter-process
communication and context-switching (store intermediate results) during reconfig-
THE RECOBLOCK CONCEPT

Plug & Play IP Cores
Library of
Reconfigurations
PROCESSOR MEMORY I/O
RTR Functions
Flexible
Interblock Links (SW)
Flexible
INTERCONNECT
Array Architecture (SW)
Built-In Buffer
p0
p1 p0
p1 RM
p3
p2
p3
p2
RM
RecoBlock IP Partial
RM Reconfiguration
IP Lib RM RM
Lib. (.bit)
Figure 3.2: The RecoBlock Concept. A framework composed of a reusable SoC template, run-time
reconfigurable plug-and-play IP-cores (RecoBlocks), a library of partial reconfiguration bitstreams,
hardware and configware software layer with API and drivers, and a design methodology. Addi-
tionally, highly flexible links selected by software help to define different arrays of reconfigurable
architectures during run-time. The RecoBlock IP-core is also as an implicit hardware accelerator
with additional built-in performance-oriented features [Paper I].
uration, the IP-core has a built in buffer that improves performance and alleviates
contention for shared RAM. The concept supports data-driven applications, and
context switching during reconfiguration.
The following scenario, illustrated in Figure 3.2, assumes there is a model of a
system where exists a process that is resource-hungry. This condition makes it an
ideal candidate to be mapped onto hardware. Then the functions are allocated in
the IP-core. But, that is nothing new, embedded systems designers have been using
FPGAs to accelerate functions, even with IP-cores. However, the difference is that
after a while, a second candidate is identified, and the system can reconfigure that
function in the embedded Reconfigurable Partition (RP) of the same IP-core, at
run-time while the processor is running. Besides, since there is no coarse-grained re-
configurable custom architecture in the partition, the processes are mapped almost
directly without any particular compiler, provided that the partial reconfigura-
tions are available beforehand. The VHSIC (Very High Speed Integrated Circuit)
Hardware Description Language (VHDL) description could become available via a
high-level synthesis tool such as C2H or HDL Coder [24]
Regarding the choices for implementation, the RecoBlock concept is supposed
to be general and not limited to any FPGA technology, hence his importance.
However, the concept has been demonstrated using Xilinx devices (i.e., Virtex-6)
and tools (i.e., ISE, XPS and PlanAhead, versions 13.x to 14.x) for the following
reasons. By the time this concept was conceived, Altera did not have devices
supporting full partial and run-time reconfiguration, their limited reconfiguration
allowed the switching of I/O standards (tranceivers) during run-time [4]. After few
years, they launched devices with RTR capability, i.e., Stratix V, and they gradually
introduce tool support [4] . In contrast, Xilinx had been for years leading RTR
technologies including tool support. During last years of the research presented
in this thesis, Zynq devices, Vivado tools, and the All Programmable and EPP
approach became available [63]. The "All Programmable SoC" concept also puts
emphasis in reusability via extensible platforms and all in one solution so that
software designers can handle the complexity of reconfigurable logic, yet it is a
complete solution with strong company support. It remains exciting to investigate
the implementation of RecoBlock arrays in the Zynq and Vivado environment.
Hardware As a consequence, the next question is which type of platform can sup-
port the RecoBlock Concept. Figure 3.3 illustrates the RecoBlock platform based
on a Xilinx Virtex-6 that supports run-time partial reconfiguration [59]. Appar-
ently, it looks like any other SoC platform because part of the research philosophy
is to keep solutions simplified and economical while enabling advanced research.
This classical Xilinx FPGA-based processor system (SoC) is called the RecoBlock
template, over which custom enhancements have been progressively added. Among
other special enhancements to the RecoBlock template, the most important are: (a)
the interconnect fabric and (b) the RecoBlock array. First, the early adopted in-
terconnection is the now de facto standard for embedded applications; the AMBA
AXI4 interconnect [60]. This custom AXI4-interconnect is configured in sparse
crossbar mode with a shared-address multiple-data (SAMD) topology. The pur-
pose is to allow independent and concurrent transfers. In that way, it enables link
flexibility. Any RecoBlock’s master can transfer data to any other RecoBlock’s
slave (even itself) without passing through memory. Although, they can also trans-
fer data to memory, no Direct Memory Access (DMA) logic is enabled inside the
IP-core architecture to keep resource consumption low and to avoid memory con-
tention. Secondly, the flexible RecoBlock array, whose architecture can be modified
via software due to the flexible links, and their functions are loaded and executed
at run-time via software due to its custom internal structure described as follows.
RecoBlock IP-core A simplified view of the RecoBlock IP-core is shown

in Figure 3.4. The Reconfigurable Partition (RP) holds the hardware accelerated
function and is the only non-static region in the core. Therefore, all other com-
ponents of the IP-core are common to each instance, and so they are reusable.
The RecoBlock interface is simple and fixed to improve flexibility. Specifically,
the interface consists of Clk, DataIn and Result ports. The AXI4 slave port is
• SAMD (Shared-Address-Multiple-Data) topology

• Independent and concurrent transfers
under single-threaded address arbitration.
Xilinx Virtex-6 RcBk-SoC System
I LMB
BRAM MICRO RESET CLOCK
Block &
DEBUG
MDM
Controller D LMB BLAZE PROC SYS GENERATOR
DC IC DP IP AXI4-Lite
AXI4 Interconnect
INTERCONNECT FABRIC (Sparse Crossbar Mode)
AXI4-Lite AXI4
AXI4-Lite AXI4 AXI4-Lite AXI4 AXI4-Lite AXI4-Lite AXI4-Lite AXI4-Lite AXI4-Lite AXI4-Lite AXI4-Lite
RCBK 0 RCBK 1 RCBK N AXI AXI AXI AXI AXI AXI AXI
HWICAP SYSACE V6 DDRX INTC TIMER GPIO UARTLITE
RCBK ARRAY RECONFIGURATION EXTER. TIMER & BASIC

CONTROL MEMORY INTERRUPTION IO
COMPACT DDR3 PC
LEDS
Flexible FLASH SDRAM TERMINAL
Arrray
Architecture Reconfiguration Generic System Control & IO
Support
Figure 3.3: The basic RecoBlock platform. It is composed of a RecoBlock template and custom
enhancements like the RecoBlock array and customized AXI4-interconnect. The template is basi-
cally a classical Xilinx FPGA-based processor (SoC) architecture. The RecoBlock concept looks
for solutions simplified, economical, reusable approaches but enables advanced research on RTR
computing [Paper I]. This platform has been gradually improved. Paper V presents the current
state that includes ten RecoBlock IP-cores, self-monitoring, and other additions.
capable of single transactions, whereas the AXI4 master is capable of single and
burst transactions, which improve the general performance. Slave registers pro-
vide status, control bits, and the input data. In every RTR system, the initial
state in the RP is unknown after reconfiguration, so a software reset is needed
to reset the function loaded in the partition. This requirement is a design chal-
lenge because the context of the process (e.g., status bits, results) must be saved
between reconfigurations, whereas using the global reset resets the whole system.
The execution-and-decoupling module disengages the outputs of the RP during re-
configuration (recommended in any reconfigurable system) and controls the start
of execution. Finally, the first input first output (FIFO) module holds results, and
works as a built-in buffer for inter-process communication, decoupling in streaming
models, and context switching. This summary describes the main components that
enable hardware and configware (CW). In addition, a software structure is also
required to control the platform during run time.
Software Figure 3.5 describes the abstraction layer stack and the supporting
application programming interface (API) functions. As other SoCs, the abstraction
layer includes the HW components in the lower level, whereas drivers, libraries and
API in higher levels. The left side shows the layers generated by vendor tools are
identified, i.e., (Xilinx) Board Support Package (BSP). The right side shows the
equivalent layers that were developed for the reconfigurable features. The API
functions are divided into two types, reconfiguration and transaction. First, the
AXI4-LITE
AXI 4
single AXI4-Lite Slave IPIF AXI4 Burst Master IPIF single & A
transactions burst
transactions A
Slave Regs up to 256 A A
Master IPIC
Slave IPIC
Master Regs
Ctrl A
Status clk Burst & Cmd
DataIn Control
ExeT ain
RP
read
reset Result
after Soft
Extra result dout
reconfiguration Reset
soft reset
exe time
exe_ena fifo_empty
Exec & fifo_full FIFO
De- fifo_ena write
coupling
decouples
RP output
during PR
RP results
simple I/O, inter-process communication
increment decoupling in streaming models,
reuse & flexibility RTR context switching.
Figure 3.4: The RecoBlock RTR IP-core. The Reconfigurable Partition (RP) is the only reconfig-
urable region, the rest are part of the static region [Paper I].
reconfiguration oriented control features like software reset, execution start, and
load configuration. Secondly, the transaction-oriented which control data movement
between RecoBlocks and memory. Using this layer, the configurable links and array
structure are actually defined. Transactions can be single between two RecoBlocks
and either single or burst between one RecoBlock and memory.
Design Flow Xilinx offers a design flow for embedded systems development [61]
and another for reconfiguration [59] [62], however, they are not tailored for any
custom platform and particularly they are not aware of specific features such as
in the RecoBlock platform and IP-core. Therefore, a reliable design flow for the
RecoBlock concept has been identified and organized based on Xilinx tools and is
depicted in Figure 3.6. Finding an adequate design flow can be compared to a
puzzle, most of the pieces are hopefully provided by the company, but they are not
aware of the custom RecoBlock platform.
The center regions in Figure 3.6 show the design flow for the reconfigurable sys-
tem designer. On the left area, is the system-level design model where the project
specification starts (this area is suggested for implementation, Matlab models have
been used in later publications). First, on (Xilinx) Xilinx Platform Studio (XPS)
the basic RecoBlock Platform project is open and depending on the system require-
ments in the high-level model, more RecoBlocks can be added from IP library, and
AXI connections are established . The XML description of the complete system is
generated and taken to the software flow. Then in (Xilinx) Software Development
Figure 3.5: Abstraction layer stack (software, hardware, configware). Abstraction layer and types
of RecoBlock IP-core transactions.
Kit (SDK), the libraries and drivers are generated as a BSP. A new application in
C is created based on this BSP, and the software functions are imported from the
RecoBlock API.
While the application is running and a reconfiguration is started by one of the
API functions, a partial reconfiguration file is taken from the library, parsed, and
downloaded to the specified RecoBlock. Further details of this Design flow are
presented in [Paper I] and [Paper II]
Case Study One of the aims of this work is to enable flexibility and reusability in
run-time reconfigurable architectures. These characteristics are evaluated through
the case study illustrated in Figure 3.7. The RecoBlock platform is used to imple-
ment a model of function adaptivity [48] [67], which abstracts an encoder-decoder
streaming application. In summary, there are four processes in the model, Source
process (S), destination process (D), encoder (P0 ), and decoder (P1 ). S and D are
implemented by software that runs on CPU. P0 and P1 are implemented by run-time
reconfiguration in two RecoBlock IP-cores. Data is sent from S to D, but in the
trajectory, data is encoded and the decoded in P0 and P1 respectively. Since data
rates can be different, decoupling buffers FS and FD are required. The buffer F01
in the middle alleviates interprocess communication. F01 and FD are implemented
with the built-in FIFO in both IP-core. FS is implemented in the Synchronous
Dynamic Random Access Memory (SDRAM) memory. Several encoder e() and
MODEL-OF-COMPUTATION SOFTWARE-DEVELOPMENT-KIT FLOW PLATFORM-STUDIO FLOW PLAN-AHEAD FLOW

Idea
HW SW
Abstract Model
Refined SDF
Reconfigurable
PA
Partitions
Define Reconfig. (RPs of RcBks)
Management # of RcBk and connections
RcBk IP RcBk
ARCHITECTURE
(Library) Platform Read Netlist
RcBk
A
SDK XPS
A
SCHEDULE Arch. & Schedule RcBk API
.xml
Set Partitions
Static Regions A A
Information (Basic Arch.) A
Generate
.ngc Define
Netlist
Strategies
Create BSP
BSP (lib&drivers) RP of RcBk Create

.ngc
RM
without functionality,
Develop as Black Boxes
Application Create
Configurations Functionality
Debug .elf
(runs) defined
Program for RP of RcBk
FPGA RP new functions
download.bit Generate
(static + partial) Netlist (.vhd) Verified &
synthesized
RUN-TIME Running APP Implement

.elf (software)
...
RTR CF
MB MEM download.bit
requested Mem
(static + initial
| newly generated
configuration) SysAce functions
RTR |
(RcBk) .bit HWICAP Function library .bit (partial)
(partial reconfig) ...
Figure 3.6: Basic RecoBlock Design Flow. Tools domains are vertical. Central and Run-Time
sections describe the straightforward flows to reuse the platform. Right section belongs to the
offline recurrent flow when configurations are not in library. Upper-left section is a recommended
Function librarydesign
(.bit ) + entry [Paper I]. A complementary design flow is presented in [Paper II].
Intitial configuration (download.bit)
Straightforward Recurrent / Manual
RcBk System & Application Generation Only for new configurations
decoder d() functions can be applied. In this application, function adaptivity is not
realized by setting control bits, changing input variables, or switching circuits, but
with actual hardware run-time reconfiguration. During implementation, process P0
and P1 are mapped into RPs in two RecoBlock IP-cores. Buffers are mapped into
built-in buffers in the IP-cores or standard memory buffers in SDRAM. Finally, S
and D are mapped to MicroBlaze.
The Experiments implement the encoder-decoder application using two Re-
coBlocks and several pairs of encoder-decoder functions [Paper I]. The flexibility
of the array is demonstrated in each experiment that combines a reconfiguration
schedule with an architecture array, i.e., spatial or phased. Spatial and phased
are typical structures in reconfigurable computing [21]. Spatial uses independent
resources for each function, whereas phased optimizes space by multiplexing the
execution in time. Phased uses less number of resources but requires methods to
save the context of current execution for the next one; it, therefore, shows the
context-switch capability.
Function Adaptivity Model: An encoder – decoder application
Interprocces Communication / Domain Interface

Implemented as: RcBk Buffer , or AXI memory
(SDRAM)
Adaptive encoder, e()
functions. Adaptive decoder, d() functions.
Implemented in the RP Implemented in the RP
Figure 3.7: Case study: A function adaptivity model implemented on RecoBlock. An encoder-
decoder application where there are four processes in the model, source (S), destination (D),
encoder (P0 ), and decoder (P1 ). S and D are implemented by software that runs on CPU. P0 and
Case Study :
P1 are implemented by run-time reconfiguration
Test in two RecoBlock IP-cores, where several encoder
Driving Flexibility-Reusability
e() and decoder d() functions can be reconfigured. The experiments combine some reconfiguration
schedules with architecture arrays i.e., spatial or phased. Phased uses only one RecoBlock and
requires contex-switching [Paper I].
Results Overview
In Paper I the reader can found extended information about the following results.
(1) The physical layout of the FPGA after generation of partial configurations in
PlanAhead [62]. (2) Size and resources assigned to each RP also known as pblock
in PlanAhead terminology. (3) Resource utilization (i.e., FFD, LUTs, DSP48E1) of
each encoder and decoder function compared to the RP. (4) Maximum supported
frequency Fmax without slack after implementation in PlanAhead. (5) Reconfigu-
ration time for each experiment of the case study, and size of bitstream files.
3.1.4 Conclusion
To conclude, this section summarized Paper I and introduced a simplified approach
to design run- time reconfigurable systems. Paper I presented the design of the
flexible and reusable RecoBlock SoC Platform characterized mainly by RTR (plug-
and-play) IP-cores, functions loaded at run-time from the library, inter-block com-
munication configured by SW, and built-in buffers for data-driven, interprocess
communication, and context-switching. This work also identified a suitable design
flow, proved flexibility and reusability using a case study of function adaptivity
that combines different encoder and decoder functions, arrays, and schedules that
are reconfigured at run time.
Based on literature research and hands-on experience, this work also defined
a set of recommendations to improve flexibility and reusability and used them to
implement the RecoBlock Concept. The case study verifies the concept and conse-
quently confirms these recommendations. For instance, an IP-core with embedded
Reconfigurable Partition (RP) increases flexibility and reusability, since the same
IP-core is reused to instantiate several RecoBlocks whose functions are not static
but flexible due to RTR. Similarly, fixed I/O interfaces in RP improve reusability
since it facilitates the relocation of the same function to another RecoBlock (al-
though independent reconfigurations are needed for each RecoBlock). The custom
configuration interconnection fabric provides links reconfigurable by software and,
therefore, enables a reconfigurable architecture array, as the case study demon-
strated.
Through the entire investigation consolidated in this thesis, these recommen-
dations were also validated and extended in different realms. For instance, after
concluding Paper V the author considers that by providing learning capability to an
adaptive embedded system, this system can take decisions not even programmed.
Therefore, learning could increase flexibility and reusability since it reduces the
code required for decision making (decide phase) and reuses the rest of the code
that executes functions (act phase), all in different, unexpected situations.
This section summarized the initial state of the RecoBlock concept presented
with detail in Paper I. Chapter 5 provides a summary of the final state. Details of
all incremental enhancements can be found in the papers reprinted in Part II.
3.2 RecoBlock Design Flow for Algorithm Modeling and

Acceleration in a Standard RTR IP-core
This section introduces the research in Paper II, which describes the investigation
to find the architecture of an ideal universal and standard RTR accelerator for SoCs
and the method to develop algorithms and generate reconfiguration bitstreams for
this accelerator. At the same time, looking forward to reusability, model and system
verification, and low-cost solutions.
Motivation
3.2.1 Motivation
In the
FUTURE OF HETEROGENEOUS COMPUTING
SMP MULTIPROCESSING + A SMP MULTIPROCESSING + 100 A
P P P P P
RP RP
100 10
RP
P P P
RP RP
P P
P P P
A A A
1 A A A A
100
A A A
UNLIKELY MORE SUSTAINTABLE
Figure 3.8: The future of Heterogeneous Computing. Personal high-performance computing is

near and becoming affordable. A hundred of accelerator cores with a dozen of CPU cores is the
most sustainable scenario
The question in this paper was how good can the performance of the RecoBlock
SoC platform be as HW accelerator in terms of speed-up and bandwidth?. In that
sense, the work in Paper II might be a test drive of the RecoBlock SoC platform
for high performance computing.
Consequently, some improvements were needed before answering this question
since Paper I demonstrated the RecoBlock concept to load functions and to assemble
architectures, but the library of reconfigurations had simple mathematical and logic
functions, which were useful for demonstrative purposes but not for generating
computational load.
Therefore, an improved but economical method to create configurations for com-
plex algorithms described and verified on high-level models was required. Besides,
3.2. RECOBLOCK DESIGN FLOW FOR ALGORITHM MODELING AND ACCELERATION IN A STANDARD RTR
IP-CORE 43
the IP-core architecture had to be revised for enabling this new approach and en-
hancing the synchronization and execution mechanism from software.
The research in Paper II is also important in an era of omnipresent multi-
core heterogeneous embedded systems is becoming real. As Figure 3.8 illustrates,
Hartenstein argues that the personal supercomputer is near [20], high-performance
computing (HPC) is becoming affordable and feasible [19]. We already have in
our mobile devices the computational power of supercomputers from last decades.
Additionally, in a heterogeneous computing survey [8], authors predicted that the
efficient use of symmetric multiprocessing is unlikely. But, a hundred of accelerator
cores with a dozen of CPU cores is a more sustainable scenario. This prediction
can bring another question: Does the industry need to redesign the hardware and
software of hundreds of accelerators for each application? What if the cores could
additionally be RTR?
Thus, combining run-time reconfigurability and high performance in multicore
embedded systems will dramatically increase their chances of success, market flex-
ibility, and durability. Besides, this will enable a dream of self-organizing, cooper-
ative, and high-performance cores, which is envisioned in this thesis.
Figure 3.9: The importance of a universal IP-core
To illustrate the importance of a generic accelerator, a RTR SoC can not be seen
anymore as blank chips where the whole space is used to accelerate one algorithm.
New challenges arise when a heterogeneous RTR SoC is implemented in an FPGA,
where functionalities in the IP-cores can be switched in and out at request. As
Figure 3.9 illustrates, one of the main problems is that classic approaches tend to
increase the design complexity, design time, and resources and reduce reusability,
maintainability, and portability. But in RTR design there may be a more important
reason, which is relocation. Without standardization of input and outputs (I/O),
relocation becomes highly improbable. Figure 3.9 explains one of the reasons to
look forward a single one-fit-all IP-core.
3.2.2 Challenges
The feedback received about Paper I motivated the investigation conducted in
Challenges in this paper
Paper II, which aims at answering the research questions illustrated in Figure 3.10.
The challenges associated with these issues are briefly discussed in the following
paragraphs.
1. ALGORITHM DEVELOMPENT
2. ONE-FIT-ALL RCBK ARCHITECTURE
How to develop
algorithms that can be How CAN the same IP (HW + SW)
economically and easily EFFICIENTLY hold the • HLS is ONLY one
step in the process
RP RP ported to a RTR SoC, reconfigurations of a • RTR is complex, so
RP enabling verification ? high variety of BLIND
RP RP ISSUES implementation is
HLS complex algorithms ?
CHALLENGES FIR NOT SAFE
QUESTIONS
KALMAN • differe
differe
• withou
3. PERFORMANCE - SPEEDUP & THROUGHPUT AES Reusa
How GOOD is the Maint
X RecoBlock as RTR +
What is the effect of ACCELERATOR ?
its iP architecture ? No benchamarks in RTR How to measure
No standar methodsFigure3.10: Challenges regarding algorithm development, a one-fit-all IP-core architecture, performance
and ? - No
performance analysis, which are addressed in Paper II
benchamarks in RTR
- no standar methods
First, when accelerating complex algorithms in FPGAs and the goal is to find a
reusable method targeting a custom partial and RTR core, the traditional require-
ment of a description in a high-level language and a High-level Synthesis (HLS)
tool is shifted to a secondary plane. It seems hard to believe, given the availability
of complex algorithms already described in C or HDL and the current research
and industry interest in HLS. The problem is that HLS tools do not and could
not be aware of specific architectural requirements of every design and particularly
of RTR design constraints. Additionally, algorithm verification is not always per-
formed, and in the best case is done at high levels, in general, sometimes from
other parties, or without architectural details. Another concern is the complexity
and extended time required to generate partial reconfigurations (e.g., 30 to 50 min-
utes). Therefore, in this scenario, it is not wise to start the generation process of a
partial reconfiguration just to discover that once it is loaded in the RTR core, the
functionality is not what was expected.
Secondly, regarding the IP-core architecture, this work realized that the config-
urations need to comply with the RecoBlock architecture and particularly with the
RP interface to facilitate the relocation but simultaneously be flexible enough to
accept different algorithms with different I/O specifications. Additionally, the de-
velopment method has to be repeatable and use available HLS tools to facilitate the
adoption of other researchers, since the generation of configuration is complex by
itself. To exemplify the reason for this architectural concern, let’s cite the challenge
of I/O interfaces in RTR design. Given that every algorithm has its requirement of
number and size of input variables and output variables (e.g., f (x, y) = (a, b, c)),
IP-CORE 45
each RP in the IP-core would require that specific I/O configuration. To load a
different reconfiguration during run-time, the I/O settings for the function and RP
should match. With this premise, designers would need to create a different IP-
core and partial reconfiguration for every function. Thus, this approach without
a standard interface would escalate the design complexity, resources needed, and
lead us to early years of FPGA designs.
Finally, no standard benchmarking tools are available for conducting perfor-
mance analysis in reconfigurable computing or RTR. Therefore, the architecture
must be first analyzed as a reconfigurable computing architecture to identify se-
quential phases involved in reconfiguration and algorithm execution. These phases
determine the overall acceleration performance following Amdahl’s laws. Addi-
tionally, custom instrumentation methods are required, at least time measurement
functions.
3.2.3 Idea
This work proposes that the answer to the first two challenges exists but there is
not a way to connect and unify the existing flows. Figure 3.11 shows individual
development flows that exist today but cover part of the whole process. There are
tools for modeling, hardware and software co-design, and configware design. How-
ever, two issues avoid their utilization, first they are not connected and secondly,
they are not aware of the custom reconfigurable architectures. Hence, this lost link
is based on a revised RecoBlock IP-core architecture that combines the existing
flows as Figure 3.11 shows.
UNLINKED FLOWS … A LINK
… the solution is

maybe already there
MODELING
HL
SYSTEM DESIGN
MODELING
HLS HW/SW CODESING
RP RP
HARDWARE SOFTWARE HARDWARE RP
SOC SOFTWARE RP RP
IMPROVED
RECOBLOCK
CONFIGWARE
TEST CONFIGWARE
VECTORS FPGA
Figure 3.11: Unconnected flows in RTR SoC design. Individual development flows that exist
today but cover part of the whole process. They are not connected and are not aware of custom
reconfigurable architectures such as the RTR RecoBlock IP-core
For instance Regarding HLS and HW-SW co-design, Matlab tools for HW and
SW code generation, i.e., HDL coder and Matlab coder respectively, provide au-
tomated flows for a limited set of third-party FPGA boards [24]. Most of these
boards run C code implemented in an embedded processor or HDL code into stan-
dalone FPGA boards, in the best case. Only during last years, tools are gradually
adding support to some SoC implementations [58]. However, there is still not total
support for RTR systems and particularly for custom modular designs based on
multiple RTR IP Cores, such as the RecoBlock concept Paper II. On the other
hand, during the configware flow, the VHDL description should be first merged
with the reusable static part of the IP-core architecture before the partial reconfig-
urations can be generated. Besides, verification and test-vectors generation since
modeling stages until onboard test will avoid disappointing surprises when the re-
configuration has been created after a long process, but its behavior does not match
the original algorithm. To clarify, using HLS tools to generate VHDL files for the
RecoBlock platform might look like a straightforward solution. However, it is far
from simple. Although there is much interest in developing High-level Synthesis
(HLS), few of them are reliable. However, most importantly, HLS covers only one
stage of the design process.
In summary, generating reconfigurations from complex algorithms is a complex
process. Hence, flexibility, reusability, portability, verification must be considered
at all times. For a successful utilization of the RecoBlock IP-core for acceleration
of complex algorithms, HW, SW, CW, and even test vectors need to be generated
using different tools. The following sections introduces the devised development
flow and the modified IP-core, which are thoroughly presented in Paper II.
3.2.4 Summary
Algorithm Development Flow
ALGORITHM DEVELOPMENT
fx.m MATLAB
& IP GENERATION
fx_tb.m
HARDWARE
fx.vhd MODELING
HDL CODER
RP RP
IP RP
RecoBlock RP RP
Template MATLAB CODER
rp.vhd IP-LIB core.vhd
*.c
fx.vhd user.vhd
*.h
PLATFORM SOFTWARE
SYSTEM INTEGRATION
ISE XPS Template main.c
*.xml
RTR SOC
rp_fx.ngc *.ngc *.c

*.h
SDK API
download.bit
PLANAHEAD download.bit + .elf

rp_fx.bit
CONFIGWARE
RECO PLATFORM
Figure 3.12: Simplified flow for algorithm and reconfiguration development in RTR RecoBlock
IP-core. The modified IP-core, with an additional layer structure, unifies the flows and allow the
algorithm (fx) transformation from model to bitstream file while keeping the execution logic and
the rest of the IP-core constant for all algorithms
The devised development flow uses COTS tools to encourage the adoption of
IP-CORE 47
RTR and avoid dealing with the lack of support when using open source solutions.
The flow uses Xilinx and Mathworks tools, but the concept could be generalized.
Detailed information is found in Paper II.
The algorithm, named fx for simplicity, is described, simulated and verified in
Matlab. HDL coder [24] performs automatic verification and generates the HDL
description. Matlab Coder creates the C description that becomes useful to run the
algorithm on the embedded processor. In this way, the application designer can
choose to run the same algorithm whether on CPU (software) or in RecoBlock core
(hardware) while still being able to correlate results using the same test vectors.
The key in this unified flow is how the IP-core is transformed along different tools
in this production line, enabled by the new layer structure. In VHDL abstraction,
the IP-core has now four layers core (AXI interfaces), user (user registers, buffer),
rp (the partial reconfiguration partition) and fx (the algorithm obtained from HDL
coder) The innovation is the sublayer (fx.vhd) which separates the algorithm from
the rest of the execution logic (fire-generator) that is kept constant although lays in
the RP logic. Figure 3.12 shows how this fx description is processed, it is wrapped
with the rp file, and it then is converted into netlist files and later in a bitstream
file. The other two layers (core and user) represent the custom IP-core available in
XPS IP library and which remains constant for any algorithm. A semi-automated
script helps to process these files.
Searching for the One-fit-all IP-core Architecture

The importance of designing a universal accelerator for a RTR SoC was illustrated in
Figure 3.9. The following paragraphs summarize the development of this solution
that starts by solving the challenge to match the register transfer level (RTL)
architecture generated from a HLS tool with the RecoBlock architecture. They then
summarize improvements in the core structure, RP interfaces, and API functions.
Extended information is presented in Paper II.
Classical HLS methods to implement algorithms in FPGA use a RTL data-
processing architecture consisting of a data-path or processing element that per-
forms operations, a control-path or state machine that transfer data from-to mem-
ory and synchronize the execution in the data-path, and a memory to hold input
and output data.
The simplest solution to transfer this architecture to the RecoBlock core would
attempt to directly place these components, inside the core. However, the question
is where in the core, inside the RP, outside the RP. Any decision, affects the
portability, flexibility, and even would require other AXI slave and master registers,
memory specifications, or access to external memory.
In the proposed solution illustrated in Figure 3.13, the fire-generator (equivalent
to control-path) and the fx-container (equivalent to data-path ) are placed inside
the RP layer. The former remains constant for all algorithms, and the latter is
variable. The memory is implemented with the built-in FIFO or in a larger system
memory accessed via AXI interface and software control. The fx-container holds the
actual algorithm and is the only part extracted from HDL Coder [24], the rest (e.g.
control-path, memory) are not suitable for a SoC environment and are dropped or
replaced withOne-fit-all
custom components (e.g., fire-generator,
RecoBlock architecturebuilt-in FIFO). No DMA is
enabled to avoid memory contention, race conditions, arbitration and scheduling
problems.
CONSTANT: to increase HW/SW
reusability and maintainability
fx.m
AXI4-Lite AXI4 Burst
Slave IPIF Master IPIF
rB_FireClk(RCBK2);
I/O compatible
Master Regs with Matlab
Slave Regs function and
Burst & Cmd
Control
RP RcBk2
FIFO
clk fifo_wr
clk_fsm fire_clk INV
trig
Soft Reset trg_fsm
reset y_out(31:0)
rst_fsm
RcBk2 IP-CORE ACCELERATOR
FIRE-GENERATOR
RCBK2-IP “The Function Container” x_in(31:0)

x_in(31:0)
• New RecoBlock 2 Architecture clk y_out(31:0)
– FX-BOX holds the function Vcc clk_enable ce_out
– FIRE-GENERATOR is a SW triggered INV reset
and programmable clock pulse FX-BOX
RP-WRAPPER
Figure 3.13: The RecoBlock IP-core as an universal function container. The Reconfigurable
Partition (RP) is now a wrapper that holds the FX-box that contains the actual algorithm, an
I/O interface compatible with Matlab model and RecoBlock, and the Fire-generator that allows
synchronization and execution controlled by software.
The fire-generator is a programmable timing logic controlled by software so that

the application programmer can trigger the execution of combinatorial or sequential
algorithms. Sequential algorithms process data at system clock frequency. The fire-
generator is not a clock source, is common for all algorithms and is therefore placed
in the non-static region (RP)
The number and size of data ports is an important topic of discussion. On
one hand, they reduce reusability but, on the contrary, they must match specific
port requirements of each algorithm. This work proposes the adoption of single
ports with standard bit size, in order to solve this critical issue. In this regard, the
serialization and de-serialization process can be moved to upper abstraction layers
or also accelerated in the core. Successful serial standards such as Universal Serial
Bus (USB) or Serial Peripheral Interface (SPI) use a similar single-port approach.
In this thesis, data ports are fixed to a single input and output ports of 32-bit wide
to increase reusability and promote relocation.
The cost of design time and maintenance is also high for embedded SW (Fig-
ure 3.9). Creating particular functions for each type of core, algorithm, or feature
does not increase portability. Hence, the drivers and API functions are re-designed,
compared to Paper I, so that a single set of drivers and functions is used for any
instantiated RecoBlock IP-core and independently of the algorithm. The unified
IP-CORE 49
API consist of only 4 files (*.c and *.h) and the Xilinx generated xparameters.h.
In this way, the application programmer reuses the same functions to control hard-
ware features such as software-reset, algorithm execution, data write and read,
burst read, timer stamps for performance analysis, and run-time reconfiguration as
well. Further details are described in Paper II.
Reconfiguration and Prefetch

The library of partial-reconfigurations is placed in non-volatile memory such as a
CF. The access time of CF memories increases the reconfiguration time, which is
also determined by the ICAP controller and the parsing phase that reads, filters
and interpret the contents of the bitstream files.
Hence, this work improves the RTR time by implementing a reconfiguration
pre-fetch technique, which uses the DDR3 memory as a fast access buffer to hold
a previously parsed bitstream so that the software overhead is reduced. During
boot time, all the partial reconfiguration files are read, parsed, and headers or non-
relevant information included by the Xilinx SysACE FAT16 file format are removed.
Only the useful bit-stream data is stored in a DDR3 buffer. During run time and
triggered by an API function, the effective bitstream is loaded from DDR3 to the
FPGA Configuration Memory (CM), through the Internal Configuration Access
Port (ICAP) controller. This pre-fetch method considerably improves the recon-
figuration performance as shown in Paper II. API functions are created to control
all possible data movements governing normal or pre-fetched reconfiguration, i.e.,
from CF to ICAP, from CF to DDR3, and from DDR3 to ICAP.
Algorithm Execution in IP-core Based Reconfigurable Architecture

The RecoBlock IP-core and platform can be seen as a special Reconfigurable Com-
puting Architecture or Processing Element (PE). Therefore, this work first analyzes
the phases or sequential segments involved in the algorithm execution, to analyze
its performance. As a custom architecture, there is so far no similar analysis for a
RTR IP-core based design.
According to Amdahl’s Law, the overall application speedup is limited by the
sequential segments of the code, which are not non-parallelized [46]. The algorithm
execution in the hardware RecoBlock is an implicit method of parallelization using
FPGA logic. Then, the speedup is yet influenced by the other sequential segments.
Data has to be moved in an out the core, and the reconfiguration time becomes
another segment for analysis of reconfigurable accelerators.
Figure 3.14 reproduces the analysis of algorithm execution in RecoBlock con-
ducted in Paper II. The whole SoC platform can be visualized as a partition of
two flows or paths, the control-path and the data-path (using RTL terminology)
and the additional reconfiguration flow in a RTR SoC. The (1) Control Path in-
cludes the embedded processor MicroBlaze, control and slave status registers, the
fire-generator (FIRE), and SW layers (drivers, API, and application). The (2) Data
One-fit-all RecoBlock architecture
FX Execution Phases in a RTR SoC

CONF
BS
APPLIC
Yout[ ]
0
Xin[ ]
SDRAM
API CONFIG ICAP
DDR3
DRIVERS BS
3 CM
1 0
ICAP
2
CTRL FIRE
STAT
FIFO
MICROBLAZE DIN FX CM
DOUT
RP-WRAPPER
CONTROL PATH
DATA PATH IP-CORE ACCELERATOR
RECONFIGURATION PATH
PHASES
tRTR TET
PHASES OF PH0 PH1 PH2 PH3 ORIGINAL
ALGORITHM
EXECUTION PH0 PH1 PH2 PH3 ACCELERATED
SEGMENTS OF
SEQUENTIAL CODE RTR WR EXE RD
Figure 3.14: Abstract view of the RTR RecoBlock SoC as reconfigurable computing architec-
ture. The SoC can be visualized as a partition of three flows or paths, i.e., control, data, and
reconfiguration path. For performance analysis, the algorithm execution is decomposed in phases
or sequential segments, i.e., reconfiguration of algorithm bitstream in IP-core (RTR), write data
(WR), execution in IP-core (EXE), read results (RD).
Path includes source (Xin[ ]) and destination (Yout[ ]) arrays in SDRAM that holds
the input and output data stream, the data input (DIN) and output (DOUT) slave
registers, the algorithm holder (FX) and the inter-process communication (FIFO).
Finally, (3) the Reconfiguration Path includes the pre-fetched buffer (CONFIG
BS), the internal configuration access port (ICAP), and the FPGA Configuration
Memory (CM). This analysis is fundamental to conduct performance analysis.
Performance in RTR system

The overall performance of the RecoBlock SoC is determined by each of the phases
shown in Figure 3.14, that is, the efficacy to load a new reconfiguration, transfer
data, and execute an algorithm. In that sense, the RecoBlock is designed with a
built-in mechanism to improve or accelerate three critical phases, i.e., (1) recon-
figuration improved by pre-fetch (phase 0), (2) algorithm execution improved by
HW acceleration in IP-core (phase 2), and (3) communication improved by FIFO’s
burst read transfers (phase 3). Given the novel characteristic of the RecoBlock ap-
proach and lack of standard benchmarking tools for RTR, which also affects similar
reconfigurable systems, this work first devised the formulas that characterize the
performance metrics of this particular RTR RecoBlock SoC.
Paper II evaluates the performance of the RecoBlock SoC platform as a hardware
acceleration system based on RTR IP-cores, using the implementation described
in Paper II. Two algorithms (i.e., FIR and Kalman filter) were executed in two
IP-CORE 51
different targets (DUT), the MicroBlaze and the RecoBlock IP-core. It also verifies
the influence that burst transfers, reconfiguration pre-fetch, and type of IP-core
implementation (reconfigurable or non-reconfigurable) have over performance. In
summary, the results show that: The speedup and throughput increase is both 2x
when burst reads are used. The total speedup (including acceleration and burst
reads) ranges from 2 to 3 orders of magnitude compared to execution in MicroBlaze
soft processor. The speedup originated by burst reads increases according to the size
of data. The reconfiguration pre-fetch improves the RTR time with 80%. (speedup
is 5x compared to direct reconfiguration from CF memory). Moreover, finally, the
acceleration is greatly affected by the sequential calls to the phases of algorithm
execution and the SW overhead. Further details are presented in Paper II.
3.2.5 Conclusion
This section introduced the research in Paper II, which presents a methodology
to develop and verify complex algorithms and to generate a highly generic RTR
IP-Cores to accelerate them. The accelerators can also be used as static non-RTR
functions. It increases controllability and enables data-flow driven execution, re-
location, reuse, and portability, almost independently of the accelerated function.
The workflow uses common access tools with good cost-performance trade-off. Ex-
periments show total speedups ranging from 2 up to 3 orders of magnitude compared
to soft processor execution.
Chapter 4
Self-healing Run-time
Reconfigurable Fault-tolerance
This chapter introduces the concept of self-healing adaptive RTR Fault-

tolerance, which is developed in Paper III and implemented in Paper IV.
This concept is a new perspective on the dependability improvement in
FPGA-based systems by exploiting the flexibility and scalability of exist-
ing RTR IP-cores of a system to assemble TMR schemes during run-
time. This group of cores behaves cooperatively to make hardware accel-
erated functions fault tolerant, for that they can self-assemble, self-test,
self-heal (repair or replace).
In the beginning, this chapter presents a motivation for this research.
It then brings awareness of the issues of scalability, reusability, and
performance-cost ratio when using hardware redundancy and RTR to
increase dependability. The chapter then summarizes how this concept
was implemented by strategically reusing the available RTR IP-cores, the
challenges, and contributions derived from this. Particularly it explains
the basis of RTR FT schemes and the Upset-Fault-Observer (UFO) con-
cept. Lastly, this chapter briefly concludes and present related concerns.
"The fossil record implies trial and error, the inability to anticipate
the future, features inconsistent with a Great Designer (though not a
Designer of a more remote and indirect temperament.)"
Carl Sagan (Cosmos)
53
54 CHAPTER 4. SELF-HEALING RUN-TIME RECONFIGURABLE FAULT-TOLERANCE
4.1 Motivation
A system can be highly reliable but still not capable to tolerate, mask, or recover
when faults occur. Hence, fault-tolerance is important even when current FPGA
fabrication is highly reliable. This section introduces the idea of having a group
of reconfigurable cores that self-organize during run-time to create hardware re-
dundant structures and consequently to provide fault-tolerance to the functions
accelerated on those cores. This dynamically reconfigurable structures are called
run-time reconfigurable (RTR) FT schemes [Paper III] [Paper IV], or alternatively
dynamic fault-tolerance (dynFT). The Upset-Fault-Observer (UFO) is an advanced
case of the concept of dynFT.
This approach is the first step to enable the design of systems that overcome the
scalability cost of hardware redundancy and adaptively trigger the best self-healing
strategy according to execution environment metrics or mission state. The impor-
tance of this kind of systems was illustrated in Chapter 1 (Figure 1.1). SEUs are bit-
fluctuations in configuration memory of SRAM-based FPGAs where their logic and
interconnections are defined. SEUs are not considered a permanent fault but repre-
sents an dependability issue. In such a scenario, if cosmic radiation produces SEUs
in the configuration memory of the FPGA-based on-board computer and without
earth control, the computer must adaptively select the best FT structure that pro-
duce optimal energy and resource consumption. This sort of self-optimization could
not be enabled with classical rigid FT structures such as those shown in Figure 4.1,
which in the best case would allow reconfiguration of the function but not of the
structure itself.
4.2 Challenges
As stated in Chapter 1, the dependability of computing systems has received an
increased interest during the last years due to issues carried out by integration
technology reaching atomic scales or problems affecting specific technologies such
as FPGA. Besides, embedded systems are becoming drastically immersed in life-
critical applications. At atomic scales, logic states will be stored in smaller tran-
sistors. With fewer atoms available, bits of information will become less stable
during lifetime, and fabrication defects will yield less reliable chips. Cosmic, at-
mospheric and electromagnetic radiation can produce SEUs in system memories
and configuration memories of FPGA. Design complexity and human errors may
also increase failure rates. Therefore, dependability or the ability of a system to
deliver its intended level of service in the presence of faults [11] is every day more
necessary.
State-of-the-art studies in fault-tolerance design also expose some issues. Among
other FT design techniques, a combination of hardware redundancy and RTR is typ-
ically applied at different granularity and abstraction levels (e.g., from gate level to
component or even board level). As illustrated in Figure 4.1, most states of the art
Trends in Fault tolerance
4.3. SOLUTION OVERVIEW
(Hardware redundancy + Reconfiguration)
55
a v d v
a v d v
a v d v V
c v
c v
b v
a d c v
b v
c IC 1 IC 2 IC 3
b v
b
(a) Fine-grained hardware redundancy (b) Board or component level redundancy

(transistor, gate)
CPU MEMORY ICAP

System
PLB INTERCONNECT
a v
In a
a
v
v
Out Reconfigurable ADDRESS INTERRUPT MUX Fault Tolerant
c v
v
c v Region Controller
c v
b
b
v
v
FT MODE VOTER STATUS
Partial
CONTROL LOGIC ICAP PR 1 PR 2 PR 3 Reconfigurable
Regions
(c) Application specific designs with fixed buses, (d) Partial RTR FPGA SoC.
no processor, maybe reconfigurable But, fixed PR structure and FT logic
Problem: Poor scalability, programmability, low reusability, small performance-cost ratio e.g., area, power, resources
Figure 4.1: Issues in fault-tolerant approaches that combine hardware redundancy and run-time
reconfiguration. In summary, there is poor scalability, low programmability, low reusability, and
small performance-cost ratio.
approaches succeed in their purposes, but they ignore the implications mentioned
above of integration scales. Furthermore, they fail to consider that application
specific designs with fixed buses have poor scalability and programmability, board
or component approaches have low performance compared to power and area uti-
lization, or designs exploiting RTR regions to create modular redundancy are yet
rigid since they offer function reconfiguration but not FT structure reconfiguration.
These technological and design issues demand paradigm shifts, e.g., life-time man-
agement of fabrication defects and variability of logic states, embedded test, on-line
monitoring, post-fabrication reconfigurability [10]
4.3 Solution Overview

By following the same design principles towards flexibility, reusability, and econ-
omy adopted in Chapter 3, Paper I and Paper II; the solution on dependability
presented in this chapter started by investigating whether a creative way of reusing
the existing RTR IP-cores in the RecoBlock platform to improve fault tolerance
can be devised. This solution should simultaneously reduce the design and im-
plementation cost of traditional solutions based on RTR. What about replicating
the accelerated functions in other available cores so that hardware redundancy is
dynamically created? If not evident, one of the advantages of this approach is that
Hardware Duplication
Accelerated TMR TMR With Comparison
Functions with-spare (DWC)
RTR IP-cores
MEMORY CPU F G H MEMORY CPU F G H
MEMORY ICAP MEMORY ICAP F G H
I/O I/O I/O I/O F G
INTERCONNECT INTERCONNECT S
(a) (b)
Figure 4.2: Reconfigurable TMR schemes based on RTR IP-cores. In (a), a FPGA-based SoC
with RTR IP-cores. Functions F,G, and H are accelerated in hardware but they are not fault-
tolerant. (b) Reconfigurable fault-tolerant schemes can be strategically assembled during run-time
to provide fault-tolerance to those functions, i.e., Triple-Modular Redundancy (TMR), TMR-with-
spare (TMRwS), and DwC. An economic scheme (DWC) can be selected to optimize resources
and performance, although fault-tolerance is decreased (i.e., detect only). TMRwS provides better
fault-tolerance (i.e., locate , repair, and replace), but consumes more resources.
FT schemes such as TMR can be assembled or disassembled at will according to

available resources and performance states. In addition, neither hardware redesign
nor implementation is required. As long as partial reconfiguration bitstream files
and enough number of RTR IP-cores are available, the complete implementation is
mainly based on software. This approach is arguably game-changing. Therefore, to
address the challenges mentioned above this work starts by proposing a solution:
Reconfigurable TMR Schemes based on RTR IP-cores: In a given

FPGA-based SoC whose critical functions or subsystems are accelerated
in RTR IP-cores e.g., RecoBlock, each core can be dynamically made
fault-tolerant during run-time by using additional similar cores to im-
plement reconfigurable FT schemes which exhibit self-healing properties,
without requiring any pre-designed special FT architecture.
Hardware redundancy schemes are based on several identical units that operate
with common inputs and ideally produce the same outputs. A majority voter
masks faults and a comparator detects faults. TMR schemes mask one fault only
whereas DwC cannot mask but detects one fault only and saves resources. A
spare is used to replace faulty units, but it requires an improved voter that detects
and locates the faulty unit. Selecting a scheme represents a trade-off between the
level of dependability achieved (i.e., detection, location, masking) and resource
consumption. Additional information is found in [11] [15].
4.3. SOLUTION OVERVIEW 57
Figure 4.2 illustrates the basic idea of the proposed solution. In this example,
functions F, G, and H are accelerated in hardware cores. Next, in order to provide
fault-tolerance to those functions, different FT schemes are strategically assem-
bled during run-time, i.e., Triple-Modular Redundancy (TMR), Triple- modular-
redundancy-with-spare (TMRwS), and DwC.
The RTR FT Schemes in RecoBlock

With this proposition, the concept of self-healing adaptive fault tolerance is de-
veloped. Systems that adaptively trigger the best self-healing strategy and self-
assemble FT schemes according to performance metrics and user-defined goals. For
that purpose, this thesis defines the RTR schemes in the RecoBlock context and
provides a detailed description of the processes, algorithms and software structures
that enable their autonomic behavior and self-x features, e.g., self-assembly, self-
repair, voting-function, roll-back recovery.
OK, BAD
F F
RB0 VOTER 0,1,…,fault-threshold
RcBk0 state
Self - repair
checkpoints
fault-counter
clone
F
INSTANTIATED RTR IP-CORES
F MicroBlaze 0, 1, 2, …

Self - replicate
group
RB1 Processor
RcBk1 chunks scheme none, DWC, TMR
F data
F function TMRwS, UFO
RB2 FIELDS
RcBk2 none, F,G,H, …, Spare
F Memory
replicate
assembly S
RB3 PARAMETERS
RcBk3
F I/O TMR with Spare F F F

Memory S
RBn
(a) Initial State (b) Self-assembly and normal execution (c) Service- Map
Figure 4.3: Overview of run-time reconfigurable (RTR) fault-tolerant (FT) schemes based on
RecoBlock IP-cores.
Figure 4.3 provides a brief overview of the management and processes that
enable the RTR FT schemes and also the UFO. Figure 4.3 (a) describes the SoC
initial state with several RTR IP-cores. Some functions, e.g., F, are accelerated
in the cores while other RecoBlocks are free. Figure 4.3 (b) shows how a TMR-
with-spare (TMRwS) is assembled during run-time by cloning the function F in
two empty cores and reserving another core as spare. After a fault is detected and
located by the voting-function, self-repair is performed by reconfiguring F and self-
replicate by relocating F in a spare. During normal-execution, the three replicas
compute the same data stream from memory and stores results in different memory
buffers. The voting-function implemented on the processor compares all results,
detects faults and triggers the adequate self-repair or self-replication process in
the case of permanent faults. To return to the previous state after healing, the
system computes data in chunks, and manages checkpoint and roll-back recovery
algorithms. Figure 4.3 (c) illustrates how the service-map, which is a data structure
in software whose fields represent each hardware core, keeps record of core status,
fault count, fault threshold, associated group number and scheme, and function
identifier. In this way, a set of functions and pointers operating over the service-
map can dynamically manage the processes governing the behavior of all schemes.
The Upset-Fault-Observer (UFO), Introduction

In short, the Upset-Fault-Observer (UFO) can be seen as a very flexible and ex-
treme case of RTR Fault-tolerance, a dynamic subset of a TMRwS. As shown in
Figure 4.4, the UFO behaves as a dynamic virtual abstraction of a TMR scheme
that exists for an amount of time called TMR-cycle. It is assembled or disassembled
at convenience. The UFO consists of three RecoBlocks, i.e., two hosts and one guest
that is the core to be made fault-tolerant. No hardware re-connections are needed
to create this virtual structure since it is entirely handled by a software algorithm
that moves pointers and updates fields in the service-map shown in Figure 4.3
As Figure 4.4 illustrates, in an initial state, the SoC platform has a number
of RecoBlocks, a group of potential guests holding accelerated functions, a group
of spares, and two hosts in the UFO. To assemble the UFO, during the start of
each TMR-cycle a guest is ”cloned” to both hosts, the guest is ”beamed-up” to the
UFO, and any available spare is linked to the UFO. Then the UFO starts scanning
for faults following the normal operation described in Figure 4.3. The TMR-cycle
repeats for a predefined time over the same guest before it hovers to the next guest
to start a new TMR-cycle. Thus, the Array-scan-cycle is a sequence of consecutive
TMR-cycles performed over each accelerated function in the RTR SoC.
During the TMR-cycle, all three cores compute the same input data simulta-
neously, and the independent results are stored in result memory buffers. Next,
the voting-function compares the buffers and issues a fault information code that
signals whether a fault exists and its location. If a fault is detected, the compu-
tation is paused, a fault-counter increased and, the faulty module is repaired by
run-time-reconfiguration. In the case of frequent faults in the same RecoBlock, the
fault is considered a permanent-fault and the faulty RecoBlock is labeled as bad in
the service-map. In this case, instead of repairing the core, its function is replicated
in the linked spare.
In this way, the UFO exceeds other schemes since it provides self-healing TMR
redundancy on request while it hovers over selected IP-cores in the system. This
characteristic makes it a sort of virtual-redundancy-scanner that performs embed-
ded on-line tests. Besides, it is a low-cost and scalable hardware-redundancy mech-
anism.
4.4 Implementing RTR FT Shemes and Self-healing Adaptivity

Implementing of RTR FT schemes and particularly the UFO should be straightfor-
ward since the proposed solution reuses existing RTR IP-cores in the system. Nev-
4.4. IMPLEMENTING RTR FT SHEMES AND SELF-HEALING ADAPTIVITY 59 T
Ass
Hosts Hosts TMR-cycle
UFO UFO Hovers
Relocate Beam-Up F* G
if BAD Clone Guest F
S
Spares Accelerated Functions Spares Accelerated Functions F* G

(a) G G
(b)
S S
Array-scan-cycle UFO ho
Hosts TMR-cycle Hosts TMR-cycle
Hovers F* G
UFO UFO
H H
Beam-Up Beam-Up S S
Clone Guest Clone Guest
UFO ho
Bad
G
Spares Accelerated Functions Spares Accelerated Functions
F F
(c) (d) F* S
F Self-r
Figure 4.4: The UFO explained. Initially, in (a), there are a number of RecoBlocks distributed
in three categories: a group of potential guests holding accelerated functions (i.e., F, G, H), a
group of spares, and two hosts in the UFO. In (b), To assemble the UFO, during the start of each
TMR-cycle a guest is cloned to both hosts, the guest is beamed-up to the UFO, and any available
spare is linked to the UFO. The UFO then starts scanning for faults. Therefore, during the TMR-
cycle all three cores compute the same input data simultaneously and the independent results
are stored in result memory buffers. Next, the voting-function compares the buffers and issues a
fault information code that signals whether a fault exists and its location. If a fault is detected,
the computation is paused, a fault-counter increased and, the faulty module is repaired by run-
time-reconfiguration. In case of frequent faults in the same RecoBlock, the fault is considered
a permanent-fault and the faulty RecoBlock is labeled as bad in the service-map. In that case,
instead of repairing the core, its function is replicated in the linked spare. In (c), the TMR-cycle
repeats for a predefined time over the same guest before it hovers to the next guest to start a new
TMR-cycle. In (d), the UFO completes an array-scan-cycle, which is a sequence of consecutive
TMR-cycles performed over each accelerated function in the RTR SoC [40] [39].
ertheless, the design complexity is moved towards other directions: (1) software
architecture, (2) interconnection, (3) physical synthesis, and (4) characterization
of FT metrics. These challenges are summarized in the following paragraphs as
an introduction to the detailed implementation presented in Paper IV. Extended
conceptual information is also offered in Paper III.
First, an efficient software model is required because it has to manage all pro-
cesses involved in the organization and behavior of reconfigurable schemes such as
voting, comparison, self-assembly, normal execution, TMR and Array-scan cycle,
cloning, self-repairing, self-replicating, check-pointing, roll-back recovery. These
features are combined with the reconfiguration management, communication, and
acceleration API functions already discussed in Chapter 3. As the software com-
plexity grows, they can not just be added to the API set. Therefore, the Operating-
System Management-Function (OSMF) model was conceived based on the auto-

nomic computing manager principle (Chapter 2, Figure 2.4) [29] which is a solution
to deal with the design complexity paradigm. However, there is another reason
for the OSMF. This model defines how the software and hardware of an adaptive
system with self-x properties should be organized. Hence, the OSMF not only sup-
ports the reconfigurable FT schemes, but enables adaptivity, self-x properties, and
provides a roadmap for future research such as Paper V where the monitoring and
self-awareness properties were annexed to this thesis research. Another challenge
was to devise a method to keep a record of the UFO and other schemes status and
functionalities. The design approach should not be just implementing functions,
but allowing maintainability and flexibility. Besides, for enabling self-x it is impor-
tant to create a dynamic software structure based on arrays and pointers so that
the system itself can dynamically assemble or disassemble groups of cores. These
are the purposes for which the Service-map concept was conceived in this thesis.
Secondly, the instantiation of more RecoBlock IP-cores in the platform, which
are almost plug-and-play, presented a new challenge concerning the limitations of
up to 16 masters in an AXI4-interconnect. Only two RecoBlocks were sufficient to
demonstrate the ideas in Paper I and Paper II. Nevertheless, proving the RTR FT
concept would require at least three cores for only one TMR scheme and reduced
functionalities. Hence, the platform interconnect was redesigned basically with
three specialized sub-interconnect systems so that a number of ten (10) RecoBlock
IP-cores were instantiated.
Thirdly, the singularity of designing RTR embedded systems is that the designer
needs to deal not only with hardware and software, but also with configware (the
generation of partial reconfigurations), for which she must descend to physical ab-
straction levels. Configware design is performed in PlanAhead (Xilinx Flow) [62],
which can be seen as a floor-planing tool where static (the RecoBlock platform) and
reconfigurable partitions (the RP of RecoBlock IP-cores) are defined. The netlists
(*.ngc) are imported, and the typical mapping, placement, and routing phases are
completed before the bitstream generation starts. Each configuration run imports
previous static configurations and implements new configurations. Then, in the best
case one run is required to create all the partial reconfigurations of all RecoBlocks
corresponding to one accelerated algorithm. So, including the initial configuration,
a system such as the RecoBlock with n functions in the RTR Library will require
n + 1 runs, which typically takes up to 56 minutes (Intel i7, Windows-7 64bits)
when the flow has been partially automated (*.tcl) and nothing goes wrong. Un-
fortunately, that is not the case, particularly when creating state-of-the-art designs.
This quick introduction should illustrate the challenge of creating configurations for
10 x RTR IP-cores. However, the real problem observed was the frequent slack.
The routing engine finds it difficult to reach the time constraints of the clock and
other critical paths that arrive at the reconfigurable regions. Although the netlist
descriptions are identical, and the partitions are also identical and placed symmet-
rically in the FPGA geometry, the final placement and routing is not the same for
all.
4.5. CONCLUSION 61
Lastly, characterizing a custom RTR system that also has a custom FT ap-
proach requires also custom solutions. The performance evaluation of RTR archi-
tectures is still complicated since standard benchmarking tools are yet missing in
reconfigurable computing, it may not be difficult to realize why. The challenge is
even higher for new approaches such as the RecoBlock platform and particularly
for the reconfigurable FT schemes. Thus, another contribution in this thesis is
the characterization and evaluation of FT metrics adapted to the unique platform
functionalities. A reconfigurable FT system can be characterized in terms of time
complexity and space complexity. Thus, this work identified, defined and evalu-
ated the following metrics. Assembly-latency (time to assemble an FT scheme),
recovery-latency (since location by the voting function until repairing or replicat-
ing), detection-latency (since event-upset until fault location by comparing buffers
in memory), throughput-reduction (due to CPU’s processing overhead caused by
a TMR cycle). Finally, a comparatively analysis of the scalability and core usage
of each FT scheme provides an illustration of the advantages of the initial solution
proposed in this chapter, the dynamic creation of reconfigurable FT schemes in a
system with RTR IP-cores.
4.5 Conclusion
In conclusion, the work summarized in this chapter provides a motivation for Pa-
per III and Paper IV. This chapter introduced the novel idea of self-healing adap-
tive FT SoC that reuses RTR IP-cores to assemble different TMR schemes during
run-time. Paper III demonstrates the feasibility of the main concepts introduced in
Paper III, particularly the IP-core based RTR TMR schemes. The advanced scheme
UFO is a run-time self-test and recovery strategy that delivers fault-tolerance over
functions accelerated in RTR cores, and that saves resources by running TMR-
scan-cycles periodically. The characterization results in Paper IV demonstrates
that the UFO has better scalability and cost optimization compared to the almost
geometrical trend of the TMRwS and TMR schemes. However, the UFO detection-
latency and throughput is compromised by the duration of the Array-scan-cycle,
and the number of cores scanned in the loop. Therefore, it would be useful to pro-
vide embedded-test and economic and scalable lifetime self-healing in RTR SoCs
designed without redundancy.
This work aims to bring a new perspective on the dependability improvement of
FPGA-based SoCs. Fault-tolerance techniques, run-time-reconfiguration, and the
advantages of the RecoBlock concept are the vehicle to fulfill this purpose and to
materialize concepts borrowed from emerging fields such as bio-inspired hardware,
organic computing, and adaptive systems.
On the other hand, this research originates a set of questions such as what hap-
pens with the fault tolerance in the other FPGA regions. This method protects only
the functions in the reconfigurable cores, but who is protecting the cores? Using
the processor as voter represents a single-point of failure and produces overhead.
Answers to this questions can be found in Paper III, which also suggests a roadmap
for future research on adaptation and learning developed in Paper V and Paper VI.
Regarding adaptation, this investigation and implementation enabled the self-
healing and self-assembly autonomic properties and defined an organization model
and road-map for the complete implementation of a self-adaptive system. The
system can provide dynamic FT and self-reconfiguration, which means that it al-
ready enables hardware adaptation. But, to become self-adaptive, the system also
requires to observe (self-monitoring), to decide (analysis, evaluation, and decision
making), and to learn. The solution to this new requirement is covered in Chapter 5
Chapter 5
Adaptation, Self-awareness and

Learning
This chapter introduces the research on self-adaptation of run-time re-

configurable (RTR) embedded systems working under uncertainty, par-
ticularly to maintain the desired system performance when triggering
hardware acceleration and dynamic RTR schemes on RTR IP-cores. In
brief, self-awareness and rule-based learning are treated in Paper V,
and reinforcement Q-learning in Paper VI. This chapter starts by mo-
tivating the research using an example of drone-based delivery systems
unable to deal with uncertainty. It then raises attention about issues
on contemporary research on self-awareness and illustrates the research
problem. The chapter then overviews the proposed solution. In this
regard, it introduces the concept of Cognitive Reconfigurable Hardware
(CRH) that defines a path for cognitive hardware development. Besides,
it discusses how self-awareness can be achieved. The chapter then sum-
marizes implementation and contributions regarding major topics such
as the configuration of hardware performance counter and metric se-
lection, the interaction of processes and threads during the adaptation
learning cycles, simulation of uncertainty, and case study. Finally, a
summary concludes the presented work.
To know is to know that you know nothing. That is the meaning of

real knowledge.
Socrates
63
64 CHAPTER 5. ADAPTATION, SELF-AWARENESS AND LEARNING
5.1 Motivation
This section introduces the author’s vision of cognitive reconfigurable hardware
systems as a pathway to designing adaptive systems and overcome the design com-
plexity of current reconfigurable heterogeneous multicore SoCs that are increasingly
confronted to work under uncertain environments and to simultaneously optimize
its resources. The relevance of this concept is illustrated with the following discus-
sion. Last year, the community became impressed by the announcement of the first
commercial drone-based delivery projects [34], an example of autonomic systems.
Surprisingly, few days later the news media reported that a delivery mission was
canceled not because of system failure but strangely due to something unexpected,
weather conditions . This embedded system was unable to re-route the mission,
and the batteries were running out. In this example, people may conclude that
the programmer did not write the code to deal with this situation. However, an
adequate conclusion is that designers cannot predict, model, or write code for all
unexpected situations. In this context and given that current embedded systems
have enough computational power, it would be valuable if these systems become
self-aware and are capable to find their own solutions. However, challenges like this
require new ways of developing adaptive embedded systems.
5.2 Challenges
Critical function needs fault-tolerance

Flow of data
Flow of data
HW HW
CPU DRAM CPU DRAM
ICAP ICAP
F F F F
HW HW HW HW
ACCEL- ACCEL- ACCEL- ACCEL-
ERATOR ERATOR ERATOR ERATOR
120
Complex 100
80 Battery Level F
function
60 Work Load
needs 40 F V
hardware Bandwidth
20 F
acceleration 0
Voter (CPU)
1 2 3 4 5 6 7 8 9 10
Is this a good time to accelerate in hardware or
a) First case b) Second case
enable fault-tolerance (hardware redundancy) ?
Figure 5.1: A problem of self-optimization in future run-time reconfigurable (RTR) embedded

systems. In (a), the system reconfigures the RTR core to accelerate a software function on hard-
ware. The price of memory bandwidth increase may be high compared to the evident acceleration
in hardware. In (b), the system creates hardware redundancy on-the-fly to increase dependability.
There is a risk of unwanted bottle-necks in a shared-memory system.
5.2. CHALLENGES 65
Modern embedded systems are gradually forced to cope with uncertainty in

live environments and to work autonomously but interconnected at the same time.
Modeling and programming methods based on cases, branches, statistic analysis,
or profiling are not entirely suitable for such run-time optimization and adaptation
requirements. Therefore, programming such systems requires novel approaches.
Perhaps, by exploiting their computational power, designers should allow them
first to become self-aware and secondly to learn how to find their solutions.
FPGA-based SoCs with reconfigurable multicores are the ideal vehicle for such
kind of adaptive embedded systems [Paper V]. Nevertheless, the state-of-the-art
has been mainly focused on enabling self-awareness to workstation computers with
the benefits of operating system (OS) support [49, 45]. Research in self-awareness
on embedded reconfigurable systems is just emerging. In both cases mentioned
above, the usage of software methods that monitor and report performance to
external observers by inserting API calls at significant points of applications have
become familiar, e.g., Application Heartbeats [49]. Nevertheless, software-based
awareness present drawbacks compared to hardware methods. In this regard, few
works implement self-awareness based on hardware performance counters, which
can be less intrusive, more accurate, rich in metric selectivity, and alleviates the
processor’s workload. On the other hand, regarding decision- making approaches,
classic methods such as control theory [26], rule-based [3], or in the best case
heuristics [31] [53] are more widespread than machine-learning based methods [45].
The latter methods are harder to model and implement in embedded systems than
in workstations.
The kind of problem addressed in this research is illustrated in Figure 5.1,
which shows two potential situations in a processor system with RTR cores. On
the first case, the main program decides to reconfigure the RTR core to accelerate
a software function on hardware. In contrast, the memory bandwidth increase
may be too high compared to the obvious benefit of acceleration in hardware. On
the second case, a function is already being accelerated on a RTR core, but the
system decides to create hardware redundancy on-the-fly to increase dependability.
These two examples raise concerns about the creation of unwanted bottle-necks,
which can be compensated by smart run-time scheduling based on self-awareness
of system performance as well as RTR performance metrics. Consequently, this
thesis is interested in investigating how the system itself can know when and which
FT scheme or acceleration can be triggered without critically affecting the overall
performance.
This problem statement implies that the system itself must know its perfor-
mance during run time, it must analyze and evaluate these measurements, and have
decision-making policies. Similarly, other questions to be solved are: How system
monitoring can be implemented to observe not only typical processor metrics but
most importantly memory, interconnect, and RTR cores? Is software or hardware
monitoring method the most adequate? Which machine learning approach is re-
quired in this scenario? Is the typical observe-decide-act adaptive model enough?.
What is the meaning of monitoring or awareness? Besides, it is important to devise
how can uncertainty be simulated with similar computational loads as those found
on embedded systems in real environments.
Regarding previous research, Paper IV enabled the system that dynamically
triggers the RTR FT schemes and conducted a comparative analysis of their per-
formance and scalability (Chapter 4). This system was implemented following the
software organization model based on autonomic computing, which was conceived
in Paper III. Nevertheless, these papers did not present (1) a solution for self-
monitoring, (2) analysis of performance metrics and self-awareness, and (3) the
decision mechanism to trigger those FT schemes. Therefore, the work described in
the current chapter complements the missing parts of the autonomic self-adaptive
system design that is addressed in this thesis.
5.3 Solution Overview

To address the problems stated above this work proposes to use the computational
power and run-time reconfiguration to let the system monitor, analyze, and learn
from experience to take decisions during run-time to maintain an optimal system
performance, particularly under uncertainty.
A careful analysis of this proposal and the problem statement leads to the con-
clusion that an enhanced self-adaptive system is required. But, what are the essen-
tial missing components and what is the right way to organize such advance system
? The classical model of an adaptive system based on the observe-decide-act phase
can help to find the answer. This model suggests that both observe (self-monitor)
and decide (decision-making) phases are missing since the act phase is implemented
by the hardware-acceleration and dynamic FT capabilities enabled by the investiga-
tion described in previous chapters. However, this classical model is not sufficient to
embrace the self-x properties of autonomic computing, the model conceived to orga-
nize the system (Chapter 4), and the new requirements for cognitive development.
To sum up, the solution requires at least the following: self-awareness (observe),
decision-making and learning (decide), and the conception of an advanced model
that connects the research stages and highlights a path for development.
Achieving Cognitive Development in Reconfigurable Hardware

Among other sciences, psychology is an excellent source of inspiration. In 1973, Du-
val and Wicklund [52] described how humans and other beings achieve cognitive de-
velopment. This process is illustrated in Figure 5.2 In summary, they argue that we
start focusing attention on the external world (context-aware) during childhood. As
we grow up, we start focusing our attention on ourselves (self-awareness). Through
our senses, we can know something (self-monitor), but real self-awareness means “to
know what we know” (self-awareness). In consequence, this self-awareness starts
in human beings an immediate process of self-evaluation that compares ourselves
against society imposed standards or positive traits. We may decide if we want
to change and launch a self-adaptation process or in contrast to avoid awareness
5.3. SOLUTION OVERVIEW 67
Towards Cognitive Reconfigurable Hardware

SUBJECT
EMBEDDED MONITORING SELF-AWARENESS
HW Counters,
OS Services, PERCEPTION
SW Monitor, WORLD CONTEXT
ACTION
On-chip Sensors AWARENESS
PERCEPTION
RECONFIGURATION
ACTION
FPGA Partial RTR, SELF
CPU, AWARENESS
System Cores,
Frequency Control
OBJECT
Performance SELF-AWARENESS
Goals
SELF SELF SELF SELF SELF

MONITOR AWARENESS EVALUATION LEARN ADAPTATION
Know what
Know I know Self Standards
Figure 5.2: Cognitive Reconfigurable Hardware (CRH) and its relationship with human develop-
ment in psychology. A path for designing self-adaptive and learning reconfigurable systems.
and adaptation to reduce the stress of not failing into standards. During this pro-
cess, we also learn based on our experience. By analogy, Figure 5.2 illustrates that
these processes have their counterpart in hardware. In this way, the author real-
izes that hardware and living beings can share similar cognitive development and
consequently proposes the concept of Cognitive Reconfigurable Hardware (CRH)
that is explained in more detail in Paper V. There is an emphasis on reconfigurable
systems since the author believes that reconfiguration will be fundamental in near
future adaptive embedded FPGAs. Besides, reconfiguration embraces all current
interpretations such as the actual hardware RTR on FPGA, and also parameter
configuration or mode switching on CPU and other IP-cores.
In classic control theory, both perception and action functions are typically
focused on the external (context), whereas in CRH these basic functions are ad-
ditionally concentrated on the internal (self). In CRH, embedded monitoring is
an essential point to enable self-awareness and the subsequent processes. Unfortu-
nately, run-time monitoring for embedded FPGAs is still a work in progress [23].
Enabling Self-Monitoring and Self-Awareness

According to the CRH model, the first requirement to achieve self-awareness is
self-monitoring. The challenge in self-monitoring is to reduce intrusiveness but si-
multaneously increase self-awareness [20]. In this research, the aim is to measure

the real-time performance in a shared-memory processor system with RTR cores.
The author believes that real-time hardware metrics such as bus latency or band-
width in strategically selected points can represent a more accurate image of the
reconfigurable system performance, without depending on an off-line static analysis
of the execution paths or threads allocation.
Choosing a monitoring method (e.g., polling, interruptions, hardware or soft-
ware based) and knowing when and what has to be sampled are questions to be
solved in order to avoid monitoring overhead, which reduces performance. For
instance, profiling is software intrusive and the information is limited to time ex-
ecution and call graph. Static-analysis is constrained to particular configurations
and can not deal with real-time uncertainty. CPU utilization or MIPS provide in-
formation about processor performance and most hardcore processors (e.g., ARM)
have built-in monitoring mechanism, but this kind of monitoring is not suitable for
embedded systems (e.g., cores, reconfigurable cores, ICAP, AXI signals)
Monitoring is implemented with software methods in most cases. Conversely,
complex and on-line methods to measure performance are based on hardware coun-
ters. This hardware method reduces performance overhead and runs concurrently.
Hardware counters can be embedded in processors, available as IP-cores, or as cus-
tom designs in the worst case. The foundation is counters triggered by internal or
external events that compute the aggregate count of the events associated with the
metric being monitored. This thesis considers hardware counters the best approach
for monitoring and, therefore implements it by adapting the (Xilinx) AXI Logicore
IP Performance Monitor (APM) [65] to the RecoBlock platform and development
tools (The APM core is fully supported only in higher versions of ISE tools and
Vivado combined with Zynq systems).
The APM core helps to measure essential performance metrics for the AMBA
Advanced eXtensible Interface (AXI) (e.g., bus latency, memory traffic, memory
latency, latency distribution, throughput). The APM works as a logger or as a
counter of the events detected in the AXI4-MM or AXI4- Stream signals associated
to any master/slave port of the IP-cores in the system. This purpose must be con-
nected to any of ten monitoring-slots available in the APM. The type of monitored
event in an AXI4 signal is known as metric, e.g., write request count, read request
count, read latency, write latency. Most features in the APM are configured by
software through registers [25] except for the slots assignments that must be fixed
during design time.
5.4 Implementation Summary

The implementation is based on the CRH model and builds-up from the RecoBlock
platform in Paper IV (Chapter 4). The following paragraphs summarize and dis-
cuss the most significant challenges addressed during implementation and experi-
mental evaluation, i.e., (1) system generation of a new platform that includes the
5.4. IMPLEMENTATION SUMMARY 69
APM, (2) configuration of hardware performance monitoring, (3) sequence diagram

for the adaptive learning system, (4) learning problem definition, (5) uncertainty
simulation, and (6) case study. These topics help to visualize some contributions
introduced in Chapter 1.
SELF-AWARE
DYNAMIC The RecoBlock RcBk 0 RcBk 1 RcBk 2 RcBk 3
MODULAR DEPENDABILITY & FT RTR SoC RcBk 0
RcBk 1
HW ACCELERATION ---
---
---
axi2axi ---
DDR3 RAM
MicroBlaze
INTC CM HWICAP
Timer Clock DDRX SLOT SELECT METRIC SELECT COUNTERS
(fixed) (run-time)
UART Reset SYSACE
MDM D I GPIO Hardware Performance Monitor
BRAM BRAM
PERF.MON.
MicroBlaze
RcBk-NR DP DC IC IP AXI4 Triple-modular- Duplication-with- Upset-fault-

AXI4 Lite RcBk-NR
AXI4 redundancy comparison observer
F TMR-cycle
Reconfigurations
F
F V V
F
RcBk 4 RcBk 5 RcBk 6 RcBk 7 F
RecoBlock IP-core
Flexible and Reusable RTR IP-Cores Run-time Reconfigurable FT Schemes

(Hardware Acceleration)
Figure 5.3: The self-aware RecoBlock platform [Paper V].
• The platform illustrated in Figure 5.3 builds-up from the previous RecoBlock
platform instantiation in Paper II. In hardware, the APM core is added to en-
able self-monitoring. In software, the improved code and API functions allow
among other features: control and configuration of the APM, self-awareness,
decision-making, rule-based learning, and each phase in the sequence-diagram
of the adaptive cycle.
Two significant challenges were experienced. First, the instantiation and con-
figuration of the APM required several iterations. The APM is compatible
with higher versions of ISE tools and Vivado. For Zynq-based boards, it is
fully supported, but it is not for previous devices that are still used in the com-
munity, such as Virtex-6 boards. Secondly, timing closure became a serious
issue for the generation of partial reconfigurations. This issue required time-
consuming exploration of different implementation strategies and constraints
in PlanAhead [62]. Apparently the high number of AXI signals connected
in each monitoring slot complicated the mapping and routing towards the
reconfigurable blocks, despite that resource utilization is not significant.
• In Paper V, hardware performance monitoring based on the APM, is

configured to enable self-monitoring and consequently self-awareness. Since it
is the first time that real-time metrics was observed in a system with multiple
RTR cores, and no similar research was found, it was not clear which signals
deserve to be monitored. The adopted criteria are to observe transaction
byte-count metric (read or write) in points carrying more traffic so that a
better real-time model of the system performance is obtained and overhead is
avoided. Then, after practical exploration, a set of six signals and agents (AXI
cores) were selected since they provided the most representative information
of the system activity. More information about the configuration is found in
Paper V and Figure 5.4 reproduces the plot that illustrates the self-monitored
signal metrics and agents.
Among the reasons for a careful selection of monitored metrics is that slots
are not software configurable. In contrast to slot assignment, counters and
metrics are software controlled. However, up to ten counters can be assigned
to one slot and only one metric to each counter. To exemplify the deci-
sion criteria, SDRAM carry most traffic activity in a shared-memory system,
the RecoBlock ports show result data from the accelerated functions, or the
Hardware ICAP port shows run-time reconfiguration activity that is rarely
monitored in current research but is important in reconfigurable computing.
To enable software control, the rbAPMReadReset() function was created to
work as wall-clock timer that measures elapsed-time and simultaneously reads
the counters.
3.5
2.5
2
Byte count (MB)
1.5
rd MicroBlaze
1
wr MicroBlaze
0.5 rd SDRAM
wr SDRAM
0 wr RecoBlock
rd ICAP
Figure 5.4: Self-monitored performance metrics observed in the RecoBlock SoC.)
• A sequence-diagram for an adaptive learning system is devised in Paper V.

This type of diagram is an abstraction model that defines the interactions
between processes of different threads in a complex embedded system [30].
In this research, the threads represent Autonomic Computing (AC) man-
agers (i.e., monitoring function, adaptive manager, reconfiguration manager,
fault-tolerant manager) and hardware modules (i.e., APM and RTR cores).
Besides, the diagram consist of five phases: (1) random execution phase that
simulates uncertainty, (2) self-monitoring phase, (3) dynamic FT assembly
phase, (4) TMR cycle execution, and (5) learning phase. The importance of
this diagram is that it defines the sequence of interactions between hardware,
software and configware, and also establishes a guideline to design a self-
5.4. IMPLEMENTATION SUMMARY 71
adaptive system that learns by experience. Detailed information is presented

in Paper V
• A learning problem is defined in Paper V. Machine learning has been suc-
cessfully applied in problems when the program itself must dynamically adapt
and optimize particularly under uncertainty [35]. But, frequently the most
difficult steps are to define the learning problem and to select the right method
or algorithm. Paper V establishes the three essential components of a learn-
ing problem definition. The task T is to launch the most suitable dynamic
FT scheme at the end of the main loop,which will make the system perfor-
mance move towards or remain in the acceptable memory byte-count range.
The performance P is to keep memory byte-count within an acceptable per-
formance range, and the experience E is to automatically run a predefined
number of training-loops according to the sequence diagram mentioned above.
A target function is also needed to define what is to be learned using a formal
representation. Besides, a target function selects a scheme from the set of FT
schemes. For the actual implementation, the target function is replaced with
an evaluation function that assigns scores to each monitored value accord-
ing to its relationship with the ideal performance range. Those performance
values inside the range are reinforced with a better score. In this way, dur-
ing iterations of the training-loop, the system will learn which scheme is more
suitable for each monitored value and will store this information as a decision-
making strategy. Then, during normal or testing-loops, the system will revise
the strategy information and adapt its behavior according to performance,
which was the goal of this research.
• A method for uncertainty simulation and performance load generation was
conceived in Paper V. This method executes a random sequence of selected
functions from the embedded benchmarking suite MiBench [17]. These func-
tions were adapted to the software requirements and API conventions of a
MicroBlaze system. To automate this simulation and to create a learning
experience for the learning problem [35], an experience generator function
rbExperimentGenerator() was implemented.
• The case study simulates performance variation and uncertainty by random
execution of selected benchmarking functions. It also evaluates the system’s
capability to (1) self-monitor significant metrics in the Advanced eXtensible
Interface (AXI) system, (2) self-evaluate by comparing the system current
state with an ideal standard or goal (acceptable byte-count range), and (3)
learn which FT scheme is more suitable to be used in order to reduce the
impact on performance. For this purpose, the experimental loop runs nine
iterations of a training-and-testing loop. In each iteration, To implement the
adaptive learning experiment, a set of helper functions were created. For in-
stance, rbExperimentGenerator() randomize and select the sequence of bench-
marking functions, rbEvaluateScore() evaluates the metric-count against an
ideal range according to the learning problem definition, and rbFtLauncher()

triggers one of the available FT schemes (, i.e., DwC, TMR, UFO) depending
on an input parameter.
• Application of Q-learning for self-optimization of dynamic FT schemes

in Paper VI. This paper takes the next step towards self-adaptation through
reinforcement learning based self-optimization. By using an on-line Q-algorithm,
the system learns an optimal policy to adapt the selection of the self-healing
dynamic FT schemes to performance goals according to the current state
of the system expressed in the self-monitored metrics. Paper VI includes
the definition of the learning problem, the Markov decision process (MDP)
model, and adaptation of a Q-algorithm to this specific problem of
self-optimization of RTR FT schemes. Besides, an investigation of the re-
inforcement learning theory applied to the particular self-optimization
problem. Finally, an implementation and verification in Matlab of the
Q-learning based solution. Figure 5.5 reproduces and provides a summary of
the results presented in Paper V.
5.5 Conclusion
The work introduced in this chapter aims at completing the missing observe and
decide phases of the self-healing adaptive system presented in Chapter 4 so that it
becomes self-aware (observe), and learns using a reinforcement learning Q-algorithm
to self-optimize the decisions that trigger the self-healing RTR FT schmes. In this
way, the RecoBlock SoC becomes self-adaptive.
A significant contribution in this chapter is the Cognitive Reconfigurable Hard-
ware (CRH) that defines a model for the cognitive development of reconfigurable
hardware systems consisting of five phases, i.e., self-monitor, self-awareness, self-
evaluation, self-learning, and self-adaptation. This model helps to overcome the
complexity of current reconfigurable heterogeneous multicore SoCs that has to
work under unpredictable situations such as drone-based delivery, robotic space
exploration. The CRH model borrows concepts from psychology and autonomic
computing. In this regard, three models have been defined at the end of this re-
search: (1) The OSMF in (Chapter 4), which guideline the hardware, configware,
and particularly the software organization. (2) the CRH in (Chapter 5) which de-
fines a path to design advanced self-adaptive and learning reconfigurable embedded
systems, and (3) the sequence-diagram in (Chapter 5) that delineate the processes
interaction between threads of software managers and hardware modules during
the training and testing loops. These three models consolidate the guidelines to
design self-adaptive and to learn reconfigurable embedded systems.
This research formally defined the experience, performance, and task of a learn-
ing problem that launches the most suitable FT scheme to keep the system per-
formance under an ideal range of memory traffic. This problem is implemented
5.5. CONCLUSION 73
using a rule-based reinforcement algorithm in Paper V. A more advanced solution

based on Q-learning reinforcement algorithm and its verification with at simulation
in Matlab is presented in Paper VI.
Furthermore, the implementation of self-awareness helps to understand the im-
pact over performance produced by the use of dynamic FT schemes, self-assembly,
and RTR, or the software execution compared to hardware acceleration. This out-
come is an additional contribution of this thesis.
Finally, as the complexity of the system increases, the generation process of
partial reconfigurations may start failing due to timing closure issues. This situation
requires exploration of map and route strategies and constraints, but each iteration
can typically consume from 30-50 minutes. Therefore, we suggest to investigate
tools such as SmartXplorer [63] which explores several strategies, runs automatic
iterations, and compares among results until successful implementation.
STATE RESULTS
current(black), next(red), goal (green) Optimal action for each state
10 3
FT schemes F=(0,1,2,3)
8 2.5
2
6
action f
state b
1.5
4
1
2 0.5
0 0
0 50 100 0 5 10
iteration k state b
byte count intervals B=(0,1,2,...,9)
ACTION Q−TABLE
3
0
2.5 1 80
2 60
2 3
40
action f
4
1.5 20
5
1 6 0
7
0.5 −20
8
9 −40
0
0 50 100 0 none 1 DC 2 TMR3 UFO
iteration k
REWARD
100
50
reward r
−50
0 50 100
iteration k
Figure 5.5: Q-algorithm applied to learn an optimal policy to select dynamic FT schemes ac-
cording to memory transactions performance (Matlab simulation). The simulation shows that
the algorithm finds an optimal policy to select dynamic FT schemes according to the current
state of memory transactions and a performance goal. The discrete space-state has ten states b.
The discrete action-space has four actions f that triggers any of the four available dynamic FT
schemes: none, DC, TMR, UFO. The optimal policy is shown on the plot "RESULTS". e.g., for
state b = 1 the UFO scheme (f = 3) is optimal and maintains the next state exactly in the goal
interval b̄goal = 4 (green line). The "Q-TABLE" illustrates the returns (accumulated rewards) for
all actions (columns) in each state (rows) in the end of the simulation. Higher returns (dark cells)
indicate the best policy for each state (i.e., in state 1, choose UFO). The plot "STATE" shows
current states (black), the goal interval (green), and next states (red) produced after applying an
action f (plot "ACTION") which in turn generates a reward r (plot "REWARD"). This process
repeats during the learning experience (100 iterations), which is divided in an initial exploration
phase (random selection) and exploitation phase in the end (actions associated with higher returns
are selected). Detailed theory and information is presented in [Paper VI].
Chapter 6
Conclusion and Outlook
6.1 Conclusion
This thesis began motivated by the need to find a simplified and reusable approach
to developing reconfigurable embedded SoCs and explore the applications of run-
time reconfiguration (RTR). This thesis investigated how the flexibility, reusability,
and productivity in the design process of FPGA-based partial and run-time re-
configurable embedded systems-on-chip can be improved to enable research and
development of novel applications in areas such as hardware acceleration, dynamic
fault-tolerance, self-healing, self-awareness, and self-adaptation.
This thesis demonstrated that the proposed approach based on modular RTR
IP-cores and design-and-reuse principles helps to overcome the design complex-
ity, maximized the productivity of RTR embedded SoCs, and enabled research in
initially unexpected fields.
Topics and sciences such as reconfigurable computing, dependability and fault-
tolerance, complex adaptive systems, bio-inspired hardware, organic and autonomic
computing, psychology, and machine learning provided inspiration to this investi-
gation.
To sum up, some relevant contributions in this thesis are
• The RecoBlock SoC concept and platform with its flexible and reusable array
of RTR IP-cores.
• A simplified method to transform complex algorithms modeled in Matlab

into relocatable partial reconfigurations adapted to an improved RecoBlock
IP-core architecture.
75
76 CHAPTER 6. CONCLUSION AND OUTLOOK
• The concept and the implementation of the self-healing RTR FT schemes, es-
pecially the UFO that reuse available RTR IP-cores to self-assemble hardware
redundancy during runtime,
• The concept of CRH that defines a development path to achieve self-adaptation

and cognitive development,
• An adaptive self-aware and fault-tolerant RTR SoC that learns to adapt the
RTR FT schemes to performance goals under uncertainty using rule-based
decision making.
• A method based on online and model-free reinforcement learning that uses

a Q-algorithm to self-optimize the activation of dynamic FT schemes in
performance-aware RecoBlock SoCs.
This investigation has also helped to visualize immediate additions that will
bring more benefits or overcome observed drawbacks. (1) A muti-thread OS: the
self-adaptive RecoBlock has API support for reconfiguration, acceleration control,
self-healing management, self-awareness, and learning. However, the system so far
lacks a multi-threading OS with or without a multi-core processor. This addition
will enable the parallelization of tasks assigned to the RecoBlock or the threads
described in the sequential-diagram of Paper V. Otherwise, the software execution
remains sequential although in Paper II significant speedups were reported by the
acceleration in the RecoBlock architecture. (2) Multi-core Processor: (2) a second
soft processor (i.e., MicroBlaze) or a hard multi-core processor (e.g., ARM) will be
used as autonomic-manager to control all reconfiguration, self-healing (e.g. voting
and comparing function), self-x, and learning processes. (3) Internal thermal mon-
itoring: this option is typically used to explore self-optimization but has not been
implemented to prioritize less explored and more expressive monitoring such as the
hardware-performance-monitor implemented in Paper V. Furthermore, some less
immediate improvements and future work is suggested in the next section.
Finally, to overcome the design complexity of modern RTR SoCs and increase
their productivity particularly in real life uncertain environments, this thesis rec-
ommends:
• flexible modular architecture focused on design-and-reuse principles and based

on IP-cores with RTR partitions.
• implementation of self-x properties enabled by partial and RTR property of

modern FPGAs.
• adequate system organization at all levels, i.e., hardware, software, and con-
figware, probably based on autonomic computing.
• reinforcement learning to achieve self-optimization and improved decision

policies, and also to increase the reusability of software code.
6.2. OUTLOOK 77
• non-intrusive self-awareness to enable the chain of cognitive processes towards

self-adaptation.
An additional recommendation is to conduct research and development of methods

and tools for high level modeling, design and integration of RTR embedded SoCs
based on RTR IP-cores.
6.2 Outlook
The discovery of new knowledge is one of the rewards of scientific research. However,
knowledge soon leads the researcher to realize that more can still be done, and new
fields can yet be explored. In this thesis, the benefits of a modular approach based
on flexible and reusable RTR cores has been explored in several fields, determined by
and analysis of the state-of-the-art and perception of future trends. For instance,
the need for cognitive and bio-inspired properties to address the complexity of
emerging and ubiquitous embedded systems, and the advantages of RTR to enable
their implementation in hardware systems. Similarly, the following briefly suggest
some ideas that can be explored, not all so conventional.
Dynamic Vectorized RecoBlock Architectures

Based on the hardware acceleration and the self-assembly property enabled in Pa-
per II and Paper IV respectively, the RecoBlock IP-cores could be dynamically
arranged in groups of two, four, or eight parallel cores to operate on a complex
algorithm over long data streams. The RecoBlock platform is a processing unit
rather than an instruction processing unit. Therefore, a vector-manager will divide
the data stream on work-shares among the cores, similar to the fork-join model.
The basic requirements would be a parallelization API like OpenMP, a software
structure similar to the service-map in Paper III and the new vector-manager along
with the RTR-manager, which will be part of the autonomic-manager described in
Paper III. Besides, a multi-thread OS in the embedded processor is required.
Dynamic Hardware Apps and Business Model

This concept proposes applications downloaded to reconfigurable hardware cores
instead of processors as currently happens in the Apps (applications) market for
mobile devices. The advantages are increased performance, low power consumption,
and probably additional security levels due to the hardware implementation on
RTR IP-cores. In a future world of mobile and pervasive embedded devices (e.g.,
smartphones, tablets, self-driven car computers), software applications may become
inefficient for the computational requirements. This concept will take ideas from
software-defined-radio (SDR), mobile application market, and the IP-core business
model. A basic requirement to enable this concept is a standard, but flexible RTR
IP-core architecture as the RecoBlock discussed in Chapter 3.
78 CHAPTER 6. CONCLUSION AND OUTLOOK
Emergent Flock of RecoBlocks

This concept is perhaps a less traditional but exciting challenge: What can a group
of RecoBlock do if they were let alone without any particular program but with
simple cognitive and communication capabilities? The realization that simple rules
can lead to complex behaviors is the fundamental principle of complex systems and
the development of emergence. This challenge will require at least the following:
(1) a simple management distributed in each RecoBlock since currently they have a
centralized autonomic manager, and (2) a simple communication method, probably
based on encoded-tokens left over the interconnection fabric or a central repository.
Thus, they can fetch messages similar to the chemical-based methods used by ant
communities. This challenge also motivates the research and cooperation with other
disciplines such as the sciences and areas from where this thesis found inspiration.
Bibliography
[1] International Technology Roadmap For Semiconductors.
[2] Zynq-7000 All Programmable SoC Technical Reference Manual“, UG585 (v1.6), Xilinx Inc.,
[17], 2014.
[3] Andreas Agne, Markus Happe, Achim Lösch, Christian Plessl, and Marco Platzner. Self-
Awareness as a Model for Designing and Operating Heterogeneous Multicores. ACM Trans-
actions on Reconfigurable Technology and Systems, 7(2):1–18, jul 2014.
[4] Altera. Altera Support Center. [Online]. Available: http://www.altera.com/support/.
[5] John Ayer. XAPP517 Dual Use of ICAP with SEM Controller, 2011.
[6] J. Becker and M. Hübner. Run-time reconfigurabilility and other future trends. In Proceedings
of the 19th annual symposium on Integrated circuits and systems design - SBCCI ’06, pages
9–11, New York, New York, USA, aug 2006. ACM Press.
[7] Jrgen Becker, Michael Hubner, Gerhard Hettich, Rainer Constapel, Joachim Eisenmann,
and Jrgen Luka. Dynamic and Partial FPGA Exploitation. Proceedings of the IEEE, 95(2):
438–452, feb 2007.
[8] Andre R Brodtkorb, Christopher Dyken, Trond R Hagen, and Jon M Hjelmervik. State-of-
the-art in heterogeneous computing. 18:1–33, 2010.
[9] Michael Cardoso, Joao, Hübner. Reconfigurable Computing From FPGAs to Hardware/Soft-
ware Codesign. 2011.
[10] A DeHon. Architecture approaching the atomic scale. In Solid State Device Research Con-
ference, 2007. ESSDERC 2007. 37th European, pages 11–20. Ieee, sep 2007.
[11] Elena Dubrova. Fault-Tolerant Design. Springer New York, New York, NY, 2013.
[12] Gerald Estrin. Organization of computer systems: The Fixed Plus Variable Structure Com-
puter. In Papers presented at the May 3-5, 1960, western joint IRE-AIEE-ACM computer
conference on - IRE-AIEE-ACM ’60 (Western), page 33, New York, New York, USA, may
1960. ACM Press.
[13] D D Gajski, A.C.-H. Wu, V Chaiyakul, S Mori, T Nukiyama, and P Bricaud. Essential issues
for IP reuse. Proceedings of the ASP-DAC 2000. Asia and South Pacific, pages 37–42, 2000.
79
80 BIBLIOGRAPHY
[14] Christian Gamrat, Jean-Marc Philippe, Chris Jesshope, Alex Shafarenko, Labros Bisdou-
nis, Umberto Bondi, Alberto Ferrante, Joan Cabestany, Michael Hübner, Juha Pärsinnen,
Jiri Kadlec, Martin Danek, Benoit Tain, Susan Eisenbach, Michel Auguin, Jean-Philippe
Diguet, Eric Lenormand, and Jean-Luc Roux. AETHER: Self-Adaptive Networked Entities:
Autonomous Computing Elements for Future Pervasive Applications and Technologies. In
João M. P. Cardoso and Michael Hübner, editors, Reconfigurable Computing From FPGAs
to Hardware/Software Codesign, chapter 7, pages 149–184. Springer New York, New York,
NY, jan 2011.
[15] Maya Graham, Paul and Gokhale. Nanocomputing in the Presence of Defects and Faults:
A Survey. In R.Iris Shukla, SandeepK. and Bahar, editor, Nano, Quantum and Molecular
Computing, chapter 2, pages 39–72. Springer US, 2004.
[16] Juan M. Guayasamin, Tim Krynak, Katherine Krynak, Jaime Culebras, and Carl R. Hutter.
Phenotypic plasticity raises questions for taxonomically important traits: a remarkable new
Andean rainfrog ( Pristimantis ) with the ability to change skin texture. Zoological Journal
of the Linnean Society, 173(4):913–928, apr 2015.
[17] M.R. Guthaus, J.S. Ringenberg, D. Ernst, T.M. Austin, T. Mudge, and R.B. Brown.
MiBench: A free, commercially representative embedded benchmark suite. Proceedings of
the Fourth Annual IEEE International Workshop on Workload Characterization. WWC-4
(Cat. No.01EX538), pages 3–14, 2001.
[18] Reiner Hartenstein. Implications of Makimoto’s Wave. Technical report, TU Kaiserslautern,
2004.
[19] Reiner Hartenstein. The Relevance of Reconfigurable Computing. chapter p5, pages 7–34.
Springer New York, New York, NY, 2011.
[20] Reiner Hartenstein and T U Kaiserslautern. Chapter 20 Basics of Reconfigurable Computing.
pages 451–501.
[21] Scott Hauck and Andre DeHon. Reconfigurable computing: the theory and practice of FPGA-
based computation. Systems-on-Silicon. Morgan Kaufmann Pub, 2010.
[22] HIPEAC. Vision for Advanced Computing in Horizon 2020.
[23] Nam Ho, Paul Kaufmann, and Marco Platzner. A hardware/software infrastructure for per-
formance monitoring on LEON3 multicore platforms. In 2014 24th International Conference
on Field Programmable Logic and Applications (FPL), pages 1–4. IEEE, sep 2014.
[24] Inc. The MathWorks. HDL Coder ™ Getting Started Guide (v R2012b). Technical report,
2012.
[25] Adam Jacobs, Grzegorz Cieslewski, Alan D. George, Ann Gordon-Ross, and Herman Lam.
Reconfigurable Fault Tolerance. ACM Transactions on Reconfigurable Technology and Sys-
tems, 5(4):1–30, dec 2012.
[26] Phillip H. Jones, Young H. Cho, and John W. Lockwood. Dynamically optimizing FPGA ap-
plications by monitoring temperature and workloads. Proceedings of the IEEE International
Conference on VLSI Design, pages 391–398, 2007.
[27] J O Kephart and D M Chess. The Vision of Autonomic Computing. Computer, 36(1):41–50,
jan 2003.
[28] T. Koal, M. Ulbricht, and H.T. Vierhaus. Virtual TMR Schemes Combining Fault Tolerance
and Self Repair. 2013 Euromicro Conference on Digital System Design, pages 235–242, sep
2013.
[29] Philippe Lalanda, Julie a. McCann, and Ada Diaconescu. Autonomic Computing. Under-
graduate Topics in Computer Science. Springer London, London, 2013.
BIBLIOGRAPHY 81
[30] Mark. Lejk and David Deeks. An introduction to systems analysis techniques, 2002.
[31] Fabrice Lemonnier, Philippe Millet, Gabriel Marchesan Almeida, Michael Hubner, Jurgen
Becker, Sebastien Pillement, Olivier Sentieys, Martijn Koedam, Shubhendu Sinha, Kees
Goossens, Christian Piguet, Marc Nicolas Morgan, and Romain Lemaire. Towards future
adaptive multiprocessor systems-on-chip: An innovative approach for flexible architectures.
Proceedings - 2012 International Conference on Embedded Computer Systems: Architectures,
Modeling and Simulation, IC-SAMOS 2012, pages 228–235, 2012.
[32] Taivo Lints. The essentials of defining adaptation. IEEE Aerospace and Electronic Systems
Magazine, 27(1):37–41, 2012.
[33] Grant Martin and Henry Chang, editors. Winning the SoC revolution : experiences in real
design. Boston, Mass. : Kluwer Academic Publishers, Boston, Mass., 2003.
[34] MIT. Delivery by drone. [Online]. Available: http://newsoffice.mit.edu, 2014.
[35] Tom M Thomas M Mitchell. Machine Learning. McGraw-Hill Science/Engineering/Math,

New York, NY, USA, 1997 edition, 1997.
[36] Christian Müller-Schloer, Hartmut Schmeck, and Theo Ungerer. Organic Computing— A
Paradigm Shift for Complex Systems. 2008.
[37] Prof C Muller-schloer. Organic Computing - On the Feasibility of Controlled Emergence.

(1):2–5, 2004.
[38] Byron Navas, Johnny Öberg, and Ingo Sander. Towards the generic reconfigurable accel-
erator: Algorithm development, core design, and performance analysis. In Reconfigurable
Computing and FPGAs (ReConFig), International Conference on, pages 1–6, dec 2013.
[39] Byron Navas, Johnny Öberg, and Ingo Sander. On providing scalable self-healing adap-
tive fault-tolerance to RTR SoCs. In 2014 International Conference on ReConFigurable
Computing and FPGAs (ReConFig14), pages 1–6. IEEE, dec 2014.
[40] Byron Navas, Johnny Öberg, and Ingo Sander. The Upset-Fault-Observer : A Concept
for Self-healing Adaptive Fault Tolerance. In 2014 NASA/ESA Conference on Adaptive
Hardware and Systems (AHS-2014), 2014.
[41] Byron Navas, Ingo Sander, and Johnny Öberg. The RecoBlock SoC Platform: A Flexible
Array of Reusable Run-Time-Reconfigurable IP-Blocks. In Design, Automation & Test in
Europe Conference & Exhibition (DATE), pages 833–838, New Jersey, 2013. IEEE Conference
Publications.
[42] Byron Navas, Ingo Sander, and Johnny Öberg. Reinforcement Learning Based Self-
Optimization of Dynamic Fault-Tolerant Schemes in Performance-Aware RecoBlock SoCs.
Technical report, KTH Royal Institute of Technology, School of Information and Communi-
cation Technology, Stockholm, Sweden, 2015.
[43] Byron Navas, Ingo Sander, and Johnny Öberg. Towards Cognitive Reconfigurable Hardware
: Self-Aware Learning in RTR Fault-Tolerant SoCs. In Reconfigurable and Communication-
Centric Systems-on-Chip (ReCoSoC), 2015 10th International Symposium on, 2015.
[44] B Osterloh, H Michalik, S A Habinc, and B Fiethe. Dynamic Partial Reconfiguration in Space
Applications. Adaptive Hardware and Systems, 2009. AHS 2009. NASA/ESA Conference
on, pages 336–343, jul 2009.
[45] Jacopo Panerati, Filippo Sironi, Matteo Carminati, Martina Maggio, Giovanni Beltrame,
Piotr J. Gmytrasiewicz, Donatella Sciuto, and Marco D. Santambrogio. On self-adaptive re-
source allocation through reinforcement learning. 2013 NASA/ESA Conference on Adaptive
Hardware and Systems (AHS-2013), pages 23–30, jun 2013.
82 BIBLIOGRAPHY
[46] Kyprianos Papadimitriou, Apostolos Dollas, and Scott Hauck. Performance of partial recon-
figuration in FPGA systems. ACM Transactions on Reconfigurable Technology and Systems,
4(4):1–24, dec 2011.
[47] Alberto Rosti, Fabio Campi, Philippe Bonnot, and Paul Brelet. State of the Art. In NikolaosS.
Voros, Alberto Rosti, and Michael Hübner, editors, Dynamic System Reconfiguration in
Heterogeneous Platforms SE - 2, volume 40 of Lecture Notes in Electrical Engineering, pages
13–27. Springer Netherlands, 2009.
[48] Ingo Sander and Axel Jantsch. Modelling Adaptive Systems in ForSyDe. Electronic Notes
in Theoretical Computer Science, 200(2):39–54, feb 2008.
[49] Marco D. Santambrogio, Henry Hoffmann, Jonathan Eastep, and Anant Agarwal. Enabling
technologies for self-aware adaptive systems. 2010 NASA/ESA Conference on Adaptive
Hardware and Systems, AHS 2010, pages 149–156, 2010.
[50] N.R. Saxena and E.J. McCluskey. Dependable adaptive computing systems-the ROAR
project. SMC’98 Conference Proceedings. 1998 IEEE International Conference on Systems,
Man, and Cybernetics (Cat. No.98CH36218), 3:2172–2177.
[51] Hartmut Schmeck, Christian Müller-Schloer, Emre Çakar, Moez Mnif, and Urban Richter.
Adaptivity and self-organization in organic computing systems. ACM Transactions on Au-
tonomous and Adaptive Systems, 5(3):1–32, sep 2010.
[52] Paul J. Silvia and T. Shelley Duval. Objective Self-Awareness Theory: Recent Progress and
Enduring Problems. Personality and Social Psychology Review, 5(3):230–241, 2001.
[53] F. Sironi, M. Triverio, H. Hoffmann, M. Maggio, and M. D. Santambrogio. Self-aware adap-
tation in FPGA-based systems. Proceedings - 2010 International Conference on Field Pro-
grammable Logic and Applications, FPL 2010, pages 187–192, 2010.
[54] Sven Tomforde, Holger Prothmann, Jürgen Branke, Jörg Hähner, Moez Mnif, Christian
Müller-Schloer, Urban Richter, and Hartmut Schmeck. Observation and Control of Organic
Systems. BT - Organic Computing - A Paradigm Shift for Complex Systems. In Organic
Computing— A Paradigm Shift for Complex Systems, chapter 4.1, pages 325–338. 2011.
[55] S. Trimberger, D. Carberry, a. Johnson, and J. Wong. A time-multiplexed FPGA. Proceed-
ings. The 5th Annual IEEE Symposium on Field-Programmable Custom Computing Ma-
chines Cat. No.97TB100186), pages 22–28, 1997.
[56] Andres Upegui and Eduardo Sanchez. Evolvable FPGAs-Chapter 33. In Scott Hauck and
Andre DeHon, editors, Reconfigurable computing: the theory and practice of FPGA-based
computation, chapter 33, pages 725–752. Elsevier Inc., 2008.
[57] Filip Veljkovic, Teresa Riesgo, Eduardo de la Torre, Raul Regada, and Luis Berrojo. A run
time adaptive architecture to trade-off performance for fault tolerance applied to a DVB
on-board processor. In 2014 NASA/ESA Conference on Adaptive Hardware and Systems
(AHS), pages 143–150. IEEE, jul 2014.
[58] VivadoUG1. Vivado Design Suite User Guide. 901:1–120, 2013.
[59] Xilinx. Partial Reconfiguration User Guide, UG702 (v12.3). Technical report, 2010.
[60] Xilinx. AXI Reference Guide, UG761 (v13.4), 2012.
[61] Xilinx. EDK Concepts, Tools, and Techniques. Technical report, 2012.
[62] Xilinx. PlanAhead User Guide, UG632 (v13.4), 2012.
[63] Xilinx. Xilinx: Product Support & Documentation. [Online]. Available:
http://www.xilinx.com/support/, 2012.
BIBLIOGRAPHY 83
[64] Xilinx Inc. Microblaze processor reference guide. Technical report, 2006.
[65] Xilinx Inc. Xilinx, 2012.
[66] L.A. Zadeh. On the definition of adaptivity. Proceedings of the IEEE, 51(3):469–470, 1963.
[67] Jun Zhu. Performance Analysis and Implementation of Predictable Streaming Applications
on Multiprocessor Systems-on-Chip. PhD thesis, KTH, 2010.

Full Text 01

Uploaded by

Copyright:

Available Formats

Full Text 01

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Full Text 01

Uploaded by

Copyright:

Available Formats

Cognitive and Self-Adaptive SoCs with

Self-Healing Run-Time-Reconfigurable RecoBlocks

Doctoral Thesis in Electronic and Computer Systems

Akademisk avhandling som med tillstånd av Kungl Tekniska högskolan framlägges

© Byron R. Navas V., Dec 2015

In contrast to classical Field-Programmable Gate Arrays (FPGAs), par-

Partiell och run-time rekonfigurering (RTR) betyder att en del av en in-

List of Acronyms xiii

3 The RecoBlock Concept 31

3.1.3 The Reconfigurable-Block IP-core (RecoBlock) Concept . . . 33

4 Self-healing Run-time Reconfigurable Fault-tolerance 53

5 Adaptation, Self-awareness and Learning 63

6 Conclusion and Outlook 75

1.1 The Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1 Abstract view of a Field-Programmable Gate Array (FPGA) internal

3.1 The system-level design and reconfigurable computing gap. . . . . . . . 33

4.1 Issues in fault-tolerant approaches that combine hardware redundancy

4.3 Overview of run-time reconfigurable (RTR) fault-tolerant (FT) schemes

5.1 A problem of self-optimization in future run-time reconfigurable (RTR)

AC: Autonomic Computing

MPSoC: multi-processor system-on- chip

to trigger them are yet to be developed. Therefore, we have a species

Technologically speaking, FPGAs are arguably less efficient than microproces-

The significance of building dependable computer systems has increased pro-

1.1.1 Problem Description and Challenges

The following paragraphs summarize some gaps that we progressively identified

1.1.2 Research Question

• Fit in a SoC (small-footprint) Self-healing Cognitive and self-adaptive

• To conceive, design, and implement a flexible and reusable solution based on

• To investigate and develop a solution to accelerate software functions in RTR

1.3 Research Contributions

The Ups et-Fault-

• Stage 1 (Chapter 3): The RecoBlock Platform and Hardware Acceleration

• Stage 2 (Chapter 4): Dependability and Self-*

– 10 x RecoBlock IP-core platform: Improved to the RecoBlock platform

1.3.2 List of Publications

This paper proposes principles to increase the flexibility and reusability of

This paper introduces a new perspective on the dependability improvement

This paper implements demonstrates and evaluates the concepts introduced in

1.4 Thesis Organization

2.1 Reconfigurable Computing

2.2 Programmable Logic, FPGA

Reconfigurable Modules (RM)

(a) Partial reconfiguration concept. (b) Generation flow of partial reconfigurations

Triple-Modular Redundancy with Triple-Modular Redundancy

Figure 2.3: Hardware Redundancy Schemes.

Another concern is that SRAM-based FPGAs are more susceptible to several

2.4 Adaptive Systems

Adaptivity is also an important and natural property in CS where a large num-

2.5 Autonomic and Organic Computing

2.5.1 Autonomic Computing

Regarding the implementation, AC systems rely on the notion of an Autonomic

2.5.2 Organic Computing

Figure 2.5: Organic Computing Architecture. Observer/Controller architecture and different

From the design perspective, OC proposes a generic Observer/Controller archi-

The RecoBlock Concept

Ludwig Mies van der Rohe, Bauhaus 1959

3.1 RecoBlock: A Flexible Array of Reusable Run-time

HIGH LEVEL OF ABSTRACTION

SYSTEM LEVEL DESIGN – HARDWARE GAP

rp_fx.ngc .ngc .c