[gem5-dev] Review Request: Bus: Split the bus into separate request/response layers

[Andreas Hansson]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1266/
-----------------------------------------------------------

Review request for Default.


Description
-------

Changeset 9074:542b2ace9778
---------------------------
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.


Diffs
-----

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

Diff: http://reviews.gem5.org/r/1266/diff/


Testing
-------

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


Thanks,

Andreas Hansson

[Ali Saidi]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1266/#review2940
-----------------------------------------------------------

Ship it!


Ship It!

- Ali Saidi

Post by Andreas Hansson
-----------------------------------------------------------
http://reviews.gem5.org/r/1266/
-----------------------------------------------------------
(Updated June 11, 2012, 6:58 a.m.)
Review request for Default.
Description
-------
Changeset 9074:542b2ace9778
---------------------------
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.
Diffs
-----
src/mem/bus.hh 35ac3a6f8ee0
src/mem/bus.cc 35ac3a6f8ee0
src/mem/coherent_bus.hh 35ac3a6f8ee0
src/mem/coherent_bus.cc 35ac3a6f8ee0
src/mem/noncoherent_bus.hh 35ac3a6f8ee0
src/mem/noncoherent_bus.cc 35ac3a6f8ee0
Diff: http://reviews.gem5.org/r/1266/diff/
Testing
-------
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
Thanks,
Andreas Hansson

[Andreas Hansson]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1266/
-----------------------------------------------------------

(Updated June 21, 2012, 8:18 a.m.)


Review request for Default.


Description (updated)
-------

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.


Diffs (updated)
-----

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/1266/diff/


Testing
-------

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


Thanks,

Andreas Hansson

[Steve Reinhardt]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1266/#review3028
-----------------------------------------------------------


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.


src/mem/bus.hh
<http://reviews.gem5.org/r/1266/#comment3232>

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.



src/mem/bus.hh
<http://reviews.gem5.org/r/1266/#comment3233>

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.


- Steve Reinhardt

Post by Andreas Hansson
-----------------------------------------------------------
http://reviews.gem5.org/r/1266/
-----------------------------------------------------------
(Updated June 21, 2012, 8:18 a.m.)
Review request for Default.
Description
-------
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.
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/1266/diff/
Testing
-------
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
Thanks,
Andreas Hansson

[Andreas Hansson]

Post by Steve Reinhardt
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.

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.

Post by Steve Reinhardt
src/mem/bus.hh, line 133
<http://reviews.gem5.org/r/1266/diff/2/?file=27501#file27501line133>
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.

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

Post by Steve Reinhardt
src/mem/bus.hh, line 90
<http://reviews.gem5.org/r/1266/diff/2/?file=27501#file27501line90>
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.

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.


- Andreas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1266/#review3028
-----------------------------------------------------------

-----------------------------------------------------------
http://reviews.gem5.org/r/1266/
-----------------------------------------------------------
(Updated June 21, 2012, 8:18 a.m.)
Review request for Default.
Description
-------
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.
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/1266/diff/
Testing
-------
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
Thanks,
Andreas Hansson

[Steve Reinhardt]

Post by Andreas Hansson

Post by Steve Reinhardt
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.

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.

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

Post by Andreas Hansson

Post by Steve Reinhardt
src/mem/bus.hh, line 90
<http://reviews.gem5.org/r/1266/diff/2/?file=27501#file27501line90>
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.

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.

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

Post by Andreas Hansson

Post by Steve Reinhardt
src/mem/bus.hh, line 133
<http://reviews.gem5.org/r/1266/diff/2/?file=27501#file27501line133>
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.

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

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


- Steve


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1266/#review3028
-----------------------------------------------------------

Post by Andreas Hansson
-----------------------------------------------------------
http://reviews.gem5.org/r/1266/
-----------------------------------------------------------
(Updated July 5, 2012, 1:53 a.m.)
Review request for Default.
Description
-------
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.
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/1266/diff/
Testing
-------
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
Thanks,
Andreas Hansson

[Andreas Hansson]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1266/
-----------------------------------------------------------

(Updated July 5, 2012, 1:36 a.m.)


Review request for Default.


Description (updated)
-------

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.


Diffs (updated)
-----

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/1266/diff/


Testing
-------

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


Thanks,

Andreas Hansson

[Andreas Hansson]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1266/
-----------------------------------------------------------

(Updated July 5, 2012, 1:53 a.m.)


Review request for Default.


Description (updated)
-------

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.


Diffs (updated)
-----

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/1266/diff/


Testing
-------

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


Thanks,

Andreas Hansson

[Steve Reinhardt]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1266/#review3052
-----------------------------------------------------------



src/mem/bus.hh
<http://reviews.gem5.org/r/1266/#comment3255>

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.


- Steve Reinhardt

Post by Andreas Hansson
-----------------------------------------------------------
http://reviews.gem5.org/r/1266/
-----------------------------------------------------------
(Updated July 5, 2012, 1:53 a.m.)
Review request for Default.
Description
-------
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.
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/1266/diff/
Testing
-------
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
Thanks,
Andreas Hansson

[Andreas Hansson]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1266/
-----------------------------------------------------------

(Updated July 5, 2012, 7:35 a.m.)


Review request for Default.


Description (updated)
-------

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.


Diffs (updated)
-----

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/1266/diff/


Testing
-------

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


Thanks,

Andreas Hansson

[Steve Reinhardt]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1266/#review3053
-----------------------------------------------------------

Ship it!


Ship It!

- Steve Reinhardt

Post by Andreas Hansson
-----------------------------------------------------------
http://reviews.gem5.org/r/1266/
-----------------------------------------------------------
(Updated July 5, 2012, 7:35 a.m.)
Review request for Default.
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.
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/1266/diff/
Testing
-------
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
Thanks,
Andreas Hansson