gem5-users@gem5.org

The gem5 Users mailing list

View all threads

Clarification on NVMain Energy Calculation Logic (Potential Double Counting?)

OK
Om Kumar
Fri, Dec 12, 2025 1:41 AM

I'm currently working on simulating non-volatile memory architectures using
NVMain, with a focus on the energy characteristics of ReRAM.

While tracing the energy calculation logic in SubArray.cpp, I came across
behavior that I found somewhat confusing and wanted to confirm whether my
understanding is correct - or if I’m overlooking a subtle detail in the
implementation.


Scenario:

I’m examining a standard write operation with the following configuration:

  • WriteAllBits = true
  • UniformWrites = true
  • MLCLevels = 1
  • Ewr: Defined in the config as the total energy for writing a word (e.g.,
    512 bits), presumably including both cell-level and peripheral energy.

My Observation:

It appears that write energy may be added twice during a write operation in
this setup.

  1. In SubArray::Write()

The following line adds Ewr to subArrayEnergy, with a minor rebate if any
bits remain unchanged:

// SubArray.cpp
subArrayEnergy += p->Ewr - p->Ewrpb * numUnchangedBits;

Since WriteAllBits = true, numUnchangedBits is zero, so this effectively
contributes the full Ewr.

My understanding is that Ewr is the total word-level write energy, which
already includes cell programming and peripheral switching.

  1. In SubArray::WriteCellData()

Later, when Write() calls WriteCellData() (mainly to get timing), the
following lines are executed:

// SubArray.cpp
subArrayEnergy += p->Ereset * writeCount0;
subArrayEnergy += p->Eset * writeCount1;

These lines add energy based on the number of bits being written to 0 or 1,
i.e., cell-level SET/RESET energy - which seems redundant if Ewr already
includes those.


My Question:

Is this behavior intentional?

It seems that under EnergyModel = energy, and UniformWrites = true, the
model:

  • Adds Ewr (total write energy)
  • Then also adds Eset and Ereset for each bit

This would lead to double-counting cell-level energy.

Should WriteCellData() be modifying energy stats if the flat model (Ewr) is
already being applied in Write()?

Any clarification or correction would be greatly appreciated. Thank you!

Source: https://github.com/SEAL-UCSB/NVmain/blob/master/src/SubArray.cpp

I'm currently working on simulating non-volatile memory architectures using NVMain, with a focus on the energy characteristics of ReRAM. While tracing the energy calculation logic in SubArray.cpp, I came across behavior that I found somewhat confusing and wanted to confirm whether my understanding is correct - or if I’m overlooking a subtle detail in the implementation. --- Scenario: I’m examining a standard write operation with the following configuration: - WriteAllBits = true - UniformWrites = true - MLCLevels = 1 - Ewr: Defined in the config as the total energy for writing a word (e.g., 512 bits), presumably including both cell-level and peripheral energy. --- My Observation: It appears that write energy may be added twice during a write operation in this setup. 1. In SubArray::Write() The following line adds Ewr to subArrayEnergy, with a minor rebate if any bits remain unchanged: // SubArray.cpp subArrayEnergy += p->Ewr - p->Ewrpb * numUnchangedBits; Since WriteAllBits = true, numUnchangedBits is zero, so this effectively contributes the full Ewr. My understanding is that Ewr is the total word-level write energy, which already includes cell programming and peripheral switching. 2. In SubArray::WriteCellData() Later, when Write() calls WriteCellData() (mainly to get timing), the following lines are executed: // SubArray.cpp subArrayEnergy += p->Ereset * writeCount0; subArrayEnergy += p->Eset * writeCount1; These lines add energy based on the number of bits being written to 0 or 1, i.e., cell-level SET/RESET energy - which seems redundant if Ewr already includes those. --- My Question: Is this behavior intentional? It seems that under EnergyModel = energy, and UniformWrites = true, the model: - Adds Ewr (total write energy) - Then also adds Eset and Ereset for each bit This would lead to double-counting cell-level energy. Should WriteCellData() be modifying energy stats if the flat model (Ewr) is already being applied in Write()? Any clarification or correction would be greatly appreciated. Thank you! Source: https://github.com/SEAL-UCSB/NVmain/blob/master/src/SubArray.cpp