I have a couple of FPGA setups to capture images from an Aptina/ONSemi MT9P031 sensor. I've done this in the past with no issues but now I have a strange problem.

I have a bit of scene dependent noise that follows along with some contours of objects that can be seen in the image. Will attach an example, you can see a ring of black or white pixels surrounding the lit-up button on the pictured equipment, and similar garbage on the text or edges of the other buttons. enter image description here

A couple of REALLY weird things about it -- if I use a Salae logic analyzer, connected to some soldered pins on my board that are on the traces between the camera and my FPGA, it can actually capture a perfectly clean image without this noise. I would have thought if anything this should be worse because it's going off-board across some extra flying leads and at the end of the day the Salae logic is another FPGA.

Two reasons why I don't believe the problem is in my external memory that I use to store the image. One, if I replace pixel data with a test pattern driven by the camera's pixel clock, it comes across perfectly cleanly. I also observe the same effect with the same camera attached to a Cypress FX3 dev board and no FPGA in between.

I've also tried doing what the Salae does, sampling both the pixel clock and data on a faster clock and just looking for the edges in the pixel clock, but the result is the same. I have a hunch that this has something to do with too many bits on the parallel bus trying to change at one time, but it's really curious that the logic analyzer doesn't have the same problem. Anybody have any ideas on this by chance?

  • 2
    \$\begingroup\$ The logic analyzer affects the signal and in this case it fixes the issue. Your initial thought that it is due to too many bits changing at once could be one explanation, either by direct capacitive coupling or via ground bounce. You might want to check if the clock edge polarity is correct on the FPGA input or is it possible to adjust the sampling phase at camera or FPGA, or if there are drive strength settings on the camera. I assume the bus is 8-bit with clock? \$\endgroup\$
    – Justme
    Commented Mar 3, 2021 at 5:32
  • 2
    \$\begingroup\$ The fact that the noise follows contours of constant intensity is a strong clue that what you are seeing is crosstalk between bits of your parallel bus. For example, the transition between 011111111111 and 100000000000 is sometimes causing the MSB to be read incorrectly. I'm working with this sensor myself, and discovered that the suggestions in the datasheet for sampling the output signals relative to the clock don't actually work with the worst case timing, especially at 96 MHz. \$\endgroup\$
    – Dave Tweed
    Commented Mar 3, 2021 at 11:49
  • \$\begingroup\$ @Justme: It's actually a 12-bit sensor. You give it a reference clock, but it returns a separate output clock at the same frequency but completely arbitrary phase, so you need to use a FIFO to get the signals (data, fsync, lsync) back into your original clock domain. \$\endgroup\$
    – Dave Tweed
    Commented Mar 3, 2021 at 11:57
  • \$\begingroup\$ Furthermore, there are two different kinds of output drivers, so you need to sample the data on one edge of the clock, but sample the control signals on the opposite edge. \$\endgroup\$
    – Dave Tweed
    Commented Mar 3, 2021 at 12:10
  • \$\begingroup\$ Thanks Dave, good point on the crosstalk. It is a 12-bit sensor but I'm generally ignoring the four least significant bits and turning it into an 8-bit per pixel image. The sensor gets its own oscillator, and I use its clock output as my reference clock, there isn't an original clock domain for me to care about. I'm putting a 16 or 24MHz oscillator into the sensor and not using the PLL, just working at that frequency at the moment. My latest code oversamples with a 60MHz clock watching for falling edge from the sensor clock, but I also tried using the sensor clock with the same result... \$\endgroup\$
    – Steve B
    Commented Mar 3, 2021 at 17:32

1 Answer 1


So it was actually an issue with my memory controller that was solved by decreasing the memory clock frequency.

I thought the memory was working totally cleanly because I had used it on a previous project and it responded well to various gradient test patterns. I was able to see that there was some sort of issue by changing to a test pattern that was more aggressively railing between black and white.

I was really thrown off by that noise following the contours of what was in the image, that really suggested sensor rather than memory in my mind.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.