vishnupsn wrote:
> Hi experts,
> 
> I am working with TI DM6446 ( DaVinci EVM )which has a 64x+ core and ARM9
> Core. I am  developing an interrupt driven application in the 64x+ core (
> Code Composer Studio project). In this context I see a strange behaviour
> when the  CCS project uses  TI Chip Support Library (CSL) for configuring
> Interrupt handlers. The interrupt latency is very huge, of the order of 3-4
> microseconds.  However, when DSP BIOS is used for Interrupt handler
> configuration, the latency is only 1-2 microseconds. Has any one seen such
> kind of latency?  Interestingly, if I setup the Interrupt handler ( without
> CSL or DSP BIOS)  by properly setting the relevant  registers and vector
> table, I get still lower latency. FYI, the 64+ core is operating at 594Mhz
> and is expected to give only a latency of less than 15 clock cycles. 
> 
> I am calculating the latency by measuring the width of a pulse on a GPIO
> pin of the DSP,  which is set high  when interrupt event occurs, and reset
> the begining of the  ISR. This ensures that whatever error   occurs  in
> measurement ( even if GPIO pin latency  is encountered) would be applicable
> to all 3 modes of Interrupt vector setting mentioned above. 
> 
> Now my question is , has any one encountered such high Interrupt latency
> while using TI CSL? If not can some one give a possible explanation for the
> behaviour ?
> 
> If this is not the right forum to ask this question can some one direct me
> to the right place.
> 
> 
> Thanks in advance,
> 
> Cheers
> 
> Vishnu Prasad S.N
> 

When looking at interrupt latency I think there are 2 main components 
you should consider:

1)  Delay in taking the interrupt due to interrupts being disabled.  I 
don't know what else is happening in your system but certain library 
routines, etc. will disable interrupts while they are processing.  This 
can cause interrupt latency.  Also, the 64x+ core is uninterruptible 
during the delay slots of a branch, so tight loops can cause the device 
to be uninterruptible.  This is less of a problem than it used to be due 
to the SPLOOP hardware that was introduced in the 64x+ core.

2)  Delay in the interrupt handler.  In the case of DSP/BIOS you have 
the choice of using the HWI_dispatcher or plugging the interrupt 
directly into the table.  Using the HWI_dispatcher is recommended but it 
will add a small amount more latency.

You're talking about 1200 cycles of interrupt latency using DSP/BIOS and 
2400 cycles of latency using CSL.  Try to break that down further to 
figure out what the CPU is doing during all those cycles.

Brad

Hi experts,

I am working with TI DM6446 ( DaVinci EVM )which has a 64x+ core and ARM9
Core. I am  developing an interrupt driven application in the 64x+ core (
Code Composer Studio project). In this context I see a strange behaviour
when the  CCS project uses  TI Chip Support Library (CSL) for configuring
Interrupt handlers. The interrupt latency is very huge, of the order of 3-4
microseconds.  However, when DSP BIOS is used for Interrupt handler
configuration, the latency is only 1-2 microseconds. Has any one seen such
kind of latency?  Interestingly, if I setup the Interrupt handler ( without
CSL or DSP BIOS)  by properly setting the relevant  registers and vector
table, I get still lower latency. FYI, the 64+ core is operating at 594Mhz
and is expected to give only a latency of less than 15 clock cycles. 

I am calculating the latency by measuring the width of a pulse on a GPIO
pin of the DSP,  which is set high  when interrupt event occurs, and reset
the begining of the  ISR. This ensures that whatever error   occurs  in
measurement ( even if GPIO pin latency  is encountered) would be applicable
to all 3 modes of Interrupt vector setting mentioned above. 

Now my question is , has any one encountered such high Interrupt latency
while using TI CSL? If not can some one give a possible explanation for the
behaviour ?

If this is not the right forum to ask this question can some one direct me
to the right place.


Thanks in advance,

Cheers

Vishnu Prasad S.N