07-01-2020 11:54 PM
Hello Xilinx Community members,
We are facing the compatibility issue of DVI-D (Original 1.0 DVI video data without Info frames) with Xilinx Video Phy Controller and HDMI-Rx-Subsystem.
Our target board is a xzcu4ev board with a tmds181 retimer chip on it. Our goal is to receive the DVI-D Single Link video data of fixed (1024x768 with 60fps) Resolution and stream it on ethernet after encoding it with H264 in Xilinx VCU. The baseline here is the HDMI-RX part of Xilinx VCU trd 2019.1
We came to know from our previous issue here :https://forums.xilinx.com/t5/Video-and-Audio/HDMI-RX-Subsystem-Compatibility-with-True-DVI-1-0-Source/m-p/1121401#M32954 that the HDMI-RX-Subsystem IP core only streams up (shows link in media-ctl) when either it gets a HDMI1.4/2.0 input or a modified DVI-D input with info frames (Nvidia GTX3000 graphic card) and it doesnt show the link with a DVI1.0 source (ZC702 with ADV7511 in DVI mode or old DVi graphics card such as Nvidia quadro k600 ). The Xilinx Video Phy Controller however gets locked and shows correct logs and debug information.
After reviewing the application notes (XAPP460, XAPP495) for Spartan 3 and Spartan 6 architecture respectively, we came to know that Xilinx have done and prepared example DVI-Receivers and DVI transmitters.
Our customers DVI source is 10 years old Spartan 3 FPGA with SiI 164 DVI Transmitter chip having max 1.6Gbps capability of Serial TMDS lanes With no HPD and EDID information (According to our tests, the missing hpd and edid is not the source of this problem as with the HDMI or modified DVI-D with info frames source, the HDMI-RX-Subsystem shows a link with Cable detect constant '1' and DDC lanes disconnected in the FPGA design). The recieving part has to be implemented on Ultrascale+ architecture (zcu4ev in our case). The dvi reciever lanes on the Ultrascale+ custom board are bound to transciever pins /Quads so we cannot use select I/O's as used in above mentioned Xilinx applications notes.
We are now taking the approach of Using this Video Phy Controller to Configure the Ultrascale+ transcievers in HDMI Reciever with out NI-DRU mode and use the DVI 10b/8b tmds decoder from XAPP460 or XAPP 495 to process the Deserialized and CDR data we get in AXI4S form from Video Phy Controller.
Our Questions are:
1) Is this approach feasible to address the HDMI-RX-Subsystems Compatibiliy with Origional DVI1.0 Digital Single Link source?
2) On our Understanding from Video Phy Controller 2.2 product guide, this core Configures the Ultrascale+ transcievers and does the Clock Data Recovery when the NI-DRU option is not selected. It means it Deserialises the incoming TMDS encoded Serial data, apply the CDR and gives us the data in AXI4S format with either 2 or 4 pixels per clock and it doesnt not insert any additional symbols or bitslips from its side. Is our Understanding Correct here?
3) When Selected 2 pixels per clock. Are We expecting the mapping as tdata[0:9] belongs to first pixel and tdata[10:19] to second pixel deserialised data?
4) If there is any other more feasible and less time consuming approach for DVI 1.0 receiver implementation in Ultrascale+ architecture or using HDMI-RX-Subsystem for DVI1.0 source, it will be very helpful as our project is blocker because of this incompatibility of HDMI-RX-Subsystem with a True DVI1.0-D source.
07-22-2020 08:14 AM
I have been working offline with Abdullah.
It turns out the issue is related to Vsync, and Hsync timing generated by VTC in ZC702 board.
If Abdullah uses analog ZC702 design, it works fine.