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

SYS bios Interrupt latency 667x

Lukasz Mitrega
Intellectual 315 points
Other Parts Discussed in Thread: TMS320C6671, SYSBIOS

Hi All,

Preface :

during development of the EDMA3 functionality wrapper for QDMA transfers (between DDR3 and MSMC SRAM) i met a strange problem with the performance. While setting single transfer for about 128 KB I could achieved expectable transfer speed (the speed was measured after transfering 256 MB). But while setting smaller single transfer sizes I observed that the performance is decreasing. I tried to find the reason of such behavior and it looks like using the interrupt causes the latency between transfers (while manually pooling the interrupt pending register in EDMA3 CC the performance was ok).

System description :

Processor : TMS320C6671

SYSBIOS : 6.34.2.18

Chip interrupt controller configured with CpIntc_xxx functions

HWI created with Hwi_create function

Problem :

Interrupt latency

I made a test and triggered the system event in the chip interrupt controller (using CpIntc api) and checked the core timestamp register (using the CLS_tscrRead) to check the time from triggering the function to the enterance of the interrupt function (passed to HWI_create) and the time of the interrupt function (the function was using CpIntc_xxx  to reset the interrupt reason and register accesses to EDMA controller to read and clear interrupt). The values I got was about 500 for each.

 

Questions :

1. Is it a normal behavior (high latency using HWI interrupts) ?

2. Is there a way to improve the interrupt performance?

3. Is there a logical mistake in the the way I configured the interrupt from EDMA ?

 

I'll be very thankful for any hints.

  • 0
    TI__Mastermind 32475 points

    Hi,

    1.  You asked if this is normal behavior.  I would say it depends.  For a primary interrupt that is mapped directly to Hwi, the latency is around 100 cycles.  In your case, since your interrupt is routed via CpIntc into Hwi, then I would expect a much more than 100 cycles.  500 cycles wouldn't be out of the question but I don't have benchmark numbers for this.

    2.  Where is memory did you place this code?  Have you made sure your cache(s) are enabled.  L2 is not enabled by default so if this code was placed into DDR memory, that could have an impact.  If its placed in L2 or MSMCRAM, you should be okay as L1P memory is enabled by default.

    3.  Doesn't sound like there's a mistake.  If the EDMA is routed through CpIntc then you will have to suffer the latency.  If it was routed directly to Hwi, you would be able to bypass the CpIntc so I would just double check to make sure that you have to go through CpIntc. 

  • 0 in reply to judahvang
    Intellectual 315 points

    Thanks a lot for the answers.

    My code is in L2 and the global edma interrupt for the channel controller 0 is not routed directly to the core (as I remember, I'll recheck it tomorrow).

    In this case, please ensure me. There is no way for high performance small transfer non pooling wait method?

  • 0 in reply to Lukasz Mitrega
    TI__Mastermind 32475 points

    Lukasz,

    Can you tell me if you have more than 1 System interrupt mapped to the same host interrupt?

    If you only have 1 System interrupt mapped to a host interrupt, the latency should not be too bad...I would say less than 200 cycles.

    Judah

  • 0 in reply to judahvang
    Intellectual 315 points

    I want only to notice, that the situation with the keystone interrupts is clear to me now.. I'm using the interrupt noticed end of edma transfer only in case of large no time critical transfers (the wait for interrupt allows to switch the multi-task environment to other task. In case of small transfers with ping-pong buffers I use the blocking wait for transfer with register read.