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 > 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> > 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> >> Date: Tuesday, 9 September 2014 18:56 >> To: Andreas Hansson <andreas.hans...@arm.com> >> Cc: gem5 users mailing list <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> >> 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. >>> >>> 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> >>> Reply-To: Prathap Kolakkampadath <kvprat...@gmail.com>, gem5 users >>> mailing list <gem5-users@gem5.org> >>> Date: Monday, 8 September 2014 18:38 >>> To: gem5 users mailing list <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 >> > >
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
