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.

AM5749: Interrupts latencied in TI-RTOS

Part Number: AM5749

Hi Dears,

 

I am currently trying to improve the interrupt responsiveness of the CorePac DSP included in the AM5749 SoC.

The firmware is based on TI-RTOS provided by SDK 8.1.0.9.

The application uses an external FPGA connected via GPMC. The transfer between the FPGA and the SoC takes around 25µs, and an acceptable latency would be around 5µs given that this operation takes place every 35µs (28kHz).

This FPGA can trigger an interrupt on the SoC's DSP1 which produces an EDMA request event that starts the CorePac's EDMA transfer. This EDMA transfers data from the FPGA to the OCMC_RAM2.

At the end of the transfer, we receive an EDMA interrupt. This interrupt has a latency of between 5 and 46µs.

This latency corresponds to the time elapsed between the end of the EDMA transfer and the acknowledgement of the end of EDMA in the interrupt handler.

We've already bypassed the event combiner to reduce latency a little, but it's clearly not enough.

In parallel, we're using the IPC layer to control the DSP1 firmware from Linux running on ARM. If we disable the IPC code in the DSP1 firmware, latency will be improved as it ranges from 5µ to 24µs.

Part of this huge latency is therefore due to the IPC layer. However, an interrupt latency of 24µs is not acceptable.

 

Is there a way to reduce these huge and highly variable latencies?

Also, is there a way to reduce the IPC priority in the TI-RTOS implementation?

 

Many thanks in advance

Kind regards,

Steve

  • Hi Steve,

    Could you help me understand how IPC layer comes into the picture in the interrupt latency measurement?

    Is EDMA transfer completion interrupt serviced on DSP or ARM? 

    Sorry, I am not clear about the sequence between FPGA, EDMA, DSP, and ARM based on your description. 

    It would be very helpful if you could layout the sequence of events vs time. 

    Regards,
    Stanley

  • Hello Stanley,

    I'm working with Steve on this topic.

    The latency measurement is between the end of the GPMC data exchange between the FPGA and the DSP trigged by an Interruption from the FPGA.
    This interruption triggers the EDMA request event.
    We have some jitter (between 5µs and 46µs) and we don't know why it happens

    By disabling the IPC exchange between the ARM and the DSP, we are able to reduce this Jitter but not entirely.

    Thoughts?

    Best regards,
    Romain

  • Instead of GPIO toggling, could you use DSP timestamp and log the timestamp when EDMA completion ISR is triggered? This way we can know for sure there is various latency from EDMA completion ISR being triggered, which I don't expect to see.

    GPIO toggling requires access to L3/L4 bus to GPIO register which can be delayed due to active requests on the L3/L4.

    Regards,
    Stanley

  • Hi Stanley,

    I do not see how I will measure the latency between the hardware event that start the EDMA transfer and the entry inside the interrupt handler.

    I can not use the TSC on the hardware event.

    What is your idea for measuring latency with TSC?

    Moreover, I've already seen this variability on latency of the GPIO interrupt I was using to trigger the DMA transfer by software. Both were cumulative!

    Thanks in advance

    Kind regards,

    Steve

  • Can't you take the timestamp from TSC in ISR serving FPGA IRQ and another timestamp in ISR serving EDMA completion interrupt?

    The difference between the 2 timestamp (TSC freq is the same as DSP clock) can be used to convert to time for transfer latency.

    You can monitor and check if the timestamp difference stays in the same range.