Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
13 years ago

Pattern detection question

I've been doing FPGA work for a while, but most of it has been in controls, not signal processing. I am trying to teach myself some of the basics, so I can take on a few of the more interesting side projects at work. For example, we have a problem right now that would be nice to solve, but I'm not sure how at the moment.

The system in question sends a finite pattern (between 250 and 500) of bytes to a receiver over a back channel, so it knows what to expect. It then encodes the same pattern and transmits it wirelessly. The receiver, knowing the pattern ahead of time, attempts to correlate what it receives with the previously stored pattern.

We intentionally glitch the transmission in various ways, and with varying severity, to verify that the receiver can still correlate the incoming stream to its internal pattern buffer. We score the receiver based on its ability to correlate with respect to the amount of error we induce. The problem is that the receiver is a black box to us, so if it fails, we don't always know if it is a problem with the transmitter or the receiver.

I would like to build a system that can perform the same function using an FPGA that we can instrument (since we will understand what is in it). At this point, I have the ability to recover the stream of bytes from the receiver, but it is the correlation that is throwing me off. I have done a bit of research, and I have learned that it is possible to use a FIR filter where the coefficients are the pattern of interest and the output represents the cross-correlation of the two signals. However, I suspect I will exceed the number of multipliers on any reasonable FPGA doing this. The length of the pattern is between 250 and 500 samples, and there doesn't appear to be any symmetry I can take advantage of to reduce the number of multiplies needed like there are with the usual FIR filter coefficients.

Fortunately, there is plenty of time between samples (on the order of dozens of microseconds), so I have considered rewriting my FIR filter core to reuse multipliers by sequentially calculating "bundles" of calculations to reduce the amount of hardware needed. However, I'm thinking there must be a better way, since this appears to be a common task.

To simulate the actual device, I do need an "analog" (integer) output that represents how well the input signal correlates to the reference signal, as opposed to a binary output. I suspect this is similar to finding sync markers in software-defined radio, but the papers I have read gloss over a lot of math that I don't really understand. I'm doing good at this point to use Matlab to generate filter coefficients, and I only just recently got my own VHDL implementation of a simple NCO and FIR filter to work correctly. I am still trying to get my decimation filter to work correctly.

We do have the full Quartus license, but I have never used the FFT/IFFT functions at all, so I would need to really study up on those to build a working system.

I presently have at my disposal boards with an EP3C16 and an EP3C40. Any help would be appreciated. Alternately, if this is something better suited to a true DSP processor, that would be helpful as well. I've been doing FPGA's for so long, I tend to use them for everything.

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    You might want to take a look at the MAC FIR topology:

    http://www.xilinx.com/publications/archives/books/dsp.pdf

    You don't need an IP core to implement what you need. You just need two RAMs and a multiplier, and then a state machine to decide which 'lag' of the correlator you are working on.

    Check out the description of a lag correlator starting on page 8:

    http://www.ovro.caltech.edu/~dwh/wbsddc/correlator_efficiency.pdf

    Pattern detection is also done using LFSRs. Check out some of the references in this tutorial here:

    http://www.ovro.caltech.edu/~dwh/correlator/pdf/lfsr_tutorial.pdf

    Feel free to ask questions here on the forum, or send me an email (to my forum name).

    Cheers,

    Dave
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Thanks for the links. I was studying them yesterday, and they have certainly helped. I now am wondering if I am overthinking this.

    I am a bit puzzled about the concept of lag, for instance. I understand how it seems to work from the second text, and in a static, statistical sense I can understand it, but in a streaming system I don't see why you would ever need to calculate it for anything other than a lag of zero? (since the stream itself will slide across the reference signal as it is received.) Am I missing something?

    It would seem that with each sample a new correlation value is generated, which could then be used to look for trends, and from that an edge or peak detection is used detect "maximal correlation".
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    I am a bit puzzled about the concept of lag, for instance. I understand how it seems to work from the second text, and in a static, statistical sense I can understand it, but in a streaming system I don't see why you would ever need to calculate it for anything other than a lag of zero? (since the stream itself will slide across the reference signal as it is received.) Am I missing something?

    --- Quote End ---

    You have two patterns you want to compare, but you don't know when (time) either was transmitted, eg., in your case, one is transmitted, and the other is the local copy of the known pattern. If both patterns were 'transmitted' at the same time, i.e., you managed to start comparing them at exactly the right moment, then sure, the zeroth lag would be the peak. However, in general you don't know when (time) the pattern was transmitted, and so you search for the peak in the lag response to determine when that time is, i.e., what the relative time is between the pattern start times.

    Does that make more sense?

    When you're doing pattern detection with transmitters, you can cheat a little, and just measure one lag, and keep adding in delays until you find a peak. If your transmitter pattern is a PRBS7, then you should find the peak within 127 tries (since after that the pattern repeats).

    Cheers,

    Dave