Re: [Gems-users] ruby caches

[Mike Marty <mikem@xxxxxxxxxxx>]

> 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