Streaming channels and "plain" channels

[kean]

Hi everybody,

I am designing my first embedded system based on XMOS (XS1-G4).

I know that one XCore can have up to 4 streaming channels ingoing+outgoing to other XCores and it is allowed to have unlimited channels.

The question is: can I still use "plain" channels when all the 4 available streaming channels have been used?

[lilltroll]

No, you need to save at least one link for "standard" channels.
You can add your own protocol with help of controltokens using for an example 4 streaming channels, to send other data/message in the streaming channels to different cores.

[kean]

Thank you for the reply.

You can add your own protocol with help of controltokens using for an example 4 streaming channels, to send other data/message in the streaming channels to different cores.

Do you mean that with one single streaming channel it is possible to comminicate to more than one thread/XCore? I'll check out the use of control tokens and definition of protocols.

[Bianco]

He means that you can add control tokens in a streaming channel to use this channel for multiple purposes, e.g. you can tell data and control sequences apart by using control tokens in the stream.
This makes that you need less channels. But you will still only be able to communicate with one thread.
Is the bandwidth of regular channels not enough? regular channels are more efficient with larger data objects or using transactions. A transaction is sending multiple data objects in a sequence with only synchronization at the beginning and end of a transaction.

I must say that both streaming channels and transactions are XC concepts. Since this thread is not in the XC section i do not know what languages you are using or plan to use. It is possible with some assembly (maybe there are some useful library functions) to have 4 streaming channels and a few regular channels. One of the streaming channels must send pause tokens once in a while to release the route (the link) so that it can be used by the regular channels. The assembly function has to get a new chanend (at both sides) The chanend id's have to be transmitted over one of the streaming channels. Then both threads set the destination of that chanend to the received chanend id from the other side. After that the setup is completed and one of the streaming chans only has to send pause tokens every now and then.

[kean]

Now it is more clear. But it doesn't help to solve my problem, since I need several communications between different threads. I should probably do as a turnaround the remapping and grouping of my components to different XCores, if possible.

Is the bandwidth of regular channels not enough? regular channels are more efficient with larger data objects or using transactions. A transaction is sending multiple data objects in a sequence with only synchronization at the beginning and end of a transaction.

No :( the latency of 100ns implied by the use of channels is way to much for my needs.

[Bianco]

Can you perhaps tell a little bit more about your application and why you need a less than 100ns latency?
There is at least one other solution, but it is more complicated.

[kean]

It is an ethernet switch that supports a quite complex real-time protocol (PROFINET). The idea of my design is having several threads performing a little specialized operation, like a "pipeline" and data is transferred between threads using streaming channels.
In my case I would like to have for example a cut-through forwarding as fast as possible. Using channels I would potentially delay the forwarding of 100ns for each "step"/operation that has to be performed on the received frame. If there is really no other solution I could maybe accept it, but for the moment I aim at doing something better.

[Bianco]

Well if you need 4 channels that transport low latency data to other cores there is no solution where you can use the streaming channels with other channels because they would degrade the performance of your streaming channels (there are only 4 links to the switch).

[kean]

I see. What about the other more complex solution that you were talking about? Maybe I could use it as alternative or in less critical links.

[Bianco]

That won't work for data streams.. only for poking other threads to notify it of an event with low latency using less channels than n threads. It involves setting up a dedicated network for these chanends that cannot be disturbed by the regular channels. In other words it would reserve uplinks for some chanends. It is in the end only usable if you have 2-3 or more regular channels, otherwise there would always be an uplink free for sending events within the deadline (say 20ns or so)