Author Topic: HDMI / DVI encoder, with audio, smart Quartus PLL integration, in SystemVerilog.  (Read 3807 times)

0 Members and 1 Guest are viewing this topic.

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Hello everyone.  This HDMI / DVI encoder was originally implemented by Sameer Puri -> https://github.com/sameer.

I have made a bunch of tweaks/changes and created a smart parameter configurable PLL module for Quartus which allows one to trick Quartus's 'toggle rate limit' on the LVDS ports so that modes like 720p and above may be compiled for.  Tests have been performed on the https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/ thread and we can confirm that a CycloneIV-8 (Should be the same for CycloneII/III/IV/10/MAX10 variants) series FPGAs using the slower LVDS_E_3R IO ports can run up to 1080mbps, IE 1280x1024@60Hz / 1440x960@59.95Hz fine.

The attached project has an example design using a CycloneIV whose top hierarchy is 'HDMI_Encoder.sv' and all the used source files are in the 'src' folder.  All the instructions for the parameters are located in the source files.

These are the list of changes/improvements:

1.  The original software serializer using the DDR was replaced with Altera's altlvds_tx serializer megafunction.  In the source 'hdmi.sv', this is a module initiated at line 367, calling source file 'HDMI_serializer_altlvds.sv'.  A dummy spot for Xilinx 'OSERDESE2' serializer was left at line 375, however, I am not familiar or setup to make and test a 'HDMI_serializer_OSERDESE2.sv' module.
2.  A bit/polarity inversion for each of the LVDS channels allowing you to swap the +&- pins on the LVDS outputs for PCB routing.
3.  A number of patches were made to offer support all the way back to Quartus 13.0 sp1 giving support to earlier Cyclones.
4.  A smart single/dual PLL generator, 'HDMI_PLL.sv' which generates the video pixel clock plus a 5x clock used by the serializer when the serializer's built in PLL is disabled.  It also offers a parameter to trick Quartus that the LVDS serial output is running at a lower frequency to allow compilation on slower FPGAs.  (Warnings in the source code.)
5.  The 'HDMI_PLL.sv' also generates an audio clock enable pulse and audio clock synchronous to the pixel clock, with a sub-pixel floating-point clock divider/remainder capable of correcting for audio sample frequencies which do not divide evenly in into the pixel clock.
6.  The original 'hdmi.sv' audio input section now can run in 100% synchronous pixel clock mode, using an 'clk_audio_ena' strobe input to advance the audio sample.  This removes the crossing of clock domain boundaries in the timing report.
7.  New video mode IDs, 34,964,965,969,1024,1084,1085.  See: 'HDMI_Encoder.sv' for the resolutions. 
8.  1KHz sine wave test tone.

Extras, Simulation (At minimal, a basic setup and display of the inner workings):
In Quartus, when doing/running an RTL simulation, in the transcript type:
Code: [Select]
do ../../hdmi_rtl.doTo setup the simulation waveform window and get access to all the core.

In Quartus, when doing an GATE simulation, in the transcript type:
Code: [Select]
do ../../hdmi_gate.doTo setup the simulation waveform to see the N&P TMDS output timing.

For our test bench, we use a 90 cent NXP IC, PTN3366BSMP, for static protection of the IOs, and 5v to 3.3v conversion for the EDID I2C and hot-plug-detect signals.  It is also a 3GHz amplifier/cable driver which may be why we have had no problems making a 550mbps -8 cyclone output a 1280x1024 video mode at 1080mbps.  See our schematic here: (note we are not using resistors R8,R10,R11,R12,R16,R15,R14,R13, and the TXD[0..2] polarity has been swapped to allow straight PCB traces while TXD[3]/TXC has the correct polarity.)
https://www.eevblog.com/forum/fpga/hdmi-dvi-encoder-with-audio-smart-quartus-pll-integration-in-systemverilog/msg3430892/#msg3430892

(The parameters INV_TMDS#s need to be set accordingly if you are to use that example schematic exactly as-is with the swapped +&- pins.)

Things not done, but maybe in the future:  Re-do the audio sampling sub-system to use a true dual-clock M9K ram block instead of logic elements.  This will remove ~700 wasted logic elements on the audio input buffer and when using an external 48KHz audio clock, there wont be a potential list of cross-clock domain timing violations.

Note that the attached .zip is a Quartus project.  If you want to simulate, just compile and then do an RTL or Gate level simulation.  RTL gives you full access to the real time source logic during simulation while the gate level shows you the actual timing of the +&- TMDS outputs pins.
« Last Edit: January 31, 2021, 08:44:48 am by BrianHG »
 
The following users thanked this post: oPossum, KE5FX, agehall, nockieboy

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Here is a stand-alone Altera ModelSim test bench just for my parameter configurable PLL module 'HDMI_PLL.sv'.

It allows you to follow the cascade of parameters and how the audio clock generator creates a perfect overall sample frequency even though it may not divide evenly into the pixel clock.

The simulation runs for 1 full millisecond, this means almost 1 minute to simulate (unless you clock stop midway).
(The testbench sim has 2 frequency counters counting the pixel & audio clock outputs for 1ms exactly after the PLL has started up.)

Since it is a stand-alone simulation project, these are the setup instructions:

1.  Un-zip the the source files into it's own directory.
2.  Run ModelSim for Altera, no Quartus...
3.  In ModelSim, select 'File - Change Directory...' and select the folder you have un-zipped the source files to.
4.  In the 'Transcript', type:  ' do setup.do ' to initialize & setup.  (includes including altera's PLL megafunction library...)
5.  In the 'Transcript', type:  ' do run.do ' to re-compile the source files, setup the waveform display and run the simulation.  (IE: make a parameter or code change and just type once again 'do run.do' to re-compile the source code and re-run the simulation.)
« Last Edit: January 25, 2021, 04:40:48 pm by BrianHG »
 
The following users thanked this post: nockieboy

Offline nockieboy

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Here's the schematic for the test PCB we created.  This PCB was designed to slot straight into an RZ-EasyFPGA A2.2 dev board, shown below and available from AliExpress (at the time this post was made):



Change the input header (H1 in the schematic) configuration for whatever dev board or setup you're designing for.

Here's my test PCB, complete except for the H1 header:

 
The following users thanked this post: BrianHG

Offline purisame

  • Newbie
  • Posts: 2
  • Country: us
Hi BrianHG & nockieboy,

First off just wanted to say it's really exciting to see my project used in some real-world applications  :)
Thank you for sharing these changes. I'll do my best to merge them into the project on Github in the coming weeks. Please share your Github usernames with me so I can credit you in the pull requests + commits.
 

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Hi purisame, welcome to the forum.

Here is Nockieboy's Github page: https://github.com/nockieboy/gpu

I do not have one as I am retired here and I just been helping out Nockieboy over the last year to create his 8-bit GPU project.  That thread begins here: https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg2741158/#msg2741158, though the HDMI begins working at around page ~93...
 

Offline purisame

  • Newbie
  • Posts: 2
  • Country: us
Hey BrianHG, just had a quick question about the serializer changes. The zip here mentions possible Xilinx support via OSERDES2 in a HDMI_serializer_OSERDESE2 module. Did you get around to implementing that?
 

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Hey BrianHG, just had a quick question about the serializer changes. The zip here mentions possible Xilinx support via OSERDES2 in a HDMI_serializer_OSERDESE2 module. Did you get around to implementing that?
I have never used Xilinx, so I am not setup to test and compile.
I do not know the learning curve though I do know how to use modelsim to a point.
If modelsim exists for Xilinx, it should be possible to build this project, swapping out using 'generate if()else' to auto select between Altera's altlvds VS Xilinx's OSERDESE2 during compile time.  If modelsim for Xilinx exists, it should be possible to generate a matching 'vsim.wlf' waveform output with only an initial PLL startup time and a slight parallel in to serial output delay difference.

It might also be possible to select between Altera's altpll and Xilinx equivalent.  My PLL codes generates a source clock divider and feedback clock divider for 5x pixel clock speed plus the 1/5th speed output which just has that output's divider set to 5x the primary clock serdes clock.  Plus it also generates the reference source clock period & frequency, which can be automatically down-tuned to trick the compiler of the true speed the serializer's output clock frequency.  The PLL code obviously does not generate re-configurable data, it just calls altpll with specific dividers set.

If I went as far as generating a re-configurable PLL core for Altera, there is a valid trick avenue to allow us to generate a true 1485mbps 1080p output, but, your HDMI encoder isn't engineered for raw FMAX on the pixel clock, so we would be cutting it close there as well unless we are using a -C6 fpga.

« Last Edit: February 07, 2021, 11:00:33 pm by BrianHG »
 

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf