Hi Javed, First a note about the relationship of classes involved in the CHI model. The L1 and L2 CHI caches are not derived from python class RubyCache corresponding to C++ class CacheMemory. CacheMemory is only responsible for managing the memory of the cache, not the protocol that goes around it. L1 and L2 CHI caches are 2 configurations of the same Cache_Controller class (same name in C++ and Python) generated by SLICC after the "Cache" state machine of the CHI protocol. A CacheMemory instance is then an attribute of this CHI_Cache_Controller class (composition in OOP).
About the block size, now. Regarding the CHI protocol, it expects the entire RubySystem to use the same block size, as all other Ruby protocols released in gem5. For convenience, the block size is stored as a static in the RubySystem class and accessed from there by many base components of a ruby model: Address, DataBlock, AbstractController, RubyPort, etc. The block size effectively is a constant global parameter for the whole simulation. While convenient, this is is both limiting to model more exotic systems, and bad OOP practice. Refactoring of this part would be more than welcome, including by me ;) Not an easy job, though. Best, Gabriel _______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
