HDL Implementation of Video Generator Test for 16-bit PVB's

[Arlet]

To simplify the code (and removing a cycle of latency at the same time), you can also remove the SRAddrtemp registers, and write directly the SRAddr. Something like this:

Code: Select all

always @(posedge clk50)
   if ( vstart )   //reset address counter at top left of screen
      SRAddr <= 0;
   else if ( pclk & countflag )
      SRAddr <= SRAddr +1;         //increment RAM address counter

[ElEctric_EyE]

Excellent.

I was thinking, with this much RAM at this low resolution, would it advantageous to do bank switching? Like a scheme where we could R/W to the memory at any time without the 'snow' effect?

EDIT: or maybe we would need 2 separate memories piggybacked... I heard of this being done somewhere, but I can't remember the details of how it was hooked up.

[Arlet]

ElEctric_EyE wrote:

I was thinking, with this much RAM at this low resolution, would it advantageous to do bank switching? Like a scheme where we could R/W to the memory at any time without the 'snow' effect?

It could be interesting to make multiple banks, so you can do double buffering. The CPU would write one buffer, while displaying the other one. When the CPU is finished, the two buffers are flipped, creating a smooth change.

The snow effect is caused because the data fetch from the video generator collides with CPU access. Creating multiple banks wouldn't help, since you'd still only have a single shared address/data bus.

However, the snow effect can be fixed by buffering the data inside the video generator. You can read a bunch of data from the SRAM at 100 MHz clock speed, and store that data inside the FPGA in a FIFO. While the video generator sends the pixels at only 25 MHz, the CPU can have full access to the memory, without any conflict.

[ElEctric_EyE]

Arlet wrote:

... You can read a bunch of data from the SRAM at 100 MHz clock speed, and store that data inside the FPGA in a FIFO. While the video generator sends the pixels at only 25 MHz, the CPU can have full access to the memory, without any conflict.

Ah that's right. You did something similar for the last project, I think. Didn't you use one scanline for the FIFO?

Anyway, I will leave this complicated development for you and I will study... With the amount of mistakes on this board, I will send in the new board version to be made soon.

I think these graphic boards are going to be very rewarding as far as speed.

[Arlet]

ElEctric_EyE wrote:

Ah that's right. You did something similar for the last project, I think. Didn't you use one scanline for the FIFO?

I used a block RAM as a FIFO. That's 1024 pixels @ 16 bits per pixel. The nice part about a FIFO is that it's really easy to work with. You get a 'vtrigger' signal that indicates it's time to start a new frame. When you get that signal, you have to send 640x480 pixels into the FIFO. Whenever the FIFO is full, you get a signal, and you pause. Since the vtrigger signal comes early (during border), you get plenty of time to fill up the FIFO. The VGA module is then responsible for taking data from the FIFO and match it exactly with the VGA timing.

I have the code for the CS4954 module, so I would still need to make a VGA version.

[ElEctric_EyE]

I've made the suggested changes. Now the pixel clock going to the videoDAC and the syncRAM are the same. Also using vstart to zero my address counter, and getting rid of SRAddrtemp. Now it's rock steady, and clean signal. Pic is deceiving as there are no borders yet. I will try to push the limits of the SyncRAM and see the upper limits of resolution. Aiming for 1024x768 next, @768K there is enough RAM for a framebuffer. I think 1280x1024 will be out of the question. One thing I would like to do is add registers to Arlet's HSync module, so variables can be programmed by a cpu on the fly.

[Arlet]

I can't understand why there are those horizontal bars at the right hand side of the screen.

[BigEd]

It looks like whatever is pushing new pixel values stops when it thinks it is at the of the line. (It's pushing them from the wrong source, or wrong locations, I suppose)

[Arlet]

I think the RGB outputs need to be set to black during front/back porch and blanking interval. The monitor is probably getting confused about the resolution now.

[ElEctric_EyE]

I have tried to do a quick test and logical NOR the vblank and hblank signals for the active low DACBLANK signal. It drives the RGB outputs to the blanking level. My little experiment didn't work when I was working with the vertical bar test.

[Arlet]

I mean something like this:

Code: Select all

always @(posedge clk50)
   if ( pclk )  begin
      Red_data   <= countflag ? SRDtemp [15:11] : 0;      //outgoing data to videoDAC
      Green_data <= countflag ? SRDtemp [10:5] : 0;
      Blue_data  <= countflag ? SRDtemp [4:0] : 0;
   end 

[ElEctric_EyE]

That would be nice if that works and I can save another pin from the FPGA for something else.

Unfortunately, I can't try this until Sunday, after a brief retreat to the beach with family.

Will report back!

[ElEctric_EyE]

Also, I'm thinking I should also test to see how this picture is looking on an older non-multisync VGA crt. I can do this test next wed. May have to use the PLL to get closer to the ideal 25.175MHz, will still be a couple hundred Hz off though.

[ElEctric_EyE]

Did some testing on an older CRT manufactured in 1998, unsure if it has the multi-sync hardware built in. There were vertical borders present, clearly seen about 1/2" on top and bottom. Also, bars like the ones on the right side of the above pic (flat screen monitor), were on both sides of this monitor. So the observation seems to be inline with some of my readings, that the newer flat screen monitors automatically trim HSYNC and VSYNC timings so that there are practically no visible borders.

I changed my code by memory from what Arlet had mentioned before. I thought he had used hblank as the trigger, but I saw he chose countflag. Maybe it doesn't matter? But it works. Interesting thing though, the picture is much brighter than before. I will add the 75ohm load resistors back to the videoDAC RGB outputs.

So this means I will have 1 more global clock pin freed up on v.1.0h, since I can just tie the videoDAC Blank pin high. EDIT: I think this pin will best be used for a separate MicroSD adapter serial clock apart from the serial clock common to the FLASHs.

Code: Select all

module SRAMif( output reg [20:0] SRAddr = 0,
					output reg WEn = 1,
					output reg SRCS = 1,
					input [15:0] SRD,
					output reg [4:0] Red_data,
					output reg [5:0] Green_data,
					output reg [4:0] Blue_data,
					output reg DACBLANKn = 1,
					input clk50,
					input pclk,
					input hstart,
					input vstart,
					input hblank
					);

reg [15:0] SRDtemp;
reg countflag;

always @(posedge clk50)
   if ( pclk )
      if ( hstart )
         countflag <= 1;	//countflag active in display area
      else if ( hblank )
         countflag <= 0;
		
always @(posedge clk50)
	if ( vstart )	//reset address counter at top left of screen
		SRAddr <= 0;
	else if ( countflag )
		SRAddr <= SRAddr + 1;			//increment RAM address counter
		
always @(posedge clk50)
	if ( pclk & countflag )
		begin
         SRDtemp <= SRD;	//latch incoming data;
			Red_data <= hblank ? 0 : SRDtemp [15:11];		//outgoing data to videoDAC
			Green_data <= hblank ? 0 : SRDtemp [10:5];
			Blue_data <= hblank ? 0 : SRDtemp [4:0];
		end
			
endmodule

[ElEctric_EyE]

@Arlet. I'm trying to 'up' the resolution to 1024x768x60Hz by using the settings shown in the tinyvga site. Can your vga module go up to this 1024 horizontal resolution? I've changed all the parameters to match the tinyvga site, I also made the odd parameters even, by adding 1, since your counters seem to subtract by 2...

I still struggle with top_level clock interconnects. What I thought should work is not working at this point. The old settings for 640x480 and the new settings, I'm trying for 1024x768 as far as HSYNC & VSYNC, are both negative edge triggered so no mod's there to your code. And you Horizontal counter goes up to bit [10]...

EDIT: clk50 input frequency is now 130MHz outputted from a DCM from the main 100MHz input.