cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
shahan.a
Participant
Participant
543 Views
Registered: ‎06-25-2019

HDMI IP vsync interrupt is getting triggered always

Jump to solution

Hi all,

We are working on a design with the HDMI TX subsystem. When we run modetest the HDMI TX  asserts v_sync interrupt continuously. What could be the reason for this? In the HDMI TX IP product guide(pg235) the description for Vsync interrupt is as given below:

Vertical Sync – This is to reflect the change of HDMI TX sub-core vsync input signal in its video interface bus.

To make sure the length of v_sync signals are the same we checked the length of 2 adjacent v_sync signals in ILA and it seemed to be the same every time we checked.

What could be the possible reason for this? And what is the solution for this?

0 Kudos
1 Solution

Accepted Solutions
shahan.a
Participant
Participant
229 Views
Registered: ‎06-25-2019

Hi,

As a result of some complications, I couldn't modify the design and use framebuffer_write IP. We were not able to view the output because there was a schematic issue and a layout issue in the custom board. Once these were corrected we received output even though the v_sync interrupt was getting triggered continuously.

Thanks @ashokkum for your support

View solution in original post

0 Kudos
6 Replies
ashokkum
Moderator
Moderator
488 Views
Registered: ‎04-09-2019

Hello @shahan.a ,

If you have are working with any of our evolution kits used in our example design section, Can you run our TX only bare metal example design and confirm, whether are you able to see the color bar video successfully. This test will confirm to us, Whether the TX pipeline is good at your end or not?

With Regards,

Ashok.

0 Kudos
shahan.a
Participant
Participant
445 Views
Registered: ‎06-25-2019

Hi @ashokkum ,

We are working with a custom board. Previously we had brought up the HDMI TX path successfully using the Avnet Evaluation kit(AES-ZU7EV-1-SK-G). I had cross-checked the design multiple times with the design we brought up, they were similar and I couldn't find any difference that could cause this problem. The HDMI TX Subsystem is configured with AXI Stream interface with 12 bits per component and 4 Pixels per clock. A VDMA feeds data to the input of the HDMI TX Subsystem. The VDMA MM2S AXI Stream data width is configured to be 96.

I checked the AXIS to Video bridge within the HDMI TX subsystem and it was getting locked.

0 Kudos
ashokkum
Moderator
Moderator
382 Views
Registered: ‎04-09-2019

Hi @shahan.a ,

Hope you are working with YUV4:2:2 color format. Please confirm. Could you please let me know the following details,

1. Resolution you are looking for?

2. Vivado build version?

3. Hope this is linux application, Please confirm?

4. Are you able to see any video on the output display?

5. The xilinx FPGA part number that you are using at your end for this application?

6. A small block diagram that can give a picture of your video pipeline?

7. What is the state of LOL and Tx_refclk_rdy ports?

please help me to know the above details. these details will help us to debug this issue furtherly.

With Regards,

Ashok.

0 Kudos
shahan.a
Participant
Participant
375 Views
Registered: ‎06-25-2019

Hi @ashokkum,

Yes, the colour format is 4:2:2.

1. Resolution you are looking for?

We were testing for 4k@60. But we need the HDMI TX to output in multiple resolutions(4k@60,4k@50, 2k@60,  2k@50, etc)

2. Vivado build version?

Vivado 2019.2

3. Hope this is linux application, Please confirm?

Using petalinux 2019.2, with Xilinx HDMI-tx Linux driver, using the mode setting utility to set the display mode and thereby the VTC get programmed with the timing values from the driver.

4. Are you able to see any video on the output display?

No, we are not seeing any output. We are testing a custom board with an HDMI splitter. We are not sure if no video at output display is because of above said Vsync related issue or splitter chip related hardware issue.

5. The Xilinx FPGA part number that you are using at your end for this application?

xczu7ev-fbvb900-1

6. A small block diagram that can give a picture of your video pipeline?

I will share a picture of the block design after checking with the project lead. We are only testing the HDMI TX path now. HDMI TX path only has HDMI TX Subsystem, Video PHY controller, (and AXI to IIC as CTL IIC of DP159 chip). The AXI Stream Slave input of the HDMI TX is connected to the VDMA MAXIS MM2S port. The Data width of the AXI Stream is 96. HDMI TX and Video PHY controller is configured with Max bits per component = 12 and Pixels per clock = 4. The clock frequency of the AXI Stream is 150MHz. I don't see any problem in the AXI Stream path. The data from VDMA seems to reach HDMI TX input.

7. What is the state of LOL and Tx_refclk_rdy ports?

We are not using the LOL from the clock synthesizer, rather we use a register bit to assert the tx_refclk_rdy signal.

0 Kudos
ashokkum
Moderator
Moderator
335 Views
Registered: ‎04-09-2019

Hi @shahan.a ,

Thank you for the response.

I would recommend you to use the frame buffer read IP, instead of VDMA. Because, the linux drivers of this IP were very old and the IP was in maintenance mode. Also, we didn't validated our HDMI IP's with VDMA IP.

FYI, we have an example design for HDMI framebuffer combination. Please go through this link to get the design and driver details. So, kindly use frame buffer read IP in your pipeline and test the design again at your end.

Still, if you are unable to see the output video, then please share me the below logs,

1. Modetest utility log

2. VTC register dump 

Post this logs, I will look into the details and will try to find the root cause for the issue.

With Regards,

Ashok.

0 Kudos
shahan.a
Participant
Participant
230 Views
Registered: ‎06-25-2019

Hi,

As a result of some complications, I couldn't modify the design and use framebuffer_write IP. We were not able to view the output because there was a schematic issue and a layout issue in the custom board. Once these were corrected we received output even though the v_sync interrupt was getting triggered continuously.

Thanks @ashokkum for your support

View solution in original post

0 Kudos