08-04-2020 04:13 AM - edited 08-04-2020 04:16 AM
I have used the VCU TRD example projects adapted for an Enclustra XCZU5EV SoM on an Enclustra Carrier board. I have been able to get single and multi-channel SDI video working (SDI ingest to VCU to UDP encoded output stream); however, we are currently having SDI video quality issues.
We currently experience very tiny horizontal tearing in the video at 1080p25 and it gets worse at 1080p50. I have been debugging it for months now and used many forum suggestions. However, a lot of our findings seem to be pointing to compatibility issues with the UHD-SDI Core. I have followed the GT debug procedure, IBERT eyescan, signal integrity checks. GT QPLL Locks are stable.I have performed tests as described in the forum post:link and detailed below:
I generated a UHD-SDI-TX and UHD-SDI-RX pipeline project in Vivado(2019.2 and 2020.1) based on VCU TRD and tested in the following configurations-
The following were observations from the above configurations:
- Tektronix WFM 8300 generated test signal source
- Dream Chip ATOM one mini SDI camera
- Marshall SDI Camera
- ATMOS SHOGUN INFERNO Atom HDR SDI source
All of the above showed the same video distortion issue of the tiny horizontal lines in the video.
The only known good configuration is when Xilinx's UHD-SDI TX is looped back to the UHD-SDI RX core on the SAME board. This further confirms that signal integrity and GT are not the culprit as I had previously suspected. It leads me to think that there is a compatibility issue with Xilinx SDI implementations of the SMPTE standards as the same video signal that displays properly in looped back mode shows exactly same distortion when connected to a Tektronix SDI analyser or another board with UHD-SDI RX that has a different REF CLOCK generator. I am unsure if there is any other changes we are required to make as not much else can be changed in the IP Cores ....or if the VCU TRD has explicitly been configured to work when both the TX and RX are on the same PL.
Please can anyone help with ideas on fixing this issue?
I have attached images to show the distortion in the video.
08-06-2020 09:23 AM
Hello @badegoke_f1 ,
Have You tried out to use our Bare metal example designs at Your end. If not, could You please do it. Because, it will helps us to know whether is it SDI issue or the VCU TRD Issue.
So, Kindly first test the pass through example designs addressed in PG290, and kindly share the results with us.
08-07-2020 02:40 AM
I am currently setting up a bare-metal example project as requested in 2020.1. Although I am getting some errors when generating the example pass through project for the UHDSDI IP. I will post result updates shortly once I get this up and running. I intend to test it with the same SDI sources I had previously used.
08-10-2020 09:35 AM
Hi @ashokkum ,
Are you okay with using just the SDI-Rx only standalone example?
I cannot seem to get the Pass-Through Standalone example to work in 2020.1. This is because my Enclustra board has the IBUFGTE I/Os for the quad connected to external clock generators. This means I cannot implement the clock TX out to the external jitter attenuator like the ZCU106 and receive a low jitter input on the IBUFGTE buffer instantiated in the example for the looped-back low jitter clock input. I tried looping back the clock internally(to exclude the jitter attenuator IC on the ZCU106 in the pass-through example top level), the project build keeps failing because the IBUFGTE can only inputs from an IO pad.
Will just Rx-Only be enough to validate if the issue is TRD or IP?
08-11-2020 04:47 AM
Hello @badegoke_f1 ,
I don't think so, It really helps us or not. Because, as far as I noticed from Your posts, that the Output video displaying on the monitor had some discrepancy. Means, most probably the TX path creating some issues. That might be a jitter issue also.
RX Only example design will help us in detecting the input Video Stream, Data Rate and Kind of Video Only. It won't give any more detailed Information about the Video data display Issues.
Let me check Internally, If we have any other options to check this.
08-11-2020 05:19 AM
Thanks @ashokkum ,
I will wait on your confirmation. Can modifying the top level of the pass through example suffice? That is: I use an external Silab Clock generator on my board to generate 2 clocks for the respective GTREF BUFGTE's clock inputs. However, the example top level wrapper uses rx_usrclk and rx_ce muxed with some ODDRE1 and OBUFDS instances to drive a clock out for the ZCU106. Can this be eliminated with the above modification?
08-12-2020 10:00 AM
I have been able to run the Pass-Through Example with modifications to the GT clock inputs, I also commented out parts in the firmware that setup the zcu106 I2C clocks as I already have this setup on my board.
I have used a Silabs quad clock generator(SI5338B) to supply two 148.5Mhz inputs to the respective IBUF_GTE's. I also changed the GT IP QPLL0 Ref Clock from SOUTHREFCLK1 to GTREFCLK0 to match my board. I have attached an image of the GT Core settings in the zipped folder.
I have an Atom One Mini SDI camera connected to a Tektronix WFM8300 to validate the signal I am connecting to the uhdsdi-Rx section. This signal is passed through from the WFM8300 to the uhdsi-Rx inputs. I have done 2 sets of tests and captured screenshots for each resolution(1080p25 and 1080p50). I have avoided fractional rated because I have my clock generators fixed at 148.5MHz.
If the IP is incorrectly detecting the resolution intermittently... this would explain why I get distorted horizontal images. Kindly see the images and status of the SDI signal used in the zipped images. I have attached all the information for the tests also in the folder.
Vivado Version 2020.1
Thanks for your time
08-13-2020 08:02 AM
Hello @badegoke_f1 ,
Glad to hear that, You are able to run the example design at Your end.
I gone through the logs and noticed that, CRC errors (0X58) are existed in the incoming video. So, Please check once again with Your source. It would be great If You can try out with some other sources also.
Because, I noticed there were lot of issues I noticed from the logs, For example Please go through the (0x00) register of SDI RX Subsystem, SDI RX bridge and Video IN AXI4S was not enabled. Where as the same were enabled for SDI TX Sub System and You can observe this at (0x00) register of SDI TX Sub System.
So, Please try to check these issues and try to test Your Source by connecting to any of SDI Analyzer (ex: Omnitek, Phabrix, etc..) to know that the source is able to transmit the video without CRC errors.
Also, If possible use oscilloscope to check the reference clock frequency, Which are going to QPLL0 and QPLL1 for exact 148.5Mhz.
Hope this Information is helpful to You.
09-10-2020 03:18 AM - edited 09-10-2020 03:18 AM
Dear @ashokkum ,
Many thanks for your patience. I ran and debugged the adapted standalone with the points you had suggested.
1. Both GTH clock are rock solid at 148.5MHz
2. I verified the data signal eye is open
3. I verified that the SDI source was not generating errors on an SDI analyser. I have not used omnitek or Phabrix as I cannot get access o these devices.
I ran the standalone debug application in SDK and I still noticed intermittent loss of lock in the terminal display. I probed the QPLL Lock status: I see QPLL0 is locked and and QPLL1 unlocks intermittently. Following your recommendation, I then checked the address 0x00 in the SDI_Rx subsystem I also noticed that the rx_vid_Bridge and Vid_in_axi4s subcore registers are not enabled when I halt the debug window in Vitis. Address 0x00 is always 0x01 when the debug session is halted. I forced it to 0x301 and yet ...on the next halt the uhd-Sid Rx system(hidden) disables these subcores again.
I then used the same GT wizard Tx/Rx standalone example configuration with 148.5MHz GTH refclk0 and 1 in Petalinux VCU TRD SDI-Rx/Tx. QPLL lock 0 and 1 are locked on their individual 148.5MHz ref clock inputs. When I stream I video, I still get the horizontal image line distortion with no loss of frames.
Are you okay for me to archive both projects and send to you? I cannot see any thing else I can change when the clocks and data are okay. I do not understand how the v_smpte_uhdsdi_rx enables the other sub cores as it is hidden.
I have basically hit a brick wall. Any suggestion will help.