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.

TCIEVMK2X: edma3 tci6630k2l

Part Number: TCIEVMK2X

I am confused as how much transfers can happen simultaneously. if one core is using Transfer Controller 0, would another core be able to use it for transfer at the same time?

it was mentioned on the tci6630k2l datasheet that edma3CC_0 has two Transfer controllers and edma3CC_1 and _2 has 4 transfer controllers. so does that mean i could only do 10 simultaneous transfer and a restriction if which ever core is using a transfer controller?

Thank you so much

  • Hello!

    EDMA3 is chip wide peripheral, thus partition between cores is developer responsibility. One cannot run multiple transfers on the same transfer controller simultaneously, though multiple channels available in channel controller, and multiple events can be queued. To my knowledge, there is some resource tracking infrastructure in EDMA LLD, but never used myself. I think other than that, you're right, number of transfer controllers limits number of running transfers, assuming they are targeted all different endpoints. If that's not true, then even between transfer controllers there is priority ranking.

  • Hi,

    For any Keystone I or II devices, including K2L, there can be several EDMA Channel Controllers (CC). Each CC can have dozens (e.g. 16, 64) EDMA channels and several Transfer Controllers (TC) (e.g. 2  or 4). Each TC can be considered as a queue.

    There is an association between EDMA channel to queue. In your K2L example, if the EDMA channel is well spread, you can have up to 10 EDMA transfers in parallel. If several EDMA channels are assigned to the same queue, they will be queued inside EDMA. If all 10 channels are well split among 10 TCs, there are still possible bottleneck in system bus or end point level. You have some technique for performance tuning inside EDMA, see EDMA user guide:

    2.11.4 Performance Considerations

    2.12.1.4 Performance Tuning  

    Regards, Eric

  • I also noticed the that the edma transfers are slower than memcpy() is this common? I created a function to do time snapshots and the edma transfers tend to be faster doing large data transfers.

  • Hi,

    For very small data transfers, it is possible that EDMA is slower than memcpy(). Also, please note most of the time you do the EDMA  transfer, the final consumer or the producer of the data is the CPU. And the data between CPU and EDMA master is not synced, in DSP you need to do cache operation. This also added extra cycles.

    For example, you move data from a peripheral/buffer A into destination B by EDMA, then you want to use DSP CPU to process the data. What you saw in DSP cache is not sync with the real data moved in by EDMA. You need to invalidate the cache, so the DSP reads the data from the real memory (not the cache).

    Regards, Eric

  • i am not sure if i am doing it correctly, i think i have both the source and destination mapped to addresses in the ddrMem

    i have this (for example) for both source and destination

    #pragma DATA_SECTION( x , ".ddrMem")
    #pragma DATA_ALIGN(x,64)
    uint32_t x

    not sure if it is working the way i thought it works(reading directly from memory), from the way i set it up.

    Thank you!

  • i also forgot to mention i am manually triggering the transfer by writing to the event set register. so after i grab my PaRAM set i just trigger the channel that has the set.

  • All looked correct to me.

    Regards, Eric

  • alright, thank you again. will definitely have more questions along the way as i am still just getting familiar with it.