MEM: Make the bus bridge unidirectional and fixed address range
Review Request #951 - Created Dec. 22, 2011 and submitted
| Information | |
|---|---|
| Andreas Hansson | |
| gem5 | |
| default | |
| Reviewers | |
| Default | |
MEM: Make the bus bridge unidirectional and fixed address range This patch makes the bus bridge uni-directional and specialises the bus ports to be a master port and a slave port. This greatly simplifies the assumptions on both sides as either port only has to deal with requests or responses. The following patches introduce the notion of master and slave ports, and would not be possible without this split of responsibilities. In making the bridge unidirectional, the address range mechanism of the bridge is also changed. For the cases where communication is taking place both ways, an additional bridge is needed. This causes issues with the existing mechanism, as the busses cannot determine when to stop iterating the address updates from the two bridges. To avoid this issue, and also greatly simplify the specification, the bridge now has a fixed set of address ranges, specified at creation time.
util/regress all passing (disregarding t1000 and eio)
Posted (Jan. 4, 2012, 12:46 a.m.)
Posted (Jan. 10, 2012, 2:39 p.m.)
I can't see this diff (I think the repo update messed up reviewboard's ability to display it). Based solely on the description, I must say I'm a little sad to see the flexibility of the old system go (it was nice to be able to take a PCI NIC and stick it wherever we wanted in the memory hierarchy), but that code was kind of complicated, and it's not like a lot of other people took advantage of it.
I confess to not reading all the new bridge code closely, but overall this looks fine.
-
src/mem/bridge.hh (Diff revision 3) -
typo
