UbiManager:A Software Tool for Managing Ubichips

Yann Thoma, Andres UpeguiREDS - HEIG-VD

Yverdon-les-Bains, SwitzerlandEmail: yann.thoma@heig-vd.ch, andres.upegui@heig-vd.ch

Abstract— This paper introduces the UbiManager, a tool formanaging the ubichip reconfigurable circuit. The ubichip is acustom reconfigurable electronic device for implementing circuitsfeaturing bio-inspired mechanisms like growth, learning, andevolution. The ubichip has been developed in the frameworkof Perplexus, a European project that aims to develop a scalablehardware platform made of bio-inspired custom reconfigurabledevices for simulating large-scale complex systems. In this paper,we present the software tool used for designing, simulating,emulating, debugging, configuring, and monitoring the systemsto be implemented in the ubichip. This paper also presents thedissemination plans of the UbiManager, that consist in a webplatform allowing researchers to access the hardware platformfrom any remote base station.

I. INTRODUCTION

The Perplexus project [1] aims to develop a scalablehardware platform made of custom reconfigurable devicesendowed with bio-inspired capabilities. This platform willenable the simulation of large-scale complex systems and thestudy of emergent complex behaviors in a virtually unboundedwireless network of computing modules.

The Perplexus platform will consist thus in a scalablenetwork of ubidules (UBIquitous computing moDULES)equipped with wireless communication capabilities and richsensory elements [2]. The platform is modular for allowingthe application developer to customize his platform set-up. Inthis way the application developer can easily build his systemsetup by selecting what to plug to the ubidule from a set ofperipherals. These peripherals can be different communicationinterfaces (wifi, bluetooth), sensors, actuators, cameras, orflash memories. This modularity is guaranteed by the use ofstandard interfaces such as USB.

At the heart of these ubidules, we use a ubichip (UbiduleBio-Inspired CHIP)[3], a custom reconfigurable electronicdevice capable of implementing bio-inspired mechanisms suchas growth, learning, and evolution. These bio-inspired mecha-nisms will be possible thanks to reconfigurability mechanismslike dynamic routing, distributed self-reconfiguration, and asimplified connectivity. Such an infrastructure will provideseveral advantages compared to classical software simulations:speed-up, an inherent real-time interaction with the environ-ment, self-organization capabilities, simulation in the presenceof uncertainty, and distributed multi-scale simulations.

One of the most critical problems faced by custom recon-figurable devices is the absence of design tools. These devices

are typically developed under projects running for a few yearsand the development of tools are rarely among the prioritiesof the project, making the device very difficult to use. In thePerplexus project, we began both - the design tool and theubichip architecture - almost in parallel from the beginning ofthe project, what have allowed us to develop a synergy amongboth.

In this paper we present the UbiManager, the tool currentlyused for design, simulation, emulation, debugging, configu-ration, and monitoring of circuits on the ubichip. For this,in sections II and III we introduce the ubidule and theubichip respectively. Section IV describes the UbiManagertool, its capabilities, and the design interface. Then, sectionV describes the utilization of the UbiManager for simulation,debugging, and monitoring purposes. Afterward, section VIIdescribes the web interface that allows to share the use ofthese ubichips. Finally, section VIII concludes.

II. UBIDULE

The ubidule is an electronic board that mainly contains anARM processor and a ubichip. The ARM processor acts likethe ubichip manager, allowing the ubichip configuration anda close interaction with it. Currently, we are using an XscalePXA270 running Linux, and it is accessible through Ethernet,Wi-fi, or Bluetooth.

A ubidule should be able to closely interact with its en-vironment. In order to keep the platform general enough, nosensor or actuator has been directly added to the board, butinstead, five USB ports and a microSD card slot allow us toconnect such devices. These ports provide the possibility toplug different communication interfaces like Wi-fi, Bluetooth,or Zigbee. They allow also to dispose of a large choice of USBsensors and actuators developed by different manufacturers,ranging from simple analogue temperature or light sensors tomore sophisticated devices as accelerometers, RFID reader,mice, and servomotors.

The ubidule offers also the possibility of driving an LCD-touchscreen that can be directly plugged onto the board. As itwill be explained later, this LCD-touchscreen is managed bya graphical application running on the ARM processor, and itcan be used for configuring the ubichip, as well as to observeits state.

At this time, we have a first ubidule prototype (figure 1) [2],and includes a Spartan-3 5000 for prototyping the ubichip.

NASA/ESA Conference on Adaptive Hardware and Systems

978-0-7695-3166-3/08 $25.00 © 2008 IEEEDOI 10.1109/AHS.2008.39

207

NASA/ESA Conference on Adaptive Hardware and Systems

978-0-7695-3166-3/08 $25.00 © 2008 IEEEDOI 10.1109/AHS.2008.39

213

NASA/ESA Conference on Adaptive Hardware and Systems

978-0-7695-3166-3/08 $25.00 © 2008 IEEEDOI 10.1109/AHS.2008.39

213

Fig. 1. Picture of a ubidule board

The Xilinx FPGA [4] allows for the emulation of a simplifiedversion of the ubichip, as well as for testing the entire system.

III. UBICHIP

The heart of the ubidule contains a ubichip. This recon-figurable circuit is a new kind of FPGA that implementsspecial features like self-replication, dynamic routing, and aSIMD architecture. In this section, we will briefly describethe ubichip, but the interested reader can find more details in[3].

A ubichip is mainly composed of three reconfigurablelayers. The first one is an array of ubicells, the reconfigurablelogic elements used for computation purposes. A ubicell iscomposed of four 4-input look-up tables (LUT) and four flip-flops (DFFs). These ubicells can be configured in differentmodes like counter, FSM, shift-register, 64-bit LFSR, adder,subtractor, etc. A ubicell can also be configured as a simple4-bit processor, allowing the merging of n ubicells for cre-ating 4n-bit processors. By using this configuration mode, aprocessor array can be used as a SIMD array of processors,with a hardwired on-chip sequencer being responsible for themulti-processor management.

The second layer contains dynamic routing units that permitthe ubicells to dynamically connect to any part of the circuit.Based on identifiers and a concept of sources and targetstrying to reach a correspondent with the same ID, it looksquite similar to the system described in [5], while havingenhancements on different points (cf. [3]). This layer allowthus to create and destroy connections in a dynamic way,allowing the implemented system to change its topology onrun-time.

Finally, the third layer is made of self-reconfiguration unitsthat allow a part of the circuit to self-replicate somewhere elseon the chip, without any external intervention. This mechanismallows also to destroy a section of the circuit. This truly newfeature can be very useful for cellular systems such as neuralnetworks with changing topologies. A neuron can, for instance,decide to duplicate when it has a high level of activity, or it

can destroy itself after a long period of inactivity in orderto leave resourced for other neurons. More details about thismechanism can be found in [6].

IV. UBIMANAGER

A new circuit with fancy reconfigurable features is nice,but without design tools that allow the creation, simulation,and debugging of the implemented circuits, it is nothing but atoy for engineers, requiring a huge effort for implementingthe simplest circuit. Design tools constitute thus a criticalissue when using any type of programmable device, being ita processor or an FPGA.

The typical design flow for an FPGA-based design consistson an initial translation from an HDL description into anetlist, and then from a netlist into a description of thecircuit configuration bits. However, the structure of the ubichipis quite different from those of standard FPGAs that arecomposed of LUTs and DFFs connected to switch matrices.The 4-LUT cell of the ubichip, as well as its non-regularrouting organization did not allow us to exploit existing HDLsynthesizers. Therefore, we conceived a graphical tool in orderto allow the development of Perplexus applications.

UbiManager (cf. figure 2) is the main tool for using thePerplexus platform. It allows to graphically configure eachone of the three reconfigurable layers of a ubichip, and thendisplays the system state during a simulation or the executionon a ubidule at run-time. It can run on a base-station or on anembedded platform as the ubidule.

The software can open multiple documents at the same time,and copy-paste commands allow to easily reuse design parts.Moreover, drag-and-drop is also implemented. Both copy-paste and drag-and-drop permit to include an image of thecurrent selected units in any software that deals with images,such as OpenOffice or Powerpoint. An auto-updater has alsobeen integrated to let the user always run the latest version.

A. Views of the configurable layers

Figure 2 shows the ubicell layer. One can select a ubicellby clicking on it, in order to configure it using a set of

Fig. 2. UbiManager graphical interface showing ubicells

208214214

configuration options through a user-friendly menu. Then, onecan visualize some of the features of the configured circuit.For instance, in the figure, one can differentiate the ubicellsconfigured as independent 4-LUTs in combinatorial mode, andin registered mode, as well as those configured as 64-bit LFSR.The same view can also be used to visualize the system state,as will be described in the next section.

Figure 3 illustrates the dynamic routing layer. The dynamicrouting units are configurable as sources or targets, and thenthe underlying system implemented on the ubicell layer cantrigger a path creation or destroy existing paths. The config-uration and visualization of these dynamic routing units arepossible thanks to this second view.

Finally, figure 4 shows the self-replication layer configura-tion. As described in [6], a self-replicating system requires amorphological description describing a construction path. Thispath allows the further construction of a daughter cell, just byfollowing the morphological description defined by a set ofbuilding flags. The screenshot shown in figure 4 depicts theconstruction path that allows a system to be replicated in theplatform. This view allows thus to edit such construction pathand to visualize the state of a system being self-replicated.

B. UbiAssembler

As presented in section III, a ubichip reconfigurable arraycan implement a SIMD architecture, where a ubicell acts likea 4-bit processor. In that case, a 4n-bit processor can beobtained by merging n ubicells. The SIMD array is controlledby a centralized sequencer that executes a program previouslyloaded in the ubidule SRAM. A special assembler has beendeveloped for this sequencer, as well as a tool for translating itto the binary format. Assembler files can be open within Ubi-Manager, in a text editor with specific keywords highlighted.

Fig. 3. UbiManager graphical interface showing routing units

Fig. 4. UbiManager graphical interface showing self-replicating units

For running a simulation, or an experiment on a ubidule, ifthe project requires the SIMD mode, then the assembler fileassociated with the project is compiled, and sent to the SRAM.In order to ease the debugging of an application, the internalstate of the sequencer can be observed during a run. The stateof every register is displayed in a windows like the one shownin figure 5.

In conclusion, the UbiManager offers a set of interactivemenus that allows to select the different types of logic units,to edit their configuration by selecting among the providedconfiguration modes, and to visualize some of the configuredfeatures in each unit as well as the connections createdon the static and dynamic routing. As previously explained,

Fig. 5. UbiManager graphical interface showing the sequencer state

209215215

there is, at this time, no automatic tools that can generate aconfiguration file based on an HDL description, because of thecomplexity of the ubicell. However, this complexity is due tothe coarse grained architecture, which let standard functionssuch as 4-bit counters be very easy to implement, even onlywith a graphical interface.

V. SIMULATION/EMULATION

After the design phase, the UbiManager allows to simulatea system in order to test its functionality. As the ubichip hasbeen described in VHDL, the simulation is performed withModelsim. A standard Modelsim simulation allows to forcesignals and to observe results in a waveform window or touse a test bench that must be previously written. While veryuseful for traditional designs, this interface is too restrictivefor our application. A third approach for managing Modelsimsimulations is from an external software description. For this,Modelsim supplies a C library that permits to interface aVHDL simulation with some C/C++ code, through the socalled Foreign Language Interface (FLI). In this way, it ispossible to let some C functions be called when certain user-defined signals change their values. The C/C++ code can theninteract with the simulation by setting signals values and byretrieving information about signals in the design.

For this purpose, we wrote a Dynamically Linked Library(DLL) loaded at the starting point of a simulation, which sup-plies a function called on every falling edge of the clock. ThisDLL, called UbiFli, instantiates a TCP/IP server that waits forconnections. The UbiManager that started the simulation canconnect to this server, and then interact with the simulation.The main advantage of using TCP/IP communication reliesin the fact that the same protocol is used to access both, thesimulated circuit on Modelsim and a real ubichip on a ubidule.

From the point of view of a UbiManager, a simulation ora ubidule supply the same functionality. Moreover, severalUbiManagers can be simultaneously connected to the samesimulation/ubidule, and interact with it. It is therefore possibleto have several users observing the same behavior fromanywhere at the same time.

When connections are established, UbiFli waits for com-mands. These commands are:

• Run 1 clock step• Run n clock steps• Run n clock steps with state recovery at each clock cycle• Run as long as no break command is sent• Break a run• Reset the system• Reconfigure the systemAt the end of a command execution, UbiFli sends the state

of the system back to all the connected UbiManagers. Thisstate contains the state of every ubicell, routing unit, and self-reconfiguration unit. When a UbiManager gets the state of thesystem, it updates its graphical display accordingly, letting theuser observe the simulation result.

Figure 6 illustrates a simulation scenario. The followingsteps detail the starting tasks of a simulation.

scan state

quit

step

startload

connect

end

step

UbiManager UbiFli Modelsim

send state

donesend state

step

donesend state

step

Fig. 6. Simulation scenario

1) (UbiManager) Starts simulation2) (UbiManager) Generate configuration files3) (UbiManager) Starts Modelsim4) (Modelsim) Loads UbiFli5) (UbiFli) starts the TCP/IP server6) (UbiManager) Connects to the UbiFli server7) (UbiManager) Do step by step (for instance)8) (UbiManager) Sends command to UbiFli9) (UbiFli) Sends back the system state

A simulation can be observed/managed by more than oneUbiManager, and so acts a ubidule. The ARM runs a TCP/IPserver, called UbiServer, that is responsible to access theubichip. This server responds to the same commands under-stood by UbiFli. Figure 7 illustrates different communicationschemes between a simulation, a ubidule, and four UbiMan-agers. The arrows represent a TCP/IP connection, and theUbiManagers are run on 3 different PCs.

UbiManager

UbiFli

UbiColibriUbiServer

Client interface

Server interface

UbiManager

UbiManager

PC1

PC3

PC2

Ubidule

Fig. 7. Communication scheme between different components

210216216

A. Plugins

At first, the UbiManager was written for the design and sim-ulation of a system implemented for a ubichip reconfigurablearray. It rapidly turned out that some applications neededto interact with the circuit, without human intervention. Forinstance, an intrinsic evolutive hardware system [7] requires agenetic algorithm [8] to run, load configurations into the chip,and retrieve information about the system execution. Thereforea system of plugins has been designed, letting the user write aC++ plugin in order to interact with the simulation. A plugincontains a function called every time the state of the systemchanges. This function can get the state of the system, and canmodify it on the fly.

For instance, a plugin can be responsible for monitoring therouting array. By analyzing the state of the array every clockcycle, it can generate logs or store intermediate configurationsin a file in order to allow, for instance, a post-simulationanalysis of the routing process.

A plugin can manage the simulation and act on the configu-ration bits. For this purpose , a configuration access library hasbeen written, and provides a similar functionality as Jbits [9].Jbits is a Java API that allows to access the configurationbitstream of Xilinx FPGAs. In a similar manner as Jbits, ourconfiguration library offers the possibility of dynamically andpartially accessing the configuration bits of the device at ahigher abstraction level. In this way one can easily modifythe content of a set of registers containing a parameter, a seedfor a pseudo-random number generator, or any building block.

The installation of the UbiManager comes with some sam-ple plugins that can be easily modified by developers to actaccordingly to their needs.

An important feature of plugins is that they can be loadedby different parts of the application:

• UbiManager: If loaded by the UbiManager, the pluginreceives the state of the system only when the UbiMan-ager retrieves this state from the simulation. It meansthat the user has to exploit the ”run n clock cycles withupdates” in order to let the plugin interact at each clockcycle.

• UbiFli: As the ”run n clock cycles with updates” forcesa lot of TCP/IP communication, and so a loss in perfor-mance, the plugin can be directly loaded by UbiFli. Inthat case, a command like ”run n clock cycle” will callthe plugin on every clock cycle, without the need of usingthe TCP/IP connection. With this option, a real gain inperformance is observed. However, no graphical interfacecan be used in this mode, and so a plugin that requiressome user interaction should not be loaded by UbiFli.

• UbiServer: The plugins are written using the Qt envi-ronment, and can therefore be compiled under Linux.UbiServer can then load the plugin, avoiding the sendingof the system state through Wireless. If the applicationallows for the use of this mode, it can offer a huge gain interm of performance, since the wireless communicationrepresents a real bottleneck in the system.

• UbiColibri: UbiManager can run directly on the Ubidule.It can then load plugins if required, as soon as the pluginsare compiled under Linux.

Figure 8 shows the different uses of a plugin after beingcompiled for the correct target system.

plugin.cpp

UbiManager UbiFli UbiServerUbiColibri

plugin.dll plugin.so

CompilationWindows

Compilationembedded Linux

Loadedby

Fig. 8. Plugins usage

B. External application

Plugins, except if loaded by the simulation or by theUbiServer, require the UbiManager to be run by the user.For some applications, it would be more convenient to havea stand-alone program taking care of the interaction with thesimulated/emulated system.

As the UbiManager can connect to a Modelsim simulationor a UbiServer, an interface has been designed in order tokeep a single type of communication between the components.This interface, in the form of a C++ class, can very easily beintegrated in any new software. An application such as oneusing a genetic algorithm could then be implemented with anexecutable instead of a plugin, if needed.

It is also interesting to note that, as every execution passesthrough a server (UbiFli or UbiServer), and a server supportingseveral connections, it is possible to launch an execution withUbiManager, start an application that will connect to thisexecution and then interact with it. The UbiManager willreceive the state updates, and let a user visually observe thesystem state.

VI. APPLICATION EXAMPLES

Up to now, the UbiManager has been used as design tool ondifferent applications that have allowed to exploit the specialreconfigurability features of the ubichip. The dynamic routinghas been used in the implementation of two types of systemsfeaturing changing topologies: ontogenetic neural networksand evolutionary graph models with dynamic topology. Theself-replication mechanism has been used in a particle swarmoptimizer with adaptable size. These three systems wheresuccessfully implemented thanks to the UbiManager designand simulation interface.

The first application example is presented in [10] and [11].These papers present implementations of neural circuits ableto grow by physically creating and destroying synaptic con-nections depending on neural activity. The described modelsinclude a synaptogenetic mechanism that allows to create

211217217

connections, and a synaptic elimination mechanism that allowsto prune the network. Both, synaptic creation and pruningare performed following an activity-driven approach: the moreactive neurons have a higher probability of being highly con-nected, and less active synapses may be destroyed. The creatednetwork is compared with a randomly created network as theone depicted in figure 3. These networks exploit the dynamicrouting mechanism in order to implement the dynamicallycreated and destroyed synapses.

A second application, also exploiting the dynamic routing,is the implementation of evolutionary graph models withdynamic topologies [12]. The models consider two graphs:an interaction graph and an imitation graph. After interaction,agents in our model revise their strategies by an imitationrule taking into account the distribution of payoffs and theproportion of behaviors in their imitation neighborhoods. Themodel of [12] explores a particular instance of this generalmodel in which the interaction graph is a static cycle and theimitation graph is a directed, dynamic small-world networkconstructed over this cycle. With this setup, they try to modelthe fact that individuals often compare and imitate otherswith whom they do not interact, and that this imitation socialnetwork is in general more dynamic than the interaction graph.

Finally, the third application is a particle swarm optimizerwith adaptable size [13] that exploits the self-replicationcapabilities of the ubichip. This implementation considers aPSO algorithm where the number of particles changes duringthe swarm life-time. A particle can decide to self-replicateor to self-destroy depending on the performance exhibited bythe swarm as depicted in figure 9. If the swarm performanceis not good enough the swarm should grow in size and ifit is good enough some particles may be removed in orderto leave reconfigurable resources for other applications. Thissystem results promising for optimizing functions that changeover time and where the size of the swarm may increase anddecrease in order to adapt the swarm to the computationalneeds of a changing environment.

Fig. 9. Particle swarm optimizer with adaptable size

These three applications have used the self and dynamicconfiguration capabilities of the ubichip, but they have alsoused plugins for automatically modifying algorithm parame-ters. For instance, the initialization of the agents’ state andthe payoff matrix in the evolutionary graph application isperformed by a plugin that partially reconfigures the device,and then recovers the agents’ state after each agent’s update.These applications are the firsts to be implemented on theubichip substrate, and their implementation would be just

unfeasible without the UbiManager.

VII. WORLDWIDE USAGE

One of the goals of the Perplexus project is to make theplatform available to anyone who would like to test/use itsnew features. The plan is to build around 100 ubidules beforethe end of the project. In order to fully exploit these ubidules,a web platform is intended to let a user have a look at thestate of the ubidules population.

PHP scripts running on the server side are accessed bothby the ubidules and by the user’s web browsers 1. An activeubidule runs a UbiServer, and accesses one of the scripts every10 minutes to indicate it is ready for an application run. Whilerunning an application, the ubidule connects also to the mainweb server every 10 minutes, letting the server know whetherthe ubidule is running. Both requests from UbiServer allowsthe PHP page to update a status file in which informationabout the ubidules state is stored. At the end of an applicationrun, the ubidule informs the server that it is ready and active,waiting for a new application. Each ubidule is identified by itsIP address, and is marked as active, running, or disconnected.In order to fully detect disconnected ubidules, the date of thelast access from UbiServer is also stored.

When a user asks for the list of available ubidules, the mainweb page only has to check the status file to detect whichone is alive, under exploitation, or disconnected. If one isavailable, then the user can request its use and directly connectthe UbiManager to the ubidule, by copying its IP address.The UbiManager also provides the capability of asking theubidules list to the web server. In that case, there is no needof copying an IP address from the web page, everythingbeing controlled by the UbiManager. In this way, a developerthat has designed a system and tested it through simulation,can rapidly test it on the real hardware, without the need ofhaving a board on his desk. Figure 10 shows a standard usagescenario, featuring a ubidule, an instance of UbiManager, anda web server.

The basic functionality of the distributed platform, currently,does not manage a potential abusive user keeping control onone or several ubidules. The first implementation assumes fairusers, but a second version will include strategies to detectsuch behaviors and block them.

VIII. CONCLUSIONS

The Perplexus ubidule is a reconfigurable hardware plat-form for the simulation of complex systems. As such systemrequires design and verification tools to deal with (from adeveloper point of view), we have created a set of tools toease its use.

The UbiManager allows a developer to create a systemusing a graphical user interface, and to simulate it. Duringa simulation, every flip-flop of the system can be graphicallyobserved. C++ plugins can also be written in order to automat-ically interact with the simulation by retrieving the flip-flopsstate and by changing it if required.

1The website can be attained through: http://www.perplexus.org

212218218

update

read

update

update

update

alive

running

alive

running

ask statusstatus+IP

start

stop

commands

UbiManager Ubidule Web server Status file

commands

Fig. 10. Scenario of a system test on a ubidule, started from UbiManager

Real test on the platform can also be launched from theUbiManager, a TCP interface allowing for a wireless commu-nication with the hardware. As there will be around 100 boardsat the end of the project, a centralized web site permits a userto monitor which ubidule is active, and which of those arerunning an application. The UbiManager can then connect toa free one in order to test a design.

The population of ubidules, being distributed, is thereforeaccessible by anyone from all over the world. It makes Per-plexus an excellent prototyping platform for complex systems.

ACKNOWLEDGMENT

This project is funded by the Future and Emerging Tech-nologies programme IST-STREP of the European Commu-nity, under grant IST-034632 (PERPLEXUS). The informationprovided is the sole responsibility of the authors and doesnot reflect the Community’s opinion. The Community is notresponsible for any use that might be made of data appearingin this publication.

REFERENCES

[1] E. Sanchez, A. Perez-Uribe, A. Upegui, Y. Thoma, J. Moreno,A. Villa, H. Volken, A. Napieralski, G. Sassatelli, and E. Lavarec,“PERPLEXUS: Pervasive computing framework for modeling complexvirtually-unbounded systems,” in AHS 2007 - Proceedings of the 2ndNASA/ESA Conference on Adaptive Hardware and Systems, T. Arslan,A. Stoica, M. Suess, D. Keymeulen, T. Higuchi, R. Zebulum, and A. T.Erdogan, Eds. Los Alamitos, CA, USA: IEEE Computer Society, aug2007, pp. 600–605.

[2] A. Upegui, Y. Thoma, E. Sanchez, A. Perez-Uribe, J. Moreno, J. Ma-drenas, and G. Sassatelli, “The perplexus bio-inspired hardware plat-form: A flexible and modular approach,” Knowledge-Based & IntelligentEngineering Systems Journal, 2008. To appear.

[3] A. Upegui, Y. Thoma, E. Sanchez, A. Perez-Uribe, J. Moreno, andJ. Madrenas, “The Perplexus bio-inspired reconfigurable circuit,” inProceedings of the 2nd NASA/ESA Conference on Adaptive Hardwareand Systems, T. Arslan, A. Stoica, M. Suess, D. Keymeulen, T. Higuchi,R. Zebulum, and A. T. Erdogan, Eds. Los Alamitos, CA, USA: IEEEComputer Society, aug 2007, pp. 600–605.

[4] S. Brown, R. Francis, J. Rose, and Z. Vranesic, Field ProgrammableGate Arrays. Kluwer Academic Publishers, 1992.

[5] Y. Thoma and E. Sanchez, “An adaptive FPGA and its distributedrouting,” in Proc. ReCoSoc ’05 Reconfigurable Communication-centricSoC, Montpellier - France, Jun. 2005, pp. 43–51.

[6] Y. Thoma, A. Upegui, A. Perez-Uribe, and E. Sanchez, “Self-replicationmechanism by means of self-reconfiguration,” in 20th InternationalConference on Architecture of Computing Systems 2007 (ARCS ’07),Workshop proceedings, M. Platzner, K.-E. Grosspietsch, C. Hochberger,and A. Koch, Eds. VDE Verlag, mar 2007, pp. 105–112.

[7] J. Torresen, “Possibilities and limitations of applying evolvable hardwareto real-world applications,” in FPL 2000, ser. Lecture Notes in ComputerScience, R. Hartenstein and H. Grunbacher, Eds., vol. 1896. BerlinHeidelberg: Springer-Verlag, 2000, pp. 230–239.

[8] J. H. Holland, Adaptation in Natural and Artificial Systems. Ann Arbor,MI: The University of Michigan Press, 1975.

[9] S. A. Guccione, D. Levi, and P. Sundararajan, “JBits: A java-basedinterface for reconfigurable computing,” Proc. of the Second AnnualMilitary and Aerospace Applications of Programmable Devices andTechnologies Conference (MAPLD), 1999.

[10] A. Upegui, Y. Thoma, A. Perez-Uribe, and E. Sanchez, “Dynamicrouting on the ubichip: Toward synaptogenetic neural networks,” inAHS 2008 - Proceedings of the 3rd NASA/ESA Conference on AdaptiveHardware and Systems. Los Alamitos, CA, USA: IEEE ComputerSociety, 2008.

[11] A. Upegui, A. Perez-Uribe, Y. Thoma, and E. Sanchez, “Neural develop-ment on the ubichip by means of dynamic routing mechanisms,” in ICES2008 - Proceedings of the 8th International Conference on EvolvableSystems. LNCS, Springer Verlag, 2008. Submitted.

[12] J. Pena, J. Pena, and A. Upegui, “Evolutionary graph models withdynamic topologies on the ubichip,” in ICES 2008 - Proceedings of the8th International Conference on Evolvable Systems. LNCS, SpringerVerlag, 2008. Submitted.

[13] D. Bertizzolo, “Optimisation par essaim de particules auto-replicatifs,”Diploma project report, HEIG-VD, Switzerland, 2008.

213219219