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

2011-06-13 Thread Brad Beckmann

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


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


configs/ruby/Ruby.py
http://reviews.m5sim.org/r/611/#comment1771

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



src/mem/protocol/MOESI_CMP_directory-dir.sm
http://reviews.m5sim.org/r/611/#comment1769

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



src/mem/protocol/MOESI_hammer-cache.sm
http://reviews.m5sim.org/r/611/#comment1770

Same here?  Why comment this out?



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

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



src/mem/ruby/system/AbstractMemory.py
http://reviews.m5sim.org/r/611/#comment1772

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



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

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



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

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


- Brad


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

Re: [gem5-dev] Review Request: Ruby: Correctly set access permissions for directory entries

2011-06-08 Thread Brad Beckmann

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

Ship it!


This looks fine to me.  I assume that if a controller doesn't include a 
setPermission or getPermission function, the compiler error message is the same 
as when a controller doesn't specify a getState function.  Correct?

- Brad


On 2011-06-06 14:45:22, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/684/
 ---
 
 (Updated 2011-06-06 14:45:22)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Correctly set access permissions for directory entries
 The access permissions for the directory entries are not being set correctly.
 This is because pointers are not used for handling directory entries.
 function. get and set functions for access permissions have been added to the
 Controller state machine. The changePermission() function provided by the
 AbstractEntry and AbstractCacheEntry classes has been exposed to SLICC
 code once again. The set_permission() functionality has been removed.
 
 NOTE: Each protocol will have to define these get and set functions in order
 to compile successfully.
 
 
 Diffs
 -
 
   src/mem/protocol/MESI_CMP_directory-L1cache.sm b9ba22cb23f2 
   src/mem/protocol/MESI_CMP_directory-L2cache.sm b9ba22cb23f2 
   src/mem/protocol/MESI_CMP_directory-dir.sm b9ba22cb23f2 
   src/mem/protocol/MESI_CMP_directory-dma.sm b9ba22cb23f2 
   src/mem/protocol/MI_example-cache.sm b9ba22cb23f2 
   src/mem/protocol/MI_example-dir.sm b9ba22cb23f2 
   src/mem/protocol/MI_example-dma.sm b9ba22cb23f2 
   src/mem/protocol/MOESI_CMP_directory-L1cache.sm b9ba22cb23f2 
   src/mem/protocol/MOESI_CMP_directory-L2cache.sm b9ba22cb23f2 
   src/mem/protocol/MOESI_CMP_directory-dir.sm b9ba22cb23f2 
   src/mem/protocol/MOESI_CMP_directory-dma.sm b9ba22cb23f2 
   src/mem/protocol/MOESI_CMP_token-L1cache.sm b9ba22cb23f2 
   src/mem/protocol/MOESI_CMP_token-L2cache.sm b9ba22cb23f2 
   src/mem/protocol/MOESI_CMP_token-dir.sm b9ba22cb23f2 
   src/mem/protocol/MOESI_CMP_token-dma.sm b9ba22cb23f2 
   src/mem/protocol/MOESI_hammer-cache.sm b9ba22cb23f2 
   src/mem/protocol/MOESI_hammer-dir.sm b9ba22cb23f2 
   src/mem/protocol/MOESI_hammer-dma.sm b9ba22cb23f2 
   src/mem/protocol/Network_test-cache.sm b9ba22cb23f2 
   src/mem/protocol/Network_test-dir.sm b9ba22cb23f2 
   src/mem/protocol/RubySlicc_Types.sm b9ba22cb23f2 
   src/mem/ruby/slicc_interface/AbstractController.hh b9ba22cb23f2 
   src/mem/slicc/ast/MethodCallExprAST.py b9ba22cb23f2 
   src/mem/slicc/symbols/StateMachine.py b9ba22cb23f2 
 
 Diff: http://reviews.m5sim.org/r/684/diff
 
 
 Testing
 ---
 
 Passes regression tests and 1 loads with ruby random tester.
 
 
 Thanks,
 
 Nilay
 


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


Re: [gem5-dev] Review Request: garnet: add network ptr to links

2011-05-30 Thread Brad Beckmann

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

Ship it!


- Brad


On 2011-05-23 18:37:49, Tushar Krishna wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/711/
 ---
 
 (Updated 2011-05-23 18:37:49)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, Nathan 
 Binkert, and Brad Beckmann.
 
 
 Summary
 ---
 
 garnet: added network ptr to links to be used by orion
 
 
 Diffs
 -
 
   src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 3f37cc5d25bc 
   src/mem/ruby/network/garnet/fixed-pipeline/NetworkLink_d.hh 3f37cc5d25bc 
   src/mem/ruby/network/orion/NetworkPower.cc 3f37cc5d25bc 
 
 Diff: http://reviews.m5sim.org/r/711/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Tushar
 


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


Re: [gem5-dev] Review Request: orion: bug fix in link power, and some reorg

2011-05-30 Thread Brad Beckmann

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

Ship it!


- Brad


On 2011-05-23 18:40:06, Tushar Krishna wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/712/
 ---
 
 (Updated 2011-05-23 18:40:06)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, Nathan 
 Binkert, and Brad Beckmann.
 
 
 Summary
 ---
 
 orion: bug fix in link power, and some reorg
 
 
 Diffs
 -
 
   src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 3f37cc5d25bc 
   src/mem/ruby/network/garnet/fixed-pipeline/Router_d.hh 3f37cc5d25bc 
   src/mem/ruby/network/orion/NetworkPower.cc 3f37cc5d25bc 
 
 Diff: http://reviews.m5sim.org/r/712/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Tushar
 


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


Re: [gem5-dev] Review Request: Ruby: Convert to M5 Stats

2011-05-30 Thread Brad Beckmann

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


I apologize it took me a while to review this code.  Overall, my major concern 
is that the patch removes some of the most valuable stats in Ruby.  Specific 
comments below:


src/mem/ruby/profiler/Profiler.hh
http://reviews.m5sim.org/r/704/#comment1754

Please, do not delete these stats.  These stats are very useful in 
discovering performance bottlenecks in protocols.  As far as those protocols 
checked into the tree, I believe the hammer protocol uses most, if not all of 
these stats.  The term wCC stands for with Cache Coherence and signifies 
those requests that require cache-to-cache transfers.



src/mem/ruby/profiler/Profiler.cc
http://reviews.m5sim.org/r/704/#comment1755

This code was used to monitor cache port and bank contention when Ruby 
modeled those resources.  I'm pretty sure that no current protocols enable the 
bank resource feature, but if the port resource is approximated by the number 
of transitions per cycle.  It is possible for that port resource to cause 
problems and this stat would catch it.  Thus I would like to keep these stats. 



src/mem/ruby/profiler/Profiler.cc
http://reviews.m5sim.org/r/704/#comment1756

Yes, Korey your last observation is exactly why those histograms are 
initialized with a fixed bin size.  It makes comparisons between different runs 
possible.  I assume you can do the same thing with M5 stats, correct?



src/mem/ruby/profiler/Profiler.cc
http://reviews.m5sim.org/r/704/#comment1757

Did you move this logic somewhere else, or did you determine that none of 
the checked in protocols use this function?



src/mem/ruby/profiler/Profiler.cc
http://reviews.m5sim.org/r/704/#comment1758

Please keep this funcitonality.  It is very useful to understand the 
behavior of the system.


- Brad


On 2011-05-16 15:06:16, Derek Hower wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/704/
 ---
 
 (Updated 2011-05-16 15:06:16)
 
 
 Review request for Default, Nathan Binkert, Korey Sewell, and Brad Beckmann.
 
 
 Summary
 ---
 
 This patch contains changes to convert Ruby's stat handling to the M5-style 
 Stat class. The ultimate goal is to remove Profiler entirely, though this 
 patch only represents a (significant) step towards that goal. Some stats 
 remain in the Profiler, notably those that do not have an obvious object to 
 hold them (like Address Profiler) or those that I'm not sure what they do 
 (e.g., *wCC*). Also, this patch does not contain a Garnet stats conversion 
 (though the simple network is converted).
 
 
 Diffs
 -
 
   src/mem/ruby/network/simple/SimpleNetwork.hh UNKNOWN 
   src/mem/ruby/network/simple/SimpleNetwork.cc UNKNOWN 
   src/mem/ruby/network/simple/Throttle.hh UNKNOWN 
   src/mem/ruby/network/simple/Throttle.cc UNKNOWN 
   src/mem/ruby/profiler/AddressProfiler.hh UNKNOWN 
   src/mem/ruby/profiler/AddressProfiler.cc UNKNOWN 
   src/mem/ruby/profiler/CacheProfiler.hh UNKNOWN 
   src/mem/ruby/profiler/CacheProfiler.cc UNKNOWN 
   src/mem/ruby/profiler/MemCntrlProfiler.hh UNKNOWN 
   src/mem/ruby/profiler/MemCntrlProfiler.cc UNKNOWN 
   src/mem/ruby/profiler/Profiler.hh UNKNOWN 
   src/mem/ruby/profiler/Profiler.cc UNKNOWN 
   src/mem/ruby/slicc_interface/RubySlicc_Profiler_interface.hh UNKNOWN 
   src/mem/ruby/slicc_interface/RubySlicc_Profiler_interface.cc UNKNOWN 
   src/mem/ruby/system/CacheMemory.hh UNKNOWN 
   src/mem/ruby/system/MemoryControl.hh UNKNOWN 
   src/mem/ruby/system/Sequencer.hh UNKNOWN 
   src/mem/ruby/system/Sequencer.cc UNKNOWN 
   src/mem/ruby/system/System.cc UNKNOWN 
   src/mem/slicc/symbols/StateMachine.py UNKNOWN 
 
 Diff: http://reviews.m5sim.org/r/704/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Derek
 


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


Re: [m5-dev] Review Request: slicc: added vnet_type field to identify response vnets from others

2011-05-10 Thread Brad Beckmann


 On 2011-05-09 16:58:52, Tushar Krishna wrote:
  Hey Brad,
  We will need some way for the total number of virtual networks declared in 
  these protocol files to be reflected in one of the network simobject.py 
  files, so that the config.ini file prints out the correct value for virtual 
  networks. Currently it prints out the default value of 10 from Network.py, 
  though the actual number of active vnets is lower.
  Just to let you know while you review this patch since the change for that 
  might be related ...
  
  Thanks

This is certainly the easiest way to provide this capability and I'm fine with 
checking it in.  However, as I mentioned to you yesterday, this is just a 
short-term solution until we figure out how to move these virtual channel 
details into the protocol python files.  


- Brad


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


On 2011-05-08 21:09:50, Tushar Krishna wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/686/
 ---
 
 (Updated 2011-05-08 21:09:50)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, Nathan 
 Binkert, and Brad Beckmann.
 
 
 Summary
 ---
 
 slicc: added vnet_type field to identify response vnets from others
 
 Identifying response vnets versus other vnets will allow garnet to
 determine which vnets will carry data packets, and which will carry
 ctrl packets, and use appropriate buffer sizes (since data packets are larger
 than ctrl packets). This in turn allows the orion power model to accurately
 estimate buffer power.
 
 
 Diffs
 -
 
   src/mem/protocol/MESI_CMP_directory-L1cache.sm db269e704d07 
   src/mem/protocol/MESI_CMP_directory-L2cache.sm db269e704d07 
   src/mem/protocol/MESI_CMP_directory-dir.sm db269e704d07 
   src/mem/protocol/MESI_CMP_directory-dma.sm db269e704d07 
   src/mem/protocol/MOESI_CMP_directory-L1cache.sm db269e704d07 
   src/mem/protocol/MOESI_CMP_directory-L2cache.sm db269e704d07 
   src/mem/protocol/MOESI_CMP_directory-dir.sm db269e704d07 
   src/mem/protocol/MOESI_CMP_directory-dma.sm db269e704d07 
   src/mem/protocol/MOESI_CMP_token-L1cache.sm db269e704d07 
   src/mem/protocol/MOESI_CMP_token-L2cache.sm db269e704d07 
   src/mem/protocol/MOESI_CMP_token-dir.sm db269e704d07 
   src/mem/protocol/MOESI_CMP_token-dma.sm db269e704d07 
   src/mem/protocol/MOESI_hammer-cache.sm db269e704d07 
   src/mem/protocol/MOESI_hammer-dir.sm db269e704d07 
   src/mem/protocol/MOESI_hammer-dma.sm db269e704d07 
   src/mem/protocol/Network_test-cache.sm db269e704d07 
   src/mem/protocol/Network_test-dir.sm db269e704d07 
   src/mem/ruby/network/Network.hh db269e704d07 
   src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.hh db269e704d07 
   src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc db269e704d07 
   src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.hh db269e704d07 
   src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc db269e704d07 
   src/mem/ruby/network/simple/SimpleNetwork.hh db269e704d07 
   src/mem/ruby/network/simple/SimpleNetwork.cc db269e704d07 
   src/mem/slicc/symbols/StateMachine.py db269e704d07 
 
 Diff: http://reviews.m5sim.org/r/686/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Tushar
 


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


Re: [m5-dev] Review Request: garnet: rename and rearrange config parameters

2011-05-10 Thread Brad Beckmann

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

Ship it!


Just when I was getting use to refering to virtual channels as message classes, 
you're changing the name back to vnets.  :)

This looks good to me.

- Brad


On 2011-05-08 23:08:23, Tushar Krishna wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/688/
 ---
 
 (Updated 2011-05-08 23:08:23)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, Nathan 
 Binkert, and Brad Beckmann.
 
 
 Summary
 ---
 
 garnet: rename and rearrange config parameters
 
 Renamed (message) class to vnet for consistency with rest of ruby.
 Moved some parameters specific to fixed/flexible garnet networks into their
 corresponding py files.
 
 
 Diffs
 -
 
   src/mem/ruby/network/garnet/BaseGarnetNetwork.hh db269e704d07 
   src/mem/ruby/network/garnet/BaseGarnetNetwork.cc db269e704d07 
   src/mem/ruby/network/garnet/BaseGarnetNetwork.py db269e704d07 
   src/mem/ruby/network/garnet/fixed-pipeline/GarnetLink_d.py db269e704d07 
   src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.hh db269e704d07 
   src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc db269e704d07 
   src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.py db269e704d07 
   src/mem/ruby/network/garnet/fixed-pipeline/GarnetRouter_d.py db269e704d07 
   src/mem/ruby/network/garnet/fixed-pipeline/NetworkInterface_d.cc 
 db269e704d07 
   src/mem/ruby/network/garnet/fixed-pipeline/NetworkLink_d.cc db269e704d07 
   src/mem/ruby/network/garnet/fixed-pipeline/Router_d.cc db269e704d07 
   src/mem/ruby/network/garnet/flexible-pipeline/GarnetLink.py db269e704d07 
   src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.hh db269e704d07 
   src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc db269e704d07 
   src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.py db269e704d07 
   src/mem/ruby/network/garnet/flexible-pipeline/GarnetRouter.py db269e704d07 
   src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.cc 
 db269e704d07 
   src/mem/ruby/network/garnet/flexible-pipeline/NetworkLink.cc db269e704d07 
   src/mem/ruby/network/garnet/flexible-pipeline/Router.cc db269e704d07 
 
 Diff: http://reviews.m5sim.org/r/688/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Tushar
 


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


Re: [m5-dev] Review Request: ruby-stats: support for dump_stats instruction

2011-05-04 Thread Brad Beckmann


 On 2011-05-03 17:45:41, Brad Beckmann wrote:
  Can we change the name of Time in base/time.hh instead of Time in Ruby?  
  Right now this patch touches 50+ Ruby files and a bunch of lines within 
  those files just to change Time to RTime.  It seems that far fewer changes 
  would be required to change the name of base/time.hh's version of Time.
 
 Nathan Binkert wrote:
 While I wouldn't be opposed to changing the time in base/time.hh if we 
 needed both, but don't we need to move ruby away from its own version of Time 
 anyway?  Shouldn't we be using Tick?
 
 Also, we've generally never shied away from changes that can be done with 
 a one line sed/perl script.
 
 Gabe Black wrote:
 I was about to say something along these lines. This would be a good 
 chance to consolidate Ruby and M5 systems a little. It might be a good idea 
 to do the simple find/replace change on its own so the non-simple 
 non-find/replace stuff doesn't get lost as noise. I don't have deep feelings 
 one way or the other, though.
 
 Korey Sewell wrote:
 This should be two diffs: 1 for rename and 1 for stat code. But since 
 they are related to getting dumpstats working I combined them both for the 
 sake of discussion.
 
 Time isnt equivalent Tick or I would've happily made that change :). 
 
 Time is really the Ruby Cycle count so if you change it to Tick then all 
 over the place you would have to convert to cycles when making comparisons 
 for request latencies and various parameters in Ruby. In the interim, maybe 
 changing Time to Cycle would work.
 
 Alternatively, you could change Time to Tick, and then force all the 
 latencies throughout Ruby to be expressed in Ticks. This would have the nice 
 effect of setting the latencies for Caches and memory objects with a real 
 time (e.g. 1ns) instead of relative time (e.g. 1 cycle).

Eventually, we absolutely need Ruby to move away from its own version of time 
and we are in the process to do just that.  Right now both Nilay and Somayeh 
are working on two pretty complicated and substantial changes that are on that 
path.  In particular, once Ruby supports functional accesses, then it can 
supply data directly to the CPUs.  Once Ruby data is functional memory, we can 
create cache warmup traces that include valid data.  Once we have a cache 
warmup methodology that includes data and works more seamlessly with 
unserialization, we can remove the Ruby event queue APIs.  Once we do that, we 
can get rid of Ruby's notion of time...As you can tell, this is a long process 
and we still have a ways to go, but that is the plan.

My hesitation with this patch is that it seems premature and it adds more 
rebase/merging work for those of us who have other patches under development 
that really need touch these same files and lines.

Overall, does this patch need to be checked in right now?  For instance, do we 
need it to move Ruby stats to M5 stats or will moving to M5 stats negate having 
to make this change?


- Brad


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


On 2011-05-03 11:20:58, Korey Sewell wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/675/
 ---
 
 (Updated 2011-05-03 11:20:58)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 ruby-stats: support for dump_stats instruction
 ***
 NOTE: The core changes for this diff are in Profiler.cc/hh, 
 stat_control.hh/cc, and pseudo_inst.cc
 
 This is a first pass toward getting dump-stats functionality to work 
 cleanly for Ruby. As is, the patch works, but there needs to be discussion 
 over:
 - Changing Ruby typedef Time to RTime because it conflicts with the Time 
 class defined in base/time.hh (The majority of files are renames)... Is there 
 a better name than RTime?
 
 - Where is the right place for this RubyStatEvent code? I hesitated to do any 
 real cosmetic changes because of what impending stat changes might do. I have 
 two thoughts:
 (1) If Ruby Stats will be registered like old M5 stats, then this code would 
 nicely fold into the old statEvent code in sim_control.cc. Fold into 
 maybe too strong of a phrase even, as most of it should just naturally work.
 (2) If Ruby Stats are not registered, then maybe placing this code into the 
 RubySystem class. I realized late that the Profiler and Network have two 
 different stats that they track so the RubySystem would be the right place 
 along with calling the namespace RubyStats.
 
 
 Diffs
 -
 
   SConstruct 3f49ed206f46 
   src/cpu/testers/rubytest/RubyTester.hh 3f49ed206f46 
   src/cpu/testers/rubytest

Re: [m5-dev] Review Request: ruby: use RubyMemory flag remove setDebug() functionality

2011-05-04 Thread Brad Beckmann

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

Ship it!


I'm surprised this wasn't fixed earlier.  Thanks for do this Korey!

- Brad


On 2011-05-03 22:24:46, Korey Sewell wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/676/
 ---
 
 (Updated 2011-05-03 22:24:46)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 ruby: use RubyMemory flag  remove setDebug() functionality
 The RubyMemory flag wasnt used in the code, creating large gaps in trace 
 output. Replace cprintfs w/dprintfs
 using RubyMemory in memory controller. DPRINTF also deprecate the usage of 
 the setDebug() pure virtual
 function in the AbstractMemoryOrCache Class as well the m_debug/cprintf 
 functions in MemoryControl.hh/cc
 
 
 Diffs
 -
 
   src/mem/ruby/system/AbstractMemOrCache.hh 3f49ed206f46 
   src/mem/ruby/system/MemoryControl.hh 3f49ed206f46 
   src/mem/ruby/system/MemoryControl.cc 3f49ed206f46 
 
 Diff: http://reviews.m5sim.org/r/676/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Korey
 


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


Re: [m5-dev] Review Request: ruby-stats: support for dump_stats instruction

2011-05-04 Thread Brad Beckmann


 On 2011-05-03 17:45:41, Brad Beckmann wrote:
  Can we change the name of Time in base/time.hh instead of Time in Ruby?  
  Right now this patch touches 50+ Ruby files and a bunch of lines within 
  those files just to change Time to RTime.  It seems that far fewer changes 
  would be required to change the name of base/time.hh's version of Time.
 
 Nathan Binkert wrote:
 While I wouldn't be opposed to changing the time in base/time.hh if we 
 needed both, but don't we need to move ruby away from its own version of Time 
 anyway?  Shouldn't we be using Tick?
 
 Also, we've generally never shied away from changes that can be done with 
 a one line sed/perl script.
 
 Gabe Black wrote:
 I was about to say something along these lines. This would be a good 
 chance to consolidate Ruby and M5 systems a little. It might be a good idea 
 to do the simple find/replace change on its own so the non-simple 
 non-find/replace stuff doesn't get lost as noise. I don't have deep feelings 
 one way or the other, though.
 
 Korey Sewell wrote:
 This should be two diffs: 1 for rename and 1 for stat code. But since 
 they are related to getting dumpstats working I combined them both for the 
 sake of discussion.
 
 Time isnt equivalent Tick or I would've happily made that change :). 
 
 Time is really the Ruby Cycle count so if you change it to Tick then all 
 over the place you would have to convert to cycles when making comparisons 
 for request latencies and various parameters in Ruby. In the interim, maybe 
 changing Time to Cycle would work.
 
 Alternatively, you could change Time to Tick, and then force all the 
 latencies throughout Ruby to be expressed in Ticks. This would have the nice 
 effect of setting the latencies for Caches and memory objects with a real 
 time (e.g. 1ns) instead of relative time (e.g. 1 cycle).
 
 Brad Beckmann wrote:
 Eventually, we absolutely need Ruby to move away from its own version of 
 time and we are in the process to do just that.  Right now both Nilay and 
 Somayeh are working on two pretty complicated and substantial changes that 
 are on that path.  In particular, once Ruby supports functional accesses, 
 then it can supply data directly to the CPUs.  Once Ruby data is functional 
 memory, we can create cache warmup traces that include valid data.  Once we 
 have a cache warmup methodology that includes data and works more seamlessly 
 with unserialization, we can remove the Ruby event queue APIs.  Once we do 
 that, we can get rid of Ruby's notion of time...As you can tell, this is a 
 long process and we still have a ways to go, but that is the plan.
 
 My hesitation with this patch is that it seems premature and it adds more 
 rebase/merging work for those of us who have other patches under development 
 that really need touch these same files and lines.
 
 Overall, does this patch need to be checked in right now?  For instance, 
 do we need it to move Ruby stats to M5 stats or will moving to M5 stats 
 negate having to make this change?

 
 Nathan Binkert wrote:
 Seems like a reasonable objection.  I've generally had success with 
 running the search/replace routines directly on my patches when this sort of 
 change happens, but if that doesn't work, then I wouldn't be opposed to 
 renaming Time to TimeOfDay or RealTime or something like that.  I would like 
 to make sure that Korey can continue working.

Agreed.  If not making this change prevents Korey from making progress, then we 
need to come up with a solution.

So I would be interested to understand if this change is needed to do the stats 
transition?  Also I would be interested to hear Derek's opinion on this change, 
assuming he's had a chance to look further into the stats transition.


- Brad


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


On 2011-05-03 11:20:58, Korey Sewell wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/675/
 ---
 
 (Updated 2011-05-03 11:20:58)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 ruby-stats: support for dump_stats instruction
 ***
 NOTE: The core changes for this diff are in Profiler.cc/hh, 
 stat_control.hh/cc, and pseudo_inst.cc
 
 This is a first pass toward getting dump-stats functionality to work 
 cleanly for Ruby. As is, the patch works, but there needs to be discussion 
 over:
 - Changing Ruby typedef Time to RTime because it conflicts with the Time 
 class defined in base/time.hh (The majority of files are renames)... Is there 
 a better name than RTime?
 
 - Where is the right place

Re: [m5-dev] Review Request: network: added Torus and Pt2Pt topologies

2011-05-03 Thread Brad Beckmann

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

Ship it!


Overall, this looks good to me.  One thing you may consider is giving the 
wrap-around links a higher latency.


src/mem/ruby/network/topologies/Torus.py
http://reviews.m5sim.org/r/667/#comment1648

Should we give the wrap-around links a higher latency?  



src/mem/ruby/network/topologies/Torus.py
http://reviews.m5sim.org/r/667/#comment1649

Same here, higher latency?


- Brad


On 2011-04-29 15:58:51, Tushar Krishna wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/667/
 ---
 
 (Updated 2011-04-29 15:58:51)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, Nathan 
 Binkert, and Brad Beckmann.
 
 
 Summary
 ---
 
 network: added Torus and Pt2Pt topologies
 
 
 Diffs
 -
 
   src/mem/ruby/network/topologies/Pt2Pt.py PRE-CREATION 
   src/mem/ruby/network/topologies/SConscript 7939dd0c4ff2 
   src/mem/ruby/network/topologies/Torus.py PRE-CREATION 
 
 Diff: http://reviews.m5sim.org/r/667/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Tushar
 


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


Re: [m5-dev] Review Request: NetworkTest: added sim_cycles parameter to the network tester.

2011-05-03 Thread Brad Beckmann


 On 2011-04-29 15:27:14, Tushar Krishna wrote:
  src/cpu/testers/networktest/networktest.cc, line 213
  http://reviews.m5sim.org/r/660/diff/1/?file=12042#file12042line213
 
  Hey Brad,
  One concern that I have with my current implementation here is that if 
  --fixed-pkts is enabled, then the tester is not scheduled after injecting 
  maxPackets. 
  Once all packets are delivered (= no more events from the network side 
  as well), there is no agent to call exitSimLoop to end the simulation, so 
  it ends at m5's max tick (9223372036854775807) cycles. This does not slow 
  down the simulation (since there are no events after all delivery), and is 
  ok. But it does screw up the power stats etc which use Ruby_cycles, and 
  sort of looks ugly since m5 prints out that the simulation ended after 
  9223372036854775807 cycles.
  
  One option is to end the simulation as soon as the tester injects 
  maxPackets, but that wont result in all packets getting delivered, 
  defeating the purpose of fixed-pkts which I added for network debugging.
  
  The other option is to keep scheduling the tester till simCycles, but 
  simply stopping the generation of packets after maxPackets (this was what I 
  was doing earlier). But this requires the simCycles input to be greater 
  than the time by which all packets are expected to be injected (which 
  depends upon maxPackets and injection rate).
  
  [Unlike the ruby random tester, the tester here does not track anything 
  to determine when everything is delivered].
  
  Any suggestions?
  
  Thanks,
  Tushar

I don't think there is an easy way to support the fixed-pkts option based on 
the current NetworkTest implementation.  Ending the simulation as soon as the 
tester injects maxPackets seems likek the only reasonable thing to do.  Unless 
we can remove the fixed-pkts option all together.  The other options seem like 
brittle hacks.

If you want to spend a bit more time on it, I suspect we could provide the 
directory a pointer to the NetworkTest object and have the directory call say a 
NetworkTest.finish() function.


- Brad


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


On 2011-04-25 16:18:04, Tushar Krishna wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/660/
 ---
 
 (Updated 2011-04-25 16:18:04)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, Nathan 
 Binkert, and Brad Beckmann.
 
 
 Summary
 ---
 
 NetworkTest: added sim_cycles parameter to the network tester.
 
 The network tester terminates after injecting for sim_cycles
 (default=1000), instead of having to explicitly pass --maxtick from the
 command line as before. If fixed_pkts is enabled, the tester stops
 scheduling itself after injecting maxpackets number of packets.
 The tester also works with zero command line arguments now.
 
 
 Diffs
 -
 
   configs/example/ruby_network_test.py de679a068dd8 
   src/cpu/testers/networktest/NetworkTest.py de679a068dd8 
   src/cpu/testers/networktest/networktest.hh de679a068dd8 
   src/cpu/testers/networktest/networktest.cc de679a068dd8 
 
 Diff: http://reviews.m5sim.org/r/660/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Tushar
 


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


Re: [m5-dev] Review Request: ruby-stats: support for dump_stats instruction

2011-05-03 Thread Brad Beckmann

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


Can we change the name of Time in base/time.hh instead of Time in Ruby?  Right 
now this patch touches 50+ Ruby files and a bunch of lines within those files 
just to change Time to RTime.  It seems that far fewer changes would be 
required to change the name of base/time.hh's version of Time.


src/mem/ruby/profiler/Profiler.cc
http://reviews.m5sim.org/r/675/#comment1651

Why do you have to create a separate namespace here?



src/mem/ruby/system/System.hh
http://reviews.m5sim.org/r/675/#comment1652

Why does this need to be static?  I think we want to avoid making it more 
difficult to run Ruby in a multiple system scenario.



src/sim/pseudo_inst.cc
http://reviews.m5sim.org/r/675/#comment1653

Why is the RUBY compile flag necessary?


- Brad


On 2011-05-03 11:20:58, Korey Sewell wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/675/
 ---
 
 (Updated 2011-05-03 11:20:58)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 ruby-stats: support for dump_stats instruction
 ***
 NOTE: The core changes for this diff are in Profiler.cc/hh, 
 stat_control.hh/cc, and pseudo_inst.cc
 
 This is a first pass toward getting dump-stats functionality to work 
 cleanly for Ruby. As is, the patch works, but there needs to be discussion 
 over:
 - Changing Ruby typedef Time to RTime because it conflicts with the Time 
 class defined in base/time.hh (The majority of files are renames)... Is there 
 a better name than RTime?
 
 - Where is the right place for this RubyStatEvent code? I hesitated to do any 
 real cosmetic changes because of what impending stat changes might do. I have 
 two thoughts:
 (1) If Ruby Stats will be registered like old M5 stats, then this code would 
 nicely fold into the old statEvent code in sim_control.cc. Fold into 
 maybe too strong of a phrase even, as most of it should just naturally work.
 (2) If Ruby Stats are not registered, then maybe placing this code into the 
 RubySystem class. I realized late that the Profiler and Network have two 
 different stats that they track so the RubySystem would be the right place 
 along with calling the namespace RubyStats.
 
 
 Diffs
 -
 
   SConstruct 3f49ed206f46 
   src/cpu/testers/rubytest/RubyTester.hh 3f49ed206f46 
   src/cpu/testers/rubytest/RubyTester.cc 3f49ed206f46 
   src/mem/ruby/buffers/MessageBuffer.hh 3f49ed206f46 
   src/mem/ruby/buffers/MessageBuffer.cc 3f49ed206f46 
   src/mem/ruby/buffers/MessageBufferNode.hh 3f49ed206f46 
   src/mem/ruby/common/Consumer.hh 3f49ed206f46 
   src/mem/ruby/common/Global.hh 3f49ed206f46 
   src/mem/ruby/common/TypeDefines.hh 3f49ed206f46 
   src/mem/ruby/eventqueue/RubyEventQueue.hh 3f49ed206f46 
   src/mem/ruby/eventqueue/RubyEventQueue.cc 3f49ed206f46 
   src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.hh 3f49ed206f46 
   src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 3f49ed206f46 
   src/mem/ruby/network/garnet/fixed-pipeline/InputUnit_d.hh 3f49ed206f46 
   src/mem/ruby/network/garnet/fixed-pipeline/NetworkInterface_d.hh 
 3f49ed206f46 
   src/mem/ruby/network/garnet/fixed-pipeline/OutVcState_d.hh 3f49ed206f46 
   src/mem/ruby/network/garnet/fixed-pipeline/VirtualChannel_d.hh 3f49ed206f46 
   src/mem/ruby/network/garnet/fixed-pipeline/flit_d.hh 3f49ed206f46 
   src/mem/ruby/network/garnet/flexible-pipeline/FlexibleConsumer.hh 
 3f49ed206f46 
   src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.hh 3f49ed206f46 
   src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc 3f49ed206f46 
   src/mem/ruby/network/garnet/flexible-pipeline/InVcState.hh 3f49ed206f46 
   src/mem/ruby/network/garnet/flexible-pipeline/InVcState.cc 3f49ed206f46 
   src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.hh 
 3f49ed206f46 
   src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.cc 
 3f49ed206f46 
   src/mem/ruby/network/garnet/flexible-pipeline/NetworkLink.hh 3f49ed206f46 
   src/mem/ruby/network/garnet/flexible-pipeline/NetworkLink.cc 3f49ed206f46 
   src/mem/ruby/network/garnet/flexible-pipeline/OutVcState.hh 3f49ed206f46 
   src/mem/ruby/network/garnet/flexible-pipeline/OutVcState.cc 3f49ed206f46 
   src/mem/ruby/network/garnet/flexible-pipeline/Router.hh 3f49ed206f46 
   src/mem/ruby/network/garnet/flexible-pipeline/Router.cc 3f49ed206f46 
   src/mem/ruby/network/garnet/flexible-pipeline/flit.hh 3f49ed206f46 
   src/mem/ruby/network/garnet/flexible-pipeline/flit.cc 3f49ed206f46 
   src/mem/ruby/network/simple/Throttle.hh 3f49ed206f46 
   src/mem/ruby/profiler/Profiler.hh 3f49ed206f46 
 

[m5-dev] changeset in m5: network: basic link bw for garnet and simple ne...

2011-04-28 Thread Brad Beckmann
changeset 7c377f5162f8 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=7c377f5162f8
description:
network: basic link bw for garnet and simple networks

This patch ensures that both Garnet and the simple networks use the bw 
value
specified in the topology.  To do so, the patch generalizes the 
specification
of bw for basic links.  This value is then translated to the specific 
value
used by the simple and Garnet networks.  Since Garent does not support
non-uniformed link bandwidth, the patch also adds a check to ensure all 
bws are
equal.

diffstat:

 configs/ruby/Ruby.py  |   4 +-
 src/mem/ruby/network/BasicLink.cc |   2 +-
 src/mem/ruby/network/BasicLink.hh |   2 +-
 src/mem/ruby/network/BasicLink.py |  10 +-
 src/mem/ruby/network/garnet/BaseGarnetNetwork.cc  |  23 ++-
 src/mem/ruby/network/garnet/BaseGarnetNetwork.hh  |   4 +-
 src/mem/ruby/network/garnet/BaseGarnetNetwork.py  |   2 +-
 src/mem/ruby/network/garnet/fixed-pipeline/GarnetLink_d.py|   3 +-
 src/mem/ruby/network/garnet/fixed-pipeline/GarnetRouter_d.py  |   2 +-
 src/mem/ruby/network/garnet/fixed-pipeline/NetworkInterface_d.cc  |   2 +-
 src/mem/ruby/network/garnet/flexible-pipeline/GarnetLink.py   |   3 +-
 src/mem/ruby/network/garnet/flexible-pipeline/GarnetRouter.py |   2 +-
 src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.cc |   2 +-
 src/mem/ruby/network/simple/SConscript|   2 +
 src/mem/ruby/network/simple/SimpleLink.cc |  73 

 src/mem/ruby/network/simple/SimpleLink.hh |  82 
++
 src/mem/ruby/network/simple/SimpleLink.py |  39 
 src/mem/ruby/network/simple/SimpleNetwork.cc  |  13 +-
 18 files changed, 249 insertions(+), 21 deletions(-)

diffs (truncated from 474 to 300 lines):

diff -r 7226aebb77b4 -r 7c377f5162f8 configs/ruby/Ruby.py
--- a/configs/ruby/Ruby.py  Thu Apr 28 17:18:14 2011 -0700
+++ b/configs/ruby/Ruby.py  Thu Apr 28 17:18:14 2011 -0700
@@ -87,8 +87,8 @@
 class RouterClass(GarnetRouter): pass
 else:
 class NetworkClass(SimpleNetwork): pass
-class IntLinkClass(BasicIntLink): pass
-class ExtLinkClass(BasicExtLink): pass
+class IntLinkClass(SimpleIntLink): pass
+class ExtLinkClass(SimpleExtLink): pass
 class RouterClass(BasicRouter): pass
 
 #
diff -r 7226aebb77b4 -r 7c377f5162f8 src/mem/ruby/network/BasicLink.cc
--- a/src/mem/ruby/network/BasicLink.cc Thu Apr 28 17:18:14 2011 -0700
+++ b/src/mem/ruby/network/BasicLink.cc Thu Apr 28 17:18:14 2011 -0700
@@ -32,7 +32,7 @@
 : SimObject(p)
 {
 m_latency = p-latency;
-m_bw_multiplier = p-bw_multiplier;
+m_bandwidth_factor = p-bandwidth_factor;
 m_weight = p-weight;
 }
 
diff -r 7226aebb77b4 -r 7c377f5162f8 src/mem/ruby/network/BasicLink.hh
--- a/src/mem/ruby/network/BasicLink.hh Thu Apr 28 17:18:14 2011 -0700
+++ b/src/mem/ruby/network/BasicLink.hh Thu Apr 28 17:18:14 2011 -0700
@@ -53,7 +53,7 @@
 void print(std::ostream out) const;
 
 int m_latency;
-int m_bw_multiplier;
+int m_bandwidth_factor;
 int m_weight;
 };
 
diff -r 7226aebb77b4 -r 7c377f5162f8 src/mem/ruby/network/BasicLink.py
--- a/src/mem/ruby/network/BasicLink.py Thu Apr 28 17:18:14 2011 -0700
+++ b/src/mem/ruby/network/BasicLink.py Thu Apr 28 17:18:14 2011 -0700
@@ -34,17 +34,21 @@
 type = 'BasicLink'
 link_id = Param.Int(ID in relation to other links)
 latency = Param.Int(1, latency)
-bw_multiplier = Param.Int(simple network bw constant, usually in bytes)
+# The following banwidth factor does not translate to the same value for
+# both the simple and Garnet models.  For the most part, the bandwidth
+# factor is the width of the link in bytes, expect for certain situations
+# with regard to the simple network.
+bandwidth_factor = Param.Int(generic bandwidth factor, usually in bytes)
 weight = Param.Int(1, used to restrict routing in shortest path analysis)
 
 class BasicExtLink(BasicLink):
 type = 'BasicExtLink'
 ext_node = Param.RubyController(External node)
 int_node = Param.BasicRouter(ID of internal node)
-bw_multiplier = 64
+bandwidth_factor = 64
 
 class BasicIntLink(BasicLink):
 type = 'BasicIntLink'
 node_a = Param.BasicRouter(Router on one end)
 node_b = Param.BasicRouter(Router on other end)
-bw_multiplier = 16
+bandwidth_factor = 16
diff -r 7226aebb77b4 -r 7c377f5162f8 
src/mem/ruby/network/garnet/BaseGarnetNetwork.cc
--- a/src/mem/ruby/network/garnet/BaseGarnetNetwork.cc  Thu Apr 28 17:18:14 
2011 -0700
+++ b/src/mem/ruby/network/garnet/BaseGarnetNetwork.cc  Thu Apr 28 17:18:14 

[m5-dev] changeset in m5: network: removed the unused network-wide latenc...

2011-04-28 Thread Brad Beckmann
changeset f113f73dd494 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=f113f73dd494
description:
network: removed the unused network-wide latency param

diffstat:

 src/mem/ruby/network/Network.cc |  1 -
 src/mem/ruby/network/Network.hh |  2 --
 src/mem/ruby/network/Network.py |  2 --
 3 files changed, 0 insertions(+), 5 deletions(-)

diffs (40 lines):

diff -r 36987780169e -r f113f73dd494 src/mem/ruby/network/Network.cc
--- a/src/mem/ruby/network/Network.cc   Thu Apr 28 17:18:14 2011 -0700
+++ b/src/mem/ruby/network/Network.cc   Thu Apr 28 17:18:14 2011 -0700
@@ -36,7 +36,6 @@
 {
 m_virtual_networks = p-number_of_virtual_networks;
 m_topology_ptr = p-topology;
-m_link_latency = p-link_latency;
 m_control_msg_size = p-control_msg_size;
 
 // Total nodes/controllers in network
diff -r 36987780169e -r f113f73dd494 src/mem/ruby/network/Network.hh
--- a/src/mem/ruby/network/Network.hh   Thu Apr 28 17:18:14 2011 -0700
+++ b/src/mem/ruby/network/Network.hh   Thu Apr 28 17:18:14 2011 -0700
@@ -67,7 +67,6 @@
 virtual void init();
 
 int getNumberOfVirtualNetworks() { return m_virtual_networks; }
-int getLinkLatency() { return m_link_latency; }
 int MessageSizeType_to_int(MessageSizeType size_type);
 
 // returns the queue requested for the given component
@@ -108,7 +107,6 @@
 int m_nodes;
 int m_virtual_networks;
 Topology* m_topology_ptr;
-int m_link_latency;
 int m_control_msg_size;
 int m_data_msg_size;
 };
diff -r 36987780169e -r f113f73dd494 src/mem/ruby/network/Network.py
--- a/src/mem/ruby/network/Network.py   Thu Apr 28 17:18:14 2011 -0700
+++ b/src/mem/ruby/network/Network.py   Thu Apr 28 17:18:14 2011 -0700
@@ -47,6 +47,4 @@
 abstract = True
 number_of_virtual_networks = Param.Int(10, );
 topology = Param.Topology();
-link_latency = Param.Int(1,
-local memory latency ?? NetworkLinkLatency);
 control_msg_size = Param.Int(8, );
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev


[m5-dev] changeset in m5: network: adjusted default endpoint bandwidth

2011-04-28 Thread Brad Beckmann
changeset 39e42ccddd63 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=39e42ccddd63
description:
network: adjusted default endpoint bandwidth

The simple network's endpoint bandwidth value is used to adjust the 
overall
bandwidth of the network.  Specifically, the ration between endpoint 
bandwidth
and the MESSAGE_SIZE_MULTIPLIER determines the increase.  By setting 
the value
to 1000, that means the bandwdith factor specified in the links 
translates to
the link bandwidth in bytes.  Previously, it was increasing that value 
by 10.

This patch will likely require a reset of the ruby regression tester 
stats.

diffstat:

 src/mem/ruby/network/simple/SimpleNetwork.py |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diffs (10 lines):

diff -r f113f73dd494 -r 39e42ccddd63 
src/mem/ruby/network/simple/SimpleNetwork.py
--- a/src/mem/ruby/network/simple/SimpleNetwork.py  Thu Apr 28 17:18:14 
2011 -0700
+++ b/src/mem/ruby/network/simple/SimpleNetwork.py  Thu Apr 28 17:18:14 
2011 -0700
@@ -34,5 +34,5 @@
 type = 'SimpleNetwork'
 buffer_size = Param.Int(0,
 default buffer size; 0 indicates infinite buffering);
-endpoint_bandwidth = Param.Int(1, );
+endpoint_bandwidth = Param.Int(1000, bandwidth adjustment factor);
 adaptive_routing = Param.Bool(False, enable adaptive routing);
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev


[m5-dev] changeset in m5: garnet: removed flit_width from Routers

2011-04-28 Thread Brad Beckmann
changeset 89d0e7c17d1e in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=89d0e7c17d1e
description:
garnet: removed flit_width from Routers

diffstat:

 src/mem/ruby/network/garnet/fixed-pipeline/GarnetRouter_d.py  |  1 -
 src/mem/ruby/network/garnet/fixed-pipeline/Router_d.cc|  1 -
 src/mem/ruby/network/garnet/fixed-pipeline/Router_d.hh|  1 -
 src/mem/ruby/network/garnet/flexible-pipeline/GarnetRouter.py |  1 -
 src/mem/ruby/network/orion/NetworkPower.cc|  3 ++-
 5 files changed, 2 insertions(+), 5 deletions(-)

diffs (55 lines):

diff -r 39e42ccddd63 -r 89d0e7c17d1e 
src/mem/ruby/network/garnet/fixed-pipeline/GarnetRouter_d.py
--- a/src/mem/ruby/network/garnet/fixed-pipeline/GarnetRouter_d.py  Thu Apr 
28 17:18:14 2011 -0700
+++ b/src/mem/ruby/network/garnet/fixed-pipeline/GarnetRouter_d.py  Thu Apr 
28 17:18:14 2011 -0700
@@ -39,6 +39,5 @@
   virtual channels per message class)
 virt_nets = Param.Int(Parent.number_of_virtual_networks,
   number of virtual networks)
-flit_width = Param.Int(Parent.ni_flit_size, flit width == flit size)
 
 
diff -r 39e42ccddd63 -r 89d0e7c17d1e 
src/mem/ruby/network/garnet/fixed-pipeline/Router_d.cc
--- a/src/mem/ruby/network/garnet/fixed-pipeline/Router_d.ccThu Apr 28 
17:18:14 2011 -0700
+++ b/src/mem/ruby/network/garnet/fixed-pipeline/Router_d.ccThu Apr 28 
17:18:14 2011 -0700
@@ -49,7 +49,6 @@
 m_virtual_networks = p-virt_nets;
 m_vc_per_vnet = p-vcs_per_class;
 m_num_vcs = m_virtual_networks * m_vc_per_vnet;
-m_flit_width = p-flit_width;
 
 m_routing_unit = new RoutingUnit_d(this);
 m_vc_alloc = new VCallocator_d(this);
diff -r 39e42ccddd63 -r 89d0e7c17d1e 
src/mem/ruby/network/garnet/fixed-pipeline/Router_d.hh
--- a/src/mem/ruby/network/garnet/fixed-pipeline/Router_d.hhThu Apr 28 
17:18:14 2011 -0700
+++ b/src/mem/ruby/network/garnet/fixed-pipeline/Router_d.hhThu Apr 28 
17:18:14 2011 -0700
@@ -96,7 +96,6 @@
   private:
 int m_virtual_networks, m_num_vcs, m_vc_per_vnet;
 GarnetNetwork_d *m_network_ptr;
-int m_flit_width;
 
 std::vectordouble buf_read_count;
 std::vectordouble buf_write_count;
diff -r 39e42ccddd63 -r 89d0e7c17d1e 
src/mem/ruby/network/garnet/flexible-pipeline/GarnetRouter.py
--- a/src/mem/ruby/network/garnet/flexible-pipeline/GarnetRouter.py Thu Apr 
28 17:18:14 2011 -0700
+++ b/src/mem/ruby/network/garnet/flexible-pipeline/GarnetRouter.py Thu Apr 
28 17:18:14 2011 -0700
@@ -39,6 +39,5 @@
   virtual channels per message class)
 virt_nets = Param.Int(Parent.number_of_virtual_networks,
   number of virtual networks)
-flit_width = Param.Int(Parent.ni_flit_size, flit width == flit size)
 
 
diff -r 39e42ccddd63 -r 89d0e7c17d1e src/mem/ruby/network/orion/NetworkPower.cc
--- a/src/mem/ruby/network/orion/NetworkPower.ccThu Apr 28 17:18:14 
2011 -0700
+++ b/src/mem/ruby/network/orion/NetworkPower.ccThu Apr 28 17:18:14 
2011 -0700
@@ -96,7 +96,8 @@
 uint32_t num_vc_per_vclass = m_vc_per_vnet;
 uint32_t in_buf_per_data_vc = m_network_ptr-getBuffersPerDataVC();
 uint32_t in_buf_per_ctrl_vc = m_network_ptr-getBuffersPerCtrlVC();
-uint32_t flit_width = m_flit_width * 8; //flit width in bits
+//flit width in bits
+uint32_t flit_width = m_network_ptr-getNiFlitSize() * 8; 
 
 orion_rtr_ptr = new OrionRouter(
 num_in_port,
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev


Re: [m5-dev] Review Request: network: convert links switches to first class C++ SimObjects

2011-04-27 Thread Brad Beckmann

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

(Updated 2011-04-27 10:32:08.616217)


Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

network: convert links  switches to first class C++ SimObjects

This patch converts links and switches from second class simobjects that were
virtually ignored by the networks (both simple and Garnet) to first class
simobjects that directly correspond to c++ ojbects manipulated by the
topology and network classes.  This is especially true for Garnet, where the
links and switches directly correspond to specific C++ objects.

By making this change, many aspects of the Topology class were simplified.


Diffs (updated)
-

  configs/ruby/MESI_CMP_directory.py b02bca5aed04 
  configs/ruby/MI_example.py b02bca5aed04 
  configs/ruby/MOESI_CMP_directory.py b02bca5aed04 
  configs/ruby/MOESI_CMP_token.py b02bca5aed04 
  configs/ruby/MOESI_hammer.py b02bca5aed04 
  configs/ruby/Network_test.py b02bca5aed04 
  configs/ruby/Ruby.py b02bca5aed04 
  src/mem/protocol/RubySlicc_Exports.sm b02bca5aed04 
  src/mem/ruby/network/BasicLink.hh PRE-CREATION 
  src/mem/ruby/network/BasicLink.cc PRE-CREATION 
  src/mem/ruby/network/BasicLink.py PRE-CREATION 
  src/mem/ruby/network/BasicRouter.hh PRE-CREATION 
  src/mem/ruby/network/BasicRouter.cc PRE-CREATION 
  src/mem/ruby/network/BasicRouter.py PRE-CREATION 
  src/mem/ruby/network/Network.hh b02bca5aed04 
  src/mem/ruby/network/Network.py b02bca5aed04 
  src/mem/ruby/network/SConscript b02bca5aed04 
  src/mem/ruby/network/Topology.hh PRE-CREATION 
  src/mem/ruby/network/Topology.cc PRE-CREATION 
  src/mem/ruby/network/garnet/fixed-pipeline/CreditLink_d.hh b02bca5aed04 
  src/mem/ruby/network/garnet/fixed-pipeline/GarnetLink_d.hh PRE-CREATION 
  src/mem/ruby/network/garnet/fixed-pipeline/GarnetLink_d.cc PRE-CREATION 
  src/mem/ruby/network/garnet/fixed-pipeline/GarnetLink_d.py PRE-CREATION 
  src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.hh b02bca5aed04 
  src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc b02bca5aed04 
  src/mem/ruby/network/garnet/fixed-pipeline/GarnetRouter_d.py PRE-CREATION 
  src/mem/ruby/network/garnet/fixed-pipeline/NetworkLink_d.hh b02bca5aed04 
  src/mem/ruby/network/garnet/fixed-pipeline/NetworkLink_d.cc b02bca5aed04 
  src/mem/ruby/network/garnet/fixed-pipeline/Router_d.hh b02bca5aed04 
  src/mem/ruby/network/garnet/fixed-pipeline/Router_d.cc b02bca5aed04 
  src/mem/ruby/network/garnet/fixed-pipeline/SConscript b02bca5aed04 
  src/mem/ruby/network/garnet/flexible-pipeline/GarnetLink.hh PRE-CREATION 
  src/mem/ruby/network/garnet/flexible-pipeline/GarnetLink.cc PRE-CREATION 
  src/mem/ruby/network/garnet/flexible-pipeline/GarnetLink.py PRE-CREATION 
  src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.hh b02bca5aed04 
  src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc b02bca5aed04 
  src/mem/ruby/network/garnet/flexible-pipeline/GarnetRouter.py PRE-CREATION 
  src/mem/ruby/network/garnet/flexible-pipeline/NetworkLink.hh b02bca5aed04 
  src/mem/ruby/network/garnet/flexible-pipeline/NetworkLink.cc b02bca5aed04 
  src/mem/ruby/network/garnet/flexible-pipeline/Router.hh b02bca5aed04 
  src/mem/ruby/network/garnet/flexible-pipeline/Router.cc b02bca5aed04 
  src/mem/ruby/network/garnet/flexible-pipeline/SConscript b02bca5aed04 
  src/mem/ruby/network/orion/NetworkPower.cc b02bca5aed04 
  src/mem/ruby/network/simple/SimpleNetwork.hh b02bca5aed04 
  src/mem/ruby/network/simple/SimpleNetwork.cc b02bca5aed04 
  src/mem/ruby/network/topologies/Crossbar.py b02bca5aed04 
  src/mem/ruby/network/topologies/Mesh.py b02bca5aed04 
  src/mem/ruby/network/topologies/MeshDirCorners.py b02bca5aed04 
  src/mem/ruby/slicc_interface/AbstractController.hh b02bca5aed04 
  src/mem/ruby/slicc_interface/Controller.py b02bca5aed04 

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


Testing
---


Thanks,

Brad

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


[m5-dev] Review Request: network: generalized bw for basic links

2011-04-27 Thread Brad Beckmann

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

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

network: generalized bw for basic links

Generalized the specification of bw for basic links.  This value is then
translated to the specific value used by the simple and Garnet networks.


Diffs
-

  configs/ruby/Ruby.py b02bca5aed04 
  src/mem/ruby/network/BasicLink.hh PRE-CREATION 
  src/mem/ruby/network/BasicLink.cc PRE-CREATION 
  src/mem/ruby/network/BasicLink.py PRE-CREATION 
  src/mem/ruby/network/garnet/fixed-pipeline/GarnetLink_d.py PRE-CREATION 
  src/mem/ruby/network/simple/SConscript b02bca5aed04 
  src/mem/ruby/network/simple/SimpleLink.hh PRE-CREATION 
  src/mem/ruby/network/simple/SimpleLink.cc PRE-CREATION 
  src/mem/ruby/network/simple/SimpleLink.py PRE-CREATION 
  src/mem/ruby/network/simple/SimpleNetwork.cc b02bca5aed04 

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


Testing
---


Thanks,

Brad

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


[m5-dev] Review Request: network: moved network config params

2011-04-27 Thread Brad Beckmann

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

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

network: moved network config params

Moved the buffer_size, endpoint_bandwidth, and adaptive_routing params out of
the top-level parent network object and to only those networks that actually
use those parameters.


Diffs
-

  src/mem/ruby/network/Network.hh b02bca5aed04 
  src/mem/ruby/network/Network.cc b02bca5aed04 
  src/mem/ruby/network/Network.py b02bca5aed04 
  src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.hh b02bca5aed04 
  src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc b02bca5aed04 
  src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.py b02bca5aed04 
  src/mem/ruby/network/simple/SimpleNetwork.hh b02bca5aed04 
  src/mem/ruby/network/simple/SimpleNetwork.cc b02bca5aed04 
  src/mem/ruby/network/simple/SimpleNetwork.py b02bca5aed04 
  src/mem/ruby/network/simple/Switch.hh b02bca5aed04 
  src/mem/ruby/network/simple/Switch.cc b02bca5aed04 
  src/mem/ruby/network/simple/Throttle.hh b02bca5aed04 
  src/mem/ruby/network/simple/Throttle.cc b02bca5aed04 

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


Testing
---


Thanks,

Brad

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


[m5-dev] Review Request: network: removed the unused network-wide latency param

2011-04-27 Thread Brad Beckmann

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

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

network: removed the unused network-wide latency param


Diffs
-

  src/mem/ruby/network/Network.hh b02bca5aed04 
  src/mem/ruby/network/Network.cc b02bca5aed04 
  src/mem/ruby/network/Network.py b02bca5aed04 

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


Testing
---


Thanks,

Brad

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


[m5-dev] Review Request: network: adjusted default endponit bandwidth

2011-04-27 Thread Brad Beckmann

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

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

network: adjusted default endponit bandwidth

The simple network's endpoint bandwidth value is used to adjust the overall
bandwidth of the network.  Specifically, the ration between endpoint bandwidth
and the MESSAGE_SIZE_MULTIPLIER determines the increase.  By setting the value
to 1000, that means the bandwdith factor specified in the links translates to
the link bandwidth in bytes.  Previously, it was increasing that value by 10.

This patch will likely require a reset of the ruby regression tester stats.


Diffs
-

  src/mem/ruby/network/simple/SimpleNetwork.py b02bca5aed04 

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


Testing
---


Thanks,

Brad

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


Re: [m5-dev] Review Request: network: generalized bw for basic links

2011-04-27 Thread Brad Beckmann


 On 2011-04-27 16:03:25, Tushar Krishna wrote:
  src/mem/ruby/network/garnet/fixed-pipeline/GarnetLink_d.py, line 44
  http://reviews.m5sim.org/r/661/diff/1/?file=12097#file12097line44
 
  In garnet, the link width is actually equal to flit size (i.e. the 
  entire flit is injected into the link). [bigger packets such as data are 
  thereby broken into multiple flits]. 
  So not sure if having both a bandwidth_factor and a flit_size 
  parameter inside BaseGarnetNetwork.py will work. 
  Perhaps we should set flit_size equal to bandwidth_factor there? 
  link_bandwidth is a clearer term but I understand that is not true 
  for simple network where the endpoint bandwidth comes into play...

Yeah, I don't want to call it link_bandwidth or simply bandwidth because the 
multipliers do impact the final bandwidth for the simple network.

The confusion I have, and the reason why I changed it, is before Garnet links 
could be of only one width, even though one would specify links of different 
widths in the topology.  Can we remove the flit _size parameter in 
BaseGarnetNetwork and just rely on the per link bandwidths (i.e. 
channel_width)?  Right now, only the NetworkInterfaces use the flit_size 
parameter and it seems more natural to have that be a configuration parameter 
for just the NIs and not the entire network.  Maybe that is a good reason to 
make the NIs sim_objects.

What do you think?  That seems like the right solution to me, but I would like 
to know your thoughts before I spend time implementing it.


- Brad


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


On 2011-04-27 10:38:47, Brad Beckmann wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/661/
 ---
 
 (Updated 2011-04-27 10:38:47)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 network: generalized bw for basic links
 
 Generalized the specification of bw for basic links.  This value is then
 translated to the specific value used by the simple and Garnet networks.
 
 
 Diffs
 -
 
   configs/ruby/Ruby.py b02bca5aed04 
   src/mem/ruby/network/BasicLink.hh PRE-CREATION 
   src/mem/ruby/network/BasicLink.cc PRE-CREATION 
   src/mem/ruby/network/BasicLink.py PRE-CREATION 
   src/mem/ruby/network/garnet/fixed-pipeline/GarnetLink_d.py PRE-CREATION 
   src/mem/ruby/network/simple/SConscript b02bca5aed04 
   src/mem/ruby/network/simple/SimpleLink.hh PRE-CREATION 
   src/mem/ruby/network/simple/SimpleLink.cc PRE-CREATION 
   src/mem/ruby/network/simple/SimpleLink.py PRE-CREATION 
   src/mem/ruby/network/simple/SimpleNetwork.cc b02bca5aed04 
 
 Diff: http://reviews.m5sim.org/r/661/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Brad
 


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


Re: [m5-dev] Review Request: NetworkTest: added sim_cycles parameter to the network tester.

2011-04-27 Thread Brad Beckmann

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

Ship it!


This looks good to me, though it does appear to be a combination of a bug fix 
and the added sim_cycle parameter.  However, I understand why they are related 
so I don't think it is necessary to split them.

- Brad


On 2011-04-25 16:18:04, Tushar Krishna wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/660/
 ---
 
 (Updated 2011-04-25 16:18:04)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, Nathan 
 Binkert, and Brad Beckmann.
 
 
 Summary
 ---
 
 NetworkTest: added sim_cycles parameter to the network tester.
 
 The network tester terminates after injecting for sim_cycles
 (default=1000), instead of having to explicitly pass --maxtick from the
 command line as before. If fixed_pkts is enabled, the tester stops
 scheduling itself after injecting maxpackets number of packets.
 The tester also works with zero command line arguments now.
 
 
 Diffs
 -
 
   configs/example/ruby_network_test.py de679a068dd8 
   src/cpu/testers/networktest/NetworkTest.py de679a068dd8 
   src/cpu/testers/networktest/networktest.hh de679a068dd8 
   src/cpu/testers/networktest/networktest.cc de679a068dd8 
 
 Diff: http://reviews.m5sim.org/r/660/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Tushar
 


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


[m5-dev] Review Request: ruby: moved topology to the top network directory

2011-04-22 Thread Brad Beckmann

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

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

ruby: moved topology to the top network directory

Moved the Topology class to the top network directory because it is shared by
both the simple and Garnet networks.


Diffs
-

  src/mem/ruby/network/Network.cc 914389024c33 
  src/mem/ruby/network/SConscript 914389024c33 
  src/mem/ruby/network/Topology.hh PRE-CREATION 
  src/mem/ruby/network/Topology.cc PRE-CREATION 
  src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 914389024c33 
  src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc 914389024c33 
  src/mem/ruby/network/simple/SConscript 914389024c33 
  src/mem/ruby/network/simple/SimpleNetwork.cc 914389024c33 
  src/mem/ruby/network/simple/Topology.hh 914389024c33 
  src/mem/ruby/network/simple/Topology.cc 914389024c33 

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


Testing
---


Thanks,

Brad

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


[m5-dev] Review Request: garnet: cleaned up flexible netwok header file

2011-04-22 Thread Brad Beckmann

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

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

garnet: cleaned up flexible netwok header file


Diffs
-

  src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc 914389024c33 

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


Testing
---


Thanks,

Brad

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


[m5-dev] Review Request: network: convert links switches to first class C++ SimObjects

2011-04-22 Thread Brad Beckmann

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

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

network: convert links  switches to first class C++ SimObjects

This patch converts links and switches from second class simobjects that were
virtually ignored by the networks (both simple and Garnet) to first class
simobjects that directly correspond to c++ ojbects manipulated by the
topology and network classes.  This is especially true for Garnet, where the
links and switches directly correspond to specific C++ objects.

By making this change, many aspects of the Topology class were simplified.


Diffs
-

  configs/ruby/MESI_CMP_directory.py 914389024c33 
  configs/ruby/MI_example.py 914389024c33 
  configs/ruby/MOESI_CMP_directory.py 914389024c33 
  configs/ruby/MOESI_CMP_token.py 914389024c33 
  configs/ruby/MOESI_hammer.py 914389024c33 
  configs/ruby/Network_test.py 914389024c33 
  configs/ruby/Ruby.py 914389024c33 
  src/mem/protocol/RubySlicc_Exports.sm 914389024c33 
  src/mem/ruby/network/BasicLink.hh PRE-CREATION 
  src/mem/ruby/network/BasicLink.cc PRE-CREATION 
  src/mem/ruby/network/BasicLink.py PRE-CREATION 
  src/mem/ruby/network/BasicRouter.hh PRE-CREATION 
  src/mem/ruby/network/BasicRouter.cc PRE-CREATION 
  src/mem/ruby/network/BasicRouter.py PRE-CREATION 
  src/mem/ruby/network/Network.hh 914389024c33 
  src/mem/ruby/network/Network.py 914389024c33 
  src/mem/ruby/network/SConscript 914389024c33 
  src/mem/ruby/network/Topology.hh PRE-CREATION 
  src/mem/ruby/network/Topology.cc PRE-CREATION 
  src/mem/ruby/network/garnet/fixed-pipeline/CreditLink_d.hh 914389024c33 
  src/mem/ruby/network/garnet/fixed-pipeline/GarnetLink_d.hh PRE-CREATION 
  src/mem/ruby/network/garnet/fixed-pipeline/GarnetLink_d.cc PRE-CREATION 
  src/mem/ruby/network/garnet/fixed-pipeline/GarnetLink_d.py PRE-CREATION 
  src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.hh 914389024c33 
  src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 914389024c33 
  src/mem/ruby/network/garnet/fixed-pipeline/GarnetRouter_d.py PRE-CREATION 
  src/mem/ruby/network/garnet/fixed-pipeline/NetworkLink_d.hh 914389024c33 
  src/mem/ruby/network/garnet/fixed-pipeline/NetworkLink_d.cc 914389024c33 
  src/mem/ruby/network/garnet/fixed-pipeline/Router_d.hh 914389024c33 
  src/mem/ruby/network/garnet/fixed-pipeline/Router_d.cc 914389024c33 
  src/mem/ruby/network/garnet/fixed-pipeline/SConscript 914389024c33 
  src/mem/ruby/network/garnet/flexible-pipeline/GarnetLink.hh PRE-CREATION 
  src/mem/ruby/network/garnet/flexible-pipeline/GarnetLink.cc PRE-CREATION 
  src/mem/ruby/network/garnet/flexible-pipeline/GarnetLink.py PRE-CREATION 
  src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.hh 914389024c33 
  src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc 914389024c33 
  src/mem/ruby/network/garnet/flexible-pipeline/GarnetRouter.py PRE-CREATION 
  src/mem/ruby/network/garnet/flexible-pipeline/NetworkLink.hh 914389024c33 
  src/mem/ruby/network/garnet/flexible-pipeline/NetworkLink.cc 914389024c33 
  src/mem/ruby/network/garnet/flexible-pipeline/Router.hh 914389024c33 
  src/mem/ruby/network/garnet/flexible-pipeline/Router.cc 914389024c33 
  src/mem/ruby/network/garnet/flexible-pipeline/SConscript 914389024c33 
  src/mem/ruby/network/orion/NetworkPower.cc 914389024c33 
  src/mem/ruby/network/simple/SimpleNetwork.hh 914389024c33 
  src/mem/ruby/network/simple/SimpleNetwork.cc 914389024c33 
  src/mem/ruby/network/topologies/Crossbar.py 914389024c33 
  src/mem/ruby/network/topologies/Mesh.py 914389024c33 
  src/mem/ruby/network/topologies/MeshDirCorners.py 914389024c33 
  src/mem/ruby/slicc_interface/AbstractController.hh 914389024c33 
  src/mem/ruby/slicc_interface/Controller.py 914389024c33 

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


Testing
---


Thanks,

Brad

___
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-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-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: dbg: use system ticks instead of cycles

2011-04-15 Thread Brad Beckmann

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

Ship it!


Just a few minor alignment requests.  Other than that, it looks good to me.


src/mem/slicc/symbols/StateMachine.py
http://reviews.m5sim.org/r/635/#comment1532

Since you're already modifying this DPRINTFR, can you align all the lines 
to the open paranethesis?

Thanks



src/mem/slicc/symbols/StateMachine.py
http://reviews.m5sim.org/r/635/#comment1533

align here please



src/mem/slicc/symbols/StateMachine.py
http://reviews.m5sim.org/r/635/#comment1534

align here please


- Brad


On 2011-04-15 10:33:39, Korey Sewell wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/635/
 ---
 
 (Updated 2011-04-15 10:33:39)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 ruby: dbg: use system ticks instead of cycles
 It's easier to debug simulations (find the exact point to rerun a trace) when 
 the output is in
 the system ticks instead of the Ruby cycle time
 
 
 Diffs
 -
 
   src/mem/ruby/buffers/MessageBuffer.cc 54a65799e4c1 
   src/mem/ruby/network/simple/PerfectSwitch.cc 54a65799e4c1 
   src/mem/ruby/system/Sequencer.cc 54a65799e4c1 
   src/mem/slicc/symbols/StateMachine.py 54a65799e4c1 
   src/mem/slicc/symbols/Type.py 54a65799e4c1 
 
 Diff: http://reviews.m5sim.org/r/635/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Korey
 


___
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: Cache warmup: fixed compile errors in Brad's cache warmup patches

2011-04-11 Thread Brad Beckmann

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


Hi Somayeh,

It doesn't appear that your patch applies cleanly to the current tree because 
all I see is a javascript error.  Regardless, I don't think we should add 
something to the repo to make those temporary patches work.  I know I suggested 
sending a patch out for review earlier, but I was under the wrong impression 
that the compile issue was not a line that my patch added.  My fault.

Instead of adding code to the main repo to make those patches work, I suggest 
change the patches directly.

- Brad


On 2011-04-11 12:06:10, Somayeh Sardashti wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/637/
 ---
 
 (Updated 2011-04-11 12:06:10)
 
 
 Review request for Default and Brad Beckmann.
 
 
 Summary
 ---
 
 Cache warmup: fixed compile errors in Brad's cache warmup patches
 
 
 Diffs
 -
 
   src/mem/ruby/network/simple/Topology.hh 955a58f51a6d 
   src/mem/ruby/recorder/Tracer.hh 955a58f51a6d 
   src/mem/ruby/system/CacheMemory.hh 955a58f51a6d 
 
 Diff: http://reviews.m5sim.org/r/637/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Somayeh
 


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


Re: [m5-dev] Review Request: ruby: dbg: use system ticks instead of cycles

2011-04-08 Thread Brad Beckmann

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


Overall, this seems pretty straightforward.  However I'm confused by the double 
curTick concerns.  Specific comments below.


src/mem/ruby/system/Sequencer.cc
http://reviews.m5sim.org/r/635/#comment1473

If we are going to replace the cycle count with curTick(), then we should 
increase the width of that first field well beyond 7.  Something like 15 makes 
sense to me.  What do you think?

Also I'm confused by Nilay's concern about printing out the curTick twice.  
DPRINTFR doesn't print out the curTick by default, correct?  Therefore the 
current tick will only be printed once.



src/mem/ruby/system/Sequencer.cc
http://reviews.m5sim.org/r/635/#comment1474

Same thing here.  Increase first field well beyond 7.



src/mem/slicc/symbols/StateMachine.py
http://reviews.m5sim.org/r/635/#comment1475

beyond 7



src/mem/slicc/symbols/StateMachine.py
http://reviews.m5sim.org/r/635/#comment1476

beyond 7



src/mem/slicc/symbols/StateMachine.py
http://reviews.m5sim.org/r/635/#comment1477

beyond 7


- Brad


On 2011-04-05 11:19:26, Korey Sewell wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/635/
 ---
 
 (Updated 2011-04-05 11:19:26)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 ruby: dbg: use system ticks instead of cycles
 It's easier to debug simulations (find the exact point to rerun a trace) when 
 the output is in
 the system ticks instead of the Ruby cycle time
 
 
 Diffs
 -
 
   src/mem/ruby/buffers/MessageBuffer.cc 54a65799e4c1 
   src/mem/ruby/network/simple/PerfectSwitch.cc 54a65799e4c1 
   src/mem/ruby/system/Sequencer.cc 54a65799e4c1 
   src/mem/slicc/symbols/StateMachine.py 54a65799e4c1 
   src/mem/slicc/symbols/Type.py 54a65799e4c1 
 
 Diff: http://reviews.m5sim.org/r/635/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Korey
 


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


[m5-dev] changeset in m5: ruby: fixes to support more types of RubyRequests

2011-04-06 Thread Brad Beckmann
changeset 02cb69e5cfeb in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=02cb69e5cfeb
description:
ruby: fixes to support more types of RubyRequests

diffstat:

 src/mem/ruby/system/Sequencer.cc |  9 +++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diffs (40 lines):

diff -r 54a65799e4c1 -r 02cb69e5cfeb src/mem/ruby/system/Sequencer.cc
--- a/src/mem/ruby/system/Sequencer.cc  Mon Apr 04 11:42:32 2011 -0500
+++ b/src/mem/ruby/system/Sequencer.cc  Wed Apr 06 14:41:41 2011 -0700
@@ -229,6 +229,7 @@
 Address line_addr(request-ruby_request.m_PhysicalAddress);
 line_addr.makeLineAddress();
 if ((request-ruby_request.m_Type == RubyRequestType_ST) ||
+(request-ruby_request.m_Type == RubyRequestType_ATOMIC) ||
 (request-ruby_request.m_Type == RubyRequestType_RMW_Read) ||
 (request-ruby_request.m_Type == RubyRequestType_RMW_Write) ||
 (request-ruby_request.m_Type == RubyRequestType_Load_Linked) ||
@@ -381,6 +382,7 @@
 markRemoved();
 
 assert((request-ruby_request.m_Type == RubyRequestType_ST) ||
+   (request-ruby_request.m_Type == RubyRequestType_ATOMIC) ||
(request-ruby_request.m_Type == RubyRequestType_RMW_Read) ||
(request-ruby_request.m_Type == RubyRequestType_RMW_Write) ||
(request-ruby_request.m_Type == RubyRequestType_Load_Linked) ||
@@ -648,6 +650,7 @@
   //
   case RubyRequestType_Load_Linked:
   case RubyRequestType_Store_Conditional:
+  case RubyRequestType_ATOMIC:
 ctype = RubyRequestType_ATOMIC;
 break;
   default:
@@ -671,8 +674,10 @@
 
 Address line_addr(request.m_PhysicalAddress);
 line_addr.makeLineAddress();
-int proc_id = request.pkt-req-hasContextId() ?
-request.pkt-req-contextId() : -1;
+int proc_id = -1;
+if (request.pkt != NULL  request.pkt-req-hasContextId()) {
+proc_id = request.pkt-req-contextId();
+}
 RubyRequest *msg = new RubyRequest(request.m_PhysicalAddress.getAddress(),
request.data, request.m_Size,
request.m_ProgramCounter.getAddress(),
___
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-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

[m5-dev] changeset in m5: hammer: fixed dma uniproc error

2011-04-01 Thread Brad Beckmann
changeset aeec9e157d06 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=aeec9e157d06
description:
hammer: fixed dma uniproc error

Fixed an error reguarding DMA for uninprocessor systems.  Basically 
removed an
overly agressive optimization that lead to inconsistent state between 
the
cache and the directory.

diffstat:

 src/mem/protocol/MOESI_hammer-cache.sm |  10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diffs (34 lines):

diff -r c7302d55d644 -r aeec9e157d06 src/mem/protocol/MOESI_hammer-cache.sm
--- a/src/mem/protocol/MOESI_hammer-cache.smThu Mar 31 18:20:12 2011 -0700
+++ b/src/mem/protocol/MOESI_hammer-cache.smFri Apr 01 15:50:23 2011 -0700
@@ -1532,8 +1532,8 @@
 l_popForwardQueue;
   }
   
-  transition(MM, NC_DMA_GETS) {
-c_sendExclusiveData;
+  transition(MM, NC_DMA_GETS, O) {
+ee_sendDataShared;
 l_popForwardQueue;
   }
   
@@ -1575,7 +1575,7 @@
 l_popForwardQueue;
   }
 
-  transition(M, NC_DMA_GETS) {
+  transition(M, NC_DMA_GETS, O) {
 ee_sendDataShared;
 l_popForwardQueue;
   }
@@ -1933,8 +1933,8 @@
 l_popForwardQueue;
   }
 
-  transition(MM_F, NC_DMA_GETS) {
-ct_sendExclusiveDataFromTBE;
+  transition(MM_F, NC_DMA_GETS, OM_F) {
+sq_sendSharedDataFromTBEToCache;
 l_popForwardQueue;
   }
 
___
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/#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: pass Packet-Req-contextId() to Ruby.

2011-03-31 Thread Brad Beckmann

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

Ship it!


- Brad


On 2011-03-31 12:16:27, Lisa Hsu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/623/
 ---
 
 (Updated 2011-03-31 12:16:27)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 Ruby: pass Packet-Req-contextId() to Ruby.
 It is useful for Ruby to understand from whence request packets came.
 This has all request packets going into Ruby pass the contextId value, if
 it exists.  This supplants the old libruby proc_id value passed around in
 all the Messages, so I've also removed the unused unsigned proc_id; member
 generated by SLICC for all Message types.
 
 
 Diffs
 -
 
   src/mem/protocol/RubySlicc_Types.sm d8587c913ccf 
   src/mem/ruby/slicc_interface/RubyRequest.hh d8587c913ccf 
   src/mem/ruby/system/Sequencer.cc d8587c913ccf 
   src/mem/slicc/symbols/Type.py d8587c913ccf 
 
 Diff: http://reviews.m5sim.org/r/623/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Lisa
 


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


Re: [m5-dev] Review Request: Ruby: enable multiple sequencers in one controller.

2011-03-31 Thread Brad Beckmann

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



src/mem/slicc/symbols/StateMachine.py
http://reviews.m5sim.org/r/624/#comment1432

Do you also need to declare the contains_dma_sequencer flag here and set it 
to False?


- Brad


On 2011-03-31 12:20:53, Lisa Hsu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/624/
 ---
 
 (Updated 2011-03-31 12:20:53)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 Ruby: enable multiple sequencers in one controller.
 
 
 Diffs
 -
 
   src/mem/slicc/symbols/StateMachine.py d8587c913ccf 
 
 Diff: http://reviews.m5sim.org/r/624/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Lisa
 


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


Re: [m5-dev] Review Request: Ruby: have the rubytester pass contextId to Ruby.

2011-03-31 Thread Brad Beckmann

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

Ship it!


- Brad


On 2011-03-31 12:20:59, Lisa Hsu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/625/
 ---
 
 (Updated 2011-03-31 12:20:59)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 Ruby: have the rubytester pass contextId to Ruby.
 
 
 Diffs
 -
 
   src/cpu/testers/rubytest/Check.cc d8587c913ccf 
 
 Diff: http://reviews.m5sim.org/r/625/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Lisa
 


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


Re: [m5-dev] Review Request: Ruby: Add new object called WireBuffer to mimic a Wire.

2011-03-31 Thread Brad Beckmann

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

Ship it!


Other than Nilay's comments, this looks good to me.

- Brad


On 2011-03-31 12:21:07, Lisa Hsu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/627/
 ---
 
 (Updated 2011-03-31 12:21:07)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 Ruby: Add new object called WireBuffer to mimic a Wire.
 This is a substitute for MessageBuffers between controllers where you don't
 want messages to actually go through the Network, because requests/responses 
 can
 always get reordered wrt to one another (even if you turn off Randomization 
 and turn on Ordered)
 because you are, after all, going through a network with contention. For 
 systems where you model
 multiple controllers that are very tightly coupled and do not actually go 
 through a network,
 it is a pain to have to write a coherence protocol to account for mixed up 
 request/response orderings
 despite the fact that it's completely unrealistic.  This is *not* meant as a 
 substitute for real
 MessageBuffers when messages do in fact go over a network.
 
 
 Diffs
 -
 
   src/mem/protocol/RubySlicc_Types.sm d8587c913ccf 
   src/mem/ruby/SConscript d8587c913ccf 
   src/mem/ruby/system/SConscript d8587c913ccf 
   src/mem/ruby/system/WireBuffer.hh PRE-CREATION 
   src/mem/ruby/system/WireBuffer.cc PRE-CREATION 
   src/mem/ruby/system/WireBuffer.py PRE-CREATION 
   src/mem/slicc/symbols/StateMachine.py d8587c913ccf 
 
 Diff: http://reviews.m5sim.org/r/627/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Lisa
 


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


Re: [m5-dev] Review Request: Ruby: Simplify SLICC and Entry/TBE handling.

2011-03-31 Thread Brad Beckmann

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

Ship it!


- Brad


On 2011-03-31 14:26:33, Lisa Hsu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/630/
 ---
 
 (Updated 2011-03-31 14:26:33)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 Ruby: Simplify SLICC and Entry/TBE handling.
 Before this changeset, all local variables of type Entry and TBE were 
 considered
 to be pointers, but an immediate use of said variables would not be 
 automatically
 deferenced in SLICC-generated code.  Instead, deferences occurred when such
 variables were passed to functions, and were automatically dereferenced in
 the bodies of the functions (e.g. the implicitly passed cache_entry).
 
 This is a more general way to do it, which leaves in place the
 assumption that parameters to functions and local variables of type 
 AbstractCacheEntry
 and TBE are always pointers, but instead of dereferencing to access member 
 variables
 on a contextual basis, the dereferencing automatically occurs on a type basis 
 at the
 moment a member is being accessed.  So, now, things you can do that you 
 couldn't before
 include:
 
 Entry foo := getCacheEntry(address);
 cache_entry.DataBlk := foo.DataBlk;
 
 or
 
 cache_entry.DataBlk := getCacheEntry(address).DataBlk;
 
 or even
 
 cache_entry.DataBlk := static_cast(Entry, pointer, 
 cache.lookup(address)).DataBlk;
 
 
 Diffs
 -
 
   src/mem/slicc/ast/ActionDeclAST.py d8587c913ccf 
   src/mem/slicc/ast/FormalParamAST.py d8587c913ccf 
   src/mem/slicc/ast/FuncCallExprAST.py d8587c913ccf 
   src/mem/slicc/ast/IsValidPtrExprAST.py d8587c913ccf 
   src/mem/slicc/ast/MemberExprAST.py d8587c913ccf 
 
 Diff: http://reviews.m5sim.org/r/630/diff
 
 
 Testing
 ---
 
 So - just to add a note (this is not about testing).  I had uploaded a patch, 
 then realized that there was some dead code that I should also remove, so I 
 uploaded a new patch.  However, the head of my tree had changed, and that 
 appears to have messed up my ability to update patches.  So, two upshots:
 
 One, this newer patch gets rid of the some of the str.replace(*, ) code 
 that was in place to auto-remove the *s from m_cache_entry and m_tbe, since 
 now, those guys do not have *s by default.
 
 Two, don't change the head of your tree and have outstanding patches at the 
 same time, if you think you want to update patches.
 
 
 Thanks,
 
 Lisa
 


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


Re: [m5-dev] Review Request: CacheMemory: add allocateVoid() that is == allocate() but no return value.

2011-03-31 Thread Brad Beckmann

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


This is more of a question, then a suggestion.  Is there a way to use 
allocateVoid() a wrapper around allocate() rather than have to duplicate code?  
What happens if you cast the return pointer to void?  Does that suppresss the 
error?  Maybe there is a way to set some attribute on the variable that the 
compiler can understand.  I have no idea if that is actually possible and if 
any solution would be portable across compiler generations.  I'm just curious 
if there was some way to avoid the code duplication.

- Brad


On 2011-03-31 12:21:22, Lisa Hsu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/629/
 ---
 
 (Updated 2011-03-31 12:21:22)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 CacheMemory: add allocateVoid() that is == allocate() but no return value.
 This function duplicates the functionality of allocate() exactly, except that 
 it does not return
 a return value.  In protocols where you just want to allocate a block
 but do not want that block to be your implicitly passed cache_entry, use this 
 function.
 Otherwise, SLICC will complain if you do not consume the pointer returned by 
 allocate(),
 and if you do a dummy assignment Entry foo := cache.allocate(address), the C++
 compiler will complain of an unused variable.  This is kind of a hack to get 
 around
 those issues, but suggestions welcome.
 
 
 Diffs
 -
 
   src/mem/protocol/RubySlicc_Types.sm d8587c913ccf 
   src/mem/ruby/system/CacheMemory.hh d8587c913ccf 
   src/mem/ruby/system/CacheMemory.cc d8587c913ccf 
 
 Diff: http://reviews.m5sim.org/r/629/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Lisa
 


___
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 
   src/mem/ruby/system

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


[m5-dev] changeset in m5: ruby: fixed cache index setting

2011-03-25 Thread Brad Beckmann
changeset d8587c913ccf in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=d8587c913ccf
description:
ruby: fixed cache index setting

diffstat:

 configs/ruby/MESI_CMP_directory.py  |  17 +++--
 configs/ruby/MI_example.py  |   4 +++-
 configs/ruby/MOESI_CMP_directory.py |  17 +++--
 configs/ruby/MOESI_CMP_token.py |  15 +--
 configs/ruby/MOESI_hammer.py|  10 +++---
 5 files changed, 41 insertions(+), 22 deletions(-)

diffs (207 lines):

diff -r bbab80b639cb -r d8587c913ccf configs/ruby/MESI_CMP_directory.py
--- a/configs/ruby/MESI_CMP_directory.pyFri Mar 25 00:46:14 2011 -0400
+++ b/configs/ruby/MESI_CMP_directory.pyFri Mar 25 10:13:50 2011 -0700
@@ -68,15 +68,19 @@
 # Must create the individual controllers before the network to ensure the
 # controller constructors are called before the network constructor
 #
+l2_bits = int(math.log(options.num_l2caches, 2))
+block_size_bits = int(math.log(options.cacheline_size, 2))
 
 for i in xrange(options.num_cpus):
 #
 # First create the Ruby objects associated with this cpu
 #
 l1i_cache = L1Cache(size = options.l1i_size,
-assoc = options.l1i_assoc)
+assoc = options.l1i_assoc,
+start_index_bit = block_size_bits)
 l1d_cache = L1Cache(size = options.l1d_size,
-assoc = options.l1d_assoc)
+assoc = options.l1d_assoc,
+start_index_bit = block_size_bits)
 
 cpu_seq = RubySequencer(version = i,
 icache = l1i_cache,
@@ -91,9 +95,7 @@
   sequencer = cpu_seq,
   L1IcacheMemory = l1i_cache,
   L1DcacheMemory = l1d_cache,
-  l2_select_num_bits = \
-math.log(options.num_l2caches,
- 2))
+  l2_select_num_bits = l2_bits)
 
 exec(system.l1_cntrl%d = l1_cntrl % i)
 
@@ -103,12 +105,15 @@
 cpu_sequencers.append(cpu_seq)
 l1_cntrl_nodes.append(l1_cntrl)
 
+l2_index_start = block_size_bits + l2_bits
+
 for i in xrange(options.num_l2caches):
 #
 # First create the Ruby objects associated with this cpu
 #
 l2_cache = L2Cache(size = options.l2_size,
-   assoc = options.l2_assoc)
+   assoc = options.l2_assoc,
+   start_index_bit = l2_index_start)
 
 l2_cntrl = L2Cache_Controller(version = i,
   L2cacheMemory = l2_cache)
diff -r bbab80b639cb -r d8587c913ccf configs/ruby/MI_example.py
--- a/configs/ruby/MI_example.pyFri Mar 25 00:46:14 2011 -0400
+++ b/configs/ruby/MI_example.pyFri Mar 25 10:13:50 2011 -0700
@@ -60,6 +60,7 @@
 # Must create the individual controllers before the network to ensure the
 # controller constructors are called before the network constructor
 #
+block_size_bits = int(math.log(options.cacheline_size, 2))
 
 for i in xrange(options.num_cpus):
 #
@@ -68,7 +69,8 @@
 # config parameters.
 #
 cache = Cache(size = options.l1d_size,
-  assoc = options.l1d_assoc)
+  assoc = options.l1d_assoc,
+  start_index_bit = block_size_bits)
 
 #
 # Only one unified L1 cache exists.  Can cache instructions and data.
diff -r bbab80b639cb -r d8587c913ccf configs/ruby/MOESI_CMP_directory.py
--- a/configs/ruby/MOESI_CMP_directory.py   Fri Mar 25 00:46:14 2011 -0400
+++ b/configs/ruby/MOESI_CMP_directory.py   Fri Mar 25 10:13:50 2011 -0700
@@ -68,15 +68,19 @@
 # Must create the individual controllers before the network to ensure the
 # controller constructors are called before the network constructor
 #
+l2_bits = int(math.log(options.num_l2caches, 2))
+block_size_bits = int(math.log(options.cacheline_size, 2))
 
 for i in xrange(options.num_cpus):
 #
 # First create the Ruby objects associated with this cpu
 #
 l1i_cache = L1Cache(size = options.l1i_size,
-assoc = options.l1i_assoc)
+assoc = options.l1i_assoc,
+start_index_bit = block_size_bits)
 l1d_cache = L1Cache(size = options.l1d_size,
-assoc = options.l1d_assoc)
+assoc = options.l1d_assoc,
+start_index_bit = block_size_bits)
 
 cpu_seq = RubySequencer(version = i,
 icache = l1i_cache,
@@ -91,9 

Re: [m5-dev] Review Request: my initial implementation of cache flushing

2011-03-24 Thread Brad Beckmann

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


Hi Somayeh,

I was hoping this would be the final review, but I'm concerned that the current 
version has a memory leak (see below).  Please correct me if I'm wrong, but 
right now it doesn't look like you delete Flush packets.  Also there are a few 
other minor fixes you should make.  Finally, please make sure you follow the 
convention for commit messages.


src/mem/protocol/MOESI_hammer-cache.sm
http://reviews.m5sim.org/r/552/#comment1373

Don't add random white space.  Please remove this line.



src/mem/ruby/system/Sequencer.cc
http://reviews.m5sim.org/r/552/#comment1374

I don't think you need to separately handle Flush request.  I believe the 
current implmementation of handleLlsc should always return true for Flush 
requests.  Please remove this change.



src/mem/ruby/system/Sequencer.cc
http://reviews.m5sim.org/r/552/#comment1376

I thought we concluded that Flush requests can callback the RubyPort?  As 
long as needsResponse is set to false, the cpu should never see the packet 
which is what we want.  Right now, I think you have a memory leak because the 
Flush packets are never deleted.  Please correct me if I'm missing something.



src/mem/ruby/system/Sequencer.cc
http://reviews.m5sim.org/r/552/#comment1375

Please remove the random white space.


- Brad


On 2011-03-23 22:28:01, Somayeh Sardashti wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/552/
 ---
 
 (Updated 2011-03-23 22:28:01)
 
 
 Review request for Default and Brad Beckmann.
 
 
 Summary
 ---
 
 my initial implementation of cache flushing
 
 
 Diffs
 -
 
   configs/example/ruby_random_test.py baf4b5f6782e 
   src/cpu/testers/rubytest/Check.hh baf4b5f6782e 
   src/cpu/testers/rubytest/Check.cc baf4b5f6782e 
   src/cpu/testers/rubytest/RubyTester.hh baf4b5f6782e 
   src/cpu/testers/rubytest/RubyTester.cc baf4b5f6782e 
   src/cpu/testers/rubytest/RubyTester.py baf4b5f6782e 
   src/mem/packet.hh baf4b5f6782e 
   src/mem/packet.cc baf4b5f6782e 
   src/mem/protocol/MOESI_hammer-cache.sm baf4b5f6782e 
   src/mem/protocol/MOESI_hammer-dir.sm baf4b5f6782e 
   src/mem/protocol/MOESI_hammer-msg.sm baf4b5f6782e 
   src/mem/protocol/RubySlicc_Exports.sm baf4b5f6782e 
   src/mem/ruby/slicc_interface/RubyRequest.hh baf4b5f6782e 
   src/mem/ruby/slicc_interface/RubyRequest.cc baf4b5f6782e 
   src/mem/ruby/system/DMASequencer.cc baf4b5f6782e 
   src/mem/ruby/system/RubyPort.cc baf4b5f6782e 
   src/mem/ruby/system/Sequencer.cc baf4b5f6782e 
 
 Diff: http://reviews.m5sim.org/r/552/diff
 
 
 Testing
 ---
 
 This implementation has passed 10,000,000 ruby test cases, and the 
 MOESI_hammer regression tests.
 
 
 Thanks,
 
 Somayeh
 


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


Re: [m5-dev] Review Request: my initial implementation of cache flushing

2011-03-24 Thread Brad Beckmann


 On 2011-03-24 08:58:15, Brad Beckmann wrote:
  src/mem/ruby/system/Sequencer.cc, line 541
  http://reviews.m5sim.org/r/552/diff/6/?file=11209#file11209line541
 
  I thought we concluded that Flush requests can callback the RubyPort?  
  As long as needsResponse is set to false, the cpu should never see the 
  packet which is what we want.  Right now, I think you have a memory leak 
  because the Flush packets are never deleted.  Please correct me if I'm 
  missing something.
 
 Somayeh Sardashti wrote:
 ruby_hit_callback calls RubyPort::M5Port::hitCallback. Then, as we set 
 accessPhysMem to False for flush requests, it will call 
 pkt-makeResponse(), which should not be called, so its assertion on 
 needsResponse will fail. Should I change this condition (in RubyPort.cc line 
 365)?


Not exactly, we should change the if (accessPhysMem) else statement in 
RubyPort::M5Port::hitCallback, to the following:


if (accessPhysMem) {
ruby_port-physMemPort-sendAtomic(pkt);
} else if (needsResponse) {
pkt-makeResponse();
}


 On 2011-03-24 08:58:15, Brad Beckmann wrote:
  src/mem/ruby/system/Sequencer.cc, line 396
  http://reviews.m5sim.org/r/552/diff/6/?file=11209#file11209line396
 
  I don't think you need to separately handle Flush request.  I believe 
  the current implmementation of handleLlsc should always return true for 
  Flush requests.  Please remove this change.
 
 Somayeh Sardashti wrote:
 handleLlsc accesses the cache entry ((m_dataCache_ptr-isLocked(address, 
 m_version)), however in case of cache flushes, we keep the line in TBE and 
 deallocate the cache entry. Therefore, regular implementation of handleLlsc 
 does not work properly with Flush requests (gives an error when it tries to 
 access the cache entry as it does not exist). I can add a condition inside 
 this function to return True for Flush requests, what do you think?

Ah, I see.  Yes, we should add a m_dataCache_ptr-isTagPresent() check before 
that m_dataCache_ptr-isLocked(address, m_version) test.


- Brad


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


On 2011-03-23 22:28:01, Somayeh Sardashti wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/552/
 ---
 
 (Updated 2011-03-23 22:28:01)
 
 
 Review request for Default and Brad Beckmann.
 
 
 Summary
 ---
 
 my initial implementation of cache flushing
 
 
 Diffs
 -
 
   configs/example/ruby_random_test.py baf4b5f6782e 
   src/cpu/testers/rubytest/Check.hh baf4b5f6782e 
   src/cpu/testers/rubytest/Check.cc baf4b5f6782e 
   src/cpu/testers/rubytest/RubyTester.hh baf4b5f6782e 
   src/cpu/testers/rubytest/RubyTester.cc baf4b5f6782e 
   src/cpu/testers/rubytest/RubyTester.py baf4b5f6782e 
   src/mem/packet.hh baf4b5f6782e 
   src/mem/packet.cc baf4b5f6782e 
   src/mem/protocol/MOESI_hammer-cache.sm baf4b5f6782e 
   src/mem/protocol/MOESI_hammer-dir.sm baf4b5f6782e 
   src/mem/protocol/MOESI_hammer-msg.sm baf4b5f6782e 
   src/mem/protocol/RubySlicc_Exports.sm baf4b5f6782e 
   src/mem/ruby/slicc_interface/RubyRequest.hh baf4b5f6782e 
   src/mem/ruby/slicc_interface/RubyRequest.cc baf4b5f6782e 
   src/mem/ruby/system/DMASequencer.cc baf4b5f6782e 
   src/mem/ruby/system/RubyPort.cc baf4b5f6782e 
   src/mem/ruby/system/Sequencer.cc baf4b5f6782e 
 
 Diff: http://reviews.m5sim.org/r/552/diff
 
 
 Testing
 ---
 
 This implementation has passed 10,000,000 ruby test cases, and the 
 MOESI_hammer regression tests.
 
 
 Thanks,
 
 Somayeh
 


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


Re: [m5-dev] Review Request: my initial implementation of cache flushing

2011-03-24 Thread Brad Beckmann

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

Ship it!


Hi Somayeh,

Other than a couple minor comment updates (see below), this looks done to me.  
Congratulations!  Make sure to run the regression tester and ask Arka or Nilay 
for help checking it in.



src/mem/ruby/system/RubyPort.cc
http://reviews.m5sim.org/r/552/#comment1383

Please update this comment.  Flushes also don't access physical memory.



src/mem/ruby/system/RubyPort.cc
http://reviews.m5sim.org/r/552/#comment1382

please add a comment explaining what is going on here.


- Brad


On 2011-03-24 17:17:59, Somayeh Sardashti wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/552/
 ---
 
 (Updated 2011-03-24 17:17:59)
 
 
 Review request for Default and Brad Beckmann.
 
 
 Summary
 ---
 
 my initial implementation of cache flushing
 
 
 Diffs
 -
 
   configs/example/ruby_random_test.py baf4b5f6782e 
   src/cpu/testers/rubytest/Check.hh baf4b5f6782e 
   src/cpu/testers/rubytest/Check.cc baf4b5f6782e 
   src/cpu/testers/rubytest/RubyTester.hh baf4b5f6782e 
   src/cpu/testers/rubytest/RubyTester.cc baf4b5f6782e 
   src/cpu/testers/rubytest/RubyTester.py baf4b5f6782e 
   src/mem/packet.hh baf4b5f6782e 
   src/mem/packet.cc baf4b5f6782e 
   src/mem/protocol/MOESI_hammer-cache.sm baf4b5f6782e 
   src/mem/protocol/MOESI_hammer-dir.sm baf4b5f6782e 
   src/mem/protocol/MOESI_hammer-msg.sm baf4b5f6782e 
   src/mem/protocol/RubySlicc_Exports.sm baf4b5f6782e 
   src/mem/ruby/slicc_interface/RubyRequest.hh baf4b5f6782e 
   src/mem/ruby/slicc_interface/RubyRequest.cc baf4b5f6782e 
   src/mem/ruby/system/DMASequencer.cc baf4b5f6782e 
   src/mem/ruby/system/RubyPort.cc baf4b5f6782e 
   src/mem/ruby/system/Sequencer.cc baf4b5f6782e 
 
 Diff: http://reviews.m5sim.org/r/552/diff
 
 
 Testing
 ---
 
 This implementation has passed 10,000,000 ruby test cases, and the 
 MOESI_hammer regression tests.
 
 
 Thanks,
 
 Somayeh
 


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


Re: [m5-dev] Review Request: my initial implementation of cache flushing

2011-03-22 Thread Brad Beckmann

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


Hi Somayeh,

This looks great.  I just have a couple comments below.  Once you address them, 
you can consider it done from my perspective.


src/cpu/testers/rubytest/Check.cc
http://reviews.m5sim.org/r/552/#comment1372

Instead of hard coding the flush requests with a true/false statement, we 
should have a flag passed in from ruby_random_test.py.  Also in 
ruby_random_test.py you can test which protocol was compiled with the binary 
and ensure that flush requests are only enabled for the MOESI_hammer protocol.



src/mem/protocol/RubySlicc_Types.sm
http://reviews.m5sim.org/r/552/#comment1371

I don't think these functions exist anymore, correct?  I think you can 
remove these declarations then.


- Brad


On 2011-03-22 19:33:58, Somayeh Sardashti wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/552/
 ---
 
 (Updated 2011-03-22 19:33:58)
 
 
 Review request for Default and Brad Beckmann.
 
 
 Summary
 ---
 
 my initial implementation of cache flushing
 
 
 Diffs
 -
 
   src/cpu/testers/rubytest/Check.hh baf4b5f6782e 
   src/cpu/testers/rubytest/Check.cc baf4b5f6782e 
   src/mem/packet.hh baf4b5f6782e 
   src/mem/packet.cc baf4b5f6782e 
   src/mem/protocol/MOESI_hammer-cache.sm baf4b5f6782e 
   src/mem/protocol/MOESI_hammer-dir.sm baf4b5f6782e 
   src/mem/protocol/MOESI_hammer-msg.sm baf4b5f6782e 
   src/mem/protocol/RubySlicc_Exports.sm baf4b5f6782e 
   src/mem/protocol/RubySlicc_Types.sm baf4b5f6782e 
   src/mem/ruby/slicc_interface/RubyRequest.hh baf4b5f6782e 
   src/mem/ruby/slicc_interface/RubyRequest.cc baf4b5f6782e 
   src/mem/ruby/system/DMASequencer.cc baf4b5f6782e 
   src/mem/ruby/system/RubyPort.cc baf4b5f6782e 
   src/mem/ruby/system/Sequencer.cc baf4b5f6782e 
 
 Diff: http://reviews.m5sim.org/r/552/diff
 
 
 Testing
 ---
 
 This implementation has passed 10,000,000 ruby test cases, and the 
 MOESI_hammer regression tests.
 
 
 Thanks,
 
 Somayeh
 


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


Re: [m5-dev] Review Request: Network Tester Patch

2011-03-21 Thread Brad Beckmann

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

Ship it!


- Brad


On 2011-03-20 05:23:02, Tushar Krishna wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/561/
 ---
 
 (Updated 2011-03-20 05:23:02)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, Nathan 
 Binkert, and Brad Beckmann.
 
 
 Summary
 ---
 
 This patch adds the network tester for simple and garnet networks.
 The tester code is in testers/networktest.
 The tester can be invoked by configs/example/ruby_network_test.py.
 A dummy coherence protocol called Network_test is also addded for 
 network-only simulations and testing. The protocol takes in messages from the 
 tester and just pushes them into the network in the appropriate vnet, without 
 storing any state.
 
 
 Diffs
 -
 
   src/mem/ruby/system/Sequencer.py 89cd8302abd3 
   src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 89cd8302abd3 
   src/mem/ruby/network/garnet/fixed-pipeline/NetworkInterface_d.cc 
 89cd8302abd3 
   src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.cc 
 89cd8302abd3 
   src/mem/ruby/system/Sequencer.hh 89cd8302abd3 
   src/mem/ruby/system/Sequencer.cc 89cd8302abd3 
   src/mem/protocol/Network_test.slicc PRE-CREATION 
   src/mem/protocol/SConsopts 89cd8302abd3 
   src/mem/ruby/network/garnet/BaseGarnetNetwork.hh 89cd8302abd3 
   src/mem/ruby/network/garnet/BaseGarnetNetwork.cc 89cd8302abd3 
   src/mem/ruby/network/garnet/BaseGarnetNetwork.py 89cd8302abd3 
   src/mem/protocol/Network_test-msg.sm PRE-CREATION 
   src/mem/protocol/Network_test-dir.sm PRE-CREATION 
   src/mem/protocol/Network_test-cache.sm PRE-CREATION 
   src/cpu/testers/networktest/networktest.cc PRE-CREATION 
   src/cpu/testers/networktest/SConscript PRE-CREATION 
   src/cpu/testers/networktest/networktest.hh PRE-CREATION 
   src/cpu/testers/networktest/NetworkTest.py PRE-CREATION 
   configs/ruby/Network_test.py PRE-CREATION 
   build_opts/ALPHA_SE_Network_test PRE-CREATION 
   configs/example/ruby_network_test.py PRE-CREATION 
 
 Diff: http://reviews.m5sim.org/r/561/diff
 
 
 Testing
 ---
 
 Testing done with garnet and simple networks. I will update config 
 assumptions etc on the wiki.
 
 
 Thanks,
 
 Tushar
 


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


Re: [m5-dev] Review Request: Ruby: Remove CacheMsg class from SLICC

2011-03-21 Thread Brad Beckmann

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

Ship it!


- Brad


On 2011-03-20 10:53:10, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/327/
 ---
 
 (Updated 2011-03-20 10:53:10)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Remove CacheMsg class from SLICC
 The goal of the patch is to do away with the CacheMsg class currently in use
 in coherence protocols. In place of CacheMsg, the RubyRequest class will used.
 This class is already present in slicc_interface/RubyRequest.hh. In fact,
 objects of class CacheMsg are generated by copying values from a RubyRequest
 object.
 
 
 Diffs
 -
 
   src/mem/protocol/MESI_CMP_directory-L1cache.sm c1c6f36e118e 
   src/mem/protocol/MI_example-cache.sm c1c6f36e118e 
   src/mem/protocol/MOESI_CMP_directory-L1cache.sm c1c6f36e118e 
   src/mem/protocol/MOESI_CMP_token-L1cache.sm c1c6f36e118e 
   src/mem/protocol/MOESI_hammer-cache.sm c1c6f36e118e 
   src/mem/protocol/RubySlicc_Exports.sm c1c6f36e118e 
   src/mem/protocol/RubySlicc_Profiler.sm c1c6f36e118e 
   src/mem/protocol/RubySlicc_Types.sm c1c6f36e118e 
   src/mem/ruby/profiler/AddressProfiler.hh c1c6f36e118e 
   src/mem/ruby/profiler/AddressProfiler.cc c1c6f36e118e 
   src/mem/ruby/profiler/Profiler.hh c1c6f36e118e 
   src/mem/ruby/profiler/Profiler.cc c1c6f36e118e 
   src/mem/ruby/recorder/TraceRecord.cc c1c6f36e118e 
   src/mem/ruby/slicc_interface/RubyRequest.hh c1c6f36e118e 
   src/mem/ruby/slicc_interface/RubyRequest.cc c1c6f36e118e 
   src/mem/ruby/slicc_interface/RubySlicc_Profiler_interface.hh c1c6f36e118e 
   src/mem/ruby/slicc_interface/RubySlicc_Util.hh c1c6f36e118e 
   src/mem/ruby/system/CacheMemory.hh c1c6f36e118e 
   src/mem/ruby/system/CacheMemory.cc c1c6f36e118e 
   src/mem/ruby/system/DMASequencer.cc c1c6f36e118e 
   src/mem/ruby/system/RubyPort.cc c1c6f36e118e 
   src/mem/ruby/system/Sequencer.cc c1c6f36e118e 
 
 Diff: http://reviews.m5sim.org/r/327/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: Convert CacheRequestType to RubyRequestType

2011-03-19 Thread Brad Beckmann

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

Ship it!


- Brad


On 2011-03-18 21:55:58, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/602/
 ---
 
 (Updated 2011-03-18 21:55:58)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Convert CacheRequestType to RubyRequestType
 This patch converts CacheRequestType to RubyRequestType so that both the
 protocol dependent and independent code makes use of the same request type.
 
 
 Diffs
 -
 
   src/mem/protocol/MESI_CMP_directory-L1cache.sm 9a6a02a235f1 
   src/mem/protocol/MI_example-cache.sm 9a6a02a235f1 
   src/mem/protocol/MOESI_CMP_directory-L1cache.sm 9a6a02a235f1 
   src/mem/protocol/MOESI_CMP_token-L1cache.sm 9a6a02a235f1 
   src/mem/protocol/MOESI_hammer-cache.sm 9a6a02a235f1 
   src/mem/protocol/RubySlicc_Exports.sm 9a6a02a235f1 
   src/mem/ruby/profiler/AccessTraceForAddress.hh 9a6a02a235f1 
   src/mem/ruby/profiler/AccessTraceForAddress.cc 9a6a02a235f1 
   src/mem/ruby/profiler/AddressProfiler.hh 9a6a02a235f1 
   src/mem/ruby/profiler/AddressProfiler.cc 9a6a02a235f1 
   src/mem/ruby/profiler/CacheProfiler.hh 9a6a02a235f1 
   src/mem/ruby/profiler/CacheProfiler.cc 9a6a02a235f1 
   src/mem/ruby/profiler/Profiler.hh 9a6a02a235f1 
   src/mem/ruby/profiler/Profiler.cc 9a6a02a235f1 
   src/mem/ruby/recorder/CacheRecorder.hh 9a6a02a235f1 
   src/mem/ruby/recorder/Tracer.hh 9a6a02a235f1 
   src/mem/ruby/slicc_interface/RubyRequest.hh 9a6a02a235f1 
   src/mem/ruby/slicc_interface/RubyRequest.cc 9a6a02a235f1 
   src/mem/ruby/slicc_interface/RubySlicc_Util.hh 9a6a02a235f1 
   src/mem/ruby/system/CacheMemory.hh 9a6a02a235f1 
   src/mem/ruby/system/CacheMemory.cc 9a6a02a235f1 
   src/mem/ruby/system/DMASequencer.cc 9a6a02a235f1 
   src/mem/ruby/system/Sequencer.hh 9a6a02a235f1 
   src/mem/ruby/system/Sequencer.cc 9a6a02a235f1 
 
 Diff: http://reviews.m5sim.org/r/602/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: Convert AccessModeType to RubyAccessMode

2011-03-19 Thread Brad Beckmann

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

Ship it!


- Brad


On 2011-03-18 21:55:08, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/601/
 ---
 
 (Updated 2011-03-18 21:55:08)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Convert AccessModeType to RubyAccessMode
 This patch converts AccessModeType to RubyAccessMode so that both the
 protocol dependent and independent code uses the same access mode.
 
 
 Diffs
 -
 
   src/cpu/testers/rubytest/Check.hh 9a6a02a235f1 
   src/cpu/testers/rubytest/Check.cc 9a6a02a235f1 
   src/mem/protocol/MESI_CMP_directory-msg.sm 9a6a02a235f1 
   src/mem/protocol/MOESI_CMP_directory-msg.sm 9a6a02a235f1 
   src/mem/protocol/MOESI_CMP_token-L1cache.sm 9a6a02a235f1 
   src/mem/protocol/MOESI_CMP_token-dir.sm 9a6a02a235f1 
   src/mem/protocol/MOESI_CMP_token-msg.sm 9a6a02a235f1 
   src/mem/protocol/RubySlicc_Exports.sm 9a6a02a235f1 
   src/mem/protocol/RubySlicc_Types.sm 9a6a02a235f1 
   src/mem/ruby/profiler/AccessTraceForAddress.hh 9a6a02a235f1 
   src/mem/ruby/profiler/AccessTraceForAddress.cc 9a6a02a235f1 
   src/mem/ruby/profiler/AddressProfiler.hh 9a6a02a235f1 
   src/mem/ruby/profiler/AddressProfiler.cc 9a6a02a235f1 
   src/mem/ruby/profiler/CacheProfiler.hh 9a6a02a235f1 
   src/mem/ruby/profiler/CacheProfiler.cc 9a6a02a235f1 
   src/mem/ruby/profiler/Profiler.hh 9a6a02a235f1 
   src/mem/ruby/slicc_interface/RubyRequest.hh 9a6a02a235f1 
   src/mem/ruby/system/CacheMemory.hh 9a6a02a235f1 
   src/mem/ruby/system/CacheMemory.cc 9a6a02a235f1 
   src/mem/ruby/system/Sequencer.hh 9a6a02a235f1 
   src/mem/ruby/system/Sequencer.cc 9a6a02a235f1 
 
 Diff: http://reviews.m5sim.org/r/601/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Nilay
 


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


[m5-dev] changeset in m5: MOESI_CMP_directory: significant dma bug fixes

2011-03-19 Thread Brad Beckmann
changeset d2cf4b19e8ad in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=d2cf4b19e8ad
description:
MOESI_CMP_directory: significant dma bug fixes

diffstat:

 src/mem/protocol/MOESI_CMP_directory-L1cache.sm |   67 -
 src/mem/protocol/MOESI_CMP_directory-L2cache.sm |  171 ---
 src/mem/protocol/MOESI_CMP_directory-dir.sm |   27 +++-
 src/mem/protocol/MOESI_CMP_directory-dma.sm |4 +
 src/mem/protocol/MOESI_CMP_directory-msg.sm |1 -
 5 files changed, 233 insertions(+), 37 deletions(-)

diffs (truncated from 637 to 300 lines):

diff -r 9a6a02a235f1 -r d2cf4b19e8ad 
src/mem/protocol/MOESI_CMP_directory-L1cache.sm
--- a/src/mem/protocol/MOESI_CMP_directory-L1cache.sm   Fri Mar 18 14:12:04 
2011 -0500
+++ b/src/mem/protocol/MOESI_CMP_directory-L1cache.sm   Sat Mar 19 14:17:48 
2011 -0700
@@ -663,10 +663,27 @@
   }
 
 
+  action(ub_dmaUnblockL2Cache, ub, desc=Send dma ack to l2 cache) {
+peek(requestNetwork_in, RequestMsg) {
+  enqueue(responseNetwork_out, ResponseMsg, latency=request_latency) {
+out_msg.Address := address;
+out_msg.Type := CoherenceResponseType:DMA_ACK;
+out_msg.Sender := machineID;
+out_msg.SenderMachine := MachineType:L1Cache;
+out_msg.Destination.add(mapAddressToRange(address, 
MachineType:L2Cache, 
+l2_select_low_bit, l2_select_num_bits));
+out_msg.Dirty := false;
+out_msg.Acks := 1;
+out_msg.MessageSize := MessageSizeType:Response_Control;
+  }
+}
+  }
+
   action(q_sendDataFromTBEToCache, q, desc=Send data from TBE to cache) {
 peek(requestNetwork_in, RequestMsg) {
   assert(is_valid(tbe));
-  if (in_msg.RequestorMachine == MachineType:L1Cache) {
+  if (in_msg.RequestorMachine == MachineType:L1Cache || 
+  in_msg.RequestorMachine == MachineType:DMA) {
 enqueue(responseNetwork_out, ResponseMsg, latency=request_latency) {
   out_msg.Address := address;
   out_msg.Type := CoherenceResponseType:DATA;
@@ -895,11 +912,17 @@
 l_popForwardQueue;
   }
 
-  transition(S, {Fwd_GETS, Fwd_DMA}) {
+  transition(S, Fwd_GETS) {
 e_sendData;
 l_popForwardQueue;
   }
 
+  transition(S, Fwd_DMA) {
+e_sendData;
+ub_dmaUnblockL2Cache;
+l_popForwardQueue;
+  }
+
   // Transitions from Owned
   transition({O, OM}, {Load, Ifetch}) {
 h_load_hit;
@@ -924,11 +947,17 @@
 l_popForwardQueue;
   }
 
-  transition(O, {Fwd_GETS, Fwd_DMA}) {
+  transition(O, Fwd_GETS) {
 e_sendData;
 l_popForwardQueue;
   }
 
+  transition(O, Fwd_DMA) {
+e_sendData;
+ub_dmaUnblockL2Cache;
+l_popForwardQueue;
+  }
+
   // Transitions from MM
   transition({MM, MM_W}, {Load, Ifetch}) {
 h_load_hit;
@@ -957,8 +986,8 @@
   }
 
   transition(MM, Fwd_DMA, MM) {
-//ee_sendDataExclusive;
 e_sendData;
+ub_dmaUnblockL2Cache;
 l_popForwardQueue;
   }
 
@@ -995,8 +1024,9 @@
 l_popForwardQueue;
   }
 
-  transition(M, Fwd_DMA, M) {
+  transition(M, Fwd_DMA) {
 e_sendData;
+ub_dmaUnblockL2Cache;
 l_popForwardQueue;
   }
 
@@ -1039,11 +1069,17 @@
 n_popResponseQueue;
   }
 
-  transition(SM, {Fwd_DMA, Fwd_GETS}) {
+  transition(SM, Fwd_GETS) {
 e_sendData;
 l_popForwardQueue;
   }
 
+  transition(SM, Fwd_DMA) {
+e_sendData;
+ub_dmaUnblockL2Cache;
+l_popForwardQueue;
+  }
+
   // Transitions from OM
   transition(OM, Own_GETX) {
 mm_decrementNumberOfMessages;
@@ -1058,11 +1094,17 @@
 l_popForwardQueue;
   }
 
-  transition(OM, {Fwd_DMA, Fwd_GETS}, OM) {
+  transition(OM, Fwd_GETS) {
 e_sendData;
 l_popForwardQueue;
   }
 
+  transition(OM, Fwd_DMA) {
+e_sendData;
+ub_dmaUnblockL2Cache;
+l_popForwardQueue;
+  }
+
   //transition({OM, OMF}, Ack) {
   transition(OM, Ack) {
 m_decrementNumberOfMessages;
@@ -1119,8 +1161,9 @@
 l_popForwardQueue;
   }
 
-  transition(MI, Fwd_DMA, MI) {
+  transition(MI, Fwd_DMA) {
 q_sendDataFromTBEToCache;
+ub_dmaUnblockL2Cache;
 l_popForwardQueue;
   }
 
@@ -1129,11 +1172,17 @@
 l_popForwardQueue;
   }
 
-  transition({SI, OI}, {Fwd_DMA, Fwd_GETS}) {
+  transition({SI, OI}, Fwd_GETS) {
 q_sendDataFromTBEToCache;
 l_popForwardQueue;
   }
 
+  transition({SI, OI}, Fwd_DMA) {
+q_sendDataFromTBEToCache;
+ub_dmaUnblockL2Cache;
+l_popForwardQueue;
+  }
+
   transition(OI, Fwd_GETX, II) {
 q_sendExclusiveDataFromTBEToCache;
 l_popForwardQueue;
diff -r 9a6a02a235f1 -r d2cf4b19e8ad 
src/mem/protocol/MOESI_CMP_directory-L2cache.sm
--- a/src/mem/protocol/MOESI_CMP_directory-L2cache.sm   Fri Mar 18 14:12:04 
2011 -0500
+++ b/src/mem/protocol/MOESI_CMP_directory-L2cache.sm   Sat Mar 19 14:17:48 
2011 -0700
@@ -125,6 +125,13 @@
 MII, AccessPermission:Busy, desc=Blocked, doing writeback, was M, got 
Fwd_GETX;
 OLSI, AccessPermission:Busy, desc=Blocked, doing writeback, was OLS;
 ILSI, AccessPermission:Busy, desc=Blocked, doing 

[m5-dev] changeset in m5: MOESI_hammer: fixed dma bug with shared data

2011-03-19 Thread Brad Beckmann
changeset 519fba665871 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=519fba665871
description:
MOESI_hammer: fixed dma bug with shared data

diffstat:

 src/mem/protocol/MOESI_hammer-cache.sm |  35 +
 src/mem/protocol/MOESI_hammer-dir.sm   |   4 +-
 2 files changed, 32 insertions(+), 7 deletions(-)

diffs (90 lines):

diff -r d2cf4b19e8ad -r 519fba665871 src/mem/protocol/MOESI_hammer-cache.sm
--- a/src/mem/protocol/MOESI_hammer-cache.smSat Mar 19 14:17:48 2011 -0700
+++ b/src/mem/protocol/MOESI_hammer-cache.smSat Mar 19 14:17:48 2011 -0700
@@ -560,7 +560,7 @@
 }
   }
 
-  action(ee_sendDataShared, \e, desc=Send data from cache to requestor, 
keep a shared copy) {
+  action(ee_sendDataShared, \e, desc=Send data from cache to requestor, 
remaining the owner) {
 peek(forwardToCache_in, RequestMsg) {
   enqueue(responseNetwork_out, ResponseMsg, 
latency=cache_response_latency) {
 assert(is_valid(cache_entry));
@@ -584,7 +584,7 @@
 }
   }
   
-  action(em_sendDataSharedMultiple, em, desc=Send data from cache to all 
requestors) {
+  action(em_sendDataSharedMultiple, em, desc=Send data from cache to all 
requestors, still the owner) {
 peek(forwardToCache_in, RequestMsg) {
   enqueue(responseNetwork_out, ResponseMsg, 
latency=cache_response_latency) {
 assert(is_valid(cache_entry));
@@ -874,12 +874,37 @@
 }
   }
 
-  action(qm_sendDataFromTBEToCache, qm, desc=Send data from TBE to cache, 
multiple sharers) {
+  action(sq_sendSharedDataFromTBEToCache, sq, desc=Send shared data from 
TBE to cache, still the owner) {
+peek(forwardToCache_in, RequestMsg) {
+assert(in_msg.Requestor != machineID);
+  enqueue(responseNetwork_out, ResponseMsg, 
latency=cache_response_latency) {
+assert(is_valid(tbe));
+out_msg.Address := address;
+out_msg.Type := CoherenceResponseType:DATA_SHARED;
+out_msg.Sender := machineID;
+out_msg.Destination.add(in_msg.Requestor);
+DPRINTF(RubySlicc, %s\n, out_msg.Destination);
+out_msg.DataBlk := tbe.DataBlk;
+out_msg.Dirty := tbe.Dirty;
+if (in_msg.DirectedProbe) {
+  out_msg.Acks := machineCount(MachineType:L1Cache);
+} else {
+  out_msg.Acks := 2;
+}
+out_msg.SilentAcks := in_msg.SilentAcks;
+out_msg.MessageSize := MessageSizeType:Response_Data;
+out_msg.InitialRequestTime := in_msg.InitialRequestTime;
+out_msg.ForwardRequestTime := in_msg.ForwardRequestTime;
+  }
+}
+  }
+
+  action(qm_sendDataFromTBEToCache, qm, desc=Send data from TBE to cache, 
multiple sharers, still the owner) {
 peek(forwardToCache_in, RequestMsg) {
   enqueue(responseNetwork_out, ResponseMsg, 
latency=cache_response_latency) {
 assert(is_valid(tbe));
 out_msg.Address := address;
-out_msg.Type := CoherenceResponseType:DATA;
+out_msg.Type := CoherenceResponseType:DATA_SHARED;
 out_msg.Sender := machineID;
 out_msg.Destination := in_msg.MergedRequestors;
 DPRINTF(RubySlicc, %s\n, out_msg.Destination);
@@ -1599,7 +1624,7 @@
   }
 
   transition({OI, MI}, {NC_DMA_GETS, Other_GETS, Other_GETS_No_Mig}, OI) {
-q_sendDataFromTBEToCache;
+sq_sendSharedDataFromTBEToCache;
 l_popForwardQueue;
   }
 
diff -r d2cf4b19e8ad -r 519fba665871 src/mem/protocol/MOESI_hammer-dir.sm
--- a/src/mem/protocol/MOESI_hammer-dir.sm  Sat Mar 19 14:17:48 2011 -0700
+++ b/src/mem/protocol/MOESI_hammer-dir.sm  Sat Mar 19 14:17:48 2011 -0700
@@ -1500,14 +1500,14 @@
 
   transition(O_DR_B, Shared_Ack) {
 m_decrementNumberOfMessages;
-so_setOwnerBit;
+r_setSharerBit;
 o_checkForCompletion;
 n_popResponseQueue;
   }
 
   transition(O_DR_B_W, Shared_Ack) {
 m_decrementNumberOfMessages;
-so_setOwnerBit;
+r_setSharerBit;
 n_popResponseQueue;
   }
 
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev


[m5-dev] changeset in m5: slicc: improved invalid transition message

2011-03-19 Thread Brad Beckmann
changeset de9e34de70ff in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=de9e34de70ff
description:
slicc: improved invalid transition message

diffstat:

 src/mem/slicc/symbols/StateMachine.py |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diffs (14 lines):

diff -r 519fba665871 -r de9e34de70ff src/mem/slicc/symbols/StateMachine.py
--- a/src/mem/slicc/symbols/StateMachine.py Sat Mar 19 14:17:48 2011 -0700
+++ b/src/mem/slicc/symbols/StateMachine.py Sat Mar 19 14:17:48 2011 -0700
@@ -1232,8 +1232,8 @@
 code('''
   default:
 fatal(Invalid transition\\n
-  version: %d time: %d addr: %s event: %s state: %s\\n,
-  m_version, g_eventQueue_ptr-getTime(), addr, event, state);
+  %s time: %d addr: %s event: %s state: %s\\n,
+  name(), g_eventQueue_ptr-getTime(), addr, event, state);
 }
 return TransitionResult_Valid;
 }
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev


[m5-dev] changeset in m5: ruby: added useful dma progress dprintf

2011-03-19 Thread Brad Beckmann
changeset 0b3252d3b400 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=0b3252d3b400
description:
ruby: added useful dma progress dprintf

diffstat:

 src/mem/ruby/system/DMASequencer.cc |  5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diffs (15 lines):

diff -r de9e34de70ff -r 0b3252d3b400 src/mem/ruby/system/DMASequencer.cc
--- a/src/mem/ruby/system/DMASequencer.cc   Sat Mar 19 14:17:48 2011 -0700
+++ b/src/mem/ruby/system/DMASequencer.cc   Sat Mar 19 14:17:48 2011 -0700
@@ -150,7 +150,10 @@
 assert(m_mandatory_q_ptr != NULL);
 m_mandatory_q_ptr-enqueue(msg);
 active_request.bytes_issued += msg-getLen();
-DPRINTF(RubyDma, Next DMA segment issued to the DMA cntrl\n);
+DPRINTF(RubyDma, 
+DMA request bytes issued %d, bytes completed %d, total len %d\n,
+active_request.bytes_issued, active_request.bytes_completed,
+active_request.len);
 }
 
 void
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev


[m5-dev] changeset in m5: RubyPort: minor fixes to trace flag and dprintfs

2011-03-19 Thread Brad Beckmann
changeset ebb373fcb206 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=ebb373fcb206
description:
RubyPort: minor fixes to trace flag and dprintfs

diffstat:

 src/mem/SConscript  |   4 ++--
 src/mem/ruby/system/RubyPort.cc |  30 +++---
 2 files changed, 17 insertions(+), 17 deletions(-)

diffs (141 lines):

diff -r 0b3252d3b400 -r ebb373fcb206 src/mem/SConscript
--- a/src/mem/SConscriptSat Mar 19 14:17:48 2011 -0700
+++ b/src/mem/SConscriptSat Mar 19 14:17:48 2011 -0700
@@ -66,12 +66,12 @@
 TraceFlag('RubyGenerated')
 TraceFlag('RubyMemory')
 TraceFlag('RubyNetwork')
+TraceFlag('RubyPort')
 TraceFlag('RubyQueue')
-TraceFlag('RubyPort')
 TraceFlag('RubySlicc')
 TraceFlag('RubyStorebuffer')
 TraceFlag('RubyTester')
 
 CompoundFlag('Ruby', [ 'RubyQueue', 'RubyNetwork', 'RubyTester',
 'RubyGenerated', 'RubySlicc', 'RubyStorebuffer', 'RubyCache', 
-'RubyMemory', 'RubyDma'])
+'RubyMemory', 'RubyDma', 'RubyPort'])
diff -r 0b3252d3b400 -r ebb373fcb206 src/mem/ruby/system/RubyPort.cc
--- a/src/mem/ruby/system/RubyPort.cc   Sat Mar 19 14:17:48 2011 -0700
+++ b/src/mem/ruby/system/RubyPort.cc   Sat Mar 19 14:17:48 2011 -0700
@@ -103,7 +103,7 @@
RubyPort *_port)
 : SimpleTimingPort(_name, _port)
 {
-DPRINTF(Ruby, creating port to ruby sequencer to cpu %s\n, _name);
+DPRINTF(RubyPort, creating port to ruby sequencer to cpu %s\n, _name);
 ruby_port = _port;
 }
 
@@ -111,7 +111,7 @@
  RubyPort *_port, bool _access_phys_mem)
 : SimpleTimingPort(_name, _port)
 {
-DPRINTF(Ruby, creating port from ruby sequcner to cpu %s\n, _name);
+DPRINTF(RubyPort, creating port from ruby sequcner to cpu %s\n, _name);
 ruby_port = _port;
 _onRetryList = false;
 access_phys_mem = _access_phys_mem;
@@ -137,7 +137,7 @@
 {
 // In FS mode, ruby memory will receive pio responses from devices
 // and it must forward these responses back to the particular CPU.
-DPRINTF(MemoryAccess,  Pio response for address %#x\n, pkt-getAddr());
+DPRINTF(RubyPort,  Pio response for address %#x\n, pkt-getAddr());
 
 assert(pkt-isResponse());
 
@@ -159,7 +159,7 @@
 bool
 RubyPort::M5Port::recvTiming(PacketPtr pkt)
 {
-DPRINTF(MemoryAccess,
+DPRINTF(RubyPort,
 Timing access caught for address %#x\n, pkt-getAddr());
 
 //dsm: based on SimpleTimingPort::recvTiming(pkt);
@@ -186,7 +186,7 @@
 // pio port.
 if (!isPhysMemAddress(pkt-getAddr())) {
 assert(ruby_port-pio_port != NULL);
-DPRINTF(MemoryAccess,
+DPRINTF(RubyPort,
 Request for address 0x%#x is assumed to be a pio request\n,
 pkt-getAddr());
 
@@ -205,19 +205,19 @@
 
 if (pkt-isLLSC()) {
 if (pkt-isWrite()) {
-DPRINTF(MemoryAccess, Issuing SC\n);
+DPRINTF(RubyPort, Issuing SC\n);
 type = RubyRequestType_Store_Conditional;
 } else {
-DPRINTF(MemoryAccess, Issuing LL\n);
+DPRINTF(RubyPort, Issuing LL\n);
 assert(pkt-isRead());
 type = RubyRequestType_Load_Linked;
 }
 } else if (pkt-req-isLocked()) {
 if (pkt-isWrite()) {
-DPRINTF(MemoryAccess, Issuing Locked RMW Write\n);
+DPRINTF(RubyPort, Issuing Locked RMW Write\n);
 type = RubyRequestType_Locked_RMW_Write;
 } else {
-DPRINTF(MemoryAccess, Issuing Locked RMW Read\n);
+DPRINTF(RubyPort, Issuing Locked RMW Read\n);
 assert(pkt-isRead());
 type = RubyRequestType_Locked_RMW_Read;
 }
@@ -263,7 +263,7 @@
 // Otherwise, we need to delete the senderStatus we just created and return
 // false.
 if (requestStatus == RequestStatus_Issued) {
-DPRINTF(MemoryAccess, Request %x issued\n, pkt-getAddr());
+DPRINTF(RubyPort, Request %#x issued\n, pkt-getAddr());
 return true;
 }
 
@@ -275,7 +275,7 @@
 ruby_port-addToRetryList(this);
 }
 
-DPRINTF(MemoryAccess,
+DPRINTF(RubyPort,
 Request for address %#x did not issue because %s\n,
 pkt-getAddr(), RequestStatus_to_string(requestStatus));
 
@@ -351,7 +351,7 @@
 pkt-convertLlToRead();
 }
 }
-DPRINTF(MemoryAccess, Hit callback needs response %d\n, needsResponse);
+DPRINTF(RubyPort, Hit callback needs response %d\n, needsResponse);
 
 if (accessPhysMem) {
 ruby_port-physMemPort-sendAtomic(pkt);
@@ -361,12 +361,12 @@
 
 // turn packet around to go back to requester if response expected
 if (needsResponse) {
-DPRINTF(MemoryAccess, Sending packet back over port\n);
+DPRINTF(RubyPort, Sending packet back over port\n);
 sendTiming(pkt);
 } else {
 delete pkt;
 }
-DPRINTF(MemoryAccess, Hit callback done!\n);
+DPRINTF(RubyPort, Hit callback done!\n);
 }

[m5-dev] changeset in m5: Ruby: dma retry fix

2011-03-19 Thread Brad Beckmann
changeset 5f69f1b0039e in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=5f69f1b0039e
description:
Ruby: dma retry fix

This patch fixes the problem where Ruby would fail to call sendRetry on 
ports
after it nacked the port.  This patch is particularly helpful for 
bursty dma
requests which often include several packets.

diffstat:

 src/mem/ruby/system/DMASequencer.cc |   8 ++--
 src/mem/ruby/system/RubyPort.cc |  24 +---
 2 files changed, 23 insertions(+), 9 deletions(-)

diffs (56 lines):

diff -r ebb373fcb206 -r 5f69f1b0039e src/mem/ruby/system/DMASequencer.cc
--- a/src/mem/ruby/system/DMASequencer.cc   Sat Mar 19 14:17:48 2011 -0700
+++ b/src/mem/ruby/system/DMASequencer.cc   Sat Mar 19 14:17:48 2011 -0700
@@ -116,9 +116,13 @@
 assert(m_is_busy == true);
 active_request.bytes_completed = active_request.bytes_issued;
 if (active_request.len == active_request.bytes_completed) {
-DPRINTF(RubyDma, DMA request completed\n); 
+//
+// Must unset the busy flag before calling back the dma port because
+// the callback may cause a previously nacked request to be reissued
+//
+DPRINTF(RubyDma, DMA request completed\n);
+m_is_busy = false;
 ruby_hit_callback(active_request.pkt);
-m_is_busy = false;
 return;
 }
 
diff -r ebb373fcb206 -r 5f69f1b0039e src/mem/ruby/system/RubyPort.cc
--- a/src/mem/ruby/system/RubyPort.cc   Sat Mar 19 14:17:48 2011 -0700
+++ b/src/mem/ruby/system/RubyPort.cc   Sat Mar 19 14:17:48 2011 -0700
@@ -305,16 +305,26 @@
 // likely has free resources now.
 //
 if (waitingOnSequencer) {
-for (std::listM5Port*::iterator i = retryList.begin();
- i != retryList.end(); ++i) {
-(*i)-sendRetry();
-(*i)-onRetryList(false);
-DPRINTF(MemoryAccess,
+//
+// Record the current list of ports to retry on a temporary list before
+// calling sendRetry on those ports.  sendRetry will cause an 
+// immediate retry, which may result in the ports being put back on the
+// list. Therefore we want to clear the retryList before calling
+// sendRetry.
+//
+std::listM5Port* curRetryList(retryList);
+
+retryList.clear();
+waitingOnSequencer = false;
+
+for (std::listM5Port*::iterator i = curRetryList.begin();
+ i != curRetryList.end(); ++i) {
+DPRINTF(RubyPort,
 Sequencer may now be free.  SendRetry to port %s\n,
 (*i)-name());
+(*i)-onRetryList(false);
+(*i)-sendRetry();
 }
-retryList.clear();
-waitingOnSequencer = false;
 }
 }
 
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev


[m5-dev] changeset in m5: MOESI_hammer: minor fixes to full-bit dir

2011-03-19 Thread Brad Beckmann
changeset 19a654839a04 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=19a654839a04
description:
MOESI_hammer: minor fixes to full-bit dir

diffstat:

 src/mem/protocol/MOESI_hammer-dir.sm |  8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diffs (39 lines):

diff -r 5f69f1b0039e -r 19a654839a04 src/mem/protocol/MOESI_hammer-dir.sm
--- a/src/mem/protocol/MOESI_hammer-dir.sm  Sat Mar 19 14:17:48 2011 -0700
+++ b/src/mem/protocol/MOESI_hammer-dir.sm  Sat Mar 19 14:17:48 2011 -0700
@@ -186,7 +186,7 @@
   }
 
   PfEntry getProbeFilterEntry(Address addr), return_by_pointer=yes {
-if(probe_filter_enabled) {
+if (probe_filter_enabled || full_bit_dir_enabled) {
   PfEntry pfEntry := static_cast(PfEntry, pointer, 
probeFilter.lookup(addr));
   return pfEntry;
 }
@@ -200,8 +200,6 @@
   if (probe_filter_enabled || full_bit_dir_enabled) {
 if (is_valid(pf_entry)) {
   assert(pf_entry.PfState == getDirectoryEntry(addr).DirectoryState);
-} else {
-  assert(getDirectoryEntry(addr).DirectoryState == State:E);
 }
   }
   return getDirectoryEntry(addr).DirectoryState;
@@ -219,6 +217,9 @@
   if (state == State:NX || state == State:NO || state == State:S || state 
== State:O) {
 assert(is_valid(pf_entry));
   }
+  if (state == State:E) {
+assert(is_valid(pf_entry) == false);
+  }
 }
 if (state == State:E || state == State:NX || state == State:NO || state == 
State:S || 
 state == State:O) {
@@ -469,6 +470,7 @@
   peek(requestQueue_in, RequestMsg) {
 set_cache_entry(probeFilter.allocate(address, new PfEntry));
 cache_entry.Owner := in_msg.Requestor;
+cache_entry.Sharers.setSize(machineCount(MachineType:L1Cache));
   }
 }
   }
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev


Re: [m5-dev] Review Request: base: disable FastAlloc in debug builds by default

2011-03-16 Thread Brad Beckmann

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

Ship it!


- Brad


On 2011-03-16 10:58:50, Steve Reinhardt wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/586/
 ---
 
 (Updated 2011-03-16 10:58:50)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 base: disable FastAlloc in debug builds by default
 
 FastAlloc's reuse policies can mask allocation bugs, so
 we typically want it disabled when debugging.  Set
 FORCE_FAST_ALLOC to enable even when debugging, and set
 NO_FAST_ALLOC to disable even in non-debug builds.
 
 
 Diffs
 -
 
   SConstruct 6c9b532da0a6 
   src/base/fast_alloc.hh 6c9b532da0a6 
   src/base/fast_alloc.cc 6c9b532da0a6 
 
 Diff: http://reviews.m5sim.org/r/586/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Steve
 


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


Re: [m5-dev] Review Request: Network Tester Patch

2011-03-15 Thread Brad Beckmann

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


Hi Tushar,

This patch basically looks done to me.  I just have a few minor comments below. 
 It seems that there are a few parameters that aren't used and should be 
removed.  Also I think you should add a better explanation of the expected 
values for the injection rate. 



configs/example/ruby_network_test.py
http://reviews.m5sim.org/r/561/#comment1339

Why multiply by 1000?  What is the expected range of injection rate?



src/cpu/testers/networktest/NetworkTest.py
http://reviews.m5sim.org/r/561/#comment1343

Is this parameter used?   If so, what does address to trace mean?



src/cpu/testers/networktest/NetworkTest.py
http://reviews.m5sim.org/r/561/#comment1341

I think you can remove the functional port now, correct?



src/cpu/testers/networktest/networktest.cc
http://reviews.m5sim.org/r/561/#comment1342

Again, I think you can remove the functional port.


- Brad


On 2011-03-15 01:14:34, Tushar Krishna wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/561/
 ---
 
 (Updated 2011-03-15 01:14:34)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, Nathan 
 Binkert, and Brad Beckmann.
 
 
 Summary
 ---
 
 This patch adds the network tester for simple and garnet networks.
 The tester code is in testers/networktest.
 The tester can be invoked by configs/example/ruby_network_test.py.
 A dummy coherence protocol called Network_test is also addded for 
 network-only simulations and testing. The protocol takes in messages from the 
 tester and just pushes them into the network in the appropriate vnet, without 
 storing any state.
 
 
 Diffs
 -
 
   build_opts/ALPHA_SE_Network_test PRE-CREATION 
   configs/example/ruby_network_test.py PRE-CREATION 
   configs/ruby/Network_test.py PRE-CREATION 
   src/cpu/testers/networktest/NetworkTest.py PRE-CREATION 
   src/cpu/testers/networktest/SConscript PRE-CREATION 
   src/cpu/testers/networktest/networktest.hh PRE-CREATION 
   src/cpu/testers/networktest/networktest.cc PRE-CREATION 
   src/mem/protocol/Network_test-cache.sm PRE-CREATION 
   src/mem/protocol/Network_test-dir.sm PRE-CREATION 
   src/mem/protocol/Network_test-msg.sm PRE-CREATION 
   src/mem/protocol/Network_test.slicc PRE-CREATION 
   src/mem/protocol/SConsopts 6c9b532da0a6 
   src/mem/ruby/network/garnet/BaseGarnetNetwork.hh 6c9b532da0a6 
   src/mem/ruby/network/garnet/BaseGarnetNetwork.cc 6c9b532da0a6 
   src/mem/ruby/network/garnet/BaseGarnetNetwork.py 6c9b532da0a6 
   src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 6c9b532da0a6 
   src/mem/ruby/network/garnet/fixed-pipeline/NetworkInterface_d.cc 
 6c9b532da0a6 
   src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.cc 
 6c9b532da0a6 
   src/mem/ruby/system/Sequencer.hh 6c9b532da0a6 
   src/mem/ruby/system/Sequencer.cc 6c9b532da0a6 
   src/mem/ruby/system/Sequencer.py 6c9b532da0a6 
 
 Diff: http://reviews.m5sim.org/r/561/diff
 
 
 Testing
 ---
 
 Testing done with garnet and simple networks. I will update config 
 assumptions etc on the wiki.
 
 
 Thanks,
 
 Tushar
 


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


Re: [m5-dev] Review Request: This patch makes garnet use the info about active and inactive vnets during allocation and power estimations etc

2011-03-15 Thread Brad Beckmann

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

Ship it!


- Brad


On 2011-03-15 01:25:16, Tushar Krishna wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/585/
 ---
 
 (Updated 2011-03-15 01:25:16)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, Nathan 
 Binkert, and Brad Beckmann.
 
 
 Summary
 ---
 
 This patch makes garnet use the info about active and inactive vnets during 
 allocation and power estimations etc
 
 
 Diffs
 -
 
   src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 6c9b532da0a6 
   src/mem/ruby/network/garnet/fixed-pipeline/Router_d.hh 6c9b532da0a6 
   src/mem/ruby/network/garnet/fixed-pipeline/SWallocator_d.cc 6c9b532da0a6 
   src/mem/ruby/network/garnet/fixed-pipeline/VCallocator_d.cc 6c9b532da0a6 
   src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc 6c9b532da0a6 
   src/mem/ruby/network/garnet/flexible-pipeline/Router.hh 6c9b532da0a6 
   src/mem/ruby/network/garnet/flexible-pipeline/Router.cc 6c9b532da0a6 
   src/mem/ruby/network/orion/NetworkPower.cc 6c9b532da0a6 
 
 Diff: http://reviews.m5sim.org/r/585/diff
 
 
 Testing
 ---
 
 using Network_test
 
 
 Thanks,
 
 Tushar
 


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


Re: [m5-dev] Review Request: my initial implementation of cache flushing

2011-03-14 Thread Brad Beckmann

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


Hi Somayeh,

I just have one larger issue to mention, then a few minor comments.  See below 
for details.  The larger issue is that I believe one of the transitions you 
specify is unecessary (see specific comments below).  In general, be very 
careful about stalling the forwarded request queue.  That usually leads to 
deadlock.

To answer your questions:  Yes, it does not make sense for the flush requests 
to return data.  However, I don't think you want to add a new hitCallback 
function just for flushes.  Instead, it seems that if you set the data pointer 
to null, then Ruby won't actually do any data updates.  Subsequently, the 
function RubyPort::M5Port::hitCallback should add a condition that says if a 
flush request, set accessPhysMem to false.  Make sense?  Finally, yes please 
update Check.cc to not deal with data.  Flush reqeusts should not replace 
Checks (i.e. reads).  Instead they should be inserted randomly into the request 
stream.

Once you make those changes, please post your next patch.  I suspect that will 
be your final round of updates.


src/mem/protocol/MOESI_hammer-cache.sm
http://reviews.m5sim.org/r/552/#comment1334

Can these transitions even happen?  If I understand the protocol correctly, 
I don't think so because the directory is already blocked once one enters the 
MI_F state.  

Stalling the forward request network can lead to deadlock.  In this 
particular case, I don't think it will because these transitions aren't 
actually executed, but in general this is bad practice.  I know the L2 to L1 
transfers stall the forward request network, but that is a special case to 
model transfer latency.

Please either describe exactly how this transition is encountered or remove 
it.

Thanks!



src/mem/protocol/MOESI_hammer-cache.sm
http://reviews.m5sim.org/r/552/#comment1333

What does the ///??? mean?  If I recall, the NC_DMA_GETS is an action 
used by uniprocessor systems.  Does that answer your question?



src/mem/ruby/system/Sequencer.cc
http://reviews.m5sim.org/r/552/#comment1335

missing space after } and before {



src/mem/ruby/system/Sequencer.cc
http://reviews.m5sim.org/r/552/#comment1336

move '+' to previous line and align m_flush... with equal sign.


- Brad


On 2011-03-13 19:50:32, Somayeh Sardashti wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/552/
 ---
 
 (Updated 2011-03-13 19:50:32)
 
 
 Review request for Default and Brad Beckmann.
 
 
 Summary
 ---
 
 my initial implementation of cache flushing
 
 
 Diffs
 -
 
   src/cpu/testers/rubytest/Check.hh baf4b5f6782e 
   src/cpu/testers/rubytest/Check.cc baf4b5f6782e 
   src/mem/packet.hh baf4b5f6782e 
   src/mem/packet.cc baf4b5f6782e 
   src/mem/protocol/MOESI_hammer-cache.sm baf4b5f6782e 
   src/mem/protocol/MOESI_hammer-dir.sm baf4b5f6782e 
   src/mem/protocol/MOESI_hammer-msg.sm baf4b5f6782e 
   src/mem/protocol/RubySlicc_Exports.sm baf4b5f6782e 
   src/mem/protocol/RubySlicc_Types.sm baf4b5f6782e 
   src/mem/ruby/slicc_interface/RubyRequest.hh baf4b5f6782e 
   src/mem/ruby/slicc_interface/RubyRequest.cc baf4b5f6782e 
   src/mem/ruby/system/DMASequencer.cc baf4b5f6782e 
   src/mem/ruby/system/RubyPort.cc baf4b5f6782e 
   src/mem/ruby/system/Sequencer.hh baf4b5f6782e 
   src/mem/ruby/system/Sequencer.cc baf4b5f6782e 
 
 Diff: http://reviews.m5sim.org/r/552/diff
 
 
 Testing
 ---
 
 This implementation has passed 10,000,000 ruby test cases, and the 
 MOESI_hammer regression tests.
 
 
 Thanks,
 
 Somayeh
 


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


Re: [m5-dev] Review Request: Network Tester Patch

2011-03-11 Thread Brad Beckmann

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


Hi Tushar,

I have a few minor comments below, but my major question is why does the config 
file create two versions of physical memory?  Do they really need to be 
accessed?  I suspect when we create this patch 1.5 years ago, that was 
required.  However since then, we added a feature that prevents the rubyport 
from accessing physical memory when it is unecessary.  I think this patch 
should use that feature.

Also once we add this patch to the repo, we should add the network test + 
garnet to the regression tester.  I'll add that to my list of outstanding 
regression tests.



configs/example/ruby_network_test.py
http://reviews.m5sim.org/r/561/#comment1310

The network test doesn't actually do any functional checks, correct?  If 
so, it seems that we can remove this line and instead tell the rubyport not to 
access physical memory.  For instance:

ruby_port.access_phys_mem = False



src/cpu/testers/networktest/networktest.cc
http://reviews.m5sim.org/r/561/#comment1309

Expand this comment a bit.  This is not straightforward.



src/cpu/testers/networktest/networktest.cc
http://reviews.m5sim.org/r/561/#comment1307

Please remove commented line.

Also if the network tester doesn't do any functional operation, why is 
funcmem specified in the config file?



src/mem/protocol/Network_test-cache.sm
http://reviews.m5sim.org/r/561/#comment1306

Please remove comment



src/mem/protocol/Network_test-cache.sm
http://reviews.m5sim.org/r/561/#comment1305

Please remove commented line



src/mem/protocol/Network_test-cache.sm
http://reviews.m5sim.org/r/561/#comment1308

You should add a comment here because it is not obvious what you're doing.  



src/mem/protocol/Network_test-dir.sm
http://reviews.m5sim.org/r/561/#comment1304

This comment should be removed.  



src/mem/protocol/Network_test-dir.sm
http://reviews.m5sim.org/r/561/#comment1303

Please remove the commented out lines.


- Brad


On 2011-03-11 09:33:50, Tushar Krishna wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/561/
 ---
 
 (Updated 2011-03-11 09:33:50)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, Nathan 
 Binkert, and Brad Beckmann.
 
 
 Summary
 ---
 
 This patch adds the network tester for simple and garnet networks.
 The tester code is in testers/networktest.
 The tester can be invoked by configs/example/ruby_network_test.py.
 A dummy coherence protocol called Network_test is also addded for 
 network-only simulations and testing. The protocol takes in messages from the 
 tester and just pushes them into the network in the appropriate vnet, without 
 storing any state.
 
 
 Diffs
 -
 
   build_opts/ALPHA_SE_Network_test PRE-CREATION 
   configs/example/ruby_network_test.py PRE-CREATION 
   configs/ruby/Network_test.py PRE-CREATION 
   src/cpu/testers/networktest/NetworkTest.py PRE-CREATION 
   src/cpu/testers/networktest/SConscript PRE-CREATION 
   src/cpu/testers/networktest/networktest.hh PRE-CREATION 
   src/cpu/testers/networktest/networktest.cc PRE-CREATION 
   src/mem/protocol/Network_test-cache.sm PRE-CREATION 
   src/mem/protocol/Network_test-dir.sm PRE-CREATION 
   src/mem/protocol/Network_test-msg.sm PRE-CREATION 
   src/mem/protocol/Network_test.slicc PRE-CREATION 
   src/mem/protocol/SConsopts 159c07f22c8e 
   src/mem/ruby/network/garnet/BaseGarnetNetwork.hh 159c07f22c8e 
   src/mem/ruby/network/garnet/BaseGarnetNetwork.cc 159c07f22c8e 
   src/mem/ruby/network/garnet/BaseGarnetNetwork.py 159c07f22c8e 
   src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 159c07f22c8e 
   src/mem/ruby/network/garnet/fixed-pipeline/NetworkInterface_d.cc 
 159c07f22c8e 
   src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.cc 
 159c07f22c8e 
   src/mem/ruby/system/Sequencer.hh 159c07f22c8e 
   src/mem/ruby/system/Sequencer.cc 159c07f22c8e 
   src/mem/ruby/system/Sequencer.py 159c07f22c8e 
 
 Diff: http://reviews.m5sim.org/r/561/diff
 
 
 Testing
 ---
 
 Testing done with garnet and simple networks. I will update config 
 assumptions etc on the wiki.
 
 
 Thanks,
 
 Tushar
 


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


Re: [m5-dev] Review Request: MOESI_hammer: adding cache flushing

2011-03-08 Thread Brad Beckmann
 not exceed 80 characters per line.  (Yes, slicc code is the only 
exception)



src/mem/ruby/system/Sequencer.cc
http://reviews.m5sim.org/r/552/#comment1274

Again, 80 char.



src/mem/ruby/system/Sequencer.cc
http://reviews.m5sim.org/r/552/#comment1275

80 again here



src/mem/ruby/system/Sequencer.cc
http://reviews.m5sim.org/r/552/#comment1276

and here



src/mem/ruby/system/Sequencer.cc
http://reviews.m5sim.org/r/552/#comment1277

It seems that flush requests shouldn't even get to this condition.  
Shouldn't flush request data packets be set to NULL?



src/mem/ruby/system/Sequencer.cc
http://reviews.m5sim.org/r/552/#comment1278

80 chars


- Brad


On 2011-03-06 16:11:12, Somayeh Sardashti wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/552/
 ---
 
 (Updated 2011-03-06 16:11:12)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, Nathan 
 Binkert, and Brad Beckmann.
 
 
 Summary
 ---
 
 MOESI_hammer: adding cache flushing
 This patch adds cache flushing to MOESI_hammer. In order to flush a 
 cache line, a FLUSH request is issued. Flushing is basically a store to 
 a line (with no change to data) followed by a write back to the memory 
 (invalidation).
 
 At the L1 cache, up on a flush request, a GETF (similar to GETX) is 
 issued. When the directory processes this request, it gives the 
 exclusive permission, and blocks this line until the flush is done 
 (stalls other GETS/GETX/GETF requests). If the cache line is already in 
 a modified state (MM/M), the cache issues a BLOCK request to the 
 directory (instead of issuing GETF as the cache already has the line 
 exclusively), 
 which blocks the line until the flush is done.
 
 
 Diffs
 -
 
   src/cpu/testers/rubytest/Check.hh baf4b5f6782e 
   src/cpu/testers/rubytest/Check.cc baf4b5f6782e 
   src/mem/packet.hh baf4b5f6782e 
   src/mem/packet.cc baf4b5f6782e 
   src/mem/physical.cc baf4b5f6782e 
   src/mem/protocol/MOESI_hammer-cache.sm baf4b5f6782e 
   src/mem/protocol/MOESI_hammer-dir.sm baf4b5f6782e 
   src/mem/protocol/MOESI_hammer-msg.sm baf4b5f6782e 
   src/mem/protocol/RubySlicc_Exports.sm baf4b5f6782e 
   src/mem/protocol/RubySlicc_Types.sm baf4b5f6782e 
   src/mem/ruby/slicc_interface/RubyRequest.hh baf4b5f6782e 
   src/mem/ruby/slicc_interface/RubyRequest.cc baf4b5f6782e 
   src/mem/ruby/system/DMASequencer.cc baf4b5f6782e 
   src/mem/ruby/system/RubyPort.cc baf4b5f6782e 
   src/mem/ruby/system/Sequencer.hh baf4b5f6782e 
   src/mem/ruby/system/Sequencer.cc baf4b5f6782e 
 
 Diff: http://reviews.m5sim.org/r/552/diff
 
 
 Testing
 ---
 
 To test this implementation, I have changed the ruby tester (Check.cc). 
 It randomly creates flushes (instead of checks (loads)). In this 
 version, a flush request returns data, so it can be used like loads 
 after issuing some stores (actions). Currently, this implementation 
 passes more than 2 ruby tests (including more than 1000 flushes), 
 however there are still bugs, which cause deadlocks.
 
 
 Thanks,
 
 Somayeh
 


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


Re: [m5-dev] Review Request: Ruby: Add stall and wait to MESI CMP directory

2011-03-03 Thread Brad Beckmann

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


Do you have to always call wakeUpAllDependents?  Initially it atleast was my 
hope that the per cache block wakeUpDependents would be sufficient.  However, I 
could see that in certain situations where requets are stalled because a tbe 
entry is unavailable that the per address wakeUpDependents could lead to 
starvation.  Do you think we should just elimiate wakeUpDependents and just use 
wakeUpAllDependents? 

- Brad


On 2011-03-03 09:20:38, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/330/
 ---
 
 (Updated 2011-03-03 09:20:38)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 This patch adds the stall and wait on the mandatory queue of L1 cache 
 controller of the MESI CMP directory protocol. It is intended to be 
 more of a discussion (so as to improve my understanding).
 
 
 Diffs
 -
 
   src/cpu/testers/rubytest/RubyTester.py 92229cb0cee9 
   src/mem/protocol/MESI_CMP_directory-L1cache.sm 92229cb0cee9 
 
 Diff: http://reviews.m5sim.org/r/330/diff
 
 
 Testing
 ---
 
 The changes have been tested for 16 processors for 40 different random 
 seeds with number of loads varying from a 1,000,000 - 4,000,000. The only 
 concern is that I had to change the dead lock threshold in RubyTester.py
 which is surprising.
 
 
 Thanks,
 
 Nilay
 


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


Re: [m5-dev] Review Request: Ruby: Fix DPRINTF bugs in PerfectSwitch and MessageBuffer

2011-03-01 Thread Brad Beckmann

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

Ship it!


- Brad


On 2011-03-01 13:31:45, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/505/
 ---
 
 (Updated 2011-03-01 13:31:45)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 At a couple of places in PerfectSwitch.cc and MessageBuffer.cc, DPRINTF()
 has not been provided with correct number of arguments. The patch fixes these
 bugs.
 
 
 Diffs
 -
 
   src/mem/ruby/buffers/MessageBuffer.cc UNKNOWN 
   src/mem/ruby/network/simple/PerfectSwitch.cc UNKNOWN 
 
 Diff: http://reviews.m5sim.org/r/505/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: Remove store buffer

2011-02-25 Thread Brad Beckmann

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

Ship it!


- Brad


On 2011-02-25 08:33:43, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/507/
 ---
 
 (Updated 2011-02-25 08:33:43)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Remove store buffer
 This patch removes the store buffer from Ruby. It is not in use currently.
 Since libruby is being and store buffer makes calls to libruby, it is not
 possible to maintain it until substantial changes are made.
 
 
 Diffs
 -
 
   src/mem/ruby/storebuffer/SConscript 4a59661d3fd1 
   src/mem/ruby/storebuffer/stb_interface.hh 4a59661d3fd1 
   src/mem/ruby/storebuffer/stb_interface.cc 4a59661d3fd1 
   src/mem/ruby/storebuffer/storebuffer.hh 4a59661d3fd1 
   src/mem/ruby/storebuffer/storebuffer.cc 4a59661d3fd1 
 
 Diff: http://reviews.m5sim.org/r/507/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: Remove libruby

2011-02-25 Thread Brad Beckmann

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

Ship it!


- Brad


On 2011-02-25 08:32:18, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/439/
 ---
 
 (Updated 2011-02-25 08:32:18)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Remove libruby
 This patch removes libruby from Ruby. It is no longer required. The
 structures defined in this file have been moved to
 slicc_interface/RubyRequest.hh file.
 
 
 Diffs
 -
 
   src/mem/ruby/SConscript 4a59661d3fd1 
   src/mem/ruby/libruby.hh 4a59661d3fd1 
   src/mem/ruby/libruby.cc 4a59661d3fd1 
   src/mem/ruby/profiler/Profiler.hh 4a59661d3fd1 
   src/mem/ruby/recorder/Tracer.hh 4a59661d3fd1 
   src/mem/ruby/slicc_interface/RubyRequest.hh PRE-CREATION 
   src/mem/ruby/slicc_interface/RubyRequest.cc PRE-CREATION 
   src/mem/ruby/slicc_interface/SConscript 4a59661d3fd1 
   src/mem/ruby/storebuffer/storebuffer.hh 4a59661d3fd1 
   src/mem/ruby/storebuffer/storebuffer.cc 4a59661d3fd1 
   src/mem/ruby/system/RubyPort.hh 4a59661d3fd1 
   src/mem/ruby/system/Sequencer.cc 4a59661d3fd1 
 
 Diff: http://reviews.m5sim.org/r/439/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: Make Address.hh independent of RubySystem

2011-02-25 Thread Brad Beckmann

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

Ship it!


- Brad


On 2011-02-25 10:51:09, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/504/
 ---
 
 (Updated 2011-02-25 10:51:09)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 Ruby: Change Address.hh
 This patch changes Address.hh so that it is not dependent on RubySystem.
 This dependence seems unecessary. All those functions that depend on
 RubySystem have been moved to Address.cc file.
 
 
 Diffs
 -
 
   src/mem/ruby/common/Address.hh UNKNOWN 
   src/mem/ruby/common/Address.cc UNKNOWN 
   src/mem/ruby/filters/BlockBloomFilter.cc UNKNOWN 
   src/mem/ruby/filters/BulkBloomFilter.cc UNKNOWN 
   src/mem/ruby/filters/LSB_CountingBloomFilter.cc UNKNOWN 
   src/mem/ruby/filters/MultiGrainBloomFilter.cc UNKNOWN 
   src/mem/ruby/filters/NonCountingBloomFilter.cc UNKNOWN 
 
 Diff: http://reviews.m5sim.org/r/504/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: Make DataBlock.hh independent of RubySystem

2011-02-25 Thread Brad Beckmann

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

Ship it!


- Brad


On 2011-02-25 10:51:51, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/503/
 ---
 
 (Updated 2011-02-25 10:51:51)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Ruby: Change DataBlock.hh
 This patch changes DataBlock.hh so that it is not dependent on RubySystem.
 This dependence seems unecessary. All those functions that depende on
 RubySystem have been moved to DataBlock.cc file.
 
 
 Diffs
 -
 
   src/cpu/testers/rubytest/RubyTester.hh 4a59661d3fd1 
   src/mem/ruby/common/DataBlock.hh 4a59661d3fd1 
   src/mem/ruby/common/DataBlock.cc 4a59661d3fd1 
 
 Diff: http://reviews.m5sim.org/r/503/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Nilay
 


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


[m5-dev] changeset in m5: ruby: removed unsupported protocol files

2011-02-23 Thread Brad Beckmann
changeset bba14984f2ce in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=bba14984f2ce
description:
ruby: removed unsupported protocol files

diffstat:

 src/mem/protocol/MESI_SCMP_bankdirectory-L1cache.sm |   894 ---
 src/mem/protocol/MESI_SCMP_bankdirectory-L2cache.sm |  1052 -
 src/mem/protocol/MESI_SCMP_bankdirectory-mem.sm |   166 -
 src/mem/protocol/MESI_SCMP_bankdirectory-msg.sm |   112 -
 src/mem/protocol/MESI_SCMP_bankdirectory.slicc  | 5 -
 src/mem/protocol/MESI_SCMP_bankdirectory_m-mem.sm   |   250 --
 src/mem/protocol/MESI_SCMP_bankdirectory_m.slicc| 5 -
 src/mem/protocol/MOESI_CMP_directory-perfectDir.sm  |   573 
 src/mem/protocol/MOESI_SMP_directory-cache.sm   |   981 
 src/mem/protocol/MOESI_SMP_directory-dir.sm |   495 
 src/mem/protocol/MOESI_SMP_directory-msg.sm |89 -
 src/mem/protocol/MOESI_SMP_directory.slicc  | 4 -
 src/mem/protocol/MOESI_SMP_token-cache.sm   |  1734 ---
 src/mem/protocol/MOESI_SMP_token-dir.sm |   405 ---
 src/mem/protocol/MOESI_SMP_token-msg.sm |61 -
 src/mem/protocol/MOESI_SMP_token.slicc  | 4 -
 src/mem/protocol/MOSI_SMP_bcast-cache.sm|  1000 
 src/mem/protocol/MOSI_SMP_bcast-dir.sm  |   267 --
 src/mem/protocol/MOSI_SMP_bcast-msg.sm  |79 -
 src/mem/protocol/MOSI_SMP_bcast.slicc   | 4 -
 src/mem/protocol/MOSI_SMP_bcast_1level-cache.sm |   921 ---
 src/mem/protocol/MOSI_SMP_bcast_1level.slicc| 4 -
 src/mem/protocol/MOSI_SMP_bcast_m-dir.sm|   345 --
 src/mem/protocol/MOSI_SMP_bcast_m.slicc | 4 -
 src/mem/protocol/MOSI_SMP_directory_1level-cache.sm |   838 ---
 src/mem/protocol/MOSI_SMP_directory_1level-dir.sm   |   333 --
 src/mem/protocol/MOSI_SMP_directory_1level-msg.sm   |74 -
 src/mem/protocol/MOSI_SMP_directory_1level.slicc| 4 -
 src/mem/protocol/MSI_MOSI_CMP_directory-L1cache.sm  |   799 --
 src/mem/protocol/MSI_MOSI_CMP_directory-L2cache.sm  |  2191 ---
 src/mem/protocol/MSI_MOSI_CMP_directory-dir.sm  |   497 
 src/mem/protocol/MSI_MOSI_CMP_directory-msg.sm  |   115 -
 src/mem/protocol/MSI_MOSI_CMP_directory.slicc   | 8 -
 src/mem/protocol/standard_1level_SMP-protocol.sm|39 -
 src/mem/protocol/standard_SMP-protocol.sm   |39 -
 35 files changed, 0 insertions(+), 14391 deletions(-)

diffs (truncated from 14531 to 300 lines):

diff -r 03ee2388ea9d -r bba14984f2ce 
src/mem/protocol/MESI_SCMP_bankdirectory-L1cache.sm
--- a/src/mem/protocol/MESI_SCMP_bankdirectory-L1cache.sm   Wed Feb 23 
16:35:25 2011 -0500
+++ /dev/null   Thu Jan 01 00:00:00 1970 +
@@ -1,894 +0,0 @@
-
-/*
- * Copyright (c) 1999-2005 Mark D. Hill and David A. Wood
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are
- * met: redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer;
- * redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in the
- * documentation and/or other materials provided with the distribution;
- * neither the name of the copyright holders nor the names of its
- * contributors may be used to endorse or promote products derived from
- * this software without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- * AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
- * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
-/*
- * $Id: MSI_MOSI_CMP_directory-L1cache.sm 1.10 05/01/19 15:55:40-06:00 
beckm...@s0-28.cs.wisc.edu $
- *
- */
-
-
-machine(L1Cache, MSI Directory L1 Cache CMP) {
-
-  // NODE L1 CACHE
-  // From this node's L1 cache TO the network
-  // a local L1 - this L2 bank, currently ordered with directory forwarded 
requests
-  MessageBuffer requestFromL1Cache, network=To, virtual_network=0, 
ordered=false;
-  // a local L1 - this L2 bank
-  MessageBuffer responseFromL1Cache, network=To, virtual_network=3, 
ordered=false;
-  MessageBuffer unblockFromL1Cache, network=To, 

[m5-dev] changeset in m5: ruby: cleaned up access permission enum

2011-02-23 Thread Brad Beckmann
changeset d1bb88080be4 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=d1bb88080be4
description:
ruby: cleaned up access permission enum

diffstat:

 src/mem/protocol/MESI_CMP_directory-L2cache.sm |   2 +-
 src/mem/protocol/RubySlicc_Exports.sm  |  20 +---
 src/mem/ruby/slicc_interface/AbstractCacheEntry.cc |   3 +--
 src/mem/ruby/system/PerfectCacheMemory.hh  |   2 +-
 4 files changed, 16 insertions(+), 11 deletions(-)

diffs (68 lines):

diff -r bba14984f2ce -r d1bb88080be4 
src/mem/protocol/MESI_CMP_directory-L2cache.sm
--- a/src/mem/protocol/MESI_CMP_directory-L2cache.smWed Feb 23 16:41:26 
2011 -0800
+++ b/src/mem/protocol/MESI_CMP_directory-L2cache.smWed Feb 23 16:41:58 
2011 -0800
@@ -219,7 +219,7 @@
   } else if (state == State:M) {
 cache_entry.changePermission(AccessPermission:Read_Write);
   } else if (state == State:MT) {
-cache_entry.changePermission(AccessPermission:Stale);
+cache_entry.changePermission(AccessPermission:Invalid);
   } else {
 cache_entry.changePermission(AccessPermission:Busy);
   }
diff -r bba14984f2ce -r d1bb88080be4 src/mem/protocol/RubySlicc_Exports.sm
--- a/src/mem/protocol/RubySlicc_Exports.sm Wed Feb 23 16:41:26 2011 -0800
+++ b/src/mem/protocol/RubySlicc_Exports.sm Wed Feb 23 16:41:58 2011 -0800
@@ -47,14 +47,20 @@
 // Declarations of external types that are common to all protocols
 
 // AccessPermission
+// The following five states define the access permission of all memory blocks.
+// These permissions have multiple uses.  They coordinate locking and 
+// synchronization primitives, as well as enable functional accesses.
+// One should not need to add any additional permission values and it is very
+// risky to do so.
 enumeration(AccessPermission, desc=..., 
default=AccessPermission_NotPresent) {
-  Busy,   desc=No Read or Write;
-  Read_Only,  desc=Read Only;
-  Read_Write, desc=Read/Write;
-  Invalid,desc=Invalid;
-  NotPresent, desc=NotPresent;
-  ReadUpgradingToWrite, desc=Read only, but trying to get Read/Write;
-  Stale,  desc=local L1 has a modified copy, assume L2 copy is stale 
data;
+  // Valid data
+  Read_Only,  desc=block is Read Only (modulo functional writes);
+  Read_Write, desc=block is Read/Write;
+
+  // Invalid data
+  Invalid,desc=block is in an Invalid base state;
+  NotPresent, desc=block is NotPresent;
+  Busy,   desc=block is in a transient state, currently invalid;
 }
 
 // TesterStatus
diff -r bba14984f2ce -r d1bb88080be4 
src/mem/ruby/slicc_interface/AbstractCacheEntry.cc
--- a/src/mem/ruby/slicc_interface/AbstractCacheEntry.ccWed Feb 23 
16:41:26 2011 -0800
+++ b/src/mem/ruby/slicc_interface/AbstractCacheEntry.ccWed Feb 23 
16:41:58 2011 -0800
@@ -50,8 +50,7 @@
 {
 m_Permission = new_perm;
 if ((new_perm == AccessPermission_Invalid) ||
-(new_perm == AccessPermission_NotPresent) ||
-(new_perm == AccessPermission_Stale)) {
+(new_perm == AccessPermission_NotPresent)) {
 m_locked = -1;
 }
 }
diff -r bba14984f2ce -r d1bb88080be4 src/mem/ruby/system/PerfectCacheMemory.hh
--- a/src/mem/ruby/system/PerfectCacheMemory.hh Wed Feb 23 16:41:26 2011 -0800
+++ b/src/mem/ruby/system/PerfectCacheMemory.hh Wed Feb 23 16:41:58 2011 -0800
@@ -149,7 +149,7 @@
 PerfectCacheMemoryENTRY::allocate(const Address address)
 {
 PerfectCacheLineStateENTRY line_state;
-line_state.m_permission = AccessPermission_Busy;
+line_state.m_permission = AccessPermission_Invalid;
 line_state.m_entry = ENTRY();
 m_map[line_address(address)] = line_state;
 }
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev


[m5-dev] changeset in m5: MOESI_hammer: cache probe address clean up

2011-02-23 Thread Brad Beckmann
changeset d1eb504fd302 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=d1eb504fd302
description:
MOESI_hammer: cache probe address clean up

diffstat:

 src/mem/protocol/MOESI_hammer-cache.sm |  46 +++--
 src/mem/slicc/ast/LocalVariableAST.py  |   9 +-
 2 files changed, 33 insertions(+), 22 deletions(-)

diffs (116 lines):

diff -r d1bb88080be4 -r d1eb504fd302 src/mem/protocol/MOESI_hammer-cache.sm
--- a/src/mem/protocol/MOESI_hammer-cache.smWed Feb 23 16:41:58 2011 -0800
+++ b/src/mem/protocol/MOESI_hammer-cache.smWed Feb 23 16:41:58 2011 -0800
@@ -390,10 +390,11 @@
   if (L2cacheMemory.cacheAvail(in_msg.LineAddress)) {
 trigger(Event:L1_to_L2, in_msg.LineAddress, L1Dcache_entry, 
tbe);
   } else {
+Address l2_victim_addr := 
L2cacheMemory.cacheProbe(in_msg.LineAddress);
 trigger(Event:L2_Replacement,
-L2cacheMemory.cacheProbe(in_msg.LineAddress),
-
getL2CacheEntry(L2cacheMemory.cacheProbe(in_msg.LineAddress)),
-TBEs[L2cacheMemory.cacheProbe(in_msg.LineAddress)]);
+l2_victim_addr, 
+getL2CacheEntry(l2_victim_addr),
+TBEs[l2_victim_addr]);
   }
 }
 
@@ -412,18 +413,20 @@
   }
 } else {
   // No room in the L1, so we need to make room
-  if 
(L2cacheMemory.cacheAvail(L1IcacheMemory.cacheProbe(in_msg.LineAddress))) {
+  Address l1i_victim_addr := 
L1IcacheMemory.cacheProbe(in_msg.LineAddress);
+  if (L2cacheMemory.cacheAvail(l1i_victim_addr)) {
 // The L2 has room, so we move the line from the L1 to the L2
 trigger(Event:L1_to_L2,
-L1IcacheMemory.cacheProbe(in_msg.LineAddress),
-
getL1ICacheEntry(L1IcacheMemory.cacheProbe(in_msg.LineAddress)),
-TBEs[L1IcacheMemory.cacheProbe(in_msg.LineAddress)]);
+l1i_victim_addr,
+getL1ICacheEntry(l1i_victim_addr),
+TBEs[l1i_victim_addr]);
   } else {
+Address l2_victim_addr := 
L2cacheMemory.cacheProbe(l1i_victim_addr);
 // The L2 does not have room, so we replace a line from the L2
 trigger(Event:L2_Replacement,
-
L2cacheMemory.cacheProbe(L1IcacheMemory.cacheProbe(in_msg.LineAddress)),
-
getL2CacheEntry(L2cacheMemory.cacheProbe(L1IcacheMemory.cacheProbe(in_msg.LineAddress))),
-
TBEs[L2cacheMemory.cacheProbe(L1IcacheMemory.cacheProbe(in_msg.LineAddress))]);
+l2_victim_addr,
+getL2CacheEntry(l2_victim_addr),
+TBEs[l2_victim_addr]);
   }
 }
   }
@@ -444,10 +447,11 @@
   if (L2cacheMemory.cacheAvail(in_msg.LineAddress)) {
 trigger(Event:L1_to_L2, in_msg.LineAddress, L1Icache_entry, 
tbe);
   } else {
+Address l2_victim_addr := 
L2cacheMemory.cacheProbe(in_msg.LineAddress);
 trigger(Event:L2_Replacement,
-L2cacheMemory.cacheProbe(in_msg.LineAddress),
-
getL2CacheEntry(L2cacheMemory.cacheProbe(in_msg.LineAddress)),
-TBEs[L2cacheMemory.cacheProbe(in_msg.LineAddress)]);
+l2_victim_addr,
+getL2CacheEntry(l2_victim_addr),
+TBEs[l2_victim_addr]);
   }
 }
 
@@ -465,18 +469,20 @@
   }
 } else {
   // No room in the L1, so we need to make room
-  if 
(L2cacheMemory.cacheAvail(L1DcacheMemory.cacheProbe(in_msg.LineAddress))) {
+  Address l1d_victim_addr := 
L1DcacheMemory.cacheProbe(in_msg.LineAddress);
+  if (L2cacheMemory.cacheAvail(l1d_victim_addr)) {
 // The L2 has room, so we move the line from the L1 to the L2
 trigger(Event:L1_to_L2,
-L1DcacheMemory.cacheProbe(in_msg.LineAddress),
-
getL1DCacheEntry(L1DcacheMemory.cacheProbe(in_msg.LineAddress)),
-TBEs[L1DcacheMemory.cacheProbe(in_msg.LineAddress)]);
+l1d_victim_addr,
+getL1DCacheEntry(l1d_victim_addr),
+TBEs[l1d_victim_addr]);
   } else {
+Address l2_victim_addr := 
L2cacheMemory.cacheProbe(l1d_victim_addr);
 // The L2 does not have room, so we replace a line from the L2
 trigger(Event:L2_Replacement,
-
L2cacheMemory.cacheProbe(L1DcacheMemory.cacheProbe(in_msg.LineAddress)),
-

[m5-dev] changeset in m5: ruby: automate permission setting

2011-02-23 Thread Brad Beckmann
changeset bf0335d98250 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=bf0335d98250
description:
ruby: automate permission setting

This patch integrates permissions with cache and memory states, and then
automates the setting of permissions within the generated code.  No 
longer
does one need to manually set the permissions within the setState 
funciton.
This patch will faciliate easier functional access support by always 
correctly
setting permissions for both cache and memory states.

diffstat:

 src/mem/protocol/MESI_CMP_directory-L1cache.sm |   37 ++
 src/mem/protocol/MESI_CMP_directory-L2cache.sm |   49 +++-
 src/mem/protocol/MESI_CMP_directory-dir.sm |   22 +-
 src/mem/protocol/MESI_CMP_directory-dma.sm |8 +-
 src/mem/protocol/MI_example-cache.sm   |   21 +--
 src/mem/protocol/MI_example-dir.sm |   22 +-
 src/mem/protocol/MI_example-dma.sm |8 +-
 src/mem/protocol/MOESI_CMP_directory-L1cache.sm|   46 ++-
 src/mem/protocol/MOESI_CMP_directory-L2cache.sm|  125 ++--
 src/mem/protocol/MOESI_CMP_directory-dir.sm|   36 +++---
 src/mem/protocol/MOESI_CMP_directory-dma.sm|8 +-
 src/mem/protocol/MOESI_CMP_token-L1cache.sm|   53 +++-
 src/mem/protocol/MOESI_CMP_token-L2cache.sm|   27 +---
 src/mem/protocol/MOESI_CMP_token-dir.sm|   34 ++--
 src/mem/protocol/MOESI_CMP_token-dma.sm|8 +-
 src/mem/protocol/MOESI_hammer-cache.sm |   61 +++--
 src/mem/protocol/MOESI_hammer-dir.sm   |   56 
 src/mem/protocol/MOESI_hammer-dma.sm   |   10 +-
 src/mem/protocol/RubySlicc_Types.sm|4 +-
 src/mem/ruby/slicc_interface/AbstractCacheEntry.cc |   10 +-
 src/mem/ruby/slicc_interface/AbstractCacheEntry.hh |5 +-
 src/mem/ruby/slicc_interface/AbstractEntry.cc  |   13 ++
 src/mem/ruby/slicc_interface/AbstractEntry.hh  |7 +
 src/mem/slicc/ast/StateDeclAST.py  |   79 +
 src/mem/slicc/ast/TypeFieldEnumAST.py  |9 +-
 src/mem/slicc/ast/TypeFieldStateAST.py |   61 ++
 src/mem/slicc/ast/__init__.py  |2 +
 src/mem/slicc/parser.py|   20 +++
 src/mem/slicc/symbols/StateMachine.py  |   13 ++
 src/mem/slicc/symbols/Type.py  |   40 ++
 30 files changed, 514 insertions(+), 380 deletions(-)

diffs (truncated from 1395 to 300 lines):

diff -r d1eb504fd302 -r bf0335d98250 
src/mem/protocol/MESI_CMP_directory-L1cache.sm
--- a/src/mem/protocol/MESI_CMP_directory-L1cache.smWed Feb 23 16:41:58 
2011 -0800
+++ b/src/mem/protocol/MESI_CMP_directory-L1cache.smWed Feb 23 16:41:59 
2011 -0800
@@ -52,23 +52,23 @@
   MessageBuffer responseToL1Cache, network=From, virtual_network=1, 
ordered=false;
 
   // STATES
-  enumeration(State, desc=Cache states, default=L1Cache_State_I) {
+  state_declaration(State, desc=Cache states, default=L1Cache_State_I) {
 // Base states
-NP, desc=Not present in either cache;
-I, desc=a L1 cache entry Idle;
-S, desc=a L1 cache entry Shared;
-E, desc=a L1 cache entry Exclusive;
-M, desc=a L1 cache entry Modified, format=!b;
+NP, AccessPermission:Invalid, desc=Not present in either cache;
+I, AccessPermission:Invalid, desc=a L1 cache entry Idle;
+S, AccessPermission:Read_Only, desc=a L1 cache entry Shared;
+E, AccessPermission:Read_Only, desc=a L1 cache entry Exclusive;
+M, AccessPermission:Read_Write, desc=a L1 cache entry Modified, 
format=!b;
 
 // Transient States
-IS, desc=L1 idle, issued GETS, have not seen response yet;
-IM, desc=L1 idle, issued GETX, have not seen response yet;
-SM, desc=L1 idle, issued GETX, have not seen response yet;
-IS_I, desc=L1 idle, issued GETS, saw Inv before data because directory 
doesn't block on GETS hit;
+IS, AccessPermission:Busy, desc=L1 idle, issued GETS, have not seen 
response yet;
+IM, AccessPermission:Busy, desc=L1 idle, issued GETX, have not seen 
response yet;
+SM, AccessPermission:Read_Only, desc=L1 idle, issued GETX, have not seen 
response yet;
+IS_I, AccessPermission:Busy, desc=L1 idle, issued GETS, saw Inv before 
data because directory doesn't block on GETS hit;
 
-M_I, desc=L1 replacing, waiting for ACK;
-E_I, desc=L1 replacing, waiting for ACK;
-SINK_WB_ACK, desc=This is to sink WB_Acks from L2;
+M_I, AccessPermission:Busy, desc=L1 replacing, waiting for ACK;
+E_I, AccessPermission:Busy, desc=L1 replacing, waiting for ACK;
+SINK_WB_ACK, AccessPermission:Busy, desc=This is to sink WB_Acks from L2;
 
   }
 
@@ -180,17 +180,6 @@
 
 if (is_valid(cache_entry)) {
   cache_entry.CacheState := state;
-
-  // Set permission
-  if (state == State:I) {
-

[m5-dev] changeset in m5: regress: MOESI_hammer memtest updates

2011-02-23 Thread Brad Beckmann
changeset 3be28ebdb07f in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=3be28ebdb07f
description:
regress: MOESI_hammer memtest updates

diffstat:

 tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_hammer/ruby.stats |  
990 +-
 tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_hammer/simerr |  
146 +-
 tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_hammer/simout |  
 10 +-
 tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_hammer/stats.txt  |  
 40 +-
 4 files changed, 593 insertions(+), 593 deletions(-)

diffs (truncated from 1727 to 300 lines):

diff -r bf0335d98250 -r 3be28ebdb07f 
tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_hammer/ruby.stats
--- 
a/tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_hammer/ruby.stats   
Wed Feb 23 16:41:59 2011 -0800
+++ 
b/tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_hammer/ruby.stats   
Wed Feb 23 16:41:59 2011 -0800
@@ -34,29 +34,29 @@
  End RubySystem Configuration Print 
 
 
-Real time: Feb/08/2011 18:01:10
+Real time: Feb/23/2011 14:32:39
 
 Profiler Stats
 --
-Elapsed_time_in_seconds: 247
-Elapsed_time_in_minutes: 4.11667
-Elapsed_time_in_hours: 0.0686111
-Elapsed_time_in_days: 0.0028588
+Elapsed_time_in_seconds: 343
+Elapsed_time_in_minutes: 5.71667
+Elapsed_time_in_hours: 0.0952778
+Elapsed_time_in_days: 0.00396991
 
-Virtual_time_in_seconds: 247.89
-Virtual_time_in_minutes: 4.1315
-Virtual_time_in_hours:   0.0688583
-Virtual_time_in_days:0.0028691
+Virtual_time_in_seconds: 266.4
+Virtual_time_in_minutes: 4.44
+Virtual_time_in_hours:   0.074
+Virtual_time_in_days:0.00308333
 
-Ruby_current_time: 38059429
+Ruby_current_time: 38170519
 Ruby_start_time: 0
-Ruby_cycles: 38059429
+Ruby_cycles: 38170519
 
-mbytes_resident: 35.4062
-mbytes_total: 337.344
-resident_ratio: 0.104968
+mbytes_resident: 35.4453
+mbytes_total: 337.395
+resident_ratio: 0.105079
 
-ruby_cycles_executed: [ 38059430 38059430 38059430 38059430 38059430 38059430 
38059430 38059430 ]
+ruby_cycles_executed: [ 38170520 38170520 38170520 38170520 38170520 38170520 
38170520 38170520 ]
 
 Busy Controller Counts:
 L1Cache-0:0  L1Cache-1:0  L1Cache-2:0  L1Cache-3:0  L1Cache-4:0  L1Cache-5:0  
L1Cache-6:0  L1Cache-7:0  
@@ -66,35 +66,35 @@
 
 Busy Bank Count:0
 
-sequencer_requests_outstanding: [binsize: 1 max: 16 count: 1223364 average: 
15.9992 | standard deviation: 0.0900488 | 0 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 
1223244 ]
+sequencer_requests_outstanding: [binsize: 1 max: 16 count: 1226929 average: 
15.9992 | standard deviation: 0.0899179 | 0 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 
1226809 ]
 
 All Non-Zero Cycle Demand Cache Accesses
 
-miss_latency: [binsize: 128 max: 20160 count: 1223236 average: 3982.16 | 
standard deviation: 4665.63 | 3708 13781 25116 33223 31921 38797 43604 45421 
39533 34780 37348 35273 29185 26408 23841 22826 19268 17942 17660 14791 14436 
14028 13947 12589 11213 12158 12485 11406 11283 10763 11315 10826 10964 11697 
10326 10963 11210 11863 11224 10479 11754 12169 11782 11935 11747 12526 12312 
12508 13274 11956 12572 12763 13270 12822 11784 12738 12948 12280 11992 11264 
11881 10994 10700 10686 9540 9613 9236 9204 8301 7394 7524 7032 6512 5971 5447 
5391 4756 4563 4247 3623 3363 3219 3041 2542 2170 2242 2127 1734 1545 1433 1353 
1137 1013 958 793 705 672 598 488 422 421 364 276 289 244 209 186 152 145 110 
83 83 85 66 45 42 32 36 20 29 27 22 17 15 12 12 9 4 5 3 1 6 2 2 1 2 0 2 1 0 0 1 
1 0 0 1 0 2 0 0 0 1 1 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ]
-miss_latency_LD: [binsize: 128 max: 19520 count: 795213 average: 3980.28 | 
standard deviation: 6214.05 | 2367 8989 16262 21781 20893 25190 28254 29586 
25661 22626 24278 23085 19116 17158 15560 14786 12693 11723 11422 9539 9375 
9108 9013 8099 7236 7910 8080 7444 7303 7019 7374 7036 7048 7598 6668 7111 7166 
7768 7191 6845 7679 7799 7673 7710 7667 8206 8031 8008 8632 7748 8177 8242 8718 
8331 7736 8254 8467 7936 7684 7323 7701 7199 6981 6919 6216 6337 6018 5989 5426 
4831 4902 4625 4293 3782 3464 3552 3151 2882 2715 2314 2186 2084 1953 1677 1406 
1498 1375 1132 1013 946 898 735 673 620 507 432 447 388 325 259 259 241 167 189 
158 133 121 101 94 71 56 59 58 46 33 24 20 23 11 20 13 14 12 6 8 8 8 3 3 3 0 5 
1 2 1 2 0 2 0 0 0 0 1 0 0 1 0 1 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ]
-miss_latency_ST: [binsize: 128 max: 20160 count: 428023 average: 3985.66 | 
standard deviation: 3071.42 | 1341 4792 8854 11442 11028 13607 15350 15835 
13872 12154 13070 12188 10069 9250 8281 8040 6575 6219 6238 5252 5061 4920 4934 
4490 3977 4248 4405 3962 3980 3744 3941 3790 3916 4099 3658 3852 4044 4095 4033 
3634 4075 4370 4109 4225 4080 4320 4281 4500 4642 4208 4395 4521 4552 4491 4048 
4484 4481 4344 4308 3941 4180 3795 3719 3767 3324 3276 

[m5-dev] changeset in m5: MOESI_hammer: fixed wakeup for SS-S transistion

2011-02-22 Thread Brad Beckmann
changeset c7f591ccf3a1 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=c7f591ccf3a1
description:
MOESI_hammer: fixed wakeup for SS-S transistion

diffstat:

 src/mem/protocol/MOESI_hammer-cache.sm |  2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diffs (19 lines):

diff -r d6294150a32e -r c7f591ccf3a1 src/mem/protocol/MOESI_hammer-cache.sm
--- a/src/mem/protocol/MOESI_hammer-cache.smWed Feb 09 16:02:09 2011 -0800
+++ b/src/mem/protocol/MOESI_hammer-cache.smThu Feb 10 13:28:23 2011 -0800
@@ -1548,6 +1548,7 @@
 gs_sendUnblockS;
 s_deallocateTBE;
 j_popTriggerQueue;
+kd_wakeUpDependents;
   }
 
   transition(SS, All_acks_no_sharers, S) {
@@ -1555,6 +1556,7 @@
 gs_sendUnblockS;
 s_deallocateTBE;
 j_popTriggerQueue;
+kd_wakeUpDependents;
   }
 
   // Transitions from MM_W
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev


Re: [m5-dev] Review Request: ruby: cleaning up RubyQueue and RubyNetwork dprintfs

2011-02-22 Thread Brad Beckmann

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

Ship it!


- Brad


On 2011-02-22 13:11:15, Korey Sewell wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/489/
 ---
 
 (Updated 2011-02-22 13:11:15)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 ruby: cleaning up RubyQueue and RubyNetwork dprintfs
 Overall, continue to progress Ruby debug messages to more of the normal M5
 debug message style
 - add a name() to the Ruby Throttle  PerfectSwitch objects so that the debug 
 output
 isn't littered w/global: everywhere.
 - clean up messages that print over multiple lines when possible
 - clean up duplicate prints in the message buffer
 
 
 Diffs
 -
 
   src/mem/ruby/buffers/MessageBuffer.hh e6ce478c05d3 
   src/mem/ruby/buffers/MessageBuffer.cc e6ce478c05d3 
   src/mem/ruby/common/NetDest.hh e6ce478c05d3 
   src/mem/ruby/network/simple/PerfectSwitch.hh e6ce478c05d3 
   src/mem/ruby/network/simple/PerfectSwitch.cc e6ce478c05d3 
   src/mem/ruby/network/simple/Throttle.hh e6ce478c05d3 
   src/mem/ruby/network/simple/Throttle.cc e6ce478c05d3 
 
 Diff: http://reviews.m5sim.org/r/489/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Korey
 


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


[m5-dev] Review Request: ruby: automate permission setting

2011-02-22 Thread Brad Beckmann

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

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

ruby: automate permission setting

This patch integrates permissions with cache and memory states, and then
automates the setting of permissions within the generated code.  No longer
does one need to manually set the permissions within the setState funciton.
This patch will faciliate easier functional access support by always correctly
setting permissions for both cache and memory states.


Diffs
-

  src/mem/protocol/MESI_CMP_directory-L1cache.sm e6ce478c05d3 
  src/mem/protocol/MESI_CMP_directory-L2cache.sm e6ce478c05d3 
  src/mem/protocol/MESI_CMP_directory-dir.sm e6ce478c05d3 
  src/mem/protocol/MESI_CMP_directory-dma.sm e6ce478c05d3 
  src/mem/protocol/MI_example-cache.sm e6ce478c05d3 
  src/mem/protocol/MI_example-dir.sm e6ce478c05d3 
  src/mem/protocol/MI_example-dma.sm e6ce478c05d3 
  src/mem/protocol/MOESI_CMP_directory-L1cache.sm e6ce478c05d3 
  src/mem/protocol/MOESI_CMP_directory-L2cache.sm e6ce478c05d3 
  src/mem/protocol/MOESI_CMP_directory-dir.sm e6ce478c05d3 
  src/mem/protocol/MOESI_CMP_directory-dma.sm e6ce478c05d3 
  src/mem/protocol/MOESI_CMP_token-L1cache.sm e6ce478c05d3 
  src/mem/protocol/MOESI_CMP_token-L2cache.sm e6ce478c05d3 
  src/mem/protocol/MOESI_CMP_token-dir.sm e6ce478c05d3 
  src/mem/protocol/MOESI_CMP_token-dma.sm e6ce478c05d3 
  src/mem/protocol/MOESI_hammer-cache.sm e6ce478c05d3 
  src/mem/protocol/MOESI_hammer-dir.sm e6ce478c05d3 
  src/mem/protocol/MOESI_hammer-dma.sm e6ce478c05d3 
  src/mem/protocol/RubySlicc_Types.sm e6ce478c05d3 
  src/mem/ruby/slicc_interface/AbstractCacheEntry.hh e6ce478c05d3 
  src/mem/ruby/slicc_interface/AbstractCacheEntry.cc e6ce478c05d3 
  src/mem/ruby/slicc_interface/AbstractEntry.hh e6ce478c05d3 
  src/mem/ruby/slicc_interface/AbstractEntry.cc e6ce478c05d3 
  src/mem/slicc/ast/StateDeclAST.py PRE-CREATION 
  src/mem/slicc/ast/TypeFieldEnumAST.py e6ce478c05d3 
  src/mem/slicc/ast/TypeFieldStateAST.py PRE-CREATION 
  src/mem/slicc/ast/__init__.py e6ce478c05d3 
  src/mem/slicc/parser.py e6ce478c05d3 
  src/mem/slicc/symbols/StateMachine.py e6ce478c05d3 
  src/mem/slicc/symbols/Type.py e6ce478c05d3 

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


Testing
---


Thanks,

Brad

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


[m5-dev] Review Request: MOESI_hammer: cache probe address clean up

2011-02-22 Thread Brad Beckmann

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

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

MOESI_hammer: cache probe address clean up


Diffs
-

  src/mem/protocol/MOESI_hammer-cache.sm e6ce478c05d3 
  src/mem/slicc/ast/LocalVariableAST.py e6ce478c05d3 

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


Testing
---


Thanks,

Brad

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


[m5-dev] Review Request: ruby: cleaned up access permission enum

2011-02-22 Thread Brad Beckmann

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

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

ruby: cleaned up access permission enum


Diffs
-

  src/mem/protocol/MESI_CMP_directory-L2cache.sm e6ce478c05d3 
  src/mem/protocol/RubySlicc_Exports.sm e6ce478c05d3 
  src/mem/ruby/slicc_interface/AbstractCacheEntry.cc e6ce478c05d3 
  src/mem/ruby/system/PerfectCacheMemory.hh e6ce478c05d3 

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


Testing
---


Thanks,

Brad

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


[m5-dev] Review Request: ruby: removed unsupported protocol files

2011-02-22 Thread Brad Beckmann

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

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

ruby: removed unsupported protocol files


Diffs
-

  src/mem/protocol/MESI_SCMP_bankdirectory-L1cache.sm e6ce478c05d3 
  src/mem/protocol/MESI_SCMP_bankdirectory-L2cache.sm e6ce478c05d3 
  src/mem/protocol/MESI_SCMP_bankdirectory-mem.sm e6ce478c05d3 
  src/mem/protocol/MESI_SCMP_bankdirectory-msg.sm e6ce478c05d3 
  src/mem/protocol/MESI_SCMP_bankdirectory.slicc e6ce478c05d3 
  src/mem/protocol/MESI_SCMP_bankdirectory_m-mem.sm e6ce478c05d3 
  src/mem/protocol/MESI_SCMP_bankdirectory_m.slicc e6ce478c05d3 
  src/mem/protocol/MOESI_SMP_directory-cache.sm e6ce478c05d3 
  src/mem/protocol/MOESI_SMP_directory-dir.sm e6ce478c05d3 
  src/mem/protocol/MOESI_SMP_directory-msg.sm e6ce478c05d3 
  src/mem/protocol/MOESI_SMP_directory.slicc e6ce478c05d3 
  src/mem/protocol/MOESI_SMP_token-cache.sm e6ce478c05d3 
  src/mem/protocol/MOESI_SMP_token-dir.sm e6ce478c05d3 
  src/mem/protocol/MOESI_SMP_token-msg.sm e6ce478c05d3 
  src/mem/protocol/MOESI_SMP_token.slicc e6ce478c05d3 
  src/mem/protocol/MOSI_SMP_bcast-cache.sm e6ce478c05d3 
  src/mem/protocol/MOSI_SMP_bcast-dir.sm e6ce478c05d3 
  src/mem/protocol/MOSI_SMP_bcast-msg.sm e6ce478c05d3 
  src/mem/protocol/MOSI_SMP_bcast.slicc e6ce478c05d3 
  src/mem/protocol/MOSI_SMP_bcast_1level-cache.sm e6ce478c05d3 
  src/mem/protocol/MOSI_SMP_bcast_1level.slicc e6ce478c05d3 
  src/mem/protocol/MOSI_SMP_bcast_m-dir.sm e6ce478c05d3 
  src/mem/protocol/MOSI_SMP_bcast_m.slicc e6ce478c05d3 
  src/mem/protocol/MOSI_SMP_directory_1level-cache.sm e6ce478c05d3 
  src/mem/protocol/MOSI_SMP_directory_1level-dir.sm e6ce478c05d3 
  src/mem/protocol/MOSI_SMP_directory_1level-msg.sm e6ce478c05d3 
  src/mem/protocol/MOSI_SMP_directory_1level.slicc e6ce478c05d3 
  src/mem/protocol/MSI_MOSI_CMP_directory-L1cache.sm e6ce478c05d3 
  src/mem/protocol/MSI_MOSI_CMP_directory-L2cache.sm e6ce478c05d3 
  src/mem/protocol/MSI_MOSI_CMP_directory-dir.sm e6ce478c05d3 
  src/mem/protocol/MSI_MOSI_CMP_directory-msg.sm e6ce478c05d3 
  src/mem/protocol/MSI_MOSI_CMP_directory.slicc e6ce478c05d3 
  src/mem/protocol/standard_1level_SMP-protocol.sm e6ce478c05d3 
  src/mem/protocol/standard_SMP-protocol.sm e6ce478c05d3 

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


Testing
---


Thanks,

Brad

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


Re: [m5-dev] Review Request: ruby: extend dprintfs for RubyGenerated TraceFlag

2011-02-21 Thread Brad Beckmann

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

Ship it!


- Brad


On 2011-02-18 14:55:40, Korey Sewell wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/492/
 ---
 
 (Updated 2011-02-18 14:55:40)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 ruby: extend dprintfs for RubyGenerated TraceFlag
 executing isnt a very descriptive debug message and in going through the
 output you get multiple messages that say executing but nothing to help
 you parse through the code/execution.
 
 So instead, at least print out the name of the action that is taking
 place in these functions.
 
 
 Diffs
 -
 
   src/mem/slicc/symbols/StateMachine.py bb35cb393bbb 
 
 Diff: http://reviews.m5sim.org/r/492/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Korey
 


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


Re: [m5-dev] Review Request: Ruby: Change PerfectSwitch's wakeup function

2011-02-09 Thread Brad Beckmann

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


Overall, this looks great.  A pretty simple change that offers significant 
speedup.  I just have one question about the parameters to storeEventInfo.


src/mem/ruby/buffers/MessageBuffer.cc
http://reviews.m5sim.org/r/328/#comment1196

Is there a reason why you want to pass the message pointer instead of just 
the vnet id?



src/mem/ruby/network/simple/PerfectSwitch.cc
http://reviews.m5sim.org/r/328/#comment1197

It seems that you could remove the safe_cast and message pointer 
dereference if you passed in the vnet id as the first parameter.  Am I missing 
something?


- Brad


On 2011-02-05 12:47:34, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/328/
 ---
 
 (Updated 2011-02-05 12:47:34)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Currently the wakeup function for the PerfectSwitch contains three loops -
 
 loop on number of virtual networks
   loop on number of incoming links
 loop till all messages for this (link, network) have been routed
 
 With an 8 processor mesh network and Hammer protocol, about 11-12% of the 
 was observed to have been spent in this function, which is the highest 
 amongst all the functions. It was found that the innermost loop is executed 
 about 45 times per invocation of the wakeup function, when each invocation 
 of the wakeup function processes just about one message.
 
 The patch tries to do away with the redundant executions of the innermost 
 loop. Counters have been added for each virtual network that record the 
 number of messages that need to be routed for that virtual network. The 
 inner loops are only executed when the number of messages for that particular 
 virtual network  0. This does away with almost 80% of the executions of the 
 innermost loop. The function now consumes about 5-6% of the total execution 
 time.
 
 
 Diffs
 -
 
   src/mem/ruby/buffers/MessageBuffer.hh UNKNOWN 
   src/mem/ruby/buffers/MessageBuffer.cc UNKNOWN 
   src/mem/ruby/common/Consumer.hh UNKNOWN 
   src/mem/ruby/network/simple/PerfectSwitch.hh UNKNOWN 
   src/mem/ruby/network/simple/PerfectSwitch.cc UNKNOWN 
   src/mem/ruby/slicc_interface/Message.hh UNKNOWN 
   src/mem/ruby/slicc_interface/NetworkMessage.hh UNKNOWN 
 
 Diff: http://reviews.m5sim.org/r/328/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Nilay
 


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


Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC

2011-02-09 Thread Brad Beckmann

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


Overall, this patch looks good to me as well.  I just have a couple minor 
questions.  Though your comment says this patch removes libruby, the diff seems 
to indicate that the file still remains.  Am I reading that correctly?  Also it 
seems that in several places you unecessarily generate the line address, even 
though the line address already exists in the ruby request (see comments below).


src/mem/ruby/storebuffer/storebuffer.cc
http://reviews.m5sim.org/r/327/#comment1201

Instead of masking the physical address, can we just use the m_LineAddress?



src/mem/ruby/storebuffer/storebuffer.cc
http://reviews.m5sim.org/r/327/#comment1202

Same here.  Can we just use the m_LineAddress?



src/mem/ruby/storebuffer/storebuffer.cc
http://reviews.m5sim.org/r/327/#comment1203

And here



src/mem/ruby/system/Sequencer.cc
http://reviews.m5sim.org/r/327/#comment1199

Why is this line address conversion necessary?  Isn't m_LineAddress already 
set correctly in the constructor?



src/mem/ruby/system/Sequencer.cc
http://reviews.m5sim.org/r/327/#comment1200

Can you just use the m_LineAddress variable of ruby_request instead of 
converting the paddr to a line address.


- Brad


On 2011-01-25 09:15:23, Nilay Vaish wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/327/
 ---
 
 (Updated 2011-01-25 09:15:23)
 
 
 Review request for Default.
 
 
 Summary
 ---
 
 Remove CacheMsg class from SLICC
 The goal of the patch is to do away with the CacheMsg class currently in use
 in coherence protocols. In place of CacheMsg, the RubyRequest class will used.
 This class is already present in libruby.hh. In fact, objects of class
 CacheMsg are generated by copying values from a RubyRequest object.
 
 The changes relating to removal of libruby have been moved to separate patch.
 
 
 Diffs
 -
 
   src/cpu/testers/rubytest/RubyTester.hh 31a04e5ac4be 
   src/mem/protocol/MESI_CMP_directory-L1cache.sm 31a04e5ac4be 
   src/mem/protocol/MI_example-cache.sm 31a04e5ac4be 
   src/mem/protocol/MOESI_CMP_directory-L1cache.sm 31a04e5ac4be 
   src/mem/protocol/MOESI_CMP_token-L1cache.sm 31a04e5ac4be 
   src/mem/protocol/MOESI_CMP_token-dir.sm 31a04e5ac4be 
   src/mem/protocol/MOESI_hammer-cache.sm 31a04e5ac4be 
   src/mem/protocol/RubySlicc_Exports.sm 31a04e5ac4be 
   src/mem/protocol/RubySlicc_Profiler.sm 31a04e5ac4be 
   src/mem/protocol/RubySlicc_Types.sm 31a04e5ac4be 
   src/mem/ruby/SConscript 31a04e5ac4be 
   src/mem/ruby/common/Address.hh 31a04e5ac4be 
   src/mem/ruby/common/Address.cc 31a04e5ac4be 
   src/mem/ruby/common/DataBlock.hh 31a04e5ac4be 
   src/mem/ruby/common/DataBlock.cc 31a04e5ac4be 
   src/mem/ruby/filters/BlockBloomFilter.cc 31a04e5ac4be 
   src/mem/ruby/filters/BulkBloomFilter.cc 31a04e5ac4be 
   src/mem/ruby/filters/LSB_CountingBloomFilter.cc 31a04e5ac4be 
   src/mem/ruby/filters/MultiGrainBloomFilter.cc 31a04e5ac4be 
   src/mem/ruby/filters/NonCountingBloomFilter.cc 31a04e5ac4be 
   src/mem/ruby/libruby.hh 31a04e5ac4be 
   src/mem/ruby/libruby.cc 31a04e5ac4be 
   src/mem/ruby/libruby_internal.hh 31a04e5ac4be 
   src/mem/ruby/profiler/AccessTraceForAddress.cc 31a04e5ac4be 
   src/mem/ruby/profiler/AddressProfiler.hh 31a04e5ac4be 
   src/mem/ruby/profiler/AddressProfiler.cc 31a04e5ac4be 
   src/mem/ruby/profiler/Profiler.hh 31a04e5ac4be 
   src/mem/ruby/profiler/Profiler.cc 31a04e5ac4be 
   src/mem/ruby/recorder/CacheRecorder.hh 31a04e5ac4be 
   src/mem/ruby/recorder/CacheRecorder.cc 31a04e5ac4be 
   src/mem/ruby/recorder/TraceRecord.hh 31a04e5ac4be 
   src/mem/ruby/recorder/TraceRecord.cc 31a04e5ac4be 
   src/mem/ruby/recorder/Tracer.hh 31a04e5ac4be 
   src/mem/ruby/recorder/Tracer.cc 31a04e5ac4be 
   src/mem/ruby/slicc_interface/RubyRequest.hh PRE-CREATION 
   src/mem/ruby/slicc_interface/RubyRequest.cc PRE-CREATION 
   src/mem/ruby/slicc_interface/RubySlicc_Profiler_interface.hh 31a04e5ac4be 
   src/mem/ruby/slicc_interface/RubySlicc_Util.hh 31a04e5ac4be 
   src/mem/ruby/slicc_interface/SConscript 31a04e5ac4be 
   src/mem/ruby/storebuffer/stb_interface.cc 31a04e5ac4be 
   src/mem/ruby/storebuffer/storebuffer.cc 31a04e5ac4be 
   src/mem/ruby/system/CacheMemory.hh 31a04e5ac4be 
   src/mem/ruby/system/CacheMemory.cc 31a04e5ac4be 
   src/mem/ruby/system/DMASequencer.hh 31a04e5ac4be 
   src/mem/ruby/system/DMASequencer.cc 31a04e5ac4be 
   src/mem/ruby/system/PerfectCacheMemory.hh 31a04e5ac4be 
   src/mem/ruby/system/RubyPort.hh 31a04e5ac4be 
   src/mem/ruby/system/RubyPort.cc 31a04e5ac4be 
   src/mem/ruby/system/Sequencer.hh 31a04e5ac4be 
   src/mem/ruby/system/Sequencer.cc 31a04e5ac4be 
   

[m5-dev] changeset in m5: ruby: removed duplicate make response call

2011-02-09 Thread Brad Beckmann
changeset d6294150a32e in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=d6294150a32e
description:
ruby: removed duplicate make response call

diffstat:

 src/mem/ruby/system/RubyPort.cc |  1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diffs (11 lines):

diff -r 215c8be67063 -r d6294150a32e src/mem/ruby/system/RubyPort.cc
--- a/src/mem/ruby/system/RubyPort.cc   Tue Feb 08 18:07:54 2011 -0800
+++ b/src/mem/ruby/system/RubyPort.cc   Wed Feb 09 16:02:09 2011 -0800
@@ -342,7 +342,6 @@
 // the RubyPort itself must convert it to a response.
 //
 accessPhysMem = false;
-pkt-makeAtomicResponse();
 }
 } else {
 //
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev


[m5-dev] changeset in m5: config: fixed minor bug connecting dma devices ...

2011-02-08 Thread Brad Beckmann
changeset bb6411d45356 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=bb6411d45356
description:
config: fixed minor bug connecting dma devices to ruby

diffstat:

 configs/common/FSConfig.py |   3 +++
 configs/example/ruby_fs.py |  12 +---
 2 files changed, 8 insertions(+), 7 deletions(-)

diffs (41 lines):

diff -r 9c245e375e05 -r bb6411d45356 configs/common/FSConfig.py
--- a/configs/common/FSConfig.pyTue Feb 08 07:47:02 2011 -0600
+++ b/configs/common/FSConfig.pyTue Feb 08 15:52:44 2011 -0800
@@ -334,6 +334,9 @@
 # Create and connect the busses required by each memory system
 if Ruby:
 connectX86RubySystem(self)
+# add the ide to the list of dma devices that later need to attach to
+# dma controllers
+self._dma_devices = [self.pc.south_bridge.ide]
 else:
 connectX86ClassicSystem(self)
 
diff -r 9c245e375e05 -r bb6411d45356 configs/example/ruby_fs.py
--- a/configs/example/ruby_fs.pyTue Feb 08 07:47:02 2011 -0600
+++ b/configs/example/ruby_fs.pyTue Feb 08 15:52:44 2011 -0800
@@ -111,19 +111,17 @@
 
 if buildEnv['TARGET_ISA'] == alpha:
 system = makeLinuxAlphaRubySystem(test_mem_mode, bm[0])
-system.ruby = Ruby.create_system(options,
- system,
- system.piobus,
- system.dma_devices)
 elif buildEnv['TARGET_ISA'] == x86:
 system = makeLinuxX86System(test_mem_mode, options.num_cpus, bm[0], True)
 setWorkCountOptions(system, options)
-system.ruby = Ruby.create_system(options,
- system,
- system.piobus)
 else:
 fatal(incapable of building non-alpha or non-x86 full system!)
 
+system.ruby = Ruby.create_system(options,
+ system,
+ system.piobus,
+ system._dma_devices)
+
 system.cpu = [CPUClass(cpu_id=i) for i in xrange(options.num_cpus)]
 
 for (i, cpu) in enumerate(system.cpu):
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev


[m5-dev] changeset in m5: memtest: due to contention increase, increased ...

2011-02-08 Thread Brad Beckmann
changeset 685719afafe6 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=685719afafe6
description:
memtest: due to contention increase, increased deadlock threshold

diffstat:

 configs/example/ruby_mem_test.py |  6 ++
 tests/configs/memtest-ruby.py|  6 ++
 2 files changed, 12 insertions(+), 0 deletions(-)

diffs (32 lines):

diff -r bb6411d45356 -r 685719afafe6 configs/example/ruby_mem_test.py
--- a/configs/example/ruby_mem_test.py  Tue Feb 08 15:52:44 2011 -0800
+++ b/configs/example/ruby_mem_test.py  Tue Feb 08 15:53:33 2011 -0800
@@ -135,6 +135,12 @@
 cpu.test = system.ruby.cpu_ruby_ports[i].port
 cpu.functional = system.funcmem.port
 
+#
+# Since the memtester is incredibly bursty, increase the deadlock
+# threshold to 5 million cycles
+#
+system.ruby.cpu_ruby_ports[i].deadlock_threshold = 500
+
 for (i, dma) in enumerate(dmas):
 #
 # Tie the dma memtester ports to the correct functional port
diff -r bb6411d45356 -r 685719afafe6 tests/configs/memtest-ruby.py
--- a/tests/configs/memtest-ruby.py Tue Feb 08 15:52:44 2011 -0800
+++ b/tests/configs/memtest-ruby.py Tue Feb 08 15:53:33 2011 -0800
@@ -96,6 +96,12 @@
  #
  cpus[i].test = ruby_port.port
  cpus[i].functional = system.funcmem.port
+ 
+ #
+ # Since the memtester is incredibly bursty, increase the deadlock
+ # threshold to 1 million cycles
+ #
+ ruby_port.deadlock_threshold = 100
 
 # ---
 # run simulation
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev


[m5-dev] changeset in m5: x86: set IsCondControl flag for the appropriate...

2011-02-06 Thread Brad Beckmann
changeset 48d31b577847 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=48d31b577847
description:
x86: set IsCondControl flag for the appropriate microops

diffstat:

 src/arch/x86/isa/microops/regop.isa |  28 +++-
 src/arch/x86/isa/microops/seqop.isa |  13 +
 2 files changed, 28 insertions(+), 13 deletions(-)

diffs (160 lines):

diff -r 44522e30d358 -r 48d31b577847 src/arch/x86/isa/microops/regop.isa
--- a/src/arch/x86/isa/microops/regop.isa   Sat Feb 05 00:16:09 2011 -0800
+++ b/src/arch/x86/isa/microops/regop.isa   Sun Feb 06 22:14:16 2011 -0800
@@ -135,6 +135,7 @@
 %(op_class)s)
 {
 %(constructor)s;
+%(cond_control_flag_init)s;
 }
 }};
 
@@ -148,6 +149,7 @@
 %(op_class)s)
 {
 %(constructor)s;
+%(cond_control_flag_init)s;
 }
 }};
 
@@ -223,7 +225,7 @@
 
 class RegOpMeta(type):
 def buildCppClasses(self, name, Name, suffix, \
-code, flag_code, cond_check, else_code):
+code, flag_code, cond_check, else_code, 
cond_control_flag_init):
 
 # Globals to stick the output in
 global header_output
@@ -231,7 +233,8 @@
 global exec_output
 
 # Stick all the code together so it can be searched at once
-allCode = |.join((code, flag_code, cond_check, else_code))
+allCode = |.join((code, flag_code, cond_check, else_code, 
+cond_control_flag_init))
 
 # If op2 is used anywhere, make register and immediate versions
 # of this code.
@@ -246,20 +249,22 @@
 matcher.sub(src2_name, code),
 matcher.sub(src2_name, flag_code),
 matcher.sub(src2_name, cond_check),
-matcher.sub(src2_name, else_code))
+matcher.sub(src2_name, else_code),
+matcher.sub(src2_name, cond_control_flag_init))
 imm_name = %simm8 % match.group(prefix)
 self.buildCppClasses(name + i, Name, suffix + Imm,
 matcher.sub(imm_name, code),
 matcher.sub(imm_name, flag_code),
 matcher.sub(imm_name, cond_check),
-matcher.sub(imm_name, else_code))
+matcher.sub(imm_name, else_code),
+matcher.sub(imm_name, cond_control_flag_init))
 return
 
 # If there's something optional to do with flags, generate
 # a version without it and fix up this version to use it.
 if flag_code !=  or cond_check != true:
 self.buildCppClasses(name, Name, suffix,
-code, , true, else_code)
+code, , true, else_code, )
 suffix = Flags + suffix
 
 # If psrc1 or psrc2 is used, we need to actually insert code to
@@ -296,7 +301,8 @@
 {code : code,
  flag_code : flag_code,
  cond_check : cond_check,
- else_code : else_code})
+ else_code : else_code,
+ cond_control_flag_init: cond_control_flag_init})
 
 # Generate the actual code (finally!)
 header_output += templates[0].subst(iop)
@@ -319,16 +325,18 @@
 flag_code = cls.flag_code
 cond_check = cls.cond_check
 else_code = cls.else_code
+cond_control_flag_init = cls.cond_control_flag_init
 
 # Set up the C++ classes
-mcls.buildCppClasses(cls, name, Name, ,
-code, flag_code, cond_check, else_code)
+mcls.buildCppClasses(cls, name, Name, , code, flag_code,
+cond_check, else_code, cond_control_flag_init)
 
 # Hook into the microassembler dict
 global microopClasses
 microopClasses[name] = cls
 
-allCode = |.join((code, flag_code, cond_check, else_code))
+allCode = |.join((code, flag_code, cond_check, else_code,
+cond_control_flag_init))
 
 # If op2 is used anywhere, make register and immediate versions
 # of this code.
@@ -347,6 +355,7 @@
 flag_code = 
 cond_check = true
 else_code = ;
+cond_control_flag_init = 
 
 def __init__(self, dest, src1, op2, flags = None, dataSize = 
env.dataSize):
 self.dest = dest
@@ -402,6 +411,7 @@
 class CondRegOp(RegOp):
 abstract = True
 cond_check = checkCondition(ccFlagBits, ext)
+cond_control_flag_init = flags[IsCondControl] = flags[IsControl];
 
 class RdRegOp(RegOp):
 abstract = True
diff -r 44522e30d358 -r 

[m5-dev] changeset in m5: MOESI_hammer: Added full-bit directory support

2011-02-06 Thread Brad Beckmann
changeset 6f5299ff8260 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=6f5299ff8260
description:
MOESI_hammer: Added full-bit directory support

diffstat:

 configs/ruby/MOESI_hammer.py   |7 +-
 src/mem/protocol/MOESI_hammer-cache.sm |   20 ++-
 src/mem/protocol/MOESI_hammer-dir.sm   |  262 +++-
 src/mem/protocol/MOESI_hammer-msg.sm   |4 +-
 src/mem/protocol/RubySlicc_Exports.sm  |1 +
 src/mem/ruby/network/Network.cc|1 +
 6 files changed, 244 insertions(+), 51 deletions(-)

diffs (truncated from 741 to 300 lines):

diff -r 7fcfb515d7bf -r 6f5299ff8260 configs/ruby/MOESI_hammer.py
--- a/configs/ruby/MOESI_hammer.py  Sun Feb 06 22:14:18 2011 -0800
+++ b/configs/ruby/MOESI_hammer.py  Sun Feb 06 22:14:18 2011 -0800
@@ -55,7 +55,9 @@
   help=allow migratory sharing for atomic only accessed blocks)
 parser.add_option(--pf-on, action=store_true,
   help=Hammer: enable Probe Filter)
-
+parser.add_option(--dir-on, action=store_true,
+  help=Hammer: enable Full-bit Directory)
+
 def create_system(options, system, piobus, dma_devices):
 
 if buildEnv['PROTOCOL'] != 'MOESI_hammer':
@@ -165,7 +167,8 @@
 options.map_levels),
  probeFilter = pf,
  memBuffer = mem_cntrl,
- probe_filter_enabled = options.pf_on)
+ probe_filter_enabled = options.pf_on,
+ full_bit_dir_enabled = options.dir_on)
 
 if options.recycle_latency:
 dir_cntrl.recycle_latency = options.recycle_latency
diff -r 7fcfb515d7bf -r 6f5299ff8260 src/mem/protocol/MOESI_hammer-cache.sm
--- a/src/mem/protocol/MOESI_hammer-cache.smSun Feb 06 22:14:18 2011 -0800
+++ b/src/mem/protocol/MOESI_hammer-cache.smSun Feb 06 22:14:18 2011 -0800
@@ -137,6 +137,7 @@
 bool Dirty,  desc=Is the data dirty (different than memory)?;
 int NumPendingMsgs,  desc=Number of acks/data messages that this 
processor is waiting for;
 bool Sharers,desc=On a GetS, did we find any other sharers in 
the system;
+bool AppliedSilentAcks, default=false, desc=for full-bit dir, does the 
pending msg count reflect the silent acks;
 MachineID LastResponder, desc=last machine to send a response for this 
request;
 MachineID CurOwner,  desc=current owner of the block, used for 
UnblockS responses;
 Time InitialRequestTime, default=0, desc=time the initial requests was 
sent from the L1Cache;
@@ -526,6 +527,7 @@
 } else {
   out_msg.Acks := 2;
 }
+out_msg.SilentAcks := in_msg.SilentAcks;
 out_msg.MessageSize := MessageSizeType:Response_Data;
 out_msg.InitialRequestTime := in_msg.InitialRequestTime;
 out_msg.ForwardRequestTime := in_msg.ForwardRequestTime;
@@ -558,6 +560,7 @@
 } else {
   out_msg.Acks := 2;
 }
+out_msg.SilentAcks := in_msg.SilentAcks;
 out_msg.MessageSize := MessageSizeType:Response_Data;
 out_msg.InitialRequestTime := in_msg.InitialRequestTime;
 out_msg.ForwardRequestTime := in_msg.ForwardRequestTime;
@@ -581,6 +584,7 @@
 } else {
   out_msg.Acks := 2;
 }
+out_msg.SilentAcks := in_msg.SilentAcks;
 out_msg.MessageSize := MessageSizeType:Response_Data;
 out_msg.InitialRequestTime := in_msg.InitialRequestTime;
 out_msg.ForwardRequestTime := in_msg.ForwardRequestTime;
@@ -600,6 +604,7 @@
 out_msg.Dirty := cache_entry.Dirty;
 DPRINTF(RubySlicc, %s\n, out_msg.DataBlk);
 out_msg.Acks := machineCount(MachineType:L1Cache);
+out_msg.SilentAcks := in_msg.SilentAcks;
 out_msg.MessageSize := MessageSizeType:Response_Data;
 out_msg.InitialRequestTime := in_msg.InitialRequestTime;
 out_msg.ForwardRequestTime := in_msg.ForwardRequestTime;
@@ -615,6 +620,7 @@
 out_msg.Sender := machineID;
 out_msg.Destination.add(in_msg.Requestor);
 out_msg.Acks := 1;
+out_msg.SilentAcks := in_msg.SilentAcks;
 assert(in_msg.DirectedProbe == false);
 out_msg.MessageSize := MessageSizeType:Response_Control;
 out_msg.InitialRequestTime := in_msg.InitialRequestTime;
@@ -631,6 +637,7 @@
 out_msg.Sender := machineID;
 out_msg.Destination.add(in_msg.Requestor);
 out_msg.Acks := 1;
+out_msg.SilentAcks := in_msg.SilentAcks;
 assert(in_msg.DirectedProbe == false);
 out_msg.MessageSize := MessageSizeType:Response_Control;
 out_msg.InitialRequestTime := in_msg.InitialRequestTime;
@@ -779,9 +786,17 @@
 peek(responseToCache_in, ResponseMsg) {
   assert(in_msg.Acks  0);
   assert(is_valid(tbe));
+  DPRINTF(RubySlicc, 

[m5-dev] changeset in m5: ruby: Assert for x86 misaligned access

2011-02-06 Thread Brad Beckmann
changeset 5ccd97218ca0 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=5ccd97218ca0
description:
ruby: Assert for x86 misaligned access

This patch ensures only aligned access are passed to ruby and includes 
a fix
to the DPRINTF address print.

diffstat:

 src/mem/ruby/system/RubyPort.cc |  5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diffs (22 lines):

diff -r 00ad807ed2ca -r 5ccd97218ca0 src/mem/ruby/system/RubyPort.cc
--- a/src/mem/ruby/system/RubyPort.cc   Sun Feb 06 22:14:18 2011 -0800
+++ b/src/mem/ruby/system/RubyPort.cc   Sun Feb 06 22:14:18 2011 -0800
@@ -226,6 +226,9 @@
  pkt-getSize(), pc, type,
  RubyAccessMode_Supervisor, pkt);
 
+assert(Address(ruby_request.paddr).getOffset() + ruby_request.len =
+RubySystem::getBlockSizeBytes());
+
 // Submit the ruby request
 RequestStatus requestStatus = ruby_port-makeRequest(ruby_request);
 
@@ -237,7 +240,7 @@
 }
 
 DPRINTF(MemoryAccess,
-Request for address #x did not issue because %s\n,
+Request for address %#x did not issue because %s\n,
 pkt-getAddr(), RequestStatus_to_string(requestStatus));
 
 SenderState* senderState = safe_castSenderState*(pkt-senderState);
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev


[m5-dev] changeset in m5: ruby: x86 fs config support

2011-02-06 Thread Brad Beckmann
changeset 00ad807ed2ca in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=00ad807ed2ca
description:
ruby: x86 fs config support

diffstat:

 configs/common/FSConfig.py |  52 +
 configs/example/ruby_fs.py |  26 --
 2 files changed, 57 insertions(+), 21 deletions(-)

diffs (136 lines):

diff -r 6f5299ff8260 -r 00ad807ed2ca configs/common/FSConfig.py
--- a/configs/common/FSConfig.pySun Feb 06 22:14:18 2011 -0800
+++ b/configs/common/FSConfig.pySun Feb 06 22:14:18 2011 -0800
@@ -10,6 +10,7 @@
 # unmodified and in its entirety in all distributions of the software,
 # modified or unmodified, in source code or in binary form.
 #
+# Copyright (c) 2010-2011 Advanced Micro Devices, Inc.
 # Copyright (c) 2006-2008 The Regents of The University of Michigan
 # All rights reserved.
 #
@@ -286,7 +287,34 @@
 IO_address_space_base = 0x8000
 return IO_address_space_base + port;
 
-def makeX86System(mem_mode, numCPUs = 1, mdesc = None, self = None):
+def connectX86ClassicSystem(x86_sys):
+x86_sys.membus = MemBus(bus_id=1)
+x86_sys.physmem.port = x86_sys.membus.port
+
+# North Bridge
+x86_sys.iobus = Bus(bus_id=0)
+x86_sys.bridge = Bridge(delay='50ns', nack_delay='4ns')
+x86_sys.bridge.side_a = x86_sys.iobus.port
+x86_sys.bridge.side_b = x86_sys.membus.port
+
+# connect the io bus
+x86_sys.pc.attachIO(x86_sys.iobus)
+
+def connectX86RubySystem(x86_sys):
+# North Bridge
+x86_sys.piobus = Bus(bus_id=0)
+
+#
+# Pio functional accesses from devices need direct access to memory
+# RubyPort currently does support functional accesses.  Therefore provide
+# the piobus a direct connection to physical memory
+#
+x86_sys.piobus.port = x86_sys.physmem.port
+
+x86_sys.pc.attachIO(x86_sys.piobus)
+
+
+def makeX86System(mem_mode, numCPUs = 1, mdesc = None, self = None, Ruby = 
False):
 if self == None:
 self = X86System()
 
@@ -298,19 +326,16 @@
 self.mem_mode = mem_mode
 
 # Physical memory
-self.membus = MemBus(bus_id=1)
 self.physmem = PhysicalMemory(range = AddrRange(mdesc.mem()))
-self.physmem.port = self.membus.port
-
-# North Bridge
-self.iobus = Bus(bus_id=0)
-self.bridge = Bridge(delay='50ns', nack_delay='4ns')
-self.bridge.side_a = self.iobus.port
-self.bridge.side_b = self.membus.port
 
 # Platform
 self.pc = Pc()
-self.pc.attachIO(self.iobus)
+
+# Create and connect the busses required by each memory system
+if Ruby:
+connectX86RubySystem(self)
+else:
+connectX86ClassicSystem(self)
 
 self.intrctrl = IntrControl()
 
@@ -380,12 +405,11 @@
 for i in range(3, 15):
 assignISAInt(i, i)
 
-
-def makeLinuxX86System(mem_mode, numCPUs = 1, mdesc = None):
+def makeLinuxX86System(mem_mode, numCPUs = 1, mdesc = None, Ruby = False):
 self = LinuxX86System()
 
-# Build up a generic x86 system and then specialize it for Linux
-makeX86System(mem_mode, numCPUs, mdesc, self)
+# Build up the x86 system and then specialize it for Linux
+makeX86System(mem_mode, numCPUs, mdesc, self, Ruby)
 
 # We assume below that there's at least 1MB of memory. We'll require 2
 # just to avoid corner cases.
diff -r 6f5299ff8260 -r 00ad807ed2ca configs/example/ruby_fs.py
--- a/configs/example/ruby_fs.pySun Feb 06 22:14:18 2011 -0800
+++ b/configs/example/ruby_fs.pySun Feb 06 22:14:18 2011 -0800
@@ -1,4 +1,4 @@
-# Copyright (c) 2009 Advanced Micro Devices, Inc.
+# Copyright (c) 2009-2011 Advanced Micro Devices, Inc.
 # All rights reserved.
 #
 # Redistribution and use in source and binary forms, with or without
@@ -109,12 +109,19 @@
 
 CPUClass.clock = options.clock
 
-system = makeLinuxAlphaRubySystem(test_mem_mode, bm[0])
-
-system.ruby = Ruby.create_system(options,
- system,
- system.piobus,
- system._dma_devices)
+if buildEnv['TARGET_ISA'] == alpha:
+system = makeLinuxAlphaRubySystem(test_mem_mode, bm[0])
+system.ruby = Ruby.create_system(options,
+ system,
+ system.piobus,
+ system.dma_devices)
+elif buildEnv['TARGET_ISA'] == x86:
+system = makeLinuxX86System(test_mem_mode, options.num_cpus, bm[0], True)
+system.ruby = Ruby.create_system(options,
+ system,
+ system.piobus)
+else:
+fatal(incapable of building non-alpha or non-x86 full system!)
 
 system.cpu = [CPUClass(cpu_id=i) for i in xrange(options.num_cpus)]
 
@@ -124,6 +131,11 @@
 #
 cpu.icache_port = system.ruby.cpu_ruby_ports[i].port
 cpu.dcache_port = system.ruby.cpu_ruby_ports[i].port
+if buildEnv['TARGET_ISA'] == x86:
+cpu.itb.walker.port = 

[m5-dev] changeset in m5: ruby: Fix RubyPort to properly handle retrys

2011-02-06 Thread Brad Beckmann
changeset 8a92b39be50e in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=8a92b39be50e
description:
ruby: Fix RubyPort to properly handle retrys

diffstat:

 src/mem/ruby/system/RubyPort.cc  |  29 +
 src/mem/ruby/system/RubyPort.hh  |  25 +
 src/mem/ruby/system/Sequencer.cc |   1 -
 src/mem/ruby/system/Sequencer.hh |   2 --
 src/mem/ruby/system/Sequencer.py |   2 +-
 5 files changed, 55 insertions(+), 4 deletions(-)

diffs (161 lines):

diff -r eee578ed2130 -r 8a92b39be50e src/mem/ruby/system/RubyPort.cc
--- a/src/mem/ruby/system/RubyPort.cc   Sun Feb 06 22:14:18 2011 -0800
+++ b/src/mem/ruby/system/RubyPort.cc   Sun Feb 06 22:14:18 2011 -0800
@@ -49,6 +49,8 @@
 m_request_cnt = 0;
 pio_port = NULL;
 physMemPort = NULL;
+
+m_usingRubyTester = p-using_ruby_tester;
 }
 
 void
@@ -108,6 +110,7 @@
 {
 DPRINTF(Ruby, creating port from ruby sequcner to cpu %s\n, _name);
 ruby_port = _port;
+_onRetryList = false;
 }
 
 Tick
@@ -256,9 +259,18 @@
 // Otherwise, we need to delete the senderStatus we just created and return
 // false.
 if (requestStatus == RequestStatus_Issued) {
+DPRINTF(MemoryAccess, Request %x issued\n, pkt-getAddr());
 return true;
 }
 
+//
+// Unless one is using the ruby tester, record the stalled M5 port for 
+// later retry when the sequencer becomes free.
+//
+if (!ruby_port-m_usingRubyTester) {
+ruby_port-addToRetryList(this);
+}
+
 DPRINTF(MemoryAccess,
 Request for address %#x did not issue because %s\n,
 pkt-getAddr(), RequestStatus_to_string(requestStatus));
@@ -283,6 +295,23 @@
 delete senderState;
 
 port-hitCallback(pkt);
+
+//
+// If we had to stall the M5Ports, wake them up because the sequencer
+// likely has free resources now.
+//
+if (waitingOnSequencer) {
+for (std::listM5Port*::iterator i = retryList.begin();
+ i != retryList.end(); ++i) {
+(*i)-sendRetry();
+(*i)-onRetryList(false);
+DPRINTF(MemoryAccess,
+Sequencer may now be free.  SendRetry to port %s\n,
+(*i)-name());
+}
+retryList.clear();
+waitingOnSequencer = false;
+}
 }
 
 void
diff -r eee578ed2130 -r 8a92b39be50e src/mem/ruby/system/RubyPort.hh
--- a/src/mem/ruby/system/RubyPort.hh   Sun Feb 06 22:14:18 2011 -0800
+++ b/src/mem/ruby/system/RubyPort.hh   Sun Feb 06 22:14:18 2011 -0800
@@ -50,12 +50,19 @@
 {
   private:
 RubyPort *ruby_port;
+bool _onRetryList;
 
   public:
 M5Port(const std::string _name, RubyPort *_port);
 bool sendTiming(PacketPtr pkt);
 void hitCallback(PacketPtr pkt);
 unsigned deviceBlockSize() const;
+
+bool onRetryList() 
+{ return _onRetryList; }
+
+void onRetryList(bool newVal)
+{ _onRetryList = newVal; }
 
   protected:
 virtual bool recvTiming(PacketPtr pkt);
@@ -118,14 +125,32 @@
 AbstractController* m_controller;
 MessageBuffer* m_mandatory_q_ptr;
 PioPort* pio_port;
+bool m_usingRubyTester;
 
   private:
+void addToRetryList(M5Port * port)
+{
+if (!port-onRetryList()) {
+port-onRetryList(true);
+retryList.push_back(port);
+waitingOnSequencer = true;
+}
+}
+
 uint16_t m_port_id;
 uint64_t m_request_cnt;
 
 M5Port* physMemPort;
 
 PhysicalMemory* physmem;
+
+//
+// Based on similar code in the M5 bus.  Stores pointers to those ports
+// that should be called when the Sequencer becomes available after a 
stall.
+//
+std::listM5Port* retryList;
+
+bool waitingOnSequencer;
 };
 
 #endif // __MEM_RUBY_SYSTEM_RUBYPORT_HH__
diff -r eee578ed2130 -r 8a92b39be50e src/mem/ruby/system/Sequencer.cc
--- a/src/mem/ruby/system/Sequencer.cc  Sun Feb 06 22:14:18 2011 -0800
+++ b/src/mem/ruby/system/Sequencer.cc  Sun Feb 06 22:14:18 2011 -0800
@@ -72,7 +72,6 @@
 m_dataCache_ptr = p-dcache;
 m_max_outstanding_requests = p-max_outstanding_requests;
 m_deadlock_threshold = p-deadlock_threshold;
-m_usingRubyTester = p-using_ruby_tester;
 
 assert(m_max_outstanding_requests  0);
 assert(m_deadlock_threshold  0);
diff -r eee578ed2130 -r 8a92b39be50e src/mem/ruby/system/Sequencer.hh
--- a/src/mem/ruby/system/Sequencer.hh  Sun Feb 06 22:14:18 2011 -0800
+++ b/src/mem/ruby/system/Sequencer.hh  Sun Feb 06 22:14:18 2011 -0800
@@ -152,8 +152,6 @@
 int m_load_waiting_on_store_cycles;
 int m_load_waiting_on_load_cycles;
 
-bool m_usingRubyTester;
-
 class SequencerWakeupEvent : public Event
 {
   private:
diff -r eee578ed2130 -r 8a92b39be50e src/mem/ruby/system/Sequencer.py
--- a/src/mem/ruby/system/Sequencer.py  Sun Feb 06 22:14:18 2011 -0800
+++ b/src/mem/ruby/system/Sequencer.py  Sun Feb 06 

[m5-dev] changeset in m5: dev: fixed bugs to extend interrupt capability ...

2011-02-06 Thread Brad Beckmann
changeset 70b56a9ac1b2 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=70b56a9ac1b2
description:
dev: fixed bugs to extend interrupt capability beyond 15 cores

diffstat:

 src/arch/x86/interrupts.cc |   7 +++
 src/dev/x86/i82094aa.cc|  22 ++
 src/dev/x86/i82094aa.hh|   2 ++
 src/dev/x86/intdev.cc  |   9 +
 src/dev/x86/intdev.hh  |  10 ++
 5 files changed, 38 insertions(+), 12 deletions(-)

diffs (126 lines):

diff -r a9f05ab40763 -r 70b56a9ac1b2 src/arch/x86/interrupts.cc
--- a/src/arch/x86/interrupts.ccSun Feb 06 22:14:18 2011 -0800
+++ b/src/arch/x86/interrupts.ccSun Feb 06 22:14:18 2011 -0800
@@ -294,7 +294,14 @@
 void
 X86ISA::Interrupts::init()
 {
+//
+// The local apic must register its address ranges on both its pio port
+// via the basicpiodevice(piodevice) init() function and its int port
+// that it inherited from IntDev.  Note IntDev is not a SimObject itself.
+//
 BasicPioDevice::init();
+IntDev::init();
+
 Pc * pc = dynamic_castPc *(platform);
 assert(pc);
 pc-southBridge-ioApic-registerLocalApic(initialApicId, this);
diff -r a9f05ab40763 -r 70b56a9ac1b2 src/dev/x86/i82094aa.cc
--- a/src/dev/x86/i82094aa.cc   Sun Feb 06 22:14:18 2011 -0800
+++ b/src/dev/x86/i82094aa.cc   Sun Feb 06 22:14:18 2011 -0800
@@ -41,9 +41,12 @@
 latency(p-pio_latency), pioAddr(p-pio_addr),
 extIntPic(p-external_int_pic), lowestPriorityOffset(0)
 {
-// This assumes there's only one I/O APIC in the system
+// This assumes there's only one I/O APIC in the system and since the apic
+// id is stored in a 8-bit field with 0xff meaning broadcast, the id must
+// be less than 0xff
+
+assert(p-apic_id  0xff);
 initialApicId = id = p-apic_id;
-assert(id = 0xf);
 arbId = id;
 regSel = 0;
 RedirTableEntry entry = 0;
@@ -54,6 +57,17 @@
 }
 }
 
+void
+X86ISA::I82094AA::init()
+{
+// The io apic must register its address ranges on both its pio port
+// via the piodevice init() function and its int port that it inherited
+// from IntDev.  Note IntDev is not a SimObject itself.
+
+PioDevice::init();
+IntDev::init();
+}
+
 Tick
 X86ISA::I82094AA::read(PacketPtr pkt)
 {
@@ -96,11 +110,11 @@
 X86ISA::I82094AA::writeReg(uint8_t offset, uint32_t value)
 {
 if (offset == 0x0) {
-id = bits(value, 27, 24);
+id = bits(value, 31, 24);
 } else if (offset == 0x1) {
 // The IOAPICVER register is read only.
 } else if (offset == 0x2) {
-arbId = bits(value, 27, 24);
+arbId = bits(value, 31, 24);
 } else if (offset = 0x10  offset = (0x10 + TableSize * 2)) {
 int index = (offset - 0x10) / 2;
 if (offset % 2) {
diff -r a9f05ab40763 -r 70b56a9ac1b2 src/dev/x86/i82094aa.hh
--- a/src/dev/x86/i82094aa.hh   Sun Feb 06 22:14:18 2011 -0800
+++ b/src/dev/x86/i82094aa.hh   Sun Feb 06 22:14:18 2011 -0800
@@ -98,6 +98,8 @@
 
 I82094AA(Params *p);
 
+void init();
+
 Tick read(PacketPtr pkt);
 Tick write(PacketPtr pkt);
 
diff -r a9f05ab40763 -r 70b56a9ac1b2 src/dev/x86/intdev.cc
--- a/src/dev/x86/intdev.cc Sun Feb 06 22:14:18 2011 -0800
+++ b/src/dev/x86/intdev.cc Sun Feb 06 22:14:18 2011 -0800
@@ -48,6 +48,15 @@
 }
 }
 
+void
+X86ISA::IntDev::init()
+{
+if (!intPort) {
+panic(Int port not connected to anything!);
+}
+intPort-sendStatusChange(Port::RangeChange);
+}
+
 X86ISA::IntSourcePin *
 X86IntSourcePinParams::create()
 {
diff -r a9f05ab40763 -r 70b56a9ac1b2 src/dev/x86/intdev.hh
--- a/src/dev/x86/intdev.hh Sun Feb 06 22:14:18 2011 -0800
+++ b/src/dev/x86/intdev.hh Sun Feb 06 22:14:18 2011 -0800
@@ -84,14 +84,6 @@
 // need to be moved into a subclass.
 void sendMessage(ApicList apics,
 TriggerIntMessage message, bool timing);
-
-void recvStatusChange(Status status)
-{
-if (status == RangeChange) {
-sendStatusChange(Port::RangeChange);
-}
-}
-
 };
 
 IntPort * intPort;
@@ -110,6 +102,8 @@
 virtual ~IntDev()
 {}
 
+virtual void init();
+
 virtual void
 signalInterrupt(int line)
 {
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev


[m5-dev] changeset in m5: m5: added work completed monitoring support

2011-02-06 Thread Brad Beckmann
changeset eee5bb0fb8ea in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=eee5bb0fb8ea
description:
m5: added work completed monitoring support

diffstat:

 configs/common/FSConfig.py|   19 -
 configs/common/Options.py |   14 +++
 configs/example/fs.py |2 +-
 configs/example/ruby_fs.py|2 +-
 src/arch/x86/isa/decoder/two_byte_opcodes.isa |6 +
 src/cpu/base.cc   |   10 ++
 src/cpu/base.hh   |4 +
 src/sim/SConscript|1 +
 src/sim/System.py |   14 +++
 src/sim/pseudo_inst.cc|  117 ++
 src/sim/pseudo_inst.hh|2 +
 src/sim/system.cc |9 +-
 src/sim/system.hh |   42 +
 util/m5/m5op_x86.S|2 +
 util/m5/m5ops.h   |3 +
 15 files changed, 243 insertions(+), 4 deletions(-)

diffs (truncated from 423 to 300 lines):

diff -r 70b56a9ac1b2 -r eee5bb0fb8ea configs/common/FSConfig.py
--- a/configs/common/FSConfig.pySun Feb 06 22:14:18 2011 -0800
+++ b/configs/common/FSConfig.pySun Feb 06 22:14:19 2011 -0800
@@ -405,7 +405,8 @@
 for i in range(3, 15):
 assignISAInt(i, i)
 
-def makeLinuxX86System(mem_mode, numCPUs = 1, mdesc = None, Ruby = False):
+def makeLinuxX86System(mem_mode, options, mdesc = None, Ruby = False):
+numCPUs = options.num_cpus
 self = LinuxX86System()
 
 # Build up the x86 system and then specialize it for Linux
@@ -415,6 +416,22 @@
 # just to avoid corner cases.
 assert(self.physmem.range.second.getValue() = 0x20)
 
+# set work count options
+if options.work_item_id != None:
+self.work_item_id = options.work_item_id
+if options.work_begin_cpu_id_exit != None:
+self.work_begin_cpu_id_exit = options.work_begin_cpu_id_exit
+if options.work_end_exit_count != None:
+self.work_end_exit_count = options.work_end_exit_count
+if options.work_end_checkpoint_count != None:
+self.work_end_ckpt_count = options.work_end_checkpoint_count
+if options.work_begin_exit_count != None:
+self.work_begin_exit_count = options.work_begin_exit_count
+if options.work_begin_checkpoint_count != None:
+self.work_begin_ckpt_count = options.work_begin_checkpoint_count
+if options.work_cpus_checkpoint_count != None:
+self.work_cpus_ckpt_count = options.work_cpus_checkpoint_count
+
 # Mark the first megabyte of memory as reserved
 self.e820_table.entries.append(X86E820Entry(
 addr = 0,
diff -r 70b56a9ac1b2 -r eee5bb0fb8ea configs/common/Options.py
--- a/configs/common/Options.py Sun Feb 06 22:14:18 2011 -0800
+++ b/configs/common/Options.py Sun Feb 06 22:14:19 2011 -0800
@@ -54,6 +54,14 @@
 parser.add_option(--maxtime, type=float)
 parser.add_option(--maxinsts, type=int)
 parser.add_option(--prog_intvl, type=int)
+parser.add_option(--work-item-id, action=store, type=int,
+  help=the specific work id for exit  checkpointing)
+parser.add_option(--work-begin-cpu-id-exit, action=store, type=int,
+  help=exit when work starts on the specified cpu)
+parser.add_option(--work-end-exit-count, action=store, type=int,
+  help=exit at specified work end count)
+parser.add_option(--work-begin-exit-count, action=store, type=int,
+  help=exit at specified work begin count)
 
 
 # Checkpointing options
@@ -69,6 +77,12 @@
 help=restore from checkpoint N)
 parser.add_option(--checkpoint-at-end, action=store_true,
   help=take a checkpoint at end of run)
+parser.add_option(--work-begin-checkpoint-count, action=store, type=int,
+  help=checkpoint at specified work begin count)
+parser.add_option(--work-end-checkpoint-count, action=store, type=int,
+  help=checkpoint at specified work end count)
+parser.add_option(--work-cpus-checkpoint-count, action=store, type=int,
+  help=checkpoint and exit when active cpu count is reached)
 
 
 # CPU Switching - default switch model goes from a checkpoint
diff -r 70b56a9ac1b2 -r eee5bb0fb8ea configs/example/fs.py
--- a/configs/example/fs.py Sun Feb 06 22:14:18 2011 -0800
+++ b/configs/example/fs.py Sun Feb 06 22:14:19 2011 -0800
@@ -131,7 +131,7 @@
 elif buildEnv['TARGET_ISA'] == sparc:
 test_sys = makeSparcSystem(test_mem_mode, bm[0])
 elif buildEnv['TARGET_ISA'] == x86:
-test_sys = makeLinuxX86System(test_mem_mode, np, bm[0])
+test_sys = makeLinuxX86System(test_mem_mode, options, bm[0])
 elif buildEnv['TARGET_ISA'] == arm:
 test_sys = makeLinuxArmSystem(test_mem_mode, bm[0],
 bare_metal=options.bare_metal, machine_type=options.machine_type)
diff -r 

  1   2   3   4   5   >