Honored Contributor
Honored ContributorI 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
