> However, the question is: when we move to interconnects that decouple > these two things, what entity becomes responsible for mapping > addresses to destinations? There must be some logic or a routing > table that uses the address to generate a destination ID. Without > having given it a ton of thought, I'd argue that that function should > not be part of the interconnect itself; it's going to be tied in to > some extent with the coherence protocol, and may be something we want > to specify as part of the configuration. If you buy this, then at the > level of the interconnect, there should only be two options: broadcast > or a specific destination. So the interface is fine. That makes sense and I feel now that we've had this discussion before. I guess my problem is that I'm trying to build a multi-hop network, so the meaning of src and dest get confusing. I was trying to use them as a port id on a router, but I guess that they have to mean the node ids at the edge of the network. I'll need to record routing information in the senderState variable I guess.
I understand the point you have about the coherence protocol needing to control the routing since a three-hop protocol would be impossible otherwise. Hopefully having SLICC will make this whole thing less confusing since it will be autogenerated or something. > Another way to look at this is to declare that it's already the case > that all routing (i.e., mapping of addresses to interconnect > destinations) must be done outside the interconnect. It's just an > anomaly of a bus interconnect that "* -> Broadcast" is a valid routing > function. Understood. We really need a better mechanism for doing this stuff. Putting in a different network with different coherence is too much of a mess. Nate _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
