cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
2,784 Views
Registered: ‎06-13-2012

HDMI TX interrutps and cpll related problems

Jump to solution

Hi all,

 

I'm working with Xilinx HDMI IP (Video PHY IP v2.2, HDMI IP v3.1) and Vivado 2018.1.

I followed the example design of Tx and Rx, to start my design I would like to try both subsystems working as loopback with VDMA buffering between receiver and transmitter (so no common clocks).
The receiver seems to work properly always, with all input formats up to 4K, not the same for the transmitter section.

Sometime when I plug the monitor to the HDMI output I see in the VPHY log the following:

 

TX frequency event
CPLL lost lock
TX frequency event

And nothing more, the output is not working or only the clock is present, than maybe if I unplug and plug the cable the transmitter start working.

In other cases, the Tx Stream never goes up

 

I can't find where the issue come from, I suspect that can be clock/PLL related, the external PLL that produces the reference clock is working properly.

 

I've another doubt, in the Video PHY controller v2.2 the DRP clock has a default value of 100MHz (pg230-vid-phy-controller page 84) and then in page 87 seems that it can be used also 50MHz or 150MHz even if in the IP block is poited out to use 100MHz.
I try change to 50MHz or 100MHz but same result.

Regards


0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
2,951 Views
Registered: ‎08-02-2007

@auricm

 

From your last thread, you can see "that after system reset the Video_rst is asserted, then is de-asserted " Does it occur on both case or only working case?

 

Also if you don't see MMCM re-config done, it seems the reference clock isn't stable yet. Can you hold tx_refclk_rdy a bit longer and then see if it makes any difference?

 

If you don't use LOL to control tx_refclk_rdy, the tx_refclk_rdy port MUST be toggled - Can be done through a GPIO

  1. De-asserted before change Video Format or before Clock Generator reconfiguration
  2. Asserted after Clock generator’s frequency output has stabilized

Can you probe with oscilloscope and just observe the time of clock chip stabilizes for different HDMI frequencies.. From slowest to 300 MHz, 10 us might not be enough.

View solution in original post

18 Replies
Highlighted
Xilinx Employee
Xilinx Employee
2,734 Views
Registered: ‎08-02-2007

@auricm

 

Firstly can you tell me how you drive the TX reference clock, and how you connect tx_refclk_rdy of Video PHY? If should be asserted only when TX reference clock is stable.

 

Normally CPLL lost lock means the reference clock isn't stable.

 

For DRP clock, normally it should be 100Mhz, but 50 Mhz should work too.

0 Kudos
Highlighted
Explorer
Explorer
2,728 Views
Registered: ‎06-13-2012

Hi xud,

 

I drive the Tx reference clock with AD9578 PLL, when I need to change the reference clock frequency I deassert the tx_refclk_rdy,  setup the new configuration of the external PLL and then I wait for about 10us before assert again the tx_refclk_rdy as I change only the output frequency divider.

Measuring with the oscilloscope I see that the external PLL il working properly and the reference seems stable to me, moreover after many test the CPLL lost lock happens only at the beginning of tx setup.

 

 

Regards

 

 

0 Kudos
Highlighted
Explorer
Explorer
2,661 Views
Registered: ‎06-13-2012

Hi,

 

any ideas?

As to start the stream I've to plug and unplug the the sink many times I think is related to some kind of reset

 

regards

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
2,649 Views
Registered: ‎08-02-2007

Hi @auricm

 

Sorry for the late response. I don't get notification unless you @ me.

 

I still feel there is something to do with tx_refclk_rdy. The slowest clock generator could take 15 seconds to lock.

 

I notice AD9578 provides loss of lock indication, please monitor Register 0x0F, Bit 21 (for PLL1) or Bit 23 (for PLL2), and ensure it's 1 before you assert tx_refclk_rdy

 

Once it's confirmed, and if you still see the issue, please provide all the Video PHY register dump, we can have more ideas on what's wrong.

Explorer
Explorer
2,627 Views
Registered: ‎06-13-2012

Hi @xud,

 

AD9578 PLL are always lock, when I change the ref. clock I use the output divider so I don't touch the PLL settings, I just toggle the tx_refclk_rdy to signal the change of frequency to HDMI/VPHY IP.

Here's the log

 

TX Connected ch 0
RX stream is down ch 0
TX stream is up ch 0
RX connected ch 0
RxStreamInitCallback ch 0
RX stream is up ch 0
Color Format: RGB
Color Depth: 8
Pixels Per Clock: 4
Mode: Progressive
Frame Rate: 60Hz
Resolution: 1920x1080@60Hz
Pixel Clock: 148500000
Enable colorbar
TX stream is down ch 0
TX stream is up ch 0


------------
HDMI RX SubSystem
------------

->HDMI RX Subsystem Cores
: HDMI RX
HDMI RX version : 03.00 (0400)

HDMI RX Mode - HDMI
------------
HDMI RX timing
------------
Color Format: RGB
Color Depth: 8
Pixels Per Clock: 4
Mode: Progressive
Frame Rate: 60Hz
Resolution: 1920x1080@60Hz
Pixel Clock: 148500000

HSYNC Timing: hav=1920, hfp=88, hsw=44(hsp=1), hbp=148, htot=2200

VSYNC Timing: vav=1080, vfp=04, vsw=05(vsp=1), vbp=036, vtot=1125

VIC: 16
Scrambled: 0
Link quality
---------
Link quality channel 0 : excellent (0)
Link quality channel 1 : excellent (0)
Link quality channel 2 : excellent (0)
Audio
---------
Format : Unknown
Channels : 2
ACR CTS : 0
ACR N : 0
Infoframe
---------
RX header: 2D040181

-----

------------
HDMI TX SubSystem
------------

->HDMI TX Subsystem Cores
: HDMI TX
: VTC Core
HDMI TX version : 03.00 (0401)
VTC version : 06.01 (000B)

HDMI TX timing
------------
HDMI TX Mode - HDMI
HDMI Video Mask is Disabled

Color Format: RGB
Color Depth: 8
Pixels Per Clock: 4
Mode: Progressive
Frame Rate: 60Hz
Resolution: 1920x1080@60Hz
Pixel Clock: 148500000

HSYNC Timing: hav=1920, hfp=88, hsw=44(hsp=1), hbp=148, htot=2200

VSYNC Timing: vav=1080, vfp=04, vsw=05(vsp=1), vbp=036, vtot=1125

Scrambled: 0
Sample rate: 1

Audio
---------
Format : L-PCM
Channels : 0
HDMI PHY
GT status
RX reference clock frequency: 148514816 Hz
VPHY 0 status
TX: CPLL
RX: QPLL0
TX state: ready
RX state: ready

QPLL0 settings
-------------
M : 1 - N : 80 - D : 8

CPLL settings
-------------
M : 1 - N1 : 5 - N2 : 4 - D : 4

RX MMCM settings
-------------
Mult : 8 - Div : 1 - Clk0Div : 32 - Clk1Div : 8 - Clk2Div : 32

TX MMCM settings
-------------
Mult : 8 - Div : 1 - Clk0Div : 32 - Clk1Div : 8 - Clk2Div : 32

 

VPHY log
------
GT init start
GT init done
TX frequency event
TX timer event
CPLL reconfig done
GT TX reconfig start
GT TX reconfig done
CPLL lock
TX reset done
TX alignment done
RX frequency event
RX timer event
RX DRU disable
QPLL reconfig done
GT RX reconfig start
GT RX reconfig done
QPLL lock
RX reset done
RX MMCM reconfig done
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
TX reset done
TX alignment done

 


But the HDMI TX IP module don't assert the locked output.

If other logs are required just let me know

 

Regards

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
2,615 Views
Registered: ‎08-02-2007

@auricm

 

Thanks for posting the Video PHY log. From the log file that you can get CPLL lock, GT reset done and phase alignment done, the reference clock should be okay.

 

But TX subsystem lock is not asserted. Can you capture the video_rst (of video native interface) to ILA, please? You should be able to find it in synthesized design. I want to check if HDMI TX is still in reset stage or the issue is to do with the video timing.

 

Please also post the HDMI TX event log.

0 Kudos
Highlighted
Explorer
Explorer
2,604 Views
Registered: ‎06-13-2012

Hi @xud,

 

With the ILA I see that the video_rst is asserted during startup and then it goes low when I plug the sink, here I paste the HDMI TX log:


TX Connected ch 1
RX stream is down ch 1
RX stream is down ch 1
TX stream is down ch 1
TX stream is up ch 1
RX connected ch 1
RxStreamInitCallback ch 1
RX stream is up ch 1
Color Format: RGB
Color Depth: 8
Pixels Per Clock: 4
Mode: Progressive
Frame Rate: 60Hz
Resolution: 1920x1080@60Hz
Pixel Clock: 148500000
Enable colorbar
TX stream is down ch 1
------------
HDMI RX SubSystem
------------

->HDMI RX Subsystem Cores
: HDMI RX
HDMI RX version : 03.00 (0400)

HDMI RX Mode - HDMI
------------
HDMI RX timing
------------
Color Format: RGB
Color Depth: 8
Pixels Per Clock: 4
Mode: Progressive
Frame Rate: 60Hz
Resolution: 1920x1080@60Hz
Pixel Clock: 148500000

HSYNC Timing: hav=1920, hfp=88, hsw=44(hsp=1), hbp=148, htot=2200

VSYNC Timing: vav=1080, vfp=04, vsw=05(vsp=1), vbp=036, vtot=1125

VIC: 16
Scrambled: 0
Link quality
---------
Link quality channel 0 : excellent (0)
Link quality channel 1 : excellent (0)
Link quality channel 2 : excellent (0)
Audio
---------
Format : Unknown
Channels : 2
ACR CTS : 0
ACR N : 0
Infoframe
---------
RX header: 2D040181

-----

------------
HDMI TX SubSystem
------------

->HDMI TX Subsystem Cores
: HDMI TX
: VTC Core
HDMI TX version : 03.00 (0401)
VTC version is not available for reading as HDMI TX Video Clock is not ready.

HDMI TX timing
------------
HDMI TX Mode - HDMI
HDMI Video Mask is Disabled

Color Format: RGB
Color Depth: 8
Pixels Per Clock: 4
Mode: Progressive
Frame Rate: 60Hz
Resolution: 1920x1080@60Hz
Pixel Clock: 148500000

HSYNC Timing: hav=1920, hfp=88, hsw=44(hsp=1), hbp=148, htot=2200

VSYNC Timing: vav=1080, vfp=04, vsw=05(vsp=1), vbp=036, vtot=1125

Scrambled: 0
Sample rate: 0

Audio
---------
Format : L-PCM
Channels : 0
HDMI PHY
GT status
RX reference clock frequency: 148514816 Hz
VPHY 0 status
TX: CPLL
RX: QPLL0
TX state: ready
RX state: ready

QPLL0 settings
-------------
M : 1 - N : 80 - D : 8

CPLL settings
-------------
M : 1 - N1 : 5 - N2 : 4 - D : 4

RX MMCM settings
-------------
Mult : 8 - Div : 1 - Clk0Div : 32 - Clk1Div : 8 - Clk2Div : 32

TX MMCM settings

-------------
Mult : 8 - Div : 1 - Clk0Div : 32 - Clk1Div : 8 - Clk2Div : 32



VPHY log
------
GT init start
GT init done
CPLL lock
TX reset done
TX alignment done
TX frequency event
CPLL lost lock
TX timer event
CPLL reconfig done
GT TX reconfig start
GT TX reconfig done
CPLL lock
TX reset done
TX alignment done
RX frequency event
RX timer event
RX DRU disable
QPLL reconfig done
GT RX reconfig start
GT RX reconfig done
QPLL lock
RX reset done
RX MMCM reconfig done
CPLL lost lock

 

HDMI TX log
------
Initializing HDMI TX core....
Initializing VTC core....
Reset HDMI TX Subsystem....
TX cable is connected....
TX Stream is Down
TX Stream is Up
TX cable is toggled....
TX Stream Start
TX Set Stream
TX Stream is Down

 

 

The TREADY signal of the HDMI TX il always low.

 

Regards

 

0 Kudos
Highlighted
Explorer
Explorer
2,591 Views
Registered: ‎06-13-2012

@xud,

 

after the log above I tried unplug the sink and the video_rst keep low, after plug and unplug a few times the video_rst went high and then low and after that the Tx started working

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
2,584 Views
Registered: ‎08-02-2007

@auricm

 

I think the TX cable connect interrupt isn't triggered. Once it's triggered, the video_rst should be toggled.

 

How do you connect HPD? What's the HPD polarity settings? 

0 Kudos
Highlighted
Explorer
Explorer
2,634 Views
Registered: ‎06-13-2012

@xud,

 

the HPD is active low as I used an inverter to shift the input to a FPGA compatible IO voltage.

 

The setting in the HDMI IP is "active low", I've also set a filter to avoid glitch during the plug and unplug operation, the plug and unplug is recognized as I see in the log "TX Connected ch 1" EVERY time i plug and "Tx Disconnected" when I unplug.

 

0 Kudos
Highlighted
Explorer
Explorer
2,599 Views
Registered: ‎06-13-2012

Hi@xud

 

in file xv_hdmitxss.c I found the XV_HdmiTxSs_ConnectCallback function, as I understand that function is called when a TX connect event occurred, I expect that when I disconnect the sink the video reset must be asserted.

Actually I see that the function is called correctly every time i connect or disconnect the sink but the video reset is not always asserted when I disconnect the sink.

I'm wrong or there's a particular reason?

 

regards

 

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
2,589 Views
Registered: ‎08-02-2007

@auricm

 

Following APIs are related to HPD :

XV_HDMITXSS_HANDLER_CONNECT

XV_HDMITXSS_HANDLER_TOGGLE

 

TX connect event seems to be fine. Toggle doesn't

 

Video_rst should occur when TX Stream is down, when there is no stable video_clk. I will need to do some tests with our example design, and then let you know at which exact stage video_rst is asserted.

 

HDMI TX log
------
Initializing HDMI TX core....
Initializing VTC core....
Reset HDMI TX Subsystem....
TX cable is connected....
TX Stream is Down
TX Stream is Up
TX cable is toggled....
TX Stream Start
TX Set Stream
TX Stream is Down

 

The expected TX event should be

HDMI TX log

------

Initializing HDMI TX core....

Initializing VTC core....

Reset HDMI TX Subsystem....

TX cable is connected....

TX Stream is Down

TX Set Stream, with TMDS (32)

TX Audio Unmuted

TX Stream is Up

 

 

There are some problems in your TX logs:

1. Why TX Stream is Up coming right after TX stream is down, before setting the TX Stream?

2. TX cable is toggled after TX Stream is Up, can you check how it was toggled?

 

If possible, can you try our example design (generation instructions can be seen in Chapter 5 of PG235)? Please also refer to Figure D3: TX Flow of PG235

0 Kudos
Highlighted
Explorer
Explorer
2,577 Views
Registered: ‎06-13-2012

@xud

 

1. Why TX Stream is Up coming right after TX stream is down, before setting the TX Stream?

I don't know, the video stream is active but Tx system has TREADY low, I check with ila.

2. TX cable is toggled after TX Stream is Up, can you check how it was toggled?

I don't know how to do it

 

 

I try again with the demo code of example desing, same behavior as mine (mine is just a customization of xilinx example microblaze code).
Here's the log obtained with the example design

 

VPHY log

------
GT init start
GT init done
TX frequency event
TX timer event
CPLL reconfig done
GT TX reconfig start
GT TX reconfig done
CPLL lock
TX reset done
TX alignment done
CPLL lost lock
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 reset done
TX alignment done

 


HDMI TX log
------
Initializing HDMI TX core....
Initializing VTC core....
Reset HDMI TX Subsystem....
TX cable is connected....
TX Audio Muted
TX Stream is Up
TX Set Stream, with TMDS (32)
TX Stream is Down
TX Audio Muted
TX Stream is Up
TX Set Stream, with TMDS (32)

 

After this log no signal coming from the output connector, just unplug and plug again and start working properly

 

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
2,539 Views
Registered: ‎08-02-2007

@auricm

 

When you see "TX cable is toggled", it means the HPD is toggled, can you monitor HPD in ILA, and use Step by step to debug the software code, and double check if HPD toggles when TX cable is toggled is printed out?

 

We need to ensure there is no problem with HPD. If HPD indeed toggles unexpectedly, can you provide IPI tcl file (by using write_bd_tcl test.tcl) or take a snapshot, so I will check how HPD is connected in your real design?

 

Please also print out the TX log after you can make it working, after unplug/plug, so we can compare the working log and non-working log.

 

Also I don't see MMCM lock in your Video PHY log,  I want to check in the working case if it's printed out or not.

 

HDMI TX Video_rst should be asserted during VphyHdmiTxInitCallback, you can also use debug mode, and step into this API, and see if Video_rst is asserted or not. 

Highlighted
Explorer
Explorer
2,526 Views
Registered: ‎06-13-2012

@xud

 

I found the toggle was due to my anti-glitch filter, as i fixed it the result is the same without toggle event, here's the log when working and not working.

 

Log when working

 

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

 

HDMI TX log
------
Initializing HDMI TX core....
Initializing VTC core....
Reset HDMI TX Subsystem....
TX cable is connected....
TX Stream is Up
TX Set Stream
TX Stream Start


When not working

 

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


HDMI TX log
------
Initializing HDMI TX core....
Initializing VTC core....
Reset HDMI TX Subsystem....
TX cable is connected....
TX Set Stream

 

OR

 

VPHY log
------
TX frequency event

 

HDMI TX log
------
TX cable is connected....

 

 

As you pointed out, in the not working log the MMCM reconfig is missing

 

In debug mode step by step I see that after system reset the Video_rst is asserted, then is de-asserted.
When I reach the VphyHdmiTxInitCallback, the function just call the XV_HdmiTxSs_RefClockChangeInit function

void XV_HdmiTxSs_RefClockChangeInit(XV_HdmiTxSs *InstancePtr)
{
/* Assert VID_IN bridge resets */
XV_HdmiTxSs_SYSRST(InstancePtr, TRUE);
XV_HdmiTxSs_VRST(InstancePtr, TRUE);

/* Assert HDMI TXCore resets */
XV_HdmiTxSs_TXCore_LRST(InstancePtr, TRUE); 
XV_HdmiTxSs_TXCore_VRST(InstancePtr, TRUE); 

/* Clear variables */
XV_HdmiTx_Clear(InstancePtr->HdmiTxPtr);
}

 

Video_rst is never asserted with that function

 

 

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
2,952 Views
Registered: ‎08-02-2007

@auricm

 

From your last thread, you can see "that after system reset the Video_rst is asserted, then is de-asserted " Does it occur on both case or only working case?

 

Also if you don't see MMCM re-config done, it seems the reference clock isn't stable yet. Can you hold tx_refclk_rdy a bit longer and then see if it makes any difference?

 

If you don't use LOL to control tx_refclk_rdy, the tx_refclk_rdy port MUST be toggled - Can be done through a GPIO

  1. De-asserted before change Video Format or before Clock Generator reconfiguration
  2. Asserted after Clock generator’s frequency output has stabilized

Can you probe with oscilloscope and just observe the time of clock chip stabilizes for different HDMI frequencies.. From slowest to 300 MHz, 10 us might not be enough.

View solution in original post

Highlighted
Explorer
Explorer
2,437 Views
Registered: ‎06-13-2012

@xud

 

Video_rst is asserted, then is de-asserted, it occurs in both cases.

 

First I hold tx_ready_port low for a longer time but without success, actually to solve I toggle the tx_ready_port periodically until the Stream is up and seems to work.

 

Thank you for your support

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

Hi @auricm,

 

As you system is now working thanks to one of @xud 's answers, could you kindly close the topic by marking the best reply from her?

 

Thanks and Regards,


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos