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
