Modifying "shareable" status of the weights Var of a Dense layer

[daevem]

Hi All,

I am currently trying to develop a process within LAVA. This process requires write access to the weights of a Dense layer, therefore I made a little change into the LAVA process of the Dense layer (at lava/src/lava/proc/dense/process.py) and set the shareable attribute of the weights to True.
My process works fine, however, I was wondering whether this would have any implication when running on Loihi? If so, could you please point out if there is another way of achieving this while keeping compatibility with Loihi?

Thanks a lot!

[drager-intel]

Hello, and thanks for reaching out! Apologies for the delay in response; the whole Lava team has been working on a major update! It sounds like you made the weights Var of the Dense Process shareable, allowing you to connect a RefPort from another Process to the weights Var. This type of shared memory access will work fine when your Processes are implemented with PyProcModels and executed on a CPU. However, this approach to weight modification will not work on Loihi, as weights are not stored in shareable memory. This distinction should become clearer in the coming weeks, after we release support for NcProcModels that are run on Loihi. Once a network has been compiled for Loihi, you may only modify weights in 2 ways, ranked here in order of efficiency :

1. Via the on-chip learning engine, so long as your weight updates can be expressed as a function of pre and/or post synaptic activity traces. Loihi's on-chip learning engine can represent most Hebbian and three-factor learning rules. Use of the learning engine allows all weight updates to be executed directly on the NeuroCores.
2. Via an I/O CProcModel, which writes the new weights from the chip's onboard x86 processor to the NeuroCores. This method places no restrictions on the form of your weight updates, but incurs extra communication costs.

As I noted, support for NcProcModels and a learning engine simulator are being released very soon, and hopefully these will aid your simulations! Let us know if you have more questions in the interim

[awintel]

A small correction to the reply above:
The reason weights are set as non-sharable is because it won't be very efficient. However, there are three ways of modifying weights in order of efficiency:

1. Via on-chip learning as described above.
2. Via RefPorts from another CProcModel running on an embedded CPU as described above. Costs more than (1) but it's still fairly local on-chip communication.
3. Via Var.set/get(..) . This is the least efficient as it requires to pause execution and hand control back to the user process. This is mostly meant for debug or interactive diagnostic purposes or perhaps swapping out stored model parameters.

All these ways will work eventually in general for Lava Vars because all Vars are in principle treated equally. However, it doesn't work for weights yet because they fall in a category that makes them a little less equal compared to other Vars implemented on Loihi: Due to the special register encoding of weights in NeuroCores on Loihi, accesses via (2) or (3) would require an automated encode/decode step to happen besides just reading the memory which is not implemented yet.

[awintel]

Regarding Hebbian and 3F learning:
We are planning to enable on-chip learning in Q2 but we have not yet decided how many incremental releases we will do in Q2. The immediate next release will enable Lava on Loihi next week. But I expect on-chip learning to be ready in the June time frame.
I see us either updating the existing connection processes like Dense to have an additional learning API to configure local learning rules or to provide new learning-enabled processes.

Unless you are thinking of a learning rule that cannot be realized with Loihi's sum-of-product mechanism, then a third process will not be required.

Let us know what you think.

[daevem]

Hi Andreas! Thank you for your reply, and sorry for the delayed answer, but I missed hitting the Reply button.
Thanks for clarifying the weights Vars; I see why accessing them is not as straightforward.

On-chip learning being ready in June is great news! I indeed thought that the way to go was by making weight updates happen within the Dense (or other connection) process either by modifying the existing ones or creating new learning-enabled ones, as you suggested. However, weight updates might depend on the activation of the following neuron processes, which are not visible to the Connection process. Would you then include the LIF (or other neurons) processes in the new Connection processes, or would you implement a side-access to the Connection through which the process can receive information about the activation? In this way, activations would be visible to the Connection process, and weights could be updated accordingly.
The same applies to 3F learning, where the weight updates might need to be triggered by a global signal broadcasted only at the end of the forward path.

Perhaps there is something I am missing here; if so, please let me know!

[awintel]

Sure, one can create a new process that combines connections and neurons in on process. That might be the easiest. However, it wouldn't be the most modular solution.
A more modular solution would be to add another InPort to a connection process to which post-synaptic neurons could send post synaptic information like spikes, traces, third factors, etc. In Loihi 2, this could be quantities computed in the uCode engine. If you've watched today's Loihi 2 deep dive, then you have learned that Loihi 2 allows you to compute "arbitrary" programs to compute not only neuron updates but also third or fourth factors that can be provided to local synaptic learning rules.

[daevem]

I have watched Loihi 2, and Lava deep dives and they have indeed been very useful to understand more about the underlying mechanics. Thanks for taking the time to answer my questions. I will be looking forward to the forthcoming releases!