digilent nexys vga glitches

Newbie problem: I get some nasty horizontal jitter on vga display controlled by a vga controller (see below) running on a digilent nexys board. It looks like all scan lines jitter relative to each other (couple of pixels left/right). The problem is worse on the first 1/16th of the screen and it is getting better below (still jitters on the bottom though).

Looking at the hsyncs via an oscilloscope shows that the pulses do actually slide left and right like crazy and are really unstable (10-20ns jitter).

I tried to look at the output of a production vga adapter and it looks more stable (do not jitter as much) and the edges of the pulses are much more "square" (raise time is much smaller). Another difference is with the voltage - nexys uses 3.3v and it looks like the vga adapter I tried has 5v output.

I looked all over the internet and it doesn't seem like anybody else has this problem. Have anybody tried to get a nice and stable picture via nexys vga? What am I doing wrong? Is it supposed to be that "imperfect"? How do I fix it?

The setup: - 100Mhz nexys builtin oscillator clock is fed into mclk input signal - Desired output 800x600 72Hz (50MHz pixel clock) - nexys vga (vga port + 12 resistors) is used (inserted into j8 slot)

-- variation of vga controller code (this is one of the ways

-- i tried library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity vga2 is Port( mclk: in std_logic; ssen: out std_logic_vector(3 downto 0); led: out std_logic_vector(7 downto 0); j8VGAR: out std_logic_vector(3 downto 0); j8VGAG: out std_logic_vector(3 downto 0); j8VGAB: out std_logic_vector(3 downto 0); j8VGASync: out std_logic_vector(1 downto 0)); -- - hs, - vs end vga2;

architecture Behavioral of vga2 is signal hCount: std_logic_vector (11 downto 0); signal hBlank: std_logic; signal hSync: std_logic;

signal vCount: std_logic_vector (20 downto 0); signal vBlank: std_logic; signal vSync: std_logic; begin -- count pixels process constant pixClocks: integer := 2; constant hMax: integer := 1040*pixClocks; -- line duration constant hWidth: integer := 120*pixClocks; -- hsync width constant hBack: integer := 61*pixClocks; -- line back porch constant hFront: integer := 53*pixClocks; -- line front porch

constant vMax: integer := hMax*666; -- frame duration constant vWidth: integer := hMax*6; -- vsync width constant vBack: integer := hMax*21; -- frame back porch constant vFront: integer := hMax*35; -- frame front porch begin wait until mclk = '1' and mclk'Event;

-- update horizontal counter if hCount = hMax - 1 then hCount '0'); else hCount

Reply to
Corer
Loading thread data ...

Are they clean ? (no ringing) If they're clean, but just too slow rising, you can try to change the IOB properties of the hsync output, try to add things like DRIVE=24 and/or SLEW=FAST (I'd try the DRIVE first, at 50MHz the FAST slew doesn't make much sense I think)

Sylvain

Reply to
Sylvain Munaut

Are they clean ? (no ringing) If they're clean, but just too slow rising, you can try to change the IOB properties of the hsync output, try to add things like DRIVE=24 and/or SLEW=FAST (I'd try the DRIVE first, at 50MHz the FAST slew doesn't make much sense I think)

Sylvain

Reply to
Sylvain Munaut

What's the source of the clock for the VGA? Does it look good?

--
Ben Jackson AD7GD

http://www.ben.com/
Reply to
Ben Jackson

It looks like I was wrong and the raise time of production vga controller is about the same as I get out of my proto-board - HSync raise time is about

19ns 0->5v on production vga and 20ns 0->3v on Changing DRIVE and SLEW doesn't make any difference to the resulting picture.

My hsyncs do ring (you can not avoid that right?) Ringing dies off in 230ns and I get four periods of a transient. Pronounced peaks are at

3.3v+0.85v; 3.3v-0.41v; 3.3v+0.2v; 3.3v-0.2;

Ringing on the real adapter hsync dies in 200ns and transient peaks are around 0.6/-0.5 but they look "smoother" and are lower frequency (sorry for my terminology). Don't forget their hsyncs are 5v high while mine is "only" 3.3

I think that the main problem I'm having is hsync to hsync jitter. If I set my analog oscilloscope to trigger at an hsync raising edge and then see what happens 470mks later I see a smear. For a production vga adapter I see a solid edge that "pans" left and right.

Corer.

Reply to
Corer

I have a proto board from digilent

formatting link
=Programmable

Nexys board has a builtin 25/50/100MHz oscillator which I use for my project's mclk input. I tried to route the clock to one of the output fpga connectors and 100MHz output doesn't look like a square wave at all (it looks more like a sine wave). Unfortunately it could be that oscilloscope/probe/myself system can not deal with such a high frequency.

BTW If I display voltage of 100MHz pin driven through fpga 2000ns after the trigger event I see a smear. The waveform is barely distingushable after 800ns. Is it supposed to be like this? I'm really new to the electronics and it looks like I'm not ready to deal with imperfections :-)

Corer

Reply to
Corer

Hi Corer,

No probs using the Nexys this end. I have the VGA adapter card aswell. Tried it with 640x480 and 800x600, 60Hz.

Couldn't get 1024x768 working properly, but that will be a job for a rainy weekend.

I was using a 25MHz pixel clock though, as in the "squares" example from:

formatting link

25 or 50MHz inputs on MCLK instead of the 100MHz you are using may be more forgiving.

Cheers, Red

Reply to
RedskullDC

Thanks for the info... I think I tried driving it from

50MHz and didn't make any appreciable difference. Could it be my oscillator is that bad? Are you using j8 connector? Do you see anything wrong with my vhdl? (first message in this thread)

I do not really know whether it is at all possible, but could share your code, so I could try and run it on my nexys? It would be just great.

I tried to look at

formatting link
it doesn't seem to work (at least right now). I'll try again later

Corer.

Reply to
Corer

Hi Corer,

Not my page, hopefully you will be able to view it later. I tried it this evening and it seems to be up.

Doubt your oscillator is bad if you are seeing anything. Try a simple divide by 2 or 4 circuit and check the output with your scope.

I am using J8.

Have you stipulated a constraint of 100MHz input for the mClk pin to see if your design can run at that speed?

10ns clock period doesn't leave much room to play with.

Thing that immediately strikes me with your code is that the vertical count is not synchronized to the horizontal count.

Best to make the Vcount a function of Hcounts. If your maths were not 100%, or a pulse or 2 got lost, then the HSync and VSync signals can get back into sync again at the end of each frame.

Red

Reply to
RedskullDC

Thank you for your time Red. I was able to access the url and did the following: - copied the squares code into a brand new vhdl project created with Xilinx ISE 7.1i - changed clk50 into clk25 (see below for full vhdl code) - flipped the clock jumper on Nexys to 25MHz - assigned pins (see .ucf below) - Changed "Generate Programming File" FPGA Start-Up Clock option to JTAG Clock - Added one timing constraint "25 MHz HIGH 50 %" to clk25 signal in Xilinx Constraints Editor - have not touched anything else in the project - Built the project - Uploaded it onto Nexys using ExPort

And I'm still getting the scanline jitter on my monitor. Could you try to run my code (below) on you nexys and say whether the picture is perfectly stable?

25MHz looks like a 25MHz square wave (it rings just a little bit) 1000ns after-trigger-delayed trace shows "thicker" edges (due to jitter)

I've changed my clock to 25MHz and set the timing constraint. xilinx tools displayed the following:

----------------------------------------------------------------------------

--
  Constraint                                | Requested  | Actual     |
Logic
                                            |            |            |
Levels
----------------------------------------------------------------------------
Reply to
Corer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.