How to create fraction of a tick delay in LabVIEW FPGA?

[ethen99999]

Hi

I am trying to add more resolution to my counter by adding delays between counters . Using feedback nodes the best delay I can get using 40MHz internal clock is 25ns but I want to get delays much finer than this 

Is the below logic works for ns and less than ns delays? 

Below I can use counter to count edges for signal and delayed signal and then I can keep add more AND logics to give more delays . 

Does a logic like this work?

[James_McN]

Hi Ethan,

No this won't work as you described. Because this is a single cycle timed loop the and doesn't cause any delays (and should get optimised away).

This depends on where you want delays to apply and how tight you want them to be. You can run the loop at higher rates and if you can put the signal to delay in that loop you may be able to achieve say 10ns.

Tighter than that and you will struggle to do it in LabVIEW. For IO some FPGAs have delay units that can provider finer delays, or perhaps a clock manager can do something if it is a delayed clock your after.

You will need to provide a few more details to know what the best answer is

[ethen99999]

Thanks James for the quick response. 

Yes , 1 solution is to run on higher internal rates like 100MHz or 200MHz if I can compile the code , but I am really looking for picoseconds delays 

I thought by giving the extra AND logic I can delay the signal a little bit so then counter can detect rising/falling edges on a delayed signal . 

A delayed clock also works for my application . Basically I have to delay either the clock or the input signal so I can detect a time period of 1 cycle and then inverse of that can give me the frequency 

Could you please provide more information which FPGAs have the ability to delay the clock or have finer delays on IO? and can I configure them in LabVIEW FPGA ?

[James_McN]

So you are attempting a frequency measurement?

This isn't something that can be done in LabVIEW I don't believe. I think it is tricky on any FPGA.

Internally to the FPGA the storage and therefore counter must be run off the internal clocks. Because of propogation delay these tend to max out at 200/250MHz.

So if you need picoseconds it has to be done at the edges. If your on a flexRIO you can use IODelay blocks (in the VHDL CLIP) which can be configured for some sub-ns delay. This can only skew the signals though and you can't detect that skew in the FPGA because it is too small.

The other idea I have is that if you generate another clock using a clock manager (probably needs a xilinx IP block or CLIP node) you can achieve certain phase shifts between clocks. I'm not sure if that helps or not.

None of these will let you count with sub-ns resolution but not sure if it might help you. This sounds quite complex though and maybe if you can explain what you are trying to do in the simplest way there maybe another way to achieve it.

Are you trying to measure the frequency of an input signal? What are the frequency ranges? What hardware are you running on?

[ethen99999]

Yes I am trying to do frequency measurements from 500kHz to 80MHz with 1ppm accuracy . I heard I can provide very precise external clock to PXIe backplane and sync the internal clock of FPGA ( since they have pll ) to that signal so I guess I should not be worry about the FPGA internal clock low accuracy and bad jitter 

But then next big issue is if I want to just count edges for frequency measurement then my captures has to be very long for better resolution. The other way to measure frequency is to detect time period and then measure frequency . This way the measurement is so fast since I only care about 1 complete cycle.

To do it with FPGA I thought I can delay either clock or input signal and keep sampling the delayed signal until I can detect 1 full cycle . By calibrating the process and counting the number of delays then I can calculate time period 

But this means I should delay the signal/clock in fraction of ns 

Again I thought by adding extra logic ( like AND ) I can add a delay to input signal but seems like I was wrong 

I don't need to really detect each skew in the timed loop , the idea is to continuously delay the signal until the timed loop can detect it . If I know for a known signal how many skew shift can give me 1 cycle then I can calibrate it ( not sure if it is linear ) to calculate any frequency . This is really a repetitive process and it is okay if I miss any skew in the timed loop

Now the question is how can I delay clock or input signal in picoseconds in the FPGA ( preferably using LabVIEW FPGA) - I am not very familiar with VHDL ?

[James_McN]

OK that makes sense. I don't think these delays will help as they are fixed (for the clock phase) or semi fixed (IO delays provide 32 steps at 10s ps per step).

There are generally 2 ways of achieving a frequency measurement - one is to use a counter of a faster clock to measure the period of the signal (I think this is what you are proposing). The other is to count the number of pulses in the period of a slower clock.

The way you are proposing it is very difficult or impossible at these speeds. Maybe there are some DSP tricks I don't know of but fundamentally you are hitting some hard limits.

A single period at 80MHz is 12.5ns. So to achieve 1ppm you would need a sub-picosecond accuracy so that just isn't possible.

Reading your comment again you talk about keeping it delayed so I think you are trying to stretch out the period to something you can read. This may be better achieved by using a clock divider or frequency divider to drop the frequency - but off the top of my head I think this will end up with a capture at a similar length as the second method anyway.

Frequency division can be quite straightforward though. I'm thinking aloud a bit here. Lets assume we can achieve a 100MHz counter, that gives a 10ns measurement resolution. For that to be 1ppm that means we need to be measuring over 10ms. Even at 200MHz that is 5ms. That means quite a step down though and you are back to a longer measurement time. (This is method 3 used by NI dedicated hardware, see https://www.ni.com/en-gb/support/documentation/supplemental/06/making-accurate-frequency-measurement...). How fast do you need the measurement time to be?

Doing a search just turns up a bunch of academic papers which I don't have access too. I suspect there are some other approaches based on modulation techniques but these probably need some analog electronics ahead of the FPGA. You are into another ball park here.

I'd love to hear if anyone else has any ideas though.

[Kevin_Price]

I can't really add anything new to what James_McN already covered, I can only add emphasis and a little sanity check.

Attempting to measure a single interval as small as 12.5 nanosec with 1ppm resolution (which is not quite the same as accuracy after all), requires a measurement system that can resolve at *least* 1 million times as small a time interval.  As James_McN already pointed out, that puts you into small fractions of a picosecond which I don't believe to be even remotely feasible.

In the other method, you need to wait for at *least* 1 million intervals of your signal to get 1ppm resolution.  For your faster 12.5 nanosec intervals, that means at least 12.5 msec.  And for slower frequencies, you need to wait longer.

To my eye, you've got yourself boxed in with incompatible constraints.  Measuring individual 12.5 nanosec intervals to 1ppm hits a physics wall and is a non-starter.  That leaves you with 2 constraints that trade off against one another pretty directly:

- # ppm you can resolve for the measurement

- time it takes to receive enough cycles to achieve that #ppm

I can't speak to the FPGA side, but here's something you could try, at least in theory, with a DAQmx counter device:

- run a buffered task that gives you 1000 ppm resolution

- use a sliding window technique in post-processing to analyze this in blocks of 1000 measurements

- this gets you a series of ~1ppm results that are separated by only a thousand intervals of your signal rather than a million.

- however, you don't get these results in real time.  You still start with a 1 million cycle delay before your first result, it's just that each result thereafter comes only 1 thousand cycles later.

- Breaking down as 1000x1000 is just for illustration.  You can trade those numbers off other ways as long as the product is >= 1 million.

-Kevin P