Why HDMI, and why on an FPGA?
HDMI is the default video interface of the consumer and professional world: displays, cameras, set-top sources, medical monitors, and test equipment all speak it. It is the interface professional AV runs on, in switchers, scalers, extenders, KVM, digital signage, conferencing systems, and live production, and the one broadcast equipment meets when it leaves the SDI chain. A product that captures, generates, or processes HDMI has to get more than pixels right. The link carries video, audio, and metadata together, with the sink advertising its capabilities through EDID and a control plane running alongside the pixels.
FPGAs fit HDMI equipment naturally. The link rates map onto FPGA serial I/O and gigabit transceivers, and once the stream is in the fabric it can be converted, processed, compressed, or analyzed in hardware. Pipelines that avoid frame buffering run at line rate with fixed, known latency.
What we deliver
HDMI capture and generation, 1.4 to 2.1
Receive and transmit on both HDMI link types: TMDS, up to the 18 Gbps of HDMI 2.0, which covers 4Kp60 at 8 bits per color, and FRL, the HDMI 2.1 signaling for the formats beyond that. The link mode follows the target format, not the version number, and HDMI 2.1 products still run TMDS for the formats it covers. The format also determines the implementation: lower TMDS rates run on the serial I/O many FPGAs already have, while full-rate 2.0 and 2.1 links use gigabit transceivers or an external HDMI PHY. We configure and bring up the link, use vendor HDMI subsystems where they fit, and build custom logic where they don’t.
The whole signal path, not just the RTL
HDMI is as much a board problem as a fabric problem. We design the path from the connector in: ESD protection, input equalization, output retimers and redrivers, level shifting for the 5 V DDC and hot-plug signals and the 3.3 V CEC bus, and the routing guidance the high-speed lanes need.
The control plane that makes the link work
Most HDMI bring-up pain lives outside the pixel path: EDID over DDC, hot-plug detect, SCDC where the link mode requires it, InfoFrames, and CEC where the product uses it. We design and debug that plane alongside the video, including the EDID content itself, so the link comes up in the modes the product actually supports.
Processing between input and output
Once the stream is in the fabric as AXI4-Stream video, the pipeline is open: color-space and format conversion, scaling, frame-rate handling, overlays and keying, plus audio extracted from or inserted into the stream as the product requires.
Bridging HDMI to everything else
Most projects connect HDMI to another world: HDMI capture into an edge AI inference pipeline, HDMI to SDI conversion for broadcast chains, HDMI-to-Ethernet streaming with compression like our mjpegZero encoder, HDMI-to-USB (UVC) capture, or a MIPI CSI-2 camera front end with an HDMI output. Most of these share the same structure: HDMI on one side, AXI4-Stream in the middle, the target interface on the other.
Verification & delivery
Delivery includes RTL verification, timing closure, board bring-up, and measurements on the target hardware, with documentation that lets your team own the design afterwards.
Why bard0
- Imaging and video is our core business. Our IP portfolio includes the FPGA ISP, the MIPI Aggregator, and the mjpegZero MJPEG encoder, so the pipeline around the HDMI interface is designed by the same team.
- Multi-vendor experience. We work with AMD/Xilinx, Intel/Altera, Lattice, Microchip, and Efinix, and select the device against the target formats. Full-rate HDMI 2.1 narrows the options, and we know where the lines are.
Frequently asked questions
What HDMI versions and rates can an FPGA handle?
Both HDMI link types: TMDS links up to 18 Gbps, which covers 4Kp60 at 8 bits per color, and FRL signaling for the HDMI 2.1 formats beyond that. The link mode follows the target format, not the version number. The rate then determines the implementation: lower TMDS rates run on the serial I/O many FPGAs already have, while full-rate HDMI 2.0 and 2.1 need gigabit transceivers or an external HDMI PHY. Device and PHY selection against the target formats is part of the work.
Do you use vendor HDMI IP or custom RTL?
Whichever fits the project. Vendor HDMI subsystems are a solid base on the devices they support; custom logic makes sense where the vendor core doesn’t fit the device, the feature set, or the portability requirements. In both cases the link bring-up, clocking, and the video pipeline around the core are engineered for the specific product.
What about HDCP content protection?
HDCP is licensed technology: shipping it requires an HDCP adopter agreement and production keys on the product side. Where a project has that licensing in place, we integrate the vendor HDCP support into the HDMI subsystem; where it doesn’t, we design the pipeline so protected content paths are cleanly out of scope.
Can you bridge HDMI to MIPI, SDI, Ethernet, or USB?
Yes. Common shapes are HDMI capture into a processing or AI pipeline, HDMI-to-SDI conversion for broadcast chains, HDMI-to-Ethernet streaming with compression, HDMI-to-USB (UVC) capture devices, and MIPI CSI-2 camera front ends with an HDMI output. Most of these share the same structure on the FPGA: HDMI on one side, AXI4-Stream video in the middle, and the target interface on the other.
Do you handle EDID, CEC, and embedded audio?
Yes. Most HDMI products need the control plane as much as the pixel path: EDID over DDC, hot-plug detect, SCDC where the link mode requires it, InfoFrames, and CEC where the product uses it, plus audio extracted or inserted as the product requires. We design and bring up that plane alongside the video link.
Tell us the formats involved and what the system needs to do between the connectors. We’ll assess device options, architecture, implementation effort, and cost.