Getting VPIF errors when running video acquisition, audio acquisition/playout and Ittiam H.264 encoder

Christian,

 I think you are on the right path here.  You can determine they type of error by looking at register address 0x01c12014: if bits 0 or 1 are set it's a CRC error in a TRC; if bits 2 or 3 are set, it's a xAV-xAV distance problem; if bits 4 or 5 are set, it's a buffer overflow problem.

In the system you describe, I'd bet that the source of your occasional errors is almost certainly periodic buffer overflow due to system bandwidth overload. You should also be able to verify it's an overflow problem by turning off the encoder in your SW. The errors should go away due to reduced DDR competition.

Unfortunately, DM6467 system design does not let us set absolute priorities for system traffic to ensure the VPIF gets a certain guaranteed service, but there are some controls at our disposal. The three primary points of control are:

1.  VPIF DMA burst size (DMA_SIZE)
   
   1. Larger requests are more efficient, recommend setting is 0x80 (max value)
2.  SCR (EDMA) priorities (MSTPRI)
   
   1. Higher priority is better, recommend VPIF at highest setting, all other requesters at lower values
   2. BUT - HDVICP requests are effectively always on highest priority due to the way those requests are arbitrated. Therefore, to the greatest extent possible, HDVICP should not access DDR directly. Instead, data needed should be DMAed into L2, going through the EDMA TCs, which can be set to a lower priority
3. EMIF priority boost (PBBPR)
   1. There's a trade off here.
      
      1. Low values reduce peak latency through the EMIF (reducing buffer overflow risk at the data source), but this comes at a cost of reduced aggregate throughput in the EMIF 
      2. High values promote efficient use of the EMIF, but may result in long peak latency times
   2. Ideally, you would set this as high as possible while still avoiding VPIF data overflow. This may need to be experimented with to determine an optimal setting

If you've adjusted those 3 controls and are still having trouble, then the remaining options are to increase available DDR bandwidth or decrease DDR competition. Since you're already running DDR at 400 MHz, you're likely maxed out there (though it may be possible to find a speed grade of DDR that supports more aggressive timings at the same 400 speed). If nothing else is working, you may need to tune the codec (or orther large consumers of DDR BW) for lower DDR usage.

Hi Todd,

Thanks for the reply.  I have verified the value at 0x01c12014 like you suggested after the error occurs and it is set to 0x110.  So it is buffer overflow like we both suspected.  As for your 3 suggestions, I have already tried these previously without any impact on the problem.

Through more testing, I have further narrowed that the issue occurs only if I am doing PCI read transactions (using EDMA TC2 to do this read) while video acquisition is occurring.  This PCI read transaction is only done in my system for audio output as I am reading audio to output from the host processor (typically sending 704 bytes packet, 25 times per second) to DSP DDR memory.  If I am not doing those PCI reads, the issue does not occur.  If I do the PCI read (then throw away the data on DSP to remove any other possible cause), then the issue occurs.  Since the amount of data for those PCI reads is quite small as compared to video, I now doubt that this is a DDR bandwidth issue.  My suspicion is that the DMA for my PCI read is somehow holding the internal bus for too long, preventing the VPIF from accessing DDR during that period and causing an overflow.  Even though the MSTPRI of EDMA TC2 is set to 3 and that of VPIF is set to 1, I am assuming that the system may not have the ability to preempt a transfer in progress of lower priority, and that PCI read might be taking long to complete (must wait for data to be received from PCI bus).  Please comment if my suspicion is possible or if you think there is another cause.

Here is other things that I have done to try to debug this:

a) I measured duration of PCI read DMA using TSC on DSP - on average these are taking in the order of 320 us which seems long for a 66 MHz bus and only 704 bytes

b) I tried to modify EDMA RDRATE register for TC2 as there was a note that this could monopolize slave resources; setting it to 0x4 (max value) did not have any impact

c) I tried to split my PCI read DMA into 64 bytes chunk in case the full transfer was causing more issues.  This actually made the issue worse as it was now occurring much more often

I would appreciate your feedback on what I should be testing next.

Thanks,

Christian 

Christian,

 That is an interesting wrinkle.

 You are correct about many of your assumptions. High priority transfers can not preempt low priority transfers; Priority is only evaluated when deciding which transfer gets to start. However, the EDMA uses split transactions to improve efficiency. Each TC has a dedicated high performance FIFO that allows it to separate the read portion  of a transfer from the write portion. Therefore, a slow read from PCI will affect any transfer waiting for TC2 and/or PCI, but transfers that are independent of those resources can proceed. When the PCI read is complete, the data is transferred from the TC fifo to the DDR controller at maximum speed.  Therefore, a slow PCI read should not be able to directly block VPIF from DDR for extended periods of time. But it sure seems like there is some kind of interaction with that affect going on in your system.

First, can you verify that ALL PCI traffic goes through TC2 and that there is none that uses another TC nor is any CPU making direct access to PCI space?What else is on TC2?

The next thing that comes to mind for unexpected stalling is MDMA/SDMA stalling in Advisory 3.0.3. While it does not appear that the PCI transaction alone would implicate this erratum, I'm thinking it could be possible for the PCI traffic to interact with other system traffic in a way that causes long pauses.

-Todd

Hi Todd,

Thanks for you clarifications.  All my PCI traffic (read/write) goes through TC2 - none is done using another TC or directly by CPU.  TC2 is used for many other transfers such as:

- copying audio input/output internally

- some grid copying for video output

- Ittiam H.264 encoder has some transfers on TC2 (also some on TC0 + TC1)

- TVP5158 line interleaving demuxing - used to copy line hearders (actual video copied in another TC)

I do understand that the delay in PCI read will cause delays with these as well, but it still is not clear to me how this ends up causing VPIF errors to occur.  I will keep looking into this and any other suggestion you may have would be welcomed.

Thanks,

Christian

Christian,

 I suspect you may be having isses with the MDMA/SDMA blocking issue. I 've asked your local FAE to assist in evaluating your DMA usage for this potential.

Hi Christian,

Can you tell me how did you determine which EDMA TC was used for your VPIF data transfer and how can I change the default value?

Thanks and Regards

Shruti

Hi,

Are you using VDCE for chroma conversion? If yes, it uses EDMA for luma transfer. i don't remember exactly which TC it uses. Could you check the driver and change the TC if it is creating the issue? or comment out VDCE operation to see if improves?

Regards,

Brijesh Jadav

Hi Brijesh,

VDCE by default uses EVENTQ_1 for luma transfer. I have tried changing it to all other TCs, does not help.

But strangely if I comment out the VDCE operation and perform the chroma conversion through software, I do see 40-50ms improvement in latency.

Thanks and Regards

Shruti

Hi Shruti,

How do you do chroma conversion in software? do you use display buffer directly as destination buffer? can you check if you are doing any memcpy when you use VDCE? Could you try changing EDMA channel number?

Regards,

Brijesh Jadav

Hi Shruti,

I think this thread is for VPIF error interrupt, we are discussing about the latency issue at below thread.

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/p/232336/827842.aspx#827842

Regards,

Brijesh Jadav