Pipeline induced interrupt latency jitter

Hi:

I discovered on the TMS320F2812 DSC that I'm using to synthesize digital words that the CPU pipeline appears to cause jitter of the interrupt latency. If I have the basic program structure:

interrupt timer_isr() { diagnostic_IO_port_bit = 1; // scope this diagnostic pulse calculate_and_output_some_data_words(); diagnostic_IO_port_bit = 0; }

main() { make_CPU_timer_interrupt_vector_point_to_timer_isr(); init_CPU_timer_to_cause_periodic_interrupts(); clear_CPU_interrupt_mask_bit(); // enable global interrupts

while(1) { do_something_preemptable_less_important_than_timer_isr_repeatedly(); } }

I set my scope to expand the time scale around the *next* rising edge of the diagnostic pulse, to observe the jitter in the timing of the periodic interrupt service routine.

What I observe is (you will need fixed font for this):

____ ____ ____/ \___________________/////// \____... trig^ ^--------timer period-------^ ^-----^ jitter

The time spacing between jitter edges is one CPU cycle (6.67ns).

Interestingly (and understandably), enabling the real-time debug mode of the C2000 and stopping the CPU (peripherals continue operating and interrupts keep getting serviced) causes the jitter to disappear.

The jitter width varies with the code that is executing in the main loop. In the simplest case of a while(1); main loop, the jitter is 6 cycles (40ns). However, fairly complex main loop code can result in 10 cycles (66.7ns) jitter.

Fortunately I can tolerate this level of jitter in my application (it gets worse because I have another interrupt which can block the important interrupt for a few cycles before I reenable interrupts in the lesser ISR).

I wonder if the new SHARC DSPs which I recall reading are not pipelined, could produce perfectly jitter-free signal synthesis?

Comments appreciated.

--
Good day!

________________________________________
Christopher R. Carlen
Principal Laser&Electronics Technologist
Sandia National Laboratories CA USA
crcarleRemoveThis@BOGUSsandia.gov
NOTE, delete texts: "RemoveThis" and
"BOGUS" from email address to reply.
Reply to
Chris Carlen
Loading thread data ...

Not pipelined does not mean one cycle per any opcode. Only if the Blackfin does that (I don't know, I have only looked at it and not used it) can zero latency jitter be expected. If it has division, there we go, I have yet to see a single cycle div :-). But then again, if they do the div in the TI style (in a loop using "conditional subtract" or whatever it was, it's been years since I last did that), this can be interruptable.... Yet 0 IRQ latency jitter would be quite a feature, I guess I would have noticed _that_ when I was looking at the Blackfin.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

formatting link

------------------------------------------------------

Reply to
Didi

This is not right.

Blackfin has a pipeline of 8 clock cycles deep, plus 32 bytes of prefetch, DMAs, code/data caches and multiple buses with complex arbitration. Due to that, the interrupt latency can be wildly different. Actually it is so different that it is difficult to account for the worst case.

The main idea of BlackFin is that the interrupts should not be used for the critical jitter free timing. There is a number of built in peripherals (PPIs, SPORTs, DMAs) which generate the timings by hardware.

Vladimir Vassilevsky DSP and Mixed Signal Consultant

formatting link

Reply to
Vladimir Vassilevsky

This is what is expected.

[...]

Jitter is caused by the coinsidence of several different events. Depending on how does the actual timing look like, there can be more or less jitter. You can only account for the worst case.

The timing for the time critical events should be generated by hardware. You can't rely on interrupts.

SHARC does not have jitter free interrupts, but it has different means (timers, SPORTs, DMAs) to generate signals by hardware.

The newer is the processor, the deeper are the pipelines and the more complex is the arbitration of the internal buses. In the other words, more jitter relative to the clock rate.

Vladimir Vassilevsky DSP and Mixed Signal Consultant

formatting link

Reply to
Vladimir Vassilevsky

If you have only one interrupt, you can put the CPU in the idle mode each while loop iteration in main(). Though the rest of the code in while loop has to execute before the next interrupt is triggered. I have tested this on C24xx and it works, I do not see any reason why it should not work on C28xx family

Mitja

Reply to
korenje

Well, the F2812 doesn't have DMA controllers. I have another application where a single compare match output which generates arbitrary pulse sequences can operate completely jitter-free since the the output is generated by the hardware peripheral. Only the register set up after each even needs to be done in software.

But the other part of the job is to output a 16 or 32 bit word when a compare match occurs on a QEP counter. The best that can be done is to have the compare match ISR output the data through IO ports. The alternative is another CPU that would have a compare match even tied to a DMA controller. And then that DMA controller would have to allow moving data from memory out an IO port. Alternately I'd have to put a memory mapped IO port on the bus.

Or, build my own QEP counter, compare match, and word pattern table indexer/outputter in hardware.

Since the jitter is tolerable, the F2812 wins in this case.

Well I've learned a few things for sure. It's not as simple as turning up the clock. For that matter, I think the last time I played with an AVR, that it could generate jitter-free interrupts.

Can anyone confirm?

Good day!

--
_____________________
Christopher R. Carlen
crobc@bogus-remove-me.sbcglobal.net
SuSE 9.1 Linux 2.6.5
Reply to
CC

If you can write a code which uses only register to register operations, no index addressing and no jumps, then yes, the AVR interrupt timing will be accurate to one cycle. But this code can't do much :-) Otherwise there will be a jitter of 2...4 cycles.

Vladimir Vassilevsky DSP and Mixed Signal Consultant

formatting link

Reply to
Vladimir Vassilevsky

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.