search

nengo / nengo-loihi

Run Nengo models on Intel's Loihi chip
https://www.nengo.ai/nengo-loihi/
Other
35 stars 12 forks source link

Discussion about exposing advanced Loihi features #104

Open arvoelke opened 6 years ago

arvoelke commented 6 years ago

I'd like to open up a general discussion to gather thoughts about how advanced features of Loihi and its lower-level implementation details might be exposed to the end-user, for sake of greater customizability, debuggability, and to support users that would like to use Nengo primarily for a more streamlined experience with Loihi.

This was spurred by someone at INRC coming up to me and asking "how do I add a synaptic delay to my connection using Nengo"? This is supported by the hardware (note: this is public info) but not currently by Nengo. In theory we could support this in the same way that nengolib.signal.z is supported. But this is still missing out on the potential to configure different delays per synapse and/or axon.

Here's a list of features, compiled from publicly available information, that I feel are perhaps most relevant to the kinds of models we build in Nengo:

And some more general features:

Some of these are more-or-less compatible with the high-level Nengo API -- and so I understand the design philosophy that we'd like to abstract these things away when possible, and support model representations that are backend-agnostic -- but that's all part of why this is a discussion. My thinking is that some of this could help promote use-cases that attract a larger user-base.

Moreover, some of the implementation details of the mapping could be exposed back to the end-user. Specifically, telling the user how their neurons were mapped onto each core, where interneurons were introduced, where filters are placed, and how spikes are being injected. If any of this logic can be optionally extended by the user, that is also a big win in my mind. Some of this could be important for debugging and improving performance, or for understanding details about how the chip is actually being exploited (e.g., to help compare with other hardware, communicate in publications, and communicate with Intel in project proposals and reports).

tcstewar commented 6 years ago

Definitely a good idea to start this conversation. I'm really not quite sure what the right approach will be.

I'd also say that my first instinct is to start with something Loihi-specific, rather than thinking at all about how to fit it with the high-level Nengo API. My hope is that certain things will pop out as things we do what to migrate up to higher-level nengo (or to set up in such a way that we can use the same syntax with other backends), but I don't want to think about that too early.

I also really like the point about exposing the details of the mapping. Having some of that information exposed has been very useful in debugging nengo_brainstorm, and it'd be great to see that for nengo-loihi. To a certain degree, you can get that information from the sim.loihi object, but the mapping from those back to the original Nengo objects isn't clear. So I wonder if a first step in this direction would be to expose the mapping in some nice way, and that might then lead us to nice ways of having people specify and control the mapping.

tbekolay commented 6 years ago

Definitely a good thing to think about long term. I'm more amenable to thinking about how it would fit into Nengo core than Terry, as if those features are being used for Loihi then it would be great to add them to the reference simulator as well. Short term, exposing more details about the mapping from Nengo model to Nengo Loihi model would be great, as I believe doing that kind of work would require useful refactoring as well.

tcstewar commented 6 years ago

One possibility in this direction might be to create a LoihiCore Process that would let people manually build whatever they wanted using calls to NxCore. #110