ruby: Add bridges between RubyPort and NoncoherentBus

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

Description

Changeset 10022:6be85e163055
---------------------------
ruby: Add bridges between RubyPort and NoncoherentBus

This patch adds bridges between the PIO port of the Ruby sequencers
(based on RubyPort) and the PIO bus (based on NoncoherentBus). Both
the RubyPort and the bus are multiplexing components, and as such,
they should be connected by a bridge, similar to the memory bus and
PIO bus in the classic memory system.

The patch http://reviews.gem5.org/r/2039/ depends on this one.

Testing Done

All regressions pass (with some minor stats changes)

Issue Summary

Description	From	Last Updated	Status
I think there is some problem here. You are setting source to 0 here, but in review 2039, you set ...	Nilay Vaish	Jan. 24, 2014, 8:40 p.m.	Open

src/mem/ruby/system/RubyPort.cc (Diff revision 1)

I think there is some problem here. You are setting source to 0 here, 
but in review 2039, you set source to the id of the port that received 
this request packet.  Which one do you want to go with?

Show all issues

Andreas Hansson Jan. 25, 2014, 1:11 a.m. (Jan. 25, 2014, 1:11 a.m.)

This patch goes first, and it has to bed set to something for the bridge to not care. However, Ruby still uses its own sender state to do the routing. This patch passes regressions, but slightly changes stats.

The 2039 patch then changes the Ruby port to do the routing properly, which is now possible with the bridge in place. Each patch on its own passes regressions, but ultimately we want both committed.

I split them since one changes regressions and the other one only changes how the behaviour is achieved.

I think we should drop this patch.  Two reasons:

* I need to add port connections where the ruby port act as the slave side and 
the piobus acts as the master side.  This means that the in-between bridge will 
have to inform the piobus of the address ranges the bridge will cater to.  
Those address ranges are not known to the ruby port until the attached 
interrupt controllers pass that information.  But the bridge assumes that this 
information is available while the object is being constructed and the piobus 
is informed of the ranges in the init() function of the bridge.  We cannot assign
some big default range (as being done for most bridges used) since one bridge
for each ruby port needs to be added.

* In future we will severe this direct connection between ruby port and the piobus.
I think we can simply retain the current setup of connecting things directly to
the piobus.

Andreas Hansson Jan. 27, 2014, 1:06 a.m. (Jan. 27, 2014, 1:06 a.m.)

I am in favour of keeping the same semantics and rules throughout the memory system, hence the patch. Doing so will make it easier for everyone to understand and modify the code base.

The issue you mention with the interrupt controller sounds rather unfortunate. I assume you are referring to the conventional interrupt controllers? Surely they should not be connected to the (slow) piobus?

I'd still like to understand the problem a bit more before giving up on this thread, and perhaps this is what you allude to in (2). Perhaps the RubyPort should not be a multiplexing component in the first place? Is there a more elegant way to do this and still adhere to the memory system semantics?

You have a pending review.

Review Board 2.0.15

This change has been discarded.

Screenshots

Files

Issue Summary

Status: Discarded