Re: [gem5-dev] Ruby: Token Coherence and Functional Access

2011-06-13 Thread Beckmann, Brad 
Yes, the token protocol is definitely one of those protocols that prevents us 
from tightly coupling the functional access support to the protocols.  However, 
I don't this issue will result in silently corrupted behavior.  Instead, it 
seems the result would be an error generated in the simulation, correct?  
Specifically in the example you mention, all controllers are in the stable 
Invalid state, right?  Therefore, the functional access won't find a valid 
block anywhere, and an error will be generated.  That seems like the right 
behavior to me.

Brad


> -Original Message-
> From: gem5-dev-boun...@m5sim.org [mailto:gem5-dev-
> boun...@m5sim.org] On Behalf Of Nilay Vaish
> Sent: Friday, June 10, 2011 8:50 AM
> To: gem5-dev@m5sim.org
> Subject: [gem5-dev] Ruby: Token Coherence and Functional Access
> 
> Brad, in the token coherence protocol, the l2 cache controller moves from
> state O to I and sends data to the memory. I think this particular transition 
> is
> may pose a problem in enabling functional accesses for the protocol. The
> problem, I think, is that both the directory and the cache controller are in
> stable states even though there is data travelling in the network. This means
> that both the controllers will allow a functional write to go ahead. But then
> the data will be over written by the value sent from the l2 controller to the
> directory controller.
> 
> My understanding of the protocol implementation is close to \epsilon. I think
> this is what I observed today in the morning. Do think this understanding is
> correct?
> 
> --
> Nilay
> ___
> gem5-dev mailing list
> gem5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/gem5-dev


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

Re: [gem5-dev] Review Request: Ruby: Add support for functional accesses

2011-06-13 Thread Brad Beckmann 

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/611/#review1330
---


This patch has all the functionality we need.  Also I really like the 
inheritance structure.  I have a few minor questions and suggestion below.  The 
only significant change/question I have is regarding the ruby system pointer.  
Right now the pointer is passed all throughout the ruby configuration process.  
Instead of doing this, can you leverage the parent.any functionality?  I know 
it can be confusing to avoid cycles in configuration, while leveraging 
parent.any, but it seems that the current system should work.  You already do 
the back pointer setting in C++ through the register pointer callbacks.


configs/ruby/Ruby.py


Why are you exec the strings instead of just directly including the 
commands?



src/mem/protocol/MOESI_CMP_directory-dir.sm


Why are you commenting out this check?  It seems to me that we can still 
include it, but if we cannot, we should remove the line.  Don't comment it out.



src/mem/protocol/MOESI_hammer-cache.sm


Same here?  Why comment this out?



src/mem/ruby/system/AbstractMemory.hh


It seems that the function "makeFunctionalAccess" is not turning a request 
into a functional access, but instead is actually performing the functional 
access.  How about we split these functions to "doFunctionalRead" and 
"doFunctionalWrite"?  That seems more appropriate and is more consistent with 
the rubyPort functions.



src/mem/ruby/system/AbstractMemory.py


Can you turn this into a parent any call and remove the need to pass around 
the ruby system pointer to all functions?



src/mem/ruby/system/CacheMemory.cc


It is possible to have a "-1" value here?  It seems that one only calls 
this function if the getPermission function returns Read_Only or Read_Write?  
Therefore aren't you guaranteed to find the block?



src/mem/ruby/system/DirectoryMemory.cc


Similar thing here.  It is possible to have the block not present here?  It 
seems that one only calls this function if the getPermission function returns 
Read_Only or Read_Write?  Therefore aren't you guaranteed to find the block?


- Brad


On 2011-06-12 14:55:53, Nilay Vaish wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/611/
> ---
> 
> (Updated 2011-06-12 14:55:53)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> Ruby: Add support for functional accesses
> This patch is meant for implementing functional access support in Ruby.
> Currently only the M5Port of RubyPort supports functional accesses. The
> support for functional through the PioPort will be added as a separate
> patch. The patch has been tested for MI, MOESI directory, MOESI hammer
> and MESI directory protocols. It seems that MOESI token protocol cannot
> support functional accesses with it current implementation, there seems
> to be some problem with the L2 cache controller.
> 
> 
> Diffs
> -
> 
>   configs/example/ruby_direct_test.py ac4da9f8ea80 
>   configs/example/ruby_fs.py ac4da9f8ea80 
>   configs/example/ruby_mem_test.py ac4da9f8ea80 
>   configs/example/ruby_network_test.py ac4da9f8ea80 
>   configs/example/ruby_random_test.py ac4da9f8ea80 
>   configs/ruby/MESI_CMP_directory.py ac4da9f8ea80 
>   configs/ruby/MI_example.py ac4da9f8ea80 
>   configs/ruby/MOESI_CMP_directory.py ac4da9f8ea80 
>   configs/ruby/MOESI_CMP_token.py ac4da9f8ea80 
>   configs/ruby/MOESI_hammer.py ac4da9f8ea80 
>   configs/ruby/Ruby.py ac4da9f8ea80 
>   src/cpu/testers/memtest/memtest.hh ac4da9f8ea80 
>   src/cpu/testers/memtest/memtest.cc ac4da9f8ea80 
>   src/mem/packet.hh ac4da9f8ea80 
>   src/mem/packet.cc ac4da9f8ea80 
>   src/mem/protocol/MOESI_CMP_directory-L1cache.sm ac4da9f8ea80 
>   src/mem/protocol/MOESI_CMP_directory-L2cache.sm ac4da9f8ea80 
>   src/mem/protocol/MOESI_CMP_directory-dir.sm ac4da9f8ea80 
>   src/mem/protocol/MOESI_hammer-cache.sm ac4da9f8ea80 
>   src/mem/protocol/MOESI_hammer-dir.sm ac4da9f8ea80 
>   src/mem/ruby/network/Network.cc ac4da9f8ea80 
>   src/mem/ruby/network/Network.py ac4da9f8ea80 
>   src/mem/ruby/profiler/Profiler.cc ac4da9f8ea80 
>   src/mem/ruby/profiler/Profiler.py ac4da9f8ea80 
>   src/mem/ruby/recorder/Tracer.cc ac4da9f8ea80 
>   src/mem/ruby/recorder/Tracer.py ac4da9f8ea80 
>   src/mem/ruby/slicc_interface/AbstractController.hh ac4da9f8ea80 
>   src/mem/ruby/slicc_interface/Ab

Re: [gem5-dev] Review Request: MIPS InorderCPU branch problems

2011-06-13 Thread Korey Sewell 

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/744/#review1328
---



src/cpu/inorder/resources/bpred_unit.cc


Can you post a separate patch for the MipsISA stuff you are describing? I 
dont see anything in the DIFF. Also, can you list benchmarks that you have 
observed to work?

My overall comment is that I think I caught #s1-3 in the new InOrderCPU 
code (the code to get Full System working). 

It's just stuck behind the patches on the reviewboard being merged and 
passing the regressions. It's predominantly done now, w/the DTB patch being 
closed to resolved. The last hiccup seems to be that the 50.vortex regressions 
seems to have been broken in the merge. Once that gets resolved, we'll get a 
wave of inorder updates.

At that point (in the near future), we'll compare the branch code and I'm 
hoping that you (Deyuan Guo) would be OK retesting your branch changes.


- Korey


On 2011-06-13 01:11:53, Deyuan Guo wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/744/
> ---
> 
> (Updated 2011-06-13 01:11:53)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> We are porting gem5 to support MIPS64, and find some problems. We try to fix 
> them, as shown below:
> 
> 1. fetch_seq_unit.cc
> Comment 2 lines. pc shouldn't be changed at this condition;
> 2. branch_predictor.cc
> Comment 1 line. By default, set target to NPC is OK.
> Adding a condition for MIPS branch likely instruction.
> 3. bpred_unit.cc
> If the branch is not taken, BTB should not be updated.
> 
> In addition, 2 places in src/arch/mips/isa/formats/branch.isa:
> elif x == 'Likely':
># not_taken_code = 'NNPC = NPC, NPC = PC;'
> The not_taken_code should be commented.
> 
> 
> Diffs
> -
> 
>   src/cpu/inorder/resources/bpred_unit.cc 9fb150de362e 
>   src/cpu/inorder/resources/branch_predictor.cc 9fb150de362e 
>   src/cpu/inorder/resources/fetch_seq_unit.cc 9fb150de362e 
> 
> Diff: http://reviews.m5sim.org/r/744/diff
> 
> 
> Testing
> ---
> 
> We have run many benchmarks of MIPS64 in gem5.
> And for MIPS32, with CPU_MODELS=InOrderCPU, hello world run correctly.
> 
> 
> Thanks,
> 
> Deyuan
> 
>

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

[gem5-dev] Cron /z/m5/regression/do-regression quick

2011-06-13 Thread Cron Daemon 
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-atomic passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/o3-timing passed.
* build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-atomic-mp 
passed.
* build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-timing-mp 
passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer
 passed.
* build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-timing 
passed.
* build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-atomic 
passed.
* build/ALPHA_SE/tests/opt/quick/01.hello-2T-smt/alpha/linux/o3-timing 
passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-atomic passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby 
passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby 
passed.
* build/ALPHA_SE/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby 
passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/inorder-timing passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token
 passed.
* build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby passed.
* build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest passed.
* 
build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual
 passed.
* 
build/ALPHA_FS/tests/opt/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic
 passed.
* 
build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-timing 
passed.
* 
build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual
 passed.
* build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/inorder-timing passed.
* build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/o3-timing passed.
* build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/simple-atomic passed.
* 
build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic 
passed.
* build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/simple-timing passed.
* build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/simple-timing-ruby 
passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer
 passed.
* build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-timing passed.
* build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/o3-timing passed.
* build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/simple-timing 
passed.
* build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-atomic passed.
* 
build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp
 passed.
* 
build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp
 passed.
* 
build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/simple-timing-mp
 passed.
* build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/simple-atomic 
passed.
* build/POWER_SE/tests/opt/quick/00.hello/power/linux/o3-timing passed.
* build/POWER_SE/tests/opt/quick/00.hello/power/linux/simple-atomic passed.
* build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-timing-ruby 
passed.
* build/X86_SE/tests/opt/quick/00.hello/x86/linux/simple-atomic passed.
* build/X86_SE/tests/opt/quick/00.hello/x86/linux/simple-timing passed.
* build/X86_SE/tests/opt/quick/00.hello/x86/linux/o3-timing passed.
***

Re: [gem5-dev] Review Request: ISA parser: Simplify operand type handling.

2011-06-13 Thread Gabe Black 
On 06/12/11 16:29, Steve Reinhardt wrote:
> On Sun, Jun 12, 2011 at 1:05 AM, Gabe Black  wrote:
>> I was thinking about this today, and if we expand the read/write
>> functions to handle signed types too, we're really just expanding the
>> arbitrary set of types they can handle, not removing the limitation that
>> you have to stay within those types which is what I think you don't like.
> I think originally we supported memory accesses for any operand type
> you could define, but that stopped being true once you made the
> definitions extensible.  My immediate concern is just to make sure
> that switching from the old explicit sign extensions to some implicit
> sign extensions that happened as a side effect of C type conversions
> is really doing the right thing, but having a cleaner way of doing
> memory accesses of arbitrary types is a good idea.
>
>> Instead of extending what we already have as far as explicit
>> instantiation, it would be nice to have a more automatic mechanism where
>> we'd just feed a list of types and a template (you can pass templates as
>> template arguments, sort of like function pointers but for templates)
>> and have some widget that cranks out the actual instantiation without so
>> much copy and paste coding.
> That sounds interesting, but seems like overkill... I just looked at
> the SimpleCPU code, and as far as I can tell, the memory access type
> (the arg type for read() and write()) is only used for two things: to
> determine the size of the access, and to control the data type in the
> InstRecord type for exec tracing (basically this is mostly setting the
> data_status enum, but also using the proper double vs int field in the
> data union).  The actual type clearly doesn't matter at all for the
> first, and only a subset of types are supported for the second.

There are actually three things, the third is to handle endianness. This
is important if we delegate endian swapping to the read and write
functions which we currently do, and helps when printing out what loads
and stores returned at the CPU level. You get the same information, it's
just easier to look at since it's a number and not a string of bytes.
Moving that into the ISA desc would be feasible, and you could make a
convincing argue that's where it should be in the first place. If ARM is
configured to do loads/stores in the "other" endianness (which we
support) then values could be swapped on the way in and then re-swapped
before being used. The idea of non-byte sized values in memory and the
endianness of them of is an ISA level concept. Other non-byte sized
values like PCI registers are another story, of course, but that's a
whole other issue.

> The original idea with the templates was that they might permit faster
> implementations for functional CPU models that communicated directly
> with memory.  However, if anything we've gone in the other direction
> by implementing these templates in terms of readBytes() and
> writeBytes().
>
> So my general feeling is that if we want to make significant changes
> to this interface, I'd be more inclined to streamline it and have the
> generated ISA code call readBytes() and writeBytes() directly with a
> size and some additional info to make exec tracing work (which should
> get rid of the templates entirely, I think) rather than expanding the
> template interface.  Then the burden of converting from an untyped
> sequence of bytes to whatever the ISA wants could be done entirely in
> the ISA definition, which seems like a good place for it.  Does that
> make sense?  Do you think it's feasible or worthwhile?

I think that makes sense, although the devil is in the details as
always. For memory in traces, it would be nice to have it endian
corrected, but it wouldn't necessarily have to be. We could just print
out each byte one at a time and have the understanding that it's a blob
of memory, low addresses on the left. Or at least I think we could do
that...

>> Also, while looking for information about Boost (in progress right now)
>> I found their page where they talk about their license (link below).
>> Looking through it, there are some ideas there which seem relevant to
>> gem5. Specifically, I like the idea of a single license for everything,
>> perhaps involving assigning copyright to a neutral body like a gem5
>> foundation or something, and then just referring to it in the actual
>> source files. That would get rid of lots of redundant text, and they
>> make a good point that all that text is the sort of thing lawyers might
>> get their underwear in a bunch over. There may be (but isn't
>> necessarily) subtle variation on a file by file basis, and it's probably
>> a lot more work to go through if somebody ever needed to do that.
> We discussed this a long long time ago (when we first started
> distributing the code, IIRC), and while it does have the advantages
> you describe, the cost of further wrangling with lawyers is basically
> not worth it IMO.  Maybe if we