Good Explanation. But note some errors on the schematic at 9:16. 1) There are 9 digital color signal from the FPGA, this will make it a 9-bit controller, but the author assumes an 8-bit controller. In that case, one of the colors (say blue) will have to be driven by 2 (as opposed to 3) signal lines. 2) If we are indeed building an 8-bit controller, then the total number of possible colors will be 256, not 512.
If the checker pattern and the color bar pattern are very dark, you can fix it by sending the color only during active region (w_Col_Count < ACTIVE_COLS && w_Row_Count < ACTIVE_ROWS). Otherwise send black. Just like during pattern 1,2,3.
(I have three of the Go Boards that I hack around with). In addition to 640x480 @ 60Hz, I have successfully written code to generate 800x600 @ 72Hz, and 1024x768 @ 70Hz. The pixel width becomes two and three time bigger so it looks strange, but higher resolutions are definitely possible even though you only have a 25MHz clock.
In the Sync Porch module, when we include the porches, why do we check for when the col/row_counts are greater than Total-Back_Porch? The -1 is for the total since we index from 0, that I get but what I’m getting from this is that we signal that the Sync signals are high (1’b1) when we’re between the back porch and end of the total width/length, but I know that can’t be it. Any help?
hi! got this one loaded on the go board, if i have a 1280x1024 display that (per online) has a pixel frequency of 108 mhz, does that mean i wont be able to drive the display?
Russell, very informative video. Thanks. Have a FPGA theory for you. You've defined TOTAL_COLS as 800, then in the code you use TOTAL_COLS-1. Does the build process (the compiler) replace TOTAL_COLS-1 with 799, or is the subtraction implemented in hardware? This is pretty simple example of this question but I can see other operations requiring hardware implementation of expressions. Does the build process have a report that explains how line by line is implemented. Kind of like looking at c compiler output of its generated assembly code. Thanks again.
Hi Craig. The synthesis tool will in fact replace TOTAL_COLS-1 with 799. It will try to find all constants and calculate their final values during the process. The tools are pretty smart about stuff like this.
Why would you need the Sync_To_Count module when the VGA_Sync_Pulses already keeps track (and outputs) the row/column counts? The Test_Pattern_Gen takes in the H & V sync, so why didn't it just also take in the row/col counts from VGA_Sync_Pulses? Maybe I'm missing something, this video did just sort of rush over the code.
The code is available on my website, check the description in the video for a link to the code. Sync_To_Count is a useful module, I use it in a few places. Just convenient if you only have the sync pulses but you need the counts.
No, you didn't read what I wrote. I'm saying that you already had the counts, so you didn't need the other module. On a side note, I have enjoyed your videos, and have watched nearly all of them. Thank you for making them. :) Please make more for anything you can think of, I have learned a lot.
I hadn't play around with the example on edaplayground.com, so I infer only from the video, but it seems Col_Count and Row_Count indeed might be obtained directly from VGA_Sync_Pulses.v module. I think Sync_To_Count.v module was implemented only to provide columns and rows count functionality in other projects where such counters aren't part of sync pulses' generator module.
Hey dude, thanks for the content, I've been building my own VGA driver and finding your video to be of massive help. I'm close to getting one working but not quite there yet. Getting an error when I plug my cable in "D-SUB Out Of Range" any ideas what this might be? is it super sensitive on timings as I'm working off the DILIGENT Pmod VGA Reference Manual and it appears the numbers are slightly different to yours.
@blakebennett5990 trying to cast my mind back, I think I got it fixed by fiddling with sync delay times, even so as to out of range. A logic analyser also helped with all that
Hi Russell, or someone, regarding the verilog code. Can you please tell me what is happening on the pattern vectors that are 3 bits wide. It looks like {VIDEO_WIDTH{1'b1}} is making all three bits 1?
Awesome I totally get that. After further looking at the checkerboard pattern, I see that you used the bit-wise XOR operator. I'm confused on doing an XOR compare of the column and row count would generate checkers. Would you be able to shed some light on this? Thanks!
I'm realizing that might work on monitors that are strictly 640x480. Any monitor with larger resolutions will show a pitch black screen. Is my conclusion correct?
It works on all monitors. The monitor itself is smart enough to change its resolution to match the input. Think about the fact that you can change your resolution in Windows.
@@Nandland Thanks for your reply. I had some time and managed to fix it. You are absolutely correct. I taught myself how to use PLL since I was doing a 1366 x 768 resolution with an 100 MHz board.
Good Explanation. But note some errors on the schematic at 9:16.
1) There are 9 digital color signal from the FPGA, this will make it a 9-bit controller, but the author assumes an 8-bit controller. In that case, one of the colors (say blue) will have to be driven by 2 (as opposed to 3) signal lines.
2) If we are indeed building an 8-bit controller, then the total number of possible colors will be 256, not 512.
I wish if you can help and make video about what you are talking the information about it is very hard and short, thanx
I wish if you can help and make video about what you are talking the information about it is very hard and short, thanx
I wish if you can help and make video about what you are talking the information about it is very hard and short, thanx
If the checker pattern and the color bar pattern are very dark, you can fix it by sending the color only during active region (w_Col_Count < ACTIVE_COLS && w_Row_Count < ACTIVE_ROWS). Otherwise send black. Just like during pattern 1,2,3.
(I have three of the Go Boards that I hack around with). In addition to 640x480 @ 60Hz, I have successfully written code to generate 800x600 @ 72Hz, and 1024x768 @ 70Hz. The pixel width becomes two and three time bigger so it looks strange, but higher resolutions are definitely possible even though you only have a 25MHz clock.
Does Nandland have any recommendations for learning about VGA protocol? Or any material he used for this? Thank you
@9:30 That is **9** bit color, not 8. 8 bits would only give you 256 colors!
In the Sync Porch module, when we include the porches, why do we check for when the col/row_counts are greater than Total-Back_Porch? The -1 is for the total since we index from 0, that I get but what I’m getting from this is that we signal that the Sync signals are high (1’b1) when we’re between the back porch and end of the total width/length, but I know that can’t be it.
Any help?
Have you done a perceptron?
14:00 all of them where tremendous fun!
hi! got this one loaded on the go board, if i have a 1280x1024 display that (per online) has a pixel frequency of 108 mhz, does that mean i wont be able to drive the display?
Why doesn't the monitor draw on the return why does it only draw from left to right?
Russell, very informative video. Thanks. Have a FPGA theory for you. You've defined TOTAL_COLS as 800, then in the code you use TOTAL_COLS-1. Does the build process (the compiler) replace TOTAL_COLS-1 with 799, or is the subtraction implemented in hardware? This is pretty simple example of this question but I can see other operations requiring hardware implementation of expressions. Does the build process have a report that explains how line by line is implemented. Kind of like looking at c compiler output of its generated assembly code. Thanks again.
Hi Craig. The synthesis tool will in fact replace TOTAL_COLS-1 with 799. It will try to find all constants and calculate their final values during the process. The tools are pretty smart about stuff like this.
Thanks for The project:), yesterday i made an hdmi interface Obu to fpgs but its dvi protocol being used plus some configuration data
What is the process of displaying characters on vga monitor using verilog?
Why would you need the Sync_To_Count module when the VGA_Sync_Pulses already keeps track (and outputs) the row/column counts? The Test_Pattern_Gen takes in the H & V sync, so why didn't it just also take in the row/col counts from VGA_Sync_Pulses?
Maybe I'm missing something, this video did just sort of rush over the code.
The code is available on my website, check the description in the video for a link to the code. Sync_To_Count is a useful module, I use it in a few places. Just convenient if you only have the sync pulses but you need the counts.
No, you didn't read what I wrote. I'm saying that you already had the counts, so you didn't need the other module.
On a side note, I have enjoyed your videos, and have watched nearly all of them. Thank you for making them. :) Please make more for anything you can think of, I have learned a lot.
I hadn't play around with the example on edaplayground.com, so I infer only from the video, but it seems Col_Count and Row_Count indeed might be obtained directly from VGA_Sync_Pulses.v module. I think Sync_To_Count.v module was implemented only to provide columns and rows count functionality in other projects where such counters aren't part of sync pulses' generator module.
Hey dude, thanks for the content, I've been building my own VGA driver and finding your video to be of massive help. I'm close to getting one working but not quite there yet. Getting an error when I plug my cable in "D-SUB Out Of Range" any ideas what this might be? is it super sensitive on timings as I'm working off the DILIGENT Pmod VGA Reference Manual and it appears the numbers are slightly different to yours.
I get the same issue idk how to fix it
@blakebennett5990 trying to cast my mind back, I think I got it fixed by fiddling with sync delay times, even so as to out of range. A logic analyser also helped with all that
Arent timings wrong? 480 + 10 + 12 + 33 = 535 not 525
Yes, It should be 2 for sync pulse, not 12. I updated the table on the website but not the video. Good find.
Hi Russell, or someone, regarding the verilog code. Can you please tell me what is happening on the pattern vectors that are 3 bits wide. It looks like {VIDEO_WIDTH{1'b1}} is making all three bits 1?
Yes that's doing replication in Verilog.
Awesome I totally get that. After further looking at the checkerboard pattern, I see that you used the bit-wise XOR operator. I'm confused on doing an XOR compare of the column and row count would generate checkers. Would you be able to shed some light on this? Thanks!
thanks for VGA test patterns top block diagram.
I'm realizing that might work on monitors that are strictly 640x480. Any monitor with larger resolutions will show a pitch black screen. Is my conclusion correct?
It works on all monitors. The monitor itself is smart enough to change its resolution to match the input. Think about the fact that you can change your resolution in Windows.
@@Nandland Thanks for your reply. I had some time and managed to fix it. You are absolutely correct. I taught myself how to use PLL since I was doing a 1366 x 768 resolution with an 100 MHz board.
Want more than a test pattern?
github.com/DendriteDigital/verilog/blob/master/P720.v