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

2011-04-18 Thread Brad Beckmann


 On 2011-04-13 10:28:08, Brad Beckmann wrote:
  src/mem/protocol/MESI_CMP_directory-L1cache.sm, line 141
  http://reviews.m5sim.org/r/611/diff/6/?file=11548#file11548line141
 
  Why are you adding this function?  SLICC already generates a similar 
  function: getPermission().
  
  Overall, I hope/think we can add functional access support without 
  requiring any more changes to the protocol specific .sm files beyond the 
  changeset:   8086:bf0335d98250 that I checked in a couple months ago.
 
 Nilay Vaish wrote:
 How would you use the function that is generated by SLICC inside the
 sm file? I am concerned about the visibility of the function.
 
 Brad Beckmann wrote:
 You can certainly use a function that is generated by SLICC inside the sm 
 file.  The 'trigger' function is one such example.
 
 However, I'm not clear why you need to do that?  Specifically, why do you 
 need to explicitly set the permissions in the getCacheEntry function?  I 
 beleive the controller's doTransition function already does that when a 
 transition successfully completes.
 
 Nilay Vaish wrote:
 I checked the generated code. It seems that permissions are being
 set only for the cache entries and not for the directory entries.
 
 Brad Beckmann wrote:
 Really?  You should see a call to set_permissions inside the 
 Directory_Transitions.cc file.  For example, when I compile the MOESI_hammer 
 protocol, I see the set_permission call on line 51 in 
 Directory_Transitions.cc.
 

 
 Nilay Vaish wrote:
 The permissions would be set for the probe filter entry and not for the
 directory entry. The directory entry pointer is not passed around like
 the cache entry or TBE pointer.
 
 Brad Beckmann wrote:
 Doh!  Yep, that is a problem.  So what are the potential solutions:
 
 1. Inside the setState functions for the DirectoryControllers, we also 
 call set_permission.  This would require us to expose set_permissions to 
 SLICC similar to how trigger is exposed to SLICC.  Certainly possilbe, but 
 not ideal.  Especially because it will require directory controllers and 
 cache controllers to have different functionality in their setState functions.
 2. Instead of allowing an entry's state to be directly assigned in the 
 setState functions, make the state variable private, thus requiring a public 
 funciton to modify state.  When SLICC generates the implementation of that 
 public function, have that function modify both the state and the permissions.
 3. Remove the m_permission field in all entries and just rely on 
 get_permission to return the current permissions for cache and directory 
 entries.  I'm not sure how to do that unless we create an AbstractState class 
 so that the state can be accessed by the Ruby side.  Do we want to make such 
 a change?
 
 If we can make it work, I would prefer the second solution.  What do you 
 think?  Do you see other potential solutions?  If you agree that the second 
 solution is best, do you want to take a crack at it or would you like me to?  
 Since it is my patch that is broken, I feel responsible to fix it.  However, 
 I'm fine with you making the fix as well.
 
 Nilay Vaish wrote:
 I will think about it. IIRC, we had a discussion earlier as well
 whether setState() can be generated automatically by SLICC and 
 we decided against it.

I'm not proposing that we try to generate the entire Controller::setState 
function.  Instead, I'm just proposing making the current 
Controller_Entry::m_ControllerState function private and adding a new 
Controller_Entry::setState() function that sets the state and the permissions.

Yeah, definitely think it through before going ahead to implement any solution. 
 There may be some issues that I'm overlooking.


- Brad


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


On 2011-04-13 14:29:01, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/611/
 ---
 
 (Updated 2011-04-13 14:29:01)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Add support for functional accesses
 This patch is meant for implementing functional access support in Ruby.
 Currently, the patch does not functional accesses for the PioPort.
 
 
 Diffs
 -
 
   configs/example/ruby_mem_test.py 8b5f900233ee 
   configs/ruby/MESI_CMP_directory.py 8b5f900233ee 
   configs/ruby/Ruby.py 8b5f900233ee 
   src/cpu/testers/memtest/memtest.cc 8b5f900233ee 
   src/mem/packet.hh 8b5f900233ee 
   src/mem/packet.cc 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-L1cache.sm 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-L2cache.sm 

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

2011-04-16 Thread Nilay Vaish


 On 2011-04-13 10:28:08, Brad Beckmann wrote:
  src/mem/protocol/MESI_CMP_directory-L1cache.sm, line 141
  http://reviews.m5sim.org/r/611/diff/6/?file=11548#file11548line141
 
  Why are you adding this function?  SLICC already generates a similar 
  function: getPermission().
  
  Overall, I hope/think we can add functional access support without 
  requiring any more changes to the protocol specific .sm files beyond the 
  changeset:   8086:bf0335d98250 that I checked in a couple months ago.
 
 Nilay Vaish wrote:
 How would you use the function that is generated by SLICC inside the
 sm file? I am concerned about the visibility of the function.
 
 Brad Beckmann wrote:
 You can certainly use a function that is generated by SLICC inside the sm 
 file.  The 'trigger' function is one such example.
 
 However, I'm not clear why you need to do that?  Specifically, why do you 
 need to explicitly set the permissions in the getCacheEntry function?  I 
 beleive the controller's doTransition function already does that when a 
 transition successfully completes.
 
 Nilay Vaish wrote:
 I checked the generated code. It seems that permissions are being
 set only for the cache entries and not for the directory entries.
 
 Brad Beckmann wrote:
 Really?  You should see a call to set_permissions inside the 
 Directory_Transitions.cc file.  For example, when I compile the MOESI_hammer 
 protocol, I see the set_permission call on line 51 in 
 Directory_Transitions.cc.
 

 
 Nilay Vaish wrote:
 The permissions would be set for the probe filter entry and not for the
 directory entry. The directory entry pointer is not passed around like
 the cache entry or TBE pointer.
 
 Brad Beckmann wrote:
 Doh!  Yep, that is a problem.  So what are the potential solutions:
 
 1. Inside the setState functions for the DirectoryControllers, we also 
 call set_permission.  This would require us to expose set_permissions to 
 SLICC similar to how trigger is exposed to SLICC.  Certainly possilbe, but 
 not ideal.  Especially because it will require directory controllers and 
 cache controllers to have different functionality in their setState functions.
 2. Instead of allowing an entry's state to be directly assigned in the 
 setState functions, make the state variable private, thus requiring a public 
 funciton to modify state.  When SLICC generates the implementation of that 
 public function, have that function modify both the state and the permissions.
 3. Remove the m_permission field in all entries and just rely on 
 get_permission to return the current permissions for cache and directory 
 entries.  I'm not sure how to do that unless we create an AbstractState class 
 so that the state can be accessed by the Ruby side.  Do we want to make such 
 a change?
 
 If we can make it work, I would prefer the second solution.  What do you 
 think?  Do you see other potential solutions?  If you agree that the second 
 solution is best, do you want to take a crack at it or would you like me to?  
 Since it is my patch that is broken, I feel responsible to fix it.  However, 
 I'm fine with you making the fix as well.

I will think about it. IIRC, we had a discussion earlier as well
whether setState() can be generated automatically by SLICC and 
we decided against it.


- Nilay


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


On 2011-04-13 14:29:01, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/611/
 ---
 
 (Updated 2011-04-13 14:29:01)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Add support for functional accesses
 This patch is meant for implementing functional access support in Ruby.
 Currently, the patch does not functional accesses for the PioPort.
 
 
 Diffs
 -
 
   configs/example/ruby_mem_test.py 8b5f900233ee 
   configs/ruby/MESI_CMP_directory.py 8b5f900233ee 
   configs/ruby/Ruby.py 8b5f900233ee 
   src/cpu/testers/memtest/memtest.cc 8b5f900233ee 
   src/mem/packet.hh 8b5f900233ee 
   src/mem/packet.cc 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-L1cache.sm 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-L2cache.sm 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-dir.sm 8b5f900233ee 
   src/mem/protocol/RubySlicc_Types.sm 8b5f900233ee 
   src/mem/ruby/network/Network.cc 8b5f900233ee 
   src/mem/ruby/network/Network.py 8b5f900233ee 
   src/mem/ruby/profiler/Profiler.cc 8b5f900233ee 
   src/mem/ruby/profiler/Profiler.py 8b5f900233ee 
   src/mem/ruby/recorder/Tracer.cc 8b5f900233ee 
   src/mem/ruby/recorder/Tracer.py 8b5f900233ee 
   

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

2011-04-16 Thread Nilay Vaish


 On 2011-04-15 15:57:28, Steve Reinhardt wrote:
  configs/example/ruby_mem_test.py, line 98
  http://reviews.m5sim.org/r/611/diff/8/?file=11625#file11625line98
 
  You probably don't want to commit this value, do you?  If you want to 
  hardwire a number, I'd pick something more reasonable (somewhere between 10 
  and 25, just guessing).

I need to add a command line option for this. I can
put the default value as 10.


 On 2011-04-15 15:57:28, Steve Reinhardt wrote:
  src/mem/packet.hh, line 109
  http://reviews.m5sim.org/r/611/diff/8/?file=11629#file11629line109
 
  I don't see much value in having separate error return codes for reads 
  and writes.  I'd use a single code that ends in Error (like 
  FunctionalAccessError), and put it up a couple of lines with the other 
  Error codes.

I will make this change.


 On 2011-04-15 15:57:28, Steve Reinhardt wrote:
  src/mem/packet.hh, line 622
  http://reviews.m5sim.org/r/611/diff/8/?file=11629#file11629line622
 
  Way too much code duplication here :-).  I think this works, correct?
  
  void
  makeFunctionalResponse(bool success)
  {
  makeResponse();
  if (!success) {
  cmd = MemCmd::FunctionalAccessError;
  }
  }
 

Will make the required changes.


- Nilay


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


On 2011-04-13 14:29:01, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/611/
 ---
 
 (Updated 2011-04-13 14:29:01)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Add support for functional accesses
 This patch is meant for implementing functional access support in Ruby.
 Currently, the patch does not functional accesses for the PioPort.
 
 
 Diffs
 -
 
   configs/example/ruby_mem_test.py 8b5f900233ee 
   configs/ruby/MESI_CMP_directory.py 8b5f900233ee 
   configs/ruby/Ruby.py 8b5f900233ee 
   src/cpu/testers/memtest/memtest.cc 8b5f900233ee 
   src/mem/packet.hh 8b5f900233ee 
   src/mem/packet.cc 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-L1cache.sm 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-L2cache.sm 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-dir.sm 8b5f900233ee 
   src/mem/protocol/RubySlicc_Types.sm 8b5f900233ee 
   src/mem/ruby/network/Network.cc 8b5f900233ee 
   src/mem/ruby/network/Network.py 8b5f900233ee 
   src/mem/ruby/profiler/Profiler.cc 8b5f900233ee 
   src/mem/ruby/profiler/Profiler.py 8b5f900233ee 
   src/mem/ruby/recorder/Tracer.cc 8b5f900233ee 
   src/mem/ruby/recorder/Tracer.py 8b5f900233ee 
   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.py PRE-CREATION 
   src/mem/ruby/system/Cache.py 8b5f900233ee 
   src/mem/ruby/system/CacheMemory.hh 8b5f900233ee 
   src/mem/ruby/system/CacheMemory.cc 8b5f900233ee 
   src/mem/ruby/system/DirectoryMemory.hh 8b5f900233ee 
   src/mem/ruby/system/DirectoryMemory.cc 8b5f900233ee 
   src/mem/ruby/system/DirectoryMemory.py 8b5f900233ee 
   src/mem/ruby/system/RubyPort.hh 8b5f900233ee 
   src/mem/ruby/system/RubyPort.cc 8b5f900233ee 
   src/mem/ruby/system/RubySystem.py 8b5f900233ee 
   src/mem/ruby/system/SConscript 8b5f900233ee 
   src/mem/ruby/system/Sequencer.cc 8b5f900233ee 
   src/mem/ruby/system/Sequencer.py 8b5f900233ee 
   src/mem/ruby/system/System.hh 8b5f900233ee 
   src/mem/ruby/system/System.cc 8b5f900233ee 
   src/mem/slicc/ast/MemberExprAST.py 8b5f900233ee 
 
 Diff: http://reviews.m5sim.org/r/611/diff
 
 
 Testing
 ---
 
 I have tested functional accesses with the ratio between functional
 and timing accesses for different ratios -- 100:0, 99:1, 90:1, 50:50,
 10:90, 1:99. It is working in all the cases.
 
 
 Thanks,
 
 Nilay
 


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


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

2011-04-15 Thread Nilay Vaish


 On 2011-04-13 10:28:08, Brad Beckmann wrote:
  src/mem/protocol/MESI_CMP_directory-L1cache.sm, line 141
  http://reviews.m5sim.org/r/611/diff/6/?file=11548#file11548line141
 
  Why are you adding this function?  SLICC already generates a similar 
  function: getPermission().
  
  Overall, I hope/think we can add functional access support without 
  requiring any more changes to the protocol specific .sm files beyond the 
  changeset:   8086:bf0335d98250 that I checked in a couple months ago.
 
 Nilay Vaish wrote:
 How would you use the function that is generated by SLICC inside the
 sm file? I am concerned about the visibility of the function.
 
 Brad Beckmann wrote:
 You can certainly use a function that is generated by SLICC inside the sm 
 file.  The 'trigger' function is one such example.
 
 However, I'm not clear why you need to do that?  Specifically, why do you 
 need to explicitly set the permissions in the getCacheEntry function?  I 
 beleive the controller's doTransition function already does that when a 
 transition successfully completes.
 
 Nilay Vaish wrote:
 I checked the generated code. It seems that permissions are being
 set only for the cache entries and not for the directory entries.
 
 Brad Beckmann wrote:
 Really?  You should see a call to set_permissions inside the 
 Directory_Transitions.cc file.  For example, when I compile the MOESI_hammer 
 protocol, I see the set_permission call on line 51 in 
 Directory_Transitions.cc.
 


The permissions would be set for the probe filter entry and not for the
directory entry. The directory entry pointer is not passed around like
the cache entry or TBE pointer.


 On 2011-04-13 10:28:08, Brad Beckmann wrote:
  src/mem/ruby/system/CacheMemory.cc, line 270
  http://reviews.m5sim.org/r/611/diff/6/?file=11563#file11563line270
 
  Why are you commenting this line out?  If you think it is no longer 
  needed, just remove it.  If we remove it, can we guarentee that the 
  permission is initialized to some value?  For instance, do we know whether 
  the entry constructor will allows initialize the value?
 
 Nilay Vaish wrote:
 I expect the state to decide what the permission should be.
 
 Brad Beckmann wrote:
 However, if we don't set the permission to some later time, say at the 
 end of a transition, what happens if we access the permission before then?

Fine, I will uncomment the line.


- Nilay


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


On 2011-04-13 14:29:01, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/611/
 ---
 
 (Updated 2011-04-13 14:29:01)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Add support for functional accesses
 This patch is meant for implementing functional access support in Ruby.
 Currently, the patch does not functional accesses for the PioPort.
 
 
 Diffs
 -
 
   configs/example/ruby_mem_test.py 8b5f900233ee 
   configs/ruby/MESI_CMP_directory.py 8b5f900233ee 
   configs/ruby/Ruby.py 8b5f900233ee 
   src/cpu/testers/memtest/memtest.cc 8b5f900233ee 
   src/mem/packet.hh 8b5f900233ee 
   src/mem/packet.cc 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-L1cache.sm 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-L2cache.sm 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-dir.sm 8b5f900233ee 
   src/mem/protocol/RubySlicc_Types.sm 8b5f900233ee 
   src/mem/ruby/network/Network.cc 8b5f900233ee 
   src/mem/ruby/network/Network.py 8b5f900233ee 
   src/mem/ruby/profiler/Profiler.cc 8b5f900233ee 
   src/mem/ruby/profiler/Profiler.py 8b5f900233ee 
   src/mem/ruby/recorder/Tracer.cc 8b5f900233ee 
   src/mem/ruby/recorder/Tracer.py 8b5f900233ee 
   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.py PRE-CREATION 
   src/mem/ruby/system/Cache.py 8b5f900233ee 
   src/mem/ruby/system/CacheMemory.hh 8b5f900233ee 
   src/mem/ruby/system/CacheMemory.cc 8b5f900233ee 
   src/mem/ruby/system/DirectoryMemory.hh 8b5f900233ee 
   src/mem/ruby/system/DirectoryMemory.cc 8b5f900233ee 
   src/mem/ruby/system/DirectoryMemory.py 8b5f900233ee 
   src/mem/ruby/system/RubyPort.hh 8b5f900233ee 
   src/mem/ruby/system/RubyPort.cc 8b5f900233ee 
   src/mem/ruby/system/RubySystem.py 8b5f900233ee 
   src/mem/ruby/system/SConscript 8b5f900233ee 
   src/mem/ruby/system/Sequencer.cc 8b5f900233ee 
   src/mem/ruby/system/Sequencer.py 8b5f900233ee 
   src/mem/ruby/system/System.hh 8b5f900233ee 
   src/mem/ruby/system/System.cc 8b5f900233ee 
   src/mem/slicc/ast/MemberExprAST.py 8b5f900233ee 
 
 Diff: 

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

2011-04-15 Thread Brad Beckmann


 On 2011-04-13 10:28:08, Brad Beckmann wrote:
  src/mem/protocol/MESI_CMP_directory-L1cache.sm, line 141
  http://reviews.m5sim.org/r/611/diff/6/?file=11548#file11548line141
 
  Why are you adding this function?  SLICC already generates a similar 
  function: getPermission().
  
  Overall, I hope/think we can add functional access support without 
  requiring any more changes to the protocol specific .sm files beyond the 
  changeset:   8086:bf0335d98250 that I checked in a couple months ago.
 
 Nilay Vaish wrote:
 How would you use the function that is generated by SLICC inside the
 sm file? I am concerned about the visibility of the function.
 
 Brad Beckmann wrote:
 You can certainly use a function that is generated by SLICC inside the sm 
 file.  The 'trigger' function is one such example.
 
 However, I'm not clear why you need to do that?  Specifically, why do you 
 need to explicitly set the permissions in the getCacheEntry function?  I 
 beleive the controller's doTransition function already does that when a 
 transition successfully completes.
 
 Nilay Vaish wrote:
 I checked the generated code. It seems that permissions are being
 set only for the cache entries and not for the directory entries.
 
 Brad Beckmann wrote:
 Really?  You should see a call to set_permissions inside the 
 Directory_Transitions.cc file.  For example, when I compile the MOESI_hammer 
 protocol, I see the set_permission call on line 51 in 
 Directory_Transitions.cc.
 

 
 Nilay Vaish wrote:
 The permissions would be set for the probe filter entry and not for the
 directory entry. The directory entry pointer is not passed around like
 the cache entry or TBE pointer.

Doh!  Yep, that is a problem.  So what are the potential solutions:

1. Inside the setState functions for the DirectoryControllers, we also call 
set_permission.  This would require us to expose set_permissions to SLICC 
similar to how trigger is exposed to SLICC.  Certainly possilbe, but not ideal. 
 Especially because it will require directory controllers and cache controllers 
to have different functionality in their setState functions.
2. Instead of allowing an entry's state to be directly assigned in the setState 
functions, make the state variable private, thus requiring a public funciton to 
modify state.  When SLICC generates the implementation of that public function, 
have that function modify both the state and the permissions.
3. Remove the m_permission field in all entries and just rely on get_permission 
to return the current permissions for cache and directory entries.  I'm not 
sure how to do that unless we create an AbstractState class so that the state 
can be accessed by the Ruby side.  Do we want to make such a change?

If we can make it work, I would prefer the second solution.  What do you think? 
 Do you see other potential solutions?  If you agree that the second solution 
is best, do you want to take a crack at it or would you like me to?  Since it 
is my patch that is broken, I feel responsible to fix it.  However, I'm fine 
with you making the fix as well.


- Brad


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


On 2011-04-13 14:29:01, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/611/
 ---
 
 (Updated 2011-04-13 14:29:01)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Add support for functional accesses
 This patch is meant for implementing functional access support in Ruby.
 Currently, the patch does not functional accesses for the PioPort.
 
 
 Diffs
 -
 
   configs/example/ruby_mem_test.py 8b5f900233ee 
   configs/ruby/MESI_CMP_directory.py 8b5f900233ee 
   configs/ruby/Ruby.py 8b5f900233ee 
   src/cpu/testers/memtest/memtest.cc 8b5f900233ee 
   src/mem/packet.hh 8b5f900233ee 
   src/mem/packet.cc 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-L1cache.sm 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-L2cache.sm 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-dir.sm 8b5f900233ee 
   src/mem/protocol/RubySlicc_Types.sm 8b5f900233ee 
   src/mem/ruby/network/Network.cc 8b5f900233ee 
   src/mem/ruby/network/Network.py 8b5f900233ee 
   src/mem/ruby/profiler/Profiler.cc 8b5f900233ee 
   src/mem/ruby/profiler/Profiler.py 8b5f900233ee 
   src/mem/ruby/recorder/Tracer.cc 8b5f900233ee 
   src/mem/ruby/recorder/Tracer.py 8b5f900233ee 
   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.py PRE-CREATION 
   src/mem/ruby/system/Cache.py 8b5f900233ee 
   src/mem/ruby/system/CacheMemory.hh 8b5f900233ee 

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

2011-04-15 Thread Steve Reinhardt

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


Thanks for pointing these changes out.  I didn't look at the Ruby stuff since 
it looks like Brad has beaten you up plenty on that.

I think it's fine to check this in initially without any support for handling 
errors outside of the tester.  I checked and there aren't many unique calls to 
sendFunctional; most of the uses of functional accesses go through 
Port::readBlob() and Port::writeBlob().  Adding code to check the return cmd 
value at each call site and call warn() if it fails would be the next step in 
my opinion.




configs/example/ruby_mem_test.py
http://reviews.m5sim.org/r/611/#comment1537

You probably don't want to commit this value, do you?  If you want to 
hardwire a number, I'd pick something more reasonable (somewhere between 10 and 
25, just guessing).



src/mem/packet.hh
http://reviews.m5sim.org/r/611/#comment1535

I don't see much value in having separate error return codes for reads and 
writes.  I'd use a single code that ends in Error (like FunctionalAccessError), 
and put it up a couple of lines with the other Error codes.



src/mem/packet.hh
http://reviews.m5sim.org/r/611/#comment1536

Way too much code duplication here :-).  I think this works, correct?

void
makeFunctionalResponse(bool success)
{
makeResponse();
if (!success) {
cmd = MemCmd::FunctionalAccessError;
}
}



- Steve


On 2011-04-13 14:29:01, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/611/
 ---
 
 (Updated 2011-04-13 14:29:01)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Add support for functional accesses
 This patch is meant for implementing functional access support in Ruby.
 Currently, the patch does not functional accesses for the PioPort.
 
 
 Diffs
 -
 
   configs/example/ruby_mem_test.py 8b5f900233ee 
   configs/ruby/MESI_CMP_directory.py 8b5f900233ee 
   configs/ruby/Ruby.py 8b5f900233ee 
   src/cpu/testers/memtest/memtest.cc 8b5f900233ee 
   src/mem/packet.hh 8b5f900233ee 
   src/mem/packet.cc 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-L1cache.sm 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-L2cache.sm 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-dir.sm 8b5f900233ee 
   src/mem/protocol/RubySlicc_Types.sm 8b5f900233ee 
   src/mem/ruby/network/Network.cc 8b5f900233ee 
   src/mem/ruby/network/Network.py 8b5f900233ee 
   src/mem/ruby/profiler/Profiler.cc 8b5f900233ee 
   src/mem/ruby/profiler/Profiler.py 8b5f900233ee 
   src/mem/ruby/recorder/Tracer.cc 8b5f900233ee 
   src/mem/ruby/recorder/Tracer.py 8b5f900233ee 
   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.py PRE-CREATION 
   src/mem/ruby/system/Cache.py 8b5f900233ee 
   src/mem/ruby/system/CacheMemory.hh 8b5f900233ee 
   src/mem/ruby/system/CacheMemory.cc 8b5f900233ee 
   src/mem/ruby/system/DirectoryMemory.hh 8b5f900233ee 
   src/mem/ruby/system/DirectoryMemory.cc 8b5f900233ee 
   src/mem/ruby/system/DirectoryMemory.py 8b5f900233ee 
   src/mem/ruby/system/RubyPort.hh 8b5f900233ee 
   src/mem/ruby/system/RubyPort.cc 8b5f900233ee 
   src/mem/ruby/system/RubySystem.py 8b5f900233ee 
   src/mem/ruby/system/SConscript 8b5f900233ee 
   src/mem/ruby/system/Sequencer.cc 8b5f900233ee 
   src/mem/ruby/system/Sequencer.py 8b5f900233ee 
   src/mem/ruby/system/System.hh 8b5f900233ee 
   src/mem/ruby/system/System.cc 8b5f900233ee 
   src/mem/slicc/ast/MemberExprAST.py 8b5f900233ee 
 
 Diff: http://reviews.m5sim.org/r/611/diff
 
 
 Testing
 ---
 
 I have tested functional accesses with the ratio between functional
 and timing accesses for different ratios -- 100:0, 99:1, 90:1, 50:50,
 10:90, 1:99. It is working in all the cases.
 
 
 Thanks,
 
 Nilay
 


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


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

2011-04-14 Thread Nilay Vaish
Brad, can you elaborate on implementing functional accesses for the 
PioPort?


--
Nilay

On Wed, 13 Apr 2011, Beckmann, Brad wrote:


I just reviewed it.  Please let me know if you have any questions.

Brad



-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org]
On Behalf Of Nilay Vaish
Sent: Tuesday, April 12, 2011 4:39 PM
To: Default
Subject: Re: [m5-dev] Review Request: Ruby: Add support for functional
accesses

Brad, can you take a look at the patch? I think we are now in position to
implement functional accesses for the PioPort.

--
Nilay


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


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

2011-04-14 Thread Nilay Vaish


 On 2011-04-13 13:43:26, Gabe Black wrote:
  Please fix these style issues, including the ones in this file I haven't 
  explicitly pointed out. You should be using M5 style generally, but 
  especially when your in M5 code. Also, please be sure to point this out to 
  one of the classic memory system experts (Nate, Steve, or Ali) and get them 
  to sign off. They might not see that this change touches outside of Ruby.

Gabe, I made the changes that you had pointed.


- Nilay


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


On 2011-04-13 14:29:01, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/611/
 ---
 
 (Updated 2011-04-13 14:29:01)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Add support for functional accesses
 This patch is meant for implementing functional access support in Ruby.
 Currently, the patch does not functional accesses for the PioPort.
 
 
 Diffs
 -
 
   configs/example/ruby_mem_test.py 8b5f900233ee 
   configs/ruby/MESI_CMP_directory.py 8b5f900233ee 
   configs/ruby/Ruby.py 8b5f900233ee 
   src/cpu/testers/memtest/memtest.cc 8b5f900233ee 
   src/mem/packet.hh 8b5f900233ee 
   src/mem/packet.cc 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-L1cache.sm 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-L2cache.sm 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-dir.sm 8b5f900233ee 
   src/mem/protocol/RubySlicc_Types.sm 8b5f900233ee 
   src/mem/ruby/network/Network.cc 8b5f900233ee 
   src/mem/ruby/network/Network.py 8b5f900233ee 
   src/mem/ruby/profiler/Profiler.cc 8b5f900233ee 
   src/mem/ruby/profiler/Profiler.py 8b5f900233ee 
   src/mem/ruby/recorder/Tracer.cc 8b5f900233ee 
   src/mem/ruby/recorder/Tracer.py 8b5f900233ee 
   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.py PRE-CREATION 
   src/mem/ruby/system/Cache.py 8b5f900233ee 
   src/mem/ruby/system/CacheMemory.hh 8b5f900233ee 
   src/mem/ruby/system/CacheMemory.cc 8b5f900233ee 
   src/mem/ruby/system/DirectoryMemory.hh 8b5f900233ee 
   src/mem/ruby/system/DirectoryMemory.cc 8b5f900233ee 
   src/mem/ruby/system/DirectoryMemory.py 8b5f900233ee 
   src/mem/ruby/system/RubyPort.hh 8b5f900233ee 
   src/mem/ruby/system/RubyPort.cc 8b5f900233ee 
   src/mem/ruby/system/RubySystem.py 8b5f900233ee 
   src/mem/ruby/system/SConscript 8b5f900233ee 
   src/mem/ruby/system/Sequencer.cc 8b5f900233ee 
   src/mem/ruby/system/Sequencer.py 8b5f900233ee 
   src/mem/ruby/system/System.hh 8b5f900233ee 
   src/mem/ruby/system/System.cc 8b5f900233ee 
   src/mem/slicc/ast/MemberExprAST.py 8b5f900233ee 
 
 Diff: http://reviews.m5sim.org/r/611/diff
 
 
 Testing
 ---
 
 I have tested functional accesses with the ratio between functional
 and timing accesses for different ratios -- 100:0, 99:1, 90:1, 50:50,
 10:90, 1:99. It is working in all the cases.
 
 
 Thanks,
 
 Nilay
 


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


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

2011-04-14 Thread Nilay Vaish


 On 2011-04-13 10:28:08, Brad Beckmann wrote:
  src/mem/protocol/MESI_CMP_directory-L1cache.sm, line 141
  http://reviews.m5sim.org/r/611/diff/6/?file=11548#file11548line141
 
  Why are you adding this function?  SLICC already generates a similar 
  function: getPermission().
  
  Overall, I hope/think we can add functional access support without 
  requiring any more changes to the protocol specific .sm files beyond the 
  changeset:   8086:bf0335d98250 that I checked in a couple months ago.
 
 Nilay Vaish wrote:
 How would you use the function that is generated by SLICC inside the
 sm file? I am concerned about the visibility of the function.
 
 Brad Beckmann wrote:
 You can certainly use a function that is generated by SLICC inside the sm 
 file.  The 'trigger' function is one such example.
 
 However, I'm not clear why you need to do that?  Specifically, why do you 
 need to explicitly set the permissions in the getCacheEntry function?  I 
 beleive the controller's doTransition function already does that when a 
 transition successfully completes.

I checked the generated code. It seems that permissions are being
set only for the cache entries and not for the directory entries.


- Nilay


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


On 2011-04-13 14:29:01, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/611/
 ---
 
 (Updated 2011-04-13 14:29:01)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Add support for functional accesses
 This patch is meant for implementing functional access support in Ruby.
 Currently, the patch does not functional accesses for the PioPort.
 
 
 Diffs
 -
 
   configs/example/ruby_mem_test.py 8b5f900233ee 
   configs/ruby/MESI_CMP_directory.py 8b5f900233ee 
   configs/ruby/Ruby.py 8b5f900233ee 
   src/cpu/testers/memtest/memtest.cc 8b5f900233ee 
   src/mem/packet.hh 8b5f900233ee 
   src/mem/packet.cc 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-L1cache.sm 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-L2cache.sm 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-dir.sm 8b5f900233ee 
   src/mem/protocol/RubySlicc_Types.sm 8b5f900233ee 
   src/mem/ruby/network/Network.cc 8b5f900233ee 
   src/mem/ruby/network/Network.py 8b5f900233ee 
   src/mem/ruby/profiler/Profiler.cc 8b5f900233ee 
   src/mem/ruby/profiler/Profiler.py 8b5f900233ee 
   src/mem/ruby/recorder/Tracer.cc 8b5f900233ee 
   src/mem/ruby/recorder/Tracer.py 8b5f900233ee 
   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.py PRE-CREATION 
   src/mem/ruby/system/Cache.py 8b5f900233ee 
   src/mem/ruby/system/CacheMemory.hh 8b5f900233ee 
   src/mem/ruby/system/CacheMemory.cc 8b5f900233ee 
   src/mem/ruby/system/DirectoryMemory.hh 8b5f900233ee 
   src/mem/ruby/system/DirectoryMemory.cc 8b5f900233ee 
   src/mem/ruby/system/DirectoryMemory.py 8b5f900233ee 
   src/mem/ruby/system/RubyPort.hh 8b5f900233ee 
   src/mem/ruby/system/RubyPort.cc 8b5f900233ee 
   src/mem/ruby/system/RubySystem.py 8b5f900233ee 
   src/mem/ruby/system/SConscript 8b5f900233ee 
   src/mem/ruby/system/Sequencer.cc 8b5f900233ee 
   src/mem/ruby/system/Sequencer.py 8b5f900233ee 
   src/mem/ruby/system/System.hh 8b5f900233ee 
   src/mem/ruby/system/System.cc 8b5f900233ee 
   src/mem/slicc/ast/MemberExprAST.py 8b5f900233ee 
 
 Diff: http://reviews.m5sim.org/r/611/diff
 
 
 Testing
 ---
 
 I have tested functional accesses with the ratio between functional
 and timing accesses for different ratios -- 100:0, 99:1, 90:1, 50:50,
 10:90, 1:99. It is working in all the cases.
 
 
 Thanks,
 
 Nilay
 


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


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

2011-04-14 Thread Brad Beckmann


 On 2011-04-13 10:28:08, Brad Beckmann wrote:
  src/mem/protocol/MESI_CMP_directory-L1cache.sm, line 141
  http://reviews.m5sim.org/r/611/diff/6/?file=11548#file11548line141
 
  Why are you adding this function?  SLICC already generates a similar 
  function: getPermission().
  
  Overall, I hope/think we can add functional access support without 
  requiring any more changes to the protocol specific .sm files beyond the 
  changeset:   8086:bf0335d98250 that I checked in a couple months ago.
 
 Nilay Vaish wrote:
 How would you use the function that is generated by SLICC inside the
 sm file? I am concerned about the visibility of the function.
 
 Brad Beckmann wrote:
 You can certainly use a function that is generated by SLICC inside the sm 
 file.  The 'trigger' function is one such example.
 
 However, I'm not clear why you need to do that?  Specifically, why do you 
 need to explicitly set the permissions in the getCacheEntry function?  I 
 beleive the controller's doTransition function already does that when a 
 transition successfully completes.
 
 Nilay Vaish wrote:
 I checked the generated code. It seems that permissions are being
 set only for the cache entries and not for the directory entries.

Really?  You should see a call to set_permissions inside the 
Directory_Transitions.cc file.  For example, when I compile the MOESI_hammer 
protocol, I see the set_permission call on line 51 in Directory_Transitions.cc.


- Brad


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


On 2011-04-13 14:29:01, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/611/
 ---
 
 (Updated 2011-04-13 14:29:01)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Add support for functional accesses
 This patch is meant for implementing functional access support in Ruby.
 Currently, the patch does not functional accesses for the PioPort.
 
 
 Diffs
 -
 
   configs/example/ruby_mem_test.py 8b5f900233ee 
   configs/ruby/MESI_CMP_directory.py 8b5f900233ee 
   configs/ruby/Ruby.py 8b5f900233ee 
   src/cpu/testers/memtest/memtest.cc 8b5f900233ee 
   src/mem/packet.hh 8b5f900233ee 
   src/mem/packet.cc 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-L1cache.sm 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-L2cache.sm 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-dir.sm 8b5f900233ee 
   src/mem/protocol/RubySlicc_Types.sm 8b5f900233ee 
   src/mem/ruby/network/Network.cc 8b5f900233ee 
   src/mem/ruby/network/Network.py 8b5f900233ee 
   src/mem/ruby/profiler/Profiler.cc 8b5f900233ee 
   src/mem/ruby/profiler/Profiler.py 8b5f900233ee 
   src/mem/ruby/recorder/Tracer.cc 8b5f900233ee 
   src/mem/ruby/recorder/Tracer.py 8b5f900233ee 
   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.py PRE-CREATION 
   src/mem/ruby/system/Cache.py 8b5f900233ee 
   src/mem/ruby/system/CacheMemory.hh 8b5f900233ee 
   src/mem/ruby/system/CacheMemory.cc 8b5f900233ee 
   src/mem/ruby/system/DirectoryMemory.hh 8b5f900233ee 
   src/mem/ruby/system/DirectoryMemory.cc 8b5f900233ee 
   src/mem/ruby/system/DirectoryMemory.py 8b5f900233ee 
   src/mem/ruby/system/RubyPort.hh 8b5f900233ee 
   src/mem/ruby/system/RubyPort.cc 8b5f900233ee 
   src/mem/ruby/system/RubySystem.py 8b5f900233ee 
   src/mem/ruby/system/SConscript 8b5f900233ee 
   src/mem/ruby/system/Sequencer.cc 8b5f900233ee 
   src/mem/ruby/system/Sequencer.py 8b5f900233ee 
   src/mem/ruby/system/System.hh 8b5f900233ee 
   src/mem/ruby/system/System.cc 8b5f900233ee 
   src/mem/slicc/ast/MemberExprAST.py 8b5f900233ee 
 
 Diff: http://reviews.m5sim.org/r/611/diff
 
 
 Testing
 ---
 
 I have tested functional accesses with the ratio between functional
 and timing accesses for different ratios -- 100:0, 99:1, 90:1, 50:50,
 10:90, 1:99. It is working in all the cases.
 
 
 Thanks,
 
 Nilay
 


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


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

2011-04-14 Thread Beckmann, Brad
Hi Nilay,

Let me start off by saying that I'm not sure if I fully understand the 
complexities of dealing with functional accesses from the PioPort and I could 
be overlooking a key concern.  

I think implementing functional accesses for the PioPort should be very similar 
to cpu functional accesses.  We still need to include the pio_port within the 
RubyPort and we need to send all requests not directed at physical memory to 
it.  You need to modify the connectX86RubySystem function in FSConfig.py so 
that all pio functional requests are seen by the ruby port versus physmem.  The 
more difficult piece maybe moving the address range registration functionality 
from physmem to RubyPort, since physmem will no longer exist.  If you run into 
difficulties there, I encourage you to send email to the dev list, since others 
will be better resources than me.

Is that the kind of information you were looking for?

Brad


 -Original Message-
 From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org]
 On Behalf Of Nilay Vaish
 Sent: Thursday, April 14, 2011 9:25 AM
 To: M5 Developer List
 Subject: Re: [m5-dev] Review Request: Ruby: Add support for functional
 accesses
 
 Brad, can you elaborate on implementing functional accesses for the
 PioPort?
 
 --
 Nilay
 
 On Wed, 13 Apr 2011, Beckmann, Brad wrote:
 
  I just reviewed it.  Please let me know if you have any questions.
 
  Brad
 
 
  -Original Message-
  From: m5-dev-boun...@m5sim.org [mailto:m5-dev-
 boun...@m5sim.org] On
  Behalf Of Nilay Vaish
  Sent: Tuesday, April 12, 2011 4:39 PM
  To: Default
  Subject: Re: [m5-dev] Review Request: Ruby: Add support for
  functional accesses
 
  Brad, can you take a look at the patch? I think we are now in
  position to implement functional accesses for the PioPort.
 
  --
  Nilay
 
 ___
 m5-dev mailing list
 m5-dev@m5sim.org
 http://m5sim.org/mailman/listinfo/m5-dev


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


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

2011-04-13 Thread Beckmann, Brad
I just reviewed it.  Please let me know if you have any questions.

Brad


 -Original Message-
 From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org]
 On Behalf Of Nilay Vaish
 Sent: Tuesday, April 12, 2011 4:39 PM
 To: Default
 Subject: Re: [m5-dev] Review Request: Ruby: Add support for functional
 accesses
 
 Brad, can you take a look at the patch? I think we are now in position to
 implement functional accesses for the PioPort.
 
 --
 Nilay
 
 
 
 On Tue, 12 Apr 2011, Nilay Vaish wrote:
 
 
  ---
  This is an automatically generated e-mail. To reply, visit:
  http://reviews.m5sim.org/r/611/
  ---
 
  (Updated 2011-04-12 16:35:34.866577)
 
 
  Review request for Default.
 
 
  Summary (updated)
  ---
 
  Ruby: Add support for functional accesses This patch is meant for
  aiding discussions on implementation of functional access support in
  Ruby.
 
 
 ___
 m5-dev mailing list
 m5-dev@m5sim.org
 http://m5sim.org/mailman/listinfo/m5-dev


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


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

2011-04-13 Thread Nilay Vaish


 On 2011-04-13 10:28:08, Brad Beckmann wrote:
  configs/example/ruby_mem_test.py, line 97
  http://reviews.m5sim.org/r/611/diff/6/?file=11542#file11542line97
 
  It seems that the following three parameters should not be hardcoded, 
  but instead should be set using command line options.  Hardcoding the 
  atomic parameter to false still makes sense, since Ruby can handle atomic 
  requests.  Also we should update the comment above.

I did not add that line. I am not even aware what the purpose of that
line is. I'll dig into what the implication of setting issue_dmas to 
false is.

I will update the comment.


 On 2011-04-13 10:28:08, Brad Beckmann wrote:
  src/cpu/testers/memtest/memtest.cc, line 401
  http://reviews.m5sim.org/r/611/diff/6/?file=11545#file11545line401
 
  Remove commented out line

Done!


 On 2011-04-13 10:28:08, Brad Beckmann wrote:
  src/mem/protocol/MESI_CMP_directory-L1cache.sm, line 141
  http://reviews.m5sim.org/r/611/diff/6/?file=11548#file11548line141
 
  Why are you adding this function?  SLICC already generates a similar 
  function: getPermission().
  
  Overall, I hope/think we can add functional access support without 
  requiring any more changes to the protocol specific .sm files beyond the 
  changeset:   8086:bf0335d98250 that I checked in a couple months ago.

How would you use the function that is generated by SLICC inside the
sm file? I am concerned about the visibility of the function.


 On 2011-04-13 10:28:08, Brad Beckmann wrote:
  src/mem/ruby/system/CacheMemory.cc, line 270
  http://reviews.m5sim.org/r/611/diff/6/?file=11563#file11563line270
 
  Why are you commenting this line out?  If you think it is no longer 
  needed, just remove it.  If we remove it, can we guarentee that the 
  permission is initialized to some value?  For instance, do we know whether 
  the entry constructor will allows initialize the value?

I expect the state to decide what the permission should be.


 On 2011-04-13 10:28:08, Brad Beckmann wrote:
  src/mem/ruby/system/System.hh, line 132
  http://reviews.m5sim.org/r/611/diff/6/?file=11573#file11573line132
 
  Why are these functions static?  I'm concerned that declaring these 
  static will unecessarily restrict using Ruby in multiple system simulation. 
   Also from my understanding of the code, there is no need to make them 
  static.  Perhaps I'm missing something.

My bad! I think I did that under the impression that static variables can
only be referenced in static functions.


 On 2011-04-13 10:28:08, Brad Beckmann wrote:
  src/mem/ruby/system/RubyPort.cc, line 302
  http://reviews.m5sim.org/r/611/diff/6/?file=11568#file11568line302
 
  Overall, I really like the comments you added in this file.  They 
  really help clarify what is going on here.  Just one
  minor correction: change Any copy to Any valid copy

Done!


 On 2011-04-13 10:28:08, Brad Beckmann wrote:
  src/mem/ruby/system/DirectoryMemory.cc, line 246
  http://reviews.m5sim.org/r/611/diff/6/?file=11565#file11565line246
 
  Please align this statement.

I am removing this line.


- Nilay


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


On 2011-04-12 16:35:34, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/611/
 ---
 
 (Updated 2011-04-12 16:35:34)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Add support for functional accesses
 This patch is meant for aiding discussions on implementation of functional
 access support in Ruby.
 
 
 Diffs
 -
 
   configs/example/ruby_mem_test.py cb1e137ac35e 
   configs/ruby/MESI_CMP_directory.py cb1e137ac35e 
   configs/ruby/Ruby.py cb1e137ac35e 
   src/cpu/testers/memtest/memtest.cc cb1e137ac35e 
   src/mem/packet.hh cb1e137ac35e 
   src/mem/packet.cc cb1e137ac35e 
   src/mem/protocol/MESI_CMP_directory-L1cache.sm cb1e137ac35e 
   src/mem/protocol/MESI_CMP_directory-L2cache.sm cb1e137ac35e 
   src/mem/protocol/MESI_CMP_directory-dir.sm cb1e137ac35e 
   src/mem/protocol/RubySlicc_Types.sm cb1e137ac35e 
   src/mem/ruby/network/Network.cc cb1e137ac35e 
   src/mem/ruby/network/Network.py cb1e137ac35e 
   src/mem/ruby/profiler/Profiler.cc cb1e137ac35e 
   src/mem/ruby/profiler/Profiler.py cb1e137ac35e 
   src/mem/ruby/recorder/Tracer.cc cb1e137ac35e 
   src/mem/ruby/recorder/Tracer.py cb1e137ac35e 
   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.py PRE-CREATION 
   src/mem/ruby/system/Cache.py cb1e137ac35e 
   src/mem/ruby/system/CacheMemory.hh cb1e137ac35e 
   src/mem/ruby/system/CacheMemory.cc cb1e137ac35e 
   

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

2011-04-13 Thread Nilay Vaish

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

(Updated 2011-04-13 11:17:53.272247)


Review request for Default.


Summary (updated)
---

Ruby: Add support for functional accesses
This patch is meant for implementing functional access support in Ruby.
Currently, the patch does not functional accesses for the PioPort.


Diffs (updated)
-

  configs/example/ruby_mem_test.py 8b5f900233ee 
  configs/ruby/MESI_CMP_directory.py 8b5f900233ee 
  configs/ruby/Ruby.py 8b5f900233ee 
  src/cpu/testers/memtest/memtest.cc 8b5f900233ee 
  src/mem/packet.hh 8b5f900233ee 
  src/mem/packet.cc 8b5f900233ee 
  src/mem/protocol/MESI_CMP_directory-L1cache.sm 8b5f900233ee 
  src/mem/protocol/MESI_CMP_directory-L2cache.sm 8b5f900233ee 
  src/mem/protocol/MESI_CMP_directory-dir.sm 8b5f900233ee 
  src/mem/protocol/RubySlicc_Types.sm 8b5f900233ee 
  src/mem/ruby/network/Network.cc 8b5f900233ee 
  src/mem/ruby/network/Network.py 8b5f900233ee 
  src/mem/ruby/profiler/Profiler.cc 8b5f900233ee 
  src/mem/ruby/profiler/Profiler.py 8b5f900233ee 
  src/mem/ruby/recorder/Tracer.cc 8b5f900233ee 
  src/mem/ruby/recorder/Tracer.py 8b5f900233ee 
  src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
  src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
  src/mem/ruby/system/AbstractMemory.py PRE-CREATION 
  src/mem/ruby/system/Cache.py 8b5f900233ee 
  src/mem/ruby/system/CacheMemory.hh 8b5f900233ee 
  src/mem/ruby/system/CacheMemory.cc 8b5f900233ee 
  src/mem/ruby/system/DirectoryMemory.hh 8b5f900233ee 
  src/mem/ruby/system/DirectoryMemory.cc 8b5f900233ee 
  src/mem/ruby/system/DirectoryMemory.py 8b5f900233ee 
  src/mem/ruby/system/RubyPort.hh 8b5f900233ee 
  src/mem/ruby/system/RubyPort.cc 8b5f900233ee 
  src/mem/ruby/system/RubySystem.py 8b5f900233ee 
  src/mem/ruby/system/SConscript 8b5f900233ee 
  src/mem/ruby/system/Sequencer.cc 8b5f900233ee 
  src/mem/ruby/system/Sequencer.py 8b5f900233ee 
  src/mem/ruby/system/System.hh 8b5f900233ee 
  src/mem/ruby/system/System.cc 8b5f900233ee 
  src/mem/slicc/ast/MemberExprAST.py 8b5f900233ee 

Diff: http://reviews.m5sim.org/r/611/diff


Testing
---

I have tested functional accesses with the ratio between functional
and timing accesses for different ratios -- 100:0, 99:1, 90:1, 50:50,
10:90, 1:99. It is working in all the cases.


Thanks,

Nilay

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


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

2011-04-13 Thread Gabe Black

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


Please fix these style issues, including the ones in this file I haven't 
explicitly pointed out. You should be using M5 style generally, but especially 
when your in M5 code. Also, please be sure to point this out to one of the 
classic memory system experts (Nate, Steve, or Ali) and get them to sign off. 
They might not see that this change touches outside of Ruby.


src/mem/packet.hh
http://reviews.m5sim.org/r/611/#comment1510

Don't add commented out code.



src/mem/packet.hh
http://reviews.m5sim.org/r/611/#comment1513

space after if, brace at the end of the line



src/mem/packet.hh
http://reviews.m5sim.org/r/611/#comment1511

space after if, brace on the end of the line not on a new one.



src/mem/packet.hh
http://reviews.m5sim.org/r/611/#comment1512

This should be } else {


- Gabe


On 2011-04-13 11:17:53, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/611/
 ---
 
 (Updated 2011-04-13 11:17:53)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Add support for functional accesses
 This patch is meant for implementing functional access support in Ruby.
 Currently, the patch does not functional accesses for the PioPort.
 
 
 Diffs
 -
 
   configs/example/ruby_mem_test.py 8b5f900233ee 
   configs/ruby/MESI_CMP_directory.py 8b5f900233ee 
   configs/ruby/Ruby.py 8b5f900233ee 
   src/cpu/testers/memtest/memtest.cc 8b5f900233ee 
   src/mem/packet.hh 8b5f900233ee 
   src/mem/packet.cc 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-L1cache.sm 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-L2cache.sm 8b5f900233ee 
   src/mem/protocol/MESI_CMP_directory-dir.sm 8b5f900233ee 
   src/mem/protocol/RubySlicc_Types.sm 8b5f900233ee 
   src/mem/ruby/network/Network.cc 8b5f900233ee 
   src/mem/ruby/network/Network.py 8b5f900233ee 
   src/mem/ruby/profiler/Profiler.cc 8b5f900233ee 
   src/mem/ruby/profiler/Profiler.py 8b5f900233ee 
   src/mem/ruby/recorder/Tracer.cc 8b5f900233ee 
   src/mem/ruby/recorder/Tracer.py 8b5f900233ee 
   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.py PRE-CREATION 
   src/mem/ruby/system/Cache.py 8b5f900233ee 
   src/mem/ruby/system/CacheMemory.hh 8b5f900233ee 
   src/mem/ruby/system/CacheMemory.cc 8b5f900233ee 
   src/mem/ruby/system/DirectoryMemory.hh 8b5f900233ee 
   src/mem/ruby/system/DirectoryMemory.cc 8b5f900233ee 
   src/mem/ruby/system/DirectoryMemory.py 8b5f900233ee 
   src/mem/ruby/system/RubyPort.hh 8b5f900233ee 
   src/mem/ruby/system/RubyPort.cc 8b5f900233ee 
   src/mem/ruby/system/RubySystem.py 8b5f900233ee 
   src/mem/ruby/system/SConscript 8b5f900233ee 
   src/mem/ruby/system/Sequencer.cc 8b5f900233ee 
   src/mem/ruby/system/Sequencer.py 8b5f900233ee 
   src/mem/ruby/system/System.hh 8b5f900233ee 
   src/mem/ruby/system/System.cc 8b5f900233ee 
   src/mem/slicc/ast/MemberExprAST.py 8b5f900233ee 
 
 Diff: http://reviews.m5sim.org/r/611/diff
 
 
 Testing
 ---
 
 I have tested functional accesses with the ratio between functional
 and timing accesses for different ratios -- 100:0, 99:1, 90:1, 50:50,
 10:90, 1:99. It is working in all the cases.
 
 
 Thanks,
 
 Nilay
 


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


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

2011-04-04 Thread Nilay Vaish


 On 2011-03-31 22:08:21, Brad Beckmann wrote:
  This looks great, I just have a few minor suggestions below.
  
  It seems like the next step is to figure out how to deal with functional 
  accesses not succeeding in the CPUs and devices.
 
 Nilay Vaish wrote:
 Brad, I would make the changes you have listed below. I also need to add
 code for directory memory accesses. Can you elaborate on the next step 
 you 
 mentioned? We are yet not dealing with the devices, I believe.
 
 Nilay Vaish wrote:
 One more question for you. Do we need functional access support for the 
 PioPort
 as well? We do not have it currently.
 
 Brad Beckmann wrote:
 Yes, eventually if we want Ruby to supply data in FS mode, RubyPort will 
 need to support functional access from the PioPort to Ruby memory.  It is up 
 to you whether you want to implement that support now, or first make sure 
 functional accesses are working SE mode.  If you want to make sure SE mode 
 functional accesses work, first modify the ruby mem tester to issue 
 functional access (right now that is hardcoded off).  Also you should try a 
 few binaries under SE mode, like hello world.

Brad, I'll test the current implementation first and then work on functional
accesses from the PioPort.


- Nilay


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


On 2011-04-02 11:42:47, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/611/
 ---
 
 (Updated 2011-04-02 11:42:47)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Add support for functional accesses
 This patch is meant for aiding discussions on implementation of functional
 access support in Ruby.
 
 
 Diffs
 -
 
   configs/ruby/MESI_CMP_directory.py aeec9e157d06 
   configs/ruby/Ruby.py aeec9e157d06 
   src/mem/ruby/network/Network.cc aeec9e157d06 
   src/mem/ruby/network/Network.py aeec9e157d06 
   src/mem/ruby/profiler/Profiler.cc aeec9e157d06 
   src/mem/ruby/profiler/Profiler.py aeec9e157d06 
   src/mem/ruby/recorder/Tracer.cc aeec9e157d06 
   src/mem/ruby/recorder/Tracer.py aeec9e157d06 
   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
   src/mem/ruby/system/Cache.py aeec9e157d06 
   src/mem/ruby/system/CacheMemory.hh aeec9e157d06 
   src/mem/ruby/system/CacheMemory.cc aeec9e157d06 
   src/mem/ruby/system/DirectoryMemory.hh aeec9e157d06 
   src/mem/ruby/system/DirectoryMemory.cc aeec9e157d06 
   src/mem/ruby/system/DirectoryMemory.py aeec9e157d06 
   src/mem/ruby/system/RubyPort.hh aeec9e157d06 
   src/mem/ruby/system/RubyPort.cc aeec9e157d06 
   src/mem/ruby/system/RubySystem.py aeec9e157d06 
   src/mem/ruby/system/SConscript aeec9e157d06 
   src/mem/ruby/system/Sequencer.cc aeec9e157d06 
   src/mem/ruby/system/Sequencer.py aeec9e157d06 
   src/mem/ruby/system/System.hh aeec9e157d06 
   src/mem/ruby/system/System.cc aeec9e157d06 
 
 Diff: http://reviews.m5sim.org/r/611/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Nilay
 


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


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

2011-04-04 Thread Nilay Vaish


 On 2011-04-03 13:45:28, Brad Beckmann wrote:
  src/mem/ruby/system/DirectoryMemory.py, line 2
  http://reviews.m5sim.org/r/611/diff/4/?file=11465#file11465line2
 
  Why are you deleting this file and where are you moving the current 
  functionality?

My bad! I had forgotten to add AbstractMemory.py file.


- Nilay


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


On 2011-04-02 11:42:47, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/611/
 ---
 
 (Updated 2011-04-02 11:42:47)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Add support for functional accesses
 This patch is meant for aiding discussions on implementation of functional
 access support in Ruby.
 
 
 Diffs
 -
 
   configs/ruby/MESI_CMP_directory.py aeec9e157d06 
   configs/ruby/Ruby.py aeec9e157d06 
   src/mem/ruby/network/Network.cc aeec9e157d06 
   src/mem/ruby/network/Network.py aeec9e157d06 
   src/mem/ruby/profiler/Profiler.cc aeec9e157d06 
   src/mem/ruby/profiler/Profiler.py aeec9e157d06 
   src/mem/ruby/recorder/Tracer.cc aeec9e157d06 
   src/mem/ruby/recorder/Tracer.py aeec9e157d06 
   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
   src/mem/ruby/system/Cache.py aeec9e157d06 
   src/mem/ruby/system/CacheMemory.hh aeec9e157d06 
   src/mem/ruby/system/CacheMemory.cc aeec9e157d06 
   src/mem/ruby/system/DirectoryMemory.hh aeec9e157d06 
   src/mem/ruby/system/DirectoryMemory.cc aeec9e157d06 
   src/mem/ruby/system/DirectoryMemory.py aeec9e157d06 
   src/mem/ruby/system/RubyPort.hh aeec9e157d06 
   src/mem/ruby/system/RubyPort.cc aeec9e157d06 
   src/mem/ruby/system/RubySystem.py aeec9e157d06 
   src/mem/ruby/system/SConscript aeec9e157d06 
   src/mem/ruby/system/Sequencer.cc aeec9e157d06 
   src/mem/ruby/system/Sequencer.py aeec9e157d06 
   src/mem/ruby/system/System.hh aeec9e157d06 
   src/mem/ruby/system/System.cc aeec9e157d06 
 
 Diff: http://reviews.m5sim.org/r/611/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Nilay
 


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


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

2011-04-04 Thread Nilay Vaish

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

(Updated 2011-04-04 06:22:20.346203)


Review request for Default.


Summary
---

Ruby: Add support for functional accesses
This patch is meant for aiding discussions on implementation of functional
access support in Ruby.


Diffs (updated)
-

  configs/ruby/MESI_CMP_directory.py aeec9e157d06 
  configs/ruby/Ruby.py aeec9e157d06 
  src/mem/ruby/network/Network.cc aeec9e157d06 
  src/mem/ruby/network/Network.py aeec9e157d06 
  src/mem/ruby/profiler/Profiler.cc aeec9e157d06 
  src/mem/ruby/profiler/Profiler.py aeec9e157d06 
  src/mem/ruby/recorder/Tracer.cc aeec9e157d06 
  src/mem/ruby/recorder/Tracer.py aeec9e157d06 
  src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
  src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
  src/mem/ruby/system/AbstractMemory.py PRE-CREATION 
  src/mem/ruby/system/Cache.py aeec9e157d06 
  src/mem/ruby/system/CacheMemory.hh aeec9e157d06 
  src/mem/ruby/system/CacheMemory.cc aeec9e157d06 
  src/mem/ruby/system/DirectoryMemory.hh aeec9e157d06 
  src/mem/ruby/system/DirectoryMemory.cc aeec9e157d06 
  src/mem/ruby/system/DirectoryMemory.py aeec9e157d06 
  src/mem/ruby/system/RubyPort.hh aeec9e157d06 
  src/mem/ruby/system/RubyPort.cc aeec9e157d06 
  src/mem/ruby/system/RubySystem.py aeec9e157d06 
  src/mem/ruby/system/SConscript aeec9e157d06 
  src/mem/ruby/system/Sequencer.cc aeec9e157d06 
  src/mem/ruby/system/Sequencer.py aeec9e157d06 
  src/mem/ruby/system/System.hh aeec9e157d06 
  src/mem/ruby/system/System.cc aeec9e157d06 

Diff: http://reviews.m5sim.org/r/611/diff


Testing
---


Thanks,

Nilay

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


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

2011-04-03 Thread Nilay Vaish


 On 2011-03-31 22:08:21, Brad Beckmann wrote:
  This looks great, I just have a few minor suggestions below.
  
  It seems like the next step is to figure out how to deal with functional 
  accesses not succeeding in the CPUs and devices.
 
 Nilay Vaish wrote:
 Brad, I would make the changes you have listed below. I also need to add
 code for directory memory accesses. Can you elaborate on the next step 
 you 
 mentioned? We are yet not dealing with the devices, I believe.

One more question for you. Do we need functional access support for the PioPort
as well? We do not have it currently.


- Nilay


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


On 2011-04-02 11:42:47, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/611/
 ---
 
 (Updated 2011-04-02 11:42:47)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Add support for functional accesses
 This patch is meant for aiding discussions on implementation of functional
 access support in Ruby.
 
 
 Diffs
 -
 
   configs/ruby/MESI_CMP_directory.py aeec9e157d06 
   configs/ruby/Ruby.py aeec9e157d06 
   src/mem/ruby/network/Network.cc aeec9e157d06 
   src/mem/ruby/network/Network.py aeec9e157d06 
   src/mem/ruby/profiler/Profiler.cc aeec9e157d06 
   src/mem/ruby/profiler/Profiler.py aeec9e157d06 
   src/mem/ruby/recorder/Tracer.cc aeec9e157d06 
   src/mem/ruby/recorder/Tracer.py aeec9e157d06 
   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
   src/mem/ruby/system/Cache.py aeec9e157d06 
   src/mem/ruby/system/CacheMemory.hh aeec9e157d06 
   src/mem/ruby/system/CacheMemory.cc aeec9e157d06 
   src/mem/ruby/system/DirectoryMemory.hh aeec9e157d06 
   src/mem/ruby/system/DirectoryMemory.cc aeec9e157d06 
   src/mem/ruby/system/DirectoryMemory.py aeec9e157d06 
   src/mem/ruby/system/RubyPort.hh aeec9e157d06 
   src/mem/ruby/system/RubyPort.cc aeec9e157d06 
   src/mem/ruby/system/RubySystem.py aeec9e157d06 
   src/mem/ruby/system/SConscript aeec9e157d06 
   src/mem/ruby/system/Sequencer.cc aeec9e157d06 
   src/mem/ruby/system/Sequencer.py aeec9e157d06 
   src/mem/ruby/system/System.hh aeec9e157d06 
   src/mem/ruby/system/System.cc aeec9e157d06 
 
 Diff: http://reviews.m5sim.org/r/611/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Nilay
 


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


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

2011-04-03 Thread Brad Beckmann

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



src/mem/ruby/system/DirectoryMemory.py
http://reviews.m5sim.org/r/611/#comment1449

Why are you deleting this file and where are you moving the current 
functionality?


- Brad


On 2011-04-02 11:42:47, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/611/
 ---
 
 (Updated 2011-04-02 11:42:47)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Add support for functional accesses
 This patch is meant for aiding discussions on implementation of functional
 access support in Ruby.
 
 
 Diffs
 -
 
   configs/ruby/MESI_CMP_directory.py aeec9e157d06 
   configs/ruby/Ruby.py aeec9e157d06 
   src/mem/ruby/network/Network.cc aeec9e157d06 
   src/mem/ruby/network/Network.py aeec9e157d06 
   src/mem/ruby/profiler/Profiler.cc aeec9e157d06 
   src/mem/ruby/profiler/Profiler.py aeec9e157d06 
   src/mem/ruby/recorder/Tracer.cc aeec9e157d06 
   src/mem/ruby/recorder/Tracer.py aeec9e157d06 
   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
   src/mem/ruby/system/Cache.py aeec9e157d06 
   src/mem/ruby/system/CacheMemory.hh aeec9e157d06 
   src/mem/ruby/system/CacheMemory.cc aeec9e157d06 
   src/mem/ruby/system/DirectoryMemory.hh aeec9e157d06 
   src/mem/ruby/system/DirectoryMemory.cc aeec9e157d06 
   src/mem/ruby/system/DirectoryMemory.py aeec9e157d06 
   src/mem/ruby/system/RubyPort.hh aeec9e157d06 
   src/mem/ruby/system/RubyPort.cc aeec9e157d06 
   src/mem/ruby/system/RubySystem.py aeec9e157d06 
   src/mem/ruby/system/SConscript aeec9e157d06 
   src/mem/ruby/system/Sequencer.cc aeec9e157d06 
   src/mem/ruby/system/Sequencer.py aeec9e157d06 
   src/mem/ruby/system/System.hh aeec9e157d06 
   src/mem/ruby/system/System.cc aeec9e157d06 
 
 Diff: http://reviews.m5sim.org/r/611/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Nilay
 


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


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

2011-04-03 Thread Brad Beckmann


 On 2011-03-31 22:08:21, Brad Beckmann wrote:
  This looks great, I just have a few minor suggestions below.
  
  It seems like the next step is to figure out how to deal with functional 
  accesses not succeeding in the CPUs and devices.
 
 Nilay Vaish wrote:
 Brad, I would make the changes you have listed below. I also need to add
 code for directory memory accesses. Can you elaborate on the next step 
 you 
 mentioned? We are yet not dealing with the devices, I believe.
 
 Nilay Vaish wrote:
 One more question for you. Do we need functional access support for the 
 PioPort
 as well? We do not have it currently.

Yes, eventually if we want Ruby to supply data in FS mode, RubyPort will need 
to support functional access from the PioPort to Ruby memory.  It is up to you 
whether you want to implement that support now, or first make sure functional 
accesses are working SE mode.  If you want to make sure SE mode functional 
accesses work, first modify the ruby mem tester to issue functional access 
(right now that is hardcoded off).  Also you should try a few binaries under SE 
mode, like hello world.  


- Brad


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


On 2011-04-02 11:42:47, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/611/
 ---
 
 (Updated 2011-04-02 11:42:47)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Add support for functional accesses
 This patch is meant for aiding discussions on implementation of functional
 access support in Ruby.
 
 
 Diffs
 -
 
   configs/ruby/MESI_CMP_directory.py aeec9e157d06 
   configs/ruby/Ruby.py aeec9e157d06 
   src/mem/ruby/network/Network.cc aeec9e157d06 
   src/mem/ruby/network/Network.py aeec9e157d06 
   src/mem/ruby/profiler/Profiler.cc aeec9e157d06 
   src/mem/ruby/profiler/Profiler.py aeec9e157d06 
   src/mem/ruby/recorder/Tracer.cc aeec9e157d06 
   src/mem/ruby/recorder/Tracer.py aeec9e157d06 
   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
   src/mem/ruby/system/Cache.py aeec9e157d06 
   src/mem/ruby/system/CacheMemory.hh aeec9e157d06 
   src/mem/ruby/system/CacheMemory.cc aeec9e157d06 
   src/mem/ruby/system/DirectoryMemory.hh aeec9e157d06 
   src/mem/ruby/system/DirectoryMemory.cc aeec9e157d06 
   src/mem/ruby/system/DirectoryMemory.py aeec9e157d06 
   src/mem/ruby/system/RubyPort.hh aeec9e157d06 
   src/mem/ruby/system/RubyPort.cc aeec9e157d06 
   src/mem/ruby/system/RubySystem.py aeec9e157d06 
   src/mem/ruby/system/SConscript aeec9e157d06 
   src/mem/ruby/system/Sequencer.cc aeec9e157d06 
   src/mem/ruby/system/Sequencer.py aeec9e157d06 
   src/mem/ruby/system/System.hh aeec9e157d06 
   src/mem/ruby/system/System.cc aeec9e157d06 
 
 Diff: http://reviews.m5sim.org/r/611/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Nilay
 


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


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

2011-04-02 Thread Nilay Vaish


 On 2011-04-01 09:30:54, Brad Beckmann wrote:
  Hi Nilay,

Comments below.  I might be missing something, but the changes to 
DirectoryMemory seem straightforward.

No, you are not missing anything. It is just that I had not implemented
it up till now.


- Nilay


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


On 2011-03-31 20:44:17, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/611/
 ---
 
 (Updated 2011-03-31 20:44:17)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Add support for functional accesses
 This patch is meant for aiding discussions on implementation of functional
 access support in Ruby.
 
 
 Diffs
 -
 
   configs/ruby/MESI_CMP_directory.py c7302d55d644 
   configs/ruby/Ruby.py c7302d55d644 
   src/mem/ruby/network/Network.cc c7302d55d644 
   src/mem/ruby/network/Network.py c7302d55d644 
   src/mem/ruby/profiler/Profiler.cc c7302d55d644 
   src/mem/ruby/profiler/Profiler.py c7302d55d644 
   src/mem/ruby/recorder/Tracer.cc c7302d55d644 
   src/mem/ruby/recorder/Tracer.py c7302d55d644 
   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
   src/mem/ruby/system/Cache.py c7302d55d644 
   src/mem/ruby/system/CacheMemory.hh c7302d55d644 
   src/mem/ruby/system/CacheMemory.cc c7302d55d644 
   src/mem/ruby/system/DirectoryMemory.hh c7302d55d644 
   src/mem/ruby/system/DirectoryMemory.cc c7302d55d644 
   src/mem/ruby/system/DirectoryMemory.py c7302d55d644 
   src/mem/ruby/system/RubyPort.hh c7302d55d644 
   src/mem/ruby/system/RubyPort.cc c7302d55d644 
   src/mem/ruby/system/RubySystem.py c7302d55d644 
   src/mem/ruby/system/SConscript c7302d55d644 
   src/mem/ruby/system/Sequencer.cc c7302d55d644 
   src/mem/ruby/system/Sequencer.py c7302d55d644 
   src/mem/ruby/system/System.hh c7302d55d644 
   src/mem/ruby/system/System.cc c7302d55d644 
 
 Diff: http://reviews.m5sim.org/r/611/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Nilay
 


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


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

2011-04-02 Thread Nilay Vaish


 On 2011-03-31 22:08:21, Brad Beckmann wrote:
  src/mem/ruby/system/RubyPort.cc, line 417
  http://reviews.m5sim.org/r/611/diff/3/?file=11443#file11443line417
 
  Are functional packets put on the stack or the heap?  I seem to 
  remember the former, but I could be wrong.

In a couple of places in src/mem/port.cc, the packet is on the stack.
But in src/cpu/testers/memtest/memtest.cc, the packet is on the heap.
As per the documentation, the packet is owned by the requestor. So, the
requestor will have to free the packet. I will remove this code. 


- Nilay


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


On 2011-03-31 20:44:17, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/611/
 ---
 
 (Updated 2011-03-31 20:44:17)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Add support for functional accesses
 This patch is meant for aiding discussions on implementation of functional
 access support in Ruby.
 
 
 Diffs
 -
 
   configs/ruby/MESI_CMP_directory.py c7302d55d644 
   configs/ruby/Ruby.py c7302d55d644 
   src/mem/ruby/network/Network.cc c7302d55d644 
   src/mem/ruby/network/Network.py c7302d55d644 
   src/mem/ruby/profiler/Profiler.cc c7302d55d644 
   src/mem/ruby/profiler/Profiler.py c7302d55d644 
   src/mem/ruby/recorder/Tracer.cc c7302d55d644 
   src/mem/ruby/recorder/Tracer.py c7302d55d644 
   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
   src/mem/ruby/system/Cache.py c7302d55d644 
   src/mem/ruby/system/CacheMemory.hh c7302d55d644 
   src/mem/ruby/system/CacheMemory.cc c7302d55d644 
   src/mem/ruby/system/DirectoryMemory.hh c7302d55d644 
   src/mem/ruby/system/DirectoryMemory.cc c7302d55d644 
   src/mem/ruby/system/DirectoryMemory.py c7302d55d644 
   src/mem/ruby/system/RubyPort.hh c7302d55d644 
   src/mem/ruby/system/RubyPort.cc c7302d55d644 
   src/mem/ruby/system/RubySystem.py c7302d55d644 
   src/mem/ruby/system/SConscript c7302d55d644 
   src/mem/ruby/system/Sequencer.cc c7302d55d644 
   src/mem/ruby/system/Sequencer.py c7302d55d644 
   src/mem/ruby/system/System.hh c7302d55d644 
   src/mem/ruby/system/System.cc c7302d55d644 
 
 Diff: http://reviews.m5sim.org/r/611/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Nilay
 


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


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

2011-04-02 Thread Nilay Vaish

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

(Updated 2011-04-02 11:42:47.195024)


Review request for Default.


Summary
---

Ruby: Add support for functional accesses
This patch is meant for aiding discussions on implementation of functional
access support in Ruby.


Diffs (updated)
-

  configs/ruby/MESI_CMP_directory.py aeec9e157d06 
  configs/ruby/Ruby.py aeec9e157d06 
  src/mem/ruby/network/Network.cc aeec9e157d06 
  src/mem/ruby/network/Network.py aeec9e157d06 
  src/mem/ruby/profiler/Profiler.cc aeec9e157d06 
  src/mem/ruby/profiler/Profiler.py aeec9e157d06 
  src/mem/ruby/recorder/Tracer.cc aeec9e157d06 
  src/mem/ruby/recorder/Tracer.py aeec9e157d06 
  src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
  src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
  src/mem/ruby/system/Cache.py aeec9e157d06 
  src/mem/ruby/system/CacheMemory.hh aeec9e157d06 
  src/mem/ruby/system/CacheMemory.cc aeec9e157d06 
  src/mem/ruby/system/DirectoryMemory.hh aeec9e157d06 
  src/mem/ruby/system/DirectoryMemory.cc aeec9e157d06 
  src/mem/ruby/system/DirectoryMemory.py aeec9e157d06 
  src/mem/ruby/system/RubyPort.hh aeec9e157d06 
  src/mem/ruby/system/RubyPort.cc aeec9e157d06 
  src/mem/ruby/system/RubySystem.py aeec9e157d06 
  src/mem/ruby/system/SConscript aeec9e157d06 
  src/mem/ruby/system/Sequencer.cc aeec9e157d06 
  src/mem/ruby/system/Sequencer.py aeec9e157d06 
  src/mem/ruby/system/System.hh aeec9e157d06 
  src/mem/ruby/system/System.cc aeec9e157d06 

Diff: http://reviews.m5sim.org/r/611/diff


Testing
---


Thanks,

Nilay

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


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

2011-04-01 Thread Nilay Vaish


 On 2011-03-31 22:08:21, Brad Beckmann wrote:
  This looks great, I just have a few minor suggestions below.
  
  It seems like the next step is to figure out how to deal with functional 
  accesses not succeeding in the CPUs and devices.

Brad, I would make the changes you have listed below. I also need to add
code for directory memory accesses. Can you elaborate on the next step you 
mentioned? We are yet not dealing with the devices, I believe.


- Nilay


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


On 2011-03-31 20:44:17, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/611/
 ---
 
 (Updated 2011-03-31 20:44:17)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Add support for functional accesses
 This patch is meant for aiding discussions on implementation of functional
 access support in Ruby.
 
 
 Diffs
 -
 
   configs/ruby/MESI_CMP_directory.py c7302d55d644 
   configs/ruby/Ruby.py c7302d55d644 
   src/mem/ruby/network/Network.cc c7302d55d644 
   src/mem/ruby/network/Network.py c7302d55d644 
   src/mem/ruby/profiler/Profiler.cc c7302d55d644 
   src/mem/ruby/profiler/Profiler.py c7302d55d644 
   src/mem/ruby/recorder/Tracer.cc c7302d55d644 
   src/mem/ruby/recorder/Tracer.py c7302d55d644 
   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
   src/mem/ruby/system/Cache.py c7302d55d644 
   src/mem/ruby/system/CacheMemory.hh c7302d55d644 
   src/mem/ruby/system/CacheMemory.cc c7302d55d644 
   src/mem/ruby/system/DirectoryMemory.hh c7302d55d644 
   src/mem/ruby/system/DirectoryMemory.cc c7302d55d644 
   src/mem/ruby/system/DirectoryMemory.py c7302d55d644 
   src/mem/ruby/system/RubyPort.hh c7302d55d644 
   src/mem/ruby/system/RubyPort.cc c7302d55d644 
   src/mem/ruby/system/RubySystem.py c7302d55d644 
   src/mem/ruby/system/SConscript c7302d55d644 
   src/mem/ruby/system/Sequencer.cc c7302d55d644 
   src/mem/ruby/system/Sequencer.py c7302d55d644 
   src/mem/ruby/system/System.hh c7302d55d644 
   src/mem/ruby/system/System.cc c7302d55d644 
 
 Diff: http://reviews.m5sim.org/r/611/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Nilay
 


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


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

2011-04-01 Thread Brad Beckmann

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


Hi Nilay,

Comments below.  I might be missing something, but the changes to 
DirectoryMemory seem straightforward.



src/mem/ruby/system/DirectoryMemory.cc
http://reviews.m5sim.org/r/611/#comment1445

In the constructor for AbstractMemory, it appears that the DirectoryMemory 
is being added to the list of abstract memories, correct?  What more do you 
need to do?



src/mem/ruby/system/DirectoryMemory.cc
http://reviews.m5sim.org/r/611/#comment1447

Directory_Entry inherits from Abstract_Entry and Abstract_Entry now 
includes m_Permission.  It seems like you can implement this function very 
similar to what you did with CacheMemory.  Am I missing something?



src/mem/ruby/system/RubyPort.cc
http://reviews.m5sim.org/r/611/#comment1444

You may want to add a ruby_system pointer directly to the RubyPort::M5Port 
to avoid at least one layer of deferencing.


- Brad


On 2011-03-31 20:44:17, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/611/
 ---
 
 (Updated 2011-03-31 20:44:17)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Add support for functional accesses
 This patch is meant for aiding discussions on implementation of functional
 access support in Ruby.
 
 
 Diffs
 -
 
   configs/ruby/MESI_CMP_directory.py c7302d55d644 
   configs/ruby/Ruby.py c7302d55d644 
   src/mem/ruby/network/Network.cc c7302d55d644 
   src/mem/ruby/network/Network.py c7302d55d644 
   src/mem/ruby/profiler/Profiler.cc c7302d55d644 
   src/mem/ruby/profiler/Profiler.py c7302d55d644 
   src/mem/ruby/recorder/Tracer.cc c7302d55d644 
   src/mem/ruby/recorder/Tracer.py c7302d55d644 
   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
   src/mem/ruby/system/Cache.py c7302d55d644 
   src/mem/ruby/system/CacheMemory.hh c7302d55d644 
   src/mem/ruby/system/CacheMemory.cc c7302d55d644 
   src/mem/ruby/system/DirectoryMemory.hh c7302d55d644 
   src/mem/ruby/system/DirectoryMemory.cc c7302d55d644 
   src/mem/ruby/system/DirectoryMemory.py c7302d55d644 
   src/mem/ruby/system/RubyPort.hh c7302d55d644 
   src/mem/ruby/system/RubyPort.cc c7302d55d644 
   src/mem/ruby/system/RubySystem.py c7302d55d644 
   src/mem/ruby/system/SConscript c7302d55d644 
   src/mem/ruby/system/Sequencer.cc c7302d55d644 
   src/mem/ruby/system/Sequencer.py c7302d55d644 
   src/mem/ruby/system/System.hh c7302d55d644 
   src/mem/ruby/system/System.cc c7302d55d644 
 
 Diff: http://reviews.m5sim.org/r/611/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Nilay
 


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


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

2011-04-01 Thread Brad Beckmann


 On 2011-03-31 11:11:03, Brad Beckmann wrote:
  src/mem/ruby/system/RubyPort.cc, line 321
  http://reviews.m5sim.org/r/611/diff/2/?file=11382#file11382line321
 
  This loop is probably the most complicated and important part of this 
  patch.  It might be easiest if we move this functionality into two 
  different functions, one for reads and one for writes.
  
  The read scan just needs to ensure that at least one memory says that 
  it has the address in Read_Only or ReadWrite state.  We may also want to 
  doublecheck that multiple memories say they have the address in ReadWrite 
  state.
  
  The write scan is more complicated.  If one memory says that it has the 
  address in ReadWrite state, then I don't think it matters what state the 
  other memories are in (except of course if another memory says it also has 
  the address in ReadWrite), the write should succeed.  Also if the write 
  scans says that all copies are in Read_Only or Invalid/NotPresent state and 
  no copies are Busy, the write should succeed.  However, writes should fail 
  if either no Read_Only or ReadWrite copies are found, or if a Busy copy is 
  found and no ReadWrite copy is found.  The latter situation will likely 
  indicate the functional write is racing with a timing write.  There is no 
  easy, protocol-agnostic way to resolve such a race in the current 
  infrastructure.
  
  Make sense?
 
 Nilay Vaish wrote:
 I think we should have the following cases for functional writes --
 1. Only read only copies -- write succeeds
 2. One read write copy -- write succeeds
 3. At least one busy -- write fails.
 4. None of the above, then simply update the memory. Memory should
 also get updated in 1. as well.
 
 Brad, from your comment it seems that you expect that there can be 
 multiple read-write copies simultaneously. Is this possible, or would
 this be a bug in the protocol?
 
 Brad Beckmann wrote:
 You are absolutely right, that would be an error in the protocol.  It 
 just seems that since we are scanning the state of the address in the system, 
 we might as well double check that at most one ReadWrite copy exists.
 
 I completely agree with your first two cases.  However, I think the third 
 case is slightly too restrictive.  Just because one memory has the address as 
 Busy, doesn't necessarily mean that we cannot update the block.  If another 
 memory has the block in read-write state, we can be certain that that 
 particular copy is not only still valid, but has also yet to relinquish 
 exclusive ownership.  Therefore a function write to that block can succeed.  
 Meanwhile, if we find a Busy block and just Read_Only block(s), than other 
 valid copies may exist somewhere in the system and thus the functional write 
 likely won't succeed.
 
 I'm confused by your fourth case.  Isn't Ruby memory (a.k.a. 
 DirectoryMemory) just another AbstractMemory object and thus just another 
 memory in the list of memories?  My hope was that we would treat CacheMemory 
 and DirectoryMemory the same when doing functional accesses.  Am I missing 
 something?
 
 Nilay Vaish wrote:
 Brad, put it down to my lack of understanding of how the memory has been 
 organized. Currently, it seems to me that directory memory will either have a 
 sparse memory vector or a memory vector. These will contain the directory 
 entries. It is these directory entries which hold the data blocks, which 
 would be handled in a fashion similar to cache entries.

Yes, that is correct.  With my recent change, directory entries also include 
access premissions which are automatically set by SLICC.  You should be able to 
treat them th same way.


- Brad


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


On 2011-03-31 20:44:17, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/611/
 ---
 
 (Updated 2011-03-31 20:44:17)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Add support for functional accesses
 This patch is meant for aiding discussions on implementation of functional
 access support in Ruby.
 
 
 Diffs
 -
 
   configs/ruby/MESI_CMP_directory.py c7302d55d644 
   configs/ruby/Ruby.py c7302d55d644 
   src/mem/ruby/network/Network.cc c7302d55d644 
   src/mem/ruby/network/Network.py c7302d55d644 
   src/mem/ruby/profiler/Profiler.cc c7302d55d644 
   src/mem/ruby/profiler/Profiler.py c7302d55d644 
   src/mem/ruby/recorder/Tracer.cc c7302d55d644 
   src/mem/ruby/recorder/Tracer.py c7302d55d644 
   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
   

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

2011-03-31 Thread Brad Beckmann

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


Hi Nilay,

First, thanks for your patience.  Sorry I wasn't able to provide you comments 
sooner.

Overall, this patch is definitely what I had in mind and is a good starting 
point.  I have several comments/questions below.  Please let me know if you 
need me to clarify anything.


src/mem/ruby/system/AbstractMemory.hh
http://reviews.m5sim.org/r/611/#comment1425

Instead of having canMakeFunctionalAccess do some internal analysis and 
return a boolean result, why not simply pass back the AccessPermission?  The 
status of the address for a particular memory object does not indicate whether 
a functional access is possible.  Rather it is the collective status across all 
memory objects which determine whether the functional access is possible.



src/mem/ruby/system/CacheMemory.cc
http://reviews.m5sim.org/r/611/#comment1426

Again, I think this type of analysis should be moved the RubyPort, but I do 
want to point out that functional accesses have different constraints than real 
accesses.  Even if the AccessPermission is Read_Only, a functional access can 
succeed and should update the block.



src/mem/ruby/system/RubyPort.cc
http://reviews.m5sim.org/r/611/#comment1427

Eventually, we'll need to change recvFunctional to return a bool indicating 
whether the access was successful.  I suspect the ramifications of the change 
will be rather significant across gem5, so for now it is fine to just return 
void.  However, eventually we will need to address this larger issue.



src/mem/ruby/system/RubyPort.cc
http://reviews.m5sim.org/r/611/#comment1421

Are you just pushing a lable here for debug purposes?  Does this have any 
impact on the actual functionality?



src/mem/ruby/system/RubyPort.cc
http://reviews.m5sim.org/r/611/#comment1428

This loop is probably the most complicated and important part of this 
patch.  It might be easiest if we move this functionality into two different 
functions, one for reads and one for writes.

The read scan just needs to ensure that at least one memory says that it 
has the address in Read_Only or ReadWrite state.  We may also want to 
doublecheck that multiple memories say they have the address in ReadWrite state.

The write scan is more complicated.  If one memory says that it has the 
address in ReadWrite state, then I don't think it matters what state the other 
memories are in (except of course if another memory says it also has the 
address in ReadWrite), the write should succeed.  Also if the write scans says 
that all copies are in Read_Only or Invalid/NotPresent state and no copies are 
Busy, the write should succeed.  However, writes should fail if either no 
Read_Only or ReadWrite copies are found, or if a Busy copy is found and no 
ReadWrite copy is found.  The latter situation will likely indicate the 
functional write is racing with a timing write.  There is no easy, 
protocol-agnostic way to resolve such a race in the current infrastructure.

Make sense?



src/mem/ruby/system/System.hh
http://reviews.m5sim.org/r/611/#comment1423

Why is this a static function?  It seems unecessary and it prevents us from 
using ruby in multiple systems.


- Brad


On 2011-03-30 16:19:26, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/611/
 ---
 
 (Updated 2011-03-30 16:19:26)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Add support for functional accesses
 This patch is meant for aiding discussions on implementation of functional
 access support in Ruby.
 
 
 Diffs
 -
 
   configs/ruby/MESI_CMP_directory.py d54b7775a6b0 
   configs/ruby/Ruby.py d54b7775a6b0 
   src/mem/ruby/network/Network.cc d54b7775a6b0 
   src/mem/ruby/network/Network.py d54b7775a6b0 
   src/mem/ruby/profiler/Profiler.cc d54b7775a6b0 
   src/mem/ruby/profiler/Profiler.py d54b7775a6b0 
   src/mem/ruby/recorder/Tracer.cc d54b7775a6b0 
   src/mem/ruby/recorder/Tracer.py d54b7775a6b0 
   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
   src/mem/ruby/system/Cache.py d54b7775a6b0 
   src/mem/ruby/system/CacheMemory.hh d54b7775a6b0 
   src/mem/ruby/system/CacheMemory.cc d54b7775a6b0 
   src/mem/ruby/system/DirectoryMemory.hh d54b7775a6b0 
   src/mem/ruby/system/DirectoryMemory.cc d54b7775a6b0 
   src/mem/ruby/system/DirectoryMemory.py d54b7775a6b0 
   src/mem/ruby/system/RubyPort.hh d54b7775a6b0 
   src/mem/ruby/system/RubyPort.cc d54b7775a6b0 
   src/mem/ruby/system/RubySystem.py d54b7775a6b0 
   src/mem/ruby/system/SConscript d54b7775a6b0 
   src/mem/ruby/system/Sequencer.py 

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

2011-03-31 Thread Nilay Vaish


 On 2011-03-31 11:11:03, Brad Beckmann wrote:
  src/mem/ruby/system/RubyPort.cc, line 321
  http://reviews.m5sim.org/r/611/diff/2/?file=11382#file11382line321
 
  This loop is probably the most complicated and important part of this 
  patch.  It might be easiest if we move this functionality into two 
  different functions, one for reads and one for writes.
  
  The read scan just needs to ensure that at least one memory says that 
  it has the address in Read_Only or ReadWrite state.  We may also want to 
  doublecheck that multiple memories say they have the address in ReadWrite 
  state.
  
  The write scan is more complicated.  If one memory says that it has the 
  address in ReadWrite state, then I don't think it matters what state the 
  other memories are in (except of course if another memory says it also has 
  the address in ReadWrite), the write should succeed.  Also if the write 
  scans says that all copies are in Read_Only or Invalid/NotPresent state and 
  no copies are Busy, the write should succeed.  However, writes should fail 
  if either no Read_Only or ReadWrite copies are found, or if a Busy copy is 
  found and no ReadWrite copy is found.  The latter situation will likely 
  indicate the functional write is racing with a timing write.  There is no 
  easy, protocol-agnostic way to resolve such a race in the current 
  infrastructure.
  
  Make sense?

I think we should have the following cases for functional writes --
1. Only read only copies -- write succeeds
2. One read write copy -- write succeeds
3. At least one busy -- write fails.
4. None of the above, then simply update the memory. Memory should
also get updated in 1. as well.

Brad, from your comment it seems that you expect that there can be 
multiple read-write copies simultaneously. Is this possible, or would
this be a bug in the protocol?


- Nilay


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


On 2011-03-30 16:19:26, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/611/
 ---
 
 (Updated 2011-03-30 16:19:26)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Add support for functional accesses
 This patch is meant for aiding discussions on implementation of functional
 access support in Ruby.
 
 
 Diffs
 -
 
   configs/ruby/MESI_CMP_directory.py d54b7775a6b0 
   configs/ruby/Ruby.py d54b7775a6b0 
   src/mem/ruby/network/Network.cc d54b7775a6b0 
   src/mem/ruby/network/Network.py d54b7775a6b0 
   src/mem/ruby/profiler/Profiler.cc d54b7775a6b0 
   src/mem/ruby/profiler/Profiler.py d54b7775a6b0 
   src/mem/ruby/recorder/Tracer.cc d54b7775a6b0 
   src/mem/ruby/recorder/Tracer.py d54b7775a6b0 
   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
   src/mem/ruby/system/Cache.py d54b7775a6b0 
   src/mem/ruby/system/CacheMemory.hh d54b7775a6b0 
   src/mem/ruby/system/CacheMemory.cc d54b7775a6b0 
   src/mem/ruby/system/DirectoryMemory.hh d54b7775a6b0 
   src/mem/ruby/system/DirectoryMemory.cc d54b7775a6b0 
   src/mem/ruby/system/DirectoryMemory.py d54b7775a6b0 
   src/mem/ruby/system/RubyPort.hh d54b7775a6b0 
   src/mem/ruby/system/RubyPort.cc d54b7775a6b0 
   src/mem/ruby/system/RubySystem.py d54b7775a6b0 
   src/mem/ruby/system/SConscript d54b7775a6b0 
   src/mem/ruby/system/Sequencer.py d54b7775a6b0 
   src/mem/ruby/system/System.hh d54b7775a6b0 
   src/mem/ruby/system/System.cc d54b7775a6b0 
 
 Diff: http://reviews.m5sim.org/r/611/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Nilay
 


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


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

2011-03-31 Thread Brad Beckmann


 On 2011-03-31 11:11:03, Brad Beckmann wrote:
  src/mem/ruby/system/RubyPort.cc, line 321
  http://reviews.m5sim.org/r/611/diff/2/?file=11382#file11382line321
 
  This loop is probably the most complicated and important part of this 
  patch.  It might be easiest if we move this functionality into two 
  different functions, one for reads and one for writes.
  
  The read scan just needs to ensure that at least one memory says that 
  it has the address in Read_Only or ReadWrite state.  We may also want to 
  doublecheck that multiple memories say they have the address in ReadWrite 
  state.
  
  The write scan is more complicated.  If one memory says that it has the 
  address in ReadWrite state, then I don't think it matters what state the 
  other memories are in (except of course if another memory says it also has 
  the address in ReadWrite), the write should succeed.  Also if the write 
  scans says that all copies are in Read_Only or Invalid/NotPresent state and 
  no copies are Busy, the write should succeed.  However, writes should fail 
  if either no Read_Only or ReadWrite copies are found, or if a Busy copy is 
  found and no ReadWrite copy is found.  The latter situation will likely 
  indicate the functional write is racing with a timing write.  There is no 
  easy, protocol-agnostic way to resolve such a race in the current 
  infrastructure.
  
  Make sense?
 
 Nilay Vaish wrote:
 I think we should have the following cases for functional writes --
 1. Only read only copies -- write succeeds
 2. One read write copy -- write succeeds
 3. At least one busy -- write fails.
 4. None of the above, then simply update the memory. Memory should
 also get updated in 1. as well.
 
 Brad, from your comment it seems that you expect that there can be 
 multiple read-write copies simultaneously. Is this possible, or would
 this be a bug in the protocol?

You are absolutely right, that would be an error in the protocol.  It just 
seems that since we are scanning the state of the address in the system, we 
might as well double check that at most one ReadWrite copy exists.

I completely agree with your first two cases.  However, I think the third case 
is slightly too restrictive.  Just because one memory has the address as Busy, 
doesn't necessarily mean that we cannot update the block.  If another memory 
has the block in read-write state, we can be certain that that particular copy 
is not only still valid, but has also yet to relinquish exclusive ownership.  
Therefore a function write to that block can succeed.  Meanwhile, if we find a 
Busy block and just Read_Only block(s), than other valid copies may exist 
somewhere in the system and thus the functional write likely won't succeed.

I'm confused by your fourth case.  Isn't Ruby memory (a.k.a. DirectoryMemory) 
just another AbstractMemory object and thus just another memory in the list of 
memories?  My hope was that we would treat CacheMemory and DirectoryMemory the 
same when doing functional accesses.  Am I missing something?


- Brad


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


On 2011-03-30 16:19:26, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/611/
 ---
 
 (Updated 2011-03-30 16:19:26)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Add support for functional accesses
 This patch is meant for aiding discussions on implementation of functional
 access support in Ruby.
 
 
 Diffs
 -
 
   configs/ruby/MESI_CMP_directory.py d54b7775a6b0 
   configs/ruby/Ruby.py d54b7775a6b0 
   src/mem/ruby/network/Network.cc d54b7775a6b0 
   src/mem/ruby/network/Network.py d54b7775a6b0 
   src/mem/ruby/profiler/Profiler.cc d54b7775a6b0 
   src/mem/ruby/profiler/Profiler.py d54b7775a6b0 
   src/mem/ruby/recorder/Tracer.cc d54b7775a6b0 
   src/mem/ruby/recorder/Tracer.py d54b7775a6b0 
   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
   src/mem/ruby/system/Cache.py d54b7775a6b0 
   src/mem/ruby/system/CacheMemory.hh d54b7775a6b0 
   src/mem/ruby/system/CacheMemory.cc d54b7775a6b0 
   src/mem/ruby/system/DirectoryMemory.hh d54b7775a6b0 
   src/mem/ruby/system/DirectoryMemory.cc d54b7775a6b0 
   src/mem/ruby/system/DirectoryMemory.py d54b7775a6b0 
   src/mem/ruby/system/RubyPort.hh d54b7775a6b0 
   src/mem/ruby/system/RubyPort.cc d54b7775a6b0 
   src/mem/ruby/system/RubySystem.py d54b7775a6b0 
   src/mem/ruby/system/SConscript d54b7775a6b0 
   src/mem/ruby/system/Sequencer.py d54b7775a6b0 
   src/mem/ruby/system/System.hh d54b7775a6b0 
   

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

2011-03-31 Thread Nilay Vaish

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

(Updated 2011-03-31 20:44:17.499794)


Review request for Default.


Summary
---

Ruby: Add support for functional accesses
This patch is meant for aiding discussions on implementation of functional
access support in Ruby.


Diffs (updated)
-

  configs/ruby/MESI_CMP_directory.py c7302d55d644 
  configs/ruby/Ruby.py c7302d55d644 
  src/mem/ruby/network/Network.cc c7302d55d644 
  src/mem/ruby/network/Network.py c7302d55d644 
  src/mem/ruby/profiler/Profiler.cc c7302d55d644 
  src/mem/ruby/profiler/Profiler.py c7302d55d644 
  src/mem/ruby/recorder/Tracer.cc c7302d55d644 
  src/mem/ruby/recorder/Tracer.py c7302d55d644 
  src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
  src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
  src/mem/ruby/system/Cache.py c7302d55d644 
  src/mem/ruby/system/CacheMemory.hh c7302d55d644 
  src/mem/ruby/system/CacheMemory.cc c7302d55d644 
  src/mem/ruby/system/DirectoryMemory.hh c7302d55d644 
  src/mem/ruby/system/DirectoryMemory.cc c7302d55d644 
  src/mem/ruby/system/DirectoryMemory.py c7302d55d644 
  src/mem/ruby/system/RubyPort.hh c7302d55d644 
  src/mem/ruby/system/RubyPort.cc c7302d55d644 
  src/mem/ruby/system/RubySystem.py c7302d55d644 
  src/mem/ruby/system/SConscript c7302d55d644 
  src/mem/ruby/system/Sequencer.cc c7302d55d644 
  src/mem/ruby/system/Sequencer.py c7302d55d644 
  src/mem/ruby/system/System.hh c7302d55d644 
  src/mem/ruby/system/System.cc c7302d55d644 

Diff: http://reviews.m5sim.org/r/611/diff


Testing
---


Thanks,

Nilay

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


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

2011-03-31 Thread Brad Beckmann

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


This looks great, I just have a few minor suggestions below.

It seems like the next step is to figure out how to deal with functional 
accesses not succeeding in the CPUs and devices.


src/mem/ruby/system/RubyPort.cc
http://reviews.m5sim.org/r/611/#comment1438

Please add comments to this function explaining what is going on here.



src/mem/ruby/system/RubyPort.cc
http://reviews.m5sim.org/r/611/#comment1439

It seems that the ro and rw counter checks should happen here, before doing 
any functional accesses.



src/mem/ruby/system/RubyPort.cc
http://reviews.m5sim.org/r/611/#comment1440

Try to avoid the duplicate code between here...



src/mem/ruby/system/RubyPort.cc
http://reviews.m5sim.org/r/611/#comment1441

...and here.



src/mem/ruby/system/RubyPort.cc
http://reviews.m5sim.org/r/611/#comment1442

Are functional packets put on the stack or the heap?  I seem to remember 
the former, but I could be wrong.


- Brad


On 2011-03-31 20:44:17, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/611/
 ---
 
 (Updated 2011-03-31 20:44:17)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Add support for functional accesses
 This patch is meant for aiding discussions on implementation of functional
 access support in Ruby.
 
 
 Diffs
 -
 
   configs/ruby/MESI_CMP_directory.py c7302d55d644 
   configs/ruby/Ruby.py c7302d55d644 
   src/mem/ruby/network/Network.cc c7302d55d644 
   src/mem/ruby/network/Network.py c7302d55d644 
   src/mem/ruby/profiler/Profiler.cc c7302d55d644 
   src/mem/ruby/profiler/Profiler.py c7302d55d644 
   src/mem/ruby/recorder/Tracer.cc c7302d55d644 
   src/mem/ruby/recorder/Tracer.py c7302d55d644 
   src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
   src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
   src/mem/ruby/system/Cache.py c7302d55d644 
   src/mem/ruby/system/CacheMemory.hh c7302d55d644 
   src/mem/ruby/system/CacheMemory.cc c7302d55d644 
   src/mem/ruby/system/DirectoryMemory.hh c7302d55d644 
   src/mem/ruby/system/DirectoryMemory.cc c7302d55d644 
   src/mem/ruby/system/DirectoryMemory.py c7302d55d644 
   src/mem/ruby/system/RubyPort.hh c7302d55d644 
   src/mem/ruby/system/RubyPort.cc c7302d55d644 
   src/mem/ruby/system/RubySystem.py c7302d55d644 
   src/mem/ruby/system/SConscript c7302d55d644 
   src/mem/ruby/system/Sequencer.cc c7302d55d644 
   src/mem/ruby/system/Sequencer.py c7302d55d644 
   src/mem/ruby/system/System.hh c7302d55d644 
   src/mem/ruby/system/System.cc c7302d55d644 
 
 Diff: http://reviews.m5sim.org/r/611/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Nilay
 


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


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

2011-03-30 Thread Nilay Vaish

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

(Updated 2011-03-30 16:19:26.551926)


Review request for Default.


Summary
---

Ruby: Add support for functional accesses
This patch is meant for aiding discussions on implementation of functional
access support in Ruby.


Diffs (updated)
-

  configs/ruby/MESI_CMP_directory.py d54b7775a6b0 
  configs/ruby/Ruby.py d54b7775a6b0 
  src/mem/ruby/network/Network.cc d54b7775a6b0 
  src/mem/ruby/network/Network.py d54b7775a6b0 
  src/mem/ruby/profiler/Profiler.cc d54b7775a6b0 
  src/mem/ruby/profiler/Profiler.py d54b7775a6b0 
  src/mem/ruby/recorder/Tracer.cc d54b7775a6b0 
  src/mem/ruby/recorder/Tracer.py d54b7775a6b0 
  src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
  src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
  src/mem/ruby/system/Cache.py d54b7775a6b0 
  src/mem/ruby/system/CacheMemory.hh d54b7775a6b0 
  src/mem/ruby/system/CacheMemory.cc d54b7775a6b0 
  src/mem/ruby/system/DirectoryMemory.hh d54b7775a6b0 
  src/mem/ruby/system/DirectoryMemory.cc d54b7775a6b0 
  src/mem/ruby/system/DirectoryMemory.py d54b7775a6b0 
  src/mem/ruby/system/RubyPort.hh d54b7775a6b0 
  src/mem/ruby/system/RubyPort.cc d54b7775a6b0 
  src/mem/ruby/system/RubySystem.py d54b7775a6b0 
  src/mem/ruby/system/SConscript d54b7775a6b0 
  src/mem/ruby/system/Sequencer.py d54b7775a6b0 
  src/mem/ruby/system/System.hh d54b7775a6b0 
  src/mem/ruby/system/System.cc d54b7775a6b0 

Diff: http://reviews.m5sim.org/r/611/diff


Testing
---


Thanks,

Nilay

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


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

2011-03-30 Thread Nilay Vaish

On Tue, 29 Mar 2011, Nilay Vaish wrote:

Brad, I have posted on the review board my current implementation for 
supporting functional accesses in Ruby. This is untested and is mainly meant 
for furthering the discussions. I have some questions for you --


1. How do we inform the other end of RubyPort's M5 Port about whether or not 
functional access was successful?


2. What's the role of directory memory in functional accesses?

3. If none of the caches have the block pertaining to the address of the 
access, then read accesses should be satisfied from the physical memory. 
Write accesses should always go to physical memory as well. How can physical 
memory be accessed from RubyPort?


--
Nilay




Brad, I have made some changes to the patch. I have updated it on the 
review board. I have added a call to sendFunctional() so as to send the 
response. I have also added call to sendFunctional() on the physical 
memory port of ruby port, so that the physical memory would also get 
updated.


You had mentioned that we would unhook M5 memory and use Ruby to supply 
the data. How do we do this? And the second question from the previous 
mail still remains unanswered.


Thanks
Nilay
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev


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

2011-03-30 Thread Beckmann, Brad
Hi Nilay,

Thanks for posting a new patch.  I will review it as soon as I can...hopefully 
tonight.

Brad

 -Original Message-
 From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org]
 On Behalf Of Nilay Vaish
 Sent: Wednesday, March 30, 2011 4:32 PM
 To: Default
 Subject: Re: [m5-dev] Review Request: Ruby: Add support for functional
 accesses
 
 On Tue, 29 Mar 2011, Nilay Vaish wrote:
 
  Brad, I have posted on the review board my current implementation for
  supporting functional accesses in Ruby. This is untested and is mainly
  meant for furthering the discussions. I have some questions for you --
 
  1. How do we inform the other end of RubyPort's M5 Port about whether
  or not functional access was successful?
 
  2. What's the role of directory memory in functional accesses?
 
  3. If none of the caches have the block pertaining to the address of
  the access, then read accesses should be satisfied from the physical
 memory.
  Write accesses should always go to physical memory as well. How can
  physical memory be accessed from RubyPort?
 
  --
  Nilay
 
 
 
 Brad, I have made some changes to the patch. I have updated it on the
 review board. I have added a call to sendFunctional() so as to send the
 response. I have also added call to sendFunctional() on the physical memory
 port of ruby port, so that the physical memory would also get updated.
 
 You had mentioned that we would unhook M5 memory and use Ruby to
 supply the data. How do we do this? And the second question from the
 previous mail still remains unanswered.
 
 Thanks
 Nilay
 ___
 m5-dev mailing list
 m5-dev@m5sim.org
 http://m5sim.org/mailman/listinfo/m5-dev


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


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

2011-03-29 Thread Nilay Vaish
Brad, I have posted on the review board my current implementation for 
supporting functional accesses in Ruby. This is untested and is mainly 
meant for furthering the discussions. I have some questions for you --


1. How do we inform the other end of RubyPort's M5 Port about whether or 
not functional access was successful?


2. What's the role of directory memory in functional accesses?

3. If none of the caches have the block pertaining to the address of the 
access, then read accesses should be satisfied from the physical memory. 
Write accesses should always go to physical memory as well. How can 
physical memory be accessed from RubyPort?


--
Nilay


On Tue, 29 Mar 2011, Nilay Vaish wrote:



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

Review request for Default.


Summary
---

Ruby: Add support for functional accesses
This patch is meant for aiding discussions on implementation of functional
access support in Ruby.



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