Questions about arrangements of data in memories and model propagations in a hardware perspective

[Toadally-Awesome]

Hello, It is an interesting and great work and I have been reading the source codes. I found some difficulties in understanding the control flow of OpenSpike.

For example, in STATE_HIDDEN or STATE_OUTPUT, the signal 'cntrl_spk_select' will switch between 0 and 1 for 64 cycles. In my understanding, it is a signal to decide to mount the 1024-bit spikes saved in spk_processor or 2 of 16 spikes read from spk_memory_controler onto accumulators. So it looks like the accumulators are accumulating irrelevant variations of potentials from different layers.

In addition for the same mentioned states, the 'cntrl_ac_spk_read_addr' and 'cntrl_ac_spk_read_switch' increase by 1 simultaneously each clock cycle where I think 'cntrl_ac_spk_read_addr' points to a word of 16-bit spikes and 'cntrl_ac_spk_read_switch' selects 2 of them, so if they increase together, it looks like you skip the remaining 14-bit spikes and just get to the next 16-bit spikes and still merely select 2 spikes just with different bit-positions. It is difficult for me to figure out how the spikes are arranged in the memories.

So my question would be:

1. Could you please give more details on the data arrangement in memories? In terms like: #N Spikes emitted by neurons No.x-to-y on input/hidden/output layer is saved in spk_memory(addr = Z) and: #N membrane potentials of neurons No.x-to-y on input/hidden/output layer is saved in potential_memory(addr = Z) or: Input spikes of input layer of (time_step=N) are initialized in spk_memory(addr = M)

2. Would you please give some more details on what exactly each states in control_unit are doing, and how the your testbench SNN model is forward propagated on OpenSpike?

3. Would you mind opensource the configs of OpenLane implementation and give more information about the hardening flow? something like: how the openrams are connected with the provided RTL designs in OpenLane?

[sfmth]

Hello

[sfmth]

The file control_unit.v has known bugs, if you want to understand the control flow you can refer to this file: https://github.com/sfmth/OpenSpike/blob/main/verilog-workbench/src/control_unit_256.v

there is supposed to be a memory controller interfacing SRAM blocks with the core that adds a layer of abstraction and aggregates different SRAM groups for the core to be able to access them sequentially with more address bits.

[sfmth]

W SRAM: size: 1025x2048 Address: Input: 0 hidden: 1:512 output: 513:1024

Spk SRAM: size: 129*16 address: input: 0:63 hidden: 64:127 output: 128

spkblty SRAM: size: 129x16 input: 0:63 hidden: 64:127 output: 128

input SRAM: size: 1024x128 each time step: 0:7

potential SRAM: size: 129x128 input: 0:63 hidden: 64:127 output: 128

beta SRAM: size: 129x64 input: 0:63 hidden: 64:127 output: 128

[sfmth]

2. The control flow is just for demonstration mainly, and a lot of things can change if you are trying to do something else with the project. As far as I can remember, every state has a pre-state that loads addresses, and then these addresses are incremented every clock cycle.
3. The config.tcl file for hardening the core is already provided, to connect Macros together you can take a look at openlane's provided examples. Hardening and connecting numerous SRAM macros over a large area is very compute heavy, and I do not have access to such hardware.

It is planned to tapeout a scaled down version of OpenSpike for future opensource MPWs, but there hasn't been any news on MPW9, unfortunately.