FPGA board?

[uwuforever]

Is there plans to build FPGA support into this? I imagine it would be cool if there was an 'active-fpga' board, and we can pass a -fpga=1 option and free up a bunch of gpio pins, fix timing issues/increase refresh rate etc and have everything else work as is.

I found this: https://github.com/rjrouquette/rgb_matrix_udp but wasn't sure how to get it to work.

[davemaster]

fpga would be for refreshing rgb panels arrangement with video memory content from raspberry pi, but; what interface between rpi and fpga will be?, how much extern memory will be needed for the fpga refreshing board? Interest project....

[hzeller]

I have plans in doing so, but no ETA. There are people using FPGAs already, so this might be useful. I imagine the 'coding part', such as arrangement of pixels, multiplexing etc. in the base code, and the criticial path execution in the FPGA.

[uwuforever]

I imagined the Pi sending completed frame segments to the FPGA; the FPGA would maintain a frame buffer of the latest received frame segments & code necessary to output to hub75. The buffer would just be the size of 1 complete frame, and 2 threads: 1 to update the buffer and 1 to reload the panel.

Not sure if this is a dumb question but could we use a Teensy/Arduino Atmega chip as a temporary alternative? I'm assuming the main reason Teensy on Smartmatrix can only handle very small setups is due to the frame generation eating resources.

[davemaster]

Could be any one of them sending frambuffer from PI by spi I think, and receiver update the memory with current pi screen content to show in rgb led panels arrangement

El mar., 31 mar. 2020 a las 13:38, uwuforever (notifications@github.com) escribió:

I imagined the Pi sending completed frame segments to the FPGA; the FPGA would maintain a frame buffer of the latest received frame segments & code necessary to output to hub75.

Not sure if this is a dumb question but could we use a Teensy/Arduino Atmega chip as a temporary alternative? I'm assuming the main reason Teensy on Smartmatrix can only handle very small setups is due to the frame generation eating resources.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hzeller/rpi-rgb-led-matrix/issues/1038#issuecomment-606801270, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIGUXYAFXOKOLNXV3XJEVDRKI2DTANCNFSM4LXCQN6A .

-- David Elias Flores Escalante TeleTracking SAC

[uwuforever]

Alternatively is it potentially possible to use something like tlc5958? not the greatest with EE, but it seems like it should be possible to use that chip to offset a lot of processing work easily.

[uwuforever]

Re: fpga

Possible fpga board design could be a PCB with this module: https://www.xilinx.com/products/boards-and-kits/1-12hrhst.html soldered by its gpio pins, add level shifter ICs on the reverse side and 4 hub75 connectors on the edges. Power connected to the 5v from the panels.

RPi connected to FPGA via SPI/UART. (possible to have this wireless? such as: connecting the FPGA to an esp32, and using a smartphone/wireless Pi to send new frames)

Then for its software, this looks like a solid base: https://github.com/Sl-Alex/rgbmatrix-fpga-fm6126a

I'm guessing it would need updates to make use of the newer fpga version to support 24+ bit color, to support more than 1 chain, to support D&E address lines & for frame update protocol.

[davemaster]

Re: fpga

Possible fpga board design could be a PCB with this module: https://www.xilinx.com/products/boards-and-kits/1-12hrhst.html soldered by its gpio pins, add level shifter ICs on the reverse side and 4 hub75 connectors on the edges. Power connected to the 5v from the panels.

RPi connected to FPGA via SPI/UART. (possible to have this wireless? such as: connecting the FPGA to an esp32, and using a smartphone/wireless Pi to send new frames)

Then for its software, this looks like a solid base: https://github.com/Sl-Alex/rgbmatrix-fpga-fm6126a

I'm guessing it would need updates to make use of the newer fpga version to support 24+ bit color, to support more than 1 chain, to support D&E address lines & for frame update protocol.

Greetings,

Looks like a teensy that fpga board.

I have already a XC6SLX16 board with build in DDR3 interface, I will try with this one. Any advice, welcome. What interface must be used for transfer the framebuffer to FPGA ??? UART or SPI?

[uwuforever]

I'm not sure how significant the difference between your Spartan 6 and my proposed Spartan 7 is, but I remember reading due to block RAM size limitation Spartan 6 colors would be 18 bit while the block size on Spartan 7 is 36 bit. I'm assuming any other limitations are for similar reasons since Spartan 7 is fairly recent.

I think SPI is a better choice because it's faster?

[davemaster]

I'm not sure how significant the difference between your Spartan 6 and my proposed Spartan 7 is, but I remember reading due to block RAM size limitation Spartan 6 colors would be 18 bit while the block size on Spartan 7 is 36 bit. I'm assuming any other limitations are for similar reasons since Spartan 7 is fairly recent.

I think SPI is a better choice because it's faster?

totally agree about the power of Spartan-7 over 6, but it's all I have

first attemp: try spi connection between RPi 4 and xc6slx16... we'll see

[arahasya]

Hi can anyone explain to a noob like me the project mentioned in the first link

I went through the project. Is that micro controller acting as an FPGA here? How much will it improve the performance?

[greatballoflazers]

Honestly it makes more sense to use receiver cards for this. There are several people which have them working with Linux. This is far cheaper and more reliable way to do. Support is pretty good. However from what I gather there is still limited support for PWM panels without sender.

The biggest issue I see for the OP is the data link to the FPGA. A small 8 bit data bus could be used but this would have potentially the same timing issues. Working with that bus would cause cost issues as you would likely need external memory. Very expensive open source solution, which would be the only real reason to do it.

May make more sense putting effort towards support for PWM drivers. Since no one really has those working. (Except for ESP32 with ICN2053.)