An Open Source HDMI Implementation For FPGAs

With some clever hacks and fast IO work, it’s possible to get your average garden-variety microcontroller to output some form of video. Old analog standards like composite and VGA are just slow enough that it’s possible to bitbash one’s way to success. If you’re serious about video work, however, you’ll want something more capable. For those use cases, [purisame]’s got what you need – an open source HDMI implementation for FPGAs.

Unlike other free and open source projects in this space, [purisame] has eschewed simply outputting compatible DVI signals on the port. This implementation is pure HDMI 1.4b, enabling the extended capabilities this brings, like combined video and audio streams. Thus far, it’s been tested on Xilinx and Altera platforms, though it may be compatible with Lattice, too.

In addition to the code, [purisame] breaks down options for those looking at going into production with an HDMI device. Licencing the technology for sale can be a fraught area, so a lawyer is recommended if you’re heading to market. Oh, and funnily enough, if your really do want to do HDMI on an Arduino, there’s a shield for that, too. Natch!

33 thoughts on “An Open Source HDMI Implementation For FPGAs

  1. “Licencing the technology for sale can be a fraught area, so a lawyer is recommended if you’re heading to market.”

    Always have a lawyer on your shoulder while coding.

    This is what the current patent system requires for software developers.

    I thought we had freedom of expression.

      1. Just use pin headers for everything. If you keep the HDMI or USB data pairs close together it should work fine. I think Car charching connectors are in the same boat: the (or at least some) standards are open, but the connectors not.

  2. I have no idea why the industry insists on sticking to royalty ridden proprietary standards while superior free standards exist

    DisplayPort is much better than HDMI, but I have never seen it in real life.

    1. You won’t see DisplayPort at least for your HaD projects:
      – the serial data rate is too high for your low end easy to use FPGA

      HDMI for industrial use license cost:
      The royalty fee structure is the same for all volumes. The following variable per-unit royalty is device-based and not dependent on number of ports, chips or connectors:
      US$0.15 for each end-user licensed product.
      US$0.05 – If the HDMI logo is used on the product and promotional material, the per-unit fee drops from US$0.15 to US$0.05. Use of HDMI logo requires compliance testing.
      US$0.04 – If HDCP is implemented and HDMI logo is used, the per-unit fee drops further from US$0.05 to US$0.04.

      1. Only a couple? I thought it peaked around 2012, 2013… there were a lot of Radeon HD 3450 low profile cards around with it on for cheap that got into a lot of SFF desktops from HP and Dell.

    2. Because its a question of whats actually being used in the real world. I work in A/V and HDMI is almost universally used, carries video and audio and does not cause interoperability issues on the whole. Yes, there are licensing fees, but as pointed out this is only a few cents per interface. We did support DP once on our encoders, almost no one used them, so we removed support and reduced the cost of testing, documenting, and support calls.

    3. I have one display which have 3 DP ports and one HDMI. The other much older display have DP + DVI and no HDMI at all. My older laptop T510 is DP only. GPU on my workstation (MSI RX580) have 2 DP and 2 HDMI. Workstations and displays at place where I work are DP only.

      So for a long time I used to think that DPs are everywhere and are a very much used standard and a successor to HDMI. Then I spoke with a friend once and was surprised to learn that there is another world where there is just HDMI and VGA and most people in that world never have seen DP and some haven’t even heard about it :D

      1. DisplayPort standard is/was sometimes ahead of HDMI, so if you’ve got an older monitor that exceeds 1080p 60hz, you might find out that the higher spec is only supported on DisplayPort. I don’t own any DP monitors, but I do have some active converters to HDMI.

      2. Seeing as USB-C is DisplayPort, I think there’s a good chance it will stay around in this new incarnation for a good while. For instance, the Nintendo Switch has USB-C video out with an adapter for HDMI.

        1. >USB-C is DisplayPort

          it just muxes DP into USB3 data lines (ANX7440 TI part for example).

          I was hoping that in 2020 we would have a packet mode video transfer. Sync at whatever arbitrary link speed, send whole screen worth of data all at once at max speed, put connection to sleep and wait for retrace, let the display take care of the retrace timings. Instead DP works just like HDMI just like DVI just like VGA – it syncs at the video dot clock and directly drives display timings :/ Even Freesync/g-sync work this way despite displays having own memory and re-timing circuity.

          1. @pelrun
            DisplayPort is packetized, but Isochronous and directly driving display timings. What good is packetized transfer mode, when the space between packets is stuffed with garbage and only opportunity for other data is during the Blanking period (BS-BE)? :/ You cant even send one whole video line in one go, instead you are supposed to divide it evenly into TUs and send isochronous ly.

    4. I have a display port on my LT and have to use an HDMI adapter to connect to my large monitor. The industry probably sticks with proprietary standards because most people haven’t a clue what to do

  3. Personally, I’m just waiting for the new Gameduino 3X Dazzler! It’s basically the excellent Gameduino 3 minus a display but adding on HDMI. Yes please. :)

  4. I get the desire to save component count and implement HDMI directly in fabric. But at some point the challenges of one solution should be compared to another. There are numerous HDMI transmitter and receivers that take 24-bit parallel video in/out. You only have to deal with the native pixel clock in those cases and not 10x TMDS or 5x TMDS/DDR I/O. And you can program all the info frames over I2C from a soft core and the chips does it for you. Even comes with a pre-paid license baked into the chip’s price. That is one reason why they are not cheap – but they are not really expensive either compared to FPGA prices.

  5. There really isn’t anything they can sue you over for implementing basic HDMI at this point as the spec is at least 18 years old (and probably patents were taken out during development) which would put the original implementation in the public domain since all the patents have expired. You’d have to make sure you only implemented HDMI as patented pre 2000 right now…but in a couple years any HDMI use case you could image for FPGAs should be good to go.

    You might not be able to call it HDMI for trademark reasons but you can implement it.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.