Re: [gem5-dev] Review Request: Ruby: Add support for functional accesses
--- 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
--- 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
--- 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
--- 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
--- 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: garnet: rename and rearrange config parameters
--- 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
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
--- 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
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
--- 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.
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
--- 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...
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...
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
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
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
--- 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
--- 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
--- 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
--- 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
--- 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
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.
--- 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
--- 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
--- 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
--- 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
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
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
--- 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
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
--- 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
--- 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
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
--- 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
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
--- 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
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
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
--- 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.
--- 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.
--- 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.
--- 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.
--- 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.
--- 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.
--- 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
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
--- 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
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
--- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
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
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
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
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
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
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
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
--- 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
--- 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
--- 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
---
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
--- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
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
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
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
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
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
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
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 ...
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 ...
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...
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
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
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
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
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 ...
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
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
[m5-dev] changeset in m5: mem: Added support for Null data packet
changeset bc39c93a5519 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=bc39c93a5519
description:
mem: Added support for Null data packet
The packet now identifies whether static or dynamic data has been
allocated and
is used by Ruby to determine whehter to copy the data pointer into the
ruby
request. Subsequently, Ruby can be told not to update phys memory when
receiving packets.
diffstat:
src/mem/packet.hh | 5 ++---
src/mem/ruby/system/DMASequencer.cc | 12
src/mem/ruby/system/RubyPort.cc | 22 +-
src/mem/ruby/system/RubyPort.hh | 5 -
src/mem/ruby/system/Sequencer.py| 4 +++-
5 files changed, 30 insertions(+), 18 deletions(-)
diffs (174 lines):
diff -r eee5bb0fb8ea -r bc39c93a5519 src/mem/packet.hh
--- a/src/mem/packet.hh Sun Feb 06 22:14:19 2011 -0800
+++ b/src/mem/packet.hh Sun Feb 06 22:14:19 2011 -0800
@@ -681,9 +681,9 @@
*/
template typename T
T*
-getPtr()
+getPtr(bool null_ok = false)
{
-assert(flags.isSet(STATIC_DATA|DYNAMIC_DATA));
+assert(null_ok || flags.isSet(STATIC_DATA|DYNAMIC_DATA));
return (T*)data;
}
@@ -768,7 +768,6 @@
data = new uint8_t[getSize()];
}
-
/**
* Check a functional request against a memory value represented
* by a base/size pair and an associated data array. If the
diff -r eee5bb0fb8ea -r bc39c93a5519 src/mem/ruby/system/DMASequencer.cc
--- a/src/mem/ruby/system/DMASequencer.cc Sun Feb 06 22:14:19 2011 -0800
+++ b/src/mem/ruby/system/DMASequencer.cc Sun Feb 06 22:14:19 2011 -0800
@@ -97,8 +97,10 @@
msg-getLen() = (offset + len) = RubySystem::getBlockSizeBytes() ?
len : RubySystem::getBlockSizeBytes() - offset;
-if (write) {
-msg-getDataBlk().setData(data, offset, msg-getLen());
+if (write (data != NULL)) {
+if (active_request.data != NULL) {
+msg-getDataBlk().setData(data, offset, msg-getLen());
+}
}
assert(m_mandatory_q_ptr != NULL);
@@ -160,8 +162,10 @@
if (active_request.bytes_completed == 0)
offset = active_request.start_paddr m_data_block_mask;
assert(active_request.write == false);
-memcpy(active_request.data[active_request.bytes_completed],
- dblk.getData(offset, len), len);
+if (active_request.data != NULL) {
+memcpy(active_request.data[active_request.bytes_completed],
+ dblk.getData(offset, len), len);
+}
issueNext();
}
diff -r eee5bb0fb8ea -r bc39c93a5519 src/mem/ruby/system/RubyPort.cc
--- a/src/mem/ruby/system/RubyPort.cc Sun Feb 06 22:14:19 2011 -0800
+++ b/src/mem/ruby/system/RubyPort.cc Sun Feb 06 22:14:19 2011 -0800
@@ -51,6 +51,7 @@
physMemPort = NULL;
m_usingRubyTester = p-using_ruby_tester;
+access_phys_mem = p-access_phys_mem;
}
void
@@ -64,7 +65,8 @@
RubyPort::getPort(const std::string if_name, int idx)
{
if (if_name == port) {
-return new M5Port(csprintf(%s-port%d, name(), idx), this);
+return new M5Port(csprintf(%s-port%d, name(), idx), this,
+ access_phys_mem);
}
if (if_name == pio_port) {
@@ -80,7 +82,8 @@
// RubyPort should only have one port to physical memory
assert (physMemPort == NULL);
-physMemPort = new M5Port(csprintf(%s-physMemPort, name()), this);
+physMemPort = new M5Port(csprintf(%s-physMemPort, name()), this,
+ access_phys_mem);
return physMemPort;
}
@@ -105,12 +108,13 @@
}
RubyPort::M5Port::M5Port(const std::string _name,
- RubyPort *_port)
+ RubyPort *_port, bool _access_phys_mem)
: SimpleTimingPort(_name, _port)
{
DPRINTF(Ruby, creating port from ruby sequcner to cpu %s\n, _name);
ruby_port = _port;
_onRetryList = false;
+access_phys_mem = _access_phys_mem;
}
Tick
@@ -245,7 +249,7 @@
}
}
-RubyRequest ruby_request(pkt-getAddr(), pkt-getPtruint8_t(),
+RubyRequest ruby_request(pkt-getAddr(), pkt-getPtruint8_t(true),
pkt-getSize(), pc, type,
RubyAccessMode_Supervisor, pkt);
@@ -320,9 +324,10 @@
bool needsResponse = pkt-needsResponse();
//
-// All responses except failed SC operations access M5 physical memory
+// Unless specified at configuraiton, all responses except failed SC
+// operations access M5 physical memory.
//
-bool accessPhysMem = true;
+bool accessPhysMem = access_phys_mem;
if (pkt-isLLSC()) {
if (pkt-isWrite()) {
@@ -351,13 +356,12 @@
if (accessPhysMem) {
ruby_port-physMemPort-sendAtomic(pkt);
+} else {
+pkt-makeResponse();
}
// turn packet around to go back to requester if response expected
if
