LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

clock counting in FPGA

to gsussman:

We have tried the way you suggested.

 

Timed loop set to 80MHz and input sigal is 20 MHz. After we got 20M counts, it needs 80M with additional about 300 ticks.The result is very similar to our previous test. It needs about 3 us more to achieve the work which I dont know why.

 

to nathand:

We output the 20 MHz signal from FPGA and input back to FPGA as signal. Timed loop set to 40 MHz. And we count for 1 second, we get the correct result this time. We have 20M counts. If we tried the method that gsussman suggested that we stop the loop after we have 20M counts, we have 80M+9 ticks. We always have the additional 9 ticks means 225 ns. It is strange.

 

to Spectre Dave:

We also prefer "Wait on Rising Edge" function, but it cannot put into timed-loop. If we use the while loop, the loop clock is very slow that can't count 20MHz. The while loop clock is also affected by the things in loop, and I can't have constant high sampling clock to count 20MHz signal.

 

Thanks to you all, but we still can't have the solution.

0 Kudos
Message 11 of 19
(940 Views)

I am sorry that I pasted the wrong data, but I cant find way to modify or delete the post, so I post it again.

 

---

 

to gsussman:

We have tried the way you suggested.

 

Timed loop set to 80MHz and input sigal is 20 MHz. After we got 20M counts, it needs 80M with additional about 300 loops.The result is very similar to our previous test. It needs about 3 us more to achieve the work which I dont know why.

 

to nathand:

We output the 20 MHz signal from FPGA and input back to FPGA as signal. Timed loop set to 40 MHz. And we count for 1 second, we get the correct result this time. We have 20M counts. If we tried the method that gsussman suggested that we stop the loop after we have 200M counts, we have 800M-2 loops. Only a little miss. 

to Spectre Dave:

We also prefer "Wait on Rising Edge" function, but it cannot put into timed-loop. If we use the while loop, the loop clock is very slow that can't count 20MHz. The while loop clock is also affected by the things in loop, and I can't have constant high sampling clock to count 20MHz signal.

 

Thanks to you all, but we still can't have the solution.

0 Kudos
Message 12 of 19
(916 Views)

 


Jacm wrote: 

to nathand:

We output the 20 MHz signal from FPGA and input back to FPGA as signal. Timed loop set to 40 MHz. And we count for 1 second, we get the correct result this time. We have 20M counts. If we tried the method that gsussman suggested that we stop the loop after we have 200M counts, we have 800M-2 loops. Only a little miss. 


So it sounds like there's no logic error in your FPGA code; rather, I think there's a slight mismatch in clocks between the FPGA and the source.  If we assume that the FPGA is correct, then your source clock is outputting 19.999927 MHz (off by less than 0.0004%).  I'm not sure how you would determine which clock is correct, but I think the FPGA will allow you to connect an external clock as the timing source for a single-cycle loop which would synchronize the two.  Is that an option in your application?

 

EDIT: for comparison purposes, the NI R Series Data Sheet gives the timebase accuracy as +/- 100ppm, which, if I'm not mistaken, is 100/1,000,000 = .0001, or 0.01%, much greater than the difference between the actual difference between the clocks.  However, this isn't my area of expertise so I may be misinterpreting the specifications here.

0 Kudos
Message 13 of 19
(899 Views)

Could you create another loop that  only counts the 20MHz clock.Then pass the counts with a global.

Try putting everything but the Wait for edge in a SCTL (Single Cycle timed Loop) this will execute in one tick (12.5nS for an 80MHz clock)

Visualize the Solution

CLA

LabVIEW, LabVIEW FPGA
0 Kudos
Message 14 of 19
(893 Views)

to nathand:

 

If we can get the external clock, that would be perfect since we can use the 20MHz as synchronous clock. Unfortunately, it is not supported in all R series board. That is why I have to count 20MHz clock ourself.

 

But I think you give a point. The 20 MHz signal might be unstable itself thouth I used the function generator and had checked it by oscilloscope. I will check it again. Thanks.

0 Kudos
Message 15 of 19
(887 Views)

to Spectre Dave:

I am not sure if I can use global variable in FPGA, and I will try. Thanks.

 

But I am sure I can't put "wait for rising edge" in timed loop. It has errors and can't pass the compilation.

0 Kudos
Message 16 of 19
(884 Views)

You can use a global in FPGA programming, however in this instance you would be better off using FPGA memory as opposed to a global.

 

I just read through this entire thread again and am not quite sure what it is that you are trying to accomplish. What is the primary purpose of this 20 MHz clock? Are you looking to perform some syncronous operation with other parts of your system, or use this master clock to drive your entire FPGA program?

 

The absoloute accuracy of the clock "may" not be a critical issue if the rest of your FPGA code is running synchronously off of it.

0 Kudos
Message 17 of 19
(877 Views)

 


Jacm wrote:  

But I think you give a point. The 20 MHz signal might be unstable itself thouth I used the function generator and had checked it by oscilloscope. I will check it again. Thanks.


While you're checking the function generator with the oscilloscope, set up the FPGA to generate pulses at the same frequency and check that output as well.  I doubt you'll be able to see a difference, though, since the two clocks are so close to each other.

 

0 Kudos
Message 18 of 19
(856 Views)

to gsussman:

 

In fact, our purpose is to synchronize with another device which is sending data in its own clock (around 20~40 MHz). The simple way is to use the device clock as trigger to reveive the data, and it should be the correct way to do so.

 

Unfortunately, the R-series board doesn't allow us to set external clock in FPGA. In order to receive the data correctly, I need to get the correct synchronous clock correctly first. That is why I need to do the test, to count the clock.

0 Kudos
Message 19 of 19
(832 Views)