Questions about "SpikeSim: An End-to-End Compute-in-Memory Hardware Evaluation Tool for Benchmarking Spiking Neural Networks"

[QNormen]

Hi, While implementing and analyzing the code, I encountered a few technical questions that I would greatly appreciate your guidance on:

1. Parameter Definitions in ela_spikesim.py
   In the code, parameters like xbar_size / 8, SUB, MUX, Temp_Buff, and dim are used, but their exact hardware interpretations are unclear to me. Specifically:

What does xbar_size / 8 represent? Is this related to crossbar partitioning or data precision?

Could you clarify the roles of SUB, MUX, and Temp_Buff in the context of the hardware architecture described in the paper?

2. Calculation in Lines 75-78
   The comment states: # (xbar_size**2) * (53*(4010e-3)2) * (k2). However, substituting xbar_size=64 and k=3 gives 64² * 53(0.04)²*9=31.26 , but the code differs. Additionally, could you explain the rationale behind multiplying by (k²) in this area calculation?

3. Tile Mapping Logic (Lines 27-30)
   The code calculates the number of Tiles required for layer mapping. However, this approach appears to allow multiple layers to share a single Tile. This seems contradictory to the statement in Section IV-A (SpikeFlow Architecture: Mapping SNNs Onto SpikeFlow), which emphasizes that "an SNN layer can be mapped over multiple Tiles, but multiple layers cannot be mapped in one Tile". Could you clarify this design choice?

4. PE Consumption Order Check (Lines 14-15)
   The code checks if the PE consumption per layer is sorted in ascending order. However, to my knowledge, SNN layers do not inherently require such an ordering. Is this check related to a hardware constraint (e.g., dataflow optimization), or is it a simplification for the current implementation?

I fully understand that you may have a busy schedule, and I sincerely appreciate any time you could spare to address these questions. If preferred, I am also happy to discuss further via email or a short call.