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
