cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
2,880 Views
Registered: ‎01-09-2018

UHD SDI GT IP in multilane cases

I am trying to implement a MULTI-LINK SDI solution using the latest UHD SDT GT IP, in a Zynq MPSOC 7EV. I have Vivado 2018.1 My issues:

1. There is no product guide for this IP. When will one be available? Why was the IP offered without one?

2. Inside the IP GUI, there appear to be typos. See attachment. Are they typos or is this the way the IP really is? Please fix!

3. The UHD SDI GT has an input port, cmp_gt_ctrl[63:0]. I NEED DETAILED port descriptions here!!!! I tried to use this IP in a multi duplex lane design with the compact_gt_ctrl code from your SDI RX subsys example design but the implemetation failed in the optdesign phase. It said stuff was optimised away that left some logic inputs floating. I took a look at the compact_gt_ctrl code and I saw it while it declares the output as a 64 bit word, only 23 of the bits are assigned. And the example design was only 1 lane. I need 2 duplex lanes. How should the other bits in the output of compact_gt_ctrl be assigned for multi lane cases? (the IP did, however, implement successfully with this code in a single lane case).

4. The inputs of the compact_gt block seem to be for when something called a "FMC" is done initialising, and for when a clock cleaner loses lock? Since I am NOT using this in a loopback, and with a Semtech reclocker in front of the RX, I do not need a clock cleaner. I am also using a fixed XCO as the GTH ref clk so there is nothing to init. Can I eliminate the compact GT ctrl entirely? IF so tell me how to tie off the cmp_gt_ctrl[63:0] inputs on the IP, or provide a user guide!!!

5. Finally, an observation: The SDI IP seems to be less well maintained than other video connectivity IP, such as HDMI, DP, or MIPI. It is less turnkey and the documentation is lacking compared to the others. Why is that? What you guys really need to do is bring the UHD SDI GT IP up to the same level of support, turnkeyness and documentation as you have for the video PHY Controller (which I am also using for HDMI).

I have submitted SRs regarding this, but have so far not gotten responses to all my questions, so I thought I'd throw it out to the forum and see if anyone has any similar experiences.

Screenshot (25).png
0 Kudos
12 Replies
Highlighted
Explorer
Explorer
2,874 Views
Registered: ‎08-31-2016

Hi @bmoore

 

Yes, there's isn't a proper separate UG/PG for UHD SDI GT IP. You'll find some information here in the appendix 

https://www.xilinx.com/support/documentation/ip_documentation/v_smpte_uhdsdi_rx_ss/v2_0/pg290-v-smpte-uhdsdi-rx-ss.pdf 

 

Yeah, That looks like a typo. Its for PLL1.

 

Also, You may need to take care and manually update compact_gt_ctrl as required for your multilink design.

 

Regards,

Vinay

 

 

 

Vinay Shenoy
0 Kudos
Highlighted
Moderator
Moderator
2,851 Views
Registered: ‎11-09-2015

Hi @bmoore,

 

1. There is no product guide for this IP. When will one be available? Why was the IP offered without one?

> This IP is an helper core. It is just intended to help users to use the UHD-Subsystem. As per @vinay_shenoy's reply, the only docuementation is (and will be) PG290.

 

2. Inside the IP GUI, there appear to be typos. See attachment. Are they typos or is this the way the IP really is? Please fix!

> I believe this was reported and will be fixed in a future version but this is bnot critical

 

3. The UHD SDI GT has an input port, cmp_gt_ctrl[63:0]. I NEED DETAILED port descriptions here!!!! I tried to use this IP in a multi duplex lane design with the compact_gt_ctrl code from your SDI RX subsys example design but the implemetation failed in the optdesign phase. It said stuff was optimised away that left some logic inputs floating. I took a look at the compact_gt_ctrl code and I saw it while it declares the output as a 64 bit word, only 23 of the bits are assigned. And the example design was only 1 lane. I need 2 duplex lanes. How should the other bits in the output of compact_gt_ctrl be assigned for multi lane cases? (the IP did, however, implement successfully with this code in a single lane case).

> I have already reported this. The documentation for cmp_gt_ctrl will be added to a future version of the documentation. If you need to understand it, note that all the HDL is available and not-encrypted

 

4. The inputs of the compact_gt block seem to be for when something called a "FMC" is done initialising, and for when a clock cleaner loses lock? Since I am NOT using this in a loopback, and with a Semtech reclocker in front of the RX, I do not need a clock cleaner. I am also using a fixed XCO as the GTH ref clk so there is nothing to init. Can I eliminate the compact GT ctrl entirely? IF so tell me how to tie off the cmp_gt_ctrl[63:0] inputs on the IP, or provide a user guide!!!

> You might want to consider also controlling the GT for you specific application using the UHD-SDI_gt HDL as reference. You might want to discuss this with your FAE

 

5. Finally, an observation: The SDI IP seems to be less well maintained than other video connectivity IP, such as HDMI, DP, or MIPI. It is less turnkey and the documentation is lacking compared to the others. Why is that? What you guys really need to do is bring the UHD SDI GT IP up to the same level of support, turnkeyness and documentation as you have for the video PHY Controller (which I am also using for HDMI).

I have submitted SRs regarding this, but have so far not gotten responses to all my questions, so I thought I'd throw it out to the forum and see if anyone has any similar experiences.

The UHD-SDI subsystem and the UHD-SDI_gt (unlike the UHD-SDI core) are new IPs while the DP and HDMI (+ Video Phy) are matured IPs. The stability will come with the time. Note that the UHD-SDI Subsystem and UHD-SDI_gt are marked as pre-production.

Note that initlally, the UHD-SDI_gt was not meant to be released (only hidden to be used in the example design). It was decided a bit late (to try to help users), to be made availble publicly. But because it was late, not all the use cases have been tested (unlike the UHD-SDI Subsystem). We are working on it.

 

I recommend you to discuss with your FAE about your concerns about this. It could get in touch with us and we can see if actions can be taken.

 

Regards,


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
Highlighted
Contributor
Contributor
2,790 Views
Registered: ‎01-09-2018

Folks, since I saw that the compact_gt_ctrl.v code had bits 23:63 unassigned, I assigned them to all 0's and re-implemented. Success this time in that it implemented OK, but will it work? Who knows? It will be months before we are able to get a PCB made to try it. What do the upper 41 bits in cmp_gt_control[63:0] do? The example design is utterly useless to me because it is a single link, where, I suppose, those bits don't do anything, and it didn't matter that they were optimised away. However, in the multilink case, they seem to go SOMEWHERE, because it wouldn't implemet unless I tied them off to valid levels. But are those levels correct?  Again I say, I need a detailed port description of cmp_gt_ctrl[63:0] of the UHDSDI_GT!!!!  I can't confidently modify the compact gt code unless I have this.

 

Sorry I can't give "kudos" because my issue isn't solved. It's a shame because this IP would have allowed me to have multiple SDI links in a quad. Now I have to use external Semtech serdes and set aside pins on the FPGA for parallel pixel ports. 

 

0 Kudos
Highlighted
Moderator
Moderator
2,787 Views
Registered: ‎11-09-2015

HI @bmoore,

 

Did you discussed with your FAE about this?


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
Highlighted
Explorer
Explorer
2,654 Views
Registered: ‎08-31-2016

Hi @florentw,

 

Looking out for some good solutions on the SDI multi-link concerns as pointed out by @bmoore .

I am too facing similar hinderance while working with SDI multi-link. I believe these concerns should be addressed at the earliest.

Even though there's no much available documentations on UHDSDI_GT, Xilinx folks should be able to address these queries regards to compact_gt_ctrl.v and multi-link SDI GT applications.

 

I request you to take this matter to the concerned folks in the community.

 

Also, I'll put up a new thread on my issue soon

 

Regards,

Vinay Shenoy

 

 

Vinay Shenoy
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
2,581 Views
Registered: ‎12-02-2009

following bit positions of cmp_gt_ctrl are used inside uhdsdi_gt_v1_0 IP:

bit 0 : qpll0 reset

bit 2: qpll1 reset

for link0:

bit14: txusrclk is available

bit15: rxusrclk is available 

for link 1:

bit26: txusrclk is available

bit27: rxusrclk is available 

for link 2:

bit38: txusrclk is available

bit39: rxusrclk is available 

for link 3:

bit50: txusrclk is available

bit51: rxusrclk is available 

 

Since it RTL is not encrypted, these ports are not documented.

 

In Xilinx UHD-SDI example designs, FMC initialization is used to reset the QPLL0 which is connected to RX SDI. QPLL1 is reset once it it receives LOOSSOFSYNC and QPLL1 connected to TX SDI. Based on your system requirement, connect the QPLL0 & QPLL1 resets. Refer respective transceiver user guide (UG576 & UG578) on sceneries QPLL needs an reset. Hope this helps.

Can you provide details about your multi-lane use case? is it all duplex links or RX-Only links?

 

Apart from cmp_gt_ctrl, are you facing any issues with uhdsdi_gt_v1_0 core?

Highlighted
Explorer
Explorer
2,528 Views
Registered: ‎08-31-2016

Hi @kka
I am actually implementing 3 SDI links in my design. I've used the ZCU106 SDI pass through example design having single link for reference.

I've got a custom board targeting a 7EV device with one SFP connector (SDI RX & TX) and two SDI BNC connectors ( 2 SDI TX). Connected in following manner,

SDI Link 0 - SDI RX & SDI TX 1 (From SFP Connector)

SDI Link 1 - SDI TX 2

SDI Link 2 - SDI TX 3

Intention here is to design a 3G SDI system. A single reference clock 148.5 MHz from a clock synthesizer will be given to SDI RX & TX paths. QPLL1 is used throughout. Please refer attached screenshots of GT GUI customization. Also, I don't use FMC in my design.

1) What should be my inputs to the uhdsdi_gt_ctrl RTL module now? ie., What value I have to provide to fmc_init_done and SI5324_LOL signals?

2) What is the significance of SI5324_LOL_DB signal? Is it necessary in my case?

3) How should the other bits in the output of compact_gt_ctrl[63:0] be used for multi lane cases?

I believe as you've pointed out in earlier post, only qpll0/1 reset, rxuserclk is avalable and txuserclk is available signals are actually needed and taken out from uhdsdi_gt_ctrl.v

4) How should I generate and give rxuserclk is avalable and txuserclk is available signals for other SDI links?


Please let me know your inputs

 

Thanks,

Vinay

Vinay Shenoy
1.PNG
2.PNG
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
2,505 Views
Registered: ‎12-02-2009

You are using QPLL1 for both TX & RX. May i know your system receives 12-G SDI and/or transmits fractional SDI line rates? If so, you need to use QPLL0 as well along with QPLL1.

 

Based on the screenshots posted, here are my responses:

1. You need to generate reset for QPLL1 and connect to cmp_gt_ctrl[2]. since, QPLL0 is not used, assign 1'b0 for cmp_gt_ctrl[0].

2. Ignore SI5324_LOL_DB signal.

3. (a) you need to generate signal that indicates QPLL1 reference clock is stable & connect that signal to following bits of cmp_gt_ctrl bus:

bit 14, 15, 26, 27, 38 & 39. 

3. (b) assign rest of other bits of cmp_gt_ctrl bus to 1'b0;

4. rxusrclk/txusrclk availability is based on system. I'll explain how it is generated it on ZCU106 system. for input clock to QPLL0 comes from FMC. So, when FMC is initialized, we know that clock is generated from FMC and feed as input to QPLL0. This is the reason, we take fmc_init_done as rxclk availability. In case of QPLL1, SI5324 chip is generating the clock. SI5324 has an output (SI5324_LOL) that gets asserted when input clock to SI5324 chip is stopped or no input clock. Based on SI5324_LOL, it is decided that clock is stable or not.

 

So, it is purely based on your system. For example, if you are generating with external PLL chip, that chip might have LOCK signal and you can use that LOCK signal for txclk/rxclk availability/stability.

 

Hope this helps. 

Highlighted
Explorer
Explorer
2,462 Views
Registered: ‎08-31-2016

Hi @kka

 

Thank you for a detailed response. I'm greatly obliged.

 

I will follow the things as per your suggestions in my design.

 

Since I don't have any SDI source, I am planning to generate a video pattern of 1920x1080p resolution and send that across the 3G SDI TX system. This 3G SDI information will be looped back and received across 3G SDI RX system. You see I have a SFP connector for his. I've got a 148.5 MHz of clock to use as SDI reference clock. Hence I am planning to go with integral line rates.

 

I'd learnt that I need an extra clock of 148.35 MHz to be used for fractional line rates. Also need to use QPLL0 as well as per your input.

 

I'd love to hear more on the use and importance of 3G SDI fractional line rates. When will inclusion of support for 3G SDI fractional line rates in design become useful?

 

Thanks,

Vinay 

 

 

 

 

Vinay Shenoy
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
2,004 Views
Registered: ‎12-02-2009

Fractional line rates requirement depends on which resolution & frame rate your system receives or transmits. 

Do you have list of resolutions that your system or end product needs to be supported?

 

Refer XAPP1248 (Ultrascale based) for more information on integer and fractional line rates.

0 Kudos
Highlighted
Explorer
Explorer
1,994 Views
Registered: ‎08-31-2016

Hi @kka

 

I am planning to add support for 1920x1080p (60Hz & 30Hz) and 1280x720p (60Hz & 30Hz). All integral line rates.

 

The ZCU106 SDI example design has SDI RX/TX GUI configurations set for 12G SDI. Will this support my required resolutions? 

or Do I need to change this settings to 3G SDI to support HD & Full HD resolutions?

 

Regards,

Vinay 

Vinay Shenoy
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
1,988 Views
Registered: ‎12-02-2009

Yes, 12G-SDI supports all resolutions you mentioned; But, 3G-SDI should be enough in your case.

12G-SDI supports all SDI standards including SD-SDI, HD-SDI, 3G -SDI Level A, 3G-SDI Level B, 6G-SDI