cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Observer
Observer
166 Views
Registered: ‎07-23-2019

Pixel Jitter/Dancing via VDMA Mystery... (not flicker.. but rather random dancing pixels..)

Jump to solution

Hi All.. Needs some combined brain power on this:

Setup:  I have HDMI in (via Digilent DVI2RGB IP) to VDMA to FrameBuffer (DDR3) to VDMA to HDMI out via ADV7511 chipset. Using one VDMA IP. Single Frame Buffer, single Address for both. I don't care about timing and sync right now. In port writes to memory as frames come in (1080p) and VDMA out writes out 1080p via timing IP to ADV7511/HDMI Out.

But results are crazy.. I can explain dancing pixels as poor HDMI timing input.. but when I turn off the input.. the still image in the FB continues to dance!!! (HDMI out was tested as working prior)

note: When the input port is not plugged in the clock lock signals goes low.. and video "in" STOPs at the VDMA.

Order:

1. A microblaze sets up FB and VDMA. Output HDMI is plugged in. A color bar patterns is drawn to the FB via Microblaze.

2. The color pattern is solid and displayed! No problems and as expected.

3. HDMI "in" is plugged in.. all activity happens in hardware (no Microblaze involvement since VDMA is setup already)

4. HDMI in video is displayed on the HDMI out screen within a second. Colors are messed up because some hardware data channels are inverted. (This is expected). Video is live and 60hz. It does have dancing pixels.. and I assume this has to do with poor/corrupted data in given the partially inverted data pins. Nothing crazy yet.

5. I UNPLUG HDMI in and the video freezes - as expected. BUT THE PIXELS STILL DANCE... what?

6. I decide to have the Microblaze write color bars to half of this frozen screen.. and the color bars are solid.. the part not touched by the microblaze continues to dance. WHAT?

It seems like FB memory touched by VDMA input.. dances.. That touched by Microblaze is solid. There is only one FB.. settings are "1" for number of buffers. VDMA is not writing data once HDMI in is unplugged. Dancing is not alternating.. but seemingly indeterminate dancing.. Like some memory cells are marked as "undetermined" or something. None of which makes any sense unless there is something I don't understand about DDR3. I have never heard about memory being marked as invalid. Both streams are 24bit data. DDR is 32bit. VDMA has 64bit AXI lanes. Chip is Artix-7 100 2c. DDR3 is 32bit at 400mhz (800mbit) and AXI to MIG is 256bit. (no bandwidth issues)

Bottom line: FB sections written to by microblaze = ok, sections written to by VDMA = undefined behavior. 

On the video please note that the color bars (top) are solid to the human eye - these are moire patterns from video off screen. But pixels that are dancing - especially along the outside of letters are what I'm talking about. There are no dancing pixels on the top color bars...

colorbars.jpgVDMA2.jpg

 

 

0 Kudos
Reply
1 Solution

Accepted Solutions
Explorer
Explorer
143 Views
Registered: ‎07-18-2011

@tschesnok 

Colorbars don't have lower-bit transitions.  They have a steady number throughout the color, then a step to another steady number in the next color, so they won't easily show timing errors.

For testing timing errors, you should write a monochrome ramp that increments one pixel per step, so you will end up with an array of single-pixel ramps that vary from 0 to 255 (for 8-bit per pixel color) repeated across the screen.   Bit errors will usually show up as pinkish or greenish vertical stripes in the monochrome ramps.  The errors will occur at the bit positions that have timing issues.  For example, if the MSB has a timing problem, you will see one vertical stripe where the pattern changes from 127 to 128.  If there is a single timing error in the next lower bit, you will see two stripes, and so forth, so sometimes you can determine where the error occurs by checking the position of the stripes.

If you are using RGB, you can also write three ramps, one each for R, G, and B, to test for bit errors in each color individually, or you can write Y and Cb Cr ramps if you are using 16-bit Y/CbCr.

View solution in original post

3 Replies
Explorer
Explorer
144 Views
Registered: ‎07-18-2011

@tschesnok 

Colorbars don't have lower-bit transitions.  They have a steady number throughout the color, then a step to another steady number in the next color, so they won't easily show timing errors.

For testing timing errors, you should write a monochrome ramp that increments one pixel per step, so you will end up with an array of single-pixel ramps that vary from 0 to 255 (for 8-bit per pixel color) repeated across the screen.   Bit errors will usually show up as pinkish or greenish vertical stripes in the monochrome ramps.  The errors will occur at the bit positions that have timing issues.  For example, if the MSB has a timing problem, you will see one vertical stripe where the pattern changes from 127 to 128.  If there is a single timing error in the next lower bit, you will see two stripes, and so forth, so sometimes you can determine where the error occurs by checking the position of the stripes.

If you are using RGB, you can also write three ramps, one each for R, G, and B, to test for bit errors in each color individually, or you can write Y and Cb Cr ramps if you are using 16-bit Y/CbCr.

View solution in original post

Observer
Observer
125 Views
Registered: ‎07-23-2019

Good news.. that was a good tip. I decided to pull up color patterns on the input side.. and most are clean too.. so only certain color transitions seem to trigger errant pixels.

Picture: Top color bars are Microblaze. Bottom strip (including red) are from HDMI in. Only the Yellow to Blue transition exhibits errant pixels.. a color transition not present in the microblaze pattern. looking closer at it.. but will probably close this out.newcolorpattern2.jpg

0 Kudos
Reply
Observer
Observer
92 Views
Registered: ‎07-23-2019

It was timing. Thanks for the hint of getting me to suspect the output being the issue. I was hoping I would be able to do 1080p with the "2" speed grade.. but no.. as soon as I slow it down a bit I get solid pictures.

Perhaps with reduced blanking I can make it work.

 

 

0 Kudos
Reply