TODOs

Top-priority TODOs
-------------------------------------------------
1. Get familiar with GARNET design details.
2. Fix bugs in AntNet implementation.
3. Merge the CPU2006 scripts with gem5.

Urgent TODOs
-------------------------------------------------
1. Investigate on how to send a packet in GEM5/Ruby/GARNET.
2. Investigate on how to get the number of router IDs and obtain the links of the specified router in GEM5/Ruby/GARNET.
3. Investigate on how to support adaptive routing in GEM5/Ruby/GARNET.
4. Test multiple workload mapping and running.
5. Support running of CPU2006.

Normal TODOs
-------------------------------------------------
1. Support running of Linux kernel 3.19.
2. Specify number of instructions/cycles to be simulated in detailed/FS simulation phase.
3. add custom statistics in gem5 (e.g., formula).
4. Add experiments on NUMA cache sizes, replacement policies.
5. Use formula in place of hardcoded memory sizes in ccnuma_fs.py.
6. Incorporate energy efficient caching.

PARSEC
-------------------------------------------------
http://comments.gmane.org/gmane.comp.emulators.m5.users/12503
http://www.cs.utexas.edu/~parsec_m5/
http://www.cs.utexas.edu/~parsec_m5/TR-09-32.pdf
http://www.m5sim.org/PARSEC_benchmarks#Running_PARSEC_in_gem5
https://schen26.wordpress.com/2012/11/16/parsec-on-m5-with-x86_fs/
http://yulistic.com/problems-solutions/230   [Gem5] Make a new boot image

General
-------------------------------------------------
https://github.com/lzyerste/gem5_doc/wiki

Computer Architecture Research
-------------------------------------------------
http://arc.zju.edu.cn/research

gem5 horrors and solutions
-------------------------------------------------
http://www.lowepower.com/jason/gem5-horrors-and-what-we-can-do-about-it.html

NUMA
-------------------------------------------------
http://reviews.gem5.org/r/1113/#review2467

http://qa.gem5.org/1395/how-to-simulate-a-numa-system?show=1395#q1395
https://www.mail-archive.com/gem5-users@gem5.org/msg09699.html
https://www.mail-archive.com/gem5-users@gem5.org/msg09709.html
http://t362027.emulators-m5-users.emulatortalk.info/help-cc-numa-in-gem5-t362027.html
https://github.com/djangkrix/gem5

http://search.gmane.org/?query=numa&group=gmane.comp.emulators.m5.users
http://thread.gmane.org/gmane.comp.emulators.m5.users/3927 *
http://thread.gmane.org/gmane.comp.emulators.m5.users/13134
http://thread.gmane.org/gmane.comp.emulators.m5.users/13188
http://thread.gmane.org/gmane.comp.emulators.m5.users/14277
http://thread.gmane.org/gmane.comp.emulators.m5.users/15970
http://thread.gmane.org/gmane.comp.emulators.m5.users/15980

http://thread.gmane.org/gmane.comp.emulators.m5.users/16572 *
http://thread.gmane.org/gmane.comp.emulators.m5.users/17326 *

http://thread.gmane.org/gmane.comp.emulators.m5.users/17738
http://thread.gmane.org/gmane.comp.emulators.m5.users/14663

I just created:
A. a 4 cpu numa system,
B. each cpu connect to a membus and then a dram controller,
C. each dram is 128MB,
D. every two membus is connected to each other by a Cache(in two
directions),
E. with address range set to the slave mebus's address range.
F. IO devices are connected to the first node.


> Hi Faris,
>
> I do not think there are any existing examples out there. In essence,
> this is what I would suggest (and believe should work):
>
> 1 change an existing script to create two completely separate CC-UMA
> "chiplets" with CPU clusters, along with their L2/L3, membus and
> (multi-channel) DRAM controller
> 2 connect these two blobs with a "numa cache" in each direction, from
> membus to membus. Configured right, this will allow the CPUs in one of
> the chiplets to talk to the DRAMs in the other in a coherent fashion.
>
> I hope that provides enough information to get you started.
>
> Andreas


Hi Faris,
>
>             The short answer is yes. You will have to manually adapt
>             se.py or fs.py based on your needs. You could, for
>             example, create two clusters of CPUs, each with their own
>             LLC and memory controllers (and memory ranges), and then
>             connect their membus instances with a "glue" cache.
>
>             Andreas


Understanding stat.txt file with multiple regions
-------------------------------------------------
https://www.mail-archive.com/gem5-users@gem5.org/msg08083.html

Hi Fulya,


> I am running Parsec on X86 FS mode using the precompiled Parsec binaries
> for X86. When i examine the stats.txt file, I see 4 sets of simulation
> statistics. I am using the .rcS script:
> #!/bin/sh
> # File to run the canneal benchmark
> cd /parsec/install/bin
> /sbin/m5 switchcpu
> */sbin/m5 dumpstats
> /sbin/m5 resetstats*
> ./canneal 4 15000 2000 /parsec/install/inputs/canneal/200000.nets 64
> echo "Done :D"
> /sbin/m5 exit
> /sbin/m5 exit
> I am assuming the first set of stats correspond to the m5 command
> "dumpstats" that i have in .rcS script right before the benchmark starts
> execution. I am also assuming that the Parsec binaries themselves have
> been instrumented to dump stats based on specific regions of the program
> (like ROI). Could you confirm that? Also could you tell me what the next 3
> sets of stats correspond to? I am trying to figure out how many
> instructions are executed until the beginning of ROI.
>

That is correct that the PARSEC benchmarks on both the ALPHA and x86 disk
images from our website (http://www.cs.utexas.edu/~parsec_m5/) will dump
and reset statistics at the beginning and end of the benchmark region of
interest.  Based on your run script above, you should see 4 separate sets
of statistics at the end of simulation corresponding to: (1) the start of
simulation until the dump in the runscript (above), (2) the beginning of
the benchmark up to the beginning of the ROI in the benchmark, (3) the
benchmark ROI, and (4) from the end of the ROI to when the simulation exits
on '/sbin/m5 exit' (above).  If you are interested in the number of
instructions leading up to the ROI, you'll be interested in the stats from
the first two stats segments.

  Hope this helps,
  Joel