Hi Gabriel Many thanks for your insight and input.
I have taken on board your suggestion and simplified the customisation of CHI.py and CHI_config.py by just using the CHI_Config.CHI_RNF() class object and adding another method to CHI_Config.CHI_RNF(), called addSharedL2Cache. Also I have started testing with 1 cluster which contains 1 CPU and permutating with shared/private L2 cache. >> I would then suggest two non-tested options. You can assign the L2 >> controller to cpu.l2 after registering it as downstream_components of l1i >> and l1d. Let's hope it will set the desired name. Will try this out. Best regards J.Osmany -----Original Message----- From: Gabriel Busnot via gem5-users [mailto:gem5-users@gem5.org] Sent: 22 July 2021 08:40 To: gem5-users@gem5.org Cc: Gabriel Busnot <gabriel.bus...@arteris.com> Subject: [gem5-users] Re: CHI - Cluster CPUs having a shared L2 cache Hi Javed, Woops, I didn't see the split option in your first post. My bad. I think the l2 is actually named "system.cpu0.l1i.downstream_destinations" and you will find it in the ini file. I think this is due to the way gem5 sets SimObject names. When you assign a SimObject to several object attributes (cpu.l2, cpu.l1i and finally cpu.l1d), it will have one of the names according to the complex SimObject and SimObjectVector logic. for some reason, it does not end up as a child of cpu0.l1d despite it being the last in the list. I am regularly fighting SimObject naming logic as well, that's normal ;) Also check the warnings in the output. Some of them will warn you about SimObject reparenting. Sadly, SimObject name is determined by the attribute you set it to and you are not supposed to change it. I would then suggest two non-tested options. You can assign the L2 controller to cpu.l2 after registering it as downstream_components of l1i and l1d. Let's hope it will set the desired name. The other "last resort" option is to violate SimObject._name privacy and set it manually after the SimObject has been assigned for the last time... I would advise against that, though. Whenever possible, it is actually best to assign a SimObject at the time of object creation and never assign it again afterwards... Not always possible, though. Also make use of "private" attributes (i.e., attributes with a name starting with '_') as much as possible. It bypasses the SimObject assignment logic and solves many issues. 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 _______________________________________________ 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
