We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Showing results for 
Search instead for 
Did you mean: 
Observer tmiller
Registered: ‎10-24-2017

SDI GT TX Clock not locking

I am trying to implement an FPGA SDI system, with 1 TX channel and 1 RX channel. I've instantiated the SDI RX and TX subsystems, and connected them to a UHD-SDI GT block. I've attached the tcl source file for the block design. The SDI GT block is set up so that SDI link 1 should carry the SDI TX using QPLL1.

When the system starts, I see that inf_0_rxoutclk of the UHD-SDI-GT block starts running, however intf_1_txoutclk stays idle. I am sure that a 148.5 MHz reference is being provided to the intf_0_qpll0_refclk_in pin. The value of cmp_gt_sts is 0x1210243, which indicates to me that both QPLLs have locked, but that the CPLL LOCK and RESETDONE bits remain unset.

Should I expect these bits to assert if everything is configured correctly, and what can be done to diagnose the problem?


Tags (3)
0 Kudos
5 Replies
Xilinx Employee
Xilinx Employee
Registered: ‎03-30-2016

Re: SDI GT TX Clock not locking

Hello @tmiller 

Just giving some inputs:

1. Both RXRESETDONE / TXRESETDONE should be asserted
2. Please check UHD-SDI GT GUI setting of your design.
    If you are using CPLL and CPLLLOCKED is not asserted, perhaps the input refclk is not correct.
    If you are using QPLL, please ignore CPLLLOCK status since your QPLLLOCK is already asserted.
3. both RX/TXRESETDONE is not asserted, so probably some issue on clocking or reset.
    Some signals to check
    Did you supply the correct clock frequency for drpclk_in input ?
    Did you apply the reset sequence correctly ?

Thanks & regards

Observer tmiller
Registered: ‎10-24-2017

Re: SDI GT TX Clock not locking

Hello Leo,

Thank you for the response. drpclk_in is correct at 100 MHz. Where is the correct reset sequence documented?

0 Kudos
Xilinx Employee
Xilinx Employee
Registered: ‎03-30-2016

Re: SDI GT TX Clock not locking

Hello tmiller @tmiller 

- UHD-SDI Subsystem docs (PG290/PG289 Chapter 3) mentioned about IP reset.
Please see also PG290 Appendix B (or PG289 Appendix D) for some hints on generals check.
Such as to ensure that the clocks are stable before initialization.

- Perhaps generating Example Design can be a good start point for you.
In our Example design all signal reset are controlled from Zynq.
Examples program can be found in

Example Design using this API fuctions are used to initialize Video subsystem.

Thanks & regards

Registered: ‎11-09-2015

Re: SDI GT TX Clock not locking

Hi @tmiller ,

Do you have any update on this? Was @karnanl 's replies enough for you?

If your question is answered or your issue is solved, please kindly mark the response which helped as solution (click on "Accept as solution" button below the reply)

If this is not solved/answered, please reply in the topic giving more information on your current status.

Thanks and Regards,

Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
Observer tmiller
Registered: ‎10-24-2017

Re: SDI GT TX Clock not locking

So, we were able to resolve the issue with the TX clock not locking. We were deasserting the QPLL power down bits of cmp_gt_ctrl (see table C-2 of PG290) simultaneously with the QPLL reset bits. Adding a short delay between these two steps fixed the problems we were seeing with the TX clock. We are now able to succesfully transmit a test pattern to an SDI receiver. We have also moved to using the uhdsdi_gt_ctrl module to control the SDI GT block, as in the example design.

Unfortunately we still have SDI related problems, now related to the RX block. When feeding in a known good SDI signal, either from the SDI TX block or from a signal generator, the block does not succesfully lock on to the signal. That is, we are not receiving the Stream Up callback, and bit 3 of the MODE_DET_STS register does not assert. If we force the receiver into a particular mode via the MODULE_CTRL register, we receive garbage data from the output of the RX subsystem. The data passing between the GT and RX block is also garbage.

I've been trying to get the SDI pass through functioning on a ZCU106 board we purchased. This has also had a lot of problems, although these are not related to the SDI itself, see https://forums.xilinx.com/t5/Evaluation-Boards/ZCU106-stalls-when-running-SDI-RX-Example-Design/m-p/971122#M22121

Below is a dump of all the registers in the RX subsystem after setup by the driver, with a known good 3G signal input:

0x00: 0x00000001
0x04: 0x00003F70
0x08: 0x00000000
0x0c: 0x00000001
0x10: 0x00000000
0x14: 0x00000603
0x18: 0x00000000
0x1c: 0x00000000
0x20: 0x00000000
0x24: 0x00000000
0x28: 0x00000000
0x2c: 0x00000000
0x30: 0x00000000
0x34: 0x00000000
0x38: 0x00000000
0x3c: 0x02000000
0x40: 0x00000002
0x44: 0x00000010
0x48: 0x000000F0
0x4c: 0x00080000
0x50: 0x00000000
0x54: 0x00000000
0x58: 0x15E4FFFF
0x5c: 0x00003000
0x60: 0x030000BD
0x64: 0x00000000
0x68: 0x00000000
0x6c: 0x00000000
0x70: 0x00000000
0x74: 0x00000000
0x78: 0x00000000
0x7c: 0x00000000
0x80: 0x00000000
0x84: 0x00000000
0x88: 0x00000000
0x8c: 0x00000000

0 Kudos