Software Installation

Preliminary remarks

The software is mainly tested on Linux. It has been reported to work on Mac OS X without considerable difficulty, but is is currently not supported by Windows.

Prerequisites

You first need the following python packages

• python
• python-dev
• numpy
• scipy
• matplotlib
• pydot
• lxml

For real-time vizualization, you will need Enthoughts Chaco Module:

• TraitsGUI
• chaco

Finally, a nice matlab–style Python prompt is IPython.

• (Optional) IPython

You can try to install all these packages in ubuntu, add the “universe” repository and run the following command in a terminal:

sudo apt-get install python python-pydot python-dev python-numpy python-matplotlib iPython python-scipy python-chaco python-lxml

Optional packages:

• interval
• Python Imaging Library (PIL)
• TableIO
• setuptools
• wxPython

Installation of pyNCS

• This packages contains all the objects needed for the setup. You can download the latest version of pyNCS by running the following command through your commandline tools.

  git clone https://github.com/inincs/pyNCS.git

For installing the python package go to the downloaded directory and run

sudo python setup.py install

You can do the same for any python package.

Installation of INI python packages

The NCS drivers can be downloaded directly from their respective repositories.

• pyAMDA: this module is required by pyNCS and contains the module to set the biases (responsible: Sadique Sheik, Daniel Sonnleithner)

  svn co https://svn.ini.unizh.ch/repos/ncs/ini/code/python/pyAMDA

• pyAex: This module has the client and servers classes used for Stimulation/Monitoring module the chips and setting the mappings (responsible: Emre)

  svn co https://svn.ini.uzh.ch/repos/ncs/ini/code/python/pyAex

This will install the python module to the appropriate place on your system.

The following is only needed if your computer is going to act as a server, i.e. it will be directly connected to an AEX board. If you don’t know what this means, this means it is probably not required

If your computer is going to act as a Server (i.e. you are going to connect chips to your computer), you also need

• fxload

  sudo apt-get install fxload

• aerfx2 and fx2: the driver for the AEX boards (Daniel)

• udevamda: the udev rule for the amda boards (Sadique Sheik, Daniel Sonnleithner). you may install the udev rules by running make install as root in the udevamda directory

Setup files and chip files explained

The “setup files” and the “chip files” contain information about the hardware setup, such as IP addresses of the servers and mappers, ID of the boards connected, the list of the chips connected to the hardware, how to interpret AER packets, and so on. The pyNCS package comes with them in the test/setupfiles and test/chipfiles folders. Here we explain some details about them.

Chip files

Chip files contain information that the driver needs to get/set biases (parameters) on the chip and translate its address events. This information is contained in a csv file, for example ifslwta.csv. Higher level information relative to the neurons and the synapses present on the chip is contained in an xml file with the same basename, for example ifslwta.xml. Chip files are usually written once for every type of chip, and do not need to be changed.

Setup files

The setup files indicate which chip is connected to which AER interface (e.g. AEX board), the latter being referred to as a slot. Each slot is associated to one channel. There are at least as many slots as there are chips.

There are two xml files for the setup. One is a setup type file, for example setuptype.xml, the other is a setup file, for example setup.xml. The former is the general description of the setup, which you need to modify if you are building a new setup, but stays fixed otherwise. The latter one described which chips are present in the actual setup, and which software modules it should use to access it.

setuptype.xml

Here is an example of setup type file:

<setuptype version="0.1">
    <channelAddressing bits="[14, 15, 16]" name="default" type="monitor"/>
    <channelAddressing bits="[14, 15, 16]" name="default" type="sequencer"/>
    <slot id="0">
        <aerMon in="[4]" out="[0]" />
        <aerSeq in="[4]" out="[0]" />
    </slot>
    <slot id="1">
        <aerMon in="[5]" out="[1]" />
        <aerSeq in="[5]" out="[1]" />
    </slot>
    <slot id="2">
        <aerMon in="[6]" out="[2]" />
        <aerSeq in="[6]" out="[2]" />
    </slot>
    <slot id="3">
        <aerMon in="[7]" out="[3]" />
        <aerSeq in="[7]" out="[3]"/>
    </slot>
</setuptype>

channelAddressing

First, the setuptype must contain two <channelAddessing /> tags. These indicate the encoding of the channels, one for the monitoring ( with attribute type="monitor"), one for the sequencing ( with attribute type="sequencer" input to chip). The attribute bits defines the list of bit positions which encode the channel. For example, the address space used in the above setup type file is:

| channel  | chip address space             |
| 16 15 14 | 13 12 11 10 9 8 7 6 5 4 3 2 1  |

meaning, for instance, that the address event 0x64d2 monitored from the setup will be decoded into channel 3 and chip address 0x4d2.

slot

The setup type then contains a number of <slot /> tags. One chip will occupy one slot, as defined by the associated setup.xml file (see below). The id can be anything, but it must match with the associated setup file. In the setup type file, the slots define how the channel of its sequencer and the monitor. Usually, you only need to define the channel number in the attribute out for <aerMon /> and in for <aerSeq />. The others are used in special cases.

For example, take <slot id="3">:

<slot id="3">
    <aerMon in="[7]" out="[3]" />
    <aerSeq in="[7]" out="[3]" />
</slot>

This slot has <aerMon in="[7]" out="[3]" /> , meaning that the address 0x64d2 will be interpreted as originating from channel number 3, meaning the chip in slot 3. The number in brackets refers to the channel number encoded by the channel bits. In the example above these were bits 16 15 and 14. The same slot contains the tag <aerSeq in="[7]" out="[3]" />. This indicates that, to stimulate synapse 0x4d2, a 0xe000 (corresponding to 7 * 2^13) must be added.

Again the in in aerMon and the out in aerSeq are usally not used, so their function is not covered here.

If possible, the setuptype will be checked against a DTD available online (Document Type Definition)

setup.xml

The setup.xml file describes which chips fit in the slots defined in the setup type. All the tags in setup.xml are enclosed by the <setup> <setup/> tags. The <setup> should contain <chip> tags, one for each chip. Here is an example:

<?xml version="1.0" ?>
<setup>
<chip chipfile="chipfiles/ifmem2.csv" id="ifmem0" slot="0">
    <configurator module="pyAMDA.api">
        <parameter name='host'>zsd</parameter>
        <parameter name='board'>T03</parameter>
    </configurator>
</chip>
<virtualchip chipfile="chipfiles/linear.csv" id="seq" slot="1"/>
<defaultchip chipfile="chipfiles/linear.csv" id="default"/>
<communicator module="pyAex.api.com_aexionet">
    <parameter name='host'>zsd</parameter>
    <parameter name='fps'>5</parameter>
</communicator>
<mapper module="pyAex.api.mapconf_aexnet">
    <parameter name='host'>zanzara2</parameter>
    <parameter name='version'>1.0</parameter>
</mapper>
</setup>

Let’s analyze it attribute by attribute.

chipfile

Usually chipfiles and setupfiles are stored in the client in some common directory, it could be /usr/share/ncs/ or ~/.ncs, so that every experiment just refers to that common source. If this is not the case you have to make sure setupfiles correctly point to chipfiles.

id

This defines the name of the chip. This name will be used in pyNCS to identify it.

<configurator>

indicates the configurator API which should be used to access the chip biases. In this case, it contains the information about which chip is connected to which host (server) and which AMDA board – the board that gets/sets biases on the chip. The attribute module=pyAmda.api is the python module implementing the configurator API. The parameter elements are used as keyword arguments for that module, in this case {‘host’:’zsd’,’board’:’T03’}. The actual id of the AMDA board should be written on a sticker below the board itself, e.g. could be AMDA #2.09.

slot

what we call the channel. On top of the FPGA mounted on the AEX board there should be a sticker referring to the channel number. In this case it should be FES 0.

In addition, there are <virtualchip> and <defaultchip> tags. The former defines a chip which does not physically exist, therefore does not have a configurator. It is typically used to provide ‘input neurons’. The latter (<defaultchip>) defines the default virtual chip to use if a slot that is defined in setuptup is not present in the setup.xml. Note that <defaultchip> does not take a configurator element, therefore defaultchip is only specifies virtual chips.

The last fields of the setup.xml file describes which modules should be used to communicate with the setup:

<communicator module="pyAex.api.com_aexionet">
    <parameter name='host'>zsd</parameter>
    <parameter name='fps'>5</parameter>
</communicator>
<mapper module="pyAex.api.mapconf_aexnet">
    <parameter name='host'>zanzara2</parameter>
    <parameter name='version'>1.0</parameter>
</mapper>

<communicator> and <mapper>

indicate the modules implementing the respective pyNCS API (communicator or mapper). As with the <configurator>, the parameter elements are used as keyword arguments for that module. The ones indicated above are probably the ones you would like to use. See pyNCS documentation otherwise.