Releases: hdl-util/hdmi
v1.2.1
There are breaking changes in this release from v1.1! They are called out with a
In order of recency:
- Screen position is now at the origin cx, cy == 0,0
⚠️ screen_start_x and screen_start_y no longer exist because they are 0- screen/frame width and height are still provided for knowing whether video is active
- Reset synchronous to clk_pixel is now supported
- The fast clock is now always DDR (5x as fast instead of 10x as fast)
⚠️ DDRIO parameter no longer exists⚠️ clk_pixel_x10 renamed to clk_pixel_x5- SDR users will need to double the divider in their PLL setups to halve the fast clock speed
- New video formats
- 4k30fps (95, 105)
- 1080p30fps (34)
- Rewritten TMDS serialization
⚠️ tmds_p and tmds_n is now just tmds⚠️ tmds_clk_p and tmds_clk_n is now just tmds_clk- Intel: use altlvds instead of handwritten serializer with altera_gpio_lite
- Xilinx: use OSERDESE2 instead of handwritten serializer
⚠️ Xilinx users! Ownership of OBUFDS has been moved outside of the hdmi module to the user side! See https://github.com/hdl-util/hdmi-demo/blob/master/top/sea/sea_top.sv#L50 for an example.- Why? Intel's altlvds automatically generates the tmds negative component and routes it to the correct pin, so unfortunately it can't be included in the hdmi module interface
- OSERDESE2 requires an initial reset and I've added one. If you want to reset it when the PLL/MMCM is ready you can do so via synchronous reset.
- other platforms: support (in theory) via ip-less tmds serializer
- Unrelated changes
- Migrate repo from Travis CI to GitHub Actions
- Minor fixes in testbenches
v1.2 released
PRE-RELEASE!
There are breaking changes in this release from v1.1! They are called out with a
- The fast clock is now always DDR (5x as fast instead of 10x as fast)
⚠️ DDRIO parameter no longer exists⚠️ clk_pixel_x10 renamed to clk_pixel_x5- SDR users will need to double the divider in their PLL setups to halve the fast clock speed
- New video formats
- 4k30fps (95, 105)
- 1080p30fps (34)
- Rewritten TMDS serialization
⚠️ tmds_p and tmds_n is now just tmds⚠️ tmds_clk_p and tmds_clk_n is now just tmds_clk- Intel: use altlvds instead of handwritten serializer with altera_gpio_lite
- Xilinx: use OSERDESE2 instead of handwritten serializer
⚠️ Xilinx users! Ownership of OBUFDS has been moved outside of the hdmi module to the user side! See https://github.com/hdl-util/hdmi-demo/blob/master/top/sea/sea_top.sv#L50 for an example.- Why? Intel's altlvds automatically generates the tmds negative component and routes it to the correct pin, so unfortunately it can't be included in the hdmi module interface
- Unrelated changes
- Migrate repo from Travis CI to GitHub Actions
- Minor fixes in testbenches
v1.1.1 released: DDR for Xilinx Platform
I've gotten around to testing a few things now that I have a Xilinx FPGA board and installed Vivado.
With this release:
- DDR should work now on Xilinx series 7 FPGAs 🙂
- If you are using HDLMake, I renamed the local OBUFDS to OBUFDS_quartus so it doesn't conflict with Xilinx's built-in SelectIO obufds
v1.1 Released
What's changed
Clock domain crossing improvements
To account for odd edge cases users might encounter, I've used clock domain crossing techniques where appropriate:
- Audio sample moved from audio clock to pixel clock via a sync chain
- Audio clock counter wrap sent over a sync chain from audio clock to pixel clock
- TMDS coding moved from pixel clock to pixel clock x10 via a sync chain
Audio fixes
There were some TVs audio wasn't working for, because:
- The audio CTS was 1 less than it should be
- The audio sample packets are sent as soon as they are received
- Instead, they are now buffered up until 4 are ready to be sent in a single burst
A big thanks goes to @LMN128 for the many hours spent debugging this with me.
Misc bugfixes/improvements
- Vsync front porch was short because I misread CEA861-D diagrams
- Shouldn't really matter, most HDMI sinks don't really rely on these timings from what I've read
- Info frame checksum was one-off, preventing them from being accepted by displays
- Gave types to all parameters to avoid confusion
- Source product description info frame
Discussion
- HDMI 2.0 implementation is a real possibility now that I have a copy of the spec. I don't have a device capable of 4k formats, so I'm holding off on it for now. Contact me if you are interested.
- Reading E-DDC is possible according to @LMN128, who has tested it with the i2c master
- There are a bunch of additional features HDMI has, like the audio return channel and 3D video formats
- I can't implement everything, but feel free to open an issue if you need one of these
- At the very least I can give you some tips on how to add it 😃
Official Release
This release is to signify that the HDMI implementation is ready for use.
While I will make every effort to ensure code on the master branch is stable, I recommend that you use these release tags if you want stable code.