• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 959 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.

Big interrupt latency for C6727 when performing memcpy

Boll
Intellectual 340 points
Other Parts Discussed in Thread: PMP

In brief, my problem is that external interrupt latency is too big.

System Setting Up:

  • AMUTEIN2 is configured as external interrupt pin, and interrupt source is from FPGA
  • Precedures in SPRAAJ3 are strictly followed to setup dMAX to generate external interrupt
  • 2 tasks in the system: background task and foreground task (ISR)
  • RTI is enabled for timing measurement in system, but interrupt is not enabled for RTI.

Observations:

  • External Interrupt is correctly generated and responded.  There is no interrupt missing.
  • Interrupt latency is around   1 us when system is idle.
  • Interrupt latency is around   1 us when performing memcpy(156 Bytes) from internal memory to internal memory in background task.
  • Interrupt latency is around 30 us when performing memcpy(156 Bytes) from external memory to internal memory in background task.
  • Interrupt latency is around 10 us when performing     dMAX(156 Bytes) from external memory to internal memory in background task.

It seems interrupt latency are heavily affected by EMIF operation.

The big latency time is not acceptable.

Are there any paticular settings for EMIF, dMAX or else to reduce the latency time?

Please Help.  Thanks.

Boll

 

  • 0
    Intellectual 820 points

    Boll,

    Memcpy() is most likely masking/restoring interrupts before/after an optimized loop that copies data in memory.  The compiler has to mask interrupts to avoid breaking assumptions the code generator/optimizer makes about the state of the instruction pipeline.

    Many other DSP and/or math library functions use optimized loops that will mask interrupts during the loop execution (e.g. FFTs, filters, log/antilog, trig functions, etc).

    You could probably work around the memcpy() latency by writing your own copy function in C, and specify a lower level of speed optimization for that C source file.  Or you could use a 1D DMA transfer to copy data to/from external memory.

    But that would still leave latency problems with other library functions that you use.

    Steve

  • 0
    TI__Guru*** 125430 points

    Please look at Figure 2-4 "Block Diagram of Crossbar Switch" in the data sheet.  The Program Master Port (PMP) has the lowest priority in the system when it comes to accessing the EMIF.

    Question:  Where is your ISR located (internal or external memory)?  I believe that placing your ISR in internal memory should help in the situation where dMAX is accessing external memory since the dMAX has higher priority than PMP.

    I believe Steven may have hit the nail on the head in terms of the compiler temporarily disabling interrupts.  The 672x has no data cache so any data accesses to external memory will be EXTREMELY slow.  I imagine that's why you're seeing such a huge latency introduced.  

  • 0 in reply to Brad Griffis
    Intellectual 340 points

    Thanks for you kind help.

    The ISR is in internal memory.

    Now the cause is spot.  As Steven's analysis, interrupt is disabled for software pipelining.

    And the solution is to switch on compiler option --interrupt_threshold=1, with which the latency time is reduced significantly to 2~3 us.

    However it will degrade pipelining performance.

    Temporarily I set the threshold to 1.  But how to optimize the threshold value? Any suggestion?

    BTW, I am going to utilize dMAX in background task.  I'd like to inquire what if interrupt comes when dMAX is onging.  Any conflicts?

     

    Thanks.

    Boll

  • 0 in reply to Boll
    TI__Guru*** 125430 points

    Boll said:

    And the solution is to switch on compiler option --interrupt_threshold=1, with which the latency time is reduced significantly to 2~3 us.

    However it will degrade pipelining performance.

    Temporarily I set the threshold to 1.  But how to optimize the threshold value? Any suggestion?

    I think you could spend gobs of time theorizing about what to set it to, but in the end I think you'll be better off simply experimenting a bit and looking at your resulting latency.  Perhaps tune the number to be as large as you can tolerate and then back off 20% (or more depending on how conservative you want to be).

     

    Boll said:

    BTW, I am going to utilize dMAX in background task.  I'd like to inquire what if interrupt comes when dMAX is onging.  Any conflicts?

    Does the interrupt access data in external memory?  The dMAX has higher priority than the CPU data port when accessing the EMIF, so dMAX activity might make the ISR execute slower if it is contending for EMIF bandwidth.