RTDX Speed on the C6713 DSK

Bendous,

Bendous said:

Can anyone please tell me what the maximum data rate for the RTDX is? I can't find it anywhere and no one has been able to give me an exact figure. I have tried talking the IT helpline but in vain!!!

I recall below the offline discussion made so far on this :

>>> Dear sir/madam, I am using the C6713 DSK along with the ADS8364M EVM to acquire an analogue signal and save it into a database on the computer. The current sampling rate is around 180KHz. I am using the RTDX function of the DSP to transfer the data to the host PC, where it is read and visualised by Matlab.  -   The problem I am facing is that the RTDX data rate I am seeing is around 7KSPS (with the sample being 16bits). Is this the maximum throughput of the RTDX?

The primary JTAG RTDX speed differences are related to the TCLK rate difference between the XDS510 [10 Mhz] and the XDS560 [variable depending on the target device and specific board design – up to 30-34 Mhz on the C671x DSK]. 

Average speed for "normal" RTDX would be up to 40 Kbytes/sec max

Some "empirical" measurements on RTDX I recall from the past, which were performed on test configurations, showed for example an *average* of 3~ ms time for transmitting 4 words host-to target and 16 words back target-to-host in a loop; however I do not have any indicators on how much this would scale down when sending back and forth just one word, or a bigger buffer, although the curves might indicate that this figure is approaching a lower bound (the performance curve tends to get flat on small transfers). Also, it would depend on the amount of activities done in the CPU application code, as these will be done concurrently with RTDX operations

Note however that your system will be influenced also by:

- the memory placement of the code / data sections. This is the same topic for any application code; having the code / data in external memory without the region marked as cacheable (via the MAR registers) and / or without L2 cache configured will slow down the performance. So at the system level, check that the rtdx segments are placed into an internal memory segment (.rtdx_text, .rtdx_data, check the BIOS  configuration settings) so that you avoid cycle overhead due to caching issues on the target

See spru609b, C671x memory architecture user guide and spru656a, C6x cache user guide, for more details on this

- the overall throughput of your system, i.e. the throughput of the EDMA chain before the data lands in the application layer buffers, see

http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=spraa02

- note that there are some application notes that describe the environment and how to setup the system, please see first application note

DSP/BIOS, RTDX and Host Target Communications - spra895

This nice article : How to synchronize the COM client and the DSP application

http://www-k.ext.ti.com/SRVS/CGI-BIN/WEBCGI.EXE/,/?St=48,E=0000000000004759650,K=6109,Sxi=0,Case=obj(9637)

contains source code for a complete RTDX application that does both reading and writing from an RTDX client application, I believe it could help you a bit in writing the software.

Also, within the RTDX tutorial, lesson S2L6 (Receiving Data From Multiple Channels) discusses using multiple channels.

Eventually also these documents might help you in a later stage:

How to Write an RTDX Host Application Using MATLAB - spra386

spra821 how to use high speed rtdx effectively

How to Optimize Your Target Application for RTDX Throughput - spra872a

this latter will be especially of interest in your case, and note spra821 mentions as well  HS-RTDX being supported on the C6x1x targets, and the requirement for an XDS560 emulator

- Regarding throughput, I believe since there should be buffering done in the RTDX channel, the values could be accumulated on the target side until an RTDX interrupt occurs, thus forcing the blocked items to be released. So in this case I assume the buffer size could also play a role. I am not sure if in the RTDX implementation a full buffer is always transferred, or just the amount of data that has been written in the buffer (I would tend to the second case)

- I believe the default rate at which the RTDX buffers are drained could be in the range of  one every 500 usec, using internally four buffers, but this is likely implementation dependant so I am not sure if this is the case on the latest releases (this information is based on RTDX app notes which are a bit outdated)

I read somewhere that some of the newer boards use the Hi-Speed RTDX (up to 2Mbyte/s transfer rate). Can you give me a list of DSKs with this functionality and give me an idea of how different they are from the C6713DSK (i.e. how difficult is it to migrate the code from C6713DSk to one of the newer boards?). I appreciate your help in this matter and hope to hear back from you very soon.

Not sure where you got this information but HS-RTDX support is not related to the boards, rather to the silicon device capabilities

The C671x supports HS-RTDX, but you will need an XDS560 class emulator to have it enabled.

The on-board DSK emulator is an XDS510 class, which does *not* support HS-RTDX, so an external emulator is needed

(for your information,  in general also all 64x and 64+ devices support HS-RTDX, with exception of the C672x)

Of course devices that support HS-RTDX support also "normal" (non high-speed) RTDX

Note that for HS-RTDX also EMU0/1 signals, which are used for HS-RTDX will be required - these are routed on the DSK Jtag emulator connector

To add on this,

RTDX would be the best way to exchange data since it is real time (it does not disable interrupts within the code itself, and is serviced by the DSP as any other interrupt routine defined on the target, so it does not block the code)

Other ways like "probe points" in CCS will stop the application flow during the data transfer, so they are not suited very well for a real time system

I would recommend trying the suggestions given on your application configuration, in order to try to increase a bit the RTDX throughput you are getting.

The above suggestions should be helpful to point you in the right direction.