Personal tools

Design of Scalable Event-driven Neural-Recording Digital Interface

From iis-projects

Revision as of 16:51, 20 February 2019 by Pschiavo (talk | contribs) (Project description)
Jump to: navigation, search

Introduction

Human Computer Interfaces (HCI) are devices that decode the human activity and use the decoded information for a wide application range: to control games in the entertainment field (through the activity of the brain or the muscles), to predict epileptic seizures, to control prosthesis or simply to record data for scientific studies. The human activity can be extracted invasively or not. Invasive methods can be used to sense: the extracellular single neuron activity (action potentials or spikes) with very tiny electrodes close to the neurons; an average communication among neurons close to the electrode via neuron’s axons via local field potentials – LFPs. Specifically for brain activities, ECoG is a signal used to acquire even more neurons ‘activity more superficially, but still implanted under the skull. Non-invasive methods are also possible by sensing EEG and EMG signals with electrodes at the skin surface. Such electrodes acquire the macro-scale activity at very low frequency (< 40Hz).

Brain signal electrodes.png

Many-channels recording systems are made of an analog-front-end (AFE) that is composed by amplifiers, filters and analog-to-digital converters (ADCs) and a digital part that streams the signals to a digital processor. This part is usually implemented with standard protocols like SPI or USB. As most of the power is spent in transmitting, smart recording systems can be equipped of circuitry to extract and send only “interesting” portion of the signal. This reduce the bandwidth from the recording system depending on the signal activity (more interesting events --> higher bandwidth and viceversa). For instance, an epileptic seizure detection device may send to a computer only portion of the signal that contains the actual seizure and do not send anything when the brain acts normally. In the context of action potentials, a neural recording system can send to a digital processor only the spikes and do not send anything when the only content of the signal is background noise. Here, the transmitting power is proportional to the spike rate (rate at which neurons fire).

Even better, with an higher level of intelligence, such device can even cluster the spikes (assigned to one of the neurons sensed by the electrode - one electrode can sense 1 – 4 neurons in the neighbourhood -). This process is called "spike sorting". The transmitting power is even lower here as the spike are sent by means of NEURON_ID (less bits to send, less time to keep the antenna on).

We can do more, with a spiking neural networks, such devices can extract more than just an ID, but the behavior behind the sequence of spikes. Like "the rat is sleeping", or "the man wants to move the left little finger".


The challenge behind these devices are different. If implanted, size and power matters the most. If not, power and size still matter (wearable) but are less constrained. Versatility is definitely a good feature that helps prototyping the device, keep a short time to market, maintainability, iterate for improvement in the future.

Microcontrollers offer the best versatility at a low price and relatively low power and area budget.

Depending on the context, neural recording systems may have from 8 - 16 channels for simple experiments with rats to 100,000 channels to study more complex neural networks as the human brain! Off-the-shelf microcontrollers cannot handle many analog channels concurrently due to their performance and bandwidth limitations. Therefore, having microcontrollers that offer the same versatility but enhanced for bio-inspired applications is definitively a contribution to human machine interfaces.

Project description

The goal of this thesis is to extend the open-source PULPissimo microcontroller to support up to 8/16 SPI channels that communicate with multiple-channels ADCs (for example [1]) for neuron-inspired applications and to tape it out in umcL65 nm technology. The PULPissimo microcontroller is equipped with a uDMA engine that autonomously and efficiently handles I/O. Such engine can also post process the data as for example to filter them before storing them to the uC memory. The datapath engine that deals with peripherals data post processing will also be extended to extract spikes coming from the ADCs, attach the time stamp to the extract spike and store the packet to the main memory.

[File:File:Spike_extraction.png|thumb|400px]]

Spikes can be detected in 2 different ways:

  • gradient based

Once there are enough spikes ready, the microprocessor can start the higher level of intelligence of the algorithm to identify the firing neurons (spike sorting) or even more, by running a spiking neural networks. The spike sorting algorithm should be implemented in C to test the work.


This thesis is part of project in collaboration with the Neural Interfaces group at Imperial College London (http://www.imperial.ac.uk/neural-interfaces) and the Institute of Neuroinformatics at UZH (https://www.ini.uzh.ch/en.html).


The student is required to:

  • Extend the uDMA engine to support from 8 to 16 SPI peripherals
  • Extend the uDMA Filter datapath to extract spikes - the datapath should be design to use the minimum resources given the performance/bandwidth requirements. Understanding the bandwidth requirement as well as the clock frequency is part of the student tasks.
  • Test the whole RTL with an application that actually does the Spike Sorting starting from the raw data that are passed in the testbench to the 8/16 SPI channels.
  • Tape out the PULPissimo microcontroller in umcL65 technology.

The HDL language for the design and testbench will be SystemVerilog.

[1] http://www.ti.com/product/ADS1298

Required Skills

To work on this project, you will need:

  • to have worked in the past with at least one RTL language (SystemVerilog or Verilog or VHDL) - having followed the VLSI1 / VLSI2 courses is recommended
  • to have prior knowedge of hardware design

Other skills that you might find useful include:

  • familiarity with a scripting language
  • to be strongly motivated for a super-cool project

If you want to work on this project, but you think that you do not match some the required skills, we can give you some preliminary exercise to help you fill in the gap.

Status: Available

Supervision: Pasquale Davide Schiavone, Alfio Di Mauro, Francesco Conti

External collaborators: Simone Benatti (University of Bologna), Elisa Donati (INI UZH), Timothy Constandinou (Imperial College London)

Professor

Luca Benini

↑ top

Meetings & Presentations

The students and advisor(s) agree on weekly meetings to discuss all relevant decisions and decide on how to proceed. Of course, additional meetings can be organized to address urgent issues.

Around the middle of the project there is a design review, where senior members of the lab review your work (bring all the relevant information, such as prelim. specifications, block diagrams, synthesis reports, testing strategy, ...) to make sure everything is on track and decide whether further support is necessary. They also make the definite decision on whether the chip is actually manufactured (no reason to worry, if the project is on track) and whether more chip area, a different package, ... is provided. For more details confer to [1].

At the end of the project, you have to present/defend your work during a 15 min. presentation and 5 min. of discussion as part of the IIS colloquium.