How do I...

[Paolomio]

Hi folks,

I'm not sure it this is exactly an XC question, but it certainly involves XC, so here we are.

I'm developing a system with a few interesting characteristics:
* a linear array of L2's, communicating over 2- and 5-wire links in a daisy chain configuration.
* an unknown array size (until runtime), since the system is highly modular and expandable. This means that the system will need to discover what other processors are attached, and their capabilities. Larger systems could have hundreds of cores.
* A client/server architecture, where some modules will provide services to other client modules (for example, one module has--among other things--external memory, and would provide bulk storage services.
* Ethernet connectivity to the outside universe.

A few questions I can't seem to find guidance on in the documentation (or in searching the xmos site or this forum):
* SInce the configuration of the system will only be known at boot time, how can a given core figure out how to open a channel with a another? Is there a definitive way to determine how to "address" a given core?

* Would it be better to do the setting up, starting, and stopping of channels in assembly, or can this be done in XC? From what I can tell, XC seems to be oriented toward a certain firmware architecture--where all of the code for all cores is in one codebase, and the underlying system boots it on the appropriate cores "under the hood." This doesn't seem quite compatible with the idea of runtime discovery, so I'm confused as to how to implement this.

Any guidance on this would be much appreciated, otherwise I'm afraid my head might explode. That would be a shame on so many levels...

Thanks,

Paul

[Bianco]

A few questions I can't seem to find guidance on in the documentation (or in searching the xmos site or this forum):
* SInce the configuration of the system will only be known at boot time, how can a given core figure out how to open a channel with a another? Is there a definitive way to determine how to "address" a given core?

One possible way is enabling an XMOS link, send a hello token and check if a credit token is received in a certain amount of time. If nothing is received there is no other side. A possible simpler way is to just use a 1-bit IO port to check if there is an other side. All cores start with a default node number which has to be set to a, this can be done by an other processor which sends a message to the switch of the destination node. The switch also has registers to determine the capabilities of the chip (number of cores etc.).

http://www.cs.bris.ac.uk/~dave/cpa.pdf

This presentation explains how routing is implemented in XS1.

* Would it be better to do the setting up, starting, and stopping of channels in assembly, or can this be done in XC? From what I can tell, XC seems to be oriented toward a certain firmware architecture--where all of the code for all cores is in one codebase, and the underlying system boots it on the appropriate cores "under the hood." This doesn't seem quite compatible with the idea of runtime discovery, so I'm confused as to how to implement this.

Any guidance on this would be much appreciated, otherwise I'm afraid my head might explode. That would be a shame on so many levels...

Thanks,

Paul

XC is a high level language, you can't achieve these things with XC only.
Besides that you will be on uncommon ground and most members on this forum do not have experience with these things, don't expect too much help. One needs a very good understanding of the architecture to implement such a system and there are many caveats.

[segher]

A possible simpler way is to just use a 1-bit IO port to check if there is an other side.

You can access the link as I/O ports as well, you don't need a separate port.

XC is a high level language, you can't achieve these things with XC only.

Oh, I'm pretty sure it _can_ be done, but it's a lot simpler to do things like this in
a more down-to-the-metal language like assembler. So yeah, I would avoid XC
for this.

Besides that you will be on uncommon ground and most members on this forum do not have experience with these things, don't expect too much help. One needs a very good understanding of the architecture to implement such a system and there are many caveats.

The good news is that this is much easier (and less work) than initialising most
other modern busses/interconnects! :-)

[Paolomio]

http://www.cs.bris.ac.uk/~dave/cpa.pdf

This presentation explains how routing is implemented in XS1.

XC is a high level language, you can't achieve these things with XC only.
Besides that you will be on uncommon ground and most members on this forum do not have experience with these things, don't expect too much help. One needs a very good understanding of the architecture to implement such a system and there are many caveats.

Thanks for the interesting link...

There obviously many things still to understand, and the docs available require a considerable amount of squinting. I wonder if anyone else is working on or thinking about these sorts of large-array issues? If so, feel free to contact me...

Paul

[Bianco]

A possible simpler way is to just use a 1-bit IO port to check if there is an other side.

You can access the link as I/O ports as well, you don't need a separate port.

That's true, but you possibly don't want a pull-up resistor on one of the lines you use for XMOS Links.
And you don't want either side to drive the line because you don't want both sides to drive the line at the same time (in a unknown configuration case).

[Bianco]

Thanks for the interesting link...

There obviously many things still to understand, and the docs available require a considerable amount of squinting. I wonder if anyone else is working on or thinking about these sorts of large-array issues? If so, feel free to contact me...

Paul

I have plans, but not for the very near future.

[Folknology]

I would like to explore this in the future but would like to master fixed/static topologies first!

Once I master the fixed stuff this will be next on the Radar.

IMHO it would be a good area of research for Xmos themselves, is Xmos working on dynamic/runtime topologies? It would certainly be advantageous to have a standard way of doing this and even ways of interconnecting different systems of topologies, perhaps using topological query and discovery between custom or enumerate system topologies..

Regards
Al

[bsmithyman]

I'm not looking at implementing anything complex at the moment, but I'd certainly welcome a bit of discussion about the low-level implementation issues involved. I think Bianco's right that some of this is more technical than most of us will ever use. However, I feel like (as with many issues that require low-level programming) it's to everyone's benefit to have some well-discussed and common solutions both on the forums and on the wiki.

Since the XLink ports override the normal ports once set up, would it be possible to have a negotiated protocol that shared this information and the configuration details over the standard I/O lines? Once the handshaking is done the XLink could be established on both sides. I may be mistaken, but my impression was that the act of setting up the XLink automatically resets the normal I/O port. This wouldn't allow hotswapping, of course. Or is it impossible to bring up an XLink late in the execution? Maybe I'm crazy :)

[Paolomio]

I Or is it impossible to bring up an XLink late in the execution? Maybe I'm crazy :)

It does seem to be possible. One of the many "features" of this beast I'm working on is that it needs to use 5-bit ports in all directions (each L2 is on a plug-in card with links from the left and the right), and this means to boot from SPI the ports would need to be reprogrammed as links after boot is complete. XMOS was kind enough to verify that this will indeed work...

Paul

[Paolomio]

I would like to explore this in the future but would like to master fixed/static topologies first!

Har! What luxury! I've already committed to do all sorts of things I don't know how to do, or if they'll actually work. In other words, Situation Normal.

IMHO it would be a good area of research for Xmos themselves, is Xmos working on dynamic/runtime topologies? It would certainly be advantageous to have a standard way of doing this and even ways of interconnecting different systems of topologies, perhaps using topological query and discovery between custom or enumerate system topologies..
Al

This is exactly what I will need to do. Xmos may well be working on this, but I have a sinking feeling I'm going to have to figure this out on a more urgent timetable.

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.

Paul