Hi everyone, Brad and I chatted about this a bit and it seems like a phone meeting or something like that is in order. I hope we didn't miss the window of your being in the US, Andreas. What times work for you? Nate, do you have any time to participate?
Thanks, Steve On Fri, Aug 24, 2012 at 11:22 AM, Andreas Hansson <[email protected]>wrote: > Hi Steve (and everyone else), > > Thanks for your e-mail. I've been travelling and I am still catching up on > e-mails...and patch rebasing :) > > I would really like to see this moving forward as we have all the 4-phase > patches stacking up behind it. When it comes to smaller changes vs bigger > changes we are looking at some 10-15 patches for the introduction of the > 4-phase handshakes. Essentially we start from the peripherals and work our > way up, then from the CPU and work our way down, all until it hits the bus > in the middle. For this to work we need both the classic and 4-phase to be > present. I think it would be very desirable to at least keep it during this > phase, and if there is no need afterwards I can make things simpler again. > > For the uses beyond the classic memory system, it would be great to hear > what the Ruby-experts out there have to say. I would think that Ruby > internally would use something different than the 4-phase, and that we > stick to that around the edges. Any input on this one? > > The next two weeks I'll be in the US so from a time-zone point of view a > skype call or similar would be easier. > > Have a nice weekend everyone. > > Andreas > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Steve Reinhardt > Sent: 13 August 2012 21:05 > To: gem5 Developer List > Subject: Re: [gem5-dev] ports, interfaces, and protocols > > 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 > > > -- 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
