[m5-dev] Cron m5t...@zizzer /z/m5/regression/do-regression quick
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/inorder-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/o3-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby passed. * build/POWER_SE/tests/fast/quick/00.hello/power/linux/simple-atomic passed. * build/POWER_SE/tests/fast/quick/00.hello/power/linux/o3-timing passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/o3-timing passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing-ruby passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing
Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC
Can you give me an example of a protocol where getCacheEntry() behaves in a different manner? -- Nilay On Wed, 5 Jan 2011, Beckmann, Brad wrote: Hi Nilay, Lisa Hsu (another member of the lab here at AMD) and I were discussing these changes a bit more and there was one particular idea that came out of our conversation that I wanted to relay to you. Basically, we were thinking about how these changes will impact the flexibility of SLICC and we concluded that it is important to allow one to craft custom getCacheEntry functions for each protocol. I know initially I was hoping to generate these functions, but I now don???t think that is possible without restricting what protocols can be support by SLICC. Instead we can use these customized getCacheEntry functions to pass the cache entry to the actions via the trigger function. For those controllers that manage multiple cache memories, it is up to the programmer to understand what the cache entry pointer points to. That should eliminate the need to have multiple *cacheMemory_entry variables in the .sm files. Instead there is just the cache_entry variable that is set either by the trigger function call or set_cache_entry. Does that make sense to you? Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Updating MOESI CMP Directory protocol as per the new interface
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/359/ --- (Updated 2011-01-06 06:52:27.512216) Review request for Default. Summary --- This is a request for reviewing the proposed changes to the MOESI CMP directory cache coherence protocol to make it conform with the new cache memory interface and changes to SLICC. Diffs (updated) - src/mem/protocol/MOESI_CMP_directory-dir.sm UNKNOWN src/mem/protocol/MOESI_CMP_directory-dma.sm UNKNOWN src/mem/protocol/MOESI_CMP_directory-L2cache.sm UNKNOWN src/mem/protocol/MOESI_CMP_directory-L1cache.sm UNKNOWN Diff: http://reviews.m5sim.org/r/359/diff Testing --- These changes have been tested using the Ruby random tester. The tester was used with -l = 1048576 and -n = 2. Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/358/ --- (Updated 2011-01-06 07:29:17.470364) Review request for Default. Changes --- This revision has following changes from the previous version - 1. The most important change is that we now formally assume that if multiple cache memories under the controller of a single controller, then for any given address, at most one of them can hold a cache entry for it. This simplifies a lot many things. We are now required to work with only one cache entry pointer. This pointer is set to the cache entry for the address being passed to the trigger function. The checks that have to carried out for code generation also get simplified. 2. is_invalid() has been introduced that can be used for testing whether a given entry (cache or transaction buffer) == NULL. 3. Earlier, *_ptr variables where being added on declaration of methods (which make use of TBE and / or Cache Entry), actions and in-ports. This is not being done any longer. 4. In FuncCallExprAST.py, when function parameters are passed to a function, a check has been added for expressions that are being passed as parameters. If the expression has a type TBE or AbstractCacheEntry, then all the occurrences of '*' are removed from the expression. This is under the assumption that the code from which the function call is being made has pointers to the variables being passed. Since SLICC will replace any occurrence of these variables with dereferenced version, therefore it is required that '*' be removed before the variable is passed to the function. Summary --- The purpose of this patch is to change the way CacheMemory interfaces with coherence protocols. Currently, whenever a cache controller (defined in the protocol under consideration) needs to carry out any operation on a cache block, it looks up the tag hash map and figures out whether or not the block exists in the cache. In case it does exist, the operation is carried out (which requires another lookup). Over a single clock cycle, multiple such lookups take place as observed through profiling of different protocols. It was seen that the tag lookup takes anything from 10% to 20% of the simulation time. In order to reduce this time, this patch is being posted. The CacheMemory class now will have a function that will return pointer to a cache block entry, instead of a reference (though the function that returns the reference has been retained currently). Functions have been introduced for setting/unsetting a pointer and check its pointer. Similar changes have been carried out for Transaction Buffer entries as well. Note that changes are required to both SLICC and the protocol files. This patch carries out changes to SLICC and committing this patch alone, I believe, will ___break___ all the protocols. I am working on patching the protocols as well. This patch is being put to get feed back from other developers. Diffs (updated) - src/mem/ruby/slicc_interface/AbstractCacheEntry.hh UNKNOWN src/mem/ruby/slicc_interface/AbstractCacheEntry.cc UNKNOWN src/mem/ruby/system/CacheMemory.hh UNKNOWN src/mem/ruby/system/CacheMemory.cc UNKNOWN src/mem/ruby/system/TBETable.hh UNKNOWN src/mem/slicc/ast/ActionDeclAST.py UNKNOWN src/mem/slicc/ast/FormalParamAST.py UNKNOWN src/mem/slicc/ast/FuncCallExprAST.py UNKNOWN src/mem/slicc/ast/InPortDeclAST.py UNKNOWN src/mem/slicc/ast/MethodCallExprAST.py UNKNOWN src/mem/slicc/ast/TypeDeclAST.py UNKNOWN src/mem/slicc/ast/__init__.py UNKNOWN src/mem/slicc/parser.py UNKNOWN src/mem/slicc/symbols/StateMachine.py UNKNOWN src/mem/protocol/RubySlicc_Types.sm UNKNOWN Diff: http://reviews.m5sim.org/r/358/diff Testing --- I have tested these changes using the MOESI_CMP_directory and MI protocols. Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] does drain need to be so complicated?
So I think I figured out the right way to handle drain, but I don't know how soon I'll have time to get to it, so I wanted to write it down and send it out for feedback, in case someone else has time to do it, and so I don't forget what I came up with. So here's the idea: Basically the C++ mechanisms all hang off of SimObject, so any SimObject can serve as the root of a subtree that gets drained. The callback pointer that gets passed to each SimObject's drain() method is just the pointer to the root of the hierarchy that's being drained; when the object wants to invoke the callback, it calls a specific new method on that root SimObject (like notifyDrainComplete() or something) that replaces the current DrainEvent::process() method. As I mentioned before, this logically requires an extra int per SimObject so that the SimObject can maintain the drain count while it's acting as root. Given that this is not performance critical, I suggest we have a global data structure that's logically a map from SimObject* to int. Then when we initiate a drain we just allocate a SimObject*,int pair for the root and use that as the drain counter, and we can deallocate it when the drain is over. In the near term since we don't support concurrent drains we could simplify this as just two global variables, the drain count and a SimObject* just to track the current root and print a warning if someone does manage to fire off two concurrent drains somehow. I'll even provide the diff for the Python side of the change: --- a/src/python/m5/simulate.py +++ b/src/python/m5/simulate.py @@ -147,15 +147,13 @@ # be drained. def drain(root): all_drained = False -drain_event = internal.event.createCountedDrain() -unready_objs = sum(obj.drain(drain_event) for obj in root.descendants()) +unready_objs = sum(obj.drain(root) for obj in root.descendants()) # If we've got some objects that can't drain immediately, then simulate if unready_objs 0: -drain_event.setCount(unready_objs) +root.setDrainCount(unready_objs) simulate() else: all_drained = True -internal.event.cleanupCountedDrain(drain_event) return all_drained (Not counting all the CountedDrainEvent swig stuff that can get whacked.) One nice side-effect is that we don't have to expose any particular callback or event object to python for it to allocate dynamically... whatever dynamic allocation happens is hidden behind the SimObject interface. (I know Nate will say this isn't hard, but I still feel like we should be keeping the python/c++ interface as narrow and clean as possible.) Another nice thing about this setup is that once a node knows that it is the root of a drain, it can easily detect if a drain is started somewhere further up the hierarchy, and in the long run maybe we'd want to do something to combine the two drain operations dynamically. We don't need to figure out the details yet, but I feel like this puts us in a good position to handle it intelligently if we need to. Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: scons: show sources and targets when building.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/366/ --- (Updated 2011-01-06 11:04:43.691088) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary (updated) --- scons: show sources and targets when building. I like the brevity of Ali's recent change, but the ambiguity of sometimes showing the source and sometimes the target is a little confusing. This patch makes scons typically list all sources and all targets for each action, with the common path prefix factored out for brevity. It's a little more verbose now but also more informative. Diffs (updated) - SConstruct 9f9e10967912 src/SConscript 9f9e10967912 src/arch/SConscript 9f9e10967912 src/arch/isa_parser.py 9f9e10967912 Diff: http://reviews.m5sim.org/r/366/diff Testing --- quick regressions pass Thanks, Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: scons: show sources and targets when building.
So is it possible to populate the Changes section with some comments when you update a patch using 'hg postreview -e NNN'? I've tried it with and without '-u' and each time it publishes the updated diff without giving me a chance to add/edit comments on the website like it does with the original request. Anyway, here are the comments I would have entered: This update uses Nate's callable-object suggestion, which I think cleans things up a bit, and also adds colorization, including --color and --no-color options to force colors on or off (overriding the default behavior of using sys.stdout.isatty() to decide). I made a stab at a maize-and-blue color scheme, but I'm not really sold on it; suggestions for a better color scheme are welcome. Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: scons: show sources and targets when building.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/366/ --- (Updated 2011-01-06 11:15:30.932181) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Changes --- Added a screenshot to show color scheme. Summary --- scons: show sources and targets when building. I like the brevity of Ali's recent change, but the ambiguity of sometimes showing the source and sometimes the target is a little confusing. This patch makes scons typically list all sources and all targets for each action, with the common path prefix factored out for brevity. It's a little more verbose now but also more informative. Diffs - SConstruct 9f9e10967912 src/SConscript 9f9e10967912 src/arch/SConscript 9f9e10967912 src/arch/isa_parser.py 9f9e10967912 Diff: http://reviews.m5sim.org/r/366/diff Testing --- quick regressions pass Screenshots --- sample colorized output http://reviews.m5sim.org/r/366/s/1/ Thanks, Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: scons: show sources and targets when building.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/366/#review632 --- Ship it! We've beaten this to death, so I don't care about any of my comments enough to hold you up if you don't want to deal with them at all. SConstruct http://reviews.m5sim.org/r/366/#comment847 Can you derive from object? I really hate classic classes as they make various things annoying and the cause is not always obvious. SConstruct http://reviews.m5sim.org/r/366/#comment851 I hate lines like this. I'll register my annoyance, but won't continue further discussion. SConstruct http://reviews.m5sim.org/r/366/#comment848 This is probably pedantic, but these could be @classmethod (and self should be cls) SConstruct http://reviews.m5sim.org/r/366/#comment849 99 seems like a lot and goes against the idea of being concise. I don't care much though. Would anyone object to [%-8s] instead? the right justified seems odd. SConstruct http://reviews.m5sim.org/r/366/#comment850 out of curiosity, can you do the following instead? main['CCCOMSTR'] = TRANSFORM(CC) Certainly, I am pretty sure that the parameter to MakeAction/Action could be the callable and not the string. (String substitution just slows down SCons) - Nathan On 2011-01-06 11:15:30, Steve Reinhardt wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/366/ --- (Updated 2011-01-06 11:15:30) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- scons: show sources and targets when building. I like the brevity of Ali's recent change, but the ambiguity of sometimes showing the source and sometimes the target is a little confusing. This patch makes scons typically list all sources and all targets for each action, with the common path prefix factored out for brevity. It's a little more verbose now but also more informative. Diffs - SConstruct 9f9e10967912 src/SConscript 9f9e10967912 src/arch/SConscript 9f9e10967912 src/arch/isa_parser.py 9f9e10967912 Diff: http://reviews.m5sim.org/r/366/diff Testing --- quick regressions pass Screenshots --- sample colorized output http://reviews.m5sim.org/r/366/s/1/ Thanks, Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: scons: show sources and targets when building.
On 2011-01-06 11:42:18, Nathan Binkert wrote: SConstruct, line 379 http://reviews.m5sim.org/r/366/diff/3/?file=8481#file8481line379 Can you derive from object? I really hate classic classes as they make various things annoying and the cause is not always obvious. No problem, it was just an oversight. On 2011-01-06 11:42:18, Nathan Binkert wrote: SConstruct, line 418 http://reviews.m5sim.org/r/366/diff/3/?file=8481#file8481line418 99 seems like a lot and goes against the idea of being concise. I don't care much though. Would anyone object to [%-8s] instead? the right justified seems odd. The 99 is just a practical approximation of infinity, not meant to be hit in practice... the main idea is to give a parameter you can explicitly set if you don't want all (or any) of the sources listed, so I can cleanly replace the TRANSFORM_NOSRC and TRANSFORM_1SRC things I had in the earlier version. On 2011-01-06 11:42:18, Nathan Binkert wrote: SConstruct, line 481 http://reviews.m5sim.org/r/366/diff/3/?file=8481#file8481line481 out of curiosity, can you do the following instead? main['CCCOMSTR'] = TRANSFORM(CC) Certainly, I am pretty sure that the parameter to MakeAction/Action could be the callable and not the string. (String substitution just slows down SCons) TRANSFORM(CC) doesn't work, but Transform(CC) does. I had tried this before and it didn't work so I gave up on it, but I must have had some other error at the time. On 2011-01-06 11:42:18, Nathan Binkert wrote: SConstruct, line 406 http://reviews.m5sim.org/r/366/diff/3/?file=8481#file8481line406 This is probably pedantic, but these could be @classmethod (and self should be cls) Yea, I knew that, but I didn't see any point to it, so I figured why bother with the extra verbiage. If there's an advantage to it I'd be glad to do it though. The one thing I would like would be to define color() in a way where I could use it immediately, so I could do 'Arrow = color(arrow_color, - )' instead of the current expression, but I couldn't find a reasonable way to get that to work. On 2011-01-06 11:42:18, Nathan Binkert wrote: SConstruct, line 383 http://reviews.m5sim.org/r/366/diff/3/?file=8481#file8481line383 I hate lines like this. I'll register my annoyance, but won't continue further discussion. This is one of the few places I feel like lines like this are useful... this whole colorization thing already chews up way too many lines for the value it brings IMO :-). I'm also tempted to do this: def color_pfx(self, s): return self.color(self.pfx_color, s) def color_srcs(self, s): return self.color(self.srcs_color, s) def color_tgts(self, s): return self.color(self.tgts_color, s) just because I hate repetitive stuff chewing up vertical screen space. - Steve --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/366/#review632 --- On 2011-01-06 11:15:30, Steve Reinhardt wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/366/ --- (Updated 2011-01-06 11:15:30) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- scons: show sources and targets when building. I like the brevity of Ali's recent change, but the ambiguity of sometimes showing the source and sometimes the target is a little confusing. This patch makes scons typically list all sources and all targets for each action, with the common path prefix factored out for brevity. It's a little more verbose now but also more informative. Diffs - SConstruct 9f9e10967912 src/SConscript 9f9e10967912 src/arch/SConscript 9f9e10967912 src/arch/isa_parser.py 9f9e10967912 Diff: http://reviews.m5sim.org/r/366/diff Testing --- quick regressions pass Screenshots --- sample colorized output http://reviews.m5sim.org/r/366/s/1/ Thanks, Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: garnet: added orion2.0 for network power calculation
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/379/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- garnet: added orion2.0 for network power calculation Diffs - src/mem/ruby/network/garnet/fixed-pipeline/InputUnit_d.hh 9f9e10967912 src/mem/ruby/network/garnet/fixed-pipeline/InputUnit_d.cc 9f9e10967912 src/mem/ruby/network/garnet/fixed-pipeline/NetworkLink_d.hh 9f9e10967912 src/mem/ruby/network/garnet/fixed-pipeline/Router_d.hh 9f9e10967912 src/mem/ruby/network/garnet/fixed-pipeline/Router_d.cc 9f9e10967912 src/mem/ruby/network/garnet/fixed-pipeline/VCallocator_d.hh 9f9e10967912 src/mem/ruby/network/garnet/fixed-pipeline/VCallocator_d.cc 9f9e10967912 src/mem/ruby/network/orion/Allocator/Arbiter.hh PRE-CREATION src/mem/ruby/network/orion/Allocator/Arbiter.cc PRE-CREATION src/mem/ruby/network/orion/Allocator/MatrixArbiter.hh PRE-CREATION src/mem/ruby/network/orion/Allocator/MatrixArbiter.cc PRE-CREATION src/mem/ruby/network/orion/Allocator/RRArbiter.hh PRE-CREATION src/mem/ruby/network/orion/Allocator/RRArbiter.cc PRE-CREATION src/mem/ruby/network/orion/Allocator/SConscript PRE-CREATION src/mem/ruby/network/orion/Allocator/SWAllocator.hh PRE-CREATION src/mem/ruby/network/orion/Allocator/SWAllocator.cc PRE-CREATION src/mem/ruby/network/orion/Allocator/VCAllocator.hh PRE-CREATION src/mem/ruby/network/orion/Allocator/VCAllocator.cc PRE-CREATION src/mem/ruby/network/orion/Buffer/AmpUnit.hh PRE-CREATION src/mem/ruby/network/orion/Buffer/AmpUnit.cc PRE-CREATION src/mem/ruby/network/orion/Buffer/BitlineUnit.hh PRE-CREATION src/mem/ruby/network/orion/Buffer/BitlineUnit.cc PRE-CREATION src/mem/ruby/network/orion/Buffer/Buffer.hh PRE-CREATION src/mem/ruby/network/orion/Buffer/Buffer.cc PRE-CREATION src/mem/ruby/network/orion/Buffer/DecoderUnit.hh PRE-CREATION src/mem/ruby/network/orion/Buffer/DecoderUnit.cc PRE-CREATION src/mem/ruby/network/orion/Buffer/MemUnit.hh PRE-CREATION src/mem/ruby/network/orion/Buffer/MemUnit.cc PRE-CREATION src/mem/ruby/network/orion/Buffer/OutdrvUnit.hh PRE-CREATION src/mem/ruby/network/orion/Buffer/OutdrvUnit.cc PRE-CREATION src/mem/ruby/network/orion/Buffer/PrechargeUnit.hh PRE-CREATION src/mem/ruby/network/orion/Buffer/PrechargeUnit.cc PRE-CREATION src/mem/ruby/network/orion/Buffer/Register.hh PRE-CREATION src/mem/ruby/network/orion/Buffer/Register.cc PRE-CREATION src/mem/ruby/network/orion/Buffer/SConscript PRE-CREATION src/mem/ruby/network/orion/Buffer/SRAM.hh PRE-CREATION src/mem/ruby/network/orion/Buffer/SRAM.cc PRE-CREATION src/mem/ruby/network/orion/Buffer/WordlineUnit.hh PRE-CREATION src/mem/ruby/network/orion/Buffer/WordlineUnit.cc PRE-CREATION src/mem/ruby/network/orion/Clock.hh PRE-CREATION src/mem/ruby/network/orion/Clock.cc PRE-CREATION src/mem/ruby/network/orion/ConfigFile.hh PRE-CREATION src/mem/ruby/network/orion/ConfigFile.cc PRE-CREATION src/mem/ruby/network/orion/Crossbar/Crossbar.hh PRE-CREATION src/mem/ruby/network/orion/Crossbar/Crossbar.cc PRE-CREATION src/mem/ruby/network/orion/Crossbar/MatrixCrossbar.hh PRE-CREATION src/mem/ruby/network/orion/Crossbar/MatrixCrossbar.cc PRE-CREATION src/mem/ruby/network/orion/Crossbar/MultreeCrossbar.hh PRE-CREATION src/mem/ruby/network/orion/Crossbar/MultreeCrossbar.cc PRE-CREATION src/mem/ruby/network/orion/Crossbar/SConscript PRE-CREATION src/mem/ruby/network/orion/FlipFlop.hh PRE-CREATION src/mem/ruby/network/orion/FlipFlop.cc PRE-CREATION src/mem/ruby/network/orion/NetworkPower.hh 9f9e10967912 src/mem/ruby/network/orion/NetworkPower.cc 9f9e10967912 src/mem/ruby/network/orion/OrionConfig.hh PRE-CREATION src/mem/ruby/network/orion/OrionConfig.cc PRE-CREATION src/mem/ruby/network/orion/OrionLink.hh PRE-CREATION src/mem/ruby/network/orion/OrionLink.cc PRE-CREATION src/mem/ruby/network/orion/OrionRouter.hh PRE-CREATION src/mem/ruby/network/orion/OrionRouter.cc PRE-CREATION src/mem/ruby/network/orion/SConscript 9f9e10967912 src/mem/ruby/network/orion/SIM_port.hh 9f9e10967912 src/mem/ruby/network/orion/SIM_power.hh 9f9e10967912 src/mem/ruby/network/orion/SIM_power_test.hh 9f9e10967912 src/mem/ruby/network/orion/TechParameter.hh PRE-CREATION src/mem/ruby/network/orion/TechParameter.cc PRE-CREATION src/mem/ruby/network/orion/Type.hh PRE-CREATION src/mem/ruby/network/orion/Wire.hh PRE-CREATION src/mem/ruby/network/orion/Wire.cc PRE-CREATION src/mem/ruby/network/orion/orion.hh PRE-CREATION src/mem/ruby/network/orion/parm_technology.hh 9f9e10967912 src/mem/ruby/network/orion/power_arbiter.hh 9f9e10967912 src/mem/ruby/network/orion/power_arbiter.cc 9f9e10967912
[m5-dev] Review Request: mcpat: Adds McPAT performance counters
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/380/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- mcpat: Adds McPAT performance counters Updated patches from Rick Strong's set that modify performance counters for McPAT Diffs - src/cpu/BaseCPU.py 9f9e10967912 src/cpu/base.hh 9f9e10967912 src/cpu/base.cc 9f9e10967912 src/cpu/o3/commit.hh 9f9e10967912 src/cpu/o3/commit_impl.hh 9f9e10967912 src/cpu/o3/cpu.hh 9f9e10967912 src/cpu/o3/cpu.cc 9f9e10967912 src/cpu/o3/iew_impl.hh 9f9e10967912 src/cpu/o3/inst_queue.hh 9f9e10967912 src/cpu/o3/inst_queue_impl.hh 9f9e10967912 src/cpu/o3/rename.hh 9f9e10967912 src/cpu/o3/rename_impl.hh 9f9e10967912 src/cpu/o3/rob.hh 9f9e10967912 src/cpu/o3/rob_impl.hh 9f9e10967912 src/cpu/simple/atomic.cc 9f9e10967912 src/cpu/simple/base.hh 9f9e10967912 src/cpu/simple/base.cc 9f9e10967912 src/cpu/simple/timing.cc 9f9e10967912 Diff: http://reviews.m5sim.org/r/380/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: trigge queue fix.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/381/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- MOESI_hammer: trigge queue fix. Diffs - src/mem/protocol/MOESI_hammer-cache.sm 9f9e10967912 Diff: http://reviews.m5sim.org/r/381/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: MessagePort: implemented virtual recvTiming avoiding double delete
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/382/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- MessagePort: implemented virtual recvTiming avoiding double delete Double packet delete problem is due to an interrupt device deleting a packet that the SimpleTimingPort also deletes. Since MessagePort descends from SimpleTimingPort, simply reimplement the failing code from SimpleTimingPort: recvTiming. Diffs - src/arch/x86/interrupts.cc 9f9e10967912 src/dev/x86/intdev.hh 9f9e10967912 src/mem/mport.hh 9f9e10967912 src/mem/mport.cc 9f9e10967912 src/mem/tport.hh 9f9e10967912 Diff: http://reviews.m5sim.org/r/382/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: IntDev: packet latency fix
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/383/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- IntDev: packet latency fix The IntDev should be responsible for setting the latency of packets sent through it's port. This patch fixes the packet scheduling failure when the IntPort latency is 0 in timing mode. Diffs - src/arch/x86/interrupts.cc 9f9e10967912 src/dev/x86/i82094aa.cc 9f9e10967912 src/dev/x86/intdev.hh 9f9e10967912 src/dev/x86/intdev.cc 9f9e10967912 Diff: http://reviews.m5sim.org/r/383/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: IntDev: latency fix
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/384/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- IntDev: latency fix Since the device should be responsible for latency of packets, remove the latency field of the IntPort completely. Diffs - src/dev/x86/intdev.hh 9f9e10967912 Diff: http://reviews.m5sim.org/r/384/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: x86: Add checkpointing capability to arch components
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/386/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- x86: Add checkpointing capability to arch components Add checkpointing capability to the x86 interrupt device and the TLBs Diffs - src/arch/x86/interrupts.hh 9f9e10967912 src/arch/x86/interrupts.cc 9f9e10967912 src/arch/x86/pagetable.cc 9f9e10967912 Diff: http://reviews.m5sim.org/r/386/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: x86: Add checkpointing capability to devices
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/387/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- x86: Add checkpointing capability to devices Add checkpointing capability to the Intel 8254 timer, CMOS, I8042, PS2 Keyboard and Mouse, I82094AA, I8237, I8254, I8259, and speaker devices Diffs - src/dev/intel_8254_timer.cc 9f9e10967912 src/dev/x86/cmos.hh 9f9e10967912 src/dev/x86/cmos.cc 9f9e10967912 src/dev/x86/i8042.hh 9f9e10967912 src/dev/x86/i8042.cc 9f9e10967912 src/dev/x86/i82094aa.hh 9f9e10967912 src/dev/x86/i82094aa.cc 9f9e10967912 src/dev/x86/i8237.hh 9f9e10967912 src/dev/x86/i8237.cc 9f9e10967912 src/dev/x86/i8254.hh 9f9e10967912 src/dev/x86/i8254.cc 9f9e10967912 src/dev/x86/i8259.hh 9f9e10967912 src/dev/x86/i8259.cc 9f9e10967912 src/dev/x86/speaker.hh 9f9e10967912 src/dev/x86/speaker.cc 9f9e10967912 Diff: http://reviews.m5sim.org/r/387/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: Added full-bit directory support
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/388/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- MOESI_hammer: Added full-bit directory support Diffs - configs/ruby/MOESI_hammer.py 9f9e10967912 src/mem/protocol/MOESI_hammer-cache.sm 9f9e10967912 src/mem/protocol/MOESI_hammer-dir.sm 9f9e10967912 src/mem/protocol/MOESI_hammer-msg.sm 9f9e10967912 src/mem/protocol/RubySlicc_Exports.sm 9f9e10967912 src/mem/ruby/network/Network.cc 9f9e10967912 Diff: http://reviews.m5sim.org/r/388/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: ruby: x86 fs config support
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/412/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- ruby: x86 fs config support Diffs - configs/common/FSConfig.py 9f9e10967912 configs/example/ruby_fs.py 9f9e10967912 Diff: http://reviews.m5sim.org/r/412/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: ruby: Assert for x86 misaligned access
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/390/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- 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. Diffs - src/mem/ruby/system/RubyPort.cc 9f9e10967912 Diff: http://reviews.m5sim.org/r/390/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: Ruby: Update the Ruby request type names for LL/SC
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/391/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: Update the Ruby request type names for LL/SC Diffs - src/mem/ruby/libruby.hh 9f9e10967912 src/mem/ruby/libruby.cc 9f9e10967912 src/mem/ruby/recorder/TraceRecord.cc 9f9e10967912 src/mem/ruby/system/DMASequencer.cc 9f9e10967912 src/mem/ruby/system/RubyPort.cc 9f9e10967912 src/mem/ruby/system/Sequencer.cc 9f9e10967912 Diff: http://reviews.m5sim.org/r/391/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: Ruby: Fix to return cache block size to CPU for split data transfers
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/393/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: Fix to return cache block size to CPU for split data transfers Diffs - src/mem/ruby/system/RubyPort.hh 9f9e10967912 src/mem/ruby/system/RubyPort.cc 9f9e10967912 Diff: http://reviews.m5sim.org/r/393/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: ruby: Fix RubyPort to properly handle retrys
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/394/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- ruby: Fix RubyPort to properly handle retrys Diffs - src/mem/ruby/system/RubyPort.hh 9f9e10967912 src/mem/ruby/system/RubyPort.cc 9f9e10967912 src/mem/ruby/system/Sequencer.hh 9f9e10967912 src/mem/ruby/system/Sequencer.cc 9f9e10967912 src/mem/ruby/system/Sequencer.py 9f9e10967912 Diff: http://reviews.m5sim.org/r/394/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: TimingSimpleCPU: split data sender state fix
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/395/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- TimingSimpleCPU: split data sender state fix In sendSplitData, keep a pointer to the senderState that may be updated after the call to handle*Packet. This way, if the receiver updates the packet senderState, it can still be accessed in sendSplitData. Diffs - src/cpu/simple/timing.cc 9f9e10967912 Diff: http://reviews.m5sim.org/r/395/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: x86: Timing support for pagetable walker
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/396/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- x86: Timing support for pagetable walker Move page table walker state to its own object type, and make the walker instantiate state for each outstanding walk. By storing the states in a queue, the walker is able to handle multiple outstanding timing requests. Note that functional walks use separate state elements. Diffs - src/arch/x86/pagetable_walker.hh 9f9e10967912 src/arch/x86/pagetable_walker.cc 9f9e10967912 src/arch/x86/tlb.hh 9f9e10967912 src/arch/x86/tlb.cc 9f9e10967912 Diff: http://reviews.m5sim.org/r/396/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: dev: fixed bugs to extend interrupt capability beyond 15 cores
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/397/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- dev: fixed bugs to extend interrupt capability beyond 15 cores Diffs - src/arch/x86/interrupts.cc 9f9e10967912 src/dev/x86/i82094aa.hh 9f9e10967912 src/dev/x86/i82094aa.cc 9f9e10967912 src/dev/x86/intdev.hh 9f9e10967912 src/dev/x86/intdev.cc 9f9e10967912 Diff: http://reviews.m5sim.org/r/397/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: m5: added work completed monitoring support
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/398/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- m5: added work completed monitoring support Diffs - configs/common/FSConfig.py 9f9e10967912 configs/common/Options.py 9f9e10967912 configs/example/fs.py 9f9e10967912 configs/example/ruby_fs.py 9f9e10967912 src/arch/x86/isa/decoder/two_byte_opcodes.isa 9f9e10967912 src/cpu/base.hh 9f9e10967912 src/cpu/base.cc 9f9e10967912 src/sim/SConscript 9f9e10967912 src/sim/System.py 9f9e10967912 src/sim/pseudo_inst.hh 9f9e10967912 src/sim/pseudo_inst.cc 9f9e10967912 src/sim/system.hh 9f9e10967912 src/sim/system.cc 9f9e10967912 util/m5/m5op_x86.S 9f9e10967912 util/m5/m5ops.h 9f9e10967912 Diff: http://reviews.m5sim.org/r/398/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: packet: Added public method to identify valid data
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/399/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- packet: Added public method to identify valid data Diffs - src/mem/packet.hh 9f9e10967912 Diff: http://reviews.m5sim.org/r/399/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: ruby: Added support for Null data packet
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/400/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- ruby: Added support for Null data packet Diffs - src/mem/ruby/system/RubyPort.cc 9f9e10967912 Diff: http://reviews.m5sim.org/r/400/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: ruby: Added Null data support to the DMASequencer
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/401/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- ruby: Added Null data support to the DMASequencer Diffs - src/mem/ruby/system/DMASequencer.cc 9f9e10967912 Diff: http://reviews.m5sim.org/r/401/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: MOESI_CMP_token: removed unused message fields
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/402/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- MOESI_CMP_token: removed unused message fields Diffs - src/mem/protocol/MOESI_CMP_token-msg.sm 9f9e10967912 Diff: http://reviews.m5sim.org/r/402/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: ruby: numa bit fix for sparse memory
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/403/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- ruby: numa bit fix for sparse memory Diffs - configs/ruby/MOESI_hammer.py 9f9e10967912 configs/ruby/Ruby.py 9f9e10967912 src/mem/ruby/system/DirectoryMemory.cc 9f9e10967912 src/mem/ruby/system/DirectoryMemory.py 9f9e10967912 src/mem/ruby/system/SparseMemory.hh 9f9e10967912 src/mem/ruby/system/SparseMemory.cc 9f9e10967912 Diff: http://reviews.m5sim.org/r/403/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: fixed dir bug counting received acks
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/404/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- MOESI_hammer: fixed dir bug counting received acks Diffs - src/mem/protocol/MOESI_hammer-dir.sm 9f9e10967912 Diff: http://reviews.m5sim.org/r/404/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: garnet: Split network power in ruby.stats
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/413/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- garnet: Split network power in ruby.stats Split out dynamic and static power numbers for printing to ruby.stats Diffs - src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 9f9e10967912 src/mem/ruby/network/garnet/fixed-pipeline/NetworkLink_d.hh 9f9e10967912 src/mem/ruby/network/garnet/fixed-pipeline/Router_d.hh 9f9e10967912 src/mem/ruby/network/orion/NetworkPower.cc 9f9e10967912 Diff: http://reviews.m5sim.org/r/413/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: boot: script that creates a checkpoint after Linux boot up
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/406/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- boot: script that creates a checkpoint after Linux boot up Diffs - configs/boot/hack_back_ckpt.rcS PRE-CREATION Diff: http://reviews.m5sim.org/r/406/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: ruby: minor fix to deadlock panic message
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/407/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- ruby: minor fix to deadlock panic message Diffs - src/mem/ruby/system/Sequencer.cc 9f9e10967912 Diff: http://reviews.m5sim.org/r/407/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: ruby: support to stallAndWait the mandatory queue
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/408/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- ruby: support to stallAndWait the mandatory queue By stalling and waiting the mandatory queue instead of recycling it, one can ensure that no incoming messages are starved when the mandatory queue puts signficant of pressure on the L1 cache controller (i.e. the ruby memtester). Diffs - src/mem/protocol/MOESI_CMP_token-L1cache.sm 9f9e10967912 src/mem/protocol/MOESI_hammer-cache.sm 9f9e10967912 src/mem/ruby/buffers/MessageBuffer.hh 9f9e10967912 src/mem/ruby/buffers/MessageBuffer.cc 9f9e10967912 src/mem/slicc/ast/WakeUpAllDependentsStatementAST.py PRE-CREATION src/mem/slicc/ast/__init__.py 9f9e10967912 src/mem/slicc/parser.py 9f9e10967912 src/mem/slicc/symbols/StateMachine.py 9f9e10967912 Diff: http://reviews.m5sim.org/r/408/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: stats: Add a histogram statistic type
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/357/#review635 --- Ship it! Didn't check your logic/math or anything, but looks good...so, this is just like Dist but the buckets change dynamically? Awesome. - Lisa On 2010-12-21 11:15:24, Nathan Binkert wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/357/ --- (Updated 2010-12-21 11:15:24) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- stats: Add a histogram statistic type Diffs - src/base/statistics.hh 4a3bddd74f36 src/base/statistics.cc 4a3bddd74f36 src/base/stats/info.hh 4a3bddd74f36 src/base/stats/text.cc 4a3bddd74f36 src/unittest/stattest.cc 4a3bddd74f36 Diff: http://reviews.m5sim.org/r/357/diff Testing --- Thanks, Nathan ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: scons: show sources and targets when building.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/366/#review636 --- How about leaving the tool name grey? Ali - Ali On 2011-01-06 11:15:30, Steve Reinhardt wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/366/ --- (Updated 2011-01-06 11:15:30) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- scons: show sources and targets when building. I like the brevity of Ali's recent change, but the ambiguity of sometimes showing the source and sometimes the target is a little confusing. This patch makes scons typically list all sources and all targets for each action, with the common path prefix factored out for brevity. It's a little more verbose now but also more informative. Diffs - SConstruct 9f9e10967912 src/SConscript 9f9e10967912 src/arch/SConscript 9f9e10967912 src/arch/isa_parser.py 9f9e10967912 Diff: http://reviews.m5sim.org/r/366/diff Testing --- quick regressions pass Screenshots --- sample colorized output http://reviews.m5sim.org/r/366/s/1/ Thanks, Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: scons: show sources and targets when building.
Hehe. http://www.imdb.com/title/tt0584442/quotes?qt0399229 Ali Saidi wrote: This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/366/ How about leaving the tool name grey? Ali - Ali On January 6th, 2011, 11:15 a.m., Steve Reinhardt wrote: Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. By Steve Reinhardt. /Updated 2011-01-06 11:15:30/ Description scons: show sources and targets when building. I like the brevity of Ali's recent change, but the ambiguity of sometimes showing the source and sometimes the target is a little confusing. This patch makes scons typically list all sources and all targets for each action, with the common path prefix factored out for brevity. It's a little more verbose now but also more informative. Testing quick regressions pass Diffs * SConstruct (9f9e10967912) * src/SConscript (9f9e10967912) * src/arch/SConscript (9f9e10967912) * src/arch/isa_parser.py (9f9e10967912) View Diff http://reviews.m5sim.org/r/366/diff/ Screenshots sample colorized output http://reviews.m5sim.org/r/366/s/1/ ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
