Driving an LVDS LCD

[BrianHG]

Just so we are clear, you can begin scaling with just adding a few numbers to your existing code.

[SiliconWizard]

So are you working on a display replacement for an old HP spectrum analyzer?

It's almost done but this is not related, the LVDS was just a learning exercise.
Take a look here for the CRT replacement:
https://www.eevblog.com/forum/projects/hp-8594e-replacing-the-green-crt-with-lcd/

I have worked on something similar for a Lecroy 9354AL scope. I've also put this project on hold so it's not quite finished, but I was able to get images directly from the display processor with colors from what originally had a monochrome CRT. (The display processor actually puts out color data, but the CRT and its controller is only monochrom - albeit with this nice amber tone.)

As this has an odd resolution of 810x696, it would also require scaling in order to get a full-size image on the 1024x768 LCD panel I chose.

BrianHG makes it sound like it's very simple stuff, but merely copying values to adjacent pixels - if that's what they suggest - will look horrible. It takes at least some bilinear interpolation to get something acceptable. Maybe this is what Brian suggested though, and it's true it's not that hard, but you still have to make this work at the pixel clock.

[BrianHG]

So are you working on a display replacement for an old HP spectrum analyzer?

It's almost done but this is not related, the LVDS was just a learning exercise.
Take a look here for the CRT replacement:
https://www.eevblog.com/forum/projects/hp-8594e-replacing-the-green-crt-with-lcd/

I have worked on something similar for a Lecroy 9354AL scope. I've also put this project on hold so it's not quite finished, but I was able to get images directly from the display processor with colors from what originally had a monochrome CRT. (The display processor actually puts out color data, but the CRT and its controller is only monochrom - albeit with this nice amber tone.)

As this has an odd resolution of 810x696, it would also require scaling in order to get a full-size image on the 1024x768 LCD panel I chose.

BrianHG makes it sound like it's very simple stuff, but merely copying values to adjacent pixels - if that's what they suggest - will look horrible. It takes at least some bilinear interpolation to get something acceptable. Maybe this is what Brian suggested though, and it's true it's not that hard, but you still have to make this work at the pixel clock.

1 step at a time...  First, beginner steps, a fractional variable X&Y scale.
Then bi-linear, then optionally bi-cubic comes next...

[Miti]

I have worked on something similar for a Lecroy 9354AL scope. I've also put this project on hold so it's not quite finished, but I was able to get images directly from the display processor with colors from what originally had a monochrome CRT. (The display processor actually puts out color data, but the CRT and its controller is only monochrom - albeit with this nice amber tone.)

As this has an odd resolution of 810x696, it would also require scaling in order to get a full-size image on the 1024x768 LCD panel I chose.

BrianHG makes it sound like it's very simple stuff, but merely copying values to adjacent pixels - if that's what they suggest - will look horrible. It takes at least some bilinear interpolation to get something acceptable. Maybe this is what Brian suggested though, and it's true it's not that hard, but you still have to make this work at the pixel clock.

For me it was much easier, the input image is 512 x 256 pixels with two brightness levels, the output is 1024 x 768. All I had to do was to display the same pixel twice on the horizontal and three times on the vertical and output that to a VGA output. It keeps the aspect ratio exactly as on the original CRT. I let the LCD controller do the interpolation.
I digitize the two levels video using LVDS inputs and with Brian's help, I recover the video clock from the horizontal sync using a very clever digital PLL scheme. The frame buffer is in the FPGA RAM. All very compact, you can see how simple the board is in one of the pictures in that thread.

[Miti]

And just because I can, a bit of picture-in-picture exercise. Unscaled, of course, because video scaling is way out of my league. 

No, it is not...
You just need to think things through.

Begin with input res and output res & what X&Y factor you wish.

Second hint, for the Y output, you will want access to 2 different/adjacent Y coordinates of video simultaneously, but, begin with a variable X scale all by itself.

Ok, so the input image is 512 x 256 pixels and my LVDS LCD is 800 x 480. I need to stretch the input to 640 x 480 to maintain the correct aspect ratio and, eventually, center it but that's easy.
So the X factor would be 640/512 = 1.25 and the Y factor is 480/256 = 1.875.

[BrianHG]

And just because I can, a bit of picture-in-picture exercise. Unscaled, of course, because video scaling is way out of my league. 

No, it is not...
You just need to think things through.

Begin with input res and output res & what X&Y factor you wish.

Second hint, for the Y output, you will want access to 2 different/adjacent Y coordinates of video simultaneously, but, begin with a variable X scale all by itself.

Ok, so the input image is 512 x 256 pixels and my LVDS LCD is 800 x 480. I need to stretch the input to 640 x 480 to maintain the correct aspect ratio and, eventually, center it but that's easy.
So the X factor would be 640/512 = 1.25 and the Y factor is 480/256 = 1.875.

Ok, this is a start.

Next, when generating the picture output, what does your current code look like?

Can you think of a stupid way you may variably stretch the output pixels of the X & Y axis by any arbitrary fractional amount just by adding an X & Y scale factor and moving around a number or register size?

(I can assure you, it should be so simple stupid that you may use your analog sampled POT input to variably stretch the image in real time...)

[BrianHG]

If it's taking you more than 5 minutes to figure it out and 1 minute to code, you are going about it wrong...

[Miti]

One way I can think of is to divide the LCD position by the scaling factor, round it to the nearest integer, and read from the buffer at that address.

The VGA Controller code is attached.

Code: [Select]

module VGA_Controller( // Host Side
iRed, // Red input from pattern generator or frame buffer
iGreen, // Green input from pattern generator or frame buffer
iBlue, // Blue input from pattern generator or frame buffer
oAddress, // Read address to the frame buffer
oCoord_X,
oCoord_Y,
// VGA Side
oVGA_R,
oVGA_G,
oVGA_B,
oDE,
oDebug1,
oDebug2,
//oVGA_H_SYNC,
//oVGA_V_SYNC,

// Control Signal
iCLK,
iRST_N
);

//`include "VGA_Param.h"
`include "Video_Param.h"

parameter H_Total = 1024;
parameter H_Active = 800;
parameter V_Total = 525;
parameter V_Active = 480;
parameter Video_H = 512;
parameter Video_V = 256;

// Host Side

//output reg [16:0] oAddress;
//output reg [10:0] oCoord_X;
//output reg [9:0] oCoord_Y;
output [16:0] oAddress;
output [10:0] oCoord_X;
output [9:0] oCoord_Y;

output oDebug1;
output oDebug2;

input [9:0] iRed;
input [9:0] iGreen;
input [9:0] iBlue;

// VGA Side
output [9:0] oVGA_R;
output [9:0] oVGA_G;
output [9:0] oVGA_B;
//output reg oVGA_H_SYNC;
//output reg oVGA_V_SYNC;

// Control Signal
input iCLK;
input iRST_N;

// Internal Registers and Wires
reg [10:0] H_Count;
reg [9:0] V_Count;
reg [10:0] Cur_Color_R;
reg [10:0] Cur_Color_G;
reg [10:0] Cur_Color_B;
//wire mCursor_EN;

output reg oDE;
reg oDE_Temp;

assign oVGA_R = (H_Count <= H_Active + 1'b1 && V_Count < V_Active) ? Cur_Color_R : 10'd0;
assign oVGA_G = (H_Count <= H_Active + 1'b1 && V_Count < V_Active) ? Cur_Color_G : 10'd0;
assign oVGA_B = (H_Count <= H_Active + 1'b1 && V_Count < V_Active) ? Cur_Color_B : 10'd0;


assign oCoord_X = (H_Count < H_Active && V_Count < V_Active) ? H_Count : 11'd1023;
assign oCoord_Y = (H_Count < H_Active && V_Count < V_Active) ? V_Count : 11'd824;
assign oAddress = (H_Count <= Video_H && V_Count <= Video_V) ? oCoord_Y * Video_H + oCoord_X: 17'd0;

assign oDebug1 = (H_Count == 0) ? 1'b1 : 1'b0;
assign oDebug2 = oDE;

// DE Output Delay
always@(posedge iCLK or negedge iRST_N)
begin
if(!iRST_N) // If Reset button is pressed
begin
oDE <= 1'b0; // Clear DE output at reset
end // if(!iRST_N)

else
begin
oDE <= oDE_Temp;
end
end




// Cursor Generator
always@(posedge iCLK or negedge iRST_N)
begin
if(!iRST_N)
begin
Cur_Color_R <= 11'd0;
Cur_Color_G <= 11'd0;
Cur_Color_B <= 11'd0;
end
else
begin
Cur_Color_R <= iRed;
Cur_Color_G <= iGreen;
Cur_Color_B <= iBlue;
end
end


// H Counter
always@(posedge iCLK or negedge iRST_N)
begin
if(!iRST_N) // If Reset button is pressed
begin
H_Count <= 11'd0; // Clear horizontal pixel counter at reset
oDE_Temp <= 1'b0; // Clear DE output at reset
end // if(!iRST_N)

else
begin

// H Counter
if( H_Count < H_Total) // Counter didn't reach the end of the line (visible + invisible)
H_Count <= H_Count + 1'b1; // Increment the horizontal pixel counter

else
H_Count <= 11'd0; // Reset the counter and start a new line

// H_Sync Generator
if( H_Count < H_Active && V_Count < V_Active) // Within the active window
oDE_Temp <= 1'b1; // Data Enable goes HI

else
oDE_Temp <= 1'b0; // Data Enable goes LO
end
end


// V Counter
always@(posedge iCLK or negedge iRST_N)
begin
if(!iRST_N) // If Reset button is pressed
begin
V_Count <= 10'd0; // Clear vertical line counter at reset
end

else
begin
// When H_Sync Re-start
if(H_Count == H_Total - 1'b1) // Increment or reset the line counter at the beginning of the line (Miti: H_Cont and V_Cont are not in sync)
begin

// V_Sync Counter
if( V_Count < V_Total ) // Counter didn't reach the end of frame (visible + FP + BP)
V_Count <= V_Count + 1'b1; // Increment the vertical line counter

else
V_Count <= 10'd0;

end
end
end


endmodule


[BrianHG]

There is nothing wrong with this code.  It does not need modifying.
Where is the code which places you sampled video bitmap on the screen.
The part which shows the ram.

How do you point the the pixel you want to show?

Where are those X&Y counters?

[Miti]

There is nothing wrong with this code.  It does not need modifying.
Where is the code which places you sampled video bitmap on the screen.
The part which shows the ram.

How do you point the the pixel you want to show?

Where are those X&Y counters?

oAddress is the read address of the dual port RAM frame buffer.

[BrianHG]

Ok, so:

Code: [Select]

assign oCoord_X = (H_Count < H_Active && V_Count < V_Active) ? H_Count : 11'd1023;
assign oCoord_Y = (H_Count < H_Active && V_Count < V_Active) ? V_Count : 11'd824;
assign oAddress = (H_Count <= Video_H && V_Count <= Video_V) ? oCoord_Y * Video_H + oCoord_X: 17'd0;

Step 1, get rid of the first 2 lines, make oCoord_X & oCoord_Y normal registers and stuff them into:

Code: [Select]

// H Counter
always@(posedge iCLK or negedge iRST_N)
begin
AND

Code: [Select]

// V Counter
always@(posedge iCLK or negedge iRST_N)
begin
So they literally run in parallel with H_Count and V_Count.
Make it like you are running the H&V counter code twice.

Next step, what would happen to your output image if you increase the bit width of oCoord_X and oCoord_Y by 1, then for this line, you do:

Code: [Select]

assign oAddress = (H_Count <= Video_H && V_Count <= Video_V) ? oCoord_Y[11:1] * Video_H + oCoord_X[10:1] : 17'd0;
Now, tell me what would happen if you increase the bits of oCoord_X&Y by 16 and change that line to:

Code: [Select]

assign oAddress = (H_Count <= Video_H && V_Count <= Video_V) ? oCoord_Y[26:16] * Video_H + oCoord_X[25:16] : 17'd0;

[BrianHG]

Ok, it would have looked nicer if your code was also not separated into H & V sections.

[Miti]

Next step, what would happen to your output image if you increase the bit width of oCoord_X and oCoord_Y by 1, then for this line, you do:

Code: [Select]

assign oAddress = (H_Count <= Video_H && V_Count <= Video_V) ? oCoord_Y[11:1] * Video_H + oCoord_X[10:1] : 17'd0;
Now, tell me what would happen if you increase the bits of oCoord_X&Y by 16 and change that line to:

Code: [Select]

assign oAddress = (H_Count <= Video_H && V_Count <= Video_V) ? oCoord_Y[26:16] * Video_H + oCoord_X[25:16] : 17'd0;

It would stretch the image by a factor of 2, the first line, and by 65536 the second line?
I think there's a mistake in the length of the registers, X is longer by 1.
So what you meant was:

Code: [Select]

assign oAddress = (H_Count <= Video_H && V_Count <= Video_V) ? oCoord_Y[10:1] * Video_H + oCoord_X[11:1] : 17'd0;
assign oAddress = (H_Count <= Video_H && V_Count <= Video_V) ? oCoord_Y[25:16] * Video_H + oCoord_X[26:16] : 17'd0;

Edit: I think I know where you're going. You stretch the image a lot, then you make a divider and squeeze it back by a number that would give you the desired fractional scale factor, without using float division.

[BrianHG]

Sorry, no divider needed...

Next step:

What would happen for the +1 bit setting if in the counter section, you changed the 'oCoord_X <= oCoord_X + 1' to a '+ 2' ?

What would happen  for the +16 bit setting if in the counter section, you changed the '+ 1' to a '+ 65535' ?

Again, for the +16 bits section, change the '+ 1' to '+ 32768' ?

What about any other number?

How about wiring the ADC of your volume control knob into the '+ 1' so that it goes from 0 -> 65535, what would happen then?

Nothing but simple addition...

[BrianHG]

Next step, what would happen to your output image if you increase the bit width of oCoord_X and oCoord_Y by 1, then for this line, you do:

Code: [Select]

assign oAddress = (H_Count <= Video_H && V_Count <= Video_V) ? oCoord_Y[11:1] * Video_H + oCoord_X[10:1] : 17'd0;
Now, tell me what would happen if you increase the bits of oCoord_X&Y by 16 and change that line to:

Code: [Select]

assign oAddress = (H_Count <= Video_H && V_Count <= Video_V) ? oCoord_Y[26:16] * Video_H + oCoord_X[25:16] : 17'd0;

It would stretch the image by a factor of 2, the first line, and by 65536 the second line?
I think there's a mistake in the length of the registers, X is longer by 1.
So what you meant was:

Code: [Select]

assign oAddress = (H_Count <= Video_H && V_Count <= Video_V) ? oCoord_Y[10:1] * Video_H + oCoord_X[11:1] : 17'd0;
assign oAddress = (H_Count <= Video_H && V_Count <= Video_V) ? oCoord_Y[25:16] * Video_H + oCoord_X[26:16] : 17'd0;


This is from your original code:

Code: [Select]

output [10:0] oCoord_X;
output [9:0] oCoord_Y;


Since you had 'oCoord_X' at [10:0], I just added 1 to both creating a left-shift by 1 bit.

[Miti]

Sorry, no divider needed...

Next step:

What would happen for the +1 bit setting if in the counter section, you changed the 'oCoord_X <= oCoord_X + 1' to a '+ 2' ?

What would happen  for the +16 bit setting if in the counter section, you changed the '+ 1' to a '+ 65535' ?

Again, for the +16 bits section, change the '+ 1' to '+ 32768' ?

What about any other number?

How about wiring the ADC of your volume control knob into the '+ 1' so that it goes from 0 -> 65535, what would happen then?

Nothing but simple addition...

This happens:



   Man, I envy smart people...

It doesn't look too bad even without interpolation.

[BrianHG]

You are doing fine.  I just have experience with fixed floating point & resizing graphics.

You can use different scale sizes for the X&Y to stretch fill the image on the LCD.

Now, bi-linear filtering is not that more complicated, but, it does require a bit of ingenuity.

(This is considered for thought and experimentation.  I'll offer further in a day or so if you wish, though, you might be able to solve the problem for yourself...)

Your 'oCoord_X/Y[25:16]' contains an integer location of which pixel you wish to draw on the output display.

And if you think it through, your 'oCoord_X/Y[15:0]' contains a fractional location in-between the current integer location and the next integer location of the pixel you wish to draw.  (You may consider only using oCoord_X/Y[15:8] for 255 sub-locations between the current integer pixel and the adjacent one.)

This means, when reading a pixel, you want to have simultaneous access to 4 pixels decoded as RGB color after your palette.  Pixels oCoord_X/Y, oCoord_X+1/Y, oCoord_X/Y+1, oCoord_X+1/Y+1.  The oCoord_X/Y[15:8] will be like a linear fader/selector multiplying how much of X/Y, X+1/Y, X/Y+1, X+1/Y+1 is blended together, with the sum result being your final pixel.

EG, everything (RGB) is 3x, this is not proper code, it is an example guide (the math was for 24 bit color, you can shrink everything from 8 bits to 4 bits for 12 bit accuracy):

Code: [Select]

assign x_fraction = oCoord_X[15:8];
assign y_fraction = oCoord_Y[15:8];

out_y0(RGB) <= ( (oCoord_X/Y[25:16]_(RGB) *  (255-x_fraction)) + (oCoord_X+1/Y[25:16]_(RGB) *  (x_fraction)) ) >> 8 ;
out_y1(RGB) <= ( (oCoord_X/Y+1[25:16]_(RGB) *  (255-x_fraction)) + (oCoord_X+1/Y+1[25:16]_(RGB) *  (x_fraction)) ) >> 8 ;

out_final(RGB) <= ( (out_y0(RGB) * (255-y_fraction)) + (out_y1(RGB) * (y_fraction)) ) >> 8 ;
The trick is how to get the 4 correct pixels at every pixel clock cycle.
There are a few solutions.

For the Y coordinate, one trick is to break up your display ram buffer into 2 dual port ram blocks.  1 block will hold all the even Y lines of the picture while the second will store all the odd Y line.  On the read side, with a little smart steering logic based on requested address and which data you read, you may now read an even and odd Y line simultaneously.  This solves simultaneous reading of Y and Y+1.  The same can be done for the X / or vertical lines.  This means 4 dual port rams, each with 1/2 the X size and 1/2 the Y size.

There are smarter ways to do the X without 4 rams since you know you are always reading from left to right.  Also, for the Y, you may also run the read side at 2X speed feeding the Y address and then the Y+1 address.

[BrianHG]

Sorry, no divider needed...

Next step:

What would happen for the +1 bit setting if in the counter section, you changed the 'oCoord_X <= oCoord_X + 1' to a '+ 2' ?

What would happen  for the +16 bit setting if in the counter section, you changed the '+ 1' to a '+ 65535' ?

Again, for the +16 bits section, change the '+ 1' to '+ 32768' ?

What about any other number?

How about wiring the ADC of your volume control knob into the '+ 1' so that it goes from 0 -> 65535, what would happen then?

Nothing but simple addition...

This happens:

(Attachment Link)

   Man, I envy smart people...

It doesn't look too bad even without interpolation.

In your LCD shot, it looks as if you only stretched the Y axis and not the X...

[Miti]

In your LCD shot, it looks as if you only stretched the Y axis and not the X...

The LCD module is 800x480, my image is stretched to 640x480. Look at the grid, it is square now.

[Miti]

Ok, I know I deviate from the subject but since I started the discussion here, I’ll continue a bit.
I figured out what was wrong with Xilinx ISE not starting. I looked at the shortcut that was created on the desktop, and rather than starting an exe file, it points to a bat file. I copied the command in the shortcut and I ran it in a command line and it tried to open python27, which wasn’t installed. Once I installed it and renamed it from pyton.exe to python27.exe, it started. Hurray!!!
However, it cannot find a license for ISE features, even though I installed one. 🤦‍♂️

Why does Xilinx ISE need Python 2.7 to run? Oy vey!

[SiliconWizard]

Why does Xilinx ISE need Python 2.7 to run? Oy vey!

ISE seems to use Python indeed. There are a few Python modules in the Xilinx\14.7\ISE_DS\ISE\bin\nt64 directory. Not sure what they are there for. But the required Python support should be installed by the ISE installer. Dunno what happened in your case.

[Miti]

A member of this forum asked me to post the code and here it is. It does what's in the picture attached.
You need to rename from _01.zip to .zip.001 and so on and unzip.

Cheers,
Miti

[Miti]

Second part.