Cartera de Markowitz

Evolvable Hardware (EH or EHW) lies at the intersection of biology, computer science and engineering [127]. Generally speaking, Evolvable Hardware is automatic design and optimisation of any physical structure using evolutionary algorithms. These physical structures can be anything from optical lens sets to antennas, analogue filters or toddling robots. The term “evolvable hardware” was firstly used only for evolution of electronic circuits, but nowadays, people use it for any kind of “hardware” evolution. A recent review of evolvable hardware, in its broad sense, can be found in [231]. Haddow and Tyrrell also have a very comprehensive recent review of the field [137] noting the definition and boundaries of EH, the potentials and current challenges.

Some researchers name the final product “evolved hardware” when it is no longer evolving during its life time. On the other hand, a real evolvable hardware can be an embodied adaptable system that continues its evolution during its lifespan in its actual environment. This could be an instinct shift of a robot in response to the changes in its environment or a self-repairing satellite controller trying to evolve a circuit robust to different radiations and noises in space.

Evolvable Hardware can be classified in many ways according to the evolutionary algorithm, appli- cation area, adaptation method, evaluation process, and even the hardware platform used. Here we focus on its applications in design and adaptation of digital circuits and particularly spiking neural networks.

Evolving Digital Circuits

The most commonly used evolutionary algorithms for evolvable hardware are Genetic Algorithms (GA) [160, 127, 131]. However, Genetic Programming (GP) [206] and Cartesian Genetic Programming (CGP) [266] are also very popular. The whole process of evolving digital circuits by GA can be summarised in figure 2.9. Each circuit is represented by a binary string called chromosome (or a set of chromosomes in some cases), which comprises the genome of the potential solutions. The process starts with a popula- tion of random genomes (or sometimes an evolved seed population from previous runs). Each genome is mapped to a circuit through a direct or indirect mapping [127] process. In direct mapping, the chromo- some explicitly describes the circuit at a switch, gate, or functional level. In contrast, indirect mapping uses the programs or derivation trees, which are encoded in the genome, to develop circuits [127]. The resulting circuits are evaluated according to the desired functionality using a fitness function. Circuits can be simulated in software or configured on a hardware platform for evaluation. The terms “extrinsic” and “intrinsic” are coined for these methods respectively [127]. The evaluation process involves feeding all the possible input vectors (or a subset of them when too many possibilities) and comparing the circuit output with the desired output to calculate a fitness score. After evaluation, a fitness score is assigned to each individual circuit. Fitter circuits are selected randomly as parents with a probability related to their fitness values. Less fit chromosomes are deleted from the population and new ones are reproduced instead using fitter chromosomes as parents. A set of recombination (crossover) and variation (mutation)

Reproduction Mapping to Circuits Circuits Fitness 0.5 0.6 0.65 0.7 0.55 0.80 0.73 0.82 . . . 0.79 101101010100...0001010 101101010100...0001010 101101010100...0001010 001000111101...0010110 101101010100...0001010 011010001010...1101101 101101010100...0001010 101101010100...0001010 101101010100...0001010 101101010100...0001010 001010101000...1010101 010010100101...1011100 100100001010...0101011 101101010100...0001010 001011101111...1111010 Population of Chromosomes 101101010100...0001010 101101010100...0001010 101101010100...0001010 001000111101...0010110 101101010100...0001010 011010001010...1101101 101101010100...0001010 101101010100...0001010 101101010100...0001010 101101010100...0001010 001010101000...1010101 010010100101...1011100 100100001010...0101011 101101010100...0001010 001011101111...1111010 Evaluation Selection Parents 0.7 0.80 0.73 0.82 . . . 0.79 101101010100...0001010 101101010100...0001010 101101010100...0001010 001000111101...0010110 101101010100...0001010 011010001010...1101101 101101010100...0001010 101101010100...0001010 101101010100...0001010 101101010100...0001010 001010101000...1010101 010010100101...1011100 100100001010...0101011 101101010100...0001010 001011101111...1111010 Crossover 011010001010...1010101 001010101000...1101101 1 1 0 New Chromosomes 011000001010...10110101 001010101010...1101101 Generate New Population Mutation

operators (depending on the algorithm type and the genome representation) are used to reproduce a new genome from parent genomes. This process iterates and continues until a satisfactory circuit evolves or the stopping condition is met. This would effectively synthesise an evolved hardware solution. A similar process can be used for evolvable or adaptive hardware that is evaluated in the actual application environment and evolves through the product life-time. However, fail-safe mechanisms or other provi- sions are required to make sure that system will perform acceptably without damaging anything when an individual with a low fitness is evaluated.

Evolvable Hardware Platforms

Researchers used different reconfigurable devices for intrinsic evolvable hardware [156], including cus- tom evolvable analogue and digital chips, Field Programmable Analogue Arrays (FPAA), Programmable Logic Arrays (PLA), Field Programmable Gate Arrays (FPGA), POEtic chip [271] and even Liquid Crystal Displays (LCD) [145]. Still, FPGAs are the most popular and de facto standard devices for in- trinsic evolution of digital hardware [138]. A discussion of evolvable hardware platforms can be found in [138]. Also a recent review of different EH platforms can be found in [137]. Here we focus on FPGAs as the platform of this study.

FPGAs have been extensively used in evolvable hardware researches and applications. However, they have also some disadvantages. The constraints they impose on evolution for protecting the device from incorrect connections and damages, and unavailability of the configuration bitstream formats of some new commercial devices are two major problems in using FPGAs as evolvable hardware platforms. To tackle these problems, three general approaches were previously applied to evolvable hardware on FPGAs. The first approach is to use an evolution-friendly FPGA (that cannot be damaged by con- tention due to incorrect configuration, e.g. XC6216) with an open configuration bitstream format allow- ing evolution to control the functional and routing resources of the FPGA at a low-level of abstraction [364]. This is an effective approach. However, those kind of devices are discontinued and new FPGA families are not evolution-friendly in that sense.

The second method is to design a virtual evolution-friendly FPGA on any FPGA [139]. This method is very flexible and allows designing the right type of reconfigurable cellular structure for each applica- tion but is very inefficient in terms of hardware resources [372]. Upegui reports that this method needs 4.5x more silicon area compared to the first method [372].

The third approach is to design the same cellular structure of the virtual FPGA and pre-route the connections between cells, but instead of dedicating some hardware resources to configuring the virtual FPGA, lock location and pin configurations of the LUTs, Muxs, and flip-flops in the cellular structure to pre-specified sites on the FPGA and then use partial reconfiguration for switching the routing and changing the function of each cell [377]. Undocumented configuration bitstream formats of new com- mercial FPGAs makes this a challenging task. However, it is always possible to modify the contents of a register, a RAM block, or a Look-Up Table (LUT) with a little bit of reverse engineering [372]. It is sometimes also possible to use specific APIs or design tools (e.g. Xilinx JBits or FPGA Editor) to make these changes in the configuration bitstream before each evaluation. However, this later method

is much slower than the former method of difference-based partial reconfiguration both due to longer reconfiguration times (if full reconfiguration is inevitable) and bitstream generation time. Xilinx APIs for embedded processors on FPGA do not allow changing the routings but they provide functions for changing the LUT and flip-flop contents. In this way, it is possible to use some of the LUTs as routing resources that can be partially reconfigured by the evolution.

Evolvable Hardware Promises

Evolvable hardware has been claimed (and sometimes proven) to minimise cost, create adaptive fault tolerant systems, able to explore new design spaces and synthesise implicitly defined circuits [127]. Evolvable hardware can be used to reduce the design or manufacturing costs by optimising a circuit or even automatic design of the circuits. Evolutionary algorithms have been used in routing [253] and layout [125] design of circuits. Successful application of evolvable hardware for optimising clock skew in chip manufacturing process leading to about 50% improvement in yield and evolutionary design of a fast low-cost controller are reported by Higuchi et al. [155, 185]. Adaptive evolvable hardware applications were reported in data compression [322], audio-visual filtering [335, 392], adaptive hashing [71], and ATM network scheduling [217, 227] and many others [137]. Fault tolerance has been demonstrated in an evolutionary robot controller [154]. Lohn et al. [230] also showed that evolution can recover the routing and logic of the circuits at the same time.

Sometimes evolvable hardware is used to synthesise circuits from an implicit high-level behavioural description or input-output examples. Pattern recognisers and classifier systems lie in this category. Input-output example vectors are given or can be obtained from behavioural description of the circuit. They are used to evaluate behaviour of the evolving circuits in form of a fitness function. Digital circuits can be evolved at the gate level or functional level. Higuchi et al. explored both of these areas in image recognition, classification of two intertwined spirals, the Iris data set, and 2D image rotation [418].

In traditional design, digital devices are used in the same way that they are designed for. But by relaxing this constraint, evolution is able to explore other innovative ways to use them. Evolution is able to exploit even parasitic properties of the components to satisfy its requirements. Thomson’s famous experiment of intrinsic evolution of a tone discriminator on a reconfigurable digital device [364] demonstrated how evolution uses secondary properties of the digital components. In another experiment, he evolved a low-frequency (4 kHz) oscillator using simulated digital gates with random delays between 1 and 5 nanosecond. A recent review of EH success stories and potentials can be found in [137].

Evolvable Hardware Challenges

With all the success, advantages and potentials, EH is also facing serious challenges. One of the major problems with evolvable hardware is its scalability. Much longer chromosomes are needed for describing complex circuits, which implies longer evolution. Moreover, the fitness landscape for digital hardware evolution is generally very epistatic and rugged [129]. That means lots of local minima and deceptive clues for the evolution. Researchers are trying to devise more scalable representations to solve this prob- lem. Koza [206] proposed GP (Genetic Programming) with Automatically Defined Functions (ADF) that may bring modularity and reuse to evolvable hardware. Torresen [367] demonstrated that dividing

the whole system into single-output subsystems can help evolution to solve more complex problems. Miller et al. introduced CGP (Cartesian Genetic Programming) [266, 387] and then ECGP (Embedded CGP) [398, 399, 265] and showed their superiority over GP for some problems. Alba et al. [5] pro- posed a parallel hybridisation of simulated annealing and evolutionary algorithms. Vasicek et al. used a SAT solver for formal verification of digital circuits solver and given a perfect initial solution were able to evolve simpler circuits and effectively optimise the silicon area needed for the function [386]. This method assumes that a perfect solution already exists. However, the scalability problem is still an obstacle in evolution of complex digital systems [365]. Gordon showed that developmental processes could be a solution to scalability problem in evolving digital hardware [129]. Developmental systems are reviewed in section 2.5.3. There are also other challenges such as fitness evaluation that involves an intractably large number of input vectors, measuring the feasibility factors of the solutions, and putting the solutions in realistic environments for evaluation and measurement [137]. A relatively recent review of these can be found in [137] and [127].