Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[SOLVED] Query : No display on monitor ( 800*600 resolution ) VGA CONTROLLER BASYS 2 BOARD

Status
Not open for further replies.
Thank you everyone for your help. The code is working as I made certain changes and I am getting the desired result now.

Code :

Code:
module vga_controller(input wire clk,reset,
output wire hsync,vsync,
output [2:0] red, // three bit signal to drive color red
output [2:0] green, // three bit signal to drive color green
output [1:0] blue, // two bit signal to drive color blue (human eye is less sensitive to color blue)
output reg video_on);
	 

// defining constants
localparam HD = 800; // horizontal display area
localparam HF = 56; // front porch (right border)
localparam HB = 64; //right porch (left border)
localparam HR = 120; // horizontal retrace
localparam VD = 600; // vertical display area
localparam VF = 37; // front porch (bottom border)
localparam VB = 23; // back porch (top border)
localparam VR = 6; // vertical retrace
localparam h_end = 1040; // total horizontal timing
localparam v_end = 666; // total vertical timing


//horizontal and vertical counter

reg [10:0] h_count_reg,v_count_reg ; // registers for sequential horizontal and vertical counters
reg[10:0] h_count_next , v_count_next;
//reg v_sync_reg , h_sync_reg ;
//wire v_sync_next , h_sync_next ;
reg v_sync_next , h_sync_next = 0 ;





always @ ( posedge clk , posedge reset)
if (reset)
begin
v_count_reg <= 0;
h_count_reg <= 0 ;
//v_sync_reg <= 1'b0;
//h_sync_reg <= 1'b0;
end
else
begin
v_count_reg <= v_count_next;
h_count_reg <= h_count_next;
//v_sync_reg <= v_sync_next ;
//h_sync_reg <= h_sync_next ;
end

// horizontal and vertical counters
always @(posedge clk) 
begin
if(h_count_next < h_end-1)
begin
			
h_count_next <= h_count_next + 1;
end
else 
begin
h_count_next <= 0;
			
if(v_count_next < v_end-1)
v_count_next <= v_count_next + 1;
else
v_count_next <= 0;
end
end

// horizontal and vertical synchronization signals
always @(posedge clk)
if(h_count_reg < HR)
h_sync_next <= 1;
else
h_sync_next <= 0;
			
	
//VSync logic		
	
always @(posedge clk)
if(v_count_reg < VR)
v_sync_next <= 1;
else
v_sync_next <= 0;

assign hsync = h_sync_next;
assign vsync = v_sync_next;


	
reg h_video_on,v_video_on; // these registers ensure that the display signals are sent only when the pixels are within the display region of the monitor.
//horizontal logic

always @(posedge clk) 
if((h_count_reg >= HR + HF) && (h_count_reg< HR + HF + HD))
h_video_on <= 1;
else
h_video_on <= 0;
			
	
//Vertical logic
	
always @(posedge clk)
if((v_count_reg >= VR + VF) && (v_count_reg < VR + VF+ VD))
v_video_on <= 1;
else
v_video_on <= 0;

always @(posedge clk)
if(h_video_on && v_video_on)
video_on <= 1;
else
video_on <= 0;


reg [9:0] pixel_x,pixel_y; // registers to describe current position of pixel within display area.

always @(posedge clk)
if(h_video_on)
pixel_x <= h_count_reg - HR - HF;
else
pixel_x <= 0;

always @(posedge clk) 
if(v_video_on)
pixel_y <= v_count_reg - VR - VF;
else
pixel_y <= 0;

//color output
reg [7:0] coloroutput; // 8 bit register which describes which color has to be displayed but only when video_on signal is turned on.

always @(posedge clk)
if(~video_on)
coloroutput <= 0;
else
begin
if(pixel_y<160)
coloroutput[7:5] <= 3'b111;
else if(pixel_y<320)
coloroutput[4:2] <= 3'b111;
else
coloroutput[1:0] <= 2'b11;
end


assign red = coloroutput[7:5];
assign green = coloroutput[4:2] ;
assign blue = coloroutput[1:0] ;


endmodule
 

Good to hear it's working. And thanks for reporting back. :)
 

I would suggest adding parenthesis around the constant subtraction (just so the synthesis tool can't mess up)
Code:
// instead of this:
pixel_x <= h_count_reg - HR - HF;

// use this:
pixel_x <= h_count_reg - (HR - HF);
This will guarantee that the constant is computed and subtracted from h_count_reg.

Regards
 

Can't hurt, and along the lines of defensive programming/coding/whatevering I certainly agree. But just out of curiosity, have you ever encountered a situation where it instantiated an extra adder/subtractor in a case as the above. That being two add/subtract operations, 3 operands and 2 of those operands are constants in the form of parameters.

Then again, maybe in combination with borderline "do not optimize this module" options that you need for something else, I can sortof see it happening...

Anyways, certainly cannot hurt. Hell, I would have gone a step further anyways. As in introduce a new named parameter that takes the function of (HR-HF). That way you only have one constant parameter in the actual operation.

That, and you could do some parameter checking in an initial block... as in assert that you provide valid values for your parameters.
 

mrfibble said:
But just out of curiosity, have you ever encountered a situation where it instantiated an extra adder/subtractor in a case as the above. That being two add/subtract operations, 3 operands and 2 of those operands are constants in the form of parameters.
I saw it happen before with a M/N NCO I designed. There were multiple computations done to perform the conversion from user friendly values to ones the NCO could use. I ended up with a daisy chained addition that was exceeding the clock period. Adding the parenthesis around the calculation of the constant fixed it. I think it depends on how smart the synthesis tool is/isn't. I prefer to err on the side of "do it this way, because I know what I want".
 

Sneaky. Were they all parameter based, or was it a mix of `define and params? Then again, that should not matter either if they are all constants that can be resolved compile time. But mixing 2 kinds of constant + some laziness on behalf of the one writing the parser, and you've got the situation you just had. Same could still go for two actual parameters, but that would be really sloppy work on the parser.
 

The constants were all localparam. It was also done using XST.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top