Hi Andreas, On 16/07/2013 23:30, Andreas Hansson wrote:
1) Cycles become a headache and essentially you end up building a spanning tree by keeping track of what port has already sent something, iterate etc 2) As a results of 1 you end up having a restricted set of possible system topologies even though the actual address ranges only belong to a single slave port 3) It is a complete mystery at specification time what address ranges correspond to what port (I'd prefer if we could even overlay the ranges on the edges in config.dot.pdf which requires it to be known in the python world, and currently it mostly is)
The thing that bothers me is that PCI is, in principle, dynamically allocated and although I agree that in simple architectures, there won't be much reallocation, when you start introducing multiple PCI bridges between endpoints and the CPU, managing address ranges gets to be a headache (not least because if you add an extra peripheral, it can potentially get inserted between two other addresses).
You're probably right: turning this functionality on might restrict topologies, but that might not be a problem depending on what the specific user is doing (and provided it's an optional behaviour, not enabled by default).
I'm not against re-adding some cleverness, but I'd prefer it to be very explicit (avoid as much magic as possible).
Right. The changes I'm working on only get turned on if the user explicitly specifies they want forwarding behaviour in the architecture description file.
If you're happy about this, can you (or anybody else) give me some clues as to how to go about passing a C++ reference from one BridgeSlavePort to another, driven by Python connections?
Thanks, David. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
