Page 6 of 11
Re: HDL Implementation of Video Generator Test for 16-bit PV
Posted: Wed Oct 03, 2012 5:27 pm
by ElEctric_EyE
Arlet, thanks for checking the sim.
...The noise you're seeing could be from setup/hold time violations at the data inputs of the FPGA...
Could be, I don't see much noise on 1280x1024 using the CRT like I did with 1024x768. I tried looking at the 1280x1024 video through the flat panel display and noticed just a slight, barely noticeable, darker waves going up the middle of the screen. Like it might be power supply noise. Not noise on the edge of pixels. On the CRT with 1024x768, I did see some noise on the edge of certain colored pixels. More observation is needed. Maybe time to solder in the high frequency bypass caps...
I got 1024x768 & 1280x1024 working also, using 108MHz. I realized the problem with the value 1024 since it sits right on the boundary. Binary 1024 is 100_0000_0000, 11 bits. So one would assume to use [10:0] for the load registers, but this is not this case. I have to use [9:0] in order for the value 1024 to work.
Also, for 1280x1024 to display I had to increase the vertical front porch to 10 and decrease the vertical back porch to 29. A value of 1 for the VFP would not display.
Progress!
Re: HDL Implementation of Video Generator Test for 16-bit PV
Posted: Wed Oct 03, 2012 5:40 pm
by Arlet
I got 1024x768 & 1280x1024 working also, using 108MHz. I realized the problem with the value 1024 since it sits right on the boundary. Binary 1024 is 100_0000_0000, 11 bits. So one would assume to use [10:0] for the load registers, but this is not this case. I have to use [9:0] in order for the value 1024 to work.
[10:0] for the load registers should work too. It's okay to have more bits than you need. However, hcount should have 1 bit more than hload, and that bit should be tested for hcount_done.
I have this in my sims, and it works as expected:
Code: Select all
reg [11:0] hcount = 0; // down counter for horizontal state
reg [10:0] hload; // next load value
reg [1:0] hstate = FRONT; // horizontal state
wire hcount_done = hcount[11]; // done when count < 0
Also, for 1280x1024 to display I had to increase the vertical front porch to 10 and decrease the vertical back porch to 29. A value of 1 for the VFP would not display.
It should be enough to increase front porch to 2. Due to pipeline delays, that's the minimum value.
Re: HDL Implementation of Video Generator Test for 16-bit PV
Posted: Wed Oct 03, 2012 6:23 pm
by ElEctric_EyE
I will do more testing, I was sort of rushing, but I've made notes of the timings that have worked.
Had to do one last one today:320x200

Not really worth messing around with this low res without interlace capability. I have the 1280x1024 settings in one PROM and 320x200 in the other PROM. Takes about 2 seconds of black screen init time before switching...
Working on the camera settings for a closeup of 1280x1024. Initial try was washed up, I think because the camera is compressing the pic...
Time for a beer!

Re: HDL Implementation of Video Generator Test for 16-bit PV
Posted: Wed Oct 03, 2012 7:31 pm
by ElEctric_EyE
[10:0] for the load registers should work too. It's okay to have more bits than you need. However, hcount should have 1 bit more than hload, and that bit should be tested for hcount_done...
Now that I've all the timings down I went back and rechecked 1024x768. It works with:
Code: Select all
// horizontal counters and state
reg [10:0] hcount = 0; // down counter for horizontal state
reg [9:0] hload; // next load value
and
Code: Select all
// horizontal counters and state
reg [11:0] hcount = 0; // down counter for horizontal state
reg [10:0] hload; // next load value
with the appropriate hcount value (either 10 or 11) set in 'x':
Code: Select all
wire hcount_done = hcount[x]; // done when count < 0
Well, this just about brings a close to this thread, now that the initial goals stated in the header have been reached...
Although I would like to get my hands on the algorithm for coming up with the timings based on desired resolution.
Re: HDL Implementation of Video Generator Test for 16-bit PV
Posted: Wed Oct 03, 2012 7:40 pm
by Arlet
Although I would like to get my hands on the algorithm for coming up with the timings based on desired resolution.
Here's an explanation (section 10 and 11)
http://www.linuxdoc.org/HOWTO/XFree86-V ... index.html
Re: HDL Implementation of Video Generator Test for 16-bit PV
Posted: Wed Oct 03, 2012 9:02 pm
by ElEctric_EyE
Excellent reading there. I think it might be desirable to do a power-up test from the lowest resolution to the highest resolution to test a monitor's functionality, then pop back to 640x480x60Hz and ask the user if all resolutions were visible, each resolution having a number in the upper left. An interactive self-test.
This is the code I have for the 2 main modules that display 1280x1024. The first is a modified version of your code, running on one clock:
Code: Select all
/*
* vga.v
*
* VGA timing generator
*
* This module only generates the VGA sync signals and control signals
* for the actual video generator. Add a suitable video generator to
* create real outputs.
*
* +-------+ +-----------------+
* | vga.v | ----> | video generator | ----> RGB outputs
* +---+---+ +-----------------+
* |
* `-----------------------------------> Hsync/Vsync ouputs
*
* The hstart/vstart and blank signals are short enable pulses with a
* width equal to the pixel clock (pclk). They are intended to drive
* a state machine in the video generator. All outputs are fully
* registered. The 'hstart' pulse signals that next pclk will shift out
* the leftmost pixel of each line. The 'hblank' pulse signals that the
* next pclk must be blanked. Likewise, the 'vstart' and 'vblank' enables
* do the same thing for vertical blanking, but with less precise timing.
*
* So, use the vstart/vblank to update state machine, and use hstart/hblank
* for pixel timing.
*
* The hsync/vsync signals are delayed by 1 pclk period with
* respect to the vstart/hstart/blank signals. It is intended that
* the video generator will introduce a 1 pclk pipeline delay so that
* the signals will align again. If the video generator requires a
* larger delay, the hsync and vsync signals need to be delayed as well.
*
* The design has been optimised for speed (>200 MHz on Spartan-3
* with ISE 9.2 and one-hot FSM encoding selected).
*
* (C) Arlet Ottens, <arlet@c-scape.nl>
*/
module vga( input clk108,
output reg hsync, // horizontal sync
output reg vsync, // vertical sync
output reg hstart, // line start on next clock
output reg vstart, // field starts on next clock
output reg hblank = 1, // hblank on next clock
output reg vblank = 0 // vblank on next clock
);
// timing parameters
parameter
HFRONT = 53, // front porch (+right border)
HVIDEO = 1280, // active video area
HSYNC = 112, // hsync
HBACK = 243; // back porch (+left border)
parameter
VFRONT = 10, // front porch (+bottom border)
VVIDEO = 1024, // active vide area
VSYNC = 3, // vsync
VBACK = 29; // back porch (+top border)
// states (used for both H and V state machines)
parameter
VIDEO = 2'd0,
FRONT = 2'd1,
SYNC = 2'd2,
BACK = 2'd3;
// horizontal counters and state
reg [11:0] hcount = 0; // down counter for horizontal state
reg [10:0] hload; // next load value
reg [1:0] hstate = FRONT; // horizontal state
wire hcount_done = hcount[11]; // done when count < 0
// vertical counters and state
reg [10:0] vcount = 0; // down counter for vertical state
reg [9:0] vload; // next load value
reg [1:0] vstate = FRONT; // horizontal state
wire vcount_done = vcount[10]; // done when count < 0
// enable signal for V state machine
wire venable = (hstate == FRONT) & hcount_done;
// preload next timer value depending on state
// subtract 2 from timing value to compensate for pipeline delays
// This should be synthesized as a small LUT ROM, so it's quite
// efficient.
always @(posedge clk108)
hload <= (hstate == BACK) ? HVIDEO - 2:
(hstate == VIDEO) ? HFRONT - 2:
(hstate == FRONT) ? HSYNC - 2:
HBACK - 2;
// do the same for vertical
always @(posedge clk108)
vload <= (vstate == BACK) ? VVIDEO - 2:
(vstate == VIDEO) ? VFRONT - 2:
(vstate == FRONT) ? VSYNC - 2:
VBACK - 2;
// adjust down counter. Reload when it's done.
always @(posedge clk108)
if( hcount_done )
hcount <= { 1'b0, hload };
else
hcount <= hcount - 1;
// when down counter is done, go to next state
always @(posedge clk108)
if( hcount_done )
case( hstate )
VIDEO : hstate <= FRONT;
FRONT : hstate <= SYNC;
SYNC : hstate <= BACK;
BACK : hstate <= VIDEO;
endcase
// start of active line
always @(posedge clk108)
hstart <= (hstate == BACK) & hcount_done & ~vblank;
// vstart pulse to signal end of vertical blanking
always @(posedge clk108)
vstart <= (vstate == BACK) & venable & vcount_done;
// adjust down counter. Reload when it's done.
always @(posedge clk108)
if( venable ) begin
if( vcount_done )
vcount <= { 1'b0, vload };
else
vcount <= vcount - 1;
end
// when down counter is done, go to next state
always @(posedge clk108)
if( venable & vcount_done )
case( vstate )
VIDEO : vstate <= FRONT;
FRONT : vstate <= SYNC;
SYNC : vstate <= BACK;
BACK : vstate <= VIDEO;
endcase
// update registered outputs
always @(posedge clk108) begin
hsync <= hstate == SYNC;
vsync <= vstate == SYNC;
hblank <= (vstate == VIDEO) & (hstate == VIDEO) & hcount_done;
vblank <= vstate != VIDEO;
end
endmodule
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 clk108,
input hstart,
input vstart,
input hblank
);
reg [15:0] SRDtemp;
reg countflag;
always @(posedge clk108)
if ( hstart )
countflag <= 1; //countflag active in display area
else if ( hblank )
countflag <= 0;
always @(posedge clk108)
if ( vstart ) //reset address counter at top left of screen
SRAddr <= 0;
else if ( countflag )
SRAddr <= SRAddr + 1; //increment RAM address counter
always @(posedge clk108)
if ( 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
EDIT: I'm thinking my code could be further compacted (untested):
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 clk108,
input hstart,
input vstart,
input hblank
);
reg [15:0] SRDtemp;
reg countflag;
always @(posedge clk108)
if ( hstart )
countflag <= 1; //countflag active in display area
else if ( hblank )
countflag <= 0;
always @(posedge clk108)
if ( vstart ) //reset address counter at top left of screen
SRAddr <= 0;
else if ( countflag )
begin
SRAddr <= SRAddr + 1; //increment RAM address counter
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
EDIT (10/5/12): Tonight, I tested this last bit of code. I also compared the resource usage numbers in the ISE summary report (short of looking at the RTL schematic) after synthesis and it is the exact same as the previous bit of code... My goal when learning Verilog is to use the least amount of characters/typing as possible. I already skim across my 65Org16.b code and see alot I will change and update/test.
Re: HDL Implementation of Video Generator Test for 16-bit PV
Posted: Tue Oct 09, 2012 5:12 pm
by ElEctric_EyE
Can someone help me? I'm having a difficult time trying to generate successful timing signals using a 3.1MHz pixel clock. It's just an experiment to observe the lowest resolution possible. I was aiming for something like 160x100 or even lower. Need some good values for H&V sync pulses and porch values.
Re: HDL Implementation of Video Generator Test for 16-bit PV
Posted: Tue Oct 09, 2012 6:15 pm
by Arlet
These low resolutions are probably not supported by the monitor. If you really want low resolutions, you'd be better off using a line doubling implementation.
Re: HDL Implementation of Video Generator Test for 16-bit PV
Posted: Tue Oct 09, 2012 7:18 pm
by ElEctric_EyE
I was able to get down to 280x180@around 10MHz. For some reason, noise is easier to see at lower resolutions. Tomorrow I will start soldering in the bypass capacitors starting at the videoDAC and it's 3.3VReg, then moving onto the SyncRAM bypass cap's, and finally the S6's, and report back my findings.
So far I have 4 resolutions working:
320x200
640x480
1024x768
1280x1024
I will add 800x600. 256x256 might be interesting too.
I think it would be a good idea to post the settings for each resolution along with the aspect ratio, and how much RAM they use and how many frame buffers are possible with each.
Re: HDL Implementation of Video Generator Test for 16-bit PV
Posted: Tue Oct 09, 2012 7:58 pm
by Arlet
Tomorrow I will start soldering in the bypass capacitors starting at the videoDAC and it's 3.3VReg, then moving onto the SyncRAM bypass cap's, and finally the S6's, and report back my findings.
I'm curious, why do you wait so long to put the bypass caps in ? When I build a board, I always put them in right away. Seems to me that you only risk the chance you'll be chasing problems caused by the lack of bypass caps.
Re: HDL Implementation of Video Generator Test for 16-bit PV
Posted: Tue Oct 09, 2012 8:08 pm
by Arlet
Regarding the code rewrite: I always prefer to update different signals in different blocks, except when they are clearly related as a group (like the red/green/blue channels). Right now, it looks nice that SRAddr and Red_data are in the same block, but at some point in time, you'll discover there are situations where you want to update only one, and not the other, and then it becomes messy to keep them together.
For instance, in this case, you don't keep track of the latency of the SRAM. If you were to implement that properly, you'll find that you need to update the address earlier in the pipeline than the RGB channel data.
Re: HDL Implementation of Video Generator Test for 16-bit PV
Posted: Tue Oct 09, 2012 8:58 pm
by ElEctric_EyE
I'm curious, why do you wait so long to put the bypass caps in ?
I had once spent a
year troubleshooting an insidious noise problem. When I finally figured it out, I swore to never relive that experience again, and this was 20+yrs ago (I still remember after a 10yr respite from electronics). Now instead of allowing a noise issue play with me, I play with it... I am ultra-confident in my power supply layout and was curious how far it would go before noise became an issue. I suspect hi speed video would be more of an "ultimate test" of noise versus an oversampling audio circuit. (1) because it is higher speed, and (2) the eyes are more discerning than the ears. What I learn here, I will apply to future construction.
Regarding the code rewrite...at some point in time, you'll discover there are situations where you want to update only one, and not the other, and then it becomes messy to keep them together...
I discovered this today when I was thinking about how to implement a simple write module. A hardware clear screen would be especially useful. I started to realize early on that I would need separate Read and Write buses in 2 separate module, joined for bidirectional use at the top module. Now my top module is schematic only, which is what halted my progress. I am currently making a new project where the top_level is also Verilog.
...you don't keep track of the latency of the SRAM. If you were to implement that properly, you'll find that you need to update the address earlier in the pipeline than the RGB channel data.
Yes, I guess I do it haphazardly. I try to figure out a total timing and try do it within a window. I was never good at timing diag's. Pipelines is a subject matter I must and will learn with some help.
So today I just retreated abit and decided to try to finish off the v1.0h board.
Re: HDL Implementation of Video Generator Test for 16-bit PV
Posted: Tue Oct 09, 2012 9:31 pm
by BigEd
(I think the ears are more discerning...)
Re: HDL Implementation of Video Generator Test for 16-bit PV
Posted: Tue Oct 09, 2012 9:49 pm
by ElEctric_EyE
(I think the ears are more discerning...)
Don't invite Garth to another 'Golden ears" discussion!

J/K Garth!
I realized I should have said that I am nearsighted to the point of astigmatism. So, although legally blind without glasses, the vision is like a microscope at close range. Also I think I have excellent ears. I don't tolerate 192Kbps MP3s. I hear a difference in the cymbals. They sound compressed. I always back up my CDs with 320Kbps rips. Of course it depends on your speaker construction too, or who you bought them from...
It's interesting though BigEd, usually the human body makes up for losses, so if one can't see well, hearing takes up for the slack.
Re: HDL Implementation of Video Generator Test for 16-bit PV
Posted: Tue Oct 09, 2012 10:15 pm
by GARTHWILSON
Yeah, MP3 stinks. Oh wait a minute—that's the nose, not the ears.
golden-ears audio discussion starts in the middle of the post at viewtopic.php?f=4&t=2188&p=19749#p19749