Concept & Design of 3.3V Parallel 16-bit VGA Boards

[ElEctric_EyE]

Arlet wrote:

...By the way, I see R10 and R11 marked on the bottom, but the two pads are connected to each other. What's the purpose of these resistors ?

R10 was meant as a pull-down for the PROGRAM button, which goes to pin 37 of the FPGA. That pin itself is pulled up to 2.5V by a 4.7K resistor. I wanted R10 present because if an external PROGRAM signal was being pulled low at the same time the button wasn't being pushed there wouldn't be a hard short. If the board is to be controlled externally, probably best not to push the switch at all, or cut the line and install a resistor less than 4.7K, probably 1K would do... Same reasoning for R11, which goes to GND for the programmable switches...

Glad you're getting into the fray! Let me know if you need another board or 2 and the mainboard in the future, for parallel endeavors...

[ElEctric_EyE]

Arlet wrote:

...Now, I need to figure out how I'm going to test the VGA. I only have one monitor, and it's hooked up to my desktop PC. I don't feel like disconnecting the VGA connector from the PC every time I want to test the FPGA board....

There are the cheap manual switchers on ebay for ~$7 that take 2 SVGA inputs for one monitor. Or even 4 ports into 1 for <$9.

[ElEctric_EyE]

Here is my latest project file for drawing a green line. It'll test out your card and monitor for 640x480.

[Arlet]

ElEctric_EyE wrote:

Here is my latest project file for drawing a green line. It'll test out your card and monitor for 640x480.

Thanks. I ran the project, and I got the green line just like you showed in the other thread, so I know the board works. I'll go play around with some of my own code My first goal is an improved VGA timing controller, with a FIFO-based data path.

[ElEctric_EyE]

Arlet wrote:

... My first goal is an improved VGA timing controller, with a FIFO-based data path.

Nice... Are you aiming for sprites?

[Arlet]

ElEctric_EyE wrote:

Arlet wrote:

... My first goal is an improved VGA timing controller, with a FIFO-based data path.

Nice... Are you aiming for sprites?

My old sprite module should mostly work, except that it can't handle the higher resolutions yet. So, this will require some modifications, especially in the CPU registers.

[Arlet]

I've made a first version of the FIFO based VGA generator. Still hardcoded for 640x480, but the VGA module now uses look up tables for all the timings. The idea is that these tables will be writable through a simple addr/data/we interface.

I've also changed the VGA code to count to 1 instead of -1. This takes slightly more resources (and time), but on the much faster Spartan-6, that's not a problem, and this allows you to use 640 to set the width, rather than 638, like it was before.

At the bottom of main.v, you'll find a simple test pattern generator, as a demonstration on how to use the FIFO interface.

vga_fifo_test.zip

ISE project

(105.33 KiB) Downloaded 168 times

[Arlet]

I made a github repository for this project, and added some refinements and bug fixes. Among other things, the test bench will create .ppm files with screen shots. Here's the output from the test image:

0000.png (2.6 KiB) Viewed 1659 times

[ElEctric_EyE]

Ah, very cool test. So no worries of simultaneously switching outputs on this design even with the small SOT-223 VReg's?
I got a successful output after I'd realized that I had to pull up DACBLANKn, since I use v1.0g. I would've responded earlier when I first tried. But I had realized my issue, then had to run some errands. So now it works.

Do you use the R5,R6 & R7 impedance matching resistors?
When do you anticipate your SyncRAM arriving?

[Arlet]

Do I need to pull up DACBLANKn too ? I never paid any attention to it. This isn't the worst possible test for SSOs, since there's a 1 pixel red line between the black and white pixels, so only a maximum of 11 switching bits at the same time. In any case, the problem would not be with the SOT-223 regulator, but rather the inductance of the traces (including the ones inside the TQFP package). By the way, since I don't have easy access to 3.3V supply, I just patched the output of the 3.3V regulator into the 3.3V input on the board, so the single regulator is powering both video DAC and FPGA. So far, so good If it gets too hot, I'll add a beefier regulator on the board somewhere.

I did mount R5-R7, but since I didn't order any 75 Ohm resistors (I figured I'd just pick the resistors from my standard set, until I realized there were some non-standard values), I mounted two 150 Ohm resistors on top of each other.

I haven't ordered the SyncRAM yet. I wanted to make sure everything else was working first. For now, I'll just play around with the bare FPGA, and see what I can do with the block RAMs.

Edit: I did notice some weird interference on the screen, but then I figured I could make it go away by disconnecting the JTAG pod. Also, I noticed a change in overall brightness when doing that.

[ElEctric_EyE]

Arlet wrote:

Do I need to pull up DACBLANKn too ? I never paid any attention to it...

No, it was commented out in the .ucf file you're using for v1.0h. In that version the pin of the FPGA now goes to the MSB of a 4MB SyncRAM.

Arlet wrote:

...By the way, since I don't have easy access to 3.3V supply, I just patched the output of the 3.3V regulator into the 3.3V input on the board, so the single regulator is powering both video DAC and FPGA. So far, so good If it gets too hot, I'll add a beefier regulator on the board somewhere...

So you are working strictly off of a 5V supply and you power everything from the 3.3VReg meant only for the videoDAC? I wouldn't be worried about the heat, i.e. lack of current from the regulator. I would worry about noise, which is why I have the videoDAC regulated from a separate voltage source. Hopefully the noise will not introduce errors for you.

Arlet wrote:

...Edit: I did notice some weird interference on the screen, but then I figured I could make it go away by disconnecting the JTAG pod. Also, I noticed a change in overall brightness when doing that.

Interesting. I don't use the impedance matching resistors. Instead I adjusted the contrast and brightness of the monitor controls. Also, I see no noise and when I unplug the JTAG connector there's no change in brightness.

[ElEctric_EyE]

BTW, with your new vga module that generates HSync and VSync, I now see the blue border on the TFT and older style CRT monitors. The TFT was trimming the visible borders out with the older vga module.

[Arlet]

Yes, my adjustable power supply only has 1 output, so I've set it to 5V, and use the regulator to make the 3.3V. I also forgot to order the ferrite bead, so I've skipped that as well.
So far, the noise isn't interfering with the digital logic. It may be interfering a bit on the video output, but not to the point where it's reason for concern (yet). Of course, when more logic gets added to the FPGA, things may get worse.

[Arlet]

ElEctric_EyE wrote:

BTW, with your new vga module that generates HSync and VSync, I now see the blue border on the TFT and older style CRT monitors. The TFT was trimming the visible borders out with the older vga module.

Strange. There should not be a difference in the actual timing of the sync pulses. Of course, since your module was sending different pixel data than mine, that may cause some differences in the way the image gets displayed.

[ElEctric_EyE]

I've been looking over your code. Sort of difficult to understand, but it looks like it wouldn't be too difficult to add/modify it to read from the RAM. Is it as straightforward, for a simple test, where one could assign the x and y pixel counters as the RAM address in the main.v module, then have the fifo_data <= SRAMdata?