clock counting in FPGA

[Jacm]

Hello,

I use PCI-7831R with LabVIEW FPGA and wnat to count the external digital 20MHz clock.

I have read the manual indicating that the limitation of digital I/O of this board is 40MHz, so the 20MHz clock should be fed without any loss. I use the timed-loop with 160MHz to count the 20MHz clock and expect it should be perfectly count or with even 1 or 2 couts loss because of the asynchronous. But the result is worse, I lost many counts that should not happen.

I attatch the bmp file of my code. I input external 20 MHz clock into DIO20 and set "count ticks" as 160M to make timed-loop couts for 1 second. I expect the counts should be near 20M output but always have tens counts lost.

I am wondering if anything I can try to solve this problem.

Thanks.

[nathand]

Have you tried a slower input clock?  That would help determine if you have some sort of logic problem, or if you're running into the limits of your IO.

[GregFreeman]

 Are you sure your digital signal is clean, no grounding issues, etc? Do you have a pulse generator where you could put a fixed signal in and test that at a slower rate (as suggested above) to count those pulses? Often I do this to troubleshoot. From the code side of things, everything looks clean as far as I can tell.

Should have read your message closer. You are always 10 counts less. Sounds to me like the timing between the external clock is not quite on what the FPGA timing is doing. I had this issue when I did audio acquisition with the 9234 module...the module had it's own timing (I think is how I understood it). The result was some lost data. I never got a consistent amount of points when using a timed loop. The way I corrected this was using a while loop, run as fast as I could and just have a counter up to 51.2 K that incremented each time I got an analog point. When my counter got to 51.2 K , I knew I had all the data. Essentially I made the assumption the 9234 modules timing was correct and used that rather than timing in FPGA.

What is your 20 MHZ source? Could your issue be similar to mine?

[Jacm]

to nathand:

Thanks for your response.

According to the manual, the limition of the IO is 40MHz. I have tried to input 10 MHz and still lost counts.

[Jacm]

to for(imstuck):

Thanks for your response, I would like to describe things in detail.

I use the function generator to generate the 20 MHz square wave, and check the waveform in oscilloscope. I think the source shoud be fine. I have tried the while-loop instead of timed-loop, but the result is worse which may be the reason of the while loop can't be execute in accurtate high clock rate. (ex. 160MHz)

Here is some test data: I counts in 1 second.

1. when I use 80MHz as timed-loop clock

 (1)input 10MHz: lost 37 counts

 (2)input 20MHz: lost 73 counts

2. when I use 160MHz as timed-loop clock

  (1) input 10MHz: lost 37 counts

3. when I use 40MHz as timed-loop clock

  (1) input 10MHz: lost 37 counts

I have simplifed the LabVIEW FPGA code and still can not figure out why.

Maybe there is better and more correct coding in FPGA to solve this, please note me.

[gsussman]

Are you certain that you are not prematurely ending the loop by virtue of the fact that your tick counts (input to the stop condition) will terminate the loop after N number of iterations as opposed to N number of acquired clock cycles? When you double your clock rate, you double the number of cycles that you miss within 1 cycle. That seems like an awfully big coincidence.

Other than that, I would check your signal quality with a scope. At 20MHz you don't need much impedance mismatch to really screw up the shape of your clock. Could be that you are right on the hairy edge of what is considered a high and low signal, thus you loose a transition here and there.

[Jacm]

to gsussman,

Thanks for your response.

1. It may be the loop stops when I am not expect, so I lost the counts. I have tried to simplify my code and searched some similar examples and I can not figure out if there any big mistakes in the code. Please note me if I have wrong coding (There really should be bugs!!).

2. If the 20MHz signal is unstable, the output counts should be unstables too. I have tried several times and had the same results, so the input 20MHz should be fine to FPGA since it is still under the 40MHz limitation.

I stiil believe that FPGA should be able to do the job. Using 160MHz to count 20MHz should be fine theoretically. I am still trying any possible coding to ahieve the job.

[gsussman]

Try altering your loop end logic to stop when you have acheived the specified number of clock cycles as opposed to number of loop iterations.

Bring the loop iterations out as an indicator.

From that, you can take a look at the signal from another perspective that may shed some light on the issue.

[nathand]

It's interesting that you lose almost exactly half as many counts at 10Mhz as you do at 20Mhz... we're a bit outside my area of expertise, but is it possible there's a slight mismatch in the clock frequencies between your source and the FPGA?  What if you use the FPGA as your signal source, and connect a wire directly from a digital output to a digital input on the FPGA?

[Spectre_Dave]

I use a method to wait for a clock edge then count the clocks and data coming from a Delta Sigma Moodulator. I get very consistant readings this way.