Well, I definitely don't think the generic scripts like se.py and fs.py are something to preserve, but unless we're prepared to break them and throw them out, then we have to figure out some way to maintain compatibility. I'm trying to figure out a way to keep things compatible at least for now, but get rid of the "if x86 do this, if arm do that" constructs that are tucked into little corners around gem5, particularly in the CPUs.
I also agree that this really shouldn't be tied to the SimObjects. I would like to see the SimObjects as bare as possible, and put all this helper functionality somewhere else. Removing it outright would again break compatibility, which I'm trying to avoid at least for now. These wrappers would *not* be new SimObjects in the sense that they would not have C++ representations, they would just be grease to help the python code work in a more generic way which would disappear when things were really instantiated. Again, I don't think these super generic mechanisms are something we should strive to maintain or support in the long term, I'm just trying to figure out a way to not break the world while I get rid of TARGET_ISA and the single ISA assumptions in gem5. Gabe On Thu, Oct 28, 2021 at 7:45 AM Jason Lowe-Power <ja...@lowepower.com> wrote: > Hi Gabe, > > This is one of the main use cases for the components in the component > library. The idea behind the component library is to have the SimObjects be > *models* which only have parameters and no instantiated objects. Then, the > *components* would tie together specific instances of SimObjects into > larger systems. For CPUs, we have a few examples so far, and they are > working with x86 and RISC-V in SE and FS mode with classic and Ruby caches. > We haven't tested Arm full system, yet, but it's our intention that the > component library support this. I would encourage you to take a look at the > AbstractProcessor and AbstractCore classes. > > https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/python/gem5/components/processors/abstract_core.py > > > https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/python/gem5/components/processors/abstract_processor.py > > To support things like core complexes which contain multiple cores and > caches, this interface won't work. My opinion is that these more complex > cases are impossible to create a generalized interface for, and we will > have to provide our users with "prebuilt systems" which implement these > kinds of architectures with tightly coupled caches and processors. > > IMO, this kind of complexity should not be in the SimObject itself, but > separated out into the component definition. I would prefer to not add more > complexity to the parameters and to the SimObject description files. > However, if you want to take this a different direction, we would > appreciate it to be fully compatible with the component library and require > the minimum changes to the (hopefully soon to be deprecated) se/fs.py > config scripts. > > Cheers, > Jason > > On Wed, Oct 27, 2021 at 9:40 PM Gabe Black via gem5-dev <gem5-dev@gem5.org> > wrote: > >> Hi folks. There are some helper functions in BaseCPU which help set up >> ancillary structures like caches, and tries to keep track of the frontier >> of ports that need to be connected so that a CPU + caches can be >> generically hooked into a system. >> >> This code is a bit clunky and complex, and makes it more difficult to >> delay setting up ISA specific components like MMUs and interrupt >> controllers which may need to connect to the memory system as well. >> >> I'm thinking that one way to clean this up could be to make a wrapper >> which represents the CPU complex as a whole, which can be nested to add new >> layers and which would provide a consistent interface no matter how much >> extra stuff got layered on. >> >> Importantly, these layers would be set up so that their ports were just a >> layer of indirection, and they would not represent extra levels of stuff to >> traverse in c++. I think systemc has a concept *roughly* analogous to this >> called exports (ex-ports, as opposed to ports? get it?) which let you poke >> ports from internal components out of the external interface. >> >> I'm thinking these port repeaters, or port proxies (overloaded term) or >> exports, or whatever they're called could be added to the existing >> SubSystem container to make a more generic and useful config level wrapper. >> >> class CpuComplex(SubSystem): >> inst_ports = VectorPortProxy >> data_ports = VectorPortProxy >> uncached_ports = VectorPortProxy >> >> class AtomicSimpleCpuComplex(CpuComplex): >> cpu = AtomicSimpleCPU >> inst_ports = cpu.icache_port >> data_ports = cpu.dcache_port >> >> class WithCaches(CpuComplex): >> cpu = AtomicSimpleCpuComplex >> inst_ports = cpu.inst_ports >> data_ports = cpu.data_ports >> uncached_ports = cpu.uncached_ports >> >> >> Something similar to this could generically hold the interrupts object, >> etc, which may or may not have certain ports connected, and then if a proxy >> has nothing on the other side of it, it could just not actually connect? >> >> There would be some python/config/SimObject/param hacking necessary to >> make this work, but I think it would generalize these different sorts of >> connections and make this easier to work with. >> >> Ideally in the long run we might not want to have these scripts which >> generically support x86, arm, etc, etc, but unless we're prepared to break >> all those scripts, we're going to need to keep that working somehow. >> >> Gabe >> _______________________________________________ >> gem5-dev mailing list -- gem5-dev@gem5.org >> To unsubscribe send an email to gem5-dev-le...@gem5.org >> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > >
_______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
