FRINK Linked Data Fragments server

Matches in SemOpenAlex for { <https://semopenalex.org/work/W66160711> ?p ?o ?g. }

• W66160711 endingPage "219" @default.
• W66160711 startingPage "216" @default.
• W66160711 abstract "Reconfigurable embedded systems are nowadays widely used, since they have the capability to modify their functionalities, adding or removing components and modify interconnections among them. In this work, the main emphasis will be on the definition of a framework, based on reconfigurable architecture, where hardware components can autonomously evolve to define the best system characterization to solve a given problem. Evolvable hardware proposes an attractive technique to the exploration of the solution space, in order to evaluate the most effective solutions that are compatible with the problem under investigation. 1. EVOLVABLE HARDWARE: BASIC PRINCIPLES The term Evolvable Hardware (EHW) refers to hardware, usually implemented on programmable logic devices (i.e. FPGA), that can reconfigure itself to adapt its architecture and behavior autonomously. The basic idea is to imitate the natural process of evolution adapting this concept to the circuit design process. The main adaptive system used by almost all EHW is an Evolutive Algorithm (such as Genetic Algorithms or Genetic Programming techniques) where the partial solutions are represented by the hardware configurations. Thus the problem of designing a complex system can be transformed into (at least) two sub-problems: find a good abstraction for the hardware to be evolved (or chromosome representation) and design a good fitness function to evaluate the candidate configurations in order to give a growth direction toward better solutions. According to the level of chromosome representation, the design approach to EHW can be classified into Gate Level Evolution (or fine grained EHW) and Function Level Evolution. Gate Level EHW uses a EA to select components or component values in an analog circuit or creates digital circuits from gate-level building blocks. Fine grained EHW maximizes exploration by searching a minimally restricted space of solutions (the space of all electronic circuits composed of some particular types of components) allowing to obtain very efficient solution to medium-small problems [1]. By contrast, function-level EHW generally involves selecting topologies and assembling circuits from high-level functional building blocks such as artificial neurons. Functionlevel EHW emphasizes exploitation of functional building block circuits which are known to the researcher to be necessary and sufficient to solve the problem thus exploring a much smaller search space. It becomes necessary to introduce some kind of middle-layer to map the abstract description given by the chromosomes to the actual hardware configuration. A possible approach in designing such structure is given by Virtual Reconfigurable Circuits (VRCs) proposed by L. Sekanina [2] [3]. This solution draws on a particular Genetic Programming technique: Cartesian Genetic Programming (CGP) [4] [5]. In CGP, digital circuits are composed of programmable elements arranged in a regular pattern of x rows and y columns. The configuration bits determines the connections between the basic elements and between basic elements and input/output signals as well as the configurations of these basic elements. The Virtual Reconfigurable Circuit is a reconfigurable circuit mapped over the FPGA resources whose behavior is determinated by some configurations bit held in a dedicated memory. A VRC is mainly composed by an array of processing elements (PEs), a programmable interconnection network, a configuration memory(typically implemented as a register array) and a configuration port. The main advantage of this method is that the array of PEs, the routing circuits and the configuration memory can be designed exactly according to the requirements of a given application. Because VRCs can be described in HDL, they can be synthetized with various constraints and for various target platforms. Figure 1: Example of VRC mapping on FPGA resources The proposed approach tries to design the whole VRC Figure 2: High Level structure of the evolutive system structure and Evolution Unit using a High Level description language, such as Impulse C, to: • Speed up the VRC’s design process allowing the designer to use a C-like programming language to describe the structure and the functionalities implemented by the PE. Something similar to the specification language proposed by Sekanina [3] but giving more flexibility to the designer. • Integrate Software design (evolutive algorithm) and Hardware design (VRC) into the same environment and automatize the creation of Hardware/Software interfaces thus allowing the designer to quickly test and modify the whole system. Here follows a brief introduction to the Impulse C language. 2. THE PROPOSED APPROACH To validate the proposed approach we re-implemented the evolutionary image operator design adapting the VRC structure and the whole system organization. The problem consists in evolving a digital 3x3 filter for Image Processing applications. In our experiments we tried to evolve various kinds of filters to test the flexibility of the whole system. In order to create the evolutive filter we divided the system into 2 sub-systems: the Evolutive Unit (implementing the Evolutive Algorithm) and the Virtual Reconfigurable Circuit(see Figure 2). This loosely coupled configuration allowed us to test very quickly various solutions for both Hardware and Software modules in order to find a good mix. Using the same configuration it is also possible to use MIMD systems in order to realize parallel evolution implementing the communications routines directly into the software module. Figure 3 shows the basic evolution steps. Once the initial population has been created, each individual is evaluated to determinate its fitness value. In order to evaluate each individual its chromosome is written into the VRC’s configuration memory (thus instantiated) and then the software reads and sends the input data(composed by each pixel and its 8-neighbor) to the hardware filter. Pairs of gray scale images have been used to extract the input data. Each pair is composed by a source image and a sample image. The results of the filtering operation are used to compute the fitness value according to eq.1 (and 2). Then genetic operators are applied to the actual population in order to create the next generation. The process can stop when a satisfactory solution is found (i.e. the best individual fitness is greater than a fixed threshold) or when a set number of iterations is exceeded. Figure 3: Basic steps of the evolution process 2.1 Evolutive Algorithm As mentioned before, using C as programming language to describe the Evolutive Unit allowed us to easily test different kinds of EA. In particular we used Simulated Annealing techniques and a Genetic Algorithm (GA). For the experiments we decided to use GA with tournament based selection, elitism, single-point crossover and population of 100 individuals. A variable mutation rate ,depending on each individual’s fitness value, has been used. Each mutation operation consists in modifying an active CFB(changing its functionality) or an active RB(changing the connection schema interconnecting the CFBs). The fitness function, based on g(i, j) = |res(i, j)− sample(i, j)|, used to evaluate each individual is: f = 255 ∗ (R − 2) ∗ (C − 2)− R−2 X" @default.
• W66160711 created "2016-06-24" @default.
• W66160711 creator A5010543929 @default.
• W66160711 creator A5040291662 @default.
• W66160711 creator A5048406423 @default.
• W66160711 creator A5064238155 @default.
• W66160711 date "2007-01-01" @default.
• W66160711 modified "2023-09-26" @default.
• W66160711 title "Evolvable Hardware: A Functional Level Evolution Framework Based on ImpulseC." @default.
• W66160711 cites W102100901 @default.
• W66160711 cites W1486894692 @default.
• W66160711 cites W1572929635 @default.
• W66160711 cites W2108548117 @default.
• W66160711 hasPublicationYear "2007" @default.
• W66160711 type Work @default.
• W66160711 sameAs 66160711 @default.
• W66160711 citedByCount "0" @default.
• W66160711 crossrefType "journal-article" @default.
• W66160711 hasAuthorship W66160711A5010543929 @default.
• W66160711 hasAuthorship W66160711A5040291662 @default.
• W66160711 hasAuthorship W66160711A5048406423 @default.
• W66160711 hasAuthorship W66160711A5064238155 @default.
• W66160711 hasConcept C149635348 @default.
• W66160711 hasConcept C2776243922 @default.
• W66160711 hasConcept C41008148 @default.
• W66160711 hasConcept C42935608 @default.
• W66160711 hasConceptScore W66160711C149635348 @default.
• W66160711 hasConceptScore W66160711C2776243922 @default.
• W66160711 hasConceptScore W66160711C41008148 @default.
• W66160711 hasConceptScore W66160711C42935608 @default.
• W66160711 hasLocation W661607111 @default.
• W66160711 hasOpenAccess W66160711 @default.
• W66160711 hasPrimaryLocation W661607111 @default.
• W66160711 hasRelatedWork W128247939 @default.
• W66160711 hasRelatedWork W1517210355 @default.
• W66160711 hasRelatedWork W1527299821 @default.
• W66160711 hasRelatedWork W1586008352 @default.
• W66160711 hasRelatedWork W1920019235 @default.
• W66160711 hasRelatedWork W2113875362 @default.
• W66160711 hasRelatedWork W2188957274 @default.
• W66160711 hasRelatedWork W2295228796 @default.
• W66160711 hasRelatedWork W2362949313 @default.
• W66160711 hasRelatedWork W2363596567 @default.
• W66160711 hasRelatedWork W2372420500 @default.
• W66160711 hasRelatedWork W2374908254 @default.
• W66160711 hasRelatedWork W2382906303 @default.
• W66160711 hasRelatedWork W2393039847 @default.
• W66160711 hasRelatedWork W2399419505 @default.
• W66160711 hasRelatedWork W2544592512 @default.
• W66160711 hasRelatedWork W2905333097 @default.
• W66160711 hasRelatedWork W80969249 @default.
• W66160711 hasRelatedWork W2114245485 @default.
• W66160711 hasRelatedWork W2187634485 @default.
• W66160711 isParatext "false" @default.
• W66160711 isRetracted "false" @default.
• W66160711 magId "66160711" @default.
• W66160711 workType "article" @default.