Hobbyist: FPGA between MCU and external memory?

[nctnico]

No logic, but they do need more voltages to drive the panel, so a boost converter has to be added to make these.

VCOM=3.0V..3.5V, DVDD=3.0V..3.6V, AVDD=9.4V..9.8V, VGH=17V..19V, VGL=-6.6V..-5.4V, so you're referring to the 9.6VDC AVDD, 18VDC VGH, and -6VDC VGL rails.  Yes, the larger panels need these because the controller chip on the FPC cannot do these internally, unlike for the smaller TFTs.  I forgot about that because I don't normally use these larger ones.  As I understand it, these rails don't draw much current at all, and is generated using charge pumps for the smaller TFTs.

Very nice if you come across such a panel. NOT!  I used an LT1947 in one of my designs. This is a single chip solution to create all the necessary voltages. IIRC the datasheet / documentation is quite straighforward. For VCOM I used an opamp as a buffer for a resistor divider. Most of the rails don't draw much current indeed.

[Nominal Animal]

Which is how I think the term GRAM is being used.  Graphics RAM.

Not by me.  I use the term to describe its behaviour: fast writes expanding data to 18-bit RGB regardless of written data width, extremely slow reads.

Note that it is also kind-of dual-ported: the controller is constantly refreshing the TFT, and thus reading from this memory. The state of the refresh does not affect the write timings at all.

[RoGeorge]

To me, GRAM looks like a (probably) wrong translation from another language, or maybe some workplace/office specific slang (unless there is a motivation/explanation for why using GRAM instead of VRAM).  Most probably specific to that datasheet only, or to that manufacturer only.

Also in the "IEEE 100 - the authoritative dictionary of IEEE standards", there is no entry for GRAM, only for VRAM:

video RAM (VRAM)
- (A) A special type of RAM used to hold
and transfer an image onto a display device. See also: image
memory.
- (B) A dual-port semiconductor memory that is spe-
cially designed for raster display devices. Note: One port is
connected directly to the processor; the other to the display
device. (C) 610.10-1994

No matter why the LCD datasheet is using GRAM, it doesn't seem to be some new type of RAM I might need to know/study/learn about (that was one of the reasons I was asking, apart from the casual curiosity reaction of "WTF is GRAM?!  ").

Thanks for clarifications, and sorry for the offtopic question.

[SiliconWizard]

GRAM just stands for graphics RAM for all I know, if that matters. This is just how the internal video RAM buffer of a display controller is usually called, for display controllers that handle display refreshing on their own, as opposed to the more basic controllers which take RGB+Sync signals and need to be manually fed (this is still a controller, but obviously much simpler).

This RAM is in effect dual-port, although internally the controller may use single-port RAM and may interleave access to it. The pixel data you send it may be using various programmable formats (common usual suspects for TFT panels are RGB565 and RGB666 or RGB888) and the controller transforms the pixel format on the fly to the full pixel data required by the panel itself, often 18- to 24-bit (so 6 to 8 bpp). For monochrome OLED panels, the formats are usually either 1 bpp or 4 bpp. I've never run into a monochrome OLED panel that supported more than 16 grayscale, but such a beast may exist. The color ones vary.

[Nominal Animal]

I'm happy to use any name for the buffer memory on these controllers, I just want to avoid any confusion as to how it is used: that it is external to the MCU/FPGA, is internal to the controller IC on the display FPC, has very asymmetric write/read timings, and is constantly read by the controller to refresh the display without affecting the write timings or access.  It's what the Ilitek ILI9341 (320×240) and ILI9488 (480×320) datasheets use, so I didn't even bother to check any dictionary for the correct term.  Should I use VRAM for this in the future, or just "display module framebuffer" or "display module graphics RAM" or something else?

The display modules I use do export the TE pin which informs the external MCU/FPGA of a completed refresh allowing the external one to start writing the contents of a new frame without tearing, plus have a register which can be read –– at 150ns cycles or max. 6.7 MHz –– to obtain the scan line currently being updated.

Just to clarify, my favourite display is

• 2.8" 320×240 IPS, ER-TFT028A2-4
  50-pin 0.5mm pitch FPC, ILI9341 controller, max. 15 MHz writes (66ns), physical size 70mm×50mm, active area 57.6mm×43.2mm, 0.18mm×0.18mm square pixels, optional capacitive touch panel uses separate 6-pin FPC, and backlight is four white LEDs in parallel with common cathode connection having 3.2V–3.4V forward voltage at 70mA–80mA current

but

• 2.4" 320×240 IPS, ER-TFT024IPS-3
  50-pin 0.5mm pitch FPC, ST7789 controller, max. 15 MHz writes (66ns), physical size 60mm×43mm, active area 48.96mm×36.72mm, 0.153mm×0.153mm square pixels, backlight is four white LEDs in parallel with common anode having 3.2V–3.4V forward voltage at 70mA–80mA current
   
• 3.5" 480×320 IPS, ER-TFT035IPS-6
  50-pin 0.5mm pitch FPC, ILI9488 controller, max. 33 MHz writes (30ns), physical size 83mm×55mm (85mm×57mm with optional capacitive touch panel in the same FPC), active area 73.44mm×48.96mm, 0.153mm×0.153mm square pixels, and backlight is six white LEDs in parallel with common anode for all, two common cathodes for each group of three LEDs, having 3.0V–3.2V forward voltage at 110mA–120mA current

all have a compatible 50-pin FPC and very similar controllers too.  Then there are

• 3.2" 320×240 IPS, ER-TFT032IPS-3.2
  40-pin 0.5mm pitch FPC, ST7789V2 controller, max. 15 MHz writes (66ns), physical size 78mm×55mm, active area 64.8mm×48.6mm, 0.2025mm×0.2025mm square pixels, optional capacitive touch, backlight is four white LEDs in parallel, 3.2V–3.4V forward voltage at 110mA–120mA current
   
• 3.92" 320×320 IPS, ER-TFT3.92-1
  40-pin 0.5mm pitch FPC, ST7796S controller, max. 15 MHz writes (66ns), physical size 84mm×84mm, active area 70mm×71mm, 0.21mm×0.22mm pixels (<5% from square), optional capacitive touch, backlight is two parallel chains of five white LEDs in series, forward voltage 15V–16V at 30mA–40mA current; no TE pin
   
• 4.3" 800×480 IPS, ER-TFT043-9
  40-pin 0.5mm pitch FPC, NT35510 controller, physical size 104mm×61mm, active area 93.6mm×56.16mm, 0.117mm×0.117mm square pixels, and backlight is two parallel chains of five series white LEDs with 15V–16V forward voltage at 30mA–40mA current; no TE pin

have 16-bit parallel 8080-style buses and can be used in the same fashion, although the pinouts vary.  All these have a controller with built-in memory for the contents, and can be used like I do (with video updates synchronized with the display, but only changes need to be sent).  While the last two do not have an output pin to indicate completion of display refresh, they do support command 0x45 that returns the scan line currently being refreshed, so one can do active polling to avoid tearing.

The annoying thing with these small panels is driving the backlight without flicker.  With series white LEDs there are efficient boost converters working in the MHz range.  With parallel LEDs, although I have 5V at sufficient currents available, losses are converted to heat, and although 0.2W or so of heat isn't that much, it does need to be get rid of, and the enclosures I use are small (routers, switches, NAS boxes, et cetera).  An MCU/FPGA-programmable current efficient buck controller from 5V (to around 3V) with resistor-settable maximum current (80mA–120mA) operating at 300kHz - 2MHz would be nice.  I've already found out that all the displays I have have very well balanced backlight LEDs, so my thread from 2022 on backlighting was overly cautious: I've not needed to balance backlight LEDs ever.

[bson]

So because of all of this it is much much easier to use SRAM if you can. For graphics at reasonable resolutions the price of a few MB of SRAM is not that terrible, while saving you a lot of manhours in development.

Totally agree.  What sensible person is even thinking of using SDRAM (and cache!) for a few MB?  Drop in a 4MB 10ns SRAM and - done!  It might cost $20, but for a one-off project, who cares.  This is the kind of SRAM that would be used for cache anyway...