Implementing an asynchronous counter in a FPGA

You don't give us much information on what the 'impulsions' (impulses?) look like. How narrow are these pulses? Without knowing this it's a little difficult...

You could use the edge of one of the impulses as the clock input to a register in the FPGA and implement a ripple counter. Whilst the ripple-counter detailed in the paper you attached is perfectly valid, the FLEX 8000 series devices are certainly worth steering clear of - even if you can get hold of some. These old devices frequently implemented such ripple counters for resource efficiency. These devices also ran at much higher voltages too such that the EMC emissions (perhaps) needed more careful consideration than newer parts operating at lower voltages.

--- Quote Start ---

I synchronize the counter with the system clock every second for example

--- Quote End ---

So you clearly need a system clock if you're to do this. But you imply it can't be 100MHz for EMC reasons - is that right? We regularly design with 'system' clocks at this and much higher frequencies. EMC certification is something all our products must go through. So, it's perfectly possible to design products with such an operating frequency.

If 100MHz is a suitable frequency to sample your impulses, then I recommend you consider doing that and using the same clock to drive a standard synchronous binary counter. Careful board and power supply design/layout should see you through any EMC certification - I hope.

Cheers,

Alex

The pulses are about 10-20-ns long, but nothing is sure until we actually make some tests on the board.

The thing that I forgot to mention is that the design is very small; basically 4 counters (4*32bits), a DAC interface (SPI), and a few logics. The counters are to be read every 1 sec, and I guess there is no need to go at 100MHz.

Does it make more sense?

--- Quote Start ---

You could use the edge of one of the impulses as the clock input to a register in the FPGA and implement a ripple counter

--- Quote End ---

This is what I would like to try. In addition, I thought of gray code for robustness, but I had troubles trying to find an implementation for n bits. I made some researches about T-FF (made of D-FF + Mux) implementation but it did not lead to anything conclusive.

How would you start to solve this problem?

Thanks again

Damien

What's the expected pulse frequency? I mean the minimum time spacing between a pulse and the following one?

Let this time be T, then you could afford a system clock frequency as low as 1/T: you can probably use the pulse itself as clock input to set a flip-flop and then you use the system clock to sample and reset it. So the counter part would be kept synchronous and you can use a common counter, without harassing with ripple clocks, Gray code and async logic.

search for n-bit counter verilog (or VHDL), lots of examples will flood to your search results.

It does not need to be a gray counter. It makes no difference for you. Any type of counter suffices your need.

If your incoming pulses are 10-20 ns, you could certainly use a synchronous counter, clocked by the system clock @ 100 MHz for example (125 MHz for better results).

You should be able to pass EMC issues, since this is a typical frequency many EMC-compliant devices are working with.

I would simply oversample the incoming signal with a "suitably" fast system clock and count the pulses, or more specifically, the number of rising edges I receive.

What is a suitably fast system clock? Expanding on Cris' thoughts, it needs to be at least 1/T where T is the minimum width of either the mark (the impulse) or the space (the time between the pulses). So if you have 10ns pulses and 100ns gaps you need at least 100MHz clock. If the pulses are 20ns but your space is 10ns, then it still needs to be a minimum of 100MHz to distinguish between the pulses.

Robustness - the only tricky bit is getting the signal onto the system clock domain. Once inside the FPGA I'd argue there is no advantage in using a greycode counter, providing a standard binary counter meets timing.

To bring the signal onto the system clock domain I recommend clocking the incoming signal through 2 flip-flops to overcome any metastability, something you'll encounter as a result of sampling a signal that's asynchronous to your system clock. There's plenty on metastability on the web. This is the only length I'd go to to ensure a robust solution. Only consider the output of the second of those flip-flops, the one whose output is guaranteed to be stable, when counting the pulses.

--- Quote Start ---

the design is very small

--- Quote End ---

With the exception of some of the smallest CPLDs, even the smallest and cheapest of FPGAs should be able to mop up all the logic you list. The smallest Cyclone IV (a device I'd consider for this) has over 6000 registers and will quite happily run all that at 100MHz.

Cheers,

Alex

Thank you for all the answers

The pulses are connected to comparators. The shape of the comparator output will look as follows:

- At low flow, ~400-ns-long pulses, spaced randomly apart from each other;

- At high flow, there is superposition of pulses. The comparator ouput is active most of the time, but I need to detect when it goes low. That represents a pulse of ~10-20 ns depending on rise/fall/propagation times of the comparator. The pulses are also random.

I attached the synopsis of the design that I have in mind. I understand that a 100-MHz system-clock domain with a synchronous counter would get the job done. But again, the design doesn't need to go that fast, and the power consumption is something I have to take into consideration.

Basically, the SPI interface is used at power-on once, then the counters are read every second and sent to the UI. The rest of the time, the design is "sleeping".

I'm still not really convinced that an asynchronous counter is a bad choice, unless the consumption difference is very negligible. But I guess it depends on the target device, which is not determined yet.

--- Quote Start ---

you can probably use the pulse itself as clock input to set a flip-flop and then you use the system clock to sample and reset it.

--- Quote End ---

I am not sure I understood this part. Are you suggesting to use the pulse as clock for all the counter FFs? How about that using gray-code?

Damien

--- Quote Start ---

I am not sure I understood this part. Are you suggesting to use the pulse as clock for all the counter FFs? How about that using gray-code?

--- Quote End ---

Nope. The pulse should clock a single FF. The output of this FF should be sampled by the system clock, thus bringing it in the synchronous domain. This status would be used as clock enable for the actual counter. Then, the next system clock event will reset the FF and make it ready to latch the following pulse.

Anyway in your last post you talked of superposed pulses: in this case the method doesn't apply, since you'll miss the pulse edges whenever they merge.

--- Quote Start ---

Anyway in your last post you talked of superposed pulses: in this case the method doesn't apply, since you'll miss the pulse edges whenever they merge

--- Quote End ---

I just wanted to give the width of the pulse that needs to be captured. The merge will be handled differently. That was not related to the discussion, that why I didn't give more details.

I am going to try it out, and I will give you feedbacks

Thank you

Damien