[gem5-users] Re: DRAM access rate too high?

[Wendy Elsasser via gem5-users]

Hi Biresh,
What is the page policy and what is the distribution across rows for your 
access pattern? For example, are these random addresses that should access 
different rows or is this sequential, in which case, the data will sequence 
across the column addresses within the same row.

Thanks,
Wendy

On 5/6/21, 11:37 AM, "Joardar, Biresh Kumar via gem5-users" 
 wrote:

Hello,
I’m simulating a 4-core system connected to 1 DRAM bank. For this purpose, 
I set both the variables ‘ranks_per_channel’ and ‘banks_per_rank’ in the file 
src/mem/DRAMInterface.py to 1, and then recompile Gem5. Next, I run a 
single-thread test workload that has 95% cache miss rate and observe the DRAM 
addresses being accessed using the CommMonitor. The CommMonitor is connected 
between L2 and membus. Following is a sample of the output of the CommMonitor 
(after processing the trace file).

...
35,u,442036224,1,3,4971232483
35,u,482271232,1,3,4971232488
35,u,352915456,1,3,4971232494
35,u,436842496,1,3,4971232499
35,u,281513984,1,3,4971232505
35,u,41616,1,3,4971232510
35,u,356982784,1,3,4971232516
35,u,420560896,1,3,4971232521
35,u,485822464,1,3,4971232527
35,u,382685184,1,3,4971232532
35,u,420356096,1,3,4971232538
35,u,293416960,1,3,4971232543
35,u,446799872,1,3,4971232549
35,u,485634048,1,3,4971232554
35,u,337686528,1,3,4971232560
35,u,278323200,1,3,4971232565
35,u,519716864,1,3,4971232571
...

The last entry in each row is the cycle when the memory access was sent to 
DRAM. As you can see, a DRAM address is accessed every 5-6 cycle (5-6ns). Since 
there is one DRAM bank, each row activation should take tRC time, which in my 
case is 48ns (as set in the file src/mem/DRAMInterface.py). Why is the DRAM 
addresses being accessed faster (5-6ns), when the tRC parameter is 48ns.
The total number of DRAM addresses accessed in 1s is also extremely high. 
Based on tRC value, there should be ~21 million DRAM access per second 
(1/48E-9). However, I see 50 million DRAM access per second in the CommMonitor 
output. Why is DRAM access rate so high?

Thanks,
Biresh
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Infinite loop in memory controller

[Wendy Elsasser via gem5-users]

Hi Taiyu,
Looks like you have a single memory controller with 2 ranks instantiated.

  *   The log flags labeled system.mem_ctrls are for general controller messages
  *   The log flags labeled system.mem_ctrls_0 relate to rank 0 specific info
  *   The log flags labeled system.mem_ctrls_1 relate to rank 1 specific info

The messages in the log file included are for DRAM maintenance operations, 
specifically a refresh command. This is required periodically to maintain the 
bit cell contents. The messages seem to be occurring at the normal intervals, 
with the delays that are defined for a DDR3 device. The refresh command takes 
260ns and is issued every 7.8us, which is in-line with the DDR3 configuration 
and DRAM requirements. What is missing is read/write activity in between these 
refresh operations. It appears that the controller is not receiving any 
read/write requests but more info is needed to fully debug.

Thanks,
Wendy

From: Taiyu Zhou via gem5-users 
Reply-To: gem5 users mailing list 
Date: Friday, July 10, 2020 at 4:18 AM
To: "gem5-users@gem5.org" 
Cc: Taiyu Zhou <645505...@qq.com>
Subject: [gem5-users] Infinite loop in memory controller

Hi guys！
I run a Muti-thread program in gem5 with O3CPU but it will not exit.

./build/X86/gem5.opt --debug-flags=DRAM,BaseXBar,DRAMState,DRAMPower 
configs/example/se.py \
--cpu-type=DerivO3CPU --sys-clock=4GHz \
-c /home/ubuntu/taiyu/test_app/sps_t -o 2 -n 3 \
--caches --l2cache --l1d_size=64kB --l1i_size=32kB --l2_size=2048kB 
--l2_assoc=8 --mem-size=16GB


And I found there is infinite loop in it.
“
19814475: system.mem_ctrls: QoS Turnarounds selected state READ
19814475: system.mem_ctrls: Rank 0 is not available
19814475: system.mem_ctrls_0: Scheduling power event at 19814475 to 
state 0
19814475: system.mem_ctrls_0: Refresh done at 19814475 and next refresh 
at 19815229
19814475: system.mem_ctrls_0: Was refreshing for 26 ticks
19814475: system.mem_ctrls_0: Scheduling next request after refreshing rank 0
19814475: system.mem_ctrls_0: All banks precharged
19814475: system.mem_ctrls: QoS Turnarounds selected state READ
198152276250: system.mem_ctrls_0: Refresh due
198152276250: system.mem_ctrls_0: All banks already precharged, starting refresh
198152276250: system.mem_ctrls_0: Scheduling power event at 198152276250 to 
state 1
198152276250: system.mem_ctrls_0: Refreshing
198152276250: system.mem_ctrls_0: 158521821,REF,0,0
198152276250: system.mem_ctrls_1: Refresh due
198152276250: system.mem_ctrls_1: All banks already precharged, starting refresh
198152276250: system.mem_ctrls_1: Scheduling power event at 198152276250 to 
state 1
198152276250: system.mem_ctrls_1: Refreshing
198152276250: system.mem_ctrls_1: 158521821,REF,0,1
198152536250: system.mem_ctrls_1: Scheduling power event at 198152536250 to 
state 0
198152536250: system.mem_ctrls_1: Refresh done at 198152536250 and next refresh 
at 198160076250
198152536250: system.mem_ctrls_1: Was refreshing for 26 ticks
198152536250: system.mem_ctrls_1: Scheduling next request after refreshing rank 
1
198152536250: system.mem_ctrls_1: All banks precharged
198152536250: system.mem_ctrls: QoS Turnarounds selected state READ
198152536250: system.mem_ctrls: Rank 0 is not available
198152536250: system.mem_ctrls_0: Scheduling power event at 198152536250 to 
state 0
198152536250: system.mem_ctrls_0: Refresh done at 198152536250 and next refresh 
at 198160076250
198152536250: system.mem_ctrls_0: Was refreshing for 26 ticks
198152536250: system.mem_ctrls_0: Scheduling next request after refreshing rank 0
198152536250: system.mem_ctrls_0: All banks precharged
198152536250: system.mem_ctrls: QoS Turnarounds selected state READ
198160062500: system.mem_ctrls_0: Refresh due
198160062500: system.mem_ctrls_0: All banks already precharged, starting refresh
198160062500: system.mem_ctrls_0: Scheduling power event at 198160062500 to 
state 1
198160062500: system.mem_ctrls_0: Refreshing
198160062500: system.mem_ctrls_0: 158528050,REF,0,0
198160062500: system.mem_ctrls_1: Refresh due
198160062500: system.mem_ctrls_1: All banks already precharged, starting refresh
198160062500: system.mem_ctrls_1: Scheduling power event at 198160062500 to 
state 1
198160062500: system.mem_ctrls_1: Refreshing
198160062500: system.mem_ctrls_1: 158528050,REF,0,1

“
 And are there any hint about why this infinite loop happen？What this event is 
doing？ Why are there three memory controller system.mem_ctrls, 
system.mem_ctrls_0 and system.mem_ctrls_1?


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to 

[gem5-users] Re: a problem about memory access latency of HMC

[Wendy Elsasser via gem5-users]

Hi,
Yes, more info would be helpful. I would specifically look for log messages 
regarding refresh and self-refresh operations. Those are some conditions that 
would put the controller / memory in a busy state.  The READ command would be 
delayed until either the refresh completes or a self-refresh exit completes for 
these cases. However as Jason indicated, more info would help confirm the 
actual scenario that is occurring.

Regards,
Wendy

From: Jason Lowe-Power via gem5-users 
Reply-To: gem5 users mailing list 
Date: Friday, June 5, 2020 at 10:27 AM
To: gem5 users mailing list 
Cc: "yangyuq...@sjtu.edu.cn" , Jason Lowe-Power 

Subject: [gem5-users] Re: a problem about memory access latency of HMC

Hello,

This is a good question for which I don't have a simple answer. I think we 
would need more context in the access stream/debug trace. I also suggest 
digging into the code to see what happens when the line "Single request, going 
to a busy rank" is printed. The code around that DPRINTF will probably have 
some hints.

Cheers,
Jason

On Fri, Jun 5, 2020 at 12:08 AM yangyuqing--- via gem5-users 
mailto:gem5-users@gem5.org>> wrote:
I'm using HMC as my memory in my system. And I found a problem that once a 
simobject sent a read request, the latency of the response was different. I 
print out the DRAM trace.
1. if a read request is processed by dramctrl as follow, the latency is longer.
377334000: system.hmc_dev.mem_ctrls00: recvTimingReq: request PIMRead addr 
1775248 size 8
377334000: system.hmc_dev.mem_ctrls00: Read queue limit 32, current size 0, 
entries needed 1
377334000: system.hmc_dev.mem_ctrls00: Address: 1775248 Rank 0 Bank 0 Row 3467
377334000: system.hmc_dev.mem_ctrls00: Read queue limit 32, current size 0, 
entries needed 1
377334000: system.hmc_dev.mem_ctrls00: Adding to read queue
377334000: system.hmc_dev.mem_ctrls00: Request scheduled immediately
377334000: system.hmc_dev.mem_ctrls00: QoS Turnarounds selected state READ
377334000: system.hmc_dev.mem_ctrls00: Single request, going to a busy rank
377334000: system.hmc_dev.mem_ctrls00: No Reads Found - exiting
2.if a read request is processed by dramctrl as follow, the latency is shorter.
344235000: system.hmc_dev.mem_ctrls00: recvTimingReq: request PIMRead addr 
1774464 size 8
344235000: system.hmc_dev.mem_ctrls00: Read queue limit 32, current size 0, 
entries needed 1
344235000: system.hmc_dev.mem_ctrls00: Address: 1774464 Rank 0 Bank 0 Row 3465
344235000: system.hmc_dev.mem_ctrls00: Read queue limit 32, current size 0, 
entries needed 1
344235000: system.hmc_dev.mem_ctrls00: Adding to read queue
344235000: system.hmc_dev.mem_ctrls00: Request scheduled immediately
344235000: system.hmc_dev.mem_ctrls00: QoS Turnarounds selected state READ
344235000: system.hmc_dev.mem_ctrls00: Single request, going to a free rank
344235000: system.hmc_dev.mem_ctrls00: Timing access to addr 1774464, 
rank/bank/row 0 0 3465
344235000: system.hmc_dev.mem_ctrls00: Activate at tick 344241000
344235000: system.hmc_dev.mem_ctrls00: Activate bank 0, rank 0 at tick 
344241000, now got 1 active
344235000: system.hmc_dev.mem_ctrls00: Access to 1774464, ready at 344264300 
next burst at 344254400.
344235000: system.hmc_dev.mem_ctrls00: Precharging bank 0, rank 0 at tick 
344262600, now got 0 active
344235000: system.hmc_dev.mem_ctrls00: Auto-precharged bank: 0

I think the point is Single request, going to a free or busy rank. I want to 
know in which case the rank is busy and why latency is different.
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to 
gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

Re: [gem5-users] WriteQueue inDramCtrl

[Wendy Elsasser]

Hi Taya,
There are 2 thresholds defined for this purpose:
- write_high_thresh_perc
- write_low_thresh_perc

The controller also has a parameter to define the minimum number of writes to 
issue once the bus has transitioned to the WRITE state.
- min_writes_per_switch

These are used to determine when the bus direction should switch from reads to 
writes in processNextReqEvent, where the next DRAM burst is selected. The 
accessAndRespond routine is called, as you indicated, when the command is 
placed in the Q for an early response upstream. This does not remove the entry 
from the Q, which will still be scheduled based on bus direction, QoS, DRAM 
timing, etc.

The parameters listed above function as follows:
Case1: Bus state is currently ‘READ’
Will switch to ‘WRITE’, enabling write bursts to issue from the writeQ if:

  *   The read Q is empty, write Q is not empty and the number of writes in Q  
is greater than the LOW threshold (write_low_thresh_perc) OR
  *   The number of writes in Q is greater than the HIGH threshold 
(write_high_thresh_perc)

Case2: Bus state us currently ‘WRITE’
Will switch to ‘READ’, enabling read bursts to issue from the ReadQ if:

  *   The writeQ is empty, OR
  *   WriteQ is below the LOW threshold (using min_writes_per_switch as the 
hysteresis), OR
  *   The read Q is not empty and the controller has issued 
min_writes_per_switch

Thanks,
Wendy

From: gem5-users  on behalf of Taya 
<645505...@qq.com>
Reply-To: gem5 users mailing list 
Date: Monday, April 13, 2020 at 6:27 AM
To: gem5-users 
Subject: [gem5-users] WriteQueue inDramCtrl

Hi guys！
I am trying to understand the DRAM in gem5.And I purpose is that stop 
writequeue flush untill it reach a setting threshold.So I look inside the 
source code abstract_mem.cc and  dram_ctrl.cc. ,but can't understand on some 
place.In the function addToWriteQueue,it translate pkt to drampkt and then put 
it back to the writequeue according to qosvalue.After that ,addToWriteQueue 
call accessAndRespond which call function 'access' to perform a memory access 
and update some state for the pkt. These functions are confusing to me,because 
in my understanding memory controller need to put drampkt to WriteQueue and 
then access memory according to those drampkt in WriteQueue instead of adding 
drampkt to writeQueue and perform access(pkt) immediately.
Is anyone familiar with this aspect. Give me some suggestion plz.
Thanks!
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] How to use multiple channels in gem5

[Wendy Elsasser]

HI Nitish,
Can you provide the full command line that you are using?

Thanks,
Wendy

From: gem5-users  on behalf of Nitish Srivastava 

Reply-To: gem5 users mailing list 
Date: Wednesday, March 13, 2019 at 4:55 PM
To: "gem5-users@gem5.org" 
Subject: [gem5-users] How to use multiple channels in gem5

[Image removed by sender.]
Hi,

I am trying to use HBM_1000_4H_1x64 DRAM model with 8 channels. I do this by 
passing "--mem-type=HBM_1000_4H_1x64 --mem-channels=8" parameters while running 
gem5 simulation. However, I am not getting any performance improvement by 
increasing the number of channels. Do I need to do something else to make use 
of these channels? Some kind of address mapping scheme for the stored data?

Please let me know if you have suggestions. Any help will be appreciated.

Thanks,
Nitish


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] Some problem with use GDDR5 memory on gem5

[Wendy Elsasser]

Quick update –
The parameter that should be updated is tXP. I’ve updated the text below to fix 
my typo. Sorry for the confusion.

Regards,
Wendy

From: gem5-users  on behalf of username 

Reply-To: gem5 users mailing list 
Date: Wednesday, October 31, 2018 at 2:29 PM
To: gem5 users mailing list 
Subject: Re: [gem5-users] Some problem with use GDDR5 memory on gem5

Hi,
Looks like this is due to an activate event being scheduled at the same time as 
a power-up event (wake-up from low-power state). In general, these will not 
occur simultaneously, and in the best case would occur on back-to-back cycles, 
with the ACT scheduled after the power-up event. To address this in the short 
term, you can set the tXP parameter of the memory to the same value as tCK (or 
greater for additional delay if required). For the GDDR_4000_2x32 config, the 
following setting should address the issue with minimum power-down exit timing. 
You can consult data sheets for a more realistic number as well.
tXP = ‘1ns’

If you still have issues, please let me know.

In parallel, I will look at options to patch the code to avoid this issue in 
the future.

Regards,
Wendy

From: gem5-users  on behalf of 王宥憲 

Reply-To: gem5 users mailing list 
Date: Tuesday, October 30, 2018 at 5:42 PM
To: "gem5-users@gem5.org" 
Subject: [gem5-users] Some problem with use GDDR5 memory on gem5

Hello everyone,

I want to use "GDDR5_4000_2x32" memory type on gem5 SE mode and FS mode.

I can successfully use it when doesn't any cpu type, just use default value.

But there will show some error when memory type chose "GDDR5_4000_2x32" and cpu 
type chose "TimingSimpleCPU" at the same time.


gem5 Simulator System.  http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.

gem5 compiled Oct 31 2018 04:53:40
gem5 started Oct 31 2018 05:07:52
gem5 executing on lab-All-Series, pid 15813
command line: build/X86/gem5.opt configs/example/se.py -c /home/lab/try/a.out 
--mem-type=ScratchpadMemoryDRAM --cpu-type=TimingSimpleCPU

Global frequency set at 1 ticks per second
warn: DRAM device capacity (1024 Mbytes) does not match the address range 
assigned (512 Mbytes)
0: system.remote_gdb: listening for remote gdb on port 7000
 REAL SIMULATION 
info: Entering event queue @ 0.  Starting simulation...
gem5.opt: build/X86/mem/dram_ctrl.cc:2113: void 
DRAMCtrl::Rank::processWakeUpEvent(): Assertion `(pwrState == PWR_ACT_PDN) || 
(pwrState == PWR_PRE_PDN) || (pwrState == PWR_SREF)' failed.
Program aborted at tick 123000
--- BEGIN LIBC BACKTRACE ---
build/X86/gem5.opt(_Z15print_backtracev+0x28)[0xe1f5f8]
build/X86/gem5.opt(_Z12abortHandleri+0x46)[0xe32b66]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7f9191d64390]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7f91903c6428]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f91903c802a]
/lib/x86_64-linux-gnu/libc.so.6(+0x2dbd7)[0x7f91903bebd7]
/lib/x86_64-linux-gnu/libc.so.6(+0x2dc82)[0x7f91903bec82]
build/X86/gem5.opt[0xcdfdeb]
build/X86/gem5.opt(_ZN10EventQueue10serviceOneEv+0xd5)[0xe26555]
build/X86/gem5.opt(_Z9doSimLoopP10EventQueue+0x48)[0xe3f878]
build/X86/gem5.opt(_Z8simulatem+0xce3)[0xe40913]
build/X86/gem5.opt[0xe0845d]
build/X86/gem5.opt[0x96c3dc]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x7852)[0x7f9192021772]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7f919215805c]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6ffd)[0x7f9192020f1d]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7f919215805c]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6ffd)[0x7f9192020f1d]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7f919215805c]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6ffd)[0x7f9192020f1d]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7f919215805c]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7f9192019da9]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x613b)[0x7f919202005b]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7f919215805c]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6ffd)[0x7f9192020f1d]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7f919215805c]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7f9192019da9]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyRun_StringFlags+0x76)[0x7f91920941f6]
build/X86/gem5.opt(_Z6m5MainiPPc+0x8f)[0xe3152f]
build/X86/gem5.opt(main+0x33)[0x6b9ad3]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f91903b1830]
build/X86/gem5.opt(_start+0x29)[0x6db809]
--- END LIBC BACKTRACE ---
已經終止 (core dumped)

My gem5 clone from "http://repo.gem5.org/gem5"; and I don't change any file.

My compiler is gcc 6 and OS version is ubuntu 16.04.5 LTS.

Can anyone help me?
Look forward to hearing from you.

Re: [gem5-users] Some problem with use GDDR5 memory on gem5

[Wendy Elsasser]

Hi,
Looks like this is due to an activate event being scheduled at the same time as 
a power-up event (wake-up from low-power state). In general, these will not 
occur simultaneously, and in the best case would occur on back-to-back cycles, 
with the ACT scheduled after the power-up event. To address this in the short 
term, you can set the tXS parameter of the memory to the same value as tCK (or 
greater for additional delay if required). For the GDDR_4000_2x32 config, the 
following setting should address the issue with minimum power-down exit timing. 
You can consult data sheets for a more realistic number as well.
tXS = ‘1ns’

If you still have issues, please let me know.

In parallel, I will look at options to patch the code to avoid this issue in 
the future.

Regards,
Wendy

From: gem5-users  on behalf of 王宥憲 

Reply-To: gem5 users mailing list 
Date: Tuesday, October 30, 2018 at 5:42 PM
To: "gem5-users@gem5.org" 
Subject: [gem5-users] Some problem with use GDDR5 memory on gem5

Hello everyone,

I want to use "GDDR5_4000_2x32" memory type on gem5 SE mode and FS mode.

I can successfully use it when doesn't any cpu type, just use default value.

But there will show some error when memory type chose "GDDR5_4000_2x32" and cpu 
type chose "TimingSimpleCPU" at the same time.


gem5 Simulator System.  http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.

gem5 compiled Oct 31 2018 04:53:40
gem5 started Oct 31 2018 05:07:52
gem5 executing on lab-All-Series, pid 15813
command line: build/X86/gem5.opt configs/example/se.py -c /home/lab/try/a.out 
--mem-type=ScratchpadMemoryDRAM --cpu-type=TimingSimpleCPU

Global frequency set at 1 ticks per second
warn: DRAM device capacity (1024 Mbytes) does not match the address range 
assigned (512 Mbytes)
0: system.remote_gdb: listening for remote gdb on port 7000
 REAL SIMULATION 
info: Entering event queue @ 0.  Starting simulation...
gem5.opt: build/X86/mem/dram_ctrl.cc:2113: void 
DRAMCtrl::Rank::processWakeUpEvent(): Assertion `(pwrState == PWR_ACT_PDN) || 
(pwrState == PWR_PRE_PDN) || (pwrState == PWR_SREF)' failed.
Program aborted at tick 123000
--- BEGIN LIBC BACKTRACE ---
build/X86/gem5.opt(_Z15print_backtracev+0x28)[0xe1f5f8]
build/X86/gem5.opt(_Z12abortHandleri+0x46)[0xe32b66]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7f9191d64390]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7f91903c6428]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f91903c802a]
/lib/x86_64-linux-gnu/libc.so.6(+0x2dbd7)[0x7f91903bebd7]
/lib/x86_64-linux-gnu/libc.so.6(+0x2dc82)[0x7f91903bec82]
build/X86/gem5.opt[0xcdfdeb]
build/X86/gem5.opt(_ZN10EventQueue10serviceOneEv+0xd5)[0xe26555]
build/X86/gem5.opt(_Z9doSimLoopP10EventQueue+0x48)[0xe3f878]
build/X86/gem5.opt(_Z8simulatem+0xce3)[0xe40913]
build/X86/gem5.opt[0xe0845d]
build/X86/gem5.opt[0x96c3dc]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x7852)[0x7f9192021772]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7f919215805c]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6ffd)[0x7f9192020f1d]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7f919215805c]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6ffd)[0x7f9192020f1d]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7f919215805c]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6ffd)[0x7f9192020f1d]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7f919215805c]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7f9192019da9]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x613b)[0x7f919202005b]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7f919215805c]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6ffd)[0x7f9192020f1d]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85c)[0x7f919215805c]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7f9192019da9]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyRun_StringFlags+0x76)[0x7f91920941f6]
build/X86/gem5.opt(_Z6m5MainiPPc+0x8f)[0xe3152f]
build/X86/gem5.opt(main+0x33)[0x6b9ad3]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f91903b1830]
build/X86/gem5.opt(_start+0x29)[0x6db809]
--- END LIBC BACKTRACE ---
已經終止 (core dumped)

My gem5 clone from "http://repo.gem5.org/gem5"; and I don't change any file.

My compiler is gcc 6 and OS version is ubuntu 16.04.5 LTS.

Can anyone help me?
Look forward to hearing from you.

Respectfully yours, Yo-Xian,Wang


[Image removed by 
sender.]

不含病毒。www.avast.com


IMPORTANT NOTICE: The contents of this email and any attachment

Re: [gem5-users] about memory configuration

[Wendy Elsasser]

Hi Jung Min,
The term ‘device’ represents a DRAM chip.

As an example, DDR3 DIMM solutions typically have a 64-bit interface and are 
comprised of multiple DRAM chips.

If the device_bus_width = 8, each device has 8 data pins and there will be 8 
devices required for the 64-bit interface.  Therefore, devices_per_rank = 8 for 
this case.
If the devices are 8Gbit devices, the device_size = 1GB and the overall DIMM 
capacity per rank is 8GB.

Please let me know if you have any more questions or if this is still unclear.

Regards,
Wendy

From: gem5-users  on behalf of 류정민 

Reply-To: gem5 users mailing list 
Date: Friday, September 28, 2018 at 1:38 AM
To: gem5 users mailing list 
Subject: [gem5-users] about memory configuration

Hi, I am working on modifying the memory configuration in gem5 simulator.

I found that src/mem/DRAMCtrl.py controls the overall configuration of gem5 
memory system.

However, I can't understand the meaning of the term 'device'.

For instance, DDR3 has device_size parameter and there are much more important 
parameters related to the 'device' term.

I guess it is as same as 'chip', but I am not sure.

If you have any knowledge about the parameter 'device', please give me an 
advise.

Best regards,

Jung Min.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] DRAMCtrl parameters for DDR4_2400_8x8

[Wendy Elsasser]

Hi everyone,
DDR4 does have 16 banks, while DDR3 is a 8 bank devices, but the devices per 
rank are defined by the module (interface). I agree that for the 2400_8x8 
configuration there should be 8 devices per rank defined. I am in the process 
of fixing this. Thanks for drawing this to my attention.

Regards,
Wendy

On 2/9/18, 10:30 AM, "gem5-users on behalf of hassan yamin" 
 wrote:

DDR4 standard has 16 devices per rank. In DDR3 it is 8 devices per rank.

On Fri, Feb 9, 2018 at 6:12 AM, 조해윤  wrote:
> Dear, all.
>
> According to below link,
> http://repo.gem5.org/gem5?cmd=changeset;node=17b37f38944a
> DDR4_2400_8x8 uses a 8-bit width device and 8 devices are in a rank.
>
> My doubt is  the below.
> DDR4_2400_8x8 class is overriding DDR4_2400_16x4 class in DRAMCtrl.py
> However, the  devices_per_rank is still 16.
> In my understanding, devices_per_rank should be 8.
> Is there any missing point for my understanding?
>
> Best regards,
> Haeyoon Cho
>
> ___
> gem5-users mailing list
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users