cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
badegoke_f1
Adventurer
Adventurer
1,274 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
17 Replies
ashokkum
Moderator
Moderator
1,156 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. 

badegoke_f1
Adventurer
Adventurer
1,112 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

badegoke_f1
Adventurer
Adventurer
1,058 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
ashokkum
Moderator
Moderator
1,030 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.

badegoke_f1
Adventurer
Adventurer
1,017 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
badegoke_f1
Adventurer
Adventurer
985 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

 

ashokkum
Moderator
Moderator
958 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.

ashokkum
Moderator
Moderator
862 Views
Registered: ‎04-09-2019

Hello @badegoke_f1 ,

Do I have any update regarding this case.

Awaiting for Your reply.

With Regards,

Ashok.

badegoke_f1
Adventurer
Adventurer
857 Views
Registered: ‎06-18-2019

Hi @ashokkum ,

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

 

Regards

Bade

badegoke_f1
Adventurer
Adventurer
732 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
ashokkum
Moderator
Moderator
645 Views
Registered: ‎04-09-2019

Hello @badegoke_f1 ,

Could you please share the register space details of the design. So, that I will try to check about the ST352 payload and other control signal details related to your source and sub system IP.

Yes, if you did this test on our evolution board, then I would be happy to go through your design.

Kind Regards.

Ashok.

0 Kudos
badegoke_f1
Adventurer
Adventurer
586 Views
Registered: ‎06-18-2019

Dear @ashokkum

Please see the register map for the  SDI-RX and SDI-TX at 1920 1080p50.  I am not sure if Video-in-AXI4S core and Bridge are disabled when I halt the program. I still get loss of lock intermittently in the terminal.

 

badegoke_f1_0-1601910098993.png

badegoke_f1_1-1601910156127.png

 

Many thanks
Bade

0 Kudos
ashokkum
Moderator
Moderator
551 Views
Registered: ‎04-09-2019

Hello @badegoke_f1 ,

Many Thanks, I will check those details and will let you know furtherly, If I need anything.

Kind Regards,

Ashok.

ashokkum
Moderator
Moderator
517 Views
Registered: ‎04-09-2019

Hello @badegoke_f1 ,

Please go through the below observations,

1. 0x74 The ST 352 payload ID packet data bytes captured from data stream 2 (C stream of data channel 0), is '0' there is no payload for this data stream. kindly check with your source once.
2. 0x58 RX CRC Errors for DS1, DS2, DS3 and DS4. Hope the source is not generating proper CRC, If possible could you please check with any other source at your end.
3. 0x48 please check the rx_t_locked in your design. make sure this signal should be '1' once the input video get locked.
4. 0x00 bit 8 & 9 are still '0'. i.e. those two bridges were not enabled.

In bare metal application, if you are design requires only integer frame rates, kindly use QPPL0 for both TX and RX paths. You can avoid using of QPLL1 for the design. So, that we can avoid the intermittent lock issues on QPLL1.

I will go through the TX registers and will let you know the details very soon.

Hope the above information is helpful to you.

kind Regards,

Ashok.

badegoke_f1
Adventurer
Adventurer
458 Views
Registered: ‎06-18-2019

Thanks @ashokkum ,

I will check it and get back to you. Thanks 

0 Kudos
badegoke_f1
Adventurer
Adventurer
408 Views
Registered: ‎06-18-2019

Dear @ashokkum ,
I have done some more tests with a 1920x1080p50 3GA camera on my design as suggested and find some things strange which I will elaborate on after responding to your suggestions below:

1. 0x74 The ST 352 payload ID packet data bytes captured from data stream 2 (C stream of data channel 0), is '0' there is no payload for this data stream. kindly check with your source once.

I checked the video source by passing it though a Tektronix WFM 8300 before connecting it to my design. Please see "verified_smpte_data.jpg" in the attached debug pack. The 352M Payload is shown as okay.

2. 0x58 RX CRC Errors for DS1, DS2, DS3 and DS4. Hope the source is not generating proper CRC, If possible could you please check with any other source at your end.

I passed it through the WFM again and all CRC's are okay. See "verified_smpte_data.jpg" in the attached debug pack . This passthrough device displays a crisp image. I constantly probed the uhdsdirx registers while streaming and also logged the register values. I can clearly see RX_CRC_ERR_DS1 and RX_CRC_ERR_DS2 in RX_CRC_ERR Register(0x58) changing. I also used an ILA in the fabric to probe the signals(rx_ds1, rx_ds2, rx_ds3, rx_ds4, rx_trs, rx_eav etc) shown in PG205 page 43. I can also clearly see rx_ds1 and rx_ds2 data. I have saved ILA data(ila_wfm_1080p50_data.ila) if you can kindly check the details and I also captured the waveform image(ila_wfm_1080p50_image.JPG). I cannot find information on how the CRC on the datastreams are calculated to verify the crc error points in the captured ILA data. 
It definitely seems the IP is not getting the correct CRC from the descrambled GT data. I changed GTREF clock to only QPLL0 and the GT qpll locks are rock solid. I also probed the rx_outclk generated clock from the GT. it is correct at 148.5MHz, tx_outclk is at 74.25MHz. See "verified_uhdsdirx_rxout_clk.jpg" in the debug data pack.

3. 0x48 please check the rx_t_locked in your design. make sure this signal should be '1' once the input video get locked.

I get video not locked error randomly even when the GT qplls and clocks are all okay. This could be a consequence of the intermittent CRC errors from the uhdsdirx IP. If I have to stream the video in Linux I have to reduce the lock window with "yavta --no-query -w '0x0098ca02 0' /dev/v4l-subdev0" for it to stream.

 

4. 0x00 bit 8 & 9 are still '0'. i.e. those two bridges were not enabled.

Bits 8 and 9 ae enabled as shown in the register 0x00 readout as 0x301

 

Other observations are :

RX_ST352_VALID Register(0x18) has a value of 0x103 referring to the logged uhdsdirx registers. This indicates that DS1,DS2 and DS3 are valid. PG205 page 43 suggests only 2 data streams for 3GA. This is different from what the IL captures as I can clearly see data on only 2 streams.

 

TS_DET_STS Register(0x48) sometimes changes from 0x903 to 0xF0 which indicates Rx_T_Family change from SMPTE ST 295(1920x1080) to UNKNOWN and RX_T_RATE from 50fps to NONE.

 

I am hoping the ILA data provides a pointer to the root cause of the CRC errors. 

Many thanks 
Bade

0 Kudos
ashokkum
Moderator
Moderator
362 Views
Registered: ‎04-09-2019

Hello @badegoke_f1 ,

Thank you for sharing the details. I will go through them thoroughly and will get back to you soon.

Kind Regards,

Ashok.

0 Kudos