Re: [Gems-users] Configuring Ruby with heterogeneous caches

[Mike Marty <mikem@xxxxxxxxxxx>]

Right now, CacheMemory.h has a constructor where the size and 
associativity is passed.  The SLICC controller specifications pass this 
information. 

I might avoid changing SLICC so that it doesn't have to figure out the 
different arguments to pass to the constructor.  Instead, you could 
modify CacheMemory.h to pass the node number.  Then the CacheMemory 
constructor can determine the proper size/associativity based on what 
you want.
Changing the access latencies of the L1 cache might take some trickery.  
The best way off the top of my head is to use a different 
SEQUENCER_TO_CONTROLLER latency for the appropriate L1 cache.  In other 
words, modify ruby/Sequencer.C to use a different latency depending on 
the L1 cache.
--Mike


Philip Garcia wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I was wondering if anyone has worked with ruby to allow for more  
> heterogeneous cache architectures.   For example simulating a CMP  
> system with 2 processors having a 64k L1 cache, and a third with a  
> smaller L1 cache (all sharing the same L2 cache).   I am looking for  
> structures like this because I am currently looking into extending  
> GEMS to allow reconfigurable hardware (or more generally any external  
> hardware) to directly access the memory hierarchy.  The level at  
> which these connections occur may vary depending on the hardware's  
> functionality (such as the external hardware connecting to the  
> processors L2 cache, or reading from main memory).
> My goal for now is just to create a processor structure with an extra  
> node that has a different L1 size (and a configurable L1 access  
> latency different from the normal L1 caches)  and isn't directly  
> attached to a simics processor (the actual simulation of the external  
> units would be controlled through a separate module).
> If anyone has done anything similar, or any ideas of the best place  
> to start editing it would be greatly appreciated.   After looking  
> through the source it appears the best place would be through  
> modifying the SLICC interface (as well as some of the configuration/ 
> initialization code), although I'm not 100% sure.
> thanks,
> Phil 
>   
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (Darwin)
>
> iD8DBQFEoZtmkSK2LwjyZ3wRArYsAJ4zCaoutWdLl3SP4a0dImDrcDLhZQCcDmeI
> FYQaGvBBl9Iq+uz38uwP02Q=
> =81Cj
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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.
>