cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
tim_severance
Scholar
Scholar
2,254 Views
Registered: ‎03-03-2017

HDMI design copy/pasted now not working

Jump to solution

Hi,

   I have a custom hardware design using Kintex-7 / DP159 retimer where I have a fully working design in Vivado/SDK 2017.4.   I copy/pasted that design (using export/import block design TCL files) into a new project (also in Vivado 2017.4 and using the same custom hardware so same pins for all connections) where I have also added in circuitry in the block design for DisplayPort RX.

   I copy/pasted the SDK project from the working to the new project's SDK project and I cannot seem to get the TxStreamUp callback to ever get triggered.

   If I look at the XVphy_HdmiDebugInfo output in both the working and newer non-working design I get the output shown below.

 

hdmi_info_differences.png

 

   Does anybody know about the TX State = "CPLL lock" versus "ready" state?   When I look in the XVphy_HdmiDebugInfo function this means that InstancePtr->Quads[QuadId].Plls[XVPHY_CH2IDX(ChId)].TxState is XVPHY_GT_STATE_LOCK instead of XVPHY_GT_STATE_READY.   I am trying to understand what this means.

 

Thanks for any inputs, this has been driving me crazy for a week now.

 

Tim

0 Kudos
1 Solution

Accepted Solutions
tim_severance
Scholar
Scholar
2,477 Views
Registered: ‎03-03-2017

@xud,

   I found the issue finally today.

   My design that was not working with HDMI sourcing also contains circuitry in the block design for DisplayPort Rx and it turns out that the MMCM (TXPLL) setup code in bsp/proc_mblz/libsrc/vphy_v1_6/src/vphy.c (void XVphy_MmcmStart function) has an #ifdef checking for "#if defined (XPAR_XDP_0_DEVICE_ID)".   Once I forced this ifdef to assume there was no DpRx in the design then HDMI started working.

   My next step is to find a way to get the MMCM setup to work for both the HDMI TX and DpRx together.

 

Thanks.

Tim

View solution in original post

12 Replies
xud
Xilinx Employee
Xilinx Employee
2,207 Views
Registered: ‎08-02-2007

@tim_severance

 

I have seen this just now in one of my test. I will feedback this to the HDMI engineering team.

 

vtc_notready.JPG

 

I only see this during initialization. After TX stream is up, the VTC version can be reported correctly.

 

After CPLL is lock, GT TX will start reset sequence and TX phase alignment sequence. Before TX ready you should achieve reset and alignment is done, TX MMCM is locked.

tim_severance
Scholar
Scholar
2,200 Views
Registered: ‎03-03-2017

@xud,

   Yes, please let me know what you find out.

   Also, if you could be of any assistance on determining what the difference is in the GT Status "CPLL lock" versus "ready".

 

Thanks.

Tim

0 Kudos
xud
Xilinx Employee
Xilinx Employee
2,197 Views
Registered: ‎08-02-2007

@tim_severanceI just edited my previous reply, which contains explanation on the difference between CPLL lock and TX ready.

Do you always see VTC version issue or only see it at start-up? I want to double check if we encounter the same issue

0 Kudos
tim_severance
Scholar
Scholar
2,186 Views
Registered: ‎03-03-2017

@xud,

   I never get my TX stream up so I am not sure if the VTC updates once the stream is up.

   So you are saying my GTX has the MMCM locked, but the reset sequence is not started?   Do you have any directions on what needs to happen for this reset sequence to be initiated?

 

Thanks.

Tim

0 Kudos
xud
Xilinx Employee
Xilinx Employee
2,183 Views
Registered: ‎08-02-2007

@tim_severance

 

Please use API below to print out the events when it doesn't work :

XVphy_LogDisplay(&Vphy);

 

I will check what is missing.

0 Kudos
tim_severance
Scholar
Scholar
2,176 Views
Registered: ‎03-03-2017

@xud,

   See below for the log:

 

VPHY log
------
GT init start
GT init done
TX frequency event
TX frequency event
TX frequency event
TX timer event
TX MMCM reconfig done
CPLL reconfig done
GT TX reconfig start
GT TX reconfig done
CPLL lock
TX frequency event
CPLL lost lock
TX frequency event
TX timer event
TX MMCM reconfig done
CPLL reconfig done
GT TX reconfig start
GT TX reconfig done
CPLL lock

 

Thanks.

Tim

0 Kudos
tim_severance
Scholar
Scholar
2,170 Views
Registered: ‎03-03-2017

@xud,

   I suspect the MMCM is not locking (i.e. expect to see "TX MMCM lock" in vPhy log).

   I guess I do not understand what the MMCM is used for when the CPLLs are locked already?   In a working design I have the vPhy log has "TX MMCM lock" then "TX reset done" right after.   So I would probably get the reset started if the MMCM would lock.

   Any ideas?

Thanks.

Tim

0 Kudos
tim_severance
Scholar
Scholar
2,165 Views
Registered: ‎03-03-2017

@xud,

   Does this potentially have anything to do with the issue mentioned below?

 

https://www.xilinx.com/support/answers/35681.html

AR35681.png

 

Tim

0 Kudos
tim_severance
Scholar
Scholar
2,148 Views
Registered: ‎03-03-2017

Image below shows my setup from external ref-clk to GTx GTREFCLK and TXUSRCLK inputs.   This is the same in the working and non-working designs (the non-working design simply has more elements in addition to the HDMI).   In the non-working design the TXPLL does not lock, but the clock_detector block reads the correct frequency.   Is there code in the HDMI TX example design that is specifically used to setup the TXPLL?

 

hdmi_block.png

 

Thanks.

Tim

0 Kudos
tim_severance
Scholar
Scholar
2,478 Views
Registered: ‎03-03-2017

@xud,

   I found the issue finally today.

   My design that was not working with HDMI sourcing also contains circuitry in the block design for DisplayPort Rx and it turns out that the MMCM (TXPLL) setup code in bsp/proc_mblz/libsrc/vphy_v1_6/src/vphy.c (void XVphy_MmcmStart function) has an #ifdef checking for "#if defined (XPAR_XDP_0_DEVICE_ID)".   Once I forced this ifdef to assume there was no DpRx in the design then HDMI started working.

   My next step is to find a way to get the MMCM setup to work for both the HDMI TX and DpRx together.

 

Thanks.

Tim

View solution in original post

tim_severance
Scholar
Scholar
1,616 Views
Registered: ‎03-03-2017

@xud,

   FYI, I just upgraded my project to using 2018.1 and I noticed in the vphy.c file the updated version fixes the issue I was having.

 

vphy_1p7_fix.png

 

Tim

xud
Xilinx Employee
Xilinx Employee
1,603 Views
Registered: ‎08-02-2007

@tim_severance

 

Thanks for your information, you actually remind me. We do have a driver patch, which can be used for v2017.3 and v2017.4 version : https://www.xilinx.com/support/answers/70174.html

 

 

0 Kudos