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

[ElEctric_EyE]

Had just a bit of success today towards my lofty goal of a Cordic Graphic Processor. No Cordic here yet, but I was able to plot a green pixel based on X & Y counters, amidst alternating black and red pixels. If I change to white & red alternating pixels, it's incorrect for some unknown reason. Any hints?

Code: Select all

module VDACif( input clk108,
					input hstart,
					input vstart,					
					input hblank,
					input vblank,
					output reg [4:0] Red_data = 0,
					output reg [5:0] Green_data = 0,
					output reg [4:0] Blue_data = 0,
					output reg DACBLANKn = 1
					);

reg countflag;
reg [8:0] X = 0;
reg [7:0] Y = 0;

parameter
Xmax = 320,
Ymax = 200;

always @(posedge clk108)
      if ( hstart )
         countflag <= 1;									//countflag active in display area
      else if ( vblank | hblank )
         countflag <= 0;
			
always @(posedge clk108)
	if ( countflag )
		X <= X + 1;												//count inside the border
		else 
			X <= 0;
			
always @(posedge clk108)
	if (( vblank | hblank ) & ( X == Xmax - 1 ))		//test for last horizontal pixel 
		Y <= Y + 1;
	 else if ( Y == Ymax )
		Y <= 0;
			
always @(posedge clk108)									//outgoing data to videoDAC
		if ( X == 49 & Y == 50 ) begin
				Red_data <= 0;
				Green_data <= 6'b111111;
				Blue_data <= 0;								//Priority 1, plot green pixel at (49,50)
		end
		
			else if ( !countflag ) begin
				Red_data <= 0;
				Green_data <= 0;
				Blue_data <= 5'b11111;						//Priority 2, blue border
			end
			
			else if ( X[0] ) begin				
				Red_data <= 5'b11111;		
				Green_data <= 0;
				Blue_data <= 0;								//Priority 3, odd pixels red
			end
				else begin				
					Red_data <= 0;
					Green_data <= 0;
					Blue_data <= 0;							//Priority 4, even pixels black
				end
				
	
	
endmodule

EDIT: Changed 'else if ( vblank | hblank ) begin' to 'else if ( !countflag ) begin' for border logic.

[Arlet]

ElEctric_EyE wrote:

If I change to white & red alternating pixels, it's incorrect for some unknown reason. Any hints?

If all you do is change red/black into white/black, and it fails, I would suspect you have a problem with too many switching outputs. Did you mount all your decoupling caps ? You can try experimenting with drive strength and slew rate of the outputs.

[ElEctric_EyE]

I made a small change to the code so it now looks correct in simulation, but same result on the monitor. Interestingly, same action down to 4mA drive strength. Thankfully I observe correct colors when I make the border black (still @4mA), so I don't think it's an SSO issue. I think I'm confusing the monitor somehow. How do I get rid of the diagonal lines? That is the vertical retrace? I need to send zero's during this time don't I?

[Arlet]

Yes, during vertical blanking interval (including front porch, back porch, and vsync interval) you need to send black values.

[ElEctric_EyE]

Ok thanks for the hint. I checked the Sim and made it so that the DAC sends zeros during ( vblank & vsync ). Almost works on my LCD using 640x480 @25MHz using timings from tinyvga website. The display area is too large, but I see correct border color (blue) and display colors (alt. blue & red) when manually shifting horizontal and vertical position using monitor controls. However, on the old CRT it is still confused and I see black and red with a green dot. I will aim for correct display timings on the TFT then see if the CRT complies.

[ElEctric_EyE]

Got it working on the LCD monitor! To make it useful and make sure that my timings are correct, I successfully plotted a green pixel @ (0,0) and also @ (639,479). The hardware in the LCD seems to automatically trim off the borders. Now, I would like to draw lines in hardware. I'll look at FPGA4FUN and openVGA project for clues. I'll work on getting the CRT working abit later...
LARGE pic.

Code: Select all

module VDACif( input clk108,
					input hstart,
					input vstart,					
					input hblank,
					input vblank,
					input VSYNCout,
					output reg [4:0] Red_data = 0,
					output reg [5:0] Green_data = 0,
					output reg [4:0] Blue_data = 0,
					output reg DACBLANKn = 1
					);

reg countflag;
reg [9:0] X = 0;
reg [8:0] Y = 0;

parameter
Xmax = 640,
Ymax = 480;

always @(posedge clk108)
      if ( hstart )
         countflag <= 1;									//countflag active in display area
      else if ( hblank )
         countflag <= 0;
			
always @(posedge clk108)
	if ( countflag )
		X <= X + 1;												//count inside the border
		else 
			X <= 0;
			
always @(posedge clk108)
	if ( X == Xmax )		
		Y <= Y + 1;
	 else if ( Y == Ymax )
		Y <= 0;
			
always @(posedge clk108)								//outgoing data to videoDAC	
	if ( countflag & (( X == 0 & Y == 0 ) | ( X == 639 & Y == 479 ))) begin
		Red_data <= 0;
		Green_data <= 6'b111111;
		Blue_data <= 0;									//Priority 1, plot green pixel at Min & Max corners
	end
		else if ( vblank & VSYNCout ) begin			
			Red_data <= 0;
			Green_data <= 0;
			Blue_data <= 0;								//Priority 2, send black during vertical retrace
		end
		else if ( !countflag ) begin
			Red_data <= 0;
			Green_data <= 0;
			Blue_data <= 5'b11111;						//Priority 3, blue border
		end
		else if ( X[0] ) begin				
			Red_data <= 5'b11111;		
			Green_data <= 0;
			Blue_data <= 0;								//Priority 4, odd pixels red
		end
			else begin				
				Red_data <= 0;
				Green_data <= 0;
				Blue_data <= 5'b11111;					// even pixels blue
			end
	
endmodule

[Arlet]

Do you want to draw lines on a bitmap, and then display the bitmap ? Or do you want to generate lines on the fly, as you generate the display (display list)

[ElEctric_EyE]

I think for now, no bitmap, only because soon I would like to make another PVB and have it output what I'm working on now into the second PVB. Then maybe at this point have it go into the frame buffer of the 2nd PVB.

[Arlet]

What version board are you using by the way? Is this still the first one, or did you assemble one of the new boards ? Anyway, line drawing is not the easiest thing to do, either with bit map or display list. Maybe you should try a text display. FPGA4FUN has an example, and it's a useful thing to have. You can make one with block RAMs, and then attach a CPU to the other port of the block RAM to provide a text output.

[ElEctric_EyE]

Arlet wrote:

What version board are you using by the way? Is this still the first one, or did you assemble one of the new boards ?...

This is still the first one, v1.0g, without the very useful pushbuttons present on v1.0h. I sent you 1 v1.0h board, so I have 2 of them on standby...
I was looking at openVGA and I don't see any line drawing modules. I guess he draws triangles using one of his processors, I'm guessing the TTA16 that runs at 140MHz.

I don't think it would be that difficult, after all it is a repetitive over/down/plot-over/down/plot or over/up/plot-over/up/plot, etc. If I could do it in hardware, I can only imagine the speed! This was the reason I wanted to learn Verilog in the first place, so I am eager to do this.

[Arlet]

Drawing on a bitmap requires first having a bitmap, plus a read channel for the display output, and a read/write channel for a processor that can draw lines. This already requires a fairly complicated bunch of logic for the memory interface. And if you want to draw the actual lines in hardware, it will take even more.

[ElEctric_EyE]

Well, I thought I would have 1 module similar to the one I have now that would plot the pixels from 2 10-bit wide, 800 deep RAMs. 800 being the longest possible line for 640x480. 1 RAM containing X, the other Y values. Another module would calculate the values to be stored in the RAMs, from some registers containing Xstart, Ystart, Xend, and Yend. Another register would hold the color info.
What do you think?

[Arlet]

I see, you want to use the RAM (block RAM I suppose) to hold a list of pixels. It would work, but you would have to keep the pixels sorted (first by Y then by X) so you can retrieve them in the order that you need them. If you generate them top-down, left-to-right, then they automatically show up in the right order.

[ElEctric_EyE]

Arlet wrote:

I see, you want to use the RAM (block RAM I suppose) to hold a list of pixels...

Yes, so this blockRAM should be instantiated on the top_level? Will it still be a RAMB16BWER dual-port type, just 1 port always read and 1 port always write?

[Arlet]

Yes, that'll work.