WAITVID sync glitches

ozpropdev · 2013-10-27 20:17

Hi Guys

I've been chasing a VGA video sync issue for a while now and I think I might have stumbled on a clue.
In my application I am generating a 800x600 60Hz VGA image. All my test displays all detect the signal fine
and show the signal as 800x600 60Hz 37.8kHz detected.
What appears on the displays is 99% perfect image except the image shows a glitch in a fixed vertical plane.
I initially blamed my multi-tasking stuff for this but testing in a single thread has not eliminated the problem.
I have created 5 VGA test programs that highlight the problem.
It seems the more I break the line into sections the more the problem is reduced?
The test programs are for DE2 only as the the test pattern is large.

Test results

Test 1 - No glitch but top border missing
Test 2 - Glitch appears in RED section on left
Test 3 - Glitch in green section on left
Test 4 - Glitch in blue section on left
Test 5 - Glitch in grey section on right

Note top border improves as number of sections increase?

My VGA driver is the most basic I can make it, to keep it simple. It just reads a long and pushes it to AUX ram.

Any ideas?

Cheers
Brian

Edit: See attached image of Test 5 result

pedward · 2013-10-27 22:31

Try a different monitor.

ozpropdev · 2013-10-27 22:37

Test results are identical on 4 different monitors!

pedward · 2013-10-27 22:45

What dot clock did you use? IIRC, that mode requires slightly higher for clock, like 46 mhz instead of 40. I'd have to look at my code. I know I did 800x600 successfully on the de0.

ozpropdev · 2013-10-27 23:00

Results for 50MHz dot clock, V=72Hz ,H=48klHz are identical.
Same for 45MHz dot clock.

Edit: I used 40MHz dot clock for V=60Hz H= 37.8kHz

Ale · 2013-10-28 00:27

It looks like you are outputting a part of the next line... curious. Maybe a counter problem.. Do you have an oscilloscope at hand, one that can trigger after a number of pulses, or a logic analyzer ?

ozpropdev · 2013-10-28 02:52

@Ale Sync signals look clean on oscilloscope.

The only correlation I see between all the tests is the glitch always appears two sections before the next sync.
I believe WAITVID is double buffered so maybe there's something going on there?

ozpropdev · 2013-10-28 19:34

Hmm.. the plot thickens.

Further testing has shown more unexplainable results.
Thinking how it is possible for the line to bend like it does in all the tests leads me to believe a very short
pulse/spike is appearing on the vertical sync signal. Probing around with mu OLD cro did not show anything unusual.
Maybe it's too short for my equipment to detect.
I have a USB oscilloscope which I can capture images but its bandwidth is not much better than my cro (could be worse!)

Two new tests were created.
TEST A - Has 22 x 32 pixel columns + 1 x 96 pixel column.
This is the best result so far. (See Image)

TEST B - has 23 x 32 pixel columns + 1 x 64 pixel column. Based on the improvements gained by adding more sections
it was expected to be a better result than TEST A.
This test failed to sync at all on all of my monitors?
What I did find is the H Sync signal showed a lot of erratic pulses.

Maybe someone out there in Propland has a flashy oscilloscope to look at these patterns closer.

Dazed and confused....
Brian

Phil Pilgrim (PhiPi) · 2013-10-28 20:21

I don't think sync has anything to do with it. Horizontal scan lines don't "bend." Errant syncing would cause tearing, rolling, or zipper (i.e. the heebie-jeebies) but definitely not what you're seeing. My guess is that partway through the scan line your program begins addressing the same position in the next line of the buffer. This can happen if your program assumes the lines begin on a certain address boundary when, in fact, they do not.

-Phil

ozpropdev · 2013-10-28 20:54

Phil Pilgrim (PhiPi) wrote: »

My guess is that partway through the scan line your program begins addressing the same position in the next line of the buffer. This can happen if your program assumes the lines begin on a certain address boundary when, in fact, they do not.

-Phil

Hi Phil

The addressing of the buffer is correct as the top and left border alignment is correct.
The CLUT ram is loaded using the same code in all tests. The more WAITVID's used the more the fault moves
to the right of screen. It seems to be related to the next incoming SYNC commands to the VID buffer.

Cheers
Brian

Tubular · 2013-10-28 21:59

Hey Brian

Just a quick note to say I see the same thing on your test A. I can't display test B either.

The sync pulses look mostly normal (to me) to be but there is a nasty transition region in the middle, at least with my setup. This may be due to reflections in the cabling? Or to do with the pin drivers in the altera chip?

The really weird thing is the step seems to go "up" a scanline. If you had an extra H pulse you'd expect it to go down. That makes me think there is something non standard about the timing setup, or the waitvid is releasing data before the H sync pulse happens, or something.

I don't have time to chase right now, just wanting to report/confirm similar results.

Yanomani · 2013-10-28 22:09

ozpropdev

The last time I'd seen some effect like the one you showed us, it was due to a poor sync stripping on some composite signal monitors, caused by a longer than usual video data output, overriding signal's back porch area.
The line endings appeared as folding over themselves, as the horizontal beam scan keeps moving, backwards and slightly slanted, waiting for the black back porch and the horizontal sync pulse.
But that was a characteristic of the affected monitors, dictated by the design of their horizontal deflection circuits.

But this is not the case here.

Only a thought; have you ever tried substituting the interleaving white lines with black ones and checked the results?

You can also try to output black pixels at the last 32 or 64 positions at each line, and verify if the skipping effect still holds, affecting the beggining of the slightly shortened last color blocks.

They are only guesses of mine, none logic at all.

Yanomani

ozpropdev · 2013-10-28 22:15

Ok

I have had some success.
It seems if you don't try loading the WAITVID buffer immediately after a SYNC command the glitch disappears.
Here's is a section of the modified code.

			call	#sync	'*** sync moved here fixes glitch ???

			mov	cx,#25
:pp1			rdlong	ax,ptra++	'get 32 pixels
			pusha	ax		'push to clut ram
			djnz	cx,#:pp1

:send_pixels	'	call	#sync			'do horizontal sync
			waitvid	mode0,char_color
			waitvid	mode1,char_color2
			waitvid	mode2,char_color3
			waitvid	mode3,char_color4
			waitvid	mode4,char_color5

While this has fixed all the test programs it is not a proper fix.
This limits how much time you have to prepare pixels for the WAITVID buffer.
Too much time spent stretches the gap between HSync which causes loss of sync.

TEST C - Has 25 x 32 pixel columns - Image is displayed correctly!

Further investigation is required.

Cheers
Brian

potatohead · 2013-10-28 22:22

I don't recall this being the case on the last FPGA core we were using. Might be worth rolling back one to evaluate similar code.

Thanks for posting code. I will run some tests this weekend. However, I completely agree with you, and the older waitvid could take pixels right away. My guess is the last round of changes modified how waitvid gets it's data. If we can boil this down to some basic case, Chip can fix it easily enough.

Tubular · 2013-10-28 22:44

I think I found something interesting with regard to where the rising edge of V sync happens relative to H sync. It's different for my laptop outputting 800x600 vs the DE2 outputting 800x600.

For the DE2 the V sync edges happen about 100ns before the H sync falls. For my laptop the V sync happens at the same time the H sync rises.

Confirming also the horrid edge transitions in my post above were due to the vga cable - if I removed it, it cleaned up nicely.

jazzed · 2013-10-28 22:56

Tubular wrote: »

Confirming also the horrid edge transitions in my post above were due to the vga cable - if I removed it it cleaned up nicely.

Ugh, the dreaded shelf.

Is there a slew-rate control on the output pins?

ozpropdev · 2013-10-29 00:03

potatohead wrote: »

Might be worth rolling back one to evaluate similar code.

Good Idea. I try that later.

@Tubular

Thanks for verifying that for me.

Cheers
Briam

ozpropdev · 2013-10-29 04:37

Hi Guys

I just loaded the older 60MHz FPGA core into my DE2 board.
This has the same glitch as the new 80MHz core.
FYI

Bill Henning · 2013-10-29 07:30

I recall having a similar problem with my Morpheus drivers on a P1 many moons ago... the issue turned out to be an incorrectly generated vblank scan line at the end of the vertical blank period.

cgracey · 2013-10-29 09:28

Briefly reading this thread, it sounds like there may be some issues of HSYNC-vs-VSYNC coincidence with different monitors.

HSYNC must be, and is, tied directly to pixel timing, being a part of the VID output.

VSYNC, on the other hand, is controlled by software manually flipping the VSYNC pin.

Because VID double-buffers the video segments, there is some potential for ambiguity surrounding HSYNC-vs-VSYNC timing.

The natural way to code this is to put the 'NOTP vsync' instruction (if that's how you're doing it), outside of the code that creates the HSYNC, which usually consists of three WAITVIDS, or so.

It may be necessary to put the 'NOTP vsync' instruction inside the HSYNC code, to offset VSYNC's edge away from HSYNC's edges. I don't know if there is some recommendation for when VSYNCs should generally occur, relative to HSYNCs. I could see monitors having issues with this, though, as nearly-coincident edges could cause problems if the monitor is registering VSYNC on an HSYNC edge.

Consider this sequence:

WAITVID
WAITVID
WAITVID
NOTP vsync

The third WAITVID releases when the second WAITVID begins to output, making the NOTP nearly coincident with the start of the second WAITVID's output.

pedward · 2013-10-29 09:31

Came up to fill your SCUBA tanks Chip?

Ariba · 2013-10-29 14:31

ozpropdev wrote: »
Ok

I have had some success.
It seems if you don't try loading the WAITVID buffer immediately after a SYNC command the glitch disappears.
Here's is a section of the modified code.
			call	#sync	'*** sync moved here fixes glitch ???

			mov	cx,#25
:pp1			rdlong	ax,ptra++	'get 32 pixels
			pusha	ax		'push to clut ram
			djnz	cx,#:pp1

:send_pixels	'	call	#sync			'do horizontal sync
			waitvid	mode0,char_color
			waitvid	mode1,char_color2
			waitvid	mode2,char_color3
			waitvid	mode3,char_color4
			waitvid	mode4,char_color5
While this has fixed all the test programs it is not a proper fix.
This limits how much time you have to prepare pixels for the WAITVID buffer.
Too much time spent stretches the gap between HSync which causes loss of sync.

TEST C - Has 25 x 32 pixel columns - Image is displayed correctly!

Further investigation is required.

Cheers
Brian

The glitch you see near the end of a line comes from overwriting the stack ram with the data of the next line while the video shifter still shifts out the stack ram. At the time you see the glitch the old line gets ovewritten with the data of the next line before the old data is shifted out.

If you have the call #sync after the fill loop then the stackram is filled while the last waitvid with a color is executed. And this data gets corrupted. If you have the call #sync before the fill loop then the waitvids in the sync routine wait until the last color data is outputted, and the stackram is filled while the Back Porch waitvid executes.

The time in the back porch may be too short for a whole line with higher resolutions, so the universal solution is to fill only parts of the line into stackram and then do a waitvid, then fill the next part and do a waitvid and so on. To spare stackram you can do it with small buffers which you reuse. But I have found that it not works always with only two buffers (ping-pong buffering) you need min. three, I think this is because of the double buffered waitvid.

Andy

ozpropdev · 2013-10-29 18:10

Ariba wrote: »

The glitch you see near the end of a line comes from overwriting the stack ram with the data of the next line while the video shifter still shifts out the stack ram. At the time you see the glitch the old line gets ovewritten with the data of the next line before the old data is shifted out.

Aha!

Thanks Andy, that makes perfect sense.
My understanding of the double-buffered arrangement was incorrect.
Now I can get some sleep!

I'll have another look at it all today.

Cheers
Brian

ozpropdev · 2013-10-30 02:55

Ok, here's the current status of the tests.

Andy's suggestion on the CLUT ram being overwritten before it has been shifted out was correct.
By creating my own double buffer has fixed the problem in most of my tests, but not all.
See attached tests 1-5 which all now work correctly.
vga tests fixed.zip

The sync issue raised by Tubular and Chip seems to be my issue now.

Test AA - 22 x 32 pixel columns + 1 x 96 pixel column - OK
Test BB - 25 x 32 pixel columns - Fails to SYNC at all! ????
TEST CC - Sane as test BB but with Hsync moved like previous fix. OK
vga tests AA-CC.zip

Hsync pattern on test BB is as earlier scope image (see bad h sync.bmp) very erratic.
Once agin all results are identical on 4 completely different monitors.

More tests on Hsync to Vsync timing as Chip suggested are required.

Cheers
Brian

cgracey · 2013-10-30 09:33

Ariba wrote: »

...But I have found that it not works always with only two buffers (ping-pong buffering) you need min. three, I think this is because of the double buffered waitvid.

I've always used only two buffers, but the trick is to do the WAITVID for the buffer which you are going to immediately fill next. Because of the double-buffering, that buffer won't be read until the prior WAITVID completes.

potatohead · 2013-10-30 09:59

And that's the hard part. Very tempting to write the waitvid for the buffer you have just filled...

Now that I think about it, perhaps that is the trouble with Baggers driver that tears. This weekend, I'm going to go look.

pedward · 2013-10-30 15:42

FWIW, I had lots of trouble with this until I took the approach of incrementing the pointer to the CLUT entry used on ever call. This way the CLUT was recycled after a short period and no contention existed for CLUT entries.

ozpropdev · 2013-10-30 22:41

Ok

All my sync issues are now solved.

It turns out I was chasing two issues that just happened to be sync related.

My loss of sync issue turned out to be my code taking too long to prepare the next line of pixel data.
At 80Mhz (80MIPS) I over estimated how much stuff I could do after my WAITVID instruction . Oops!

Each line starts of with a Hsync pattern. This is built on 3 parts, front porch,sync and back porch.
Pixel time for the Hsync is 40 + 128 + 88 pixels. Using a 40Mhz dot clock this equates to 6.4uS.
Each 32 pixel column takes 800nS to shift out.
By placing the Hsync before my pixel handling stuff opened a bigger window to process the code (approx. 5.4uS instead of 800nS)

This in combination with my double-buffer issues lead to some interesting results.

I'm feeling better now and my coffee consumption is returning to normal levels.

Thanks to all for your help. Now back to testing code....

Cheers
Brian

Cluso99 · 2013-10-31 00:40

Pleased to hear you have resolved the problems and there are no silicon problems. Sorry you spent so much time on this, but we all have learnt from this.

WAITVID sync glitches

Comments