1. Home
  2. Field-Programmable Gate Arrays
  3. Measuring the period of a signal

Measuring the period of a signal

Hi, I am trying to measure an input signal that will be a square wave of a certain unknown frequency in the range 1MHz to 4 MHz using an FPGA. I have no control over that input signal. The FPGA should be able to track the signal as it changes. Usually there is a +-5% max shift in frequency from time to time. There is no reference clock for this signal.

I am not sure a simple counter will be an effective solution in this case. I am afraid of setup time issues since the internal FPGA clock will not be synchronized with the external signal. Can one phase lock two signals easily in an FPGA? I would probably need a counter running at 400 MHz to effectively to measure a 1% change in a 4MHz signal accurately.

I am wondering if there is an asynchronous solution to this issue that might be more effective. Any ideas would be highly appreciated. Thanks a lot, Amish

Reply to
axr0284
Loading thread data ...

You can measure with a simple counter if you look at the average over several pulses rather than just one period. If you used asynchronous solutions to try to phase lock, that phase lock takes many cycles to become stable and reduce the error.

I have used a simple counter and run the count value through a simple low pass filter to have displayed results to high accuracy. An average can be taken over n pulses by accumulating a count over those n pulses, not individually. The only caveat to using simple counts is that the first and last edges can both be slightly off if the clocks are lining up. The count error will be barely more than +/-1 from ideal for the worst case whether you're sampling 1 or 100 pulses.

To get around the asynchronous sampling problem, just use a syncronizer for your input frequency to sample it into your counter time domain. If you detect in the counter's clock domain when the input frequency transitions, the clock sample will have the standard setup/hold time for the counter clock's domain. It's the single synchronizer that can violate the setup/hold time with little concern.

So use a clock frequency you're comfortable with (40 MHz? 100 MHz?) and use a counter to measure several pulses.

If you need extreme accuracy *per pulse* then your task is beyond simple FPGA design though the task is achievable. Don't overstep your requirements if a simple design will suffice.

Reply to
John_H

You have two options:

1) oversampling: use a much faster system clock to sample, detect and count transitions to determine the pulse width

2) use your input signal as the clock for a gray-code counter, capture, decode and compare that against another counter running on the system clock

The second approach is used by precision frequency meters - all they need to do is a periodic difference between counts. These often use 1MHz internal clocks and simply count to 100k/250k/500k/1M/10M between diffs (depending on selected scale and precision) and output updates. If you need tight temporal granularity, oversampling (count the number of fastclk cycles between N slowclk transitions, select N as a power-of-two for convenience: fixed-point average for free) is probably best.

Reply to
Daniel S.

Thanks for the help, I will try to test all the solutions to see which one fits my needs. Thanks a lot, Amish

Reply to
axr0284

You forgot to mention how often you need this information updated ?.

If you need to know on every single cycle, then yes, you need 2.5ns precision (which does not have to 400MHz, it can be 100MHz with 4 phases) If you do not need the info on every cycle, but just want to track slower changes in speed, then the task becomes simpler - a 7bit frequency counter will resolve to < 1%, or you can create a hybrid- eg if you measure over 10 cycles, a 40Mhz clock will give 1% resolve at 400KHz measurement bandwidth.

-jg

.
Reply to
-jg

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.