Extending a 1ns pulse

[BreakingOhmsLaw]

Hi everyone,

I am designing a timer for my kids school with a 1ns resolution to enable them to measure the speed of light in the lab.

So far, I designed a 1GHz OCXO that feeds into a 1,5GHz ECL 8-bit binary counter that provides the lower 1ns resolution digits and divides the 1GHz by 250.
When that counter overflows, i get a 1ns negative pulse on a pin. Now, that is *technically* a 4MHz signal, but the pulse is much too short to be detected by the STM32 timer input, as that requires several clock cycles to detect a logic level depending on the APBCLK frequency.

My normal go-to solution would be a monostable multivibrator to extend that pulse, but they mostly need a 5ns input pulse themselves.
So i'm considering preceding that multivibrator with a fast D-type flip-flop like the 3GHz SY10EP51 and feed the pulse into its clock input. That part will work down to ~320ps pulse with, so that should be fine. Resetting the flip-flop again would be done by the multivibrator to "arm" it for the next pulse.

That should work, but does anyone know of a better or more elegant solution?

[Mahagam]

Everything can be done in one Spartan-6 FPGA (speed grade 3). You can create a logic to measure length of the pulse with 1ns resolution, and send measured value to MCU via uart or whatever you want.

[BreakingOhmsLaw]

Everything can be done in one Spartan-6 FPGA (speed grade 3). You can create a logic to measure length of the pulse with 1ns resolution, and send measured value to MCU via uart or whatever you want.

I though of that, but I'm building this on my home lab. While I have a Fritsch LM901 manual pick-and-place machine and a reflow oven, any large BGA parts are going to be hard to check for quality. My wife just won't clear the budget for an x-ray machine, can you believe it? 

[pcprogrammer]

I'm not sure if it can be done with a Spartan-6 FPGA. 1GHz is close to the limits of the IO and the internal fabric. But there are standard boards available with a Spartan XL9 or XL16 for not to much money. And it does not have to be a BGA package. They also come in TQG144.

[BreakingOhmsLaw]

It's also been 20 years since I've last used Verilog, so FPGAs are not my comfort zone. My main focus is low noise analog circuit design, mixed signal, STM32 and T&M.

[nali]

Sounds like a job for a simple old-school SR latch set by the counter reset by the STM ISR which would be a couple of NAND or NOR gates depending on polarity (as long as you're comfortable that S & R won't happen simultaneously)

[Mahagam]

I'm not sure if it can be done with a Spartan-6 FPGA. 1GHz is close to the limits of the IO and the internal fabric. But there are standard boards available with a Spartan XL9 or XL16 for not to much money. And it does not have to be a BGA package. They also come in TQG144.

Spartan-6 ISERDES can fetch data at 1.08 Gsps rate. After deserialization of 1:8 is possible to get only 125MHz data rate clock.
And it seems its single unit project, so its possible to buy a cheapest board with Spartan-6.

[BreakingOhmsLaw]

Sounds like a job for a simple old-school SR latch set by the counter reset by the STM ISR which would be a couple of NAND or NOR gates depending on polarity (as long as you're comfortable that S & R won't happen simultaneously)

At 4MHz vs a 72MHz clock, the signal occurs every 18 clock cycles. Using the ISR to reset the latch isn't going to cut it. Just the PUSH & POP for the program counter around the ISR, branch & return, and a single MOV to output register and another MOV to reset the NVIC would the bare minimum required. That ads up to at least 8 cycles. *If* you hand build the ISR yourself with asm{} code and not leave it to the compiler. The compiler would probably push/pop all registers to the stack and need more than 18 cycles.
It might barely work, but it would not leave many cycles for the MCUs other tasks.

[Ian.M]

Hmm....
I'd run the flipflop reset through a 74LVC2G17 dual Schmitt buffer or similar, with a RC delay between its stages.   Pick a time constant to suit the MCU's min. timer input pulse duration with sufficient margin.   You can get away with a single Schmitt buffer if you don't care about the RC loading the output pulse, or even with no Schmitt at all if the RC risetime meets the flipflop's reset input requirements.

[pcprogrammer]

Which STM32 are you using for the project?

The cortex M series have hardware that takes care of interrupt context saving. Have not looked into how many clock cycles it all takes, and it probably is not fast enough like you concluded, but even though it comes every 18 clock cycles, ARM does more in one cycle then you think.

It might be possible to do it with timer hardware though. Use the signal to trigger the timer, and use a compare setup to toggle an output that resets the flipflop. The timer can run on 72MHz and if the trigger is used to start it and the compare sets the output a couple of clocks later it should work.

[Mahagam]

Ok. Lets imagine that you already have this extended pulse. But what is the time from rising edge to MCU react?

[BreakingOhmsLaw]

Which STM32 are you using for the project?

STM32F105VCT6

It might be possible to do it with timer hardware though. Use the signal to trigger the timer, and use a compare setup to toggle an output that resets the flipflop. The timer can run on 72MHz and if the trigger is used to start it and the compare sets the output a couple of clocks later it should work.

While that's true, the MCU has a bunch of other tasks like multiplexing a keyboard and a 10-digit 7-segment display. This could of course be disabled during the admittedly very short measuring time.
However, all the hardware function of the timer need several clock cycles to react (that's what got me into this problem in the first place.) The STM32 Timer cookbook has good insight o that.

[BreakingOhmsLaw]

Hmm....
I'd run the flipflop reset through a 74LVC2G17 dual Schmitt buffer or similar, with a RC delay between its stages.   Pick a time constant to suit the MCU's min. timer input pulse duration with sufficient margin.   You can get away with a single Schmitt buffer if you don't care about the RC loading the output pulse, or even with no Schmitt at all if the RC risetime meets the flipflop's reset input requirements.

1ns is the lower limit of an 74LVC2G17 (1.0ns to 7.1ns). Nexperia supplies a SPICE model for the part, i might run it through a simulation tonight, but I doubt it'd be reliable.
Maybe someone makes a faster version of it.

[BreakingOhmsLaw]

Ok. Lets imagine that you already have this extended pulse. But what is the time from rising edge to MCU react?

250ns. The timer needs 6 clock cycles to detect the pulse. 1 clock cycle @72MHz = 13,88ns x 6 = 83ns. More than enough. EDIT: Might actually be twice that depending on the clock configuration. Still enough though.

Once the pulse is long enough to count up the internal timer of the STM32, the overrun of the 16 bit counter occurs every:
1ns x 250  x (2^16)  = 16.384ms

So, really slow in MCU terms.

[RoGeorge]

Leaving aside the technical details, I can not figure the experiment's setup.
Do you happen to have a block diagram of the physics experiment, please?

[Ian.M]

Hmm....
I'd run the flipflop reset through a 74LVC2G17 dual Schmitt buffer or similar, with a RC delay between its stages.   Pick a time constant to suit the MCU's min. timer input pulse duration with sufficient margin.   You can get away with a single Schmitt buffer if you don't care about the RC loading the output pulse, or even with no Schmitt at all if the RC risetime meets the flipflop's reset input requirements.

1ns is the lower limit of an 74LVC2G17 (1.0ns to 7.1ns). Nexperia supplies a SPICE model for the part, i might run it through a simulation tonight, but I doubt it'd be reliable.
Maybe someone makes a faster version of it.

Its not a 1ns pulse *after* the flipflop, so slow is OK.  You probably want to shoot for a >100ns output pulse so your worst case 7.1ns propagation delay per Schmitt buffer is an order of magnitude better than required.

[BreakingOhmsLaw]

Leaving aside the technical details, I can not figure the experiment's setup.
Do you happen to have a block diagram of the physics experiment, please?

Documentation is not finished, but the setup is quite simple: The timer has two BNC inputs, A and B. A starts the timer, B stops it.
A photo detector is connected to both inputs. The detector creates a short pulse when a certain intensity threshold is met.
The optical input for both detectors is an optic fibre of different lengths. Input B fibre is typically >100m longer. So students can have some fun running the fibre through their school, across the hall etc.
Then both inputs are placed together and you use a simple flashlight to do the measurement. They can then compare their calculation to the nominal value of the optic fibre.
Right now we use a Hameg HM8211 or 8123 for that, but that unit is obsolete (and very expensive). Frequency counters have gone out of fashion, and the ones you can still buy mostly come without the interval measurements needed for the experiment. So this whole project is really just a replacement for the Hameg's 8122/8123 interval measurement.

An alternative acoustic detector has a microphone. Student can clap their hands or a clapper board to measure the speed of sound.

[BreakingOhmsLaw]

Its not a 1ns pulse *after* the flipflop, so slow is OK.  You probably want to shoot for a >100ns output pulse so your worst case 7.1ns propagation delay per Schmitt buffer is an order of magnitude better than required.

The datasheet is unclear on the subject, so i have assumed that an Input signal below the propagation threshold will not reliably trigger the output.

[Ian.M]

A bigger issue will be logic level compatibility with the fast flipflop.  You may need to use a similar logic family for the reset delay, and put a comparator or line receiver between the flipflop and the MCU

[Mahagam]

So this whole project is really just a replacement for the Hameg's 8122/8123 interval measurement.

It seems, that it can be replaced with oscilloscope with high bandwidth.

[BreakingOhmsLaw]

It seems, that it can be replaced with oscilloscope with high bandwidth.

That is true, of course, but from an educational point of view, the scope has big disadvantages.
Students that perform this experiment are typically 11-13 years old. A scope with 30+ buttons is a very daunting piece of equipment, and thus would need to be operated by the teacher. That takes a lot of the fun out of it. Or you would need to first teach the students to operate an oscilloscope before they can even start the experiment. And I'm sure that you still remember the time you learned to "ride a scope". To you and me, that's something we don't think about twice, as it has become second nature. To a student, that's an unnecessary hurdle.
The timer that we are building is very accessible. It has a simple button to arm the next measurement and then displays the time. Easy peasy, and you can concentrate on the experiment.

[pcprogrammer]

Which STM32 are you using for the project?

STM32F105VCT6

So similar to F103, but with more stuff and pins.

It might be possible to do it with timer hardware though. Use the signal to trigger the timer, and use a compare setup to toggle an output that resets the flipflop. The timer can run on 72MHz and if the trigger is used to start it and the compare sets the output a couple of clocks later it should work.

While that's true, the MCU has a bunch of other tasks like multiplexing a keyboard and a 10-digit 7-segment display. This could of course be disabled during the admittedly very short measuring time.
However, all the hardware function of the timer need several clock cycles to react (that's what got me into this problem in the first place.) The STM32 Timer cookbook has good insight o that.

The setup I have in mind does not use CPU power while running. It needs to be setup and then it takes care of itself. It will require dedicated pins to be free though. It is an interesting challenge. 

Response time has to be well within 250ns for it to work, so at 72MHz clock less then18 cycles. Timer response time according to what you found 6 cycles, let it count 2 cycles and the compare maybe also needs a couple of cycles to output, so should be possible. Another timer can be used to count the actual 4MHz pulses. Needs an other external connection.

[RoGeorge]

...
The optical input for both detectors is an optic fibre of different lengths.
...
a replacement for the Hameg's 8122/8123 interval measurement.

It's clear now, thank you.

...
That should work, but does anyone know of a better or more elegant solution?

Wouldn't be more convenient to use a dual channel oscilloscope, instead of building a dedicated counter?

A low entry 4 channels DSO, e.g. Rigol DS1054Z, would be able to visualise the pulses, one on each channel.  Fastest sweep is 5ns/division, and a division is about 1cm on the screen.  Max sampling rate is 1Gsa/s, so 1ns is visible, and the signal can be frozen on the screen for more detailed inspection/explanations.  In fact, for 2 channels is half of 1Gsa/s, but 1ns is about 30cm, so 100m of optical path is no problem to see, even with the slower 2ns resolution. (3 or 4 channels simultaneous is done at 1/4 GSa each).

Then, with the oscilloscope, the same experiment can be repeated with electric impulses in an electric cable, instead of light.  By doing time domain reflectrometry (TDR) with an electric cable, no photodectors would be needed, and while sending the pulses to the cable, the other end can be snipped away shorter and shorter, live, so the students will see the reflected pulses coming back faster and faster while they keep snipping away from the other end of the cable.  Eventually a 3rd oscilloscope channel can be used , etc.

Any school should have an oscilloscope for the physics classes.  Nothing can beat "seeing" the results as a waveform.

If the school can afford an oscilloscope about $3-400 before taxes, see the exact price for EU at www.batronix.com.  Maybe pay a 100 extra to get a 4 channel oscilloscope that also includes a signal generator, like DS1074Z-S.  Batronix offers some other models from Siglent, too, or more expensive brands like Rohde & Schwarz.

[BreakingOhmsLaw]

The setup I have in mind does not use CPU power while running. It needs to be setup and then it takes care of itself. It will require dedicated pins to be free though. It is an interesting challenge. 

It certainly is. And it would probably mean falling asleep on the Cortex-M3 reference manual for several days 
At my regular hourly rate, It'd probably be cheaper to just spend the extra €60 in my BOM to cascade three more 8-bit ECL timers to end up with a true ECL 1,5GHz 32-bit counter 

[Chalcogenide]

My suggestion is to just use a fast ECL flip flop (for example MC100EPT51), data input tied high, clocked by the negative pulse, with an RC feedback network from its Q to its reset pin, that sets the duration of the output pulse. I have done it multiple times and in works to stretch/shrink pulses, although you might have to try a few R-C values to get the pulse duration you want.