> 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? > > Andreas Hansson wrote: > 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.
The concept makes perfect sense and is one I've seen before; I just wasn't aware of a standard name. I still find "layer" a bit confusing for the reasons I mentioned. In fact if you google "site:ocpip.org layer" it looks like 90% of the uses of that word refer to abstraction layers and not bus "layers". But if that's the standard terminology, then I guess it's not your fault ;-). - Steve ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1265/#review3027 ----------------------------------------------------------- On July 5, 2012, 1:35 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1265/ > ----------------------------------------------------------- > > (Updated July 5, 2012, 1:35 a.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9094:3a907dece3ac > --------------------------- > 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 5f0321c03a26 > src/mem/bus.cc 5f0321c03a26 > src/mem/coherent_bus.hh 5f0321c03a26 > src/mem/coherent_bus.cc 5f0321c03a26 > src/mem/noncoherent_bus.hh 5f0321c03a26 > src/mem/noncoherent_bus.cc 5f0321c03a26 > > 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
