TE0726-04 ZynqBerry + zhdmi HDMI core issue

[zerkman]

Hello,

I've been lent a newly purchased TE0726, rev. 04 ZynqBerry board. I am trying to run my open source zhdmi HDMI transmitter core on it.

The problem is that I haven't been able to have the zhdmi demo running properly. It seems the output is incorrect HDMI, with the blue component getting the same levels as the red component. The audio is not playing correctly: the expected 440 Hz sine wave can be heard, but with many crackles.

My HDMI capture device does not recognise the signal, so I had to take a picture of the screen:


The correct image should be:

(as captured from another board).

The demo project to obtain this display can be created as follows:

Code Select Expand

git clone https://github.com/zerkman/zhdmi
cd zhdmi/demo/vivado
VIVADO=/opt/Xilinx/Vivado/2024.1/bin/vivado ./create_project.sh zhdmi_demo_zynqberry
Of course, use the real path to your installed copy of Vivado.
I used Vivado 2024.1, but it should also work with other versions.

I believe I used the proper pin assignment constraints, as borrowed from one of the TE0726 demos.

Am I doing something wrong? Could someone try and tell me if they can reproduce the issue?

[zerkman]

After further investigation, it appears the hdmi_tx_d_p

• and hdmi_tx_d_n
• output ports (blue component) are physically swapped.

I worked around the issue by inverting the input data bits for the TMDS serialiser of the blue component, and now I'm getting correct image and sound. No idea if it can easily be fixed on the Xilinx HDMI IP core.

Is it a known issue on the TE0726? Maybe only on revision 4?

[zerkman]

Sorry I meant hdmi_tx_d_p[ 0 ] and and hdmi_tx_d_n[ 0 ] are swapped.

[RC]

Hi,

The Swap is for the optimal PCB routing. Otherwise,the routing would be complicated. Could you modify the XDC file and manually assign all the pins(n and p)? It might be a simpler workaround.

[zerkman]

I rewrote the HDMI constraints as follows, specifying all n and p pins.
From the schematic I also noticed the clock p and n pins are swapped, but I'm leaving the original order for now.
I only swapped the d_p[ 0 ] and d_n[ 0 ] as instructed.

Code Select Expand

# HDMI
set_property IOSTANDARD TMDS_33 [get_ports {hdmi_tx_clk_p hdmi_tx_clk_n}]
set_property PACKAGE_PIN R7 [get_ports hdmi_tx_clk_p]
set_property PACKAGE_PIN R8 [get_ports hdmi_tx_clk_n]

set_property IOSTANDARD TMDS_33 [get_ports {hdmi_tx_d_p[*] hdmi_tx_d_n[*]}]
set_property PACKAGE_PIN P9 [get_ports {hdmi_tx_d_p[0]}]
set_property PACKAGE_PIN P8 [get_ports {hdmi_tx_d_n[0]}]
set_property PACKAGE_PIN P10 [get_ports {hdmi_tx_d_p[1]}]
set_property PACKAGE_PIN R10 [get_ports {hdmi_tx_d_n[1]}]
set_property PACKAGE_PIN P11 [get_ports {hdmi_tx_d_p[2]}]
set_property PACKAGE_PIN R11 [get_ports {hdmi_tx_d_n[2]}]

Now, Vivado produces this error on write_bitstream:

ERROR: [DRC UCIO-1] Unconstrained Logical Port: 2 out of 43 logical ports have no user assigned specific location constraint (LOC). This may cause I/O contention or incompatibility with the board power or connectivity affecting performance, signal integrity or in extreme cases cause damage to the device or the components to which it is connected. To correct this violation, specify all pin locations. This design will fail to generate a bitstream unless all logical ports have a user specified site LOC constraint defined.  To allow bitstream creation with unspecified pin locations (not recommended), use this command: set_property SEVERITY {Warning} [get_drc_checks UCIO-1].  NOTE: When using the Vivado Runs infrastructure (e.g. launch_runs Tcl command), add this command to a .tcl file and add that file as a pre-hook for write_bitstream step for the implementation run.  Problem ports: hdmi_tx_d_p[0], and hdmi_tx_d_n[0].

Please note that I also previously got the same error when trying to swap the n and p in the top level design. Similarly I got errors when trying to invert (NOT operator) the output values of d_p[ 0 ] and d_n[ 0 ].

I could set the SEVERITY to Warning as explained in the error message, but I assume my problem is not about unspecified pin locations (they are set correctly in the xdc) so I would not want to do something dangerous.

As explained above the clock p and n bits also seem to be swapped; if I swap the R7/R8 pin assignments in the xdc, this results in 4 port assigment issues (the previous ones plus the clock p and n ports) instead of 2.