Channel pause on streaming channel

[bearcat]

I noticed that sending a pause from soutct is saying it's depreciated in 11.11.1. The newer documentation says it's not supported to send a pause.

Is there a different built-in or something to do this?

[sethu_jangala]

Hi,

For transmission, a channel opens a route over network to send tokens and data. A normal channel closes the route over the network after sending data to free up resources whereas a streaming channel keeps the route open for future transmissions. Therefore, a normal channel acts as a packet switched network while Streaming channel acts as circuit switched network. A streaming channel will not have the overhead of synchronization tokens during transmission. If you wan to send your data as packets, it is recommended to use normal channels instead of streaming channels. So, the latest tools does not support passing the tokens using channels.

Sethu.

[segher]

So you are saying a useful feature was removed simply
because not many people use it? I hope that isn't the
full story!

[Ross]

I think the issue is that if you declare the channel as streaming the tools make certain assumptions - if you start sending END and PAUSE tokens you are going to invalid these assumptions (since routes will be shut down).

AFAIK there is no reason why you cannot simply declare the channel without the "streaming" qualifier and construct your own communication protocol using the functions provided (outct, outuint, chkct, inuint etc...).

Of course there should be a health warning attached to this since you ideally need to know what you are doing...

[bearcat]

Streaming channels are significantly faster, and they allow using the port buffer to your advantage. You can buffer 4 32bit words to send, before blocking. Which allows you to then start receiving at the same time, instead of being blocked. Maybe for an internal XLINK, this may be fast enough, but between 2 tiles with a slower link, this will significantly slow down the comms.

In my case, if I don't pause the channel and perform a "ping" between tiles, boot up doesn't work. It appears the code gets loaded on the higher tiles and started, prior to the lower tiles, and the boot gets blocked with the streaming channel (my guess). I tried using delays to start the streaming channel, but that wasn't reliable. Once started, my application does not pause or end the streaming channel, it's only for boot up.

Normal channels are not fast enough in my application. Giving up on streaming channels does seem like a step in the wrong direction.

[Ross]

Yes streaming channels have their advantages. However, by sending PAUSE and END tokens you are packetising things and closing the route - so not a true streaming channel.

The tools cannot error/warn regarding exceeding the number of routes between tiles - since you are changing it at run-time. This is therefore a "discouraged" usage.

It sounds like you are into the territory of advanced usage. As I said, if you want to avoid the warnings, I would suggest declaring the channels as standard channels and using the outuint()/inuint() functions - essentially creating your own packetised channel comms.

outuint(chanend c, unsigned x) is the same as a c <: x on streaming chanend c i.e. one OUT instruction..

It's worth mentioning that no functionality has been removed in the tools thus far - your current usage is currently just discouraged. There is some argument whether this should be deprecated or simply a warning.

[segher]

Sending on a "closed route" streaming channel is almost
the same latency as on one with an open route -- if the
resources are available of course ;-) Sending on a
"normal" (handshaken) channel has awful latency. It
sounds like bearcat wants the route closed during some
bootup thing (I didn't quite follow), which is exactly what
PAUSE is _for_! And yes, advanced use, sure. You could
always just throw in some

Code: Select all

asm("outct res[%0],3" : : "r"(c));

or hey, hide that behind an inline or macro, you could
call it "soutct" perhaps...

[segher]

Ross: It seems you are saying that if you want to do things
just a little bit different than XC normally does, you should
give up on XC completely and use the C-style interfaces?

I think I am hearing wrong.

[bearcat]

This was only a question, really. I can use inline assembly to get around the error, at least for now, if I want to.

My application never needs to close the channel, so I am using it as a streaming channel should.

The problem I have ran into, is the system won't boot with a streaming channel being the only XLINK between the two tiles. If the channel starts before the boot (or maybe more correctly all the par tasks in main have started, and not the actual boot) is complete, then the system blocks. The pause and ping has solved that issue.

Thanks for the replies.

[Ross]

Ross: It seems you are saying that if you want to do things
just a little bit different than XC normally does, you should
give up on XC completely and use the C-style interfaces?

I think I am hearing wrong.

In a way, yes. If you declare a channel as streaming the tools are going to assume (and check) that that there are enough free routes and try and look after you. You are invalidating these checks by sending PAUSE/END tokens - this is the reasoning behind the warning/deprecation.

As I said, this is likely to be changed to a standard warning (with a reasonable explanation I assume) rather than a deprecation warning.

Using inline asm is just going to bypass these checks, so using soutct() etc is preferable in my opinion.