News:

Attention: For security reasons,please choose a user name *different* from your login name.
Also make sure to choose a secure password and change it regularly.

Main Menu

TE0726-04 ZynqBerry + zhdmi HDMI core issue

Started by zerkman, October 26, 2024, 09:25:19 PM

Previous topic - Next topic

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:
test-zynqberry.jpg

The correct image should be:
test-z7lite.png
(as captured from another board).

The demo project to obtain this display can be created as follows:
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.

# 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:
QuoteERROR: [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.

zerkman

It seems p and n physical pins can not be swapped in pin assignment or fpga logic since it's a physical constraint. Thus the p output of an OBUFDS can only be routed to a p output pin, and the n output must be routed to a n output pin. This means the only way to "invert back" the differential pair is to invert the OBUFDS input. But since it is connected to a OSERDES output, there is no routable way to place a LUT in between so I had to invert the OSERDES input.

I have updated the zhdmi code so the user can set up a INVERTED_TX generic bitfield that specifies which of the TMDS channels are inverted so the generated logic inverts the channel data again. See the ZynqBerry toplevel design of the zhdmi demo.