Bus: Split the bus into separate request/response layers

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

Description

Changeset 9095:6d876723c1e7
---------------------------
Bus: Split the bus into separate request/response layers

This patch splits the existing buses into multiple layers. The
non-coherent bus is split into a request and a response layer, and the
coherent bus adds an additional layer for the snoop responses. The
layer is modified to be templatised on the port type, such that the
different layers can have retryLists with either master or slave
ports. This patch also removes the dynamic cast from the retry, as
previously promised when moving the recvRetry from the port base class
to the master/slave port respectively.

Overall, the split bus more closely reflects any modern on-chip bus
and should be at step in the right direction. From this point, it
would be reasonable straight forward to add separate layers (and thus
contention points and arbitration) for each port and thus create a
true crossbar.

The regressions all produce the correct output, but have varying
degrees of changes to their statistics. A separate patch will be
pushed with the updates to the reference statistics.

Testing Done

util/regress all running and producing the right output (disregarding t1000 and eio) but with essentially all timing tests exhibiting stat differences reflecting less bus contention

Issue Summary

Description	From	Last Updated	Status
Would you document this template parameter more? Obviously every bus connects MasterPorts to SlavePorts, so it's not immediately obvious what ...	Steve Reinhardt	July 4, 2012, 6:40 p.m.	Resolved
Sorry to nitpick, but I was looking for a precise statement like "The template parameter indicates the destination port type ...	Steve Reinhardt	July 5, 2012, 12:35 a.m.	Resolved

Ship It!

Description:

~		Changeset 9074:542b2ace9778
	~	Changeset 9079:5fb6386c07b4

		Bus: Split the bus into separate request/response layers

		This patch splits the existing buses into multiple layers. The
		non-coherent bus is split into a request and a response layer, and the
		coherent bus adds an additional layer for the snoop responses. The
		layer is modified to be templatised on the port type, such that the
		different layers can have retryLists with either master or slave
		ports. This patch also removes the dynamic cast from the retry, as
		previously promised when moving the recvRetry from the port base class
		to the master/slave port respectively.

		Overall, the split bus more closely reflects any modern on-chip bus
		and should be at step in the right direction. From this point, it
		would be reasonable straight forward to add separate layers (and thus
		contention points and arbitration) for each port and thus create a
		true crossbar.

		The regressions all produce the correct output, but have varying
		degrees of changes to their statistics. A separate patch will be
		pushed with the updates to the reference statistics.

Diff:

Revision 2 (+71 -44)

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

Looks nice.  Does it make sense to keep the old single-layer buses as an option?  I agree they're not very realistic for modern designs, but they do model something that people have built in the past.  I'm not sure if it's worth the hassle or not, but I thought I'd raise the question.

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

I think there is little point. I'd prefer to have the split request/response as the base, as that also avoids any protocol deadlock issues, both involving the interaction of two caches, and the bridges between buses. Makes sense?

From there it is easy to support everything from split req/resp all the way to a single layer per converging port, i.e. req layer per connected slave and resp layer per connected master.

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

Good point, I'd forgotten about the deadlock issues with the existing bus.  That's a sufficient reason to get rid of it IMO.

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

Would you document this template parameter more?  Obviously every bus connects MasterPorts to SlavePorts, so it's not immediately obvious what goes here.

Also, I don't know if we have an official style rule for template parameter naming, but I know that all-caps is not common usage.  I tend to make them camel case but with a suffix that indicates that it's not just a class name; e.g., in this case I would probably use PortClass.  I'm happy to open a discussion on this if desired.

Show all issues

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

I'm happy to change it. I was not aware of the convention, and if PortClass is desired then that's fine with me. It is a bit long though, that's my only concern. For the port it is fine, but I am about to post a patch which uses templates for the port interfaces, and that ends up being BaseMasterPortInterfaceClass.

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

As I said, there isn't an official convention (at least not documented on the wiki), but we should have one.  Looking through the existing code base, we are not consistent.  Most uses are either one or two capital letters (e.g., T) or follow our standard class naming convention (e.g., Stat, Derived, Impl).  There are a few exceptions; mem/ruby/system/PerfectCacheMemory.hh uses ENTRY, arch/arm/insts/vfp.hh uses fpType.  I guess tacking on "Class" is something that only I do.  So I guess if we use existing code as a guide, "Port" would be the appropriate capitalization, but in this case that would be pretty confusing though, so I would still lean toward "PortClass".  It would be nice to establish some standard and I'd be happy to have a discussion about it.  We should probably start a new thread instead of burying it in these comments though.

For longer parameter names, you can always use typedefs if they get awkward.  Plus I'd argue that BaseMasterPortInterface is pretty long by itself anyway (so tacking on "Class" doesn't make it that much worse), and BASEMASTERPORTINTERFACE or whatever you were planning on doing otherwise is pretty ugly ;-).

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

I feel like we discussed "Port* port" vs "Port *port" before as well... do you recall what we ended up deciding?  We should probably record that decision on the wiki.

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

The decision was:

1) Port* port is ok
2) Port *port is ok
3) Port * port is _not_ ok

For 1) and 2), the use should be guided by the context, i.e. if changing an existing file that predominantly uses 1), then stick with it (or change the whole file to be consistent). If creating a major chunk of code from scratch, we did not decide whether to favour 1) or 2)...so I go with 1).

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

OK, I'm glad you remembered.  I updated the wiki to make it official.

Description:

~		Changeset 9079:5fb6386c07b4
	~	Changeset 9095:d69353863278

		Bus: Split the bus into separate request/response layers

		This patch splits the existing buses into multiple layers. The
		non-coherent bus is split into a request and a response layer, and the
		coherent bus adds an additional layer for the snoop responses. The
		layer is modified to be templatised on the port type, such that the
		different layers can have retryLists with either master or slave
		ports. This patch also removes the dynamic cast from the retry, as
		previously promised when moving the recvRetry from the port base class
		to the master/slave port respectively.

		Overall, the split bus more closely reflects any modern on-chip bus
		and should be at step in the right direction. From this point, it
		would be reasonable straight forward to add separate layers (and thus
		contention points and arbitration) for each port and thus create a
		true crossbar.

		The regressions all produce the correct output, but have varying
		degrees of changes to their statistics. A separate patch will be
		pushed with the updates to the reference statistics.

Diff:

Revision 3 (+71 -44)

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

Description:

~		Changeset 9095:d69353863278
	~	Changeset 9095:d34f7edb5762

		Bus: Split the bus into separate request/response layers

		This patch splits the existing buses into multiple layers. The
		non-coherent bus is split into a request and a response layer, and the
		coherent bus adds an additional layer for the snoop responses. The
		layer is modified to be templatised on the port type, such that the
		different layers can have retryLists with either master or slave
		ports. This patch also removes the dynamic cast from the retry, as
		previously promised when moving the recvRetry from the port base class
		to the master/slave port respectively.

		Overall, the split bus more closely reflects any modern on-chip bus
		and should be at step in the right direction. From this point, it
		would be reasonable straight forward to add separate layers (and thus
		contention points and arbitration) for each port and thus create a
		true crossbar.

		The regressions all produce the correct output, but have varying
		degrees of changes to their statistics. A separate patch will be
		pushed with the updates to the reference statistics.

Diff:

Revision 4 (+81 -48)

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

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

Sorry to nitpick, but I was looking for a precise statement like "The template parameter indicates the destination port type for the bus."  The rest of your comment is good to keep as an explanation, but it's not a direct description of the parameter.

Show all issues

Description:

~		Changeset 9095:d34f7edb5762
	~	Changeset 9095:6d876723c1e7

		Bus: Split the bus into separate request/response layers

		This patch splits the existing buses into multiple layers. The
		non-coherent bus is split into a request and a response layer, and the
		coherent bus adds an additional layer for the snoop responses. The
		layer is modified to be templatised on the port type, such that the
		different layers can have retryLists with either master or slave
		ports. This patch also removes the dynamic cast from the retry, as
		previously promised when moving the recvRetry from the port base class
		to the master/slave port respectively.

		Overall, the split bus more closely reflects any modern on-chip bus
		and should be at step in the right direction. From this point, it
		would be reasonable straight forward to add separate layers (and thus
		contention points and arbitration) for each port and thus create a
		true crossbar.

		The regressions all produce the correct output, but have varying
		degrees of changes to their statistics. A separate patch will be
		pushed with the updates to the reference statistics.

Diff:

Revision 5 (+82 -48)

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

Issue Summary

Description:

Changeset 9074:542b2ace9778

Changeset 9079:5fb6386c07b4

Diff:

Description:

Changeset 9079:5fb6386c07b4

Changeset 9095:d69353863278

Diff:

Description:

Changeset 9095:d69353863278

Changeset 9095:d34f7edb5762

Diff:

Description:

Changeset 9095:d34f7edb5762

Changeset 9095:6d876723c1e7

Diff:

Status: Closed (submitted)