Re: [Gems-users] invalidating a cache block

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

  I'm really sorry, but I can't find the place in the protocol where
the in_port triggers replacement for a load, store or Ifetch. There are
definitions of "Events" in the protocol for LD, ST, IFETCH and
L1_Replacement, but I guess that is not the place to add a invalidate
definition.

The only place that sounds similar to what you are describing is the
code starting at line 402 in the protocol file:

         // *** DATA ACCESS ***

         // Check to see if it is in the OTHER L1
         if (L1IcacheMemory.isTagPresent(in_msg.Address)) {
           // The block is in the wrong L1, put the request on the
queue to the shared L2
           trigger(Event:L1_Replacement, in_msg.Address);
         }
         if (L1DcacheMemory.isTagPresent(in_msg.Address)) {
           // The tag matches for the L1, so the L1 ask the L2 for it
           trigger(mandatory_request_type_to_event(in_msg.Type),
in_msg.Address);
         } else {
           if (L1DcacheMemory.cacheAvail(in_msg.Address)) {
             // L1 does't have the line, but we have space for it in
the L1 let's see if the L2 has it
             trigger(mandatory_request_type_to_event(in_msg.Type),
in_msg.Address);
           } else {
             // No room in the L1, so we need to make room in the L1
             trigger(Event:L1_Replacement,
L1DcacheMemory.cacheProbe(in_msg.Address));



This code triggers replacement but I don't see that it is caused by
load, store, or Ifetch. Is this the code you are talking about?

Yes, this is the code I'm talking about.  Since the line you are invalidating is already present, your addition to mandatory_request_type_to_event will work fine.  My apologies.

 

Regarding the label INVALIDATE - although it is called like that I want
to actually cause a writeback in cases where I discover modified or
owned cache blocks when traversing the cache inside the sequencer. In
all other cases I want to simply make an invalidation, which now I'm
unsure whether I have to do through the protocol or if I can do by
simply modifying the state variable without sending a message to the
controller.

What I had in mind is that the Sequencer would walk the cache by directly accessing the CacheMemory objects.  It would then issue  an INVALIDATE for each block address that is valid.

Even though i have created an event called INVALIDATE, my main goal was
to cause a writeback of dirty data by triggering the replacement event
in the protocol which I believe would give me the result I want (dirty
data being pushed to L2 with possibly replacing the entry with some
dummy data). So the label is wrong, but is the approach also wrong? Do I
need to create a new separate code for this? My hope was to avoid that.

I think the approach is sound and that Invalidate is not such a bad label.
 

Another thing, since the files in the generated directory are off-limits
due to re-generation upon compilation, I guess the modification to
CacheRequestType is also invalid, right? So, any changes I make should
only be done to the sequencer and the protocol file is my conclusion.

You can add to CacheRequestType in RubySlicc_Exports.sm in the protocols/ directory.

--Mike