> On July 4, 2012, 4:10 p.m., Steve Reinhardt wrote: > > This looks like a nice step forward; it will be good to be able to have > > separate request and response buses. I'm not sure that Layer is the best > > term for this though... I don't know of an "official" term (does ARM use > > "layer" for this?), but to me the name makes me think of protocol layers, > > like "link layer" or "transaction layer". "Lane" is more intuitive to me, > > but I can see where that would cause confusion since that's not what PCI > > Express means by "lane". I don't have any other good ideas... I thought of > > "bundle" or "subbus" but I'm not going to claim those are good. Are there > > official documents that use "layer" for this concept?
AMBA uses layer as the official term, and so does OCP. Ask google for multi-layer AHB for example. Ultimately a layer (or what ever we choose to call it) denotes a shared resource, i.e. a unit of arbitration/contention. As the extreme case, we would have one request layer for each connected slave (e.g. memories) to allow all the connected masters (e.g. CPUs) to have parallel transactions as long as they do not go to the same destination. A similar approach would be taken for the responses, with one layer per connected master. At this point the interconnect really becomes a full crossbar (even though it is still called a bus). This is what most AXI and OCP interconnects do. I vote for layer, but that's because I've been living in the on-chip bus world for the last decade and happen to find it intuitive. > On July 4, 2012, 4:10 p.m., Steve Reinhardt wrote: > > src/mem/bus.hh, line 136 > > <http://reviews.gem5.org/r/1265/diff/2/?file=27495#file27495line136> > > > > I assume this will inherit the tryTiming() rename from the other patch, > > correct? You're absolutely right. I'll bump the patch. It is already changed. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1265/#review3027 ----------------------------------------------------------- On June 21, 2012, 8:16 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1265/ > ----------------------------------------------------------- > > (Updated June 21, 2012, 8:16 a.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9078:920ca8183398 > --------------------------- > Bus: Add a notion of layers to the buses > > This patch moves all flow control, arbitration and state information > into a bus layer. The layer is thus responsible for all the state > transitions, and for keeping hold of the retry list. Consequently the > layer is also responsible for the draining. > > With this change, the non-coherent and coherent bus are given a single > layer to avoid changing any temporal behaviour, but the patch opens up > for adding more layers. > > > Diffs > ----- > > src/mem/bus.hh d8e5ca139d7c > src/mem/bus.cc d8e5ca139d7c > src/mem/coherent_bus.hh d8e5ca139d7c > src/mem/coherent_bus.cc d8e5ca139d7c > src/mem/noncoherent_bus.hh d8e5ca139d7c > src/mem/noncoherent_bus.cc d8e5ca139d7c > > Diff: http://reviews.gem5.org/r/1265/diff/ > > > Testing > ------- > > util/regress all passing (disregarding t1000 and eio) > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
