FPGA VGA Controller for 8-bit computer

[BrianHG]

The code internally seems to support DDRIO mode, IE shift 2 bits per clock.  You will need to read up on how to get it to work, or it might be automatic...

The DDRIO is a parameter in the HDMI module.  Just turn it on and make the x10 clock only x5.

[nockieboy]

Oooops, the module you are using uses x10 on the PLL instead of x5.  I don't think they are using Altera's SERDES.  If not, it may not be possible to achieve the 742.5mbps as the code cant run that fast if they are using a software SERDES instead of a hardware one.

Hmm... the ALTPLL config megawizard can't achieve the required 740MHz on the PLL.  It'll manage 739MHz, but complains that the requested mult/div factors are not achievable if I ask for one more megahertz.

It manages 720x480p just fine, though - you may not see any difference in the next screenshot, but the vertical lines are definitely slightly thinner than the 640x480 version.

[BrianHG]

Oooops, the module you are using uses x10 on the PLL instead of x5.  I don't think they are using Altera's SERDES.  If not, it may not be possible to achieve the 742.5mbps as the code cant run that fast if they are using a software SERDES instead of a hardware one.

Hmm... the ALTPLL config megawizard can't achieve the required 740MHz on the PLL.  It'll manage 739MHz, but complains that the requested mult/div factors are not achievable if I ask for one more megahertz.

It manages 720x480p just fine, though - you may not see any difference in the next screenshot, but the vertical lines are definitely slightly thinner than the 640x480 version.

(Attachment Link)

Set the X10 clock to 371.25Mhz (IE x5) and learn about using the DDR output mode.
It's one of the parameters...
First test with the current 480p by making the current x10 252 Mhz on the PLL 1/2 the current speed and setting the DDRIO parameter.

[asmi]

Hmm... the ALTPLL config megawizard can't achieve the required 740MHz on the PLL.  It'll manage 739MHz, but complains that the requested mult/div factors are not achievable if I ask for one more megahertz.

It manages 720x480p just fine, though - you may not see any difference in the next screenshot, but the vertical lines are definitely slightly thinner than the 640x480 version.

I'd suggest you implement a simple I2C master and dump out DDC information for this monitor, it will tell you exactly which modes are supported. There are MANY different options possible: https://www.mythtv.org/wiki/Modeline_Database
Also touch you FPGA to check if it gets warm (or hot) - I found that when you push really high clocks through FPGA (as in - "out of spec high"), they get rather hot. At least in my case Spartan-7 50T device would've cooked itself if I didn't add a heatsink on top of it.

[nockieboy]

The code internally seems to support DDRIO mode, IE shift 2 bits per clock.  You will need to read up on how to get it to work, or it might be automatic...

Quartus isn't going to play ball with me.    I've enabled DDRIO mode, halved the multiplier on the x10_pixel_clk so that it's a x5_pixel_clk, which made the ALTPLL megawizard happy to synthesise the PLL, but when compiling the project Quartus threw this at me:

Error (176060): The transmitter driving I/O pin TMDS_CLK_p at data rate 743 Mbps exceeds the maximum allowed data rate of 550 Mbps for LVDS_E_3R output

I'll wait to see if you have any suggestions, but it appears that 720p testing will have to continue on the CV - but I still consider this exercise a success as it means I can replace the VGA output on the CV board AND it takes up less space and IOs than the TFP410 would have done, whilst still giving me 640x480 (or even 720x480) video output.

[BrianHG]

Tell Quartus that your source clock is 37MHz instead of 50, but, keep the PLL divider ratios the same.

IE, if you have a frequency set, then record the set divider ratios, then, when editing the PLL, set the source clock to 37MHz.  Then for the output frequency, set those divider ratios instead of a set frequency and give it a try.

You are basically tricking Quartus to overclock the outputs.

The outputs on the CV using the true- LVDS is 740MHz, not 743MHz, so, we will do the same trick, but, with 49.7MHz in place of the 50MHz.

[BrianHG]

Try changing the IO standard to HSIODR if available.  It has a higher FMAX.

[nockieboy]

Tell Quartus that your source clock is 37MHz instead of 50, but, keep the PLL divider ratios the same.

IE, if you have a frequency set, then record the set divider ratios, then, when editing the PLL, set the source clock to 37MHz.  Then for the output frequency, set those divider ratios instead of a set frequency and give it a try.

You are basically tricking Quartus to overclock the outputs.

The outputs on the CV using the true- LVDS is 740MHz, not 743MHz, so, we will do the same trick, but, with 49.7MHz in place of the 50MHz.

Okay, I've given this a try but the monitor is displaying the same image as before and telling me I've got a 480p HDMI signal. 

Have attached the Quartus schematic so you can see the PLL settings, and a screenshot of top.sv to show the hdmi.sv instantiation values.

[BrianHG]

That reference 50MHz is making a mess of things.  I hope you changed that to 27MHz for the CV board.
Can you send me the QP project.
I'll add a primary PLL to first generate 27MHz from the 50, then use the second PLL to make the video clocks.

[nockieboy]

That reference 50MHz is making a mess of things.  I hope you changed that to 27MHz for the CV board.
Can you send me the QP project.
I'll add a primary PLL to first generate 27MHz from the 50, then use the second PLL to make the video clocks.

I hadn't, but it'll be easy enough to change the BOM.  Project attached.

[BrianHG]

Give this a try.
I changed the FPGA to a -7, so it believes the DDRIO FMAX is 640mbps instead of 550.
And in the second PLL, I have the correct dividers setup, but, I told Quartus it was receiving a 23MHz clock instead of 27.
The first PLL creates the 27MHz and 48KHz audio clocks from the source 50MHz.

Other than setting the vertical scan rate to the standard 59.94hz, I didn't do anything else.
Give it a test.
Also, you can go back to 480p for testing with the 2 PLLs as well.

[nockieboy]

Just tried it - no signal that the monitor can recognise, unfortunately.

[BrianHG]

Try 480p, 720x480 using DDR mode.

IE edit the second PLL to 27mhz in, 135mhz & 27Mhz out.

Just want to make sure the DDR mode is functional.
If so, then you probably need to add the 8x 50ohm pullup resistors and maybe play with the 2 dipswitches.


At least if the DDR functions, we can try a CV build and see if the compiler will pass the 743MHz barrier when using a 'true-differential' set of IO pins.  A -6 has a 840MHz max, a -7 has a 740MHz max.  That 2.5 MHz difference should be over-clockable with clean data as we are even amplifying the output.

[BrianHG]

I also just realized the possibility of the compiler merging the 2 PLLs together into 1 and literally reformulating the divider ratios to match the 23MHz source and multiply the clocks from there.  Right now, we will say this is not the case.

[nockieboy]

Try 480p, 720x480 using DDR mode.

IE edit the second PLL to 27mhz in, 135mhz & 27Mhz out.

Just want to make sure the DDR mode is functional.
If so, then you probably need to add the 8x 50ohm pullup resistors and maybe play with the 2 dipswitches.


At least if the DDR functions, we can try a CV build and see if the compiler will pass the 743MHz barrier when using a 'true-differential' set of IO pins.  A -6 has a 840MHz max, a -7 has a 740MHz max.  That 2.5 MHz difference should be over-clockable with clean data as we are even amplifying the output.

Hmm, okay..  I've had to roll back my project to before your change to add the 27MHz PLL.  No matter what I've tried, I've not been able to output a signal the monitor could read.  Won't be able to test any more tonight, but I'll take another look at trying DDR mode tomorrow morning.

[nockieboy]

It would appear that the DDRIO mode doesn't work - or doesn't work just by halving the x10 pixel clock and setting DDRIO to 1'b1, in any case.  Have tried to get it working with the basic 640x480 output that I know works - seems the same problem is evident.

[asmi]

You might want to go through P&R warnings - at least in Vivado they often contain hints as to why something doesn't work.
But fundamentally I think you guys should just leave it alone for now. The fact that 480p works fine should give you confidence to drop VGA port and TFP410 for good, so that you can finish your PCB design and continue with your experiments on a new board. Also note all issues found with breakout board and write them down somewhere, so that you won't forget to correct them when you transfer design to a final board. I often place such notes as text right in the schematic, because it not uncommon for me to begin incorporating these things into a final board few moths after I've done my testing, so obviously I forget a lot of stuff.

[asmi]

EDIT:  In my defence, the TX outputs where connected up to the PTN3366 to create the simplest routing to the HDMI connector.  If I'd connected positive to positive, negative to negative, each of the pairs would have had to cross over to get to the HDMI connector...  Which seems a bit odd, you'd think the chip or the connector would be made so that wouldn't happen, but I recall someone telling me a while ago that it didn't matter which way round the connections were made, but I guess it helps to know that they're swapped around though, so that the outputs can be swapped accordingly in Quartus...  I'd forgotten I'd done that.

It could be that the chip pinout was designed for placement on the other side of the board from HDMI connector. I can see how this would allow for more tight layout. It's not uncommon for interface chips to have several versions with different pinouts optimized for different placement scenarios.

[BrianHG]

Ok, here is the HDMI_multi_tests.zip...

5 Projects inside:

HDMI_test_SDR_480p  > only proceed onto the next project if this one works.
HDMI_test_DDR_480p  > only proceed onto the 720p projects if this one works.

If the first 2 pass, then try all these 3:
HDMI_test_720p_A    >  Attempts 742.5 mbps exact using odd dividers in the PLLs.
HDMI_test_720p_B    >  Attempts ~740 mbps proper short dividers.  (This could have been the official 742.5 if you had a 27MHz crystal on the PCB.)
HDMI_test_720p_C    >  Attempts 640 mbps proper short dividers.  This is an oddball low frequency non-standard 720p @ 52.5hz.  It may have a chance on your desktop PC monitor's HDMI input.  If the monitor reports frequency out of range instead of dead/no video, then we know the HDMI data was understood, just that the video mode was a lemon scan rate.  Audio packets will most likely be corrupt.

Happy New Years...

[nockieboy]

Ok, here is the HDMI_multi_tests.zip...

5 Projects inside:

HDMI_test_SDR_480p  > only proceed onto the next project if this one works.
HDMI_test_DDR_480p  > only proceed onto the 720p projects if this one works. <<< FAILS HERE

If the first 2 pass, then try all these 3:
HDMI_test_720p_A    >  Attempts 742.5 mbps exact using odd dividers in the PLLs.
HDMI_test_720p_B    >  Attempts ~740 mbps proper short dividers.  (This could have been the official 742.5 if you had a 27MHz crystal on the PCB.)
HDMI_test_720p_C    >  Attempts 640 mbps proper short dividers.  This is an oddball low frequency non-standard 720p @ 52.5hz.  It may have a chance on your desktop PC monitor's HDMI input.  If the monitor reports frequency out of range instead of dead/no video, then we know the HDMI data was understood, just that the video mode was a lemon scan rate.  Audio packets will most likely be corrupt.

As above - the DDR_480p test doesn't work - no HDMI signal picked up by the monitor.

Happy New Years...

And to you! 

[BrianHG]

Can you do me a favor and try changing the IO Standard to Differential 2.5v SSTL Class II.

I tried simulating the 480p SDR and DDR.  The output from the 2 look identical other than the PLL startup time.  If this doesn't work, can you point me to where you downloaded the source code.  I do know that in the code, they are using their own parallel to serial shift register instead of an official SERDES and that the DDR is their own home made 2-step shift-er.

Without using the DDR, or, Altera's SERDES which also uses a 5x clock to transmit the 10bit high megabaud output, you could never use this particular code for 720p or 1080p.

[BrianHG]

If the change in IO standard doesn't work, return it back and try placing 1 inverter on the 5x/10x clock, or one inverter on the pixel clock. (Inbetween PLL and HDMI transmitter...)
The simulation final HDMI output did match (on old Quartus with Cyclone III), yet, what I gave you did match and the video out didn't work.

[nockieboy]

Can you do me a favor and try changing the IO Standard to Differential 2.5v SSTL Class II.

I tried simulating the 480p SDR and DDR.  The output from the 2 look identical other than the PLL startup time.  If this doesn't work, can you point me to where you downloaded the source code.  I do know that in the code, they are using their own parallel to serial shift register instead of an official SERDES and that the DDR is their own home made 2-step shift-er.

Without using the DDR, or, Altera's SERDES which also uses a 5x clock to transmit the 10bit high megabaud output, you could never use this particular code for 720p or 1080p.

Here's the source for the HDMI code I'm using: https://github.com/hdl-util/hdmi/

Changing the IO standard to Differential 2.5v SSTL Class II just threw errors when I tried to compile the code - unsupported standard or something.

If the change in IO standard doesn't work, return it back and try placing 1 inverter on the 5x/10x clock, or one inverter on the pixel clock. (Inbetween PLL and HDMI transmitter...)
The simulation final HDMI output did match (on old Quartus with Cyclone III), yet, what I gave you did match and the video out didn't work.

Adding an inverter doesn't work either - no HDMI signal picked up by the monitor.

[BrianHG]

Ok, I think that step 1 should be reverting to the original code where we get the errors:

Code: [Select]

Error (15856): Output port O of I/O output buffer "top:inst1|hdmi:hdmi|OBUFDS:obufds|altera_gpio_lite:obufds_inst|altgpio_one_bit:gpio_one_bit.i_loop[3].altgpio_bit_i|true_diff_output_buf.obuf" must drive a top-level pin
Error (15856): Output port O of I/O output buffer "top:inst1|hdmi:hdmi|OBUFDS:obufds|altera_gpio_lite:obufds_inst|altgpio_one_bit:gpio_one_bit.i_loop[2].altgpio_bit_i|true_diff_output_buf.obuf" must drive a top-level pin
Error (15856): Output port O of I/O output buffer "top:inst1|hdmi:hdmi|OBUFDS:obufds|altera_gpio_lite:obufds_inst|altgpio_one_bit:gpio_one_bit.i_loop[1].altgpio_bit_i|true_diff_output_buf.obuf" must drive a top-level pin
Error: Quartus Prime Analysis & Synthesis was unsuccessful. 3 errors, 10 warnings
Error: Peak virtual memory: 644 megabytes
Error: Processing ended: Fri Jan 01 22:08:27 2021
Error: Elapsed time: 00:00:27
Error: Total CPU time (on all processors): 00:00:34
Error (293001): Quartus Prime Full Compilation was unsuccessful. 5 errors, 10 warnings

Ok, what Quartus is saying isn't that there is a coding error.  It is saying that the defined output buffer must drive a top level pin.
Let's see if we can resolve that properly instead of skipping the IOBUF module.

[BrianHG]

Ok, issue properly resolved.  All I had to do was assign the 'top.sv' as top hierarchy in quartus to allow compilation.  I do not like this solution as it demands that this module needs to become the top priority in quartus.

Doing the above has just wired the top.sv directly to IO pins ignoring the rest of the design.