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
