FPGA Video Display Adapater

[jbaum81]

Hi guys,

Trying to build a video `card` for my 6502 project and I'm sort of at the early stages with just video output reading addresses out of ram and piping through a palette.

Problem is that I'm getting some flickering, if you look at the picture where boxes are not perfectly square those lines are shaking. I would think it was just a timing issue with sram, but my sram is 10ns and I've gotten the same results running both a 25.175 640*x480 as well as an 800*600 @ 40mhz and the monitor looses sync randomly. I've also attached my Verilog to see if anyone can help.

Thanks!

[geon]

Is the photo of an LCD or a CRT?

[Martin A]

I don't think it's necessarily your Ram either.

I managed to get 2 reads per 8 pixels from 55ns ram at 40mhz, for 100x 32 text on 800 x600 SVGA timings.

viewtopic.php?f=10&t=6502&start=45#p85539

It might be worth checking exactly when your address addition is taking place. Simple adders use a ripple carry, and that takes time, it'm wondering if the addition is sometimes incomplete when the "next" address is required.

[jbaum81]

Must be alliance memory , I've had great luck pushing that stuff well past mfg's recommended specs.

As far as the counters, that crossed my mind too, but I'm incrementing a register that has way more than enough space on the rising edge of a PLL clock, and the PLL shows locked... I thought it might be something to do with the way i'm pipelining the next vSync values, that one scrambled me a little at first since it does depend on the end of the horizontal row, but I'm pretty confident I did it right.

[Rob Finch]

What kind of connector are you using? Does it connect directly to the FPGA through circuit traces? Using a ribbon cable for instance will pick up a lot of noise.
What does the timing circuit look like? Are the sync signals registered outputs? Are the ram address signals registered? Is the address the output of synchronous or ripple counters? It looks like there may be some sort of delay in one of the counter bits. There is a little glitch 16 rows apart.

[jbaum81]

Rob Finch wrote:

What kind of connector are you using? Does it connect directly to the FPGA through circuit traces? Using a ribbon cable for instance will pick up a lot of noise.
What does the timing circuit look like? Are the sync signals registered outputs? Are the ram address signals registered? Is the address the output of synchronous or ripple counters? It looks like there may be some sort of delay in one of the counter bits. There is a little glitch 16 rows apart.

Using a mercury II (Xilinx Artix 7) connected to one of the DVI PMOD's for the icebreaker. the PMOD is connected through jumper wires that are ~100mm long. I get nearly the exact same interference running a 25mhz (640*480) clock as the 40mhz 800*600 clock.

The mercury II has a 50mhz oscillator driving the PLL putting out 200mhz for the main FPGA clock and another @ 40mhz for the video. The counters are just registers that get incremented at the rising edge of the Vid clock. All outputs are registered and pipelined through a clock cycle to allow time for the read of the memory.

This is the sequence of events

1. On rising edge of the Vid Clock the following takes place sequentially.
A. the "next{vSync | hSync | DE | RGB} registers are copied to the corresponding output registers
B. counters are incremented
C. counters are mapped to memory address output register
D. SRAM CE is pulled low.
D. next{vSync | hSync | DE} registers are set based upon the current values of the counters.

2. on the falling edge of Vid Clock the value of the SRAM data lines are stored to the nextRGB register.

Timing wise it should be plenty of time. The counters look like this


reg [15:0] hcounter = 16'b0;

always @(posedge vClk) begin
if (//some logic) begin
hcounter <= hcounter +1;
end

end


My source code was attached as a zip to the first post. I didn't want the post to be too long so I didn't imbed. I can imbed if that helps?

[Rob Finch]

It looks like in the vgaDriver.v the timings are for a 50MHz clock. 72Hz refresh rate. IF the video clock is only 40MHz then the times will be off.
1040x666 timing is for 50MHz clock rate 72Hz refresh
1056x628 timing is for 40MHz clock rate 60Hz refresh

[jbaum81]

It is 50mhz, sorry i was thinking of another resolution i was trying that ran on 40. The picture was taken at 50mhz with the attched code in the forst post.

Did you happen to see anything wrong?

[Rob Finch]

I do not see anything wrong. I notice the palette output is being clocked on the negative edge of the clock. There would be more time for the palette if it was clocked on the positive edge. This would shift the display pixels by one clock to the right which probably is not a bit deal. If desired a pipeline stage for the sync and display enable signals could be added. But most monitors allow for at least two pixels extra spacing. In a couple of places, the number of zeros is off by one compared to the size of the reg. 15’d0 instead of 16’d0, and 11’d0 instead of 12’d0. This will not affect anything, but SIM might complain.

[kernelthread]

You've got at least 3 clocks I can see in your system. One of them looks like the cpu clock, so I guess that won't be having any effect when the screen memory isn't accessed by the CPU. However it looks like both the others are used, so are you sure that all the setup/hold time requirements are being met if the D input to a flip-flop changes on one clock but the flip-flop itself is clocked by the other?

[fachat]

With xilinx CPLDs I had the effect that sometimes I had to be careful to double buffer signals. When I drove a pipeline always on the same clock edge, sometimes signals would 'overtake' a step as the clock was probably distributed differently and the result of the previous stage was already visible on the following step but in the same clock cycle. That resulted in flickering in my VGA card...
So I had to buffer on the opposite edge between stages. At least that's what I figured and the 'double buffering' at least helped.

André

[jbaum81]

Just to post a follow up on this subject.

This is resolved and here is sort of the final state

On the rising edge of the video clock I latch in the horizontal and vertical counters which are piped over to the ram

on the negedge of the video clock the video positions are latched into a buffer register along with the returned data from the ram

on the posedge the buffered positions are set to the output registers that go to the HDMI driver itself

This results in a 1 clock delay from the signal generator to the hdmi signal itself allowing time for the the ram to become valid. The output of the ram feeds to color palette and/or the font rom which is a continual assignment that sends the final pixel data to the HDMI driver. Works perfectly.