cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
625 Views
Registered: ‎06-18-2019

UHD-SDI IP Core Compatibility Problem

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:

Test :

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-

  1. UHD-SDI-TX looped back externally with SMA cables to the UHD-SDI-RX
  2. Several SDI sources connected as inputs to UHD-SDI RX(Please see list of sources below)
  3. Connected UHD-SDI-TX to a Tektronix WFM800 SDI Waveform/Image analyser.
  4. UHD-SDI-TX(Board 1) connected externally with SMA cables to the UHD-SDI-RX(Board 2)


The following were observations from the above configurations:

  1. Using "modetest" and "gstreamer test source" to drive the SDI-TX looped back to the RX. All image and video patterns sent by the SDI-TX and received by the SDI-RX were able to be encoded by the VCU, streamed, and displayed without any error or image distortion.
  2. The following SDI sources were connected to the SDI-RX :

    - 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.

  3. On connecting UHD-SDI TX to a Tektronix WFM8300(Industry standard SDI test equipment), the test equipment displays "Filed Length Err" and "Line Length Err" from the Xilinx's UHD-SDI TX generated video signal using "modetest" and "gst-launch-1.0 videotestsrc…". The image distortion seen on WFM8300 is exactly like that we get when we connect an external SDI video source (the ones listed above) to the UHD-SDI RX IP.
  4. I have used the same Petalinux UHD-SDI-RX/TX project running on two separate boards, one as a transmitter and the other as a receiver. With gst and modetest we get the same distortion.

Conclusion:
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.

 

Thanks 
Bade

 

CAM1080p50_TO_WFM8300.JPEG
CAM1080p50_TO_UHDSDIRX.JPEG
WFM800_1080p50_To_uhdsdiRXviaVLC.JPG
WFM800_1080p25_To_uhdsdiRXviaVLC.JPG
UHDSDI-TX_Loopback_UHDSDI-RX.JPG
uhdsdiTX_1080p50_To_WFM800.JPG
0 Kudos
10 Replies
Highlighted
Moderator
Moderator
507 Views
Registered: ‎04-09-2019

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.

With Regards,

Ashok. 

Highlighted
Contributor
Contributor
463 Views
Registered: ‎06-18-2019

Thanks Ashok,
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. 

Regards
Bade

Highlighted
Contributor
Contributor
409 Views
Registered: ‎06-18-2019

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?

Many thanks

Bade

0 Kudos
Highlighted
Moderator
Moderator
381 Views
Registered: ‎04-09-2019

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.

With Regards,

Ashok.

Highlighted
Contributor
Contributor
368 Views
Registered: ‎06-18-2019

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?

Thanks

Bade

0 Kudos
Highlighted
Contributor
Contributor
336 Views
Registered: ‎06-18-2019

Hi @ashokkum,

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.

My setup:
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.

Observations:

  • I can see in the terminal printouts for both tests that there is an intermittent loss of lock being displayed. 
  • Even though the resolution and frame rates are fixed going to the uhdsdi-Rx, it constantly and intermittently reports wrong video resolutions and wrong video format different from what the WFM displays. There is a delay used in the firmware source which, I think reduces the frequency of the status reports to the terminal.
  • Observing the uhdsdi-tx signal on a scope, one can clearly see the effect of the Rx section changing format and resolution.

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
Device: xczu5ev-sfvc784-2-i


Thanks for your time
Bade

 

Highlighted
Moderator
Moderator
309 Views
Registered: ‎04-09-2019

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.

With Regards,

Ashok.

Highlighted
Moderator
Moderator
213 Views
Registered: ‎04-09-2019

Hello @badegoke_f1 ,

Do I have any update regarding this case.

Awaiting for Your reply.

With Regards,

Ashok.

Highlighted
Contributor
Contributor
208 Views
Registered: ‎06-18-2019

Hi @ashokkum ,

I will update shortly. Currently testing and debugging. 
Many thanks for checking in

 

Regards

Bade

Highlighted
Contributor
Contributor
83 Views
Registered: ‎06-18-2019

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.

Thanks

Bade

 

0 Kudos