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.

VP FIFO overrun, blocked EDMA transfer?

Hi,

my application uses a DM647 on a PCI card. Data is captured on DM647s Videoport (8bit raw). The captured data (testcase: 640x480 byte at 72MHz from FPGA) is forwarded over the PCI interface into the PCs memory (while data arrives from the Videoport). In a testcase Videoport 0.A is used:

FPGA.port1 -> 72MHz -> VP0.A -> EDMA -> DDR
                                        DDR -> EDMA -> PCI -> PC

The FPGA generates 480 times 640 bytes of data (+8 hblanks). An A-synchronized EDMA transfer is used to move this from the VP into DDR-memory (FIFO Threshold: 640). A TSK polls the EDMA paRam to know 'how far incoming data has been captured'. If there is already new data (checked once every ms), the new block is forwarded over PCI (using an EDMA transfer into the PCIs address window).

As soon as the EDMA->PCI transfer starts, there are several COVR-Interrupts (Capture FIFO overrun). A FIFO overrun (raw fifo size 2560 byte) occurs at 72MHz after about 35us.

The DDR setup seems to be correct. Copying a 256k block from ISRAM to DDR takes 280µs which results in a transfer rate of about 940MB/s. The EDMA transfer into the PCI address window can be quite big - according to this post (http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/p/52779/186870.aspx#186870) this should be ok.

How do I guarantee that the EDMA transfer DDR->PCI does not block the EDMA VP->DDR transfer (in the testcase "for more than 35us")?

bye,

Thomas

  • another question:

    I use DVSDK EDMA LL Driver 1.05.00. EDMA3_DRV_requestChannel() is used to request a channel for both transfers. The EDMA3_DRV_requestChannel call for VP->DDR transfer gets CSL_EDMA3_CHA_VP0EVTYA for both pLCh and pTcc. The EDMA3_DRV_requestChannel call for the DDR->PCI transfer gets EDMA3_DRV_DMA_CHANNEL_ANY at pLCh and EDMA3_DRV_TCC_ANY at pTcc.

    I dont understand the role of the EDMA TransferController that is mentioned in some parts of the EDMA documentation. I thought that maybe I need to use a different transfer controller for moving Data from VP to DDR and from DDR to PCI. How can I select which TransferController should be used?

  • Thomas,

     

    Please check out this app note on DM648/7 Architecture and Throughput:

     

    http://focus.ti.com/lit/an/spraaz9/spraaz9.pdf

    You should ensure that the VP->DDR transfer is on a different EDMA queue/transfer-controller than the DDR->PCI transfer.  Also, make sure to make the change the queue/TC used by the VP->DDR transers to be of a higher priority than the queue used fro the DDR->PCI transfers.  Since the DDR->PCI transfer is more of a bulk transfer, consider placing it in TC2 or TC3, while placing the VP->DDR tranfers in queue TC0 or TC1.  To improve DDR performance, also ensure that the DDR BPRIO register is set to lower then 0xFF (0x20 is a typical value).

    For details on how to use the EDMA LLD, please check out the PDF training in the Abstract secition of this Wiki page:

    http://processors.wiki.ti.com/index.php/Programming_the_EDMA3_using_the_Low-Level_Driver_%28LLD%29

    Regards,

    Brad

  • Thanks Brad,

    well... the information that the EDMA Queue is directly linked to a TransferController (and that you select a TransferController through selecting an event queue) is really hidden in the documentation. But at least it is there in this workshop pdf you mentioned... Before I searched quite a while for a way to select the Transfer Controller (which is not directly possible). Its also a little bit bad that most times "TC" is used in the docs which makes it difficult to search for it in the hundreds of pages of pdf that are available... I think that the EDMA3_DRV_requestChannel doc could be improved a lot if there was a hint that evtQueue selects the TransferController.

    The first test looks good - before I had everything on eventQueue 0. Now the DDR->PCI transfer is on 2 and the COVRA Interrupts are gone. I have to test it a little bit more but I think that this is the solution...

    I have set this BPRIO register already - I thought that the problem is caused by bug in the DDR setup...

    bye,

    Thomas