From a drawing to a picture on a monitor
How OSD Design Studio generates a video overlay, and what happened when the generated module was put in a real 720p path on an AC701.
Draft. Replace the bracketed notes with what actually happened, delete the rest of this line, then set draft: false in the frontmatter above and deploy.
A generated module is only worth as much as the evidence behind it. This is what the evidence looks like for OSD Design Studio: first a reference renderer and a bit-exact testbench, then an Artix-7 board driving a monitor.
Idea
In a project I was providing consultancy, One of the tasks was designing an OSD menu/readouts overlay in an imaging system. There were quite different texts, numbers, menus that needed to be overlayed onto the image that is being streamed. At that moment, I remembered the OSD designs I did for some old projects. I really had fun doing them. Now, I thought about how I can make it more enjoyable and at the same time efficient and quick. So, the idea of having an OSD design application became very appealing. And, I decided to give it a shot and wanted an application where I can design everything about OSD. I named it OSD Design Studio and completed the project. It is now very easy and quick to export your own OSD design studio with this. Getting help from AI also made this app possible in a short amount of time.
I am not gonna go into the details of OSD Design Studio. My aim here is to generate the Verilog module of our OSD design and run it in a FPGA.
Since we want to see how OSD design runs in a real device, we need a board that has some kind of video output to display it. That is how we will check it.
I checked my inventory and found that I have a FPGA development kit from Xilinx (AMD). I remember it has HDMI output. The development kit is an AC701 which has an Artix 7 200T in the center. Now it is time to dust it off and use it for something fun to do.
The OSD design
I would like to design a simple OSD menu and overlays. And I also would like to use buttons to control some of the outputs showed in OSD overlay.
We can start basic. We can have following elements as starter:
Elements:
- Cross-hair in the center. Down button will turn on/off cross-hair
- REC text in bottom-right of the screen. Up button will show/hide REC text as if the system can record.
- A fake temperature monitor output will be on the right-top.
- A static text will always be on the bottom-left like a company logo in a product.
- A hidden menu that is visible when the center button is pressed. It will have some fake controls such as brightness, contrast, invert and exit.
Block design
Phase 1 - Video pattern generation and streaming through HDMI
Before integrating the generated OSD block. First, we need a video stream that will get through HDMI. There are very beautiful ready to use video IPs in the AMD's inventory for this purpose.
Video Pipeline Video Timing Control Video Pattern Generator HDMI Output
Auxiliary Blocks
- HDMI init (to program AC7511)
- TPG init (to program video pattern generator)
- AXI VIP master (for verification)
Phase 2 - Integrating OSD block
Between Video output and HDMI output we can insert our OSD block.
The problem with on-screen displays
[Why menus and readouts over video keep being rebuilt by hand. What the usual approaches cost: a frame buffer, a soft CPU, a variable latency nobody wants to characterise.]
What the tool generates
You lay the overlay out over a sample frame, run the menu with on-screen buttons, and export a synthesizable module. Video goes in, the same video comes out with the overlay drawn on it, after a fixed number of clock cycles, with no frame buffer and no line buffer.
[The architecture in a paragraph: why fixed latency falls out of the design, what the bindings are, how the menu state machine is generated rather than written.]
Verification before hardware
The export includes a testbench whose golden frames come from the same renderer you designed with, so the hardware is compared against the picture you saw, pixel for pixel.
[What the testbench does per frame. How many test projects. What Verilator reported. The bugs this caught that a waveform would not have.]
The test bed
The board is a Xilinx AC701, an Artix-7 XC7A200T. The picture is generated on chip and pushed out through the board's ADV7511 transmitter. There is no DDR3 and no soft CPU: a small write-only I2C engine configures the transmitter at power-up, and an AXI4-Lite master programs the pattern generator after reset.
TPG -> AXI4-Stream to Video Out -> vid_reorder -> vid_to_gray -> vid_zoom
-> osd_osd -> vid_from_gray -> hdmi_out -> ADV7511| Module | Role |
|---|---|
hdmi_init | I2C master with the ADV7511 and PCA9548 setup table |
vid_to_gray, vid_from_gray | 24-bit RGB to the export's 8-bit gray bus and back |
vid_zoom | 2x, 4x and 8x nearest-neighbour zoom with a programmable centre |
osd | the OSD project and its generated module |
osd_bindings | drives the live values: target box, readout digits, modes, countdown |
button_router | five buttons, picture controls until the menu opens and navigation after |
[Why 720p60 and grayscale. What the zoom block is doing there. Why the bindings are animated rather than static.]
What broke
[The honest part, and the part people will read. Bring-up problems: the transmitter refusing to lock, timing closure, the order of the colour components, anything that differed between simulation and the board.]
What matched
[The payoff: the overlay on the monitor against the golden frame from the renderer. A photograph of the screen beside the rendered image is the strongest figure you can publish.]
What this says about generated RTL
[The conclusion worth making: a generator is trustworthy exactly as far as its verification reaches, and a reference model that draws the picture is a better oracle than a hand-written expectation.]
The tool is free to use in the browser at linebuffer.com/tools/osd-design-studio. The test bed is a linebuffer project; if you are putting an overlay into a video path and want it verified rather than eyeballed, get in touch.