This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SRIO seemingly drops type 11 packages.

Hi

I’m having problems getting type 11 srio messages to work. First a couple of words about my setup:

I have a custom board equipped with two C6678s. The two DSPs are connected with one SRIO lane (lane 0 - the other three SRIO lanes are connected to a FPGA.)

Now I try to send messages from one DSP to the other (eventually the FPGA will do the sending, but for now I’m using one DSP to simulate traffic.)

I have modified the PDK SRIO example SRIOMulticoreLoopback to send messages between the cores – only one core is active on each DSP.

I also mark each message with a sequence number in order to be able to detect if all messages arrive.

If I send a single or a few message this works, but if I try to send more messages they seemingly don’t reach the destination although I cannot detect this on the sending side (srio_sockSend returns 0 and nothing appears in the garbage queues)

E.g., when sending a total of 200 messages the sending side detects no error, but the receiving side gets message no 8 when it expects number 6.

If I put a slight delay after the srio_sockSend call, i.e.

volatile int k;

for(k=0; k<150; k++) {}

all messages are received correctly.

 

I suspect that the error is on the receiving side as the sending side doesn’t detect any errors, but obviously I might be wrong about this.

 

Does anyone have any ideas about how to solve or debug this?

 

Regards

  • Hi,

    I might be a little late on answering this one, but better late than never. I had an issue which sounds similar to yours and a possible work around. 

    I was experiencing dropped packets due to the fact that I was sending the packets to DSP faster than any one core could receive them. Most of the TI SRIO examples use 4 separate receive queues because they know it takes time to update a queue when receiving a message. By having multiple queues to receive, additional SRIO messages can be accepted while other queues are updating. 

    Unfortunately even with the 4 receive queues, I was still able to send messages faster then they could update. I have experienced this less with larger message sizes (4KB), due to the fact that they require more packets and therefore higher latency between messages. The increased time between messages allows for the receive queues to update in time. The only other option that I have found is to ensure that you "pace" how often you send the messages. Hence the "pacing" metric in the SRIO throughput example. It's not an ideal solution, but it works. Another solution could be to send to multiple cores that each could have their own receive queues. Allowing for more time for each of the receive queues to update.

    -Dan