Hi Andreas, Sorry for the slow responses.
I think we're in agreement on the desirable end-point, in terms of everything in the classic memory system at least using 4-phase handshakes, and Ruby using gem5 ports. I'm just not 100% sold yet on the mechanism to get there. If Ruby ports need something different from the 4-phase handshake, then that's a good argument for your interface/protocol separation, but I'd like some of the more Ruby-oriented people like Brad to weigh in on that. As far as the gradual introduction of the 4-phase interfaces, we should talk about that with Brad some more too. He was responsible for keeping our internal code base synced with the public repository, and I believe he might think that one big change is easier to handle than a bunch of little ones. Don't misunderstand, I'm not opposed to the idea; it's just a big change that in some ways is a significant increase in complexity, so I'd like to get some broader input agreeing that this additional complexity is needed before we pull the trigger. Maybe Nate is right, a discussion over skype or google hangout or something might be justified to get us all on the same page. The next few days are busy for me, but I should have some time Thu or Fri if this sounds good to everyone. Steve On Thu, Aug 9, 2012 at 2:44 PM, Andreas Hansson <[email protected]>wrote: > Hi Steve, > > Thanks for taking time to go through the patch. > > On your question on the need for diversity, I think there is a good reason > to enable e.g. Ruby to use gem5 ports, but with a different interface. > Similarly, for any other alternative interconnects it provides a > possibility to use the existing infrastructure for assembling the system. > > When it comes to the "classic" vs 4-phase, we will indeed phase it in > gradually. The way we do this is with adapter blocks that have one port of > each kind. These adapters will eventually be completely removed again, and > the "classic" old-style handshakes removed. There is still a possibility > to e.g. Have cache-coherent and non-cache-coherent ports with the same > protocol in the bottom, just a few more interface methods or not. This > becomes trivial with the interface/protocol separation (sorry about the > confusion with the naming btw). > > From my point of view, this is really a necessary change to get the > 4-phase handshakes in place. Once we are in the next stable state, we can > potentially simplify bits and pieces, especially if there is push-back > from the Ruby part of the world when it comes to using it. I think that > there are compelling reasons to share as much as possible and align e.g. > Ruby and classic memory controllers/buses etc. > > Thanks again for all the feedback. > > Andreas > > On 08/08/2012 20:17, "Steve Reinhardt" <[email protected]> wrote: > > >I finally got around to looking at Andreas's big patch ( > >http://reviews.gem5.org/r/1301/) yesterday, and perhaps more importantly, > >spent some time reading up on SystemC TLM 2.0 and what the port/interface > >separation is used for there. One big disconnect I found is that my > >interpretation of "protocol" wasn't the same as what SystemC or Andreas > >meant. > > > >I was thinking of "protocol" at a higher level, as in what are the set of > >commands/requests that are supported, what are the available > >flags/attributes on a request, etc., all the way up to protocol in the > >Ruby > >sense. However, it looks like much of the purpose of the port/interface > >separation is to abstract away the very low-level protocol that two > >connected modules use to exchange a packet, e.g., what does the handshake > >look like, how is flow control handled, etc. Loosely speaking, it's like > >the difference between the transaction layer protocol and the link layer > >protocol. > > > >I'm curious how much diversity and flexibility we really need at that > >lowest layer. The current send/retry scheme has some issues, which > >Andreas > >is proposing to fix with the four-phase handshake; I'm a little sad to see > >that get introduced since it doubles the number of events required on each > >transaction, but if that's what it takes to solve our current problems, > >I'm > >fine with it. However, if we do adopt a four-phase handshake, I'd like to > >just switch over to it rather than introduce it as another option. It > >seems awkward to support two handshake protocols in most if not all > >objects. > > > >I know you've put a lot into this, Andreas, so I don't want to be an > >obstacle, but at the same time I'd like to work out our long-term strategy > >a little before we let such a sweeping change go in. You say this > >"enables > >us to gradually introduce the 4-phase ports as an alternative interface"; > >do you envision us switching over completely to 4-phase? If not, how do > >we > >manage having two different interface protocols? > > > >I'm also interested in what Nate thinks, since he's the one who designed > >the current Port interface originally. > > > >Steve > >_______________________________________________ > >gem5-dev mailing list > >[email protected] > >http://m5sim.org/mailman/listinfo/gem5-dev > > > > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
