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
