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

[ElEctric_EyE]

OK Finally got it working! Closeup of the upperleft portion of the monitor. This is ramping RGB from high to low. Noise issue is gone as well.

[ElEctric_EyE]

External control of the PROM select and FPGA /Program works as expected. 2 different patterns were programmed and selected successfully. Good news is PROM 1 & 2 designations on the board matches up with ISE. When ISE initiates the JTAG scan it shows the leftmost PROM (1), the middle PROM (2) and the FPGA on the right.

I think it's time to solder in the SyncRAM and try to come up with some simple HDL to try reading from it.

[BigDumbDinosaur]

ElEctric_EyE wrote:

OK Finally got it working! Closeup of the upperleft portion of the monitor. This is ramping RGB from high to low. Noise issue is gone as well.

Looks like designer vertical window blinds. Good job!

[BigEd]

Well done!

[ElEctric_EyE]

Guys, thanks! Very excited here. I soldered in the .65mm SyncRAM. Overdid it with the solder and used braid to get excess off. I like this technique! Will use it from now on. PVB powers up and runs still and no smoke...

Now I've been busy with some code and cannot use a testbench since there's no way to simulate the RAM. But I have made a successsful symbol with all the I/O's present, so the ISE tool must think it knows what I want to do. I've tried to approach it logically. Here goes:

Code: Select all

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

always @(posedge clk50)
		SRCLK <= ~SRCLK;		//pixel clk is SyncRAM clk
		
always @(posedge clk50)
	if ( hstart & vstart )	//reset address counter at top left of screen
		SRA <= 0;
		
always @(posedge clk50)
   if ( pclk )
      if ( hstart )
         countflag <= 1;	//countflag active in display area
      else if ( hblank )
         countflag <= 0;
		
always @(posedge clk50)
	if ( countflag )
		SRA <= SRA +1;			//increment RAM address counter
		
always @(posedge clk50)
	if ( pclk & countflag ) 
			SRDtemp <= SRD;	//latch incoming data

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

[Arlet]

ElEctric_EyE wrote:

Guys, thanks! Very excited here. I soldered in the .65mm SyncRAM. Overdid it with the solder and used braid to get excess off. I like this technique!

If you use too much solder, sometimes little blobs get stuck behind the pins. These can be nasty, as they are hard to see, and since they're only barely touching the pins, they don't always melt when you touch the pins with the iron. If that happens, you can fix it by adding some extra solder, and then use one of those hand held solder suckers to get it out. That's why I started to use the other technique I mentioned: load up a piece of braid, and use that as a brush to "paint" the solder on the pins. This avoids the problem in the first place.

In any case, try not to use really dry braid. If it works too well, it sometimes leaves too little on the pin. Instead, if it gets saturated, only cut off the end, but leave the half-saturated part. It's a matter of trial and error and experience to see how much you need.

[ElEctric_EyE]

Arlet wrote:

...In any case, try not to use really dry braid. If it works too well, it sometimes leaves too little on the pin. Instead, if it gets saturated, only cut off the end, but leave the half-saturated part. It's a matter of trial and error and experience to see how much you need.

Yeah, I used dry braid and it really took up the solder. I went back over the pins with the solder tip. We'll see if I was successful...

Last post with code passed syntax check and was able to make a symbol, but it did not synthesize. SRA was a reserved name, so had to change it, also SRCS was wrong value. I did not have the SyncRAM address outputs registered like I did with the databus outputs and got a multiple driver error. So I fixed it, and it passes sythesis. I tried it out. Getting totally random pixels all the time. Timing not right. But it's something!

Code: Select all

module SRAMif( output reg [20:0] SRAddr = 0,					//SyncRAM address bus
					output reg WEn = 1,			//SyncRAM R/W, always read
					output reg SRCLK = 0,			//SyncRAM clock			
					output reg SRCS = 1,			//SyncRAM chip select
					input [15:0] SRD,				//SyncRAM databus
					output reg [4:0] Red_data,		//
					output reg [5:0] Green_data,		//videoDAC databus, always write
					output reg [4:0] Blue_data,		//
					input clk50,				//50MHz main clock
					input pclk,					//25MHz pixel clock
					input hstart,
					input vstart,
					input hblank
					);
reg [20:0] SRAddrtemp;
reg [15:0] SRDtemp;
reg countflag;

always @(posedge clk50)
		SRCLK <= ~SRCLK;		//pixel clk is SyncRAM clk
		
always @(posedge clk50)
   if ( pclk )
      if ( hstart )
         countflag <= 1;	//countflag active in display area
      else if ( hblank )
         countflag <= 0;
		
always @(posedge clk50)
	if ( hstart & vstart )	//reset address counter at top left of screen
		SRAddrtemp <= 0;
	else if ( countflag )
		SRAddrtemp <= SRAddrtemp +1;			//increment RAM address counter
		
always @(posedge clk50)
	if ( pclk & countflag ) 
			SRDtemp <= SRD;	//latch incoming data

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

[Arlet]

Are the pixels stable, or are they flickering ?

[ElEctric_EyE]

Always changing, like my address counter is not being reset.

EDIT: I will go back to the simulator and see how your HVSync module works.

[Arlet]

Here's a verilog model of the RAM

[ElEctric_EyE]

Thanks for looking that up. I'm sure i will need that in time, but now I know my problem is that the RAM counter is not being reset. My logic for resetting it using hstart and vstart is wrong. I must determine how to tell it the last pixel has been displayed. Maybe I could generate this signal from within your vga.v HVSynv module?

[Arlet]

Here's a problem:

Code: Select all

   if ( hstart & vstart )   //reset address counter at top left of screen

The hstart and vstart pulses don't happen at the same time. Try resetting the address counter just based on vstart. The vstart signal comes early, so you can prepare the data path. At hstart, you start incrementing.

You'll still have artifacts because the code doesn't compensate for all the pipeline delays, but at least you should have a stable picture.

[ElEctric_EyE]

Arlet wrote:

...You'll still have artifacts because the code doesn't compensate for all the pipeline delays, but at least you should have a stable picture.

Arlet, thanks for your tip.
I'm aiming for a stable pixel generation (i.e. data from a fast read-only memory (in my initial test), non-FPGA Block Memory, but similar) and should be able to achieve it at such a low pixel clock (25 MHz, 40ns access time) without even looking at timing diag's. Hopefully this pass-thru synchronous RAM has a 6.5ns delay, not pipelined like the other versions of this Synchronous RAM.

[MichaelM]

EEyE:

This comment is not going to help, but I suggest that you use a single clock for the SRAM. Your comment on the following code says it, so I would recommed using pclk as the clock source for the SRAM.

Code: Select all

always @(posedge clk50)
      SRCLK <= ~SRCLK;      //pixel clk is SyncRAM clk

However, instead of using an assignment statement (and its potential path delays), I would suggest clocking the SRAM in the following manner:

Code: Select all

always @(posedge clk50)
      SRCLK <= ~pclk;      //pixel clk is SyncRAM clk

This will allow pclk == 1 to function as the enable for input FFs in the IOBs, which appears to be already included in your SRAM interface module.

====================================================

Thinking on this a bit more, I suggest that you need to look at the path delays in the IOB relative to the SRCLK and pclk. My understanding of the signal timing means that your use of the same phase of the clock (pclk and SRCLK should be in-phase) means that you are sampling the data in the middle of the cycle instead at the end of the cycle. I expect that the data may not be stable at that point, or if it is, you have not applied a NO_DELAY attribute on the input buffer of the FPGA. In either case, the data is clearly not stable, unless of course the SRAMs are not initialized.

The changes I suggested above should alleviate this timing issue.

[ElEctric_EyE]

That does help. pclk and SRCLK need to be the same. I will just rename 1 and adjust the ucf accordingly. But I think what's happening presently is that with a 2MB RAM and 640x480=311040 pixels, the data being written to the videoDACs is overlapping on the display, since my address counter does not have the correct logic to reset to 0 at the end of the last pixel. That's enough memory for 6.7 displays.

Hopefully will have time tonight to try yours and Arlet's suggestions. Thanks!