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.
- 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.
- 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