Re: [gem5-dev] Review Request 3498: tests: Split test results into running and verification

2016-06-15 Thread Joe Gross 

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3498/#review8412
---

Ship it!


Ship It!

- Joe Gross


On June 6, 2016, 11:50 a.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3498/
> ---
> 
> (Updated June 6, 2016, 11:50 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11532:284b74f149d1
> ---
> tests: Split test results into running and verification
> 
> The test base class already assumes that test cases consists of a run
> stage and a verification stage. Reflect this in the results class to
> make it possible to detect cases where a run was successful, but
> didn't verify.
> 
> Change-Id: I31ef393e496671221c5408aca41649cd8dda74ca
> Signed-off-by: Andreas Sandberg 
> Reviewed-by: Curtis Dunham 
> 
> 
> Diffs
> -
> 
>   tests/SConscript 6e143fd2cabf 
>   tests/testing/results.py 6e143fd2cabf 
>   tests/testing/tests.py 6e143fd2cabf 
> 
> Diff: http://reviews.gem5.org/r/3498/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3500: tests: Add a test command to get test status as an exit code

2016-06-15 Thread Joe Gross 

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3500/#review8411
---

Ship it!


This looks like a nice feature to easily roll up the tester results.

- Joe Gross


On June 6, 2016, 11:50 a.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3500/
> ---
> 
> (Updated June 6, 2016, 11:50 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11533:ca86fea05ac8
> ---
> tests: Add a test command to get test status as an exit code
> 
> Add a "test" command to tests.py that queries a test pickle file and
> returns different exit codes depending on the outcome of the tests in
> the file. The following exit codes can currently be returned:
> 
>   * 0: All tests were successful or skipped.
> 
>   * 1: General fault in the script such as incorrect parameters or
> failing to parse a pickle file.
> 
>   * 2: At least one test failed to run. This is what the summary
> formatter usually shows as a 'FAILED'.
> 
>   * 3: All tests ran correctly, but at least one failed to verify
> its output. When displaying test output using the summary
> formatter, such a test would show up as 'CHANGED'.
> 
> The command can be invoked like this:
> 
> ./tests/tests.py test `find build/ARM/tests/opt/ -name status.pickle`
> 
> Change-Id: I7e6bc661516f38ff08dfda7c4359a1e10bf97864
> Signed-off-by: Andreas Sandberg 
> Reviewed-by: Curtis Dunham 
> 
> 
> Diffs
> -
> 
>   tests/tests.py 6e143fd2cabf 
> 
> Diff: http://reviews.gem5.org/r/3500/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3477: misc: SystemC Elastic Trace Player Example

2016-06-15 Thread Matthias Jung 


> On Juni 15, 2016, 2:23 nachm., Andreas Sandberg wrote:
> > Thanks for your patch!
> > 
> > I think this config script is independant enough that you should consider 
> > not using the Options helper in configs/common. I would argue that it just 
> > creates confusion due to the large number of unused options. I would 
> > suggest that you make it as independent as possible of the functionality in 
> > config/common/ and make it completely stand alone instead. However, don't 
> > consider these comments to be blockers for submission, they are just 
> > nice-to-have improvements.
> 
> Jason Lowe-Power wrote:
> I agree with this, Andreas! What Andreas said is a much clearer way to 
> get to the point I was making in my review.
> 
> I would really like to see this change. Although I won't block it either, 
> it seems like it shouldn't take long to update. I hope you choose to, 
> Matthias.

Thank you for the suggestions, of course I will address them and update the 
patch! We should get this into gem5 before the SAMOS conference (mid of july) 
where we will present the new elastic trace player approach and the systemc 
player.

Thanks again and regards
Matthias


> On Juni 15, 2016, 2:23 nachm., Andreas Sandberg wrote:
> > util/tlm/tlm_elastic.py, line 126
> > 
> >
> > This shouldn't be needed since you're not in FS mode (and you're 
> > simulating a trace CPU).

Actually cpu.createInterruptController() is needed it wont work else :/


- Matthias


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3477/#review8408
---


On Juni 14, 2016, 9:06 nachm., Matthias Jung wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3477/
> ---
> 
> (Updated Juni 14, 2016, 9:06 nachm.)
> 
> 
> Review request for Default and Andreas Sandberg.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> This patch adds an example configuration for elastic trace playing into the
> SystemC world, similar to the already existing traffic generator example in
> /util/tlm.
> 
> 
> Diffs
> -
> 
>   util/tlm/README fc247b9c42b6 
>   util/tlm/tlm_elastic.py PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/3477/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Matthias Jung
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Ruby Network Messages

2016-06-15 Thread Mohamed Ibrahim 
Hi,

I wanted to look into the message types flowing the network within gem5. In
the stats.txt file I found a section for the count of the following message
types:
system.ruby.network.msg_count.Control
system.ruby.network.msg_count.Request_Control
system.ruby.network.msg_count.Response_Data
system.ruby.network.msg_count.Response_Control
system.ruby.network.msg_count.Writeback_Data
system.ruby.network.msg_count.Writeback_Control
system.ruby.network.msg_count.Unblock_Control

Is there any description for these message (function, source, ...)? I have
checked the SLICC files, however there was no clear documentation for such
messages.

Thanks.

-- 
Regards,
Mohamed
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3477: misc: SystemC Elastic Trace Player Example

2016-06-15 Thread Jason Lowe-Power 


> On June 15, 2016, 2:23 p.m., Andreas Sandberg wrote:
> > Thanks for your patch!
> > 
> > I think this config script is independant enough that you should consider 
> > not using the Options helper in configs/common. I would argue that it just 
> > creates confusion due to the large number of unused options. I would 
> > suggest that you make it as independent as possible of the functionality in 
> > config/common/ and make it completely stand alone instead. However, don't 
> > consider these comments to be blockers for submission, they are just 
> > nice-to-have improvements.

I agree with this, Andreas! What Andreas said is a much clearer way to get to 
the point I was making in my review.

I would really like to see this change. Although I won't block it either, it 
seems like it shouldn't take long to update. I hope you choose to, Matthias.


- Jason


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3477/#review8408
---


On June 14, 2016, 9:06 p.m., Matthias Jung wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3477/
> ---
> 
> (Updated June 14, 2016, 9:06 p.m.)
> 
> 
> Review request for Default and Andreas Sandberg.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> This patch adds an example configuration for elastic trace playing into the
> SystemC world, similar to the already existing traffic generator example in
> /util/tlm.
> 
> 
> Diffs
> -
> 
>   util/tlm/README fc247b9c42b6 
>   util/tlm/tlm_elastic.py PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/3477/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Matthias Jung
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3502: cache: Split the hit latency into tag lookup latency and RAM access latency

2016-06-15 Thread Sophiane SENNI 

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3502/
---

(Updated juin 15, 2016, 2:43 après-midi)


Review request for Default.


Repository: gem5


Description (updated)
---

Changeset 10875:b498767cb7d8
---
cache: Split the hit latency into tag lookup latency and RAM access latency

If the cache access mode is parallel ("sequential_access" parameter set to 
"False"), tags and RAMs are accessed in parallel. Therefore, the hit latency is 
the maximum latency between tag lookup latency and RAM access latency. On the 
other hand, if the cache access mode is sequential ("sequential_access" 
parameter set to "True"), tags and RAM are accessed sequentially. Therefore, 
the hit latency is the sum of tag lookup latency plus RAM access latency.


Diffs
-

  configs/common/Caches.py 629fe6e6c781 
  src/mem/cache/tags/base_set_assoc.hh 629fe6e6c781 
  src/mem/cache/tags/fa_lru.hh 629fe6e6c781 
  src/mem/cache/tags/fa_lru.cc 629fe6e6c781 
  src/mem/cache/BaseCache.py 629fe6e6c781 
  src/mem/cache/base.hh 629fe6e6c781 
  src/mem/cache/base.cc 629fe6e6c781 
  src/mem/cache/tags/Tags.py 629fe6e6c781 
  src/mem/cache/tags/base.hh 629fe6e6c781 
  src/mem/cache/tags/base.cc 629fe6e6c781 

Diff: http://reviews.gem5.org/r/3502/diff/


Testing
---

Tested using --Debug-flags=Cache


Thanks,

Sophiane SENNI

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3502: cache: Split the hit latency into tag lookup latency and RAM access latency

2016-06-15 Thread Sophiane SENNI 

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3502/
---

(Updated June 15, 2016, 2:34 p.m.)


Review request for Default.


Summary (updated)
-

cache: Split the hit latency into tag lookup latency and RAM access latency


Repository: gem5


Description (updated)
---

Changeset 10875:b498767cb7d8
---
cache: Split the hit latency into tag lookup latency and RAM access latency


Diffs (updated)
-

  configs/common/Caches.py 629fe6e6c781 
  src/mem/cache/tags/base_set_assoc.hh 629fe6e6c781 
  src/mem/cache/tags/fa_lru.hh 629fe6e6c781 
  src/mem/cache/tags/fa_lru.cc 629fe6e6c781 
  src/mem/cache/BaseCache.py 629fe6e6c781 
  src/mem/cache/base.hh 629fe6e6c781 
  src/mem/cache/base.cc 629fe6e6c781 
  src/mem/cache/tags/Tags.py 629fe6e6c781 
  src/mem/cache/tags/base.hh 629fe6e6c781 
  src/mem/cache/tags/base.cc 629fe6e6c781 

Diff: http://reviews.gem5.org/r/3502/diff/


Testing
---

Tested using --Debug-flags=Cache


Thanks,

Sophiane SENNI

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3502: Split the hit latency into tag lookup latency and RAM access latency

2016-06-15 Thread Sophiane SENNI 

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3502/
---

Review request for Default.


Repository: gem5


Description
---

Split the hit latency into tag lookup latency and RAM access latency.

If the cache access mode is parallel ("sequential_access" parameter set to 
"False"), tags and RAMs are accessed in parallel. Therefore, the hit latency is 
the maximum latency between tag lookup latency and RAM access latency. On the 
other hand, if the cache access mode is sequential ("sequential_access" 
parameter set to "True"), tags and RAM are accessed sequentially. Therefore, 
the hit latency is the sum of tag lookup latency plus RAM access latency.


Diffs
-

  configs/common/Caches.py 629fe6e6c781 
  src/mem/cache/BaseCache.py 629fe6e6c781 
  src/mem/cache/base.hh 629fe6e6c781 
  src/mem/cache/base.cc 629fe6e6c781 
  src/mem/cache/tags/Tags.py 629fe6e6c781 
  src/mem/cache/tags/base.hh 629fe6e6c781 
  src/mem/cache/tags/base.cc 629fe6e6c781 
  src/mem/cache/tags/base_set_assoc.hh 629fe6e6c781 
  src/mem/cache/tags/fa_lru.cc 629fe6e6c781 
  src/mem/cache/tags/fa_lru.hh 629fe6e6c781 

Diff: http://reviews.gem5.org/r/3502/diff/


Testing
---

Tested using --Debug-flags=Cache


Thanks,

Sophiane SENNI

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3477: misc: SystemC Elastic Trace Player Example

2016-06-15 Thread Andreas Sandberg 

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3477/#review8408
---


Thanks for your patch!

I think this config script is independant enough that you should consider not 
using the Options helper in configs/common. I would argue that it just creates 
confusion due to the large number of unused options. I would suggest that you 
make it as independent as possible of the functionality in config/common/ and 
make it completely stand alone instead. However, don't consider these comments 
to be blockers for submission, they are just nice-to-have improvements.


util/tlm/tlm_elastic.py (lines 41 - 44)


I'd suggest not using any of these components. You'll just end up creating 
a gazillion of options that you'll never use in the end.



util/tlm/tlm_elastic.py (line 96)


You already force options.cpu_type to 'trace', which means that you 
statically already know that your CPU will be the TraceCPU and the memory mode 
will be timing.



util/tlm/tlm_elastic.py (line 97)


You shouldn't need to care about this for the trace cpu.



util/tlm/tlm_elastic.py (lines 100 - 101)


cpu=TraceCPU(cpu_id=0),
mem_mode='timing',



util/tlm/tlm_elastic.py (line 126)


This shouldn't be needed since you're not in FS mode (and you're simulating 
a trace CPU).


- Andreas Sandberg


On June 14, 2016, 10:06 p.m., Matthias Jung wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3477/
> ---
> 
> (Updated June 14, 2016, 10:06 p.m.)
> 
> 
> Review request for Default and Andreas Sandberg.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> This patch adds an example configuration for elastic trace playing into the
> SystemC world, similar to the already existing traffic generator example in
> /util/tlm.
> 
> 
> Diffs
> -
> 
>   util/tlm/README fc247b9c42b6 
>   util/tlm/tlm_elastic.py PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/3477/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Matthias Jung
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Cron <m5test@zizzer> /z/m5/regression/do-regression quick

2016-06-15 Thread Cron Daemon 
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-atomic: passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing: 
passed.* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/minor-timing: 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing: passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby: 
passed. 
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing: passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/o3-timing: passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-atomic: passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing: passed.
* build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing-mt: 
passed.* 
build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby: passed.
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-simple:
 passed.
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-two-level:
 passed.
* build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-atomic: 
passed.
* build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-timing: 
passed.
* build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-timing-mp: 
passed.
* build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-atomic-mp: 
passed.
* build/ALPHA/tests/opt/quick/se/30.eon/alpha/tru64/simple-atomic: passed.
* build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby: 
passed.
* build/ALPHA/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby: 
passed.
* build/ALPHA/tests/opt/quick/se/50.vortex/alpha/tru64/simple-atomic: 
passed.
* build/ALPHA/tests/opt/quick/se/50.vortex/alpha/tru64/simple-timing: 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic: 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual:
 passed.
* build/ALPHA/tests/opt/quick/se/70.twolf/alpha/tru64/simple-atomic: passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing: 
passed.
* build/ALPHA/tests/opt/quick/se/70.twolf/alpha/tru64/simple-timing: passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual:
 passed.
* 
build/ALPHA/tests/opt/quick/fs/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic:
 passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer:
 passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer:
 passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer:
 passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer:
 passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MESI_Two_Level:
 passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MESI_Two_Level:
 passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MESI_Two_Level:
 passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MESI_Two_Level:
 passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory:
 passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory:
 passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory:
 passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory:
 passed.
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token:
 passed.
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token:
 passed.
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token:
 passed.
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token:
 passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing: passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-atomic: passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing: passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing-ruby: 
passed.
* 
build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-simple:
 passed.
* 
build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-two-level:
 passed.
*