• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 755 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

EDMA/EVE: Process 32kB of data with single Transfer Event

Tobias Schulze
Intellectual 900 points


Hello Everyone,

I'm implementing an EVE/VCOP application, where EDMA copies 32kB of data from external DDR memory into internal VCOP buffer and vice versa. I used evelib_fir_filter_2d_test / edma_utils_autoincrement as a reference. I want to set up all EDMA params (SRC/DST addresses, ACNT, BCNT etc.) before the actual transfer and then just submit trigger events to the DMA, so that it transfers the data and sets the next memory indices etc. automatically.

Now I faced a problem with EDMA PaRAMs: When I transfer 32kB (=32768 byte) of data (e.g. AB sync mode, ACNT=4, BCNT=8192), the address of next memory block should be 32kB after the initial buffer address. This offset can be set up via SRCCIDX param. However this param just supports values from -32768 to 32767 (not 32768 as needed). Does that mean EDMA can't process 32kB of data with one single transfer event? Do I have to split up the buffers and trigger the EDMA multiple times? Or is there some kind of trick I could use?

Regards

Tobias

  • 0
    TI__Guru 56820 points
    Hi Tobias,
    The SRCCIDX are 16 bit signed so you cannot provide jump of more than 32767. One way could be if your processing can work on two independent blocks then you can setup 2 DMA each doing 16KB of DMA where one DMA is in the first half of the image and the other DMA is in second half of the image. But all this will depend on your processing. Can you explain us more in detail about what you want to do in terms of processing, then we can provide some other alternative.

    Regards,
    Anshu
  • 0 in reply to Anshu Jain
    Intellectual 900 points

    Hello Anshu,

    I want to create an application for combining video frames from a camera. It takes two 16-bit values from an buffer (two pixels of that frame), merges them with VCOP (shifting and OR'ing) and writes the new 32 bit values to the same buffer. I already made an E2E post about this app:

    https://e2e.ti.com/support/arm/automotive_processors/f/1021/p/665039/2472272#pi320098=1

    I'm using a single 32kB VCOP buffer (IBUFL & IBUFH combined) and VCOP processes 32kB of data before DMA loads new data into its buffer. The EDMA program is based on FIR Filter 2D Non BAM example, but is modified to write 32kB of data in a 1D way (sequentially) instead of block based 2D writing of the example. The main goal of my modification is to shorten execution time of the app: using biggest buffers, using DMA as little as possible and set DMA up only once per frame (and not "waste" time programming buffer offsets etc. manually every 32kB via ARP32).

    Regards,

    Tobias

  • 0 in reply to Tobias Schulze
    TI__Guru 56820 points
    Hi Tobias,
    To me this operation looks like it can independently be applied on two sets of data. So what you can do is to configure 2 DMA channels one which is working on first half of the image and second which is working on the second half of the image. So each transfer will only be of 16KB and you will not face the issue which you described earlier.

    Regards,
    Anshu
  • 0 in reply to Anshu Jain
    TI__Guru 56820 points
    Hi Tobias,
    Were you able to make progress on this issue? If yes please mark this thread as resolved and if not then let us know.

    Regards,
    Anshu
  • 0 in reply to Anshu Jain
    Intellectual 900 points
    Hey Anschu,

    we decided to go back to 16 kB transfers and seperate input and output buffers on VCOP (BUFH and BUFL). This way we even get a faster processing time than by using a single 32 kB buffer, because in the latter we cannot utilize parallel processing of input and output writings of EDMA (input writes have to wait for output writes to be completed).

    Regards,
    Tobias
  • 0 in reply to Tobias Schulze
    TI__Guru 56820 points

    Hi Tobias,

        This means your processing is data bound and not compute bound and hence DMA is actually coming in foreground.


    Regards,

    Anshu