I'm interested in developing a very high frame rate OLED display capable of displaying ~1000fps with a resolution of around 1200×800 or so. This obviously has some pretty severe bandwidth requirements, and will likely require the use of an FPGA to implement a custom controller as typical display controllers don't run faster than 60-120Hz. At the risk of really showing my ignorance, with a "raw" OLED display (no controller) should I be able to drive the display at these rates? I'm sure whatever display controller comes with the display will be unhelpful, so I'd be starting from example controller code for the FPGA.
Electronic – Implementing a very high frame rate (~1Khz) OLED display
displayhigh speedoled
Related Solutions
First of all, I do not know of any displays available that support what you want.
This article implies that OLED displays should be able to deliver refresh rates > 80Hz. It claims 1000 times current displays which would put it in the 60kHz range. That may be true for an individual pixel, but I think they're confusing the response time of a pixel with the ability to give a pixel a new value. The former is how fast the pixel gets to a new value, the latter is the refresh rate (i.e. how often you can refresh the whole display).
It does seem that OLEDs could do what you want, but I doubt there is a display that will allow you to select an arbitrary refresh rate.
The reason I doubt is that the way video works is that you have an image that is refreshed at a particular rate to produce the video. Electronically this is done by sending pixels out one at a time to the display at a well-defined pixel clock.
Example:
Assuming a resolution of 1920x1080 and a refresh rate of 60Hz, your pixel clock would be a minimum of 1920*1080*60 = 12.4416MHz. In practice, you clock out extra pixels at the end of each line (horizontal blanking) and after the last line (vertical blanking). This is done to allow for a more reasonable clock (12.4416MHz isn't an easy frequency to generate from standard oscillators). Blanking time is also used to send other data and/or allow the receiving end (a display in your case) to process the received data. To continue the 1080p60 example, the pixel rate for that resolution and frame rate is defined as 148.5MHz. This is a more "rounded" frequency and allows for 2200x1125 pixels to be clocked out at 60Hz. When transmitted over HDMI, the blanking periods are used to send audio and control data.
So you see that both the video source and the video receiver (in your case a graphics chip and a display) have to both know about the exact format of the data being sent in order to work together. This is why I doubt there are displays like you desire. The graphics chip manufacturer would have to support a highly variable pixel clock which basically means they'd have to put an FPGA on-board to clock out the data in addition to their graphics chip. The display controller manufacturer would have to do the same on their end. Though depending on the display the display controller manufacturer might be able to just use the input clock from the graphics card without knowing the exact timings (within the limits of the display and controller).
You could conceivably support what you want, but you'd basically be implementing a graphics card in an FPGA. You'd take whatever the original video was and then convert it to the frame rate you want inside the FPGA. You'd be limited in the maximum pixel clock that the display controller can use and you'd have to select a few discrete frame rates (i.e. maybe 80, 85, 90, 95, etc) to output based on how much logic and how many PLLs your FPGA has. So you couldn't vary the frame rate in real time, but you could support more frame rates than a typical display driver supports.
Almost none of the prefab display modules I've seen on the market give a "user" any significant control over when information is actually displayed; many don't even let the user know when information will be displayed. The normal design pattern is for the module to accept data from the user into a buffer at times of the user's choosing, and then display the contents of that buffer at a time of the module's choosing. In cases where both the module and the eyes of anyone looking at it are stationary, having the time between when data is fed to the module and when it appears on screen arbitrarily vary between 0-15ms won't be a problem. If the module or the user's eyes are moving, however, the scanning behavior may become quite relevant.
For a 64x64 module, I would expect that it should probably be possible to supply the module with a new frame's worth of data on every scan cycle; if you're interested in controlling or at least knowing exactly when things are displayed, however, you'll have to check the data sheets of any specific modules you're considering to see what sort of control you can get. I wouldn't say that modules "typically" give any control, but some might let you program a frame rate or scanning pattern that would fit your needs even if you have to do some trickery to achieve such behavior (e.g. if the module scans one line every 100us, allows a programmable number of scan lines, and counts scan lines with a down-counter that's reloaded when it hits zero, and if one wanted a frame rate of exactly 125Hz, one could have the scan-line count register programmed with a value of 81 for 7.809ms and a value of 80 for 101us. The timing on the module would then drift until the start of frame coincided with the time when the screen was programmed for 80 lines.
Best Answer
A suggested approach to updating a 1200 x 800 pixel display at 1000 fps, would be to break up the display into a matrix of lower resolution OLED panels, ideally OLEDs with so-called "edge-to-edge active display". For instance, a 2 x 2 matrix of 640 x 480 OLED panels would provide a bit more than the specified resolution. However, these sub- panels selected must themselves allow refresh rates of 1000 frames per second, as well.
Each panel needs to be controlled through a separate signal channel. Depending on the capability versus price of the FPGA chosen, a single FPGA may be used to drive one or more of the panels.
This is similar to the way ultra-large displays are created for stage performance backdrops, for instance, using a matrix of standard large screen HD LCD or LED televisions. Each TV is typically driven off a separate video source. Allowance is made for bezel distances, cropping off an appropriate amount of the image at each edge of each TV.
As the application itself is not described in the question, an assumption is that a somewhat contiguous display is required. Unfortunately, using separate panels will not provide contiguous display area, as the connections to each OLED panel in the matrix have to come out somewhere. Thus, bezel-like gaps will need to exist between panels, similar to the matrix-of-TVs approach mentioned.
If this is unacceptable, the alternative is to select an OLED panel of the desired resolution, that brings out individual signal rows and columns to a connector and allows these to be driven in definable banks. Typical OLED panels with Chip-on-Glass (COG) controllers will not work this way, raw OLED panels will need to be sourced.
Individual banks of OLED rows / columns would then be controlled via separate channels and conceivably separate controllers, to achieve the desired end-result display.