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.

Serial Rapid I/O: Request for example code for bulk data transfers >4kiB (EVM6474)

Other Parts Discussed in Thread: TMS320C6474

With the EVM6474 kit some examples for SRIO transfers are delivered.
All the examples support only transfer sizes of up to 4096 byte (with origin in internal memory).

Are there any Serial Rapid I/O examples for transferring more than 4096 byte, let's say some MegaByte with source and destination in external DDR memory?

I've already search the whole TI support documents and the web, but no success. [:S]

  • Dieter Landl,

    Hopefully, someone will have some ready-to-use examples for you. Like you, I did not find any in my search.

    The examples limit the size to 4096 since that is the limit for a single load of a single LSU. Anything more than that becomes more system dependent, and the same is true for moving to external memory. Issues like cache coherency come to mind, as well as interaction with other C6474 masters vying for the same resource. All of these issues can be handled, but we avoid those by making the example simple while still showing how to use the SRIO peripheral.

    If you turn off caching for the DDR region you are interested in accessing, your early testing may be a little easier.

    Without looking at the exact same example code you are, my advice below will have to be vague, but it should be clear enough since you seem to understand what is going on in the examples already.

    If you change the source and destination addresses in the example you are using now, the SRIO will very easily pick up data from DDR and send it to DDR.

    Then, if you just repeatedly call the same function in the example using incrementing addresses and a decrementing count, you will get a very clean transmission of your large block of data. This means the flow for every 4096B block will be WRITE/DOORBELL/Completion interrupt on the transmit side and Doorbell interrupt on the receive side. Then repeat. I call this clean because it will have positive feedback on both sides that something has happened for every 4096B block.

    Like we say in our training classes for every aspect of DSP development, if that meets your performance requirements for data transfer speeds, great! You are done.

    But if you need higher efficiency out of your transfers, you will want to design an EDMA sequence to send the configuration commands to an LSU, wait for the RIOINT to signal completion, then let that RIOINT trigger the next DMA with the next set of addresses to the same LSU. When the whole sequence is complete, you will likely still want to send a Doorbell to let the receive side know you are done. This will save the time for all the extra Doorbells, save the DSP from having to service the LSU to keep it running, and should greatly improve your SRIO utilization efficiency.

    If *that* is still not enough, you may consider using both SRIO lanes simultaneously to double your external bandwidth, but remember that the DDR only supports an absolute maximum of 2.6Gbps at 333/667MHz so you could never hit the 2x2.5=5.0Gbps absolute maximum for 2 SRIO lanes. Using 2 lanes would require keeping track of how well synchronized they are at the end, in case one lane had more retries (if any) than the other.

    To improve the single lane or 2 lane implementation, you could use multiple LSUs to keep one ready behind the currently active one all the time. This is also more design overhead for you, but that is what makes your implementation better than the others.

    I hope this wordy answer is helpful, even though I have not fulfilled your request for more robust examples.

    Good luck, and thanks for using the TI E2E Community Forum.

    Regards,
    RandyP

  • I wondered whether the SRIO can transmit data in DDR directly or store the received data to DDR directly! From page 20 of the SRIO user guide,  the SRIO packets are transferred to L2 memory! So if  a large amount of data needed to be  transferred, I think an EDMA transfer between L2 and  DDR may be required, is that correct?

  • Yes, I wondered too.

    But actually I've rewritten the example code. Now buffers from external memory of DSP-A are transfered to external memory of DSP-B by means of LSU-transfers and without any extra EDMA coding (i.e. all necessary EDMA is done by SRIO!).

    As the first reply shows, just change the source and destination addresses of the LSU-transfers to refer the buffers in external memory - and it works.

    Further its true, that large buffers (>4kiB) have to be transfered by multiple LSU-transfers each up to 4kiB.

    As measured on a C6474 EVM board, the maximum transfer rate of a single 1x-SRIO lane by using 4 LSU-channels fired concurrently, not using interrupts (DSP is waiting for completion in a loop, no doorbells) and no error recovery is appr. 273 MiB/s; using transmit completion interrupts (DSP is waiting for a SEM set by ISR) and minimal error detection on transmit side, no doorbells the max. transfer rate is appr. 230 MiB/s (all measurements done running under DSP-BIOS).

     

  • Thanks, I'll try as your instructions!

  • Hi, Dieter,

    Could you tell me how to determine the maximum transfer rate for a single 1x-SRIO ?

  • Please check out the "TMS320C6474 Module Throughput Application Report" spraaw5.

    You can find this and other very helpful App Notes and User Guides from www.ti.com . Do a search on C6474 and select the Product Folder, then click on Technical Documents to quickly get down to the documents list.

    SPRAAW5 has throughput measurements for SRIO and other peripherals and paths in the C6474. You should find it quite useful.

  • I mean, how to set up the transfer to get the max transfer rate, eg,....273 MiB/s and 230 MiB/s. where can I check the rate? 

  • The CSL that is provided with the C6474 has an example for transferring data using DirectIO mode with one of the LSUs.

    The conversations above in this thread provide additional information that may be helpful for doing what your system requires.

    If you want the exact code that was referenced above, you may need to contact the author directly or by addressing him directly in your posting, so people like me do not answer instead. Or you can click on his name or avatar to look for more contact information.