FPGA VGA Controller for 8-bit computer

[BrianHG]

I think you need to join Hithub and ask the author how to do everything since he wrote the code.

With his code, you cannot seem to use the LVDS_E_3R.
You cannot seem to be able to invert the output data.
The DDR doesn't seem to work.

And you cannot use any earlier versions Quartus other than 18.0 and above thanks to the:
Error: Node instance "true_diff_output_buf.obuf" instantiates undefined entity "fiftyfivenm_io_obuf

It would be useful to be able to properly bypass these issues before you go onto the 'DDR' problem.
That is unless you want to claim our current bypass as 'perfect' and claim the 'DDR' is flawed which we cannot truly officially do.  All you can say is that we got the 480p SDR mode working with a separate top hierarchy in Quartus and turning on the DDR with a 5x clock fails at the same 480p.

Remember that we are using Cyclones.
Also mention that a selection for inverting individual bits is useful as N&P wiring can be easily made straight.
Also mention that using emulated LVDS, IE LVDS_E_3R is still capable of 650mb/sec.
Also offer the 94cent NXP IC we found to buffer and protect the source LVDS and your example schematic.

Try to get the guy to do some minimal work for you.
Maybe upload the example 480p to him.
(Make clear that you bypassed the OBUFDS.v to get the code to fit.)

Without DDR support, or use Quartus serializer, you will never go above 480p.

[BrianHG]

Ok, I modified the GitHub's HDMI transmitter code to use Altera's 'altlvds_tx' serializer megafunction.
It's set to 480p, and I also now added the ability to configure each TMDS output channel's polarity.
I also added a parameter PIXEL_MHZ which overrides and tells the serializer the source pixel clock frequency.  It has no effect anywhere else.  This means if we try 720p where the bit rate is 742.5mbps while the -7's limit is only 740.0mbps, we can just lie here and set it to 74MHz instead and Quartus wont have a melt-down aborting the compile.

Let me know if it works.

The 'altlvds_tx' serializer also tells the IOs up the chain of any number of modules to be configured as differential of any type and works out the maximum bitrate based on which pins you use.  It also now works with earlier versions of Quartus all the way back to 9.1.

[BrianHG]

  Do me a favor and test this old DDR one as well.
It seems the - tmds clk_n pin in all the previous package were not assigned, IE they were set to weak pull-up VCC only.

Though, the - tmds clk_n was also not assigned in the SDR build as well...

Anyways, the altlvds_tx version is the true way to do it unless you want to debug the damn IOBUF and manually set every nuance hoping you haven't left anything to chance including setting up the PLL manually.

[nockieboy]

Don't know what happened yesterday, but I missed any notification of your posts so apologies for the delay replying.

Ok, I modified the GitHub's HDMI transmitter code to use Altera's 'altlvds_tx' serializer megafunction.
It's set to 480p, and I also now added the ability to configure each TMDS output channel's polarity.
I also added a parameter PIXEL_MHZ which overrides and tells the serializer the source pixel clock frequency.  It has no effect anywhere else.  This means if we try 720p where the bit rate is 742.5mbps while the -7's limit is only 740.0mbps, we can just lie here and set it to 74MHz instead and Quartus wont have a melt-down aborting the compile.

Let me know if it works.

The 'altlvds_tx' serializer also tells the IOs up the chain of any number of modules to be configured as differential of any type and works out the maximum bitrate based on which pins you use.  It also now works with earlier versions of Quartus all the way back to 9.1.

This one works - getting good 480p HDMI output.

Do me a favor and test this old DDR one as well.
It seems the - tmds clk_n pin in all the previous package were not assigned, IE they were set to weak pull-up VCC only.

Though, the - tmds clk_n was also not assigned in the SDR build as well...

Anyways, the altlvds_tx version is the true way to do it unless you want to debug the damn IOBUF and manually set every nuance hoping you haven't left anything to chance including setting up the PLL manually.

No joy with this one - still no HDMI output detected by the monitor.

I think you need to join Hithub and ask the author how to do everything since he wrote the code.

Will do.

[BrianHG]

Don't know what happened yesterday, but I missed any notification of your posts so apologies for the delay replying.

Ok, I modified the GitHub's HDMI transmitter code to use Altera's 'altlvds_tx' serializer megafunction.
It's set to 480p, and I also now added the ability to configure each TMDS output channel's polarity.
I also added a parameter PIXEL_MHZ which overrides and tells the serializer the source pixel clock frequency.  It has no effect anywhere else.  This means if we try 720p where the bit rate is 742.5mbps while the -7's limit is only 740.0mbps, we can just lie here and set it to 74MHz instead and Quartus wont have a melt-down aborting the compile.

Let me know if it works.

The 'altlvds_tx' serializer also tells the IOs up the chain of any number of modules to be configured as differential of any type and works out the maximum bitrate based on which pins you use.  It also now works with earlier versions of Quartus all the way back to 9.1.

This one works - getting good 480p HDMI output.

Holy crap....
Great.
Make sure the audio is available too.
Give me a minute to compile a few 720p tests.

[BrianHG]

Ok, here are 3 720p tests.

Because of the source 50MHz clock and only 2 PLLs, version A has the pixel clock at 74.23MHz instead of the true 74.25MHz.

Version B has it at 74MHz.

Version C has it at 64MHz being that the IO Pin standard of LVDS_E_3R's limit is officially 640mbps.   Version C might only work on a PC monitor as the output is a weird 51.6Hz.

If version C works, then we pretty much know something is weird with the original author's 'DDR' function as if the current clues already don't point to a problem somewhere.

If none work, you will probably need to add those 8 resistors you did not place on your PCB as the termination is required for the higher bit rates.  Worst, the DRAM chip would probably need to be removed.  However, since Altera's official 'altlvds_tx' megafunction has properly transmitted 480p, and with the megafunction's specs match the datasheet's numbers, using the right 4 LVDS IOs on the CV is pretty much a go if you use my patched version of the HDMI transmitter.  (Note that the right 740mbps true-LVDS outputs are on the sides of the CycloneIV, not the bottom row which we used because of convenience.)

[nockieboy]

All three work fine.

Here's an image from the 'A' test - B & C are identical.



EDIT:  Test 'C' reports HDMI 720p @ 52Hz.

[BrianHG]

LOL.... So much for the 650mbps limit.  But wait, you are actually using a -8 chip, the limit supposed to be 550mbps and you are doing 742mbps.  With this kind of stretch, I wonder if 1080p @60hz would work with a -6 cyclone and the NXP amp IC.  It's official true-LVDS is 840mbps and we need 1485mbps.  The NXP IC also has an enhancement gain beginning at 1.5GHz all the way up to 3GHz as it was designed to amplify weak signals.

Did you install the resistors?
The NXP chip being mounted right next to the Cyclone must be sharpening the edge of the sluggish IOs.

Please test the next one.  Let me know if the lines are razor sharp.

Something ain't right with the original author's 'DDR' function.  Yet, I did a simulation of both 480p with and without the DDR and they appeared to match.

[nockieboy]

LOL.... So much for the 650mbps limit.  But wait, you are actually using a -8 chip, the limit supposed to be 550mbps and you are doing 742mbps.

Did you install the resistors?
The NXP chip being mounted right next to the Cyclone must be sharpening the edge of the sluggish IOs.

Please test the next one.  Let me know if the lines are razor sharp.

I guess there's a big safety margin in those performance quotes.... 

No, haven't installed the termination resistors.  Here's a picture of my setup - if you look closely, you'll see no termination resistors, just blank pads where they should go.



The NXP chip will be even closer to the CV on the final board - with dedicated signal lines not being shared with a DRAM chip like the existing dev board setup!  (The DRAM chip is hidden underneath the DVI Tester board, for those following along).

[nockieboy]

Please test the next one.  Let me know if the lines are razor sharp.

No HDMI signal detected. 

[BrianHG]

Ok, all I did was use video ID mode 16, 1080p@60Hz and half the clock rate for 30Hz.  I looked at the CEA861D spec and this video mode's format ID is actually #34.  I added this mode to the HDMI transmitter code and re-zipped the new project.

Note that not all computer screens will support this 30Hz mode, but HDMI TVs will as it is part of the spec.

Give this one a test...

[nockieboy]

Note that not all computer screens will support this 30Hz mode, but HDMI TVs will as it is part of the spec.

Give this one a test...

I'm getting a message on the monitor - "HDMI Out of Range - 67.4kHz / 81 Hz"

[BrianHG]

Note that not all computer screens will support this 30Hz mode, but HDMI TVs will as it is part of the spec.

Give this one a test...

I'm getting a message on the monitor - "HDMI Out of Range - 67.4kHz / 81 Hz"

Found another bug.  The author of the original code has stripped the number of bits for the horizontal and vertical counters unless a particular video mode was selected.  He should have let the compiler deal with that...
Try this build.

[nockieboy]

Note that not all computer screens will support this 30Hz mode, but HDMI TVs will as it is part of the spec.

Give this one a test...

I'm getting a message on the monitor - "HDMI Out of Range - 67.4kHz / 81 Hz"

Found another bug.  The author of the original code has stripped the number of bits for the horizontal and vertical counters unless a particular video mode was selected.  He should have let the compiler deal with that...
Try this build.

No HDMI signal at all with this one. 

[BrianHG]

No HDMI signal at all with this one. 

You will probably need to try a different screen which supports 30Hz.  Or, something else in the HDMI code isn't done right.  We do not know if the author has ever successfully tested 1080p @ 60Hz in the first place.
You can also try looking at the '' 'real '' command in the parameter in the audio packet portion of the code.  I have it removed for compatibility, but, I doubt that would make a difference.

Ok, we know you can do video above 480p.

It is time to build a CV project with only Altera's DDR3 ram controller configured and plan the IO banks & pins.  We would like to get an FMAX of 371.25MHz or 324MHz instead of the bottom end guaranteed 303MHz.  The first 2 are nice multiples of 27MHz & 720p video clock.  I doubt we can achieve 27Mhz*16=432MHz unless you are using a CV-6 and a little trickery.

Then insert the HDMI and plan the IO pins.

Then build your PCB, then add the other slow Z80 & other IO ports.

Also, if there is IO room, you might be able to place 2 HDMI ports even if you only wire up one of them.

[nockieboy]

Ok, we know you can do video above 480p.

The 720p mode is looking sharp and stable.

It is time to build a CV project with only Altera's DDR3 ram controller configured and plan the IO banks & pins.  We would like to get an FMAX of 371.25MHz or 324MHz instead of the bottom end guaranteed 303MHz.  The first 2 are nice multiples of 27MHz & 720p video clock.  I doubt we can achieve 27Mhz*16=432MHz unless you are using a CV-6 and a little trickery.

Then insert the HDMI and plan the IO pins.

Then build your PCB, then add the other slow Z80 & other IO ports.

So just a standalone CV project for the DDR3 controller?

[BrianHG]

Found another bug.  I had to add another reference to mode #34.  But it seems it was only for the packet counter.

[nockieboy]

Found another bug.  I had to add another reference to mode #34.  But it seems it was only for the packet counter.

No valid HDMI signal. 

[BrianHG]

So just a standalone CV project for the DDR3 controller?

Yes.  Make a DDR3 controller set to the ram chip we are using and have 2 read/write ports for now.
Set and wire the memory IOs and PLL.
Create dummy controls for the DDR3 controller's read and write port commands.

BTW, Hun, what with that photo?
Where did the text and color bars come from?

[BrianHG]

Try using your monitor with your PC in HDMI 1080p @ 30Hz/29.97Hz.  If the monitor shows a picture, then there is a flaw in the HDMI code.

[nockieboy]

BTW, Hun, what with that photo?
Where did the text and color bars come from?

The HDMI project on github has a basic test screen (the coloured edges of the screen created with a single line in the top.sv file).  There is a more advanced output from another repo by the same author, compatible with the top.sv in our test project.  I just added the symbol file and couple of other files from the other repo and modded our top.sv to use them to generate the output you see in the pic.  I figured it was a little more helpful than just the coloured edges.

EDIT: Note that I've only done that with the HDMI_test_720p_altlvds_tx_A project (oh, and the original SDR_480p one too).

[BrianHG]

Ok, no prob.
It may be useful to add an audio tone on the audio input for testing.
The 720pA is the closest to the real thing.  Off by 20khz, but having a 27MHz source crystal would fix the issue.

See if you can get your PC to output 1080p @ 29.97Hz onto your monitor.
It is not worth my time debugging someone else's code if the limitation is in your monitor.
The 1080p @29.97Hz has the same clock as the 720P version A.
I suspect the code based on the weird high frequency error message when the counters did not have enough bits, so they looped around quickly.
You can try changing the counters in the top.sv from 10bits to 13bits.  IE [9:0] to [12:0].  Maybe that will fix the bug.

[nockieboy]

Ok, no prob.
It may be useful to add an audio tone on the audio input for testing.
The 720pA is the closest to the real thing.  Off by 20khz, but having a 27MHz source crystal would fix the issue.

See if you can get your PC to output 1080p @ 29.97Hz onto your monitor.
It is not worth my time debugging someone else's code if the limitation is in your monitor.
The 1080p @29.97Hz has the same clock as the 720P version A.
I suspect the code based on the weird high frequency error message when the counters did not have enough bits, so they looped around quickly.
You can try changing the counters in the top.sv from 10bits to 13bits.  IE [9:0] to [12:0].  Maybe that will fix the bug.

The counters are already 14-bit in top.sv?  But anyway, I've been unable to set up a 1080p 30Hz display on my PC, but as luck would have it Santa brought my daughter a new TV for Christmas, so the old one was sitting around gathering dust.  I've just set it up and plugged the test board into it with the latest HDMI_test_1080p_altlvds_tx project running, and it works!  A pixel-sharp 1080p image at 30Hz! 

As soon as I plug in some noise generation, I'll test the audio output as well (my PC monitor doesn't have built-in speakers so I couldn't test it before).

[asmi]

You might want to try 1080p@24Hz, which is standard HDMI mode:

Code: [Select]

pixel_clk hres  hs_s hs_e hs_t vres vs_s vs_e vs_t
74.16 1920 2558 2602 2750 1080 1084 1089 1125
pixel_clk - pixel clock frequency
hres - horizontal active area width
hs_s - horiz. sync start
hs_e - horiz. sync end
hs_t - total horiz. line length
vres - vertical active area height
vs_s - vertical sync start
vs_e - vertical sync end
vs_t - total vertical sync length
hound here: https://www.mythtv.org/wiki/Modeline_Database
This mode worked with my monitor, and it requires slightly less bitrate than 720p@60, so it should be easier to reach.

[BrianHG]

You might want to try 1080p@24Hz, which is standard HDMI mode:

Code: [Select]

pixel_clk hres  hs_s hs_e hs_t vres vs_s vs_e vs_t
74.16 1920 2558 2602 2750 1080 1084 1089 1125
pixel_clk - pixel clock frequency
hres - horizontal active area width
hs_s - horiz. sync start
hs_e - horiz. sync end
hs_t - total horiz. line length
vres - vertical active area height
vs_s - vertical sync start
vs_e - vertical sync end
vs_t - total vertical sync length
hound here: https://www.mythtv.org/wiki/Modeline_Database
This mode worked with my monitor, and it requires slightly less bitrate than 720p@60, so it should be easier to reach.

What's the format number?
These are the official DTV HDTV modes circa CEA-861-D:



BTW, your 24hz mode is format id #32, however, if a monitor wont do the basic #34, it probably wont do #32.  Also, the pixel clock frequency is wrong.  In the  CEA-861-D specs, it should be either 74.25Mhz for 24hz, or, 74.188MHz for telecin 23.98Hz.  There is no 74.16Mhz standard.  Do not get your tech information from Wiki please...
We are achieving the 74.25Mhz fine, otherwise, Nockieboy would have seen some digital garbage with the 720p version A example.

The problems we had trying to get higher clock rates were issues with the author's home made serializing code.