Mircro-controller designs to generate nano second pulses with variable delay.

[fracton]

For another project, I am trying to build a controller circuit that can generate four 50ns second pulses with variable delay upon receiving a TTL pulse as a trigger (with a repetition rate of 10Hz). While I have a low duty cycle application, I was hoping to build something that could operate atleast at a kHz repitition rates. I am considering to use Teensy4.1 for this application, I am guessing just counting for CPU clock cycles to give out pulses on the output pins should work. However, I am a beginner and have lilttle to no experience with microcontrollers. Would appreciate any help for any useful comments.

[Andy Chee]

Can you sketch out a few example timing waveforms?

Or even better, please provide the datasheet of the thing you are trying to control!

[JPortici]

I'm a bit unsure about the 50ns, but you *should* be able to do it with a dsPIC33CK high speed PWM. You also have a retriggerable mode with a retriggerable counter, so you can generate up to 7 pulses after a trigger

[pcprogrammer]

There are of course many solutions to your problem, but using hardware timers that are available in many MCU's will make it more robust than counting CPU cycles. The nano seconds timing you like limits things to MCU's that can run on higher frequencies.

The Teensy 4.1 certainly falls in this category and has timer peripherals that can create the pulses and the delays you need. The software only has to write the registers to set the durations. Get yourself the datasheet and reference manual to find out more about the capabilities of this MCU. To get the reference manual you have to create an account at NXP though.

[Siwastaja]

E.g. STM32H7 series HRTIM (which is a downgraded version of earlier HRTIM without the analog extra time resolution trickery) can run at 400MHz, giving nice 2.5ns steps, so accurate 50ns is doable, so it depends on the needs of those "variable delays", but I assume 2.5ns resolution for the delays would be fine, too?

[PCB.Wiz]

For another project, I am trying to build a controller circuit that can generate four 50ns second pulses with variable delay upon receiving a TTL pulse as a trigger (with a repetition rate of 10Hz). While I have a low duty cycle application, I was hoping to build something that could operate atleast at a kHz repitition rates. I am considering to use Teensy4.1 for this application, I am guessing just counting for CPU clock cycles to give out pulses on the output pins should work.

Broadly, yes.
You need to define the tolerance and granularity on the delays and pulses.
Any small MCU can wiggle pins at opcode speeds, but pulses and delays will be quite granular, as will the response time and jitter from the trigger pulse.

You could also look at the Pi PICO RP2040 or newer RP2350 PIO modules.
Those can wait on a pin, then delay and pulse, with opcodes speeds IIRC of 150MHz on the RP2350, so that improves your granularity

[pcprogrammer]

The STM32F334 has 217 pico second resolution timers, but getting a board with one of those might not be as easy and cheap as a H7 variant.

On the other hand, the STM32G474 has 184 pico second resolution timers, and can easily be found on Aliexpress.

As I wrote earlier, there will be many solutions for the problem. Choosing the right MCU is one of them.

[Siwastaja]

The STM32F334 has 217 pico second resolution timers, but getting a board with one of those might not be as easy and cheap as a H7 variant.

Yeah, that's the analog trickery HRTIM I mentioned above. Be careful with it though, it is not an actual digital timer with that much resolution, so it has "terms and conditions". Like, you cannot sample an input with such accuracy, therefore cannot create delay from input trigger to output with that resolution. It's only mainly for high-resolution pulse width modulation and even then comes with maximum and minimum duty cycles.

So the later H7 "crippled" HRTIM which runs at 400MHz or 480MHz is in many ways "better" and easier to understand. And something similar is probably available on nearly every high-end microcontroller.

[fracton]

Can you sketch out a few example timing waveforms?

Please see the attached image. I need 2 sets of pulses with variable delay between them i.e delay between (1,2) and (3,4) is can be fixed (50-100 ns) while I need to have control over the delay between the two sets.

Or even better, please provide the datasheet of the thing you are trying to control!

The "thing" I am trying to control are MOSFET gate drivers of switching circuit I am trying to build.

 

[Andy Chee]

Or even better, please provide the datasheet of the thing you are trying to control!

The "thing" I am trying to control are MOSFET gate drivers of switching circuit I am trying to build.

What are your MOSFETs controlling? 

If it's a stepper motor, rail gun coils, or something mechanical, then such mechanics cannot respond to your tiny nanosecond pulses.

[pcprogrammer]

Looks like the interval is a multiple of the 50ns pulse. If that is indeed the case timers clocking at 20MHz should be capable of pulling this of. Have the TTL signal trigger an interrupt and in the interrupt routine start a timer and use compare settings to generate the pulses. I think this can even be done with a STM32F103C8T6 found on the bluepill.

[fchk]

A FPGA (even a small one) would be perfect for this task. Since everything is logic dates driven by a stable clock timings can be 100% accurate and repeatable.

The logic inside this FPGA would be a simple counter and some comparators that compare the counter value to some preset and set or reset a RS flipflop.

[pcprogrammer]

A FPGA (even a small one) would be perfect for this task. Since everything is logic dates driven by a stable clock timings can be 100% accurate and repeatable.

The logic inside this FPGA would be a simple counter and some comparators that compare the counter value to some preset and set or reset a RS flipflop.

Absolute, but the OP stated to be a beginner, so a FPGA might be even more difficult than using a MCU.

[Siwastaja]

A FPGA (even a small one) would be perfect for this task. Since everything is logic dates driven by a stable clock timings can be 100% accurate and repeatable.

Oh, FPGA would be "perfect" for any task. But this task is 99% likely one for which market is full of well-suited microcontrollers. Which are one tenth of price of FPGA and require one tenth of design complexity.

But of course devil is in details, so to confirm this more information about what OP is actually doing is necessary.

[pcprogrammer]

The STM32F334 has 217 pico second resolution timers, but getting a board with one of those might not be as easy and cheap as a H7 variant.

Yeah, that's the analog trickery HRTIM I mentioned above. Be careful with it though, it is not an actual digital timer with that much resolution, so it has "terms and conditions". Like, you cannot sample an input with such accuracy, therefore cannot create delay from input trigger to output with that resolution. It's only mainly for high-resolution pulse width modulation and even then comes with maximum and minimum duty cycles.

So the later H7 "crippled" HRTIM which runs at 400MHz or 480MHz is in many ways "better" and easier to understand. And something similar is probably available on nearly every high-end microcontroller.

I took a look at the reference manual for the STM32G4 series and the HRTIM is indeed a complex beast. Would be fun to play with, but I have no test equipment that can check if it can actually create pulses with the 184ps resolution. You are on the dot with the "terms and conditions" it comes with. 

[fracton]

A FPGA (even a small one) would be perfect for this task. Since everything is logic dates driven by a stable clock timings can be 100% accurate and repeatable.

But of course devil is in details, so to confirm this more information about what OP is actually doing is necessary.

I am currently trying to build a High Voltage pulse generator circuit for a time-of-flight experiment using high voltage SiC MOSFETs. The HV pulse generator basically is sits between a HV power supply and a capactive load, driving it during the duration of pulse.

The HV and the control sides of circuit are galvanically isolated using pulse transformers. To drive the gate capacitance of the MOSFETs on the HV side, I use high-speed MOSFET gate drivers that give out pulses upon receiving an input trigger. I only want provide the pulse generator a single external trigger, from which I plan to generate four pulses to sequetially charge and discharge the gate capacitance of the MOSFETS to generate a HV pulse. Further, in my current application the external trigger pulse has a repitition of 10Hz, while this could easily go upto 10's of kHz for other applications.  Unfortunately, I don't have a neat schematic of my circuit, but it is largely based on this design (see the attached pdf) from a related textbook.

[fracton]

A FPGA (even a small one) would be perfect for this task. Since everything is logic dates driven by a stable clock timings can be 100% accurate and repeatable.

The logic inside this FPGA would be a simple counter and some comparators that compare the counter value to some preset and set or reset a RS flipflop.

Absolute, but the OP stated to be a beginner, so a FPGA might be even more difficult than using a MCU.

I have some decent amount experience in working with C/C++, Fortran and Python. I could give it a try to program an FPGA. But, my only concern is the cost. I'm looking for a low-cost alternative that it robust enough to give these 4 pulses with minimal jitter and without any false triggering.

From the inputs, I got from this thread, I'd try dsPIC33CK high speed PWM suggested by @JPortici as well as the  the HRTIM option with the STM microcontrollers suggested by @Siwastaja and @pcprogrammer. Can any of you, comment on the jitter and timing issue, if any with either of these options.

[nctnico]

A FPGA (even a small one) would be perfect for this task. Since everything is logic dates driven by a stable clock timings can be 100% accurate and repeatable.

The logic inside this FPGA would be a simple counter and some comparators that compare the counter value to some preset and set or reset a RS flipflop.

Absolute, but the OP stated to be a beginner, so a FPGA might be even more difficult than using a MCU.

Not necessarily. There are tons of simple FPGA boards out there. Tang nano with a Gowin FPGA for example. A few lines of VHDL will do the trick. As a teenager I was using programmable logic as much as microcontrollers already. And nowadays the tools have become much easier to use and more powerful.

[fracton]

Looks like the interval is a multiple of the 50ns pulse. If that is indeed the case timers clocking at 20MHz should be capable of pulling this of. Have the TTL signal trigger an interrupt and in the interrupt routine start a timer and use compare settings to generate the pulses. I think this can even be done with a STM32F103C8T6 found on the bluepill.

- what is the required latency

<100 ns, anything more than that would significantly increase the dead time of my device.

- what is the accuracy of pulse placement - for example, you want 150 ns delay, is 140 ns Ok, or 160 ns - what is the biggest allowable deviation from the requited 150 ns?

- what is the desired accuracy of the pulse width?

+/- 5-10 ns would be an acceptable accuracy for the intended application.

- how fast must be the edges - if the rise time is 5 ns, is that Ok, how about 20 ns?

The intended application of this timer circuit is to control an ultrafast HV pulse generator. The desired rise and fall times should ideally be <10-15 ns.

- does the response pattern change, or is it always the same?

As I explained in one of my replies, the delay between first two pulse and the last two pulses has to be variable. Ideally, these delays could vary between the two sets of pulses 100ns to 100's microseconds.

[nctnico]

Looks like the interval is a multiple of the 50ns pulse. If that is indeed the case timers clocking at 20MHz should be capable of pulling this of. Have the TTL signal trigger an interrupt and in the interrupt routine start a timer and use compare settings to generate the pulses. I think this can even be done with a STM32F103C8T6 found on the bluepill.

- what is the required latency

<100 ns, anything more than that would significantly increase the dead time of my device.

You might be able to pull this off with a microcontroller which has a programmable timer (=a timer which can do things automatically based on inputs changing). But this timer would need to run at at least 100MHz (10 ns cycle time). And even then I'm not sure a 100ns latency is feasible with the degree of flexibility you want to achieve. Keep in mind that the event inputs will be sampled using the clock which drives the timer. This adds latency especially if the inputs go through a debounce/filter circuit.

Have you considered looking at a multi-output function generator or some kind of digital pattern generator? Using an off-the-shelve unit would save you quite a bit of effort compared to building something like that from scratch.

[PCB.Wiz]

I have some decent amount experience in working with C/C++, Fortran and Python. I could give it a try to program an FPGA. But, my only concern is the cost. I'm looking for a low-cost alternative that it robust enough to give these 4 pulses with minimal jitter and without any false triggering.

Did you look at the Raspberry pi pico ?
The PIO engine on that can give lower trigger jitter and delay, than a MCU interrupt design.
That’s much cheaper than a fpga, and has modest SW complexity.

Latency <100 ns, anything more than that would significantly increase the dead time of my device.
+/- 5-10 ns would be an acceptable accuracy for the intended application.
As I explained in one of my replies, the delay between first two pulse and the last two pulses has to be variable. Ideally, these delays could vary between the two sets of pulses 100ns to 100's microseconds.

The Pico PIO will have sampling granularity of  appx 7ns, so that sets your response jitter.
There is a latency delay of InPin -> sampler -> state engine -> sampler -> OutPin which will be 2-4 clks + a few ns. Should be well under your 100ns - I'd guess 21-49ns ballpark, with 7ns jitter.
 
Subsequent Edge to edge timing will be low jitter, and you could adjust the PIO PLL to fine tune that, if 7ns steps are too coarse.
eg pick 100Mhz for 10ns ruler, 90.9 MHz for 11ns ruler and 111MHz for 9ns ruler etc

If sampled clock delay quantize is too large for you, you could move into the somewhat analog domain with a Monostables, or triggered VCO+counters or Delay lines (ADI have a series )

[nimish]

The STM32F334 has 217 pico second resolution timers, but getting a board with one of those might not be as easy and cheap as a H7 variant.

Yeah, that's the analog trickery HRTIM I mentioned above. Be careful with it though, it is not an actual digital timer with that much resolution, so it has "terms and conditions". Like, you cannot sample an input with such accuracy, therefore cannot create delay from input trigger to output with that resolution. It's only mainly for high-resolution pulse width modulation and even then comes with maximum and minimum duty cycles.

So the later H7 "crippled" HRTIM which runs at 400MHz or 480MHz is in many ways "better" and easier to understand. And something similar is probably available on nearly every high-end microcontroller.

The HRTIM is just a timer with a delay line attached (or DLL, iirc)

You can make them in verilog, CERN has a bunch of open source ones since ToF/TDC measurement is critical for them

[pcprogrammer]

I have some decent amount experience in working with C/C++, Fortran and Python. I could give it a try to program an FPGA. But, my only concern is the cost. I'm looking for a low-cost alternative that it robust enough to give these 4 pulses with minimal jitter and without any false triggering.

Having programming experience can be a burden when working with a FPGA. It is very different even though for example verilog has a lot of similar syntax to C. For "programming" a FPGA a HDL is used which is a hardware description language. So you have to think hardware not software. The logic works in parallel and is not directly sequential like how things are done in software.

And yes there are cheap enough FPGA boards out there, even cheaper than STM32H7 boards, and maybe with a lot of example code that can be found on the net, it will need a lot of time if you are not used to thinking in digital hardware terms. There certainly is a learning curve to it that has many elements. At first the HDL, then a simulation environment and last but not least the vendor tools needed for the chosen FPGA.

It will definitely provide a very robust solution, but with the need for an adjustable delay between the two sets of pulses it also needs something like a state machine, a softcore or an external MCU to write the needed delay to a register in the FPGA.

From the inputs, I got from this thread, I'd try dsPIC33CK high speed PWM suggested by @JPortici as well as the  the HRTIM option with the STM microcontrollers suggested by @Siwastaja and @pcprogrammer. Can any of you, comment on the jitter and timing issue, if any with either of these options.

Jitter depends mainly on the quality of the crystal and the clock hardware in the MCU. Latency depends on how fast the MCU runs and it's interrupt handling system, if this is used of course. A more hardware based solution like in the Raspberry Pico it will be different, like clearly explained by PCB.Wiz.

I have some decent amount experience in working with C/C++, Fortran and Python. I could give it a try to program an FPGA. But, my only concern is the cost. I'm looking for a low-cost alternative that it robust enough to give these 4 pulses with minimal jitter and without any false triggering.

Did you look at the Raspberry pi pico ?
The PIO engine on that can give lower trigger jitter and delay, than a MCU interrupt design.
That’s much cheaper than a fpga, and has modest SW complexity.

Latency <100 ns, anything more than that would significantly increase the dead time of my device.
+/- 5-10 ns would be an acceptable accuracy for the intended application.
As I explained in one of my replies, the delay between first two pulse and the last two pulses has to be variable. Ideally, these delays could vary between the two sets of pulses 100ns to 100's microseconds.

The Pico PIO will have sampling granularity of  appx 7ns, so that sets your response jitter.
There is a latency delay of InPin -> sampler -> state engine -> sampler -> OutPin which will be 2-4 clks + a few ns. Should be well under your 100ns - I'd guess 21-49ns ballpark, with 7ns jitter.
 
Subsequent Edge to edge timing will be low jitter, and you could adjust the PIO PLL to fine tune that, if 7ns steps are too coarse.
eg pick 100Mhz for 10ns ruler, 90.9 MHz for 11ns ruler and 111MHz for 9ns ruler etc

If sampled clock delay quantize is too large for you, you could move into the somewhat analog domain with a Monostables, or triggered VCO+counters or Delay lines (ADI have a series )

Using the Pico PIO part also has a bit of a learning curve, but so do the other solutions with timers found in MCU's. It might be the best in between solution though.

[peter-h]

I did FPGA/ASIC design consultancy (Xilinx) for many years and although FPGA software is now a lot better I would still do anything with a microcontroller if at all possible. With FPGAs you sink a lot of time and learning curve climbing into an area which is a dead end... not what I want to do with my life. With code, you are learning useful stuff almost all the time.

We still don't have the spec for this project, have we?

A 480MHz CPU ought to be able to waggle a GPIO pin with a ~2ns resolution - assuming the GPIO clock is actually 480MHz in the fastest-GPIO mode. Any better, one might do it with PCB tracks of different lengths (1ns is about 2cm?) and then use the CPU to switch a mux selecting different taps. IOW, a DIY delay line.

[PCB.Wiz]

The "thing" I am trying to control are MOSFET gate drivers of switching circuit I am trying to build.

Some more thoughts on this :
If the clock-sampling jitter on the trigger pulse is a problem, a hybrid solution might work.
Use chained monostables for the immediate 'close in' two output pulses, will give you sub-ns jitter and analog precision of delays and widths.
Then, the further out pulses, of 1us+ are probably ok with clock based pulses. The % error is quite small of 7ns in 1us