Verilog RGB panel driver - Page 1
Forum section: electronics / general

author: davorin
author_rank: Unknown
timestamp: April 29, 2018, 10:36:48 am
content: 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:module rgb_matrix (inputwireclk_12,outputreg[1:0]red,outputreg[1:0]green,outputreg[1:0]blue,outputreg[4:0]row,outputregblank,outputreglatch,outputregstart,outputwiresclk);localparam WAIT = 0,LOAD = 1,BLANK = 2,LATCH1 = 3,LATCH2 = 4,UNBLANK = 5;reg[5:0]column;regclock_enable;reg[7:0]delay;reg[2:0]state;wire[11:0]addr;wire[23:0]data;wire[23:0]data_bottom;wireclock;wirerst_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)beginif (rst_n == 1'b0)beginrow <= 5'b00000;column <= 6'b000000;delay <= 8'b00000000;blank <= 1'b0;clock_enable <= 1'b0;latch <= 1'b0;start <= 1'b0;state <= WAIT;endelsebegincase (state)WAIT:beginstate <= LOAD;blank <= 1'b0;red <= 2'b00;green <= 2'b00;blue <= 2'b00;endLOAD:beginif(row == 0)beginstart <= 1'b1;endelsebeginstart <= 1'b0;endif(column == 63)beginstate <= BLANK;endclock_enable <= 1'b1;red <= data;green <= data;blue <= data;red <= data_bottom;green <= data_bottom;blue <= data_bottom;column <= column + 1;endBLANK:beginblank <= 1'b1;clock_enable <= 1'b0;state <= LATCH1;endLATCH1:beginlatch <= 1'b1;state <= LATCH2;endLATCH2:beginlatch <= 1'b0;state <= UNBLANK;endUNBLANK:beginblank <= 1'b0;if(delay == 15)begindelay <= 0;row <= row + 1;state <= WAIT;endelsebegindelay <= delay + 1;endendendcaseendendendmoduleI 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;

author: @rt
author_rank: Super Contributor
timestamp: April 29, 2018, 01:41:22 pm
content: 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?

author: @rt
author_rank: Super Contributor
timestamp: April 29, 2018, 03:47:24 pm
content: 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.

author: davorin
author_rank: Unknown
timestamp: April 30, 2018, 03:29:10 pm
content: 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;

author: @rt
author_rank: Super Contributor
timestamp: April 30, 2018, 03:57:08 pm
content: 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 lineIt 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?