Bus: Add a notion of layers to the buses

Information
Submitter:	Andreas Hansson
Repository:	gem5
Branch:	default
Bugs:
Depends On:
Reviewers
Groups:	Default
People:

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.

Testing Done

util/regress all passing (disregarding t1000 and eio)

Ship It!

Description:

~		Changeset 9073:6bb29a29c452
	~	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.

Diff:

Revision 2 (+232 -109)

Show changes

	src/mem/bus.hh
	src/mem/bus.cc
	src/mem/coherent_bus.hh
	src/mem/coherent_bus.cc
	src/mem/noncoherent_bus.hh
	src/mem/noncoherent_bus.cc

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 July 4, 2012, 5:23 p.m. (July 4, 2012, 5:23 p.m.)

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.

Steve Reinhardt July 5, 2012, 12:07 a.m. (July 5, 2012, 12:07 a.m.)

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 ;-).

src/mem/bus.hh (Diff revision 2)

I assume this will inherit the tryTiming() rename from the other patch, correct?

Andreas Hansson July 4, 2012, 5:23 p.m. (July 4, 2012, 5:23 p.m.)

You're absolutely right. I'll bump the patch. It is already changed.

Description:

~		Changeset 9078:920ca8183398
	~	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.

Diff:

Revision 3 (+232 -109)

Show changes

	src/mem/bus.hh
	src/mem/bus.cc
	src/mem/coherent_bus.hh
	src/mem/coherent_bus.cc
	src/mem/noncoherent_bus.hh
	src/mem/noncoherent_bus.cc

Ship It!

You have a pending review.

Review Board 2.0.15

This change has been marked as submitted.

Screenshots

Files

Description:

Changeset 9073:6bb29a29c452

Changeset 9078:920ca8183398

Diff:

Description:

Changeset 9078:920ca8183398

Changeset 9094:3a907dece3ac

Diff:

Status: Closed (submitted)