[gem5-dev] Change in gem5/gem5[develop]: arch-arm, dev-arm: Consistently use ISO prefixes
Andreas Sandberg has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/39575 )
Change subject: arch-arm, dev-arm: Consistently use ISO prefixes
..
arch-arm, dev-arm: Consistently use ISO prefixes
We currently use the traditional SI-like prefixes to represent
binary multipliers in some contexts. This is ambiguous in many cases
since they overload the meaning of the SI prefix.
Here are some examples of commonly used in the industry:
* Storage vendors define 1 MB as 10**6 bytes
* Memory vendors define 1 MB as 2**20 bytes
* Network equipment treats 1Mbit/s as 10**6 bits/s
* Memory vendors define 1Mbit as 2**20 bits
In practice, this means that a FLASH chip on a storage bus uses
decimal prefixes, but that same flash chip on a memory bus uses binary
prefixes. It would also be reasonable to assume that the contents of a
1Mbit FLASH chip would take 0.1s to transfer over a 10Mbit Ethernet
link. That's however not the case due to different meanings of the
prefix.
The quantity 2MX is treated differently by gem5 depending on the unit
X:
* Physical quantities (s, Hz, V, A, J, K, C, F) use decimal prefixes.
* Interconnect and NoC bandwidths (B/s) use binary prefixes.
* Network bandwidths (bps) use decimal prefixes.
* Memory sizes and storage sizes (B) use binary prefixes.
Mitigate this ambiguity by consistently using the ISO/IEC/SI prefixes
for binary multipliers for parameters and comments where appropriate.
Change-Id: I9b47194d26d71c8ebedda6c31a5bac54b600d3bf
Signed-off-by: Andreas Sandberg
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39575
Reviewed-by: Richard Cooper
Tested-by: kokoro
---
M src/arch/arm/ArmSemihosting.py
M src/arch/arm/table_walker.cc
M src/arch/arm/table_walker.hh
M src/dev/arm/FlashDevice.py
M src/dev/arm/RealView.py
5 files changed, 49 insertions(+), 49 deletions(-)
Approvals:
Andreas Sandberg: Looks good to me, approved; Looks good to me, approved
Richard Cooper: Looks good to me, approved
kokoro: Regressions pass
diff --git a/src/arch/arm/ArmSemihosting.py b/src/arch/arm/ArmSemihosting.py
index e445590..8674edc 100644
--- a/src/arch/arm/ArmSemihosting.py
+++ b/src/arch/arm/ArmSemihosting.py
@@ -53,10 +53,10 @@
files_root_dir = Param.String("",
"Host root directory for files handled by Semihosting")
-mem_reserve = Param.MemorySize("32MB",
+mem_reserve = Param.MemorySize("32MiB",
"Amount of memory to reserve at the start of the address map.
This "
"memory won't be used by the heap reported to an application.");
-stack_size = Param.MemorySize("32MB", "Application stack size");
+stack_size = Param.MemorySize("32MiB", "Application stack size");
time = Param.Time('01/01/2009',
"System time to use ('Now' for actual time)")
diff --git a/src/arch/arm/table_walker.cc b/src/arch/arm/table_walker.cc
index e658b02..7f19adb 100644
--- a/src/arch/arm/table_walker.cc
+++ b/src/arch/arm/table_walker.cc
@@ -648,7 +648,7 @@
MISCREG_TTBR0, currState->tc, !currState->isSecure));
tsz = currState->ttbcr.t0sz;
currState->isUncacheable = currState->ttbcr.irgn0 == 0;
-if (ttbr0_max < (1ULL << 30)) // Upper limit < 1 GB
+if (ttbr0_max < (1ULL << 30)) // Upper limit < 1 GiB
start_lookup_level = L2;
} else if (currState->vaddr >= ttbr1_min) {
DPRINTF(TLB, " - Selecting TTBR1 (long-desc.)\n");
@@ -673,7 +673,7 @@
MISCREG_TTBR1, currState->tc, !currState->isSecure));
tsz = currState->ttbcr.t1sz;
currState->isUncacheable = currState->ttbcr.irgn1 == 0;
-// Lower limit >= 3 GB
+// Lower limit >= 3 GiB
if (ttbr1_min >= (1ULL << 31) + (1ULL << 30))
start_lookup_level = L2;
} else {
@@ -2379,16 +2379,16 @@
pageSizes // see DDI 0487A D4-1661
.init(10)
.flags(Stats::total | Stats::pdf | Stats::dist | Stats::nozero);
-pageSizes.subname(0, "4K");
-pageSizes.subname(1, "16K");
-pageSizes.subname(2, "64K");
-pageSizes.subname(3, "1M");
-pageSizes.subname(4, "2M");
-pageSizes.subname(5, "16M");
-pageSizes.subname(6, "32M");
-pageSizes.subname(7, "512M");
-pageSizes.subname(8, "1G");
-pageSizes.subname(9, "4TB");
+pageSizes.subname(0, "4KiB");
+pageSizes.subname(1, "16KiB");
+pageSizes.subname(2, "64KiB");
+pageSizes.subname(3, "1MiB");
+pageSizes.subname(4, "2MiB");
+pageSizes.subname(5, "16MiB");
+pageSizes.subname(6, "32MiB");
+pageSizes.subname(7, "512MiB");
+pageSizes.subname(8, "1GiB");
+pageSizes.subname(9, "4TiB");
requestOrigin
.init(2,2) // Instruction/Data, requests/completed
diff --git a/src/arch/arm/table_walker.hh b/src/arch/arm/table_walker.hh
index
[gem5-dev] Change in gem5/gem5[develop]: arch-arm, dev-arm: Consistently use ISO prefixes
Andreas Sandberg has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/39576 )
Change subject: arch-arm, dev-arm: Consistently use ISO prefixes
..
arch-arm, dev-arm: Consistently use ISO prefixes
We currently use the traditional SI-like prefixes for to represent
binary multipliers in some contexts. This is ambiguous in many cases
since they overload the meaning of the SI prefix.
Here are some examples of commonly used in the industry:
* Storage vendors define 1 MB as 10**6 bytes
* Memory vendors define 1 MB as 2**20 bytes
* Network equipment treats 1Mbit/s as 10**6 bits/s
* Memory vendors define 1Mbit as 2**20 bits
In practice, this means that a FLASH chip on a storage bus uses
decimal prefixes, but that same flash chip on a memory bus uses binary
prefixes. It would also be reasonable to assume that the contents of a
1Mbit FLASH chip would take 0.1s to transfer over a 10Mbit Ethernet
link. That's however not the case due to different meanings of the
prefix.
The quantity 2MX is treated differently by gem5 depending on the unit
X:
* Physical quantities (s, Hz, V, A, J, K, C, F) use decimal prefixes.
* Interconnect and NoC bandwidths (B/s) use binary prefixes.
* Network bandwidths (bps) use decimal prefixes.
* Memory sizes and storage sizes (B) use binary prefixes.
Mitigate this ambiguity by consistently using the ISO/IEC/SI prefixes
for binary multipliers for parameters and comments where appropriate.
Change-Id: I2d24682d207830f3b7b0ad2ff82b55e082cccb32
Signed-off-by: Andreas Sandberg
---
M src/mem/AbstractMemory.py
M src/mem/DRAMInterface.py
M src/mem/NVMInterface.py
M src/mem/SimpleMemory.py
M src/mem/XBar.py
M src/mem/cache/prefetch/Prefetcher.py
M src/mem/cache/tags/Tags.py
7 files changed, 49 insertions(+), 48 deletions(-)
diff --git a/src/mem/AbstractMemory.py b/src/mem/AbstractMemory.py
index 4c21d52..e1941c3 100644
--- a/src/mem/AbstractMemory.py
+++ b/src/mem/AbstractMemory.py
@@ -44,9 +44,10 @@
abstract = True
cxx_header = "mem/abstract_mem.hh"
-# A default memory size of 128 MB (starting at 0) is used to
+# A default memory size of 128 MiB (starting at 0) is used to
# simplify the regressions
-range = Param.AddrRange('128MB', "Address range (potentially
interleaved)")
+range = Param.AddrRange('128MiB',
+"Address range (potentially interleaved)")
null = Param.Bool(False, "Do not store data, always return zero")
# All memories are passed to the global physical memory, and
diff --git a/src/mem/DRAMInterface.py b/src/mem/DRAMInterface.py
index 85a6092..4f59498 100644
--- a/src/mem/DRAMInterface.py
+++ b/src/mem/DRAMInterface.py
@@ -259,7 +259,7 @@
# an 8x8 configuration.
class DDR3_1600_8x8(DRAMInterface):
# size of device in bytes
-device_size = '512MB'
+device_size = '512MiB'
# 8x8 configuration, 8 devices each with an 8-bit interface
device_bus_width = 8
@@ -268,7 +268,7 @@
burst_length = 8
# Each device has a page (row buffer) size of 1 Kbyte (1K columns x8)
-device_rowbuffer_size = '1kB'
+device_rowbuffer_size = '1KiB'
# 8x8 configuration, so 8 devices
devices_per_rank = 8
@@ -338,7 +338,7 @@
# [2] High performance AXI-4.0 based interconnect for extensible smart
memory
# cubes (E. Azarkhish et. al)
# Assumed for the HMC model is a 30 nm technology node.
-# The modelled HMC consists of 4 Gbit layers which sum up to 2GB of memory
(4
+# The modelled HMC consists of 4 Gbit layers which sum up to 2GiB of
memory (4
# layers).
# Each layer has 16 vaults and each vault consists of 2 banks per layer.
# In order to be able to use the same controller used for 2D DRAM
generations
@@ -354,8 +354,8 @@
# of the HMC
class HMC_2500_1x32(DDR3_1600_8x8):
# size of device
-# two banks per device with each bank 4MB [2]
-device_size = '8MB'
+# two banks per device with each bank 4MiB [2]
+device_size = '8MiB'
# 1x32 configuration, 1 device with 32 TSVs [2]
device_bus_width = 32
@@ -458,11 +458,11 @@
# A single DDR4-2400 x64 channel (one command and address bus), with
# timings based on a DDR4-2400 8 Gbit datasheet (Micron MT40A2G4)
# in an 16x4 configuration.
-# Total channel capacity is 32GB
-# 16 devices/rank * 2 ranks/channel * 1GB/device = 32GB/channel
+# Total channel capacity is 32GiB
+# 16 devices/rank * 2 ranks/channel * 1GiB/device = 32GiB/channel
class DDR4_2400_16x4(DRAMInterface):
# size of device
-device_size = '1GB'
+device_size = '1GiB'
# 16x4 configuration, 16 devices each with a 4-bit interface
device_bus_width = 4
@@ -569,14 +569,14 @@
# A single DDR4-2400 x64 channel (one command and address bus), with
# timings based on a DDR4-2400 8 Gbit datasheet (Micron MT40A1G8)
# in an 8x8 configuration.
-# Total channel capacity is 16GB
-# 8 devices/rank * 2
[gem5-dev] Change in gem5/gem5[develop]: arch-arm, dev-arm: Consistently use ISO prefixes
Andreas Sandberg has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/39575 )
Change subject: arch-arm, dev-arm: Consistently use ISO prefixes
..
arch-arm, dev-arm: Consistently use ISO prefixes
We currently use the traditional SI-like prefixes for to represent
binary multipliers in some contexts. This is ambiguous in many cases
since they overload the meaning of the SI prefix.
Here are some examples of commonly used in the industry:
* Storage vendors define 1 MB as 10**6 bytes
* Memory vendors define 1 MB as 2**20 bytes
* Network equipment treats 1Mbit/s as 10**6 bits/s
* Memory vendors define 1Mbit as 2**20 bits
In practice, this means that a FLASH chip on a storage bus uses
decimal prefixes, but that same flash chip on a memory bus uses binary
prefixes. It would also be reasonable to assume that the contents of a
1Mbit FLASH chip would take 0.1s to transfer over a 10Mbit Ethernet
link. That's however not the case due to different meanings of the
prefix.
The quantity 2MX is treated differently by gem5 depending on the unit
X:
* Physical quantities (s, Hz, V, A, J, K, C, F) use decimal prefixes.
* Interconnect and NoC bandwidths (B/s) use binary prefixes.
* Network bandwidths (bps) use decimal prefixes.
* Memory sizes and storage sizes (B) use binary prefixes.
Mitigate this ambiguity by consistently using the ISO/IEC/SI prefixes
for binary multipliers for parameters and comments where appropriate.
Change-Id: I9b47194d26d71c8ebedda6c31a5bac54b600d3bf
Signed-off-by: Andreas Sandberg
---
M src/arch/arm/ArmSemihosting.py
M src/arch/arm/table_walker.cc
M src/arch/arm/table_walker.hh
M src/dev/arm/FlashDevice.py
M src/dev/arm/RealView.py
5 files changed, 49 insertions(+), 49 deletions(-)
diff --git a/src/arch/arm/ArmSemihosting.py b/src/arch/arm/ArmSemihosting.py
index e445590..8674edc 100644
--- a/src/arch/arm/ArmSemihosting.py
+++ b/src/arch/arm/ArmSemihosting.py
@@ -53,10 +53,10 @@
files_root_dir = Param.String("",
"Host root directory for files handled by Semihosting")
-mem_reserve = Param.MemorySize("32MB",
+mem_reserve = Param.MemorySize("32MiB",
"Amount of memory to reserve at the start of the address map.
This "
"memory won't be used by the heap reported to an application.");
-stack_size = Param.MemorySize("32MB", "Application stack size");
+stack_size = Param.MemorySize("32MiB", "Application stack size");
time = Param.Time('01/01/2009',
"System time to use ('Now' for actual time)")
diff --git a/src/arch/arm/table_walker.cc b/src/arch/arm/table_walker.cc
index e658b02..7f19adb 100644
--- a/src/arch/arm/table_walker.cc
+++ b/src/arch/arm/table_walker.cc
@@ -648,7 +648,7 @@
MISCREG_TTBR0, currState->tc, !currState->isSecure));
tsz = currState->ttbcr.t0sz;
currState->isUncacheable = currState->ttbcr.irgn0 == 0;
-if (ttbr0_max < (1ULL << 30)) // Upper limit < 1 GB
+if (ttbr0_max < (1ULL << 30)) // Upper limit < 1 GiB
start_lookup_level = L2;
} else if (currState->vaddr >= ttbr1_min) {
DPRINTF(TLB, " - Selecting TTBR1 (long-desc.)\n");
@@ -673,7 +673,7 @@
MISCREG_TTBR1, currState->tc, !currState->isSecure));
tsz = currState->ttbcr.t1sz;
currState->isUncacheable = currState->ttbcr.irgn1 == 0;
-// Lower limit >= 3 GB
+// Lower limit >= 3 GiB
if (ttbr1_min >= (1ULL << 31) + (1ULL << 30))
start_lookup_level = L2;
} else {
@@ -2379,16 +2379,16 @@
pageSizes // see DDI 0487A D4-1661
.init(10)
.flags(Stats::total | Stats::pdf | Stats::dist | Stats::nozero);
-pageSizes.subname(0, "4K");
-pageSizes.subname(1, "16K");
-pageSizes.subname(2, "64K");
-pageSizes.subname(3, "1M");
-pageSizes.subname(4, "2M");
-pageSizes.subname(5, "16M");
-pageSizes.subname(6, "32M");
-pageSizes.subname(7, "512M");
-pageSizes.subname(8, "1G");
-pageSizes.subname(9, "4TB");
+pageSizes.subname(0, "4KiB");
+pageSizes.subname(1, "16KiB");
+pageSizes.subname(2, "64KiB");
+pageSizes.subname(3, "1MiB");
+pageSizes.subname(4, "2MiB");
+pageSizes.subname(5, "16MiB");
+pageSizes.subname(6, "32MiB");
+pageSizes.subname(7, "512MiB");
+pageSizes.subname(8, "1GiB");
+pageSizes.subname(9, "4TiB");
requestOrigin
.init(2,2) // Instruction/Data, requests/completed
diff --git a/src/arch/arm/table_walker.hh b/src/arch/arm/table_walker.hh
index dbb480e..f4ee552 100644
--- a/src/arch/arm/table_walker.hh
+++ b/src/arch/arm/table_walker.hh
@@ -132,7 +132,7 @@
return (EntryType)(data & 0x3);
}
-/** Is the page a Supersection (16MB)?*/
+/** Is the page a Supersection (16 MiB)?*/
