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. Basically, all we need to do is add
back in the capability for the programmer to write their own getCacheEntry
function in the .sm file. I know that I initially asked you to automatically
generate those functions, and I still think that is useful for most protocols,
but Lisa made me realize that we need customized getCacheEntry functions as
well. Also we may want to change the name of generated getCacheEntry function
to getExclusiveCacheEntry so that one realizes the exclusive assumption made by
the function.
Other than that, the only other change I suggest is to allow the trigger
function to directly set the implicit cache_entry and tbe_entry variables.
Below is example of what I'm envisioning:
Currently in MOESI_CMP_directory-L1cache.sm:
in_port(useTimerTable_in, Address, useTimerTable) {
if (useTimerTable_in.isReady()) {
set_cache_entry(getCacheEntry(useTimerTable.readyAddress()));
set_tbe(TBEs[useTimerTable.readyAddress()]);
trigger(Event:Use_Timeout, useTimerTable.readyAddress());
}
}
Replace that with the following:
in_port(useTimerTable_in, Address, useTimerTable) {
if (useTimerTable_in.isReady()) {
trigger(Event:Use_Timeout, useTimerTable.readyAddress(),
getExclusiveCacheEntry(useTimerTable.readyAddress()),
TBEs[useTimerTable.readyAddress()]);
}
}
Please let me know if you have any questions.
Thanks...you're almost done. :)
Brad
-----Original Message-----
From: Nilay Vaish [mailto:ni...@cs.wisc.edu]
Sent: Thursday, January 06, 2011 6:32 AM
To: Beckmann, Brad
Cc: Default
Subject: RE: 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
