Re: [Gems-users] ruby caches

[Christian Bienia <cbienia@xxxxxxxxxxxxxxxx>]

Hi,

thanks for the help. I'm using MSI_MOSI_CMP_directory. For my research I have 
to play around with the L1 and L2 hit latencies. I guess to get an L1 latency 
different from 1 I'll have to modify the code. If you guys can point me to 
the right position I can do that myself. The L1 cache shouldn't be that hard, 
but I'm a little bit worried about the scheduler: Usually, the schedule 
assumes an L1 hit and if possible schedules instruction s.t. the data is 
referenced no earlier than after the L1 latency has passed. I found a little 
bit here, but it's for the L1I and not the L1D:
https://lists.cs.wisc.edu/archive/gems-users/2005-June/msg00036.shtml
How difficult will it be to incorporate that behavior?

One more question about the cache size: g_DATA_BLOCK_BYTES is the size of a 
cache line, right?

Chris


On Tuesday 21 June 2005 08:33 pm, Mike Marty wrote:
> > I have a few question about the configurability of the ruby caches. I
> > had a look on config.include in the $GEMS/ruby/config directory and saw
> > the following parameters:
> >
> > PARAM( L1_CACHE_ASSOC );
> > PARAM( L1_CACHE_NUM_SETS_BITS );
> > PARAM( L2_CACHE_ASSOC );
> > PARAM( L2_CACHE_NUM_SETS_BITS );
> >
> > I couldn't find a parameter to change the size directly. Am I supposed
> > to change the cache capacity indirectly by modifying the number of sets?
> > How does ruby determine the size of the L1 instruction and data caches
> > from that (I assume a split L1 cache is used)?
>
> All of the protocols we include use the parameters above for instantiating
> the L1I, L1D, and L2 caches (if the L2 exists).  Yes, you change cache
> capacity by modifying the number of sets, and the number of ways in each
> set.
>
> A 64kb 4-way L1 cache (for both I and D):
>
>   (4-ways per set) * (2^8 sets) * (64 bytes per cache block) = 64kb
>
> The L1I and L1D are both instantiated to the size specified.  If you need
> different sizes, you will need to change the SLICC specification to
> instantiate based on different parameters.
>
> > How do I change the number of banks for the L1 cache, I can only find
> > the parameter g_NUM_L2_BANKS, but no "g_NUM_L1_BANKS".
>
> We assume that each processor has a single L1 cache controller attached to
> it.  Each L1 cache controller controls a single I and D cache bank (except
> for the single level protocols in which each processor has a single
> cache).  If you really must sub-bank the L1 cache, we can give you tips on
> how to do this but it will require some more substantial effort and
> extensions on your part.  The only reason to sub-bank the L1 cache is to
> model bank contention in more detail than what is currently done.
>
> > And finally, how do I set the latency of the caches? I could find the
> > following parameters which all seem to affect the hit latency:
> >
> > PARAM( NULL_LATENCY );
> > PARAM( ISSUE_LATENCY );
> > PARAM( CACHE_RESPONSE_LATENCY );
> > PARAM( L2_RESPONSE_LATENCY );
> > PARAM( L1_RESPONSE_LATENCY );
> >
> > Could somebody please briefly explain their meaning?
>
> These are the latencies used by a cache controller specification.
> Different protocols will use them differently.  In general, the SMP
> protocols will use CACHE_RESPONSE_LATENCY, and the CMP protocols use
> L1_RESPONSE_LATENCY and L2_RESPONSE_LATENCY for approximating the tag
> latency of the cache(s).  ISSUE_LATENCY is the fixed delay an L1
> controller incurs upon issuing a coherence or memory request.
>
> When Simics issues a request to Ruby, the Ruby Sequencer checks the L1
> cache to see if it has sufficient permissions (a cache hit).  If the
> sequencer hits, it returns a single cycle.  Otherwise it will issue the
> request to the processor's L1 cache controller which will then process the
> request incurring delay either in the interconnection network, or by the
> latency parameters such as those above.  The SMP protocols use a single
> cache controller for both the L1 and L2 caches.  On an L1 miss, the
> CACHE_RESPONSE_LATENCY parameter is used after attaining coherence
> permission.
>
> Brad gave a good answer to how this works in a thread last week.  Please
> check it out in the archive:
>
> https://lists.cs.wisc.edu/archive/gems-users/2005-June/msg00033.shtml
>
> I know I didn't give the best of anwsers.  If you are interested in
> setting hit latencies for a particular protocol, tell me what the protocol
> is and I can try to be more specific.
>
> --Mike
>
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users