Re: [Gems-users] Invalidate directory entry

[Mike Marty <mikem@xxxxxxxxxxx>]

Here are the relationships between the L1/L2 ports for
MSI_MOSI_CMP_directory

L1Cache                         L2Cache
--------                        -------------
out: requestFromL1Cache (0)     in: L1RequestToL2Cache (0)
out: responseFromL1Cache (3)    in: responseToL2Cache (3)
in:  requestToL1Cache (2)       out: L1RequestFromL2Cache (2)
in:  responseToL1Cache (3)      out: responseFromL2Cache (3)

Does this help?

--Mike


> So let's take protocol as an example, in the L2Cache.sm file:
>
> // L2 BANK QUEUES
> // From local bank of L2 cache TO the network
> MessageBuffer dummyFrom0, network="To", virtual_network="0", ordered="false";  // dummy buffer that shouldn't be used
> MessageBuffer DirRequestFromL2Cache, network="To", virtual_network="1", ordered="false";  // this L2 bank -> mod-directory
>
> >>>>>>>>>  MessageBuffer L1RequestFromL2Cache, network="To", virtual_network="2", ordered="true";  // this L2 bank -> a local L1
>
> MessageBuffer responseFromL2Cache, network="To", virtual_network="3", ordered="false";  // this L2 bank -> a local L1 || mod-directory
> MessageBuffer finalAckFromL2Cache, network="To", virtual_network="4", ordered="false";  // this L2 bank -> mod-directory
>
> // FROM the network to this local bank of L2 cache
> //MessageBuffer L1RequestToL2Cache, network="From", virtual_network="1", ordered="true";  // a local L1 -> this L2 bank
> MessageBuffer L1RequestToL2Cache, network="From", virtual_network="0", ordered="true";  // a local L1 -> this L2 bank
> MessageBuffer dummyTo1, network="From", virtual_network="1", ordered="false";  // dummy buffer that shouldn't be used
>
> >>>>>>>>> MessageBuffer forwardedRequestToL2Cache, network="From", virtual_network="2", ordered="true";  // mod-directory -> this L2bank
>
> MessageBuffer responseToL2Cache, network="From", virtual_network="3", ordered="false";  // a local L1 || mod-directory -> this L2 bank
> MessageBuffer dummyTo4, network="From", virtual_network="4", ordered="false";  // dummy buffer that shouldn't be used
>
> While in the L1Cache.sm file:
>
> // From this node's L1 cache TO the network
> // a local L1 -> this L2 bank, currently ordered with directory forwarded requests
> MessageBuffer requestFromL1Cache, network="To", virtual_network="0", ordered="true";
> MessageBuffer dummyFrom1, network="To", virtual_network="1", ordered="false";  // dummy buffer that shouldn't be used
> MessageBuffer dummyFrom2, network="To", virtual_network="2", ordered="false";  // dummy buffer that shouldn't be used
> MessageBuffer responseFromL1Cache, network="To", virtual_network="3", ordered="false";
> MessageBuffer dummyFrom4, network="To", virtual_network="4", ordered="false";  // dummy buffer that shouldn't be used
>
> // To this node's L1 cache FROM the network
> MessageBuffer dummyTo0, network="From", virtual_network="0", ordered="false";  // dummy buffer that shouldn't be used
> MessageBuffer dummyTo1, network="From", virtual_network="1", ordered="false";  // dummy buffer that shouldn't be used
>
> >>>>>>>>>>>  MessageBuffer requestToL1Cache, network="From", virtual_network="2", ordered="true";
>
> MessageBuffer responseToL1Cache, network="From", virtual_network="3", ordered="false";
> MessageBuffer dummyTo4, network="From", virtual_network="4", ordered="false";  // dummy buffer that shouldn't be used
>
>
> So these three buffers should be connected together: L1RequestFromL2Cache, forwardedRequestToL2Cache, requestToL1Cache
> because they have the same virtual network number, right? But this doesn't make sense to me, why should L1RequestFromL2Cache
> be connected to forwardedRequestToL2Cache?
>
> Your advice is very much appreciated!
>
> Thanks,
> Lei
>   ----- Original Message -----
>   From: hongxia sun
>   To: Lei Yang ; Gems Users
>   Sent: Thursday, January 11, 2007 8:45 PM
>   Subject: Re: [Gems-users] Invalidate directory entry
>
>
>   For the first question, you can modify the protocol as your design, both of the L2 cache and the directory.
>   For the second question, these buffer are not connected according to their name, but according to their "virtual_network" No. Buffers with the same No. are connected together.
>
>
>   2007/1/12, Lei Yang <lya755@xxxxxxxxxxxxxxxxxxxx>:
>     I see. So with this protocol (MSI_MOSI_CMP_directory), if Processor 0 is the
>     only sharer of one cache line, after it evicts this line, the directory
>     state is still S. I've verified this with a simple trace. It doesn't matter
>     with the current protocol because even if a line is shared by other L2
>     caches, as long as it is not in M state, it's always fetched from main
>     memory.  But for a protocol that supports clean cache-to-cache data
>     transfer, this may be a problem.
>
>     Another question is, when reading the protocol sm files, I couldn't find
>     where/how the buffers are connected. For example, there is a buffer for L2
>     cache called L1RequestToL2Cache (a local L1 -> this L2 bank), but for L1
>     cache, the buffer requestFromL1Cache is supposed to be Local L1 -> this L2
>     bank. So with different names, how are they actually connected? I mean,
>     after L1 sends a request to L2 using the requestFromL1Cache buffer, how does
>     L2 actually receive it?
>
>     Thanks list, you've been super helpful!
>
>     Lei
>
>     ----- Original Message -----
>     From: "Mike Marty" < mikem@xxxxxxxxxxx>
>     To: "Lei Yang" <lya755@xxxxxxxxxxxxxxxxxxxx>
>     Cc: "'Gems Users'" < gems-users@xxxxxxxxxxx>
>     Sent: Thursday, January 11, 2007 9:41 AM
>     Subject: Re: [Gems-users] Invalidate directory entry
>
>
>     >> That's for M state, right? For S state, would any action be taken? Thanks
>     >> a
>     >> lot for your time!
>     >>
>     >
>     > Yes, for S state the L2 silently replaces.
>     >
>     >
>
>
>     _______________________________________________
>     Gems-users mailing list
>     Gems-users@xxxxxxxxxxx
>     https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>     Use Google to search the GEMS Users mailing list by adding "site: https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
>
>
>
>