Why mod.. when you can make?

User Tools

Site Tools


Table of Contents

HDMI alpha notes

Quick post, so I ramble a bit :) So 2020 happened and we all got busy with a certain existential world crisis and many of my hobby projects just went on .. suddenly forgotten in changing priorities; mostly ended up 'wasting' my spare time instead of 'being useful' with it .. at least I turned nervous energy into cycling a lot, for fitness and give myself a focus. Anyway.

Some fine folks on Youtube have been posting comments <sorry, I didn't see them for awhile!> asking about some of the HDMI code. As I mentioned there, the better parts of the code are more closely intertwined with zikzak and in various states of <dis>repair. When you're rolling the whole machine from hardware to firmware and OS, and all the test cases for every single little bit (test main keyboard combinations, joystick, SD card, external clocks, video in various modes and colour test patterns, sound in various forms, the cart slot, flashing a cart, the OS debugger, the OS functions, etc etc..) .. you tend to have hundreds of tiny little snippets piling up. When building a video system, you're making a design on back of the envelope then implementing software drivers and some test code, then changing design and hardware spec and OS and test code and they all tend to tightly depend on each other … not like most sensible software systems where you have well defined contracts between components so each can be developed separately. As I'm just having fun learning I've been a little fast and loose with compartmentalization and leaky abstractions so things get tangled pretty quick - its not such a discrete 'heres a working simple video system' as 'heres some video stuff that doesn't do anything except when the other parts of the system bus are doing this, and that….'. Its a funny place in the zikzak where the entire machine could be done on a single chip but I'm very carefully going out of my way to try and make it more retro styled (cpu, gpu, IO all separate and not just done in the mcu or fpga.)

All that said, I've not packaged up any current code as 'current' is a shifting thing. Whats current when theres 30 directories of 'things' in motion? :)

But! Some of the earliest experiments are a little more standalone. I've got a moment so heres a few files .. If you need, I can try and make a 'hello world' Vivado project and zip it up but heres a first step in case it helps. Time is ever tight!

Credit: Much of this is swiped from fpga4fun - I stumbled across their site years ago and grabbed a few files, and found them extremely useful! Note that much of the HDMI spec is hidden behind paywalls in various working groups that only large companies are privvy to, so finding a few snippets here or there is all we hobbyists can really get.

I'm not sure if fpga4fun is clear for you - they know what they're doing more than I, but they're just hacking around having fun too - but his code works and is enough to bootstrap your own work. If you understand how analog VGA works it should be fairly easy to pick up how HDMI works .. despite being digital its not all that much different to VGA at a level of abstraction but in practice the timings are now super critical (hence good fodder for FPGA); doing VGA with sloppy timings generally works out well (get your vsync and hsync interupt calculations half right and everything else will render _something_) and you can pull it off on darned near any chip in some form or another, but HDMI requires rock solid timings or you just get 'nothing'. Also, those timings are high speed and LVDS so its much harder to inspect with budget lab equipment (your low end Rigol won't have the bandwidth to see anything, and DS requires a fancier scope to see at all)

That said, heres 3 files zipped up; they'll just show you the cribbed fpga4fun stuff, commented and mapped to my own board, in case it helps; this is very early alpha stuff, but again .. it works and renders a test pattern; I forget where in the lifcycle of dev this code is, but I think I had commented in there on how to do the test pattern and what the bits of code are for.

Not including the 'board constants' file since its extremely board specific (and no one has the board but me) but the key is to just set the appropriate pins to TMDS or LVDS etc depending on your IDE. set_property -dict { PACKAGE_PIN L17 IOSTANDARD TMDS_33 } [get_ports { JA1P }];

The actual HDMI files are here: zikzak-hdmi-experiment-alpha-vivado-stuff.zip

blinken - just sets up some clocks

HDMI_Emitter_TOP - this is the setup and top level for the HDMI module below; this takes the clocks in and multiplies up to the HDMI clock needed, maps board output GPIOs to the HDMI modules output signals, and blinks LEDs for fun

HDMI_video - this is the actual HDMI code, the only real piece you need (plus HDMI_Emitter to see the high speed clock generation); you could probably drop the two HDMI files into your own project and get them working pretty quick; if you only look at one file, this is the one!

- theres a test pattern generator in there a couple times I think, for you to fiddle with; ie: its essentially an 'if statement' block that says turn red or green or blue on when we're at this raster line or column, sort of thing; you can fiddle around to make basic images. –> in the later code, this is where its reading from a ram chip, or pulling off a bus; and I get goofy with pre-fetching off the bus into FPGA RAM and then rendering from that, and all kinds of experiments and messyness I never finalized, but you see the point

The rest of the first module just sets up the TMDS encoder sub module which does the 'unpublished HDMI magic' the working group doesn't want you to see.

Anyway, this is rambled enough and I need to get to work! Cheers folks!


Enter your comment. Wiki syntax is allowed:
/home/skeezix/public_html/zikzak.ca/zikzak.ca/dokuwiki/__data/pages/blog/hdmi_alpha_notes.txt · Last modified: 2020/09/11 14:44 by skeezix