HDMI on Blackice Mx

lawrie 2019-07-17 14:27:31 UTC #1

I have been attempting to use the HDMI connector on the Blackice Mx using a variant of the test program I used with @uXe's HDMI Pmod.

It works with the HDMI Pmod on the Blackice Mx, but not with HDMI mini socket.

Here is my setup, testing both:

This is my modified test program. I have changed the PLL and set all the -ve signals to zero.

github.com

lawrie/hdmi_examples/blob/master/hdmi_test_mx/hdmitest.v

`default_nettype none // disable implicit definitions by Verilog
//-----------------------------------------------------------------
// minimalDVID_encoder.vhd : A quick and dirty DVI-D implementation
//
// Author: Mike Field <hamster@snap.net.nz>
//
// DVI-D uses TMDS as the 'on the wire' protocol, where each 8-bit
// value is mapped to one or two 10-bit symbols, depending on how
// many 1s or 0s have been sent. This makes it a DC balanced protocol,
// as a correctly implemented stream will have (almost) an equal
// number of 1s and 0s.
//
// Because of this implementation quite complex. By restricting the
// symbols to a subset of eight symbols, all of which having have
// five ones (and therefore five zeros) this complexity drops away
// leaving a simple implementation. Combined with a DDR register to
// send the symbols the complexity is kept very low.
//-----------------------------------------------------------------

module top(

This file has been truncated. show original

Am I doing something wrong? I have a shorter cable on order in case it is a problem with the sync, but it works with a long cable with the HDMI Pmod.

Here is my pcf file:

github.com

lawrie/hdmi_examples/blob/master/hdmi_test_mx/hdmi.pcf

set_io clk25 60 # Onboard 25Mhz oscillator

set_io hdmi_p[3] 41
set_io hdmi_p[0] 43
set_io hdmi_p[1] 45
set_io hdmi_p[2] 48 

set_io hdmi_n[3] 39
set_io hdmi_n[0] 42
set_io hdmi_n[1] 44
set_io hdmi_n[2] 47

This the PCF file that works with the HDMI Pmod:

github.com

lawrie/hdmi_examples/blob/master/hdmi_test_mx/hdmi_pmod.pcf

set_io clk25 60 # Onboard 25Mhz oscillator

set_io hdmi_p[3] 4
set_io hdmi_p[0] 3
set_io hdmi_p[1] 144
set_io hdmi_p[2] 143

set_io hdmi_n[3] 8
set_io hdmi_n[0] 7
set_io hdmi_n[1] 2
set_io hdmi_n[2] 1

The hdmi_n pins are not used by that, but I kept them so that I could use the exact same test program in both cases.

lawrie 2019-07-17 17:39:53 UTC #2

I realised that as the Mx HDMI connector has both the positive and negative LVDS outputs, I should be setting the _n output to the negation of the _p ouputs, not to 0, so I tried that.

But that isn't working either.

github.com

lawrie/hdmi_examples/blob/master/hdmi_test_mx/hdmitest.v

`default_nettype none // disable implicit definitions by Verilog
//-----------------------------------------------------------------
// minimalDVID_encoder.vhd : A quick and dirty DVI-D implementation
//
// Author: Mike Field <hamster@snap.net.nz>
//
// DVI-D uses TMDS as the 'on the wire' protocol, where each 8-bit
// value is mapped to one or two 10-bit symbols, depending on how
// many 1s or 0s have been sent. This makes it a DC balanced protocol,
// as a correctly implemented stream will have (almost) an equal
// number of 1s and 0s.
//
// Because of this implementation quite complex. By restricting the
// symbols to a subset of eight symbols, all of which having have
// five ones (and therefore five zeros) this complexity drops away
// leaving a simple implementation. Combined with a DDR register to
// send the symbols the complexity is kept very low.
//-----------------------------------------------------------------

module top(

This file has been truncated. show original

uXe 2019-07-18 01:12:48 UTC #3

...it's a shot in the dark, but maybe try swapping the output bits back around so that D_OUT_0 corresponds to bit 0 and D_OUT_1 corresponds to bit 1?? I know it works the way it is on the Pmod, but maybe it has something to do with the Pmod using single-ended outputs and the IceCore's connector using 'pseudo' differential outputs??

// clock -
defparam hdmin3.PIN_TYPE = 6'b010000;
defparam hdmin3.IO_STANDARD = "SB_LVCMOS";
SB_IO hdmin3 (
    .PACKAGE_PIN (hdmi_n[3]),
    .CLOCK_ENABLE (1'b1),
    .OUTPUT_CLK (clk_x5),
    .OUTPUT_ENABLE (1'b1),
    .D_OUT_0 (~clk_output_bits[1]),
    .D_OUT_1 (~clk_output_bits[0])
);
// D_OUT_0 and D_OUT_1 swapped?
// https://github.com/YosysHQ/yosys/issues/330

lawrie 2019-07-18 08:02:04 UTC #4

Thanks for the suggestion. I tried it, but it did not work.

electrified 2019-07-18 08:53:20 UTC #5

Have you seen @daveshah's ECP5 DVI example?

We don't have the ECP5 vendor DDR module, but the ULX3S has the HDMI connector wired up similarly (I think?)

It might work as a starting point...

Folknology 2019-07-18 09:03:50 UTC #6

Be careful with that link as it may contain ECP5 specific settings which will probably differ from the Ice40, although the theory is the same. I have asked @daveshah to take a look and come back on this thread with more specific IO settings advice etc..

daveshah 2019-07-18 09:05:16 UTC #7

The inversion, rather than setting the other side to zero, is definitely correct. I am not so sure about the D1/D0 swapping but it should definitely be the same as what works with the PMOD, the pseudo differential wouldn't affect this.

It might be that a pulldown is needed on HPD, this might be a monitor specific requirement though. This would need to be enabled in the STM32.

Folknology 2019-07-18 09:16:19 UTC #8

To change this go to the MX_GPIO_Init function in main.c, HDMI_HDP and ICE40_CDONE GPIOs share a config section:

/*Configure GPIO pins : HDMI_HPD_Pin ICE40_CDONE_Pin */
  GPIO_InitStruct.Pin = HDMI_HPD_Pin|ICE40_CDONE_Pin;
  GPIO_InitStruct.Mode = GPIO_MODE_INPUT;
  GPIO_InitStruct.Pull = GPIO_NOPULL;
  HAL_GPIO_Init(GPIOC, &GPIO_InitStruct);

replace this with the following separate configs for each:

/*Configure GPIO pin : HDMI_HPD_Pin */
  GPIO_InitStruct.Pin = HDMI_HPD_Pin;
  GPIO_InitStruct.Mode = GPIO_MODE_INPUT;
  GPIO_InitStruct.Pull = GPIO_PULLDOWN;
  HAL_GPIO_Init(HDMI_HPD_GPIO_Port, &GPIO_InitStruct);

  /*Configure GPIO pin : ICE40_CDONE_Pin */
  GPIO_InitStruct.Pin = ICE40_CDONE_Pin;
  GPIO_InitStruct.Mode = GPIO_MODE_INPUT;
  GPIO_InitStruct.Pull = GPIO_NOPULL;
  HAL_GPIO_Init(ICE40_CDONE_GPIO_Port, &GPIO_InitStruct);

BTW I just changed the code as accidentally included interupt GPIO settings on CDONE due to copy and paste from my experimental local branch, fixed now!

If this helps let me know, I will change it permanently in the newer firmware I'm working on this week..

Folknology 2019-07-18 10:39:26 UTC #9

Is this just arachne_pnr specififc, are you using next_pnr @lawrie?

lawrie 2019-07-18 10:55:43 UTC #10

I am mainly using nextpnr, but tried arachne_pnr to see if it made any difference.

I tried those SB_IO outputs both ways round without any luck.

I also tried reversing the positive and negative LVDS pins, but again with no luck. With The HDMI Pmod, it still works with the polarity reversed, but reverses the order of the colours.

Folknology 2019-07-18 10:58:11 UTC #11

Have you tried the HPD patch yet?

lawrie 2019-07-18 11:07:23 UTC #12

I did look at the ULX3S code and confirmed that it is doing the inversion of the LVDS pins similarly to how I am now doing it.

lawrie 2019-07-18 11:12:35 UTC #13

I tried it with three different monitors, both HDMI and DVI, all of which work with the HDMI Pmod. I get the best sync with the small HDMIPi device, designed for the Raspberry Pi.

I will try the HPD pulldown, but is that likely to affect a DVI monitor used with an HDMI to DVI adapter? (That combination worked with the HDMI Pmod, but the sync wasn't that good).

Folknology 2019-07-18 11:21:37 UTC #14

It's worth trying to eliminate this possible issue, I do not know what the HDMI Pmod does with the HPD signal, does it pull it down?

Also I need to know if I should pull this down by default in the firmware generally..

uXe 2019-07-18 11:46:29 UTC #15

Yes, the PTN3366 level-shifter has an "integrated 200 kΩ pull-down resistor on HPD sink". The only other difference I can see is that you have the connector's shield grounded - I had read so much conflicting information about this that I made grounding the connector shield optional with a solder jumper... looking at the ULX3S schematic I can't see it grounded there either?

lawrie 2019-07-18 11:50:59 UTC #16

I tried that iceboot change to pulldown HPD, but it made no difference.

lawrie 2019-07-18 12:22:14 UTC #17

The short cable I ordered has now arrived, but that made no difference either:

lawrie 2019-07-18 13:37:34 UTC #18

I have added an HDMI switch to my set up. When I plug in the cable from the HDMI Pmod, it switches the input and the light comes on next to that input on the switch. That doesn't happen with the HDMI mini socket, even with the iceboot patch, suggesting that HPD is not working still.

Folknology 2019-07-18 13:55:07 UTC #19

You should probably test the voltage level on the HPD pin, on mine here after the change it was definitely pulled down. It might be worth reading the HPD pin voltage with and without the cable plugged in.

lawrie 2019-07-18 15:09:22 UTC #20

I measured 0v on the HPD pin, but then I looked at the resistance across various pins. I am using an HDMI to DVI adapter to do that as it is easier to get at the pins. All of of DVI pins 19 (data 0 shield) , 22 (clock shield), 7 (DDC data) and 16 (HPD) appear to be shorted to ground. I don't get any of that with the Pmod.

I then looked at the HDMI connector and it looks like it has a solder bridge on it.