I'm trying to understand exactly how these should be used. Are they
intended to be used entirely internally to an interconnect? i.e. just
within the bus or crossbar or mesh or whatever? I want a source and
destination for my crossbar model, but I don't want to break things.
I'm slightly
Ok, I've read the code a bit more, and it seems clear that dest needs
to be sent by the sender. So this means that the sender needs to know
the topology of the network (or at least the node id) of an object on
the other side? For responses, this makes sense, you want to respond
to the guy who
Yea, Ali's got it right... the way to think about address-based
routing on the bus is that the packet logically does get broadcast to
determine the destination; all our mucking with address ranges is
really just some combination of optimization and sanity check.
As far as the setSrc() calls in
Yea, Ali's got it right... the way to think about address-based
routing on the bus is that the packet logically does get broadcast to
determine the destination; all our mucking with address ranges is
really just some combination of optimization and sanity check.
I buy that, but I'd argue that
On Wed, Nov 5, 2008 at 7:57 PM, nathan binkert [EMAIL PROTECTED] wrote:
Yea, Ali's got it right... the way to think about address-based
routing on the bus is that the packet logically does get broadcast to
determine the destination; all our mucking with address ranges is
really just some
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
I don't have anything constructive to add, but the interrupt stuff I
added to x86 could make use of a real broadcast if that happens.
Gabe
nathan binkert wrote:
However, the question is: when we move to interconnects that decouple
these two things, what entity becomes responsible for mapping
