3D visualisation of the mapping ofa neural network model onto

a neuromorphic hardware system

Projektpraktikum Informatik

Supervisor: Eric Muller, Daniel Bruderle

v2

1 Introduction

The Electronic Visions group [1] of theKirchhoff Institut fur Physik (KIP) is de-veloping digital hardware with analog maincomponents to simulate neural networks.This approach of using ‘neuromorphic hard-ware’, which is not just application-specificreconfigurable hardware for numerical simu-lations but rather has analog spiking neu-rons, which operate in parallel for them-selves, allows for faster than real time sim-ulation of neural activity, greatly facilitat-ing experiments. As a first stage a chip(‘Spikey’) with 2 synapse arrays, each prop-agating to 192 artificial neurons, which to-gether with their array of synaptic weightsform a core and in turn are able to forwardpropagate to every other neuron of its core,was developed. However to reduce the com-plexity the connections between neurons ofdifferent cores are far more limited, a de-sign principle similar to the kind of biolog-ical networks targeted, exploiting the spar-sity of the connection matrix. This createsunfortunately the problem of allocation ofthe hardware neurons which correspond tothose of the biological model a user of thesystem has, especially for the second stageof this system [2] which greatly increases thenumber of possible neurons, synapses andthe complexity. This mapping process isdone by algorithms, developed at the TUDresden, that don’t need action from theuser who doesn’t need intimate knowledge ofthe hardware and its limitations but rathercan use the abstracting Python scriptinglanguage interface PyNN1 [3] that is devel-oped in conjunction with other groups ofother universities within the scope of theFACETS Project [4] and allows to perform

1pronounced a like ‘pine’ tree

experiments interchangeably on neuromor-phic hardware as well as, in principle com-pletely limitation free in-software simulatorslike NEST, NEURON.

The algorithms use an abstract graph ofthe hardware and another one for the neuralnetwork, both subclassing a common highlygeneric GraphModel. To visualise2 the map-ping of neurons and synapses of a biologi-cal neural network model (which for biologi-cal simulations should be three-dimensional)to the hardware (which is effectively two-dimensional) in order to help the developeror user of the software environment in itsverification, and the models themselves, theinternship of Tobias Harion [5] resulted in amodule to the mapping software for 3D dis-play using OpenGL.

2 glVisu‘glVisu’ is a set of C++ source files(GraphVisu.h / GraphVisu.cpp, glCon-trol.h / glControl.cpp) which use the CAPI of OpenGL (the 1.X fixed-functionpipeline) for 3D rendering of the graphsand GLUT (OpenGL Utility Toolkit) forplatform integration like window man-agement and user input with mouseand keyboard. It is is invoked bythe function AlgorithmController::StartVisualization() from the C++-code that is managed by Boost.Python forthe interoperability with Python.

Although more of a demonstrator it has arange of features. Neurons of the hardwareare displayed on a square lattice as spheres,the ones used in a different colour as theothers ones. The neurons of the bio model

2As a compromise American English is used forthe software, a German variant of British Englishfor this report

2

are also little spheres and can be positionedon a cubic lattice, a square lattice, or onrandom positions on the inside of a sphere.They can be selected separately by clicking,by pressing of a key, or by aiming at themand pressing another key. For a selected bioneuron parameters from the graph are dis-played on-screen, the outgoing synapses aredisplayed with different colours for excita-tory and inhibitory impact and a mappingconnection to hardware neurons, the onlypart of‘stage 1’ that is included, can be show.There is a context menu for the window withoptions, like what components to show orhide.

The user moves around in the 3D spacein first-person navigation with mouse inputfor direction and keyboard for translation.There is also a full-screen mode which locksthe mouse, giving standard game controls.

A console can be opened for input of alimited set of commands, the most impor-tant being the one to input a fille name fora simulation mode in which a spike train isloaded from the file and the spiking neuronsare eye-catchingly coloured.

The scene can be rendered with ananaglyphic 3D effect for use with a set offiltering glasses.

The neurons and synapses of the bio graphare tranferred into structs for faster andeasier rendering. In this process bio neuronsare assigned numbers according to the orderin which they appear in the graph.

Because GLUT is a C-API that executesuser-provided callbacks, a global variable ap-proach with wrappers is used to mix C call-back functions and C++ member functions.

3 Course of the intern-ship

The internship was done for the Soft-warepraktikum credit in the semester breakin February3 and a good part of March of2009 with only short breaks for a blockedlecture and a short excursion.

The most park of the work was done at theresearch group’s office at the opening hourson a small laptop computer4 which had tostay in place. There was an advertising giftlike set of red-blue anaglyph glasses made ofcardboard.

As the GraphModel classes depend ona whole range of in-house developed soft-ware and in particular the build systemis building the complete shared library‘pyhal c interface s1v2.so’ the glVisu codecould only be compiled in-house. For testingPyNN had to be run.

Ahead of the internship the papers [2] [3]were provided partially in pre-release ver-sion. Mostly in the first two weeks a ref-erence book at the university library [6] wasworked through off-time.

The group requires portable, and prefer-ably open source software, and for that rea-son OpenGL with its wide spread supportwas chosen, with the benefit of its client/ server model allowing using the softwareover ssh. The library GLUT, although more, had additionally the advantage of beingcross-platform. In addition to that, an upperbound was set by the requirement of the soft-

3Coincidentally the moment 1234567890 in theUNIX epoch was almost spent working on thisproject.

4System: HP Compaq 6910p, CPU: Intel Core 2Duo CPU T7300 @ 2.00GHz, RAM: 1978 MiB,GPU: Intel Corporation Mobile GM965/GL960 In-tegrated Graphics Controller (rev 0c), Resolution:1440x900

3

ware being able to run on older hardware,which was the reason the full OpenGL 3.0function set could certainly not be used andone reason no parts of OpenGL 2.1 wereused but instead the limited fixed-functionpipeline of OpenGL 1.X.

The C++ Standard Library was used forcontainers (STL) and string manipulation.

Tasks for development on glVisu were amore flexible colour selection with a highcontrast mode and white background, mak-ing the hardware neurons selectable, dis-playing ‘parameters’ of them and doing thevisualisation of the interconnections. Fur-thermore concepts for the visualisation of‘stage 2’ and the interactive editing of themodel should be developed. As the workprogressed more tasks were introduced.

While the projected time for the actualwork as well as the report was 4 weeks, thiswas more or less doubled.

A lot of time was spent as a first part oncleaning up and structuring the code base forthe existing initial visualisation to make itmore accessible and most of all easier to im-plement the given tasks, like the essentiallyquite easy dynamic replacement of colours.As it was promised work done on the pro-gram would be of actual use in the devel-opment and use of the neuromorphic hard-ware, time was spent on making it easy tofurther build on it and correcting as needed.Close to everything was revised in the pro-cess, leaving little untouched. The resultingsource files have about 3300 sloc from previ-ously about 1800 sloc

As no documentation between, preferen-tially graphic for easy access and reference,could be provided on the relevant parts oflayout of the chip and its relation to thehardware model – possibly something thevisualisation was supposed to be of use to,but questionable giving the lack of knowl-

edge by the person doing it and given thatof the 4 components of homogeneous coordi-nates only 2 are used – but only a couple ofshort conversations about the topic, the taskof drawing the ‘stage 1’ emerged to be quiteunsatisfactory. This, combined with the ren-dering speed problem and the developmentstate (paradoxically the work was supposedto help with this), was the reason no workwas done on ‘stage 2’.

Because of this work was spent on a 2Ddisplay of the hardware and improving thesource package in general for further devel-opment.

The tools KCacheGrind and callgrind fromvalgrind were used to some extend toprofile the drawing process. The resultswere mixed owing to the abundant and in-tertwined function calling necessary in theOpenGL 1.x API on one hand and on theother hand the dramatic slowdown whenrunning on the valgrind virtual machineand the difficulty of setting up a meaning-ful test. However, unfortunately there wasa lot of compulsion for speed so quite a lotof time was spent on, regrettably, prematureoptimization.

The source code was documented in largepart with comments in the Doxygen syntaxand so can be compiled into a software ref-erence documentation. While this was pre-viously the case, this needed work giving theamount of change.

For further improvement of the applica-tion a couple of things were investigated.

Looking into the cross-platform applica-tion framework Qt for a native C++ re-placement of GLUT for improved and eas-ier usabilty, and better multi-view handling,seemed promising and resulted in more sep-aration of the displaying process.

Improvement of the stereoscopic displaywas researched.

4

First and foremost for faster rendering,but also for more rich visual presentation thefeatures that separate OpenGL 3.0 and 2.1from 1.X like Vertex Buffer Objects werelooked into. More advanced animation tech-niques like keyframe animation were consid-ered.

For better and easier image generation thepossibility of rendering in higher resolutionand output with a library like libpng.

The work on glVisu was incorporated inthe dissertation of Daniel Bruderle [7, sec-tion 3.2.6 / pp. 68-71] in the form of a coupleof screenshots.

The looping functionality of the simula-tion was done in very short time, and giventhe groundwork very easily, a short time af-ter the end of the internship to be used in atelevised interview.

4 Contributions

4.1 ImprovementsBeyond the tasks to be completed a coupleof other things were done to lay the ground-work or be of help in the development.

To improve speed additional structswere introduced as suggested in [5] for therelevant data from the hardware graph,hw neuron, hw core, hw syndriver (whichis an either internal or external input witheither positive or negative synaptical weightfor all neurons of a core), which keep refer-ences to their corresponding nodes for lessfrequently used information, in addition tobio neuron and bio synapse which were al-ready in existence.

The workings of these structures werechanged in the way the they reference eachother. Instead of keeping the index intoan array, this indirection was avoided to

gain speed and let later manual editing bythe user become feasible without , by di-rectly linking the nodes together. For thismore difficult process a map was used in thenew transferGraphs() member function,using the pointer as a key to semi-finishedsynapses. If parallel editing of the originalgraph and the copy turns out to be imprac-tical, this transferal could be repeated, butthis is certainly bad for much larger graphs.

The code was cleaned up and partlyrewritten. A first step was automatic for-matting and rearrangement. The codemakes use of namespaces, enums. Of theStandard Library string, ostringstream,istringstream, list, vector, set, map,pair, and the respective iterators wereused, with for example the capacity reservedin advance. C-style strings were avoided asmuch as possible.

Instead of permanent casting the OpenGLtypes were used where sensible. It was aimedfor const correctness.

The parsing of commands was somewhatsimplified. The shortcuts were made to usekeycodes where character literals could acci-dentally replaced or mistaken.

The layout algorithms, which were previ-ously assuming a specific neuron count, werecorrected and reverting to the positions fromthe model was made possible.

A command was introduced to put thecenter of masses and bounding boxes of thebio neurons and the hardware in respect toeach other independently of their positionsin their own private frame of reference. Andanother command to set the position of theorigins of the bio model and the hardwaremodel in the scene, putting the matrix stackto good use.

The stereoscopic mode was revised andmade more flexible given more and a colourtheme introduced with a constrained like

5

palette so as to have three dimensional partsof the image always in both independent im-ages.

The hardware neurons were made able tobe selected in consecutive order, like previ-ously the bio neurons, but with both enu-merations repeated at the ends.

Information in the graph model regard-ing the synapses, hardware neurons, synapsedrivers, in addition to the bio neurons isnow given in the on-screen display and eas-ier extensible. Giving the groups of infor-mation translucent background boxes wastested, but is not in the final version.

A very helpful new feature is saving theposition and viewing direction to be able torestore them later using shortcuts.

To help with orientation and the position-ing using the commands, coordinate axes aredrawn colour-coded RGB for the x (red), y(green), z (blue) coordinates of the right-handed coordinate system. Also for orien-tation crosshairs were added.

The position in space and line of directioncan now be set with the console and out-putted to the console. Mind that the outputvalues are the rounded off accumulations ofmultiple steps with in floating point arith-metic, so feeding back the values will resultin slightly different position and orientation.

The simulation mode was improved withan integration time setting by which can becontrolled how long a spiking neuron is dis-played as such. The outbound connectionscan be shown. Furthermore the simulationcan be paused, for example for inspection.The animation can now be looped, ended atthe last event or continue running like previ-ously. The last option was kept combinedwith the ability to enter simulation modewithout a valid simulation file in order toget an idea of the frame rate.

Boost.Python installs a signal handlerthat prevents termination while running theunmanaged C++ code. For that reason arequirement was to install a custom handlerfor the SIGINT signal. After the interruptionthe old handler is restored.

As a measure to prevent unintentional ter-mination, the shortcut was changed to use akey combination. Conversely it leaving thefull-screen mode was made to be more in linewith expectations.

It was tested to use only decimal frac-tions that are exact in binary representationwith only more significant mantissa bits set,preferably few, for better graphics quality.

4.2 Changed

The responsibility of the classes was changedwith GraphVisu as an entry point, handlingof the data and drawing of the models, andglControl for user interface, managementof OpenGL and control flow. See Section 5.3for obvious improvements.

By using the freeglut extension to GLUTglutExitMainLoop and the option GLUTACTION CONTINUE EXECUTION the API usercan now simply use a blocking call toglControl::show() instead of knowing theintrinsics of a threading workaround.

The menu was newly arranged and furthercompleted. Various menu entries for display-ing options of the model were added, for ex-ample to show the hardware only. It wasmade more compact by having a single tog-gle entry instead of two normal ones, whichwas also done for the keystrokes. Instead ofsimulating key presses, the keystroke han-dler now invokes the menu functions whichallows for easy reassignment of the keys butcould be further improved by more commonfunctions.

6

The shortcuts for plane, sphere and cubepositioning were permuted so as to be moremnemonic.

4.3 Drawing of the hardwareWhile previously only the hardware neu-rons and the labels of the cores were in thescene, now more components are shown: thesynapse drivers, the array of their outputweights and various connections like the con-nection of hardware neurons to other hard-ware neurons via the synapse drivers and thearray.

The hardware neurons were given morefitting little cubes using glutSolidCube,while for the synapse driver a simi-lar function solidWedge(length,height,, width) with correct normals was pro-grammed. The core is now surrounded bya rectangle and the core names slanted forviewing in top-down view.

The difficult part is the weight matrix, be-cause of the more than squared amount ofweights. For that reason they are but lit-tle squares that have a linear interpolatedcolour depending on their value from low val-ues to high values and sign, with a specialcolour for zero.

Synapse drivers getting their input notfrom their core are coloured differently, thesame holding true for mapped hardware neu-rons.

The hardware was more or less drawn ina more logical than physical way. Com-pletely unattached from that fact a problemwas that the weights couldn’t be read fromthe graph model as they are not included inthe stage 1 graph model. For that reasona realistic configuration was not depictable.Rather random values were generated withp(0) = 3

4 and the weight linearly decreasingdown to zero for increasing weights by in-

verse transform sampling, which was tested.The synapse drivers that are configurablewith numbers smaller than 192 were givena 40% chance to be FEEDBACK or FEEDBACK2instead of EXTERNAL.

4.4 SelectionPreviously out of the object in the scene theuser could only select the bio neurons. Nowin addition to focussing on bio neurons, theuser can click as well on bio synapses, hard-ware neurons, mapping connections betweenthe two graphs, and synapse drivers. Whenconnections are selected information is alsogiven on the binding partners.

In addition to the focus mode, a selectmode was incorporated, which can be ac-tivated through the console. In this modefocus is not changed, but sets of objects canbe selected, which can be read out later fromdata members of GraphVisu with a name ofthe form selected*, as a way to pass infor-mation on to the controller. The invoker canalso read out the last selected item type, thelast selected item per type. The same holdsfor the items. This was done to make the vi-sualisation more useful to the mapping pro-cess, by not only showing the result withoutoutcome, as progress to modification withinthe visualisation instance was limited to theimprovement of the graph transferral anddata structures (see 4.1). It could be usedfor batch processing as well.

The detection is done by using OpenGLsupport for picking with the same basic prin-ciple that it was done previously. With thehelp of gluPickMatrix() a projection ma-trix is calculated, that restricts the viewvolume in such a way that its projectionon the screen surface is within the sur-roundings of the mouse cursor. By set-ting a special rendering mode by invocation

7

of glRenderMode(GL SELECT) all the primi-tives of all the objects that are then renderedget an assigned key value, that is chosen tobe distinct for each object, in a buffer thathas previously to be specified. The key valueis then mapped back to the object with thehelp of a table. Since multiple types of ob-ject are now selectable, each type got its owntable that is populated anew for each draw-ing cycle with the help of a numDrawn vari-able and the keys given to the API have anoffset calculated from the total number ofthe elements of each type. As this packs thetable entries tightly, care must be taken notto draw elements multiple times. There isa way to built a hierarchy, but it was notused as it appeared to be a waste of space.Another approach would have been to useparts of pointers for identification. Use ofthe special rendering mode can be avoidedby colour-coding the objects and then read-ing the pixel values from the frame buffer,but this makes the selection of underlyingobjects, which was planned, quite harder.

4.5 Colour managementAll occurrences of colour usage that werepreviously distributed as literals all over thecode base organized with a color schemestructure with member names that corre-spond to the logical meaning. At the mo-ment there are three hard-coded themeswhich can be selected using a ColorSchemesenum, including a higher contrast one withwhite background for printing and presen-tation with a beamer. This managementallows for easy introduction of nice im-provements like coloured headings of theparameter boxes that separate them visu-ally. style scheme is another structurethat, at the moment, bundles the propertiesof synapses, including how thick the con-

nections are drawn depending on synpaticweight.

Previously only either inbound or out-bound connections could be viewed for a se-lected neuron. By using OpenGL line stip-pling simultaneous presentation became rea-sonable.

4.6 Viewing modesSince a 2D view of the hardware is simplymore practical a 2D view mode was inte-grated which can also be used as an overlayto the conventional 3D mode giving a bom-bardier perspective. This last, effectivelysplitscreen, view is more useful with wideaspect ratio of for example 16:9. The zoomfactor of the 2D view and the field of viewof the 3D view can be set using the con-sole. Combined with the commands and theunderlying member functions for placementthis proved to be useful in development. Atthe same time it made the display code moregeneral.

However, because the scene is now ren-dered twice, it is unpleasantly slow on thedevelopment system.

4.7 Rendering speedWith the provided target hardware theframe rate is noticeably slow, especially inthe split screen mode. By running the sim-ulation in continuous mode the update ratecan be seen without changing the view man-ually (when simulating as an end in itself thehardware model should be hidden).

The bottleneck is the high vertex count(589 824) for the triangles (196 608) of thetwo cores. In comparison to contemporarycomputer games this is quite high given thesimplicity.

8

In addition to the display list, that can becompiled by the graphics driver into an ef-ficient format and saves data transfers andfunction calls, that was used previously forthe spheres, display lists for the other itemswere used. Each was core was given a list,handled by the core structure, which is up-dated as needed. Replacing the squares withdots was tested, resulting in better perfor-mance but unusable graphics and further-more painting only non-zero weights.

Leading to the conclusion that that in thisway not many cores can be dsplayed.

5 Proposals

5.1 Miscellaneous. . .

By switching to Qt, the user interface forediting of the graphs would be easier to de-velop.

If not choosing to replace GLUT then themenus could be improved by rebuilding themenus after each change of state.

. . .The bio model should be scalable and ro-

tatable around the vertical axis.. . .Entering commands would be a lot more

useful if a command history was retained.The GNU History library could be used,making it easy to persist.

. . .There should definitely be an Easter egg

in the form of replacing the bio neurons withUtah teapots.

5.2 Rendering speedWhile the drawing could further benefit fromadditional display lists for drawing of the bio

neurons, especially if there are a lot more ofthem or all synapses are displayed, this willnot solve the problem of too many weightswithout dramatically better hardware of thefar distant future. But as the weights are notreally that important or helpful if they arefar away, they can simply be left out for coresthat are not in the field of view or distantones, or somehow combined into a meaning-ful form. Animation would be quite hard.

However, it could be that using more re-cent features of OpenGL can bring improve-ments. Using Vertex Buffer Objects could beuseful by avoiding branching and save theinitial costs, but the display lists probablyuse a similar mechanism anyway and then alot of colour values, that are not very infor-mative, have to be copied.

For better analysis a frames per secondindicator should be included.

By rewriting to use GLSL shaders forthe different components the graphics couldnot only improve, but another technique be-comes possible: using texture memory tostore the values of the weights and then afragment shader to read out the right value.Rather than compiling the texture with re-stricted resolution and then simply applyingit to the area of the weight array, this couldbe made to look similar and even more ap-pealing to what is now being displayed.

5.3 Software architectureWhile there were a couple of reasons the twoexisting classes were kept it seems naturalto divide them up massively into a lot moreclasses and source files.

Most importantly the hardware modelshould be drawn by a hardware version spe-cific subclass of a more general hardwaredrawing class. This would make necessarychanges to the layout algorithm as the graph

9

model changes localized to this class alone.The stage 2 hardware could be another sub-class.

There should be a class or template forencapsulation of the selection mechanism,making it much less verbose, redundant andmaintainable.

The console should be managed by a classfor its data and parsing, and using a com-mand line history class. Another class canthen display the state on the screen.

There should be a single concise class toread spike trains, that even could be easilyreused.

The and keystroke and menu handlers andtheir callbacks should be put into a separatefile respectively.

Instead of retaining switching dependingon a lot of flags, special subclasses that drawa part could be used in some cases to savesome of the accompanying costs and makethe drawing code more readable.

There should be a better setup to compilethe code.

6 Known issuesKno

10

Appendix A

Updated user manual

1 InvocationTerminate using the window controls of theplatform, the menu, shortcuts, the console,or from the Terminal with Ctrl + c .

1.1 PyNNThe visualisation is displayed when pass-ing the visualization keyword argumentto the simulation function PyNN.run.

1.2 C++Usage of the visualisation can look like thefollowing. The models have to be properlyinitialised.

1 BioModel bioModel ;2 HWModel hwModel ;3 // . . . i n i t i a l i s e models . . .4 GraphVisu∗ gv = new

GraphVisu(&bioModel , &hwModel ) ;5 gv−>contro l −>show ( ) ;

Before the blocking call of show() prop-erties of the display can be changed on theGraphVisu class instance. A Doxygen APIreference can be compiled from the headerfiles.

2 ShortcutsSee Table 1.

3 CommandsSee Table 2.

Remember the console is opened with+ ˜ , ˆ .

4 MenuSee Table 3.

11

Key Actionw , a , s , d move forward, left, backward, rightr , f move up, down

Esc exit visualisationEsc exit full screen mode

+ Q exit visualisation+ F maximize window

g resize window to 800x600+ ˜ , ˆ open the console

print information (position and direction ofthe camera)

o cycle through the bio neuronsAlt + o cycle through the hardware neuronsk toggle display of synapsese toggle display of synapses in the animationh toggle display of hardwaren toggle display of core namesi toggle display of mappingc start the simulation

+ C end the simulationSpace pause / continue animation

1 , 2 , 3 , 4 , 5 timestep 0.01 (new), 0.1, 1.0, 10, 100 (default1.0)

u position neurons on a cubic latticep position neurons on a square latticej position neurons randomly within a sphere

+ J reset positions to the original positions fromthe bio model

+ V save viewv load viewt , + T enable / disable cullingz , + Z toggle cull back / front facesb , + B switch transparency on / off

Table 1: Shortcuts available. New functionality in italics.

12

Command Action

close the consolequit exit the visualisationhelp print (not really helpful) help to stdoutset neuronid <n> select a specific bio neuronset mode select / set mode focus change mode to select/deselect bio neurons,

bio synapses, hardware neurons with themouse into a list with visual feedback, or toshow information and mapping

set anaglyph / unset anaglpyh turn on/off anaglyph effect forset hwmodel / unset hwmodel show/hide hardwareset bio conn / unset bio conn draw synaptic connections in the bio modelset param / unset param Show/hide the names and parameters from

the graph model of selected itemsset simfile <name> use the file with the provided name for the

simulationset simtime <t> set the simulation time to the instant pro-

videdset timeinterval <interval> set the step size of the simulation (default

1.0)set integration <time> set for how long after a spike event a neuron

is displayed as active (default 10.0)set borigin <x> <y> <z> set the origin of the bio neuron locations to

the specified coordinateset horigin <x> <y> <z> set the origin of the hardware to the specified

coordinateset origins set the ’center of mass’ of hardware and bio

model to lie on the y axis, with the hardwarebelow y = −5 and the biomodel on top ofy = +5

set pos <x> <y> <z><heading> <pitch>

set the camera location to the given posi-tion (heading and pitch in degrees) (default(−15.5, 1..0, −7.0, 135.0, −22.5)

set pos <x> <y> <z><target-x> <target-y><target-z>

set the camera location to the given position,looking at the target position

set 3d set the view to 3D (default)set 2d set the view to 2D, looking down along the y

axis

13

set 3d2d set the view to 3D with a 2D bombardier per-spective looking down along the y axis dis-played on the right side

set fov <fov> set the field of view in degrees for 3d display(default 50)

set zoom <factor> set zoom level for 2D display (default 0.0625)

Table 2: Commands available in the console. New functionality in italics.

14

Menu entry ActionPositioning x menu for positioning of the bio neuronsx Original (J) reset neurons to the positions provided by the

graph model (default)x Cube (j) put the neurons on a cubic latticex Plane (p) put the neurons on a square latticex Sphere (u) put the neurons randomly on the inside of a

spherePerformance x menu for performance and testing settingsx Select GL FLAT shading model use the simpler flat shading modelx Select GL SMOOTH shading model use the more complex smooth shading model

(default)x Enable culling enable the culling of back faces and / or front

faces (default)x Disable culling disable cullingx Cull back face cull back faces, show front faces (default)x Cull front face cull front faces, show back facesx Enable fog enable simple OpenGL fogx Disable fog disable fog (default)Full-screen x menu for full-screen display (leave with Escx 640x480x 800x600x 1024x768 newx 1280x800x 1280x1024x 1440x900x 1600x1200 newx Leave full-screen leave full-screen modeSimulation x menu for the animation of a spike train from

a filex Start simulation change in to simulation modex Pause / Continue toggle running of the simulationx End simulation leave the simulation modex Reset time to zero reset simulation to the beginningx Continuous simulation keep simulation running at the end of the

spike trainx Load file load the simulation filex Loop animation continue the simulation at the end of the

spike train beginning at its startDisplay options x menu for displaying options of the bio model

and the hardware model

15

Menu entry Actionx Show parameters show on-screen display with information on

the selected items (default)x Hide parameters hide on-screen displayx Toggle bio graph show/hide bio model (default show)x Toggle targeted neuron identification emphasize postsynaptic neuron (default on)x Toggle synapses show/hide synapses (default show)x Toggle incoming synapses toggle display of synapses from presynaptic

neurons independently of those to postsynap-tic neurons (default hide)

x Toggle outgoing synapses toggle display of synapses to postsynapticneurons independently of those from presy-naptic neurons (default show)

x Toggle only synapses of focused show/hide synapses from focused neuron orall synapses (default single)

x Toggle animation of spiking synapses display the synapses (incoming / outgoinglike configured) of a spiking neuron in thesimulation also (default off)

x Toggle hardware graph toggle display of the hardware model (defaulton)

x Toggle core names toggle display of the core labels (default on)x Toggle mapping toggle display of the mapping connections be-

tween bio model and hardware model (de-fault on)

x Toggle only mapping of focused switch between displaying all mapping con-nections or those of a focused hardware orbio neuron (default single)

x Transparency on (b) turn transparency onx Transparency off (B) turn transparency off (default)x Maximize window (F) maximize the visualisation windowx Enable anaglyphic 3D render the scene as a 3D anaglyph imagex Disable anaglyphic 3D turn of anaglyphic 3D (default)Colors x menu to change between colour themesx Black is beautiful black backgroundx Higher contrast white backgroundx Safe colors for anaglyph images use colours that have components in both fil-

tered imagesQuit (q) leave the visualisation

Table 3: Menu items available. New functionality in italics.

16

Appendix B

Screenshots

(a) synapse selected and mappings be-tween two pairs of bio and hardware neu-rons, repositioned bio model, light theme

(b) 3D2D mode with inbound connectionsshown, mapping connection shown in bothviews, crosshairs visible

(c) console open, syndriver selected,crosshairs visible, fog turned on, bio graphhidden, axes visible, starting location

(d) 2D mode, console showing positioningcommand, parameters and bio model hid-den, light theme

Figure 1: Four images with the same graphs. Colour weight disabled set to translucentfor the screenshots.

17

References

[1] url: http://www.kip.uni-heidelberg.de/vision/.[2] J. Schemmel, J. Fieres, and K. Meier. “Wafer-Scale Integration of Analog Neural

Networks”. In: 2008 IEEE International Joint Conference on Neural Networks (IEEEWorld Congress on Computational Intelligence). (June 1–8, 2008). Hong Kong: IEEEPress, 2008, pp. 431–438.

[3] D. Bruderle, E. Muller, A. Davison, E. Muller, J. Schemmel, and K. Meier. “Estab-lishing a novel modeling tool: a python-based interface for a neuromorphic hardwaresystem”. In: Frontiers in Neuroinformatics 3 (2009), p. 17.

[4] url: http://facets.kip.uni-heidelberg.de/.[5] T. Harion. “3D-Visualisierung einer Abbildung von neuronalen Netzwerkmodellen auf

eine neuromorphe Hardware”. In: (2008), p. 33.[6] Programming guide: the official guide to learning OpenGl, Vers. 1.2. eng. 3. ed.,

[Nachdr.] Reading, Mass.: Addison-Wesley, 2002, XL, 730 S.[7] D. Bruderle. Neuroscientific Modeling with a Mixed-Signal VLSI Hardware System.

2009.

18