Verilog RGB panel driver

[davorin]

EHLO (o;

As the image conversion is now clear for loading images into FPGAs....now have a first output of a red/green/dot overlay image on the panel...
Seems that the first line is a copy of the last row of the top half (image is upside down).

I haven't found anywhere a timing specification how to exactly drive those Hub75 RGB panels....just some description...
The most important thing is that you have to drive OE/Blank high when you want to latch in a row onto the output drivers, as otherwise it won't do anything...

Code so far looks like:

Code: [Select]

module rgb_matrix (
input wire clk_12,
output reg[1:0] red,
output reg[1:0] green,
output reg[1:0] blue,
output reg[4:0] row,
output reg blank,
output reg latch,
output reg start,
output wire sclk
);

localparam WAIT = 0,
   LOAD = 1,
   BLANK = 2,
   LATCH1 = 3,
LATCH2 = 4,
   UNBLANK = 5;

reg [5:0] column;
reg clock_enable;
reg [7:0] delay;

reg [2:0] state;

wire [11:0] addr;
wire [23:0] data;
wire [23:0] data_bottom;
wire clock;
wire rst_n;

assign sclk = (clock_enable) ? !clock : 1'b0;
// assign sclk = !clock;

red red_memory (
.address({1'b0, row, column}),
.clock(!clock),
.q(data[23:16])
);

green green_memory (
.address({1'b0, row, column}),
.clock(!clock),
.q(data[15:8])
);

blue blue_memory (
.address({1'b0, row, column}),
.clock(!clock),
.q(data[7:0])
);

red_bottom red_memory_bottom (
.address({1'b1, row, column}),
.clock(!clock),
.q(data_bottom[23:16])
);

green_bottom green_memory_bottom (
.address({1'b1, row, column}),
.clock(!clock),
.q(data_bottom[15:8])
);

blue_bottom blue_memory_bottom (
.address({1'b1, row, column}),
.clock(!clock),
.q(data_bottom[7:0])
);

pll rgb_pll (
.inclk0(clk_12),
.locked(rst_n),
.c0(clock)
);


always @ (posedge clock)
begin
if (rst_n == 1'b0)
begin
row <= 5'b00000;
column <= 6'b000000;
delay <= 8'b00000000;
blank <= 1'b0;
clock_enable <= 1'b0;
latch <= 1'b0;
start <= 1'b0;
state <= WAIT;
end
else
begin
case (state)
WAIT:
begin
state <= LOAD;
blank <= 1'b0;
red <= 2'b00;
green <= 2'b00;
blue <= 2'b00;
end
LOAD:
begin
if(row == 0)
begin
start <= 1'b1;
end
else
begin
start <= 1'b0;
end
if(column == 63)
begin
state <= BLANK;
end
clock_enable <= 1'b1;
red[0] <= data[23];
green[0] <= data[15];
blue[0] <= data[7];
red[1] <= data_bottom[23];
green[1] <= data_bottom[15];
blue[1] <= data_bottom[7];
column <= column + 1;
end
BLANK:
begin
blank <= 1'b1;
clock_enable <= 1'b0;
state <= LATCH1;
end
LATCH1:
begin
latch <= 1'b1;
state <= LATCH2;
end
LATCH2:
begin
latch <= 1'b0;
state <= UNBLANK;
end
UNBLANK:
begin
blank <= 1'b0;
if(delay == 15)
begin
delay <= 0;
row <= row + 1;
state <= WAIT;
end
else
begin
delay <= delay + 1;
end
end
endcase
end
end

endmodule

I had to double the memories for top and bottom half....and currently only the MSB of a color is used...so no intermediate levels yet (o;

[@rt]

Is that not having the last row of the first draw latched when you switch to the second display,
when your last instruction to the first part of the display, should be to clear the last line instead?

[@rt]

It looks bitwise shifted horizontal as well so some of the blue has shifted into green.
That’s latch clock clear in the wrong order inside a loop that draws a line.
Hard to look at when the source image you posted is anti aliased.

[davorin]

Hmm..something is really fishy here (or in my code ;o)

In the attached diagram it shows clearly the switch from row 31 to row 0....row 31 contains all 3 colours...as I would expect for the line in the middle of the whole panel...
But in row 0 only a short pulse of red is present in the output...but the the whole line is lit as being copied from row 31....

So something must be wrong in the timing switching from row 31 to row 0....

Sadly I can't get modelsim altera edition to run on my linux box...and I am out of output pins on the MAX1000 board (o;

[@rt]

Nice bashing of binary, but I’m not pretending to read your code. That probably means it’s formal and correct.

You should be drawing a one pixel wide square border on the edge of the display in a single colour.
Is there some problem with rewriting whatever the device is? Because you could also slow everything down.
If slowing down will fry LEDs or one of their controllers, do the cycling multiple times on each line

It looks like for the dim line in the middle of the display, the line is latched where it should be, but moved to the next section of the display before being cleared.
Aside from what is going on horizontal.
I haven’t figured out the few red pixels in the right hand bottom corner of the screen yet. They could be just void of valid data.

Backing up in that post about what you know about the signal lines, are you sure? Is this written, or did something just work?
Have you any chips on the display, such as those switching high current, that need a small delay to accommodate propagation delay?


For the dimmest line near the middle of the display, where the first section ends, are you sure that line isn’t actually clear,
and what you see is artefact of the previous line that was drawn?