Categories

[SpiROSE] FPGA and driver inner working

FPGA inner working

This week we have chosen all the components, including the FPGA . It has sufficient memory to store a whole 3D image, which is nice to do avoid synchronization issue. The FPGA role is to receive the voxels sent by the SBC, cross the clock domains, and send the correct voxels and control signals to the drivers.

Driver inner working

The TLC5957 is specially built for high density panel, and his inner working is explained very well by this document . Loosely:

  • There are three buffers, the common shift register, and the first and second GS data latch. A control signal, named LAT, is used to latch data from a buffer to another. There are two input clocks, SLCK for writing data, and GCLK for displaying data.
  • The common shift register is 48-bit wide, and this is where we write a voxel from the outside, one bit at each SLCK rising edge. Then we latch the data into the first GS data shift register, which is 768-bit wide (16 LEDs, 48 bits per LED). When all data have been written into the first GS data latch, we latch it into the second one for display.
  • The trick is that GCLK needs to be input continuously and defined segment of 2^N cycles, the display latch must be done at the end of a segment. This produces an overhead if SCLK and GCLK have the same period (which is our case), because after 768 cycles you have written all the data but you must wait for the 1024th cycle.

16 bits per color causes the bandwidth to be too high, fortunately we have chosen the TLC5957 because it has a poker mode, allowing us to send from 9 to 16 bits per color. We will send 9 bits. However in poker mode we don’t write a voxel in the common shift register, instead we write the 9th bit of all the 16 Leds, then the 8th bit and so on. This means that we need the 16 voxels before writing anything in the driver, this would have to be handled by the fifo.

Therefore in poker mode, we send 432 bits and then wait for the 512th cycle of GCLK, but wait this change the bandwidth calculation of last week ! Now the bandwidth is 31.46 MHz, which is still under the 33 MHz of the driver, we’re saved.

A word about continuous integration

Modelsim and Quartus being proprietary softwares, we can’t use them on a docker image to test our RTL code. Thus we have chosen Verilator, which translates SystemVerilog to SystemC, allowing us to write our tests in the latter.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>