Re: [Gems-users] invalidating a cache block

["Mike Marty" <mike.marty@xxxxxxxxx>]

On Jan 10, 2008 2:06 AM, Mladen Nikitovic <mladen@xxxxxx> wrote:

Mike Marty wrote:
> On Jan 9, 2008 3:43 AM, Mladen Nikitovic <mladen@xxxxxx> wrote:
>
>
>> I have found a possible solution:
>>
>> I noticed that there is a section in the generated file
>> L1Cache_Transitions.C that handles L1Cache_Event_L1_Replacement and
>> L1Cache_Event_L1_Writeback events with the following actions:
>>
>> i_allocateTBE(addr);
>> d_issuePUTX(addr);
>> x_copyDataFromL1CacheToTBE(addr);
>> ff_deallocateL1CacheBlock(addr);
>> return TransitionResult_Valid;
>>
>> I have seen that these functions/methods (i_allocTBE etc) are
>> implemented in the L1Cache_Controller.C file, which means that I should
>> be able to call them via a L1cache_controller object, right?
>>
>>
>
> I don't recommend this approach.  The protocol needs to go through its
> state-machine actions for handling replacements.  The Ruby Sequencer
> currently issues either a "Load", "Store", or "Ifetch" request to L1
> controllers via the mandatory queue.  I think adding a fourth "Invalidate"
> request is a better approach. The in_port processing logic would then just
> trigger an L1_Replacement event and the protocol will take care of the
> rest.
>
>
>
>

 Ok, I just want to confirm that I have understood what needs to be
done here.

First, in order to send a request to the L1 controller via the mandatory
queue I can do something like this, right?

m_chip_ptr->m_L1Cache_mandatoryQueue_vec[m_version]->enqueue(msg, latency);

Yes, something like that.
 

Then, to support the Invalidate request I intend to add a
CacheRequestType_Invalidate definition to the file CacheRequestType.h
file, add a case for this in the string_to_CacheRequestType and
CacheRequestType_to_string functions in the CacheRequestType.C

Finally, when the definitions and string conversions are in place I can
add an if-case that catches the Invalidate message in file
MOESI_CMP_directory-L1Cache.sm protocol file

 Event mandatory_request_type_to_event(CacheRequestType type) {
   if (type == CacheRequestType:LD) {
     return Event:Load;
   } else if (type == CacheRequestType:IFETCH) {
     return Event:Ifetch;
   } else if ((type == CacheRequestType:ST) || (type ==
CacheRequestType:ATOMIC)) {
     return Event:Store;
   } else if(type == CacheRequestType:INVALIDATE) {
     return Event:L1_Replacement;
   } else {
     error("Invalid CacheRequestType");
   }
 }

Will this be enough to do the trick?

Close, but you might want to check the CacheRequestType in the in_port itself instead of using the above wrapper function.  The reason is that for an INVALIDATE request, you do *not* want to make room for the block by kicking something else out.  See how the in_port logic triggers a replacement for a victim on a Load, Store, or Ifetch

I have another question related to this. I found another file (in the
generated catalog) called L1Cache_mandatory_request_type_to_event.C that
looks like this:

#include "Types.h"
#include "Chip.h"
#include "L1Cache_Controller.h"

L1Cache_Event
L1Cache_Controller::L1Cache_mandatory_request_type_to_event(CacheRequestType
param_type)
{
 if ((param_type == CacheRequestType_LD)) {
   return L1Cache_Event_Load;
 } else {
   if ((param_type == CacheRequestType_IFETCH)) {
     return L1Cache_Event_Ifetch;
   } else {
     if (((param_type == CacheRequestType_ST) || (param_type ==
CacheRequestType_ATOMIC))) {
       return L1Cache_Event_Store;
     } else {
               cerr << "Runtime Error at
../protocols/MSI_MOSI_CMP_directory-L1cache.sm:252, Ruby Time: " <<
g_eventQueue_ptr->getTime() << ": " << ("Invalid CacheRequestType") <<
", PID: " << getpid() << endl;
char c; cerr << "press return to continue." << endl; cin.get(c); abort();

;
     }
   }
 }
}

It is very similar to the if-else switch statements in the protocol. I
could add another clause here also but then I noticed that there is
already a L1Cache_Event_INV event defined in L1Cache_Event.h. The
problem I find here is that I could choose to translate the
CacheRequestType_INVALIDATE into either  a L1Cache_Event_INV or
L1Cache_Event_L1_Replacement. Should I choose the latter to be
consistent with the changes in the protocol? What happens if I choose
the former option? do I need to make any changes at all to this file?

This is the corresponding generated C-file.  I do not recommend modifying the generated files because when SLICC regenerates the file, your modifications are gone

--Mike