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
