Logi-Bone driving 64x32 RGB LED Panels?

chrisoutwright

Having been able to drive one 32x32 Panel by using jpiat's files with the help of here on the valentfx forum, further development to extend the vhd files for 64x32 Panels is impeded by my low working knowledge on RTL and VHDL/Verilog.

The logic changes would have to be implemented in ISE Project Navigator Software Suite, using the logibone_mat.xise file together with other files in the directory on github.

I am wondering what changes have to be made to the vhd files to extend the implementation to 64x32 RGB Panels, or its chained versions. 
The file-links: "rgb_32_32_matrix_ctrl.vhd" and "wishbone_led_matrix_ctrl.vhd".
Logic-changes would likely occur in these by my knowledge for far.

Simply changing constants in rgb_32_32_matrix_ctrl like: 
constant LINE_SIZE : positive := 32*nb_panels ; constant RAM_SIZE : positive := LINE_SIZE*32 ; constant BOTTOM_ADDRESS_OFFSET : positive := LINE_SIZE * 16 ; 
Won't be enough to my reasoning as for the existence of a double-frame buffer etc.

I know that FPGAs are not really meant for hobbyists like me, but tutorials like the ones of Glen Akins appeared not too otherworldly to have RGB Panels driven, but sadly his one is out of date regarding the newer Logi-Bone revisions.

chrisoutwright

I hoped that I could adapt the coding for the bigger size panel, with the support here. I will have to commit the request to my local marketspace, to solve with remuneration.
Interest is sparse here for help. Seems a better way sadly at the moment.

chrisoutwright

Mhh, in the file rgb_32_32_matrix_ctrl.vhd i found following code I can't follow:

signal pixel_write_addr_line0, pixel_write_addr_line16 : std_logic_vector((nbit(32*32*nb_panels))-1 downto 0);

signal pixel_write_addr : std_logic_vector((nbit(32*32*nb_panels))-1 downto 0);

signal pixel_value_out_0, pixel_value_out_1 : std_logic_vector((bits_per_color*3)-1 downto 0);

signal write_mem0, write_mem1 : std_logic ;

begin

Isn't there  a 32 too much, as it is for a line? pixel_write_addr looks okay using this reasoning for all rows.

But looking at this snippet:

-- ram buffer instanciation

pixel_write_addr <= pixel_addr  ;

pixel_write_addr_line0 <= pixel_write_addr ;

--when pixel_write_addr < ((32*nb_panels)*16) else

--(others => '0');

pixel_write_addr_line16 <= pixel_write_addr - BOTTOM_ADDRESS_OFFSET ; 

--when pixel_write_addr >= (32*nb_panels)*16 else

--(others => '0'); -- only for simulation purpose ...

write_mem0  <=  write_pixel when pixel_write_addr < BOTTOM_ADDRESS_OFFSET else

'0' ;

I conclude that my reasoning what pixel_write_addr_line16 was meant by, was wrong and the original code correct. Any other ideas where the error is hidden for failing cascading of RGB Panels?

The component decleration seems to assign specific lengths for the signals (what about nb_panels, or line size?), they should be variable instead, right?

component dpram_NxN is

generic(SIZE : natural := 64 ; NBIT : natural := 8; ADDR_WIDTH : natural := 6);

port(

  clk : in std_logic; 

  we : in std_logic; 

 

  di : in std_logic_vector(NBIT-1 downto 0 ); 

a : in std_logic_vector((ADDR_WIDTH - 1) downto 0 );

  dpra : in std_logic_vector((ADDR_WIDTH - 1) downto 0 );

spo : out std_logic_vector(NBIT-1 downto 0 );

dpo : out std_logic_vector(NBIT-1 downto 0 )

); 

end component;