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?
Channel pause on streaming channel
-
- Respected Member
- Posts: 283
- Joined: Fri Mar 19, 2010 4:49 am
-
- XCore Expert
- Posts: 589
- Joined: Wed Feb 29, 2012 10:03 am
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.
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.
-
- XCore Expert
- Posts: 844
- Joined: Sun Jul 11, 2010 1:31 am
So you are saying a useful feature was removed simply
because not many people use it? I hope that isn't the
full story!
because not many people use it? I hope that isn't the
full story!
-
- XCore Expert
- Posts: 968
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
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...
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...
-
- Respected Member
- Posts: 283
- Joined: Fri Mar 19, 2010 4:49 am
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.
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.
-
- XCore Expert
- Posts: 968
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
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.
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.
-
- XCore Expert
- Posts: 844
- Joined: Sun Jul 11, 2010 1:31 am
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
or hey, hide that behind an inline or macro, you could
call it "soutct" perhaps...
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));
call it "soutct" perhaps...
-
- XCore Expert
- Posts: 844
- Joined: Sun Jul 11, 2010 1:31 am
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.
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.
-
- Respected Member
- Posts: 283
- Joined: Fri Mar 19, 2010 4:49 am
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.
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.
-
- XCore Expert
- Posts: 968
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
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.segher wrote: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.
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.