How do I...

[bsmithyman]

The fundamental thing I don't get yet is how is any particular core ("tile"?) identified so it is addressable by other cores. I suspect this is something buried in the switch routing table, or something you have to put into the routing table, but it's all opaque and fuzzy at this point. It seems you can configure links, open and close channels, and so on programmatically, but the underlying documentation hasn't passed in front of these eyeballs yet. It may be there...I just haven't found it.

This is touched on briefly on page 2 of the XS1 Architecture document:

Messages are routed through the links using a message header which contains the number of the destination chip, the number of the destination processor and the number of a destination channel within the processor. These can be encoded using either 24 bits (8 bit chip address, 8 bit processor address, 8 bit channel address) or 8 bits (1 bit chip address, 2 bit processor address, 5 bit channel address).

Exactly how that gets assigned, I'm not sure. I would imagine it's one of the incompatibilities between G- and L-series links (though from context, the implication is that the actual addressing scheme above applies to both).

[Paolomio]

This is touched on briefly on page 2 of the XS1 Architecture document:
...

Exactly how that gets assigned, I'm not sure. I would imagine it's one of the incompatibilities between G- and L-series links (though from context, the implication is that the actual addressing scheme above applies to both).

The key word here is "briefly"...I have seen this, and it is a description of what it is, but not how to use it. For example, is there any documentation on the switch registers, their format and address procedure? It's clear that what I need to do can be done. The question is how.

My understanding of the incompatibility between G-links and L-links is that L-links require the use of HELLO and G-links do not support this protocol. But I haven't dug too deeply into this, since I lost interest when I found they were not compatible, and there wasn't a viable workaround.

Paul

[segher]

The fundamental thing I don't get yet is how is any particular core ("tile"?) identified so it is addressable by other cores.

Register 5 in the sswitch of each node (not core) is the node id.

If you want to plug two existing networks together, they need to:
a) Decide which of the two sides is going to be master for this network
reconfiguration;
b) Figure out if they already _are_ one network;
c) If not, one side needs to renumber its nodes so they don't overlap
with the other side;
d) Enable links, set up routing.

If you only want to add single, not-yet-connected boards, it is easier:
(more detailed description, it's a lot less work really ;-) ):
-- The new board initialises its node it to 0 (or any other particular value);
-- Both sides enable the link;
-- The "accepting" side sets up its routing table so it can access the new
board, at that particular node id;
-- Now the "accepting" side can write to the "new" sswitch, set the node id
it wants, set the routing tables; and update all routing tables in the "old"
network to make the new board reachable.

[I haven't yet done this with xmos chips, mind -- there might well be
mistakes/oversights/terrible errors/dragons].

[bsmithyman]

My understanding of the incompatibility between G-links and L-links is that L-links require the use of HELLO and G-links do not support this protocol. But I haven't dug too deeply into this, since I lost interest when I found they were not compatible, and there wasn't a viable workaround.

Paul

My understanding was that the G-series chips could only be connected in hypercube configurations; that they needed 2^n nodes. Not sure where I picked that up from though.

[Paolomio]

The fundamental thing I don't get yet is how is any particular core ("tile"?) identified so it is addressable by other cores.

Register 5 in the sswitch of each node (not core) is the node id.
...

In this system, discovery will be done once during boot, so the network configuration will not already exist. I don't currently intend to support hot-plugging, but what you describe would support that, and this system will allow expansion via externally connected 2-wire xlinks, so that's probably a future feature to support.

BTW, are these registers documented somewhere?

Thanks!

Paul

[Jamie]

My understanding was that the G-series chips could only be connected in hypercube configurations; that they needed 2^n nodes. Not sure where I picked that up from though.

The routing is called dimension-order and can route on any n-dimensional array, i.e. arrays, meshes, tori and hypercubes.

BTW, are these registers documented somewhere?

I think it's all in the system specification document.

[Bianco]

My understanding was that the G-series chips could only be connected in hypercube configurations; that they needed 2^n nodes. Not sure where I picked that up from though.

The routing is called dimension-order and can route on any n-dimensional array, i.e. arrays, meshes, tori and hypercubes.

That's not correct for the G series, it only supports hypercubes in 2^n.

[Jamie]

That's not correct for the G series, it only supports hypercubes in 2^n.

Where's that specified?

[Bianco]

That's not correct for the G series, it only supports hypercubes in 2^n.

Where's that specified?

"All XS1-G link networks must be N-dimensional hypercubes"

http://www.xmos.com//system/files/xs1-g-links-1v2.pdf 6.3

[Jamie]

"All XS1-G link networks must be N-dimensional hypercubes"

http://www.xmos.com//system/files/xs1-g-links-1v2.pdf 6.3

Fair enough, I hadn't seen that. It seems to me to disagree with what's said in the XS1-G spec though!

Edit: just to clarify, there was a problem with the implementation with the G4 switch which means the routing is restricted. It is still possible though to build structures such as the pipeline as explained in the G-system spec, although somewhat indirectly.