• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 101 subscribers
  • Views 496 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

C6455: EDMA transfer from EMIFA to L2 SRAM stalls

Ralf Goebel
Genius 3715 points

Hi,

I'm using the EDMA to move data from an FPGA into L2 SRAM. The FPGA is connected to the EMIFA using 32 Bits. The EDMA is synchronized by a GPIO pin. For each DMA event, 512 bytes of data are moved. The entire EDMA transfer consists of many events.

Under normal conditions, packets are read by the DSP without interruptions and I can measure a delay between the rising edge of the GPIO and the first read cycle of less than 100ns.

In my program, there is some arbitrary code which manipulates data in DDR2. If this code executes, the EDMA seems to stall for a long time, sometimes for hundrets of us.

The problem goes away if the destination for the EDMA is changed to DDR3. This suggests that the problem is located within the Megamodule. I already tried to change priorities of the EDMA and the Bandwidth Arbitration Registers, but without success.

Any help is appreciated.

Ralf

  • 0
    Expert 1950 points

    Hi Ralf,

    The problem may come from the erratum 2.1.6 of sprz234r.pdf; if not already done, you could modify the BPRIO register of the DDR2 controller.

  • 0 in reply to Jakez
    Genius 3715 points

    Changing the BPRIO register has no effect.

    But I think this problem could be related to Advisory 2.1.21. I will try to implement a workaround.

    Thanks,
    Ralf

  • 0 in reply to Ralf Goebel
    TI__Guru* 84110 points

    Ralf,

    Which version of silicon are you using? This would be found from the markings on the top of the package. Advisory 2.1.21 is not in the list for rev 3.1, so it is fixed in rev 3.1.

    When you say that the operation stalls, what does that mean? The implication is that the delay from GPIO to EMIF read is increased. Or is the stall in the middle of the transfer?

    When you read from the FPGA, do you access it as a FIFO (read from a single address) or as a memory (read from a series of addresses)? There could be a performance advantage to using the memory method, reading from 128 sequential words, instead of from a single address. If it would be possible to try it just to see if the stalls happen, that might give some good information - no need to change the FPGA, but just read differently and ignore the bad data you will be getting (if possible).

    How much time is there between the last EMIF read and the next GPIO pulse? How much time is there between GPIO pulses? Are the GPIO pulses periodic or require writes to the FPGA before they will kick off the next GPIO?

    Regards,
    RandyP

  • 0 in reply to RandyP
    Genius 3715 points

    I have silicon revision 2.1.

    Sometimes, the delay from GPIO to EMIF read is delayed and sometimes, the stall happens in the middle of the transfer.

    I already read from the FPGA as memory and ignore the lower address lines.

    The timing for the GPIO pulses depend on the FPGA's FIFO level and the DSP timing:
    1. If at least one packet of data is present in the FIFO, the GPIO goes high (rising edge => DMA event)
    2. As soon as the DSP starts reading the packet, the GPIO goes low again
    3. The FPGA waits for the entire packet to be transfered before it continues with step 1.
    There is no additional write required to kick off the next Event.
    The delay between pulses depends on the data source which is sending the data. At the moment, it's a camera which is continuously sending data at about 30 MB/s. If no packets pile up in the FIFO, the delay between packets is about 17us.

    Thanks,
    Ralf

  • 0 in reply to Ralf Goebel
    TI__Guru* 84110 points

    Ralf,

    With silicon revision 2.1, then this has a good chance of being related to Advisory 2.1.21. The information there is lengthy and detailed, with all the possible work-arounds listed.

    If your "arbitrary code" is doing unrealistic work that is tying up the MDMA port, then you may be able to succeed by switching to some less arbitrary code.

    The best solution is to use rev 3.0. But many products have gone to production with 2.1 and earlier, so it is possible to work around this issue.

    If you have questions about anything in the Advisory, please let us know.

    Regards,
    RandyP

  • 0 in reply to RandyP
    Genius 3715 points

    I find the workarounds in the advisory 2.1.21 to be rather unsatisfying, because it's difficult to predict if this stalling would also occur for different functions. For example,  the code which was causing the problem is located within a library function which is provided to our customers. The occurrence also depends on the parameters used in the function call. In addition, our customers could also write their own code which would trigger this problem.

    Fortunately, I found a different workaround which works without changing any code at all:
    Within the FPGA, I added some logic to detect if the EDMA stall is occurring. If this is the case, the FPGA triggers a DSP interrupt by using a different GPIO pin. This interrupt causes the DSP to interrupt the loop which is causing the problem and the DSP continues reading the DMA packet. The interrupt itself doesn't do anything, it's just an empty function.
    The only situation which would still cause this problem is if interrupts are disabled for such a loop for a long time. But I think this is rather unlikely.

    Regards,
    Ralf