Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-13 Thread Nilay Vaish
> On 2011-01-13 08:33:49, Brad Beckmann wrote: > > I can't fully appreciate these latest changes without also seeing the > > updated .sm files, but overall this looks very inline with what we have > > been discussing over the past few days. I just have one basic question on > > why we need to

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-13 Thread Nilay Vaish
> On 2011-01-13 08:33:49, Brad Beckmann wrote: > > I can't fully appreciate these latest changes without also seeing the > > updated .sm files, but overall this looks very inline with what we have > > been discussing over the past few days. I just have one basic question on > > why we need to

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-13 Thread Brad Beckmann
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/358/#review727 --- I can't fully appreciate these latest changes without also seeing the upda

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-12 Thread Nilay Vaish
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/358/ --- (Updated 2011-01-12 22:45:22.150420) Review request for Default. Summary ---

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-12 Thread Nilay Vaish
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/358/ --- (Updated 2011-01-12 22:42:07.876214) Review request for Default. Summary ---

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-12 Thread Nilay Vaish
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/358/ --- (Updated 2011-01-12 22:37:49.117675) Review request for Default. Summary ---

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-12 Thread Lisa Hsu
How funny - yes, my usage of implicit and explicit are the same as Brad's...implicit meaning that in the actions, you can just say "address" and it always knows what you are talking about because it was sent via the trigger function. Glad things seem cleared up now! Keep up the great work Nilay.

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-12 Thread Beckmann, Brad
> > Are you sure you would call the above piece of code as __implicit__ setting > of cache and tbe entry variables? In this case, the local variable has been > __explicitly__ passed in the call to the trigger function. > > To me 'X is implicit' means that the programmer does not need to write 'X'

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-12 Thread Nilay Vaish
Hi Brad, As I understand from your mail below, you do would like to write ENTRY L1I_cache_entry = getL1ICacheEntry(in_msg.LineAddress); trigger(Event, address, L1I_cache_entry); instead of set_cache_entry(getL1ICacheEntry(in_msg.LineAddress)); trigger(Event, address); In other words, local v

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-12 Thread Nilay
On Tue, January 11, 2011 7:24 pm, Lisa Hsu wrote: > Hi Nilay, > > I've been talking with Brad here at work about some of these things so I > will finally jump into the conversation via email. First, great job on > this > - this has clearly been a substantial amount of work. I'm impressed. > > I'

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-11 Thread Lisa Hsu
Hi Nilay, I've been talking with Brad here at work about some of these things so I will finally jump into the conversation via email. First, great job on this - this has clearly been a substantial amount of work. I'm impressed. I've got some comments below. On Tue, Jan 11, 2011 at 3:46 PM, Nil

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-11 Thread Beckmann, Brad
Hi Nilay, Overall, I believe we are in more agreement with each other than maybe you think. I'm glad you included pseudo code in your latest email. That is a great idea. I think part of our problem is we are comprehending our textual descriptions in different ways. Below are my responses:

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-11 Thread Nilay Vaish
Brad, my comments are inline. On Tue, 11 Jan 2011, Beckmann, Brad wrote: Sure, using a local variable to further reduce the calls to getCacheEntry is a great idea. I think that is orthogonal to the suggestion I was making. I just want the ability to directly set the cache_entry and tbe_entry

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-11 Thread Beckmann, Brad
> > Sure, using a local variable to further reduce the calls to > > getCacheEntry is a great idea. I think that is orthogonal to the > > suggestion I was making. I just want the ability to directly set the > > cache_entry and tbe_entry variables in the trigger function. That way > > the address,

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-11 Thread Nilay Vaish
On Tue, 11 Jan 2011, Beckmann, Brad wrote: Hi Nilay, Sure, using a local variable to further reduce the calls to getCacheEntry is a great idea. I think that is orthogonal to the suggestion I was making. I just want the ability to directly set the cache_entry and tbe_entry variables in the

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-11 Thread Beckmann, Brad
Hi Nilay, Sure, using a local variable to further reduce the calls to getCacheEntry is a great idea. I think that is orthogonal to the suggestion I was making. I just want the ability to directly set the cache_entry and tbe_entry variables in the trigger function. That way the address, cache

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-07 Thread Nilay Vaish
Brad, my comments are inline. On Fri, 7 Jan 2011, Beckmann, Brad wrote: Hi Nilay, Unfortunately I can't provide you an example of a protocol where getCacheEntry behaves in a different manner, but they do exist. I reviewed your most recent patch updates and I don't think what we're askin

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-07 Thread Beckmann, Brad
Hi Nilay, Unfortunately I can't provide you an example of a protocol where getCacheEntry behaves in a different manner, but they do exist. I reviewed your most recent patch updates and I don't think what we're asking for is much different than what you have on reviewboard right now. Basical

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-06 Thread Nilay Vaish
--- 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 ---

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-06 Thread Nilay Vaish
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 c

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-05 Thread Beckmann, Brad
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

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-04 Thread Beckmann, Brad
Hi Nilay, At one point in time, the combination of several letters at the beginning of the action name corresponded to the short hand name for the action. The short hand name is the letter or letter combination that appears in the HTML tables. SLICC may have once enforced that the combination

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-04 Thread Nilay Vaish
Brad Is there a reason why each action name follows the pattern several letters>_? The letters used are not abbreviations of the action performed. Can we use any combination? Thanks Nilay On Tue, 4 Jan 2011, Beckmann, Brad wrote: Hi Nilay, My responses are below: The main thing I would l

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-04 Thread Beckmann, Brad
Hi Nilay, My responses are below: > The main thing I would like to see improved is not having to differentiate > between “entry” and “entry_ptr” in the .sm files. Am I correct > that the only functions in the .sm files that are passed an > “entry_ptr” are “is_valid_ptr”, “getCa

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-04 Thread Arkaprava Basu
Hi Nilay, On deadlock issue with MESI_CMP_directory : Yes, this can happen as ruby_tester or Sequencer only reports *possible* deadlocks. With higher number of processors there is more contention (and thus latency) and it can mistakenly report deadlock. I generally look at the protocol

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-04 Thread Nilay Vaish
> On 2011-01-03 15:31:20, Brad Beckmann wrote: > > Hi Nilay, First, I must say this is an impressive amount of work. You definitely got a lot done over holiday break. :) Overall, this set of patches is definitely close, but I want to see if we can take them a step forward. Also I have a few

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-03 Thread Brad Beckmann
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/358/#review596 --- Hi Nilay, First, I must say this is an impressive amount of work. You de

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-03 Thread Nilay Vaish
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/358/ --- (Updated 2011-01-03 14:18:13.801375) Review request for Default. Changes ---

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2011-01-03 Thread Steve Reinhardt
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/358/#review585 --- src/mem/ruby/slicc_interface/AbstractCacheEntry.hh

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2010-12-31 Thread Nilay Vaish
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/358/ --- (Updated 2010-12-31 17:50:59.779517) Review request for Default. Changes ---

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2010-12-24 Thread Nilay Vaish
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/358/ --- (Updated 2010-12-24 09:04:02.816498) Review request for Default. Changes ---

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2010-12-22 Thread Nilay Vaish
> On 2010-12-22 14:35:28, Brad Beckmann wrote: > > Hi Nilay, Could you please include the changes to the MOESI_CMP_directory protocol in this patch? It is difficult to understand the ramifications of these changes without seeing their impact to the .sm files. Also this is a very tricky patch

Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2010-12-22 Thread Brad Beckmann
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/358/#review570 --- Hi Nilay, Could you please include the changes to the MOESI_CMP_directory

[m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC

2010-12-22 Thread Nilay Vaish
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/358/ --- Review request for Default. Summary --- The purpose of this patch is to change