1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Pipeline induced interrupt latency jitter

Discussion in 'Embedded' started by Chris Carlen, Jul 19, 2007.

  1. Chris Carlen

    Chris Carlen Guest

    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

    NOTE, delete texts: "RemoveThis" and
    "BOGUS" from email address to reply.
     
    Chris Carlen, Jul 19, 2007
    #1
    1. Advertisements

  2. Chris Carlen

    Didi Guest

    I wonder if the new SHARC DSPs which I recall reading are not pipelined,
    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
     
    Didi, Jul 20, 2007
    #2
    1. Advertisements

  3. 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
    www.abvolt.com
     
    Vladimir Vassilevsky, Jul 20, 2007
    #3
  4. 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
    www.abvolt.com
     
    Vladimir Vassilevsky, Jul 20, 2007
    #4
  5. Chris Carlen

    korenje Guest

    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
     
    korenje, Jul 20, 2007
    #5
  6. Chris Carlen

    CC Guest

    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!
     
    CC, Jul 21, 2007
    #6
  7. 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
    www.abvolt.com
     
    Vladimir Vassilevsky, Jul 21, 2007
    #7
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.