4
« on: September 18, 2020, 10:32:40 AM »
We are thinking to evaluate the BT816 for use with an 800x480 TFT panel. However calculations show issues with the required memory bandwidth for ATSC compressed images. Please correct me if some of the assumptions are wrong.
The FTDI is clocked at 72 MHz. Nominal dot clock for the panel is 40 MHz, maximum 50 MHz, so using the PCLK divider we run at 36MHz. From timing specs the horizontal raster time is 862-1200 dots (1056 nominal), giving 2112…2400 master clocks to build a scanline using the display list.
Now, from the datasheet and the ATSC 2×2 tile organization it is strongly inferred that the texture line cache size is 64 bytes: 2×2 ATSC blocks are 64 bytes, every address in flash must be multiple of 64 bytes and so on.
The fastest way to access the SPI flash is in quad SPI XIP mode, which is what the firmware blob I assume does… in this mode from the chip select the memory needs: 6 cycles for the address, 2 for the mode/address extension, 4 dummy cycles for access latency and then it outputs the data. So for a 64 byte transfer you need 44 master clocks.
Since a scanline runs for 2112…2400 clock you can only have 48-50 tile transfers in a line (for a 2×2 ATSC block tile). At the minimum compression level (4×4 texels for block) a tile represents 8×8 texels, so to hypotetically fill a full size background image (800 pixels) you would need 100 tiles and that doesn't fit the timings.
This is of course a bit extreme (since it's kind of a worse case, we could use bigger blocks and so on) but if there are many bitmaps (i.e. many characters) on the scanline, the texture unit/rasterize can definitely starve. What happen in this case? The condition is not described in neither the datasheet nor in the programming manual.
- The bitmap is not drawn? (like the old game console with something like max 5 sprites for scanline)
- The display list stalls? like when the display list is too long and there is no time to render all the pixels
- Something else?
On a smaller 480×272 panels there is a lot more time (because there are a) less pixels and b) dot clock is usually about 8MHz) so probably it isn't a concern, and I will try to lower the dot clock to see if it's feasible; this panel is currently running on the FT810 without issues however it seems to be quite sensible to the clock (for example it hangs if I try to do a snapshot) so I'd like to know what would actually happen if the scanline timing are exceeded due to memory accesses.
Thanks in advance
Regards