# Nanosecond interrupt accuracy on a 64MHz microprocessor

I am currently designing a PCB with a 64MHz nRF52832 bluetooth MCU. I have an interrupt connected to this MCU which needs to be detected with 1-3 nanosecond accuracy.

Unfortunately, the 64MHz MCU has a clock cycle of 15.625ns, meaning the interrupt could be recognized up to 15.625ns late (assuming zero interrupt latency for now). Please note that the interrupt does not need to be acted upon straight away, I only need to know at which time it arrived.

Is there any way for me to use external circuitry to improve my accuracy? I've considered using an external nanosecond timer to measure the offset, and sending that to the MCU every time the interrupt is triggered. Unfortunately, I'm having a hard time finding any timers that can run at this speed.

I am capable of changing the MCU to a faster processor, however nothing greater than ~180MHz - which would still be 5.56ns per clock cycle. For this reason, a creative external solution would be ideal.

• You should probably consider using a FPGA with a fast clock. – user2233709 Apr 17 '17 at 21:00
• Thanks, but unfortunately I am limited on size and budget - I am hoping there is an alternative solution, before deciding to use an FPGA. – inushii Apr 17 '17 at 21:03
• 1ns accuracy compared to what reference? Is this a situation for a time-to-digital converter? What's the source of the signal and its rise time? – pjc50 Apr 17 '17 at 21:05
• +1 for time-to-digital converter, but it won't be cheap. Knowing more about the actual problem to solve would help. – bobflux Apr 17 '17 at 21:14
• Here's a tdc with 250 ps resolution, looks inexpensive. – tomnexus Apr 17 '17 at 21:21

# Theoretical considerations

For a digitizing system to detect something with a temporal resolution of $$\\Delta t\$$, it needs to have a sample rate of at least $$\\frac2{\Delta t}\$$. That's a corollary of Nyquist's sampling theorem.

In your case, this means that whatever pin might cause an interrupt that somehow notes the time the signal edge happened, you'd need some sampling clock (or, more precisely related to your application: a counter that can be latched on the external signal) running at least at 666.67 MHz.

# practical considerations

Nothing short of that will do, unless you can build an external system that somehow converts the event into something slower that can then be observed afterwards to calculate the time it happened.

So, what I'd propose is actually the approach you've been recommended in the comments, namely, using high-speed counter e.g. inside an FPGA to capture the time and read it whenever you're ready with your MCU.

Or, you use the impulse and very fast analog electronics to e.g. kick of e.g. an exponential voltage decay which you can periodically observe and extrapolate from the observed rate of decay the point in time when it got started. That way, you'd actually be trading ADC resolution (interrupt pin: "1 bit ADC", if you want so) for timing resolution. You'd still need a pretty good ADC and accompanying CPU speed.

In the end, your problem is a hard one, as detecting nanosecond precision pulses is a hard problem – even starting from a PCB layout point of view (the quality of your pulse edge is a function of the signal bandwidth you can transport on your PCB trace – and for a signal with 1/(1ns) = 1 GHz fundamental frequency, this already becomes non-trivial).

You'll probably either need a very fast FPGA, or aforementioned analog time-to-function converter, a moderately fast ADC and a moderately fast FPGA to deal with the ADC data.

# scratch that.

I just read up on time-to-digital converters. Maxim (e.g. MAX35102) and TI offer such (other company certainly, too).

As far as I read this, there's different approaches, but the TI TDC7200, for example, uses an internal ring oscillator (which runs at pretty high speeds, giving you high resolution) to run a counter.

The ring oscillator is disciplined against an external clock, so you'll have to make sure your accuracy needs are met by the quality of that clock.

• I would personally try abusing an FPGA deserializer. It is possible to get relatively low end FPGAs that have serializers capable of >1Gbps, which should provide at least 1 ns resolution. It may be necessary to do some external calibration to get the absolute delay nailed down, though. – alex.forencich Apr 18 '17 at 5:03
• Thank you to you and everyone who recommended a TDC! It took some researching to find one with a short enough measurement range, but fortunately TI makes the TDC7201 which goes down to 0.25ns and is similar to what you suggested. I think I'll give this a go! – inushii Apr 18 '17 at 15:08

It is possible to generate high accuracy timing with a variety of tricks; the action of an MCU on interrupt, however, is unlikely to be of such precision.

One option is to start an oscillator, and beat it against a reference oscillator vernier time measurement . This requires an oscillator that can be started in a known phase (usually, a delay line and inverting gate), and a time reference, with a phase detector. The phase detector gives a fine-adjust correction to apply to the coarse timing afforded by conventional counter timing.

The vernier timer requires a long time, so a modest clock (20 MHz) can proceed for a hundred-count while the phase measurement is being completed. It can thus take several microseconds to complete a 1 ns time determination.