Sub microsecond jitter accuracy - what to use?

Question

I have four TTL level signals that must change state in a particular order.

From the “go” signal on one of the lines, all toggling of the other lines will be done within 100 us. The other three signals will toggle at most a couple of times. The start, end and duration between state change that these other three signals will toggle varies depending upon metrics in the system that are know well before the go signal occurs. But the timing is variable so the sequence of pulses and their durations need to be programmable. The timing and duration is known before the sequence starts.

Here’s the rub, I need sub microsecond jitter accuracy. The 120 MHz ARM micro I’m using can’t guarantee such deterministic timing profiles due to pipelining and a host of other performance enhancing reasons. We can do our best to architect the system to minimize the jitter but I want to know if it’s use a faster micro or DSPs or CPLD, PALs, etc. are a typical way to get the accuracy and resolution I’m looking for.

In the past with an 8 bit micro running at 8 MHz with one instruction per clock cycle I could write some assembler, put the micro to sleep, wake on interrupt, count some clock cycles and have 0.25 us accuracy

What technology to I need to investigate to achieve this resolution and accuracy?

Answer 1

STM32 devices have very powerful and configureable timer peripherals. They can be chained or synchronized and offer cycle-accurate outputs. You may want to spend some time reading over the datasheets for the STM32L4 and H4 devices to start, and perhaps reviewing some of STMicro's timer specific documentation.

I'm personally using the timers along with an FPGA to give me microsecond-accurate timing and sequencing for 32 digital outputs. The FPGA is not doing anything timing specific, but rather just MUXing the STM32's excellent and configurable timers to one of 32 outputs. The final hardware will eliminate the STM32 but for prototyping and development it can't be beat.

Answer 2

It's not clear what exactly the signals are you need to generate, and their timing relative to incoming signals.

However, 250 ns isn't really all that hard to achieve with something like a EP series dsPIC, for example. At 70 MHz instruction rate, that gives you up to 17 instruction cycles of allowable jitter. That's a lot.

Having your incoming signal cause a interrupt, then generating the output signals from fixed instruction timing will give you much less than 17 cycles of jitter. It would be even better if the input signal can trigger a PWM generator or the like. But, you haven't given enough information about the nature of the output signals to know whether specific hardware available on such micros would be applicable.

Answer 3

Usually you can achieve this kind of real-time as long as the output does not depend on software/interrupts. That is, pins aren't set from an ISR or similar, in which case you will have microsecond jitter. Interrupt latency might be a static time, but I wouldn't count on it, in case more than one interrupt fires at once etc.

You might be able to solve this with the output compare feature of the hardware timer. That is, all relevant pins are set when a timer elapses, like for example when using PWM. This can often be done with system clock or system clock/2 accuracy. Other alternatives are DMA, if supported for the specific pins.

This may work down to 50-100ns somewhere, where you'll be at the mercy of the analog characteristics of the pins.

And then of course, you won't be able to get better accuracy than your oscillator allows. You certainly can't use some built-in RC oscillator, but need to use a high accuracy crystal or external oscillator.

Answer 4

DMA and a timer?

A couple of SPI busses and just use the data pins (Possibly again with DMA if you need more then 32 time slots)?

My feeling is that 1us should be well doable if you pick your IO pins correctly and are prepared to play a few low level games.

100ns I would have to think about, but maybe something devious with loading up a QSPI ram chip then clocking out the bit pattern using a timer as the clock?

10ns is FPGA territory.

Answer 5

Check if you have timers which are able to drive multiple pins, typically used for motor control (usually 4 or 6, for H-bridge and 3-phase respectively). In many cases, such timers have "preload" registers which allow you to seamlessly modify the period and the duty cycle, which means you can essentially generate an arbitrary waveform with them. If done right, such waveforms are precise down to the timer resolution.

Answer 6

Maybe something like a Cypress PSOC with the programmable logic cells. I think Microchip has parts with similar capabilities. They're like microcontrollers with tiny, limited FPGA functionality that you can customize. It sounds like you will need some form of either DMA or FPGA to hit your requirements.

Answer 7

I'm doing something very similar at work with a DSP. I have an FPGA which carries out the precision timing part. I was hoping to use a square wave from the DSP to test the PLL for syncing two FPGAs. In fact I found that although the FPGA timing tolerances were set at around 0.01us based on clock tolerances, my DSP had too much else going on to do better than 0.1us.

This is a pretty full-on processing loop though. With a less intensive loop, it could be better, of course. For the parts which really needed to be deterministic, running them at the very start of the loop can help. Do be warned though that although interrupt latency is predictable, it is very much non-zero! For my platform it's 91 clock ticks at 456MHz. I can easily get sub-us jitter from interrupts, but microsecond delays need the interrupt latency to be baked into the calculations.