Need help...

[mopplayer]

Hi @sameer,

I have studied several repos of related projects.
https://github.com/charcole/NeoGeoHDMI/blob/master/HDMIDirect.v
My monitor was CHIMEI 24SH-L, also tested with BENQ GW2480, but no luck (no signal).
https://imgur.com/ArIkfPk
The first block of the picture is "video guardband", and is the second white block "wrong audio block"?

After some reworking, I use this repo and others, to simplify the problem.
https://imgur.com/fWueDsr
Now I can get the "wrong audio block" disappeared, but no audio comes out.

Scenario  (720x480, 27M pixel clock):

1. CounterX(cx) >= 720 + 4  && CounterX(cx) < 720 + 4 + 8
   --->  Enter Data Island Preamble, CTL[3:0] = 4'b0101

If the 12 pixels prior to the transition contain any pixels not encoded with Control Period Coding then FAIL, (Control Period too short) (HDMI 1.4b CTS page 148)

2.  CounterX(cx) >= 720 + 4  && CounterX(cx) < 720 + 4 + 8 + 2
   ---> Enter Data guardband, Channel 0 = { HSYNC ,VSYNC }, Channel 1 = 10'b0100110011, Channel 2 = 10'b0100110011, CTL[3:0] = 4'b0000

If TMDS channel 0 for either of these pixels does not equal one of the 4 permitted Data Island Guard Band characters (0xC, 0xD, 0xE, 0xF) [HDMI: 5.2.3.3] then FAIL (HDMI 1.4b CTS page 148)

3. CounterX(cx) >= 720 + 4  && CounterX(cx) < 720 + 4 + 8  + 2 + 32
   ---> Data Island, for now I JUST send one packet, more will lead to "wrong audio block" to come out. For Channel 0 bit 3 first=0, and others= 1.
   If Audio Clock Regeneration packet is ok then send this packet, otherwise sends Audio Sample Packet, AVI Infoframe packet or Audio infoframe packet.
   I also have checked the packet definition of HDMI and CEA861-D.
   (*Packet format assume OK, I have no changed)

If first character following the Leading Guard Band has TERC4 ch. 0, bit 3 == 1 then FAIL (HDMI 1.4b CTS page 148)
If any other character prior to Trailing Guard Band has TERC4 ch. 0, bit 3 != 1 then FAIL (HDMI 1.4b CTS page 148)
Length of Data Island is equal to number of pixels following Leading Guard Band and prior to Trailing Guard Band. Number of packets = Length of Data Island / 32. (HDMI 1.4b CTS page 148)
If any two video fields occur with no AVI InfoFrame then FAIL (HDMI 1.4b CTS page 168)
If Audio InfoFrame Packet is detected at least once per two video fields then continue else then FAIL (HDMI 1.4b CTS page 177)

4. CounterX(cx) >= 720 + 4  && CounterX(cx) < 720 + 4 + 8  +  2 + 32 + 2
   ---> Data Guardband , Channel 0 = { HSYNC ,VSYNC }, Channel 1 = 10'b0100110011,  Channel 2 = 10'b0100110011, CTL[3:0] = 4'b0000

If any character following the Leading Guard Band but preceding the Trailing Guard Band is not a legal TERC4 code then FAIL  (HDMI 1.4b CTS page 148)

5. CounterX(cx) >= 720 + 4 + 8  +  2 + 32 + 2 && CounterX(cx) <  858 - 8  - 2
   ---> Do nothing, CTL[3:0] = 4'b0000

6. CounterX(cx) >=  858 -  8 - 2 && CounterX(cx) <  858 - 2
   ---> Video Preamble, CTL[3:0] = 4'b0001

7. CounterX(cx) >=  858 -  2 && CounterX(cx) < 858
   ---> Video Guardband, Channel 0 = 10'b1011001100, Channel 1 = 10'b0100110011, Channel 2 = 10'b1011001100

8. CounterX(cx) >= 0 && CounterX(cx) < 720
   ---> Video Data

If any character following Video Guard Band up to transition is not a correctly encoded Video Data code then FAIL  (HDMI 1.4b CTS page 149)

Did I miss something?

Could you let me know how to get started?

Thank you very much.

[sameer]

I am surprised you are actually able to see the guard bands... that implies that the sink is understanding the hdmi input and the guard is somehow duplicated. I feel like there could be some hardware setup / parameter issue.

Few more questions:

• What FPGA board are you using?
• Have you tried alternate HDMI cables?
• Is the HDMI port on the board or did you solder it yourself?
• Can you share the parameters you used when instantiating the hdmi module?

[mopplayer]

Hi @sameer,

The guardband is like author (https://github.com/charcole/NeoGeoHDMI/blob/master/HDMIDirect.v) saying.

		// Send the data period preamble
		// A nice "feature" of my test monitor (GL2450) is if you comment out
		// this line you see your data next to your image which is useful for
		// debugging

If I change this `define VIDEO_GUARDBAND 32
I get this for fun:
https://imgur.com/1vVq5b5

What FPGA board are you using?
My board is Lichee Tang Primer. The FPGA is Anlogic EG4S20.
But if it works under DVI mode only, that video guard band also disappears, anything is fine.
I want the audio working.
If only I use this repo to do, there is no signal (720x480, 59.94, 27M, 32K for both monitors)

Have you tried alternate HDMI cables?
Changing cables is the same result.

Is the HDMI port on the board or did you solder it yourself?
The HDMI port is connected between 2.54 pins and wires (21 cm). Port setting is LVDS3V3.

Can you share the parameters you used when instantiating the hdmi module?

I am based on charcole code: Other settings in the code leaving no changes. (720 x 480, N=4096, CTS=27000, and so on)
You could just see the main block (https://github.com/charcole/NeoGeoHDMI/blob/8d66141d150ea53abcc77258ed8db8890887f646/HDMIDirect.v#L642)

HDMIDirectV	u_HDMIDirectV(
	.pclk_hdmix5(pclk_hdmix5),	
	.pclk_hdmi(pclk_hdmi),		
	.reset(reset),
	.red(red),		
	.green(green),
	.blue(blue),					
	.CounterX(CounterX),	
	.CounterY(CounterY),		
	.audioL(audioL),			
	.audioR(audioR),		
	.TMDS(TMDS),		
	.led(led)
); 		 

[sameer]

I mean the module parameters for this repo, i.e. VIDEO_ID_CODE. Unfortunately, I don't have the bandwidth to look into the charcole code.

Lichee Tang Primer

I recently got the Tang Nano 9k and I'm planning to set up a demo in hdi-util/hdmi-demo for it. Will let you know if I run into similar issues with it

[mopplayer]

Hi @sameer,

VIDEO_ID_CODE = 2, other setting is listed above.
That's OK, just see your repo and code, Now there is no signal.

hdmi #(.VIDEO_ID_CODE(2), .VIDEO_REFRESH_RATE(59.94), .AUDIO_RATE(32000), .AUDIO_BIT_WIDTH(16)) hdmi(

And you could check the difference from waveform:
The serializer is totally same.
Your repo:
https://imgur.com/0GJqTCT

others:
https://imgur.com/j5k7RjA

I also notice that "LVDS voltage swing range from 250mV(minimum) to 450mV (maximum) with a typical value of 350mV. Because the voltage swing is very low and."

So..., it might be the electrical  problem, need several resistors to lower the peak-peak.

By now, I connect directly to the HDMI connector from the FPGA LVDS33 pin.

Thank you very much.

[mopplayer]

Congratulations!

I could hear the sounds using the  charcole code.

And the video guard band disappeared.

But I do not know why....

Now I use "emulated" LVDS33 (i.e. not true LVDS33) to send TMDS signal.

From the manual, emulated LVDS33 needs some external resistors to low down swing voltage....

But I connect directly to the HDMI connector.

You could see the waveform and peak-peak.

TMDS:
https://imgur.com/L70d2X0

TMDS clock:
https://imgur.com/QBM55jl

Did you know why?

By the way,  your repo and code still have no signal....
https://imgur.com/AlrFEhf

[hvegh]

Hi all, would like to share my findings with Tang Nano 9K:

On my older Samsung TV audio and video work on the port labeled "HDMI/DVI" the other HDMI port on this device has no output.
The newer Samsung TV I have, knows there is a device but fails with check cables on all of the HDMI ports... so no output here.

So I think maybe mode line is not supported i check:

Linux report on TV:

// Modeline "Mode 4" 74.250 1280  1390       1420     1650   720   725        730      750 +hsync +vsync
//                   pclk   hdisp hsyncstart hsyncend htotal vdisp vsyncstart vsyncend vtotal

So slight adjustment in the hdmi.v table changed the hsync_pulse_size to 30 in order to match modeline...

        4:
        begin
            assign screen_width      = 1280;
            assign hsync_pulse_start = 110;
            assign hsync_pulse_size  = 30; // 40;
            assign frame_width       = 1650;

            assign screen_height     = 720;
            assign vsync_pulse_start = 5;
            assign vsync_pulse_size  = 5;
            assign frame_height      = 750;
            assign invert            = 0;
        end

Still no luck, any ideas?

Kind regards,
Henk

[hvegh]

So questions is:

Why do regular TV's not support this signal.
While DVI monitors output this signal without problem...

Is it electrical compatibility?
For Gowin I use emulated LVDS ...

Or is it some sort of configuration issue where the TV decides the content is not compliant, due to not being encrypted?

[edanuff]

Old open issue, but seeing related problem with Tang Nano 9k - testing with Eizo monitors that work with the SimpleVOut core that Sipeed uses in their demos (picotiny, etc.), but finding do not work when using this core, even with same resolutions and clock timing.

[sameer]

Old open issue, but seeing related problem with Tang Nano 9k - testing with Eizo monitors that work with the SimpleVOut core that Sipeed uses in their demos (picotiny, etc.), but finding do not work when using this core, even with same resolutions and clock timing.

From what I can tell, SimpleVOut is just a DVI signal. It is possible that those monitors do not support true HDMI, could you try setting DVI_OUTPUT to 1? https://github.com/hdl-util/hdmi/blob/master/src/hdmi.sv#L30

That will help pinpoint things further.

@edanuff

[sameer]

Also, I see that you started a Tang Nano 9k demo -- if you get it working would really love to see it merged into https://github.com/hdl-util/hdmi-demo

[edanuff]

Hi Sameer, thanks for your reply. I was looking at the DVI_OUTPUT flag but when I turn that on, it stops working on my HDMI monitors. This original problem I'm trying to solve is that I'm using your HDMI core in a different Tang Nano 9K project and I got a bug report by one of my testers that it wasn't working with either of his Eizo monitors. After discussing with him and looking at the spec sheets for the monitors, it became clear these monitors were DVI monitors being used with an HDMI adapter. I was going to do a build with DVI_OUTPUT set to 1 and see if it fixes it for him but I was trying to figure out why DVI_OUTPUT didn't work with my HDMI monitors first. I'll also clean up the hdmi-demo example and send it as a pull request. That was just a mashup of Sipeed's HDMI example and your hdmi-demo code.

EDIT: DVI_OUTPUT=1 causes it to stop working on one of my HDMI monitors, interestingly SimpleVOut does work on this monitor though. I will update once I've determined with DVI_OUTPUT=1 fixes the problem on the actual DVI monitors.

[sameer]

EDIT: DVI_OUTPUT=1 causes it to stop working on one of my HDMI monitors, interestingly SimpleVOut does work on this monitor though. I will update once I've determined with DVI_OUTPUT=1 fixes the problem on the actual DVI monitors.

That's definitely not expected, thank you for looking into it!

[sameer]

It's possible we may need some more configuration than just DVI_OUTPUT. Maybe the data islands are not supported by these DVI sinks, but some of the other stuff like the guard bands can go unignored.

[edanuff]

Thought the problem was in the control data component but on second look, I don't think that's the problem.

[sameer]

@edanuff would you mind checking if this is fixed by #44?

[edanuff]

Hi Sameer, DVI_OUTPUT(1) fixes the problem with the Eizo monitors (both the previous version and the current version).

However, it doesn't fix the issue I'm seeing with the Eyoyo HDMI monitor that I'm also using for testing. WIth that monitor, what I see with both the previous version and the #44 fix is:

hdl-util/hdmi with DVI_OUTPUT(0): works
SimpleVOut: works
hdl-util/hdmi with DVI_OUTPUT(1): blank screen except after about a minute or two it then works

[krisdover]

hdl-util/hdmi with DVI_OUTPUT(0): works SimpleVOut: works hdl-util/hdmi with DVI_OUTPUT(1): blank screen except after about a minute or two it then works

@sameer I wonder if this might have something to do with legacy DVI having a different TMDS encoding for control data. Page 29 of the DVI v1.0 spec has the following:

Also have a look at how legacy TMDS encoding is handled in this video lag tester project I've been tinkering with. Hope this helps.

[xtreme8000]

I wonder if this might have something to do with legacy DVI having a different TMDS encoding for control data. Page 29 of the DVI v1.0 spec has the following

@krisdover I just came here from google; the control data encoding is in fact the same for HDMI and DVI, it's just that the bits are written mirrored in the DVI spec. Note how it says q_out[0:9] there vs q_out[9:0] in 5.4.2 of the HDMI 1.4 spec.

[krisdover]

@xtreme8000 ah, I did not realise that was the only difference. Thanks for clarifying.