Loihi Limitations


I’ve run into some limitations on running some models on Loihi, primarily the axons limitation, synapse bit limit, and the bit loss in weight rounding. Also I get the high intercept limit when discretizing the model warning as well.

I’ve managed to overcome a good portion of the axon limitations and the synapse bit limit using the solution described here.

However I’m not sure how to handle the bit loss as it drastically changes the the expected output of various nengo models (compared to running it with the normal nengo simulator). Are there methods or suggestions to alleviate this?

Also some other questions:

  1. Does the high intercept limit just make the encoders have noisier responses to its original preferred directions?
  2. How is the synapse bits limit derived? I’ve looked through some of the code and it uses 16,384 * 64 bits, it doesn’t seem as straightforward as the axon limit (at least at first glance from the Intel Loihi slides).
  3. Does nengo-loihi support multiple loihi chips? If so, how does it handle placement between multiple chips? (Or is that transparent to the user?)


Have you tried playing with the intercepts and max_rates passed to the ensembles? There is the nengo_loihi.set_defaults() method that sets these globally for you (must be called at the top of your file), although intercepts distributed across [-1, 0.5) might actually be better.

Would you be able to post a minimal version of the kind of model you’re trying to run so that we can see the difference between the Nengo and Nengo-Loihi simulators? We could then better assess the problem and try to come up with solutions. This would also be valuable for us as a benchmark / regression test for future improvements to the software.

@Eric might be able to better answer these questions.

Nengo-Loihi does support multiple chips, but it is currently an experimental / development feature that is not widely advertised to the user. If you would like to dive into this I would suggest taking a quick look at this pull request which has some code in the first post demonstrating how to use multiple chips on the hardware. Currently this is a proof-of-concept that takes the mindless approach of looping through the chips in round-robin order. In theory you could subclass the Allocator to do this more intelligently based on your needs. Let us know if you have some particular use case, or think of a way to do this that would work for you. Thanks!

Oh yeah, I keep forgetting about the nengo_loihi.set_defaults() method. I haven’t played around with the intercepts and max_rates a whole lot, I’ll try messing around with them when I run into it again. I’ll see if I can start collecting some models of interest when I encounter them.

I haven’t looked too much at a multi-chip setup but it’s probably something I’m going to run into at some point. Making a subclass of Allocator sounds like it should be fairly straightforward. I take it that it still does a 1-to-1 mapping of ensembles to cores? (Assuming that the loihi-block resembles an ensemble)

Thanks for the info!

Excellent, thanks!

That is right. This will likely be relaxed in the near future as well, but for now it should not cause issues except in relation to some scaling limitations like the one you mentioned.