TMS320C28346 XINTF from External Interrupt Timing

Jason, 

I have a few thoughts

JasonHaedt said:

1.) Overhead to enter ISR from external interrupt - I believe this is 16 clock cycles from external interrupt?

Yes.  This assumes that the CPU is ready/able to take the interrupt (i.e. interrupts are enabled, CPU isn't servicing a high-priority interrupt, etc).  Some registers are saved as part of the automatic context save, but the ISR may require additional registers to be saved.  If this is the case, then  this will add to the start of the interrupt before "real work" can be done.    Some of this will depend on what the ISR is doing - it can be measured with experiments on a device. 

This wiki article has more information:

http://processors.wiki.ti.com/index.php/Interrupt_FAQ_for_C2000#ISR_Latency

JasonHaedt said:

2.) DMA will have to burst two bytes in from XINTF to internal SARAM.  I only have enough pins to do a byte interface, so I have to do two XINTF transfers - I believe this is 4 cycles per word to do dma transfer.  In addition I would have to add my external CPLD timing which can be accomplished in 24 DSP clocks for byte.  Total time to go from XINTF to SARAM would be 52 clocks. 

JasonHaedt said:

3.) DMA will have to burst two bytes out from internal SARAM to XINTF.  Again I am using the same byte wide interface.  So this is another 4 cycles per word to do the dma transfer.  In addition I would have to add external CPLD timings which is 24 DSP clocks for byte.  Total time to go from SARAM to XINTF would be 52 clocks. 

The key is the DMA will not issue a read on each cycle. It is copying data so it will issue a read then write then read etc.. Minimum transfer time is 4 SYSCLKOUT cycles (refer to section 3 in the DMA ref guide www.ti.com/lit/SPRUG78.   This only shows 1 cycle for the read/write, but the XINTF will extend this via the lead/active/trail.  These values must be configured to meet the timing required by the external device.

JasonHaedt said:

4.) Increment Receive Counter - ? clock cycle?

5.) Increment Transmit Counter - ? clock cycle?

One or two cycles (load DP, increment counter).

JasonHaedt said:

6.) Overhead to exit ISR - 16 clock cycles? 

This depends on how many registers need to be restored.  The return itself is 4 cycles.

Hope this helps

Regards

Lori

JasonHaedt said:

1.) Overhead to enter ISR from external interrupt - I believe this is 16 clock cycles from external interrupt?

Lori Heustess said:

Yes. This assumes that the CPU is ready/able to take the interrupt (i.e. interrupts are enabled, CPU isn't servicing a high-priority interrupt, etc). Some registers are saved as part of the automatic context save, but the ISR may require additional registers to be saved. If this is the case, then this will add to the start of the interrupt before "real work" can be done. Some of this will depend on what the ISR is doing - it can be measured with experiments on a device.

Jason,

One point to note is that the 'manual context save' (my name for saving of registers by the user/compiler rather than the CPU) can be variable in length depending on what happens in your ISR. It can be up to 36 more cycles (entrance and exit) or more dependant on code. If you are using C for your ISR (which is most peoples first choice) be very careful and check the disassembly every time you change your ISR code as the length of the manual context save may have increased/decreased and this additional latency will need to be noted in your calculations. If you are really trying to save cycles I suggest coding your ISR in assembly as you have more control on what variables you use and how many that need to be saving. If you do use C try to avoid function calls within your ISR. Unless your optimizer is set properly, the C compiler will assume it uses every register possible in the function call and thus it will save all of them.

Here is what I wrote in a manual for an RTOS port about the stack: ----

Upon an interrupt, whether it be from a peripheral or a software trap, the processor automatically pushes the following information onto the stack in the following order (32-bit words)(automatic context save):

1) T: ST0 – Temporary register and Status Register 0

2) ACC – Accumulator

3) P – Product Register

4) AR1:AR0 – Auxilary registers

5) DP:ST1 – Data point and Status Register 1

6) DBGSTAT:IER – Debug status register and interrupt enable register

7) Return Address

The User/OS needs to save the following variables (manual context save):

1) XAR2

2) XAR3

3) XAR4

4) XAR5

5) XAR6

6) XAR7

7) RPC

8) XT

9) AR1H:AR0H

10) FPU variables if necessary

-----

Note C will (possibly) save all the registers except RPC. This means (up to) another 8 more cycles on both the entrance and exit (16 in total). If the FPU is in use then up to another 10 more cycles could be used (20 in total).

TL;DR: In conclusion, the interrupt latency could be anywhere from 16 to 34 cycles on entrance and exit depending on what variables the user or compiler saves.

Hopefully this has been informative and helps you getting the system working,

Tim

Edit: E2E posts are working today and have reparagraphed the whole thing.  Now its readable!