04-16-2019 08:26 AM
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?
04-17-2019 08:55 PM
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
04-24-2019 05:00 AM
Thank you for the response. drpclk_in is correct at 100 MHz. Where is the correct reset sequence documented?
04-25-2019 02:57 AM
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
04-30-2019 03:12 AM
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,
05-10-2019 03:04 AM
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: