> That makes sense. I think these things are mostly aggregated into a > single chip in modern systems anyway, so it would probably actually be > more realistic. I think on the C++ end I'll keep these bits separated, > but they'll all be hooked up as one SimObject which attaches to the > memory system. That's fine, don't go too crazy. Keep it simple.
> I'm pretty sure a real machine takes the second approach. For PCI, > it would be built into the PCI bus bridge which would likely be built > into the north bridge (I believe). That sucks performance wise, but > there are apparently features built in to circumvent this mechanism and > memory map the config space. For a lot of this other stuff like the > CMOS, it ends up stuffed into the south bridge (again not entirely > sure), so it all ends up becoming just part of the interface for the big > device rather than a bridge of some sort with a device behind it. Alright. I'd suggest not merging them into the bridge itself though. Make it a separate device so it can get stuck anywhere on any bus. > I was under the impression that there was some device which would > field requests for PCI since they don't necessarily have fixed addresses > to listen on. It would listen to everything and then send the right > accesses to the right places. That might be a misinterpretation on my part. No. There are registers in the PCI config space called BARs. Those registers are read by the operating system to query the device about how many, what type, and how big are the address ranges (there are 6). The operating system is then expected to take this data and allocate physical memory and write the BARs with the addresses of the physical memory chunks. That's why the PCI config space is in a fixed place, but the rest of PCI memory is not. The default responder on a bus is so that the bus can be probed. ISA for example doesn't have a config space, so you just have to go search for the device. PCI has a default responder according to the spec, but I don't know that it's really used. Ali would know more about this. Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
