Thread doesn't start due to XLINK?

[bearcat]

This is a little complex, so bear with me.
2 L1's.
Single XLINK between them.
Master core has 5 threads running fine and using a few channels between threads.
Slave core currently has a single thread running that communicates to one master thread constantly using a single channel. No problems with this.

When I try to par another thread on the slave it never starts.

I am thinking the following:
1 - The master core is the one to startup a thread, and it can't because the XLINK is allocated?? Even though the PAR is in code on the slave??
2 - I tried sending a XS1_CT_END from the slave back to the master every 2 sends and receives, the master discards it. Thread still doesn't start.
3 - If the first thread is commented out, the second starts just fine, so probably not a code issue.
4 - I tried sending some control tokens back and forth between threads to wait for the second one to start, and that would be very complex to work out. That didn't work either.

On the slave core, is it limited to a single channel between threads on that core??
Does a thread need to exit for the channel to be free??

Any ideas?

[bearcat]

After more thought, I remembered a little more about using control tokens between slave threads (holding off the first thread's channel to the master till the second thread starts). This actually did work. Both threads did start, but the threads ended up locking due to channel blocks. They start and stop a couple times and would be tricky to do this to handle every case (I think). Also, there are going to be at least four more threads in this project and this would mean ALL threads have to start at the same time (doable probably).

So, it looks like multiple channels on the slave core is ok. It also would appear that a thread has to end to free up the XLINK?? How do I free the XLINK to allow another thread to start without ending a thread (or stopping communications)?

I will see if the control tokens back and forth is a little more robust than I attempted the first time, but will be complex with 4-5 threads.

[Woody]

All communications between the master and slave XCores will pass down the link. This will work fine so long as data is always sent as a packet. When a packet ends (EOP or PAUSE control token) the link then becomes available for other packets to use, and there is an arbitration process for that.

So you will have a problem if you use a streaming channel, or if you have a non-streaming channel, but delay sending the EOP after sending the first token down the link.

[bearcat]

Woody can you elaborate a little more. I am using the outuint builtin to send data. I need to send two words up and down at a time, up to 200K per second. I had tried sending a XS1_CT_PAUSE instead of the XS1_CT_END above from the master inbetween the two words up and down, but that didn't work either. The channel is not defined as streaming.

So do I need to send a XS1_CT_PAUSE after every outuint on both master and slave, or just one of the master or slave (I am wondering if this extra packet will cause problems with a FIFO full delay)? Or send the pause after every 2 words, for example, but from both sides? Is the pause the XS1_CT_PAUSE token?

The exact FIFO size is not specified that I could find. But I believe in my testing it holds 2 outuints before it blocks. An extra control word is probably fine in my case as the XLINK is only running at around 20% utilization, as long as the FIFO doesn't fill. I assume building up the channel and pausing it will not fill up the XLINK.

[bearcat]

As a follow up. I think I am good on this item.

Using control tokens to wait for a thread to start appears robust and architectually works for my application. So far has worked fine. The first time I was not taking the control token off the channel in one thread.

[Woody]

Sorry for not responding sooner. I'm glad that you have solved the problem.

Non-streaming channels perform synchronization between the two ends of the channel at the start of each packet. This involves sending some packets in both directions. If the link is blocked in either direction when this synchronization is attempted, then the synchronization will not complete and the threads may will block.

However if streaming channels are used, then there is no synchronization, and the transfers should be successful in one direction, even if the link is blocked in the other.

I'm not sure if this really explains your exact situation, but glad you solved it anyway.