On Mon, 27 Jan 2014, Andreas Hansson wrote:
On Jan. 27, 2014, 7:02 a.m., Nilay Vaish wrote:
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.
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.
While I agree with you on this, I think once all the packets start flowing
through the ruby network, we will be able to add a bridge at the point
where packets from the ruby network to the piobus and vice versa.
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?
If a device wants to raise an interrupt, should it not be routed through
the piobus? What else do you see as a possible design? What do you mean
by slow?
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?
As of now, the interrupt controller, that each processor has, connects
directly to the piobus when ruby is in use. I am of the view that they
should connect to the pio bus through ruby port and that ultimately all
the packets between these interrupt controllers and the piobus should flow
through ruby's network. A larger aim is to eliminate the extra copy of
memory that is attached to the piobus when ruby is in use.
If we decide on introducing bridges between ruby port and piobus, then we
will have one bridge whose master port is connected to ruby and slave port
is connected to the piobus. The address range that this bridge caters to
is not known to the ruby port initially. It becomes known when the slave
side of the interrupt controller informs the ruby port. But the bridge
needs to inform the address range to the piobus when its init() function
is called. I tried to think of ways to modify the bridge so that it
informs the piobus only when its master port has received the address
range. Ultimately I concluded that this might not be feasible since some
instantiations of the bridge class rely on the default address range
provided to the bridge.
As I mentioned above, once all packets start flowing through ruby's
network, the point at which they enter/exit ruby network and the piobus
would be connected via a bridge, whose address range I am guessing would
be the entire 64-bit space.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
