08-25-2015 03:24 AM
08-25-2015 09:46 AM
08-25-2015 09:47 AM - edited 08-25-2015 09:48 AM
You can fit quite a bit of boolean logic in a 5 MHz clock tick, but without knowing more specifics I would recommend just trying it out and seeing if it works. And, like others mentioned previously, there are a number of ways to do this trading off clock rate for resource utilization.
08-25-2015 10:57 AM
I suspect counting bits isn't really what you're looking for. You mentioned the gold pattern... You can probably XOR the input with your gold pattern, and OR the results:
As long as there aren't a lot of bits, it should be single-cycle (I never found the cell-size limits of the FPGAs).
It sounds like this is a serial application, so counting as the bits come in may be tempting, but it's hard to reset the counters correctly. In a few cases, you may get away with an unsigned fixed-point number that doesn't wrap on overflow.
08-25-2015 11:01 PM
08-25-2015 11:02 PM - edited 08-25-2015 11:05 PM
the array contains about 500 boolen elements.
08-26-2015 09:26 AM
Is the boolean signal stream coming from a digital I/O? If so, you should definitely be able to clock your digital input into a shift register and then compare the latest 500 elements to a golden header packet to perform the correlation.
08-26-2015 10:12 AM
I'm relatively certain for 500 elements, the answer is: No.
I have some good experience with GPS (with CDMA), and this sounds fairly similar to that, so I'll answer you from that perspective. So, it sounds like what you'd like is something more like:
In GPS, at least in about 1994, that wasn't feasible. What we did instead, was guess at the clocking, and start multiplying (XOR) the input against what we thought was the right pattern, sum the result, and see if the sum constantly increased, or averaged close to 0. If it increased, we were likely correct. If it decreased, we had the polarity opposite (easy in GPS), but otherwise likely correct. We constantly shifted the guess at clocking, until we got a match. This algorithm (correlation) was done many times at once, looking for different clocking, to find the match more quickly.
It would be awefully tedious, but you may be able to get some success by breaking up the 500 bit gold pattern into groups of about 8 bits, and test the input against each one separately, then see if the match against [0-7] 492 clicks ago, plus the match against [8-15] 484 clicks ago.......[492..499] right now, all add up to the acceptable level (or highest level). I said '8 bits' thinking the idea posted before by nathand, about using a memory-look-up to count 'on' bits would be very helpful.
08-26-2015 10:47 AM
Here's another approach, but it requires a huge FPGA:
Use 500 counters. Each counter compares the input to a different clocking of the signal. You may need to read the counters and clear them periodically.
08-26-2015 11:44 AM
One thing to remember is that even though the clock being synchronized is running at 5 MHz, the FPGA clock can be much faster. If you clock the logic at 100 MHz, that gets you 20 cycles to compute the correlation which should be more than enough time to pipeline scanning 500 elements. And if you only need to slowly stear the 5 MHz clock every once in a while you may have 100s of 100 MHz clock cycles to work with. Again, this all depends on exactly what the needs for this particular system are.