Interfacing PULP with a Brain-Inspired Ultra-Low Power Spiking Cochlea
At the Integrated Systems Laboratory (IIS) we have been working on a Parallel Ultra-Low Power Processor (PULP) System for the past two years. PULP is intended to be used for near-sensor computing in smart sensors, particularly on sensors that have a high need for extremely low power envelope and overall energy consumption, but at the same time can benefit from the availability of a level of computing performance orders of magnitude better than that of ultra-low power microcontrollers. The Institute of NeuroInformatics (INI) of the University of Zurich has recently developed a sensor that fits well the “smart low-power sensor” tag: an artificial cochlea, inspired to the similarly named organ that is located within the human ear. The natural cochlea is made up of sensory neurons that transform sounds and voices in a representation in terms of activation potentials or “spikes”, that are then elaborated by the neural cortex. The INI artificial cochlea strives to replicate this functionality in a silicon sensor. In nature, the spiking representation conveys enough information for us to recognize natural sounds, phonemes (and thus language), and music. There is natural overlap between the two projects, in that both strive to develop more advanced, smarter and more energy-efficient sensor nodes. As a consequence, we believe there is significant research interest in coupling the low-power cochlea developed at INI with the PULP platform.
Goal of the Project
The goal of this project is to implement a low-power interfacing mechanism between the INI cochlea and the open PULP platform, developed as a collaboration between IIS and other partners. The specific model of INI cochlea we target is the cochleaLP, the latest and most efficient version, which uses the asynchronous “serial” AER interface. Specifically, this project will strive to achieve two concurrent, yet separate targets: 1. design a low-power interface in standard cell technology that could be used to link a future PULP chip fabricated in the UMC 65nm technology with the cochleaLP. The interface would reside directly on the same die of the PULP cluster. 2. design a low-power interface to be used to link already existing PULP emulator and chips with the cochleaLP sensor. In this target, the interface resides on a low-power FPGA (e.g. an a MicroSemi IGLOO). To achieve both goals while reusing as much of the design as possible, and in particular to keep up with the second target, the cochlea will have to be interfaced with the PULP interface subsystem using one of the available sensor interfaces, e.g. SPI or I2S. The bulk of the project will therefore consist in the RTL design of the interface; proper ways to handle the asynchronous AER interface will have to be designed, using asynchronous state machines to clock-gate the interface as much as possible. Moreover, a meaningful way to tag and pack spikes and to send them to the PULP cluster only when necessary (to avoid waking it up too often) will also have to be designed. The design will have to be thoroughly verified and will have to be design-time and run-time configurable as much as possible and as much as it is needed by the application.
Outcomes and Acquired Expertise
With this project you will work in a field of active exciting research to develop a state-of-art neuromorphic accelerator for MPSoC and FPGA targets. You will learn:
- how to design a hardware module and integrate it within a more complex platform, using EDA tools for verification and RTL synthesis to evaluate results;
- how spiking neural networks models work and how they differ from other neural models
To work on this project, you will need:
- a minimum level of confidence with basic engineering tools (web search, basic usage of Linux operating system, compilers…) and of work independence
- to have worked in the past with at least one RTL language (SystemVerilog or Verilog or VHDL)
- to have basic prior knowedge of hardware design and computer architecture (i.e. have followed the relative courses)
Other skills that you might find useful include:
- basic familiarity with a scripting language for numerical simulation (Python or Matlab or Lua…)
- to be strongly motivated for a difficult but 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.
Alfio Di Mauro (Politecnico di Torino)
Detailed Task Description
Within the first month of the project you will be asked to prepare a project plan. This plan should identify the tasks to be performed during the project and sets deadlines for those tasks. The prepared plan will be a topic of discussion of the first week’s meeting between you and your advisers. Note that the project plan should be updated constantly depending on the project’s status.
Meetings & Weekly Report
Weekly meetings will be held between the student and the assistants. The exact time and location of these meetings will be determined within the first week of the project in order to fit the student’s and the assistants schedule. These meetings will be used to evaluate the status and progress of the project. Beside these regular meetings, additional meetings can be organized to address urgent issues as well. Moreover, the student will have to send a (short) written report at the end of every week.
Since most of the PULP project is written in System Verilog, it is strongly suggested to use System Verilog for this project as well. However, any other HDL can also be used if there are strong arguments to use them. Adapting a consistent naming scheme is one of the most important steps in order to make your code easy to understand. If signals, processes, and entities are always named the same way, any inconsistency can be detected easier. Moreover, if a design group shares the same naming convention, all members would immediately feel at home with each others code. Try to maintain the PULP naming convention in order to create readable and maintainable HDL code. Note that there might still be some legacy code which may not be compatible to the naming convention. It is not the goal of this work to re-write and adapt all code to a common naming convention, but the newly developed code should be compatible, and the top-level interfaces to legacy code should be adapted to be compatible to the rest of the system.
Documentation is an important and often overlooked aspect of engineering. One final report has to be completed within this project. Therefore, the final report of the work will have to be written in English, the de facto common language of electrical engineering and information technology. Any form of word processing software is allowed for writing the reports, nevertheless the use of LaTeX with a vector drawing software for block diagrams is strongly encouraged by the IIS staff (e.g. Inkscape, Tgif, Visio, OmniGraffle). The final report has to be presented at the end of the project and a digital copy need to be handed in.
- The EDA wiki with lots of information on the ETHZ ASIC design flow (internal only) 
- The IIS/DZ coding guidelines