Re: [Gems-users] invalidating a cache block

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

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. 

This is what I propose:

go through the L1 cache block-by-block {
 if I find a block that need to be written back I call the methods
(i_allocateTBE, d_issuePUTX, x_copyDataFromL1CacheToTBE, and
ff_deallocateL1CacheBlock) via the corresponding controller in the
L1Cache_Controller_vec vector.
}

If this is correct, I have a follow-up question since I'm not a
coherence protocol expert: My initial thought was to perform a writeback
only when I see a block that is in the M and O state, but I might have
missed any other vital states. Also, there are many intermediate states,
do I need to consider those possibilities also?

MOESI_CMP_directory does not do silent S replacements.  It sends a control message to keep directories up-to-date. 

--Mike