Hi David, The bridge used to do filtering, and there was a rather complex scheme where the buses "discovered" ranges by iterating over the ports until everything settled down. The main drawbacks with this approach were:
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) I'm not against re-adding some cleverness, but I'd prefer it to be very explicit (avoid as much magic as possible). If we really need to change address ranges on the fly I'd like to know more about the use-case. I would imagine that in most cases, what sits behind the bridge should be part of one or a few larger ranges. Andreas On 7/16/13 8:00 PM, "David Miller" <[email protected]> wrote: >Hi, > >I'm hacking some changes into src/mem/bridge so that subordinate >peripherals are reachable by the CPU without manual configuration of >range lists, especially when in a hierarchy of buses. Ali tells me that >there used to be this or similar functionality, but it got taken out for >some reason he didn't remember. (Andreas?) It'd be great to get some >background on that if possible. > > >At least in the x86 case, there is a cycle between membus and iobus (so >that PCI agents can initiate DMA transactions), so the approach I'm >going to take is to compare the subordinate bus's range list with the >superordinate bus, and forward only those addresses that don't exist on >the superordinate bus. > >In order to do this, I need to get a reference to the upstream bridge's >SlavePort into the downstream bridge. I can see how a class like Bridge >instantiates other classes (like SlavePort or, rather, BridgeSlavePort), >and I see how to pass simple parameters into a C++ class from its Python >equivalent, but I don't see how to pass a reference to another C++ class. > >I would imagine that a mechanism similar to the port connection might do >the job, but I don't quite see how that works, either. Apologies, I'm >an FPGA guy and it's been years since I did anything serious in C++. > >Any pointers (so to say) would be most welcome. > >Thanks, > >David. >_______________________________________________ >gem5-dev mailing list >[email protected] >http://m5sim.org/mailman/listinfo/gem5-dev > -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
