Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Some advice in accuracy for a frequency counter using a spartan 6 fpga

Status
Not open for further replies.

moro

Member level 3
Joined
Jul 12, 2009
Messages
65
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,286
Activity points
2,013
Some advices in acurracy for a frequency counter using a spartan 6 fpga

Hello all,

i am trying to build up a counter for measuring high frequency signals less than 30MHZ.
For this ideea i was thinking of using a "reference clock" using a 10mhz ocxo trough a PLL to feed 100mhz at the fpga clock input.

On my fpga i will declare a 32bit counter, clocked at 100mhz (10ns/count)... and set to overflow at 20 000 000 counts.

On the "measured freq input" eveytime its detected a rising edge, i will store the current cnt value till the next rising edge... and do a "delta" to extract the measured period.

Is this feasable?


Thanks
 

Re: Some advices in acurracy for a frequency counter using a spartan 6 fpga

I think you have a mistake there. If your counter runs at 100MHz and your measured clock is 30MHz, then you will only count to 3 at most between rising edges.

Instead have a process clocked to the clock you are measuring and increment the large counter each time you have a positive edge. Then have another process on your reference clock (100MHz, but can be another value) that capture the counter value after exactly 1 second (100 million cycles). This will give you the exact count of rising edges during the 1 second. You don't have to use the PLL and make 100MHz, just use the 10MHz clock to determine 1 second.

At least that's how I would have done it.
 

Re: Some advices in acurracy for a frequency counter using a spartan 6 fpga

Hi,

100MHz counter
...and if you have an update rate of 1 per second
... this means a count of 100 000 000 per update

now take the square root of 100 000 000 and get 10000

this 10 000 is the limit where one method gives better resolution than the other:
With input frequencies less than 10 000 Hz its better to choose the time measurement method (moro´s solution)
With input frequencies more than 10 000 Hz its better to choose the edge_count method (whack´s solution)

For an update rate of 1s the counter needs to be able to count up to 100 000 000 .. this is 27 bit wide.
Then you are able to measure precisely frequencies down to 1Hz.


Klaus
 

Re: Some advices in acurracy for a frequency counter using a spartan 6 fpga

Hello

lets see if i understand this corectly

- i need "cnt1" whick ticks at 100mhz, and overflows at 100 000 000 ticks( 1 Hz rate)

- i need "cnt2" which ticks at the given input signal frequency.

For example i have a signal of 1MHZ to be measured

- cnt1 ticks at 10ns, its set to overflow at 1 second (100 000 000 counts), after which its reading cnt2?

- cnt2 ticks at 1us, so i increment counter2 variable... and set a overflow? how large should be the overflow value?

When cnt2 should be reseted? After each reading from cnt1?

I am a bit confused
 

Re: Some advices in acurracy for a frequency counter using a spartan 6 fpga

Hi,

you did not specify your desired update rate.
You did not specify your desired lowest input frequency.
You did not specify your desired resolution/precision.
Do you want to implement both methods in parallel? Or choose a single method.

Without your specifications we could write a whole book about frequency measurement....

Klaus
 

Re: Some advices in acurracy for a frequency counter using a spartan 6 fpga

I wrote a VHDL example of what I would have done. This will work for measuring from 1Hz to 100MHz, but you can make it go higher.

I did not test it. I only checked syntax, synthesized and implemented it for FPGA (targeted Spartan 3E).


Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
 
entity fcount is
    Port ( clk_measure : in  STD_LOGIC;
           clk_10Mref : in  STD_LOGIC;
              ready : out  STD_LOGIC;
              count_out: out std_logic_vector (31 downto 0);
              reset : in  STD_LOGIC); -- active high
end fcount;
 
architecture Behavioral of fcount is
 
signal counted: integer range 0 to 100000000 := 0; --100M range
signal timer: integer range 0 to 10000000 := 0; --10M range
signal finish : std_logic := '0';
 
begin
 
-- process to determine 1 second and update output
process(clk_10Mref, reset)
begin
    if (reset = '0') then
        if rising_edge(clk_10Mref) then
            if (timer = 10000000) then 
                finish <= '1';
                count_out <= conv_std_logic_vector(counted,32);
            end if;
            if (finish = '0') then timer <= timer + 1;
            end if;
        end if;
    else
        finish <= '0';
        timer <= 0;
    end if;
    ready <= finish and not reset;
end process;
 
-- process to count rising edges
process(clk_measure, clk_10Mref, finish, reset)
begin
    if (reset = '0') then
        if (finish = '0' and rising_edge(clk_measure)) then counted <= counted + 1;
        end if;
    else counted <= 0;
    end if;
end process;
 
end Behavioral;

 
Last edited:

Re: Some advices in acurracy for a frequency counter using a spartan 6 fpga

Hello Klaus,

- the lowest input frequency would be 1hz, because i am intrested in measuring a range of 1hz to 30mhz ( higher...better)

- the update rate should be faster than 1 second, but for the moment its enough ( i was thinking of 100ms n the future)

I am guessing the update speed is dictated on how fast cnt1 is sampling cnt2 ticks ?

If i set cnt1 to overflow at 200 000 000 ( 2 seconds) then i sample cnt2 i should have better resolution for low frequency signals?

I am a bit new in the fpga world :) its too much logic sometimes
 

Re: Some advices in acurracy for a frequency counter using a spartan 6 fpga

Hi,

Did you consider how to measure 1Hz with an update rate of 100ms?
This needs to be especially evaluated.

I am guessing the update speed is dictated on how fast cnt1 is sampling cnt2 ticks ?
I don´t see what you mean.

Sadly you didn´t say what method you want to choose.
I assume the "pulse counting method".

For sure you can just count pulses.
The precision will be about +/- 1 pulses. (Ideally +/- 0.5 pulses)
This means you can´t decide if it 0.5Hz or 1.0Hz, or 1.223345Hz or 1.499Hz. --> the result always will be either "0" or "1" or "2" without decimal precision.

If you want to measure 50Hz mains frequency for example, the it will show: "49" or "50" or "51", without decimal precision. (

While with the time measurement method you could prcisely measure 1.0000Hz and 1.0001Hz (even better)
But combining both methods you have a 4 digit precision at worst case:
1.0000Hz resolution better than 0.0001 Hz
10.000Hz resolution better than 0.001 Hz
100.00Hz resolution better than 0.01 Hz
1000.0Hz resolution better than 0.1 Hz
from 10 000 Hz up to 30MHz resolution 1Hz

Klaus
 

Re: Some advices in acurracy for a frequency counter using a spartan 6 fpga

Hello Klaus,
i am intrested in the time measurement method. I presume its the same method as from whack's code.

In essence the method, counts how many pulses occur in a interval of 1 second? Correct?
 

Re: Some advices in acurracy for a frequency counter using a spartan 6 fpga

You can also improve this by using the ISERDES modules along with a high-rate clock. You can then sample the IO multiple times per 100MHz cycle.
 

Re: Some advices in acurracy for a frequency counter using a spartan 6 fpga

Hi,

Time measurement method...
I'm surprised. Because there is bad resolution at high frequencies:
33 333 333 Hz
25 000 000 Hz
20 000 000 Hz
16 666 667 Hz
14 285 714 Hz
12 500 000 Hz
.... no values inbetween

Klaus
 

Re: Some advices in acurracy for a frequency counter using a spartan 6 fpga

You can also use both estimators.

For example, you can coarsely estimate frequency in terms of cycles within an update window, perhaps 250 ms. At this point you can choose a method that is based on time differences or number of cycles within the window based on which is most accurate. You can also improve results using various other methods, especially if the input does not have modulation.

The "Time measurement" method will be more accurate when the frequency is low. The pulse count method will be more accurate when the frequency is high.

There are also options to coarsely estimate frequency, then select a value N and perform a time measurement to reach N cycles.
 

Re: Some advices in acurracy for a frequency counter using a spartan 6 fpga

Hi,

Time measurement method...
I'm surprised. Because there is bad resolution at high frequencies:
33 333 333 Hz
25 000 000 Hz
20 000 000 Hz
16 666 667 Hz
14 285 714 Hz
12 500 000 Hz
.... no values inbetween

Klaus

Depends on what you mean by time measurement. I'm not saying the method I propose is best, but I don't measure time. My method counts clock edges over a fixed long period of time instead of measuring time between clock edges. It's "pulse count" in other words.

Accuracy is +0/-1 Hz over the entire frequency range. Frankly trying to measure high frequencies (in MHz range) with accuracy to 1Hz is probably a fundamentally flawed task because your reference clock has a ppm tolerance, it's not perfect to begin with, and you can have your 1Hz inaccuracy just from jitter alone, especially if you employ a PLL and such.

Result is always whole integer, no fractions, hence it always underestimates by up to 1Hz.
 
Last edited:

Re: Some advices in acurracy for a frequency counter using a spartan 6 fpga

Hi,

@whack
In post#11 I answered to moro's post#9.

***
I know the difference between time_measurement and pulse_counting...it's already explained in post#3.
***
Moro decided to use "time measurement".

Klaus
 

Re: Some advices in acurracy for a frequency counter using a spartan 6 fpga

Hello all,

today i managed to port the code from vhdl to verilog.... and do some simulations.

I used some small count periods, just to see the logic working as expected.

But what if i want to increase the speed?

If i want to read faster than 1 second? Then i should decrease the "clk" count period? and accept a tradeoff of not being able to measure low frequencies?

The design is going to fed the 32bit count data to a uart module, and i want to be able to send the data faster than 1second

For example i want to read with a speed of 100ms, how should i proceed?


Code:
        reg overflow;
        reg [31:0] counter = 0;
	reg [31:0] f_cnt =0;
	reg [31:0] value = 0;
	parameter f_cnt_max = 1000;
	reg ready = 0;
	
	initial begin
		// Initialize Inputs
	        f_clock = 0;
		clk = 0;
                overflow = 0;
		// Wait 100 ns for global reset to finish
		#100;
        end
     
        always #5 clk =~clk;                  // ref clock ticks at 10ns period
	always #10 f_clock = ~f_clock;   // measured clock ticks at 20ns period

  
  
	
	always @(posedge clk) begin
	    
 		 if(counter == 50) begin // if reached 1us second
                     counter<=0; // reset the ref_counter
		     ready<=1'b1; //
                     overflow <=1'b1;			  
		     value<=f_cnt; // store in a buffer
	             f_cnt<=0;
                  end			  
		   else begin
                          counter<=counter+1; //increment counter
			  ready <= 1'b0; // also activate frequency counter
			  overflow<=1'b0;
			 value<=0;
        	end	 
		
	end
	
	
	always@(posedge f_clock ) begin 	         
			                 
						if(ready == 1'b0) begin
                                                                if(f_cnt == f_cnt_max) begin 
							             f_cnt<=0;
							        end
							        else begin
							             f_cnt<= f_cnt+1;
							        end
					       end	
                                              else begin
                                                 f_cnt<=0;
                                              end					  
 end
  endmodule
fpga1.png
 

Re: Some advices in acurracy for a frequency counter using a spartan 6 fpga

You can push your data out of serial port with a simple FSM very easily. 100ms is not a problem at all.

I don't know what your intended application is, but if you just wanted to capture and see the data a software serial terminal may be a good solution.
 

Re: Some advices in acurracy for a frequency counter using a spartan 6 fpga

Hello whack

the intended aplication is a frequency meter where i measure clocks/pwms frequencys.

The aplication will comunicate with a pc-software via uart/rs232. Right now i am not worrying about uart comunication speed.

The concept is that i send a command to uart where i tell the fpga "measure the frequency please", then the fpga responds "this is the value (raw 32bit value) ".

But the counter data must be available for the uart in 100ms.

If i count till 1 second, to see how many "measured ticks" are in that interval, then i am limited to waiting 1 second before the data is available. correct? Only after 1 second i will be able to feed information to the uart line. Or?

Thanks
 

Re: Some advices in acurracy for a frequency counter using a spartan 6 fpga

Well, I figured you'd be sampling your signal continuously and your FPGA would be pushing out data at regular interval, that way you won't have to worry about two way communication, only one way. That's up to you entirely, just more work for two way communication.

If I understood correctly you want to measure wave period, the amount of time between edges in other words. If that's the case your data can be ready as soon as your logic detects the second edge, it's finished measuring time at that point. If you want to do it this way, then you'd just need to check to make sure you're not exceeding the data rate on the interface, otherwise you'd have to make it wait. So yes, it can be ready in 100ms, or a lot quicker than 100ms.

How did you come up with the 100ms number anyway? I thought you're measuring period, which as I described above would make your data availability delay a variable amount of time. If you want data ready in no more than 100ms then the frequencies you measure have to be 10Hz or higher (rough estimate).

If instead you measure ticks, or pulses, or edges, within a time interval, you're free to choose what fixed time interval you want, and how soon you need the data. 1 second makes math easy because Hz are oscillations per second. 100ms you multiply your measurement by 10, et cetera. The longer your sample time the more accurate result you get, on the other hand if lower accuracy is acceptable then you are free to pick a short interval and multiply to get Hz. This method would result in data ready in a fixed amount of time.
 

Re: Some advices in acurracy for a frequency counter using a spartan 6 fpga

Hello whack

Well, I figured you'd be sampling your signal continuously and your FPGA would be pushing out data at regular interval

The FPGA from the counter side point of view is sampling continuously the signal and after each 1 second, it updates the "ticks_register". This should happen independent from the uart comunication.

The uart module will take as a reference a "data ready" signal to be sure its reading the correct content before sending to the PC
 

Re: Some advices in acurracy for a frequency counter using a spartan 6 fpga

Hello whack



The FPGA from the counter side point of view is sampling continuously the signal and after each 1 second, it updates the "ticks_register". This should happen independent from the uart comunication.

The uart module will take as a reference a "data ready" signal to be sure its reading the correct content before sending to the PC

I don't think you understood what I was suggesting. I wasn't talking about the UART, UART is a really boring component you can either implement on FPGA using existing source or use external hardware, both solutions require no work at all.

I was talking about is this:
The concept is that i send a command to uart where i tell the fpga "measure the frequency please", then the fpga responds "this is the value (raw 32bit value) ".
I was suggesting that you keep communication in one direction. Instead of having to ask the FPGA to take the measurement, all you have to do is wait some ms and a new measurement will be ready if your FPGA is sampling continuously. Purpose of this suggestion is simplification.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top