Re: [Gems-users] SINGLE_ACCESS_L2_BANKS Usage

[Hemayet Hossain <hossain@xxxxxxxxxxxxxxxx>]

Thanks Mike.
I was considering the events in cache controller itself.
I am using MSI_MOSI_CMP_directory protocol.  From the protocol file one transition
  transition(L2_SS, {L1_GETS, L1_GET_INSTR}) {
    set_setMRU;
    ww_profileMissNoDir;
    nn_addSharer;
    k_dataFromL2CacheToL1Requestor;
    jj_popL1RequestQueue;
  }
That means, the cache line is not moving to transient state and the data from L2 is enqueued at output port of L2 controller after L2_RESPONSE_LATENCY cycles, right? And it also seems it will allow to serve another GETS coming in the next cycle and the data for that will be in output port of cache controller at L2_RESPONSE_LATENCY+1 cycle from current cycle. Am I right?

And if that is the case then it seems the cache is assumed pipelined, right?

Thanks,
Hemayet

Mike Marty wrote:

I was wondering whether  "SINGLE_ACCESS_L2_BANKS" ruby parameter defined
in rubyconfig.defaults is used or not. I was looking for any usage of
that but I did not find any (I am using Gems 1.3). If it is used, can
anyone plz tell where is it?

    

If you can't find it anywhere else, the parameter is probably unused.

  

I have another question about L2 access interleaving. Lets assume
L2_RESPONSE_LATENCY is set to 8 cycles. For a GETS request (hit) at
cycle t, L2 will send the data to output after 8 cycles at t+8. Within
this 8 cycles (after the transition) can any other request (say another
GETS at t+1 cycle) be processed? When the data for next GETS will be in
output port?

    

Depends on the protocol.  First, L2_RESPONSE_LATENCY is only used by a few 
protocols (the ones with CMP in the names).  Second, L2_RESPONSE_LATENCY 
only models the fixed access latency.  There is additional latency 
incurred in the interconnect to get the data back to the L1 controller 
(assuming a protocol with seperate L1 and L2 controllers).  As far as 
allowing another GETS, it depends on the protocol.  If the SLICC 
specification indicates that a GETS hit enters a transient state, then it 
might not allow another request until the transient state leaves.

--Mike

_______________________________________________
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.