Hi Prathap,
Indeed. The atomic mode is for fast-forwarding only. Once you actually want to
get some representative performance numbers you have to run in timing mode with
either the O3 or Minor CPU model.
Andreas
From: Prathap Kolakkampadath <kvprat...@gmail.com<mailto:kvprat...@gmail.com>>
Date: Monday, 13 October 2014 10:19
To: Andreas Hansson <andreas.hans...@arm.com<mailto:andreas.hans...@arm.com>>
Cc: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>>
Subject: Re: [gem5-users] Questions on DRAM Controller model
Thanks for your reply. The memory mode which I used is atomic. I think, I need
to run the tests in timing More. I believe which shows up interference and
queueing delay similar to real platforms.
Prathap
On Oct 13, 2014 2:55 AM, "Andreas Hansson"
<andreas.hans...@arm.com<mailto:andreas.hans...@arm.com>> wrote:
Hi Prathap,
I don’t dare say exactly what is going wrong in your setup, but I am confident
that Ruby will not magically make things more representative (it will likely
give you a whole lot more problems though). In the end it is all about
configuring the building blocks to match the system you want to capture. The
crossbars and caches in the classic memory system do make some simplifications,
but I have not yet seen a case when they are not sufficiently accurate.
Have you looked at the various policy settings in the DRAM controller, e.g. the
page policy and address mapping? If you’re trying to correlate with a real
platform, also see Anthony’s ISPASS paper from last year for some sensible
steps in simplifying the problem and dividing it into manageable chunks.
Good luck.
Andreas
From: Prathap Kolakkampadath <kvprat...@gmail.com<mailto:kvprat...@gmail.com>>
Date: Monday, 13 October 2014 00:29
To: Andreas Hansson <andreas.hans...@arm.com<mailto:andreas.hans...@arm.com>>
Cc: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>>
Subject: Re: [gem5-users] Questions on DRAM Controller model
Hello Andreas/Users,
I used to create a checkpoint until linux boot using Atomic Simple CPU and then
restore from this checkpoint to detailed O3 cpu before running the test. I
notice that the mem-mode is set to atomic and not timing. Will that be the
reason for less contention in memory bus i am observing?
Thanks,
Prathap
On Sun, Oct 12, 2014 at 4:56 PM, Prathap Kolakkampadath
<kvprat...@gmail.com<mailto:kvprat...@gmail.com>> wrote:
Hello Andreas,
Even after configuring the model like the actual hardware, i still not seeing
enough interference to the read request under consideration. I am using the
classic memory system model. Since it uses atomic and functional
Packet allocation protocol, I would like to switch to Ruby( I think it more
resembles with real platform).
I am hitting in to below problem when i use ruby.
/build/ARM/gem5.opt --stats-file=cr1A1.txt configs/example/fs.py --caches
--l2cache --l1d_size=32kB --l1i_size=32kB --l2_size=1MB --num-cpus=4
--mem-size=512MB
--kernel=/home/prathap/WorkSpace/linux-linaro-tracking-gem5/vmlinux
--disk-image=/home/prathap/WorkSpace/gem5/fullsystem/disks/arm-ubuntu-natty-headless.img
--machine-type=VExpress_EMM
--dtb-file=/home/prathap/WorkSpace/linux-linaro-tracking-gem5/arch/arm/boot/dts/vexpress-v2p-ca15-tc1-gem5_4cpus.dtb
--cpu-type=detailed --ruby --mem-type=ddr3_1600_x64
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/home/prathap/WorkSpace/gem5/src/python/m5/main.py", line 388, in main
exec filecode in scope
File "configs/example/fs.py", line 302, in <module>
test_sys = build_test_system(np)
File "configs/example/fs.py", line 138, in build_test_system
Ruby.create_system(options, test_sys, test_sys.iobus, test_sys._dma_ports)
File "/home/prathap/WorkSpace/gem5/src/python/m5/SimObject.py", line 825, in
__getattr__
raise AttributeError, err_string
AttributeError: object 'LinuxArmSystem' has no attribute '_dma_ports'
(C++ object is not yet constructed, so wrapped C++ methods are unavailable.)
What could be the cause of this?
Thanks,
Prathap
On Tue, Sep 9, 2014 at 1:35 PM, Andreas Hansson
<andreas.hans...@arm.com<mailto:andreas.hans...@arm.com>> wrote:
Hi Prathap,
There are many possible reasons for the discrepancy, and obviously there are
many ways of building a memory controller :-). Have you configured the model to
look like the actual hardware? The most obvious differences would be in terms
of buffer sizes, the page policy, arbitration policy, the threshold before
closing a page, the read/write switching, actual timings etc. It is also worth
checking if the controller hardware treats writes the same way the model does
(early responses, minimise switching).
Andreas
From: Prathap Kolakkampadath <kvprat...@gmail.com<mailto:kvprat...@gmail.com>>
Date: Tuesday, 9 September 2014 18:56
To: Andreas Hansson <andreas.hans...@arm.com<mailto:andreas.hans...@arm.com>>
Cc: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>>
Subject: Re: [gem5-users] Questions on DRAM Controller model
Hello Andreas,
Thanks for your reply. I read your ISPASS paper and got a fair understanding
about the architecture.
I am trying to reproduce the results, collected from running synthetic
benchmarks (latency and bandwidth) on real hardware, in Simulator
Environment.However, i could see variations in the results and i am trying to
understand the reasons.
The experiment has latency(memory non-intensive with random access) as the
primary task and bandwidth(memory intensive with sequential access) as the
co-runner task.
On real hardware
case 1 - 0 corunner : latency of the test is 74.88ns and b/w 854.74MB/s
case 2 - 1 corunner : latency of the test is 225.95ns and b/w 283.24MB/s
On simulator
case 1 - 0 corunner : latency of the test is 76.08ns and b/w 802.25MB/s
case 2 - 1 corunner : latency of the test is 93.69ns and b/w 651.57MB/s
Case 1 where latency test run alone(0 corunner), the results matches on both
environment. However Case 2, when run with bandwidth(1 corunner), the results
varies a lot.
Do you have any thoughts about this?
Thanks,
Prathap
On Mon, Sep 8, 2014 at 1:46 PM, Andreas Hansson
<andreas.hans...@arm.com<mailto:andreas.hans...@arm.com>> wrote:
Hi Prathap,
Have you read our ISPASS paper from last year? It’s referenced in the header
file, as well as on gem5.org<http://gem5.org>.
1. Yes and no. Two different buffers are used in the model are used, but they
are random access, so you can treat the entries any way you want.
2. Yes and no. It’s a C++ model, so the scheduler executes in 0 time. Thus,
when looking at the various requests it effectively sees all the banks.
3. Yes and no. See above.
Remember that this is a model. The goal is not to be representative down to
every last element of an RTL design. The goal is to be representative of a real
design, and then be fast. Both of these goals are delivered upon by the model.
I hope that explains it. IF there is anything in the results you do not agree
with, please do say so.
Thanks,
Andreas
From: Prathap Kolakkampadath via gem5-users
<gem5-users@gem5.org<mailto:gem5-users@gem5.org>>
Reply-To: Prathap Kolakkampadath
<kvprat...@gmail.com<mailto:kvprat...@gmail.com>>, gem5 users mailing list
<gem5-users@gem5.org<mailto:gem5-users@gem5.org>>
Date: Monday, 8 September 2014 18:38
To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>>
Subject: [gem5-users] Questions on DRAM Controller model
Hello Everybody,
I am using DDR3_1600_x64. I am trying to understand the memory controller
design and have few doubts about it.
1) Do the memory controller has a separate Bank request buffer (read and write
buffer) for each bank or just a global queue?
2) Is there a scheduler per bank which arbitrates between different queue
requests parallel with other bank schedulers?
3) Is there DRAM bus scheduler that arbitrates between different bank requests?
Thanks,
Prathap
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered
in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered
in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered
in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered
in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
