Zybo HDMI in example project

[michaelcrapse]

I have successfully compiled, flashed, and ran the hdmi in example project in the digilent github repo. However, no matter the hdmi source I use, I cannot get the hdmi to connect to the Zybo dev board. The CRT monitor is displaying the VGA output, and I can change resolution and frame buffers. However, I always get an !HDMI unplugged! error on the uart output. My windows machine recognizes the "monitor" and I can change the resolutions on the windows side of things, but no matter the resolution I cannot get the connection to go through. See attached screenshot. This is very frustrating for me. Any help would be appreciated. This is the 3rd or 4th tutorial/example I have tried since getting the board today. All in all everything has gone smoothly up to this point, but I have not the fpga/vivado experience to determine the issue. also my log output from vivado is attached.

implementation.txt

[brycecrapse]

Hello Again,

In contrast the following Demo did work, purely as a filter mind you, but with the same monitor, hdmi cables, Mac Laptop etc... 

Honestly I am quite new to all this so I am not sure why and I was unable to look into the code.  But... If the Mac, Board, HDMI Cables, and Monitor work here then it is probably something I did not do for this

Zybo HDMI in example project

-

 

Demo that worked is here:

Quick Start Test Demo: Zybo (Xilinx Zynq 7000) Image Filtering Demo

-

http://www.instructables.com/id/Quick-Start-Test-Demo-Zybo-Xlinx-Zynq-7000-Image-F/

 

[Michal]

Hi @JColvin,

sorry for a long delay. I was just checking my previous projects and i have realised I left you without the answer.
Well - yes, it helped, your solution worked perfectly.

Thank you 

[JColvin]

Hi @Michal,

I apologize for the delay.

I haven't gotten to look into the 2016.4 version of this project specifically, but I worked with another Digilent engineer and we were able to fix this for the Zybo Z7-20 HDMI project and when I compared the files in question, the fix should be the same.

To fix the "HDMI Unplugged!" I would recommend changing is two lines of code within the video_demo.c file that is within the Zybo-Z7-20-HDMI project in the src folder as this will help prevent crashes while the application is running. The two changes are as follows:

In the "DemoPrintMenu" function, change line 284 (on my system anyway, the number may be slightly different for you) as follows:

//LINE 284 currently says:
printf("*Display Pixel Clock Freq. (MHz): %15.3f*\n\r", dispCtrl.pxlFreq);

//Change LINE 284 to instead say:
xil_printf("*Display Pixel Clock Freq. (MHz): %11d.%03d*\n\r", (int)dispCtrl.pxlFreq, (((int)dispCtrl.pxlFreq*1000)%1000));

In the "DemoCRMenu" function, change line 389 (on my system anyway, the number may be slightly different for you) as follows:

//LINE 389 currently says:
printf("*Pixel Clock Freq. (MHz): %23.3f*\n\r", dispCtrl.pxlFreq);

//Change LINE 389 to instead say:
xil_printf("*Display Pixel Clock Freq. (MHz): %11d.%03d*\n\r", (int)dispCtrl.pxlFreq, (((int)dispCtrl.pxlFreq*1000)%1000));

This should help resolve any crashes while running the application. I was able to unplug and re-plug in both HDMI cables, have the project complain on the serial terminal when the HDMI was disconnected, but successfully resolve itself by itself when I reconnected the HDMI cable.

Please let me know if you have any questions about this.

Thanks,
JColvin

[Michal]

This problem still occurs to me. "hdmi unplugged" msg pops up. Who should i contact to solve the issue?
I was using demo project from git with 2016.4 Vivado version

[Meng]

Hello all,

I got this problem too.

But I solved it.

DO NOT use Vivado Webpack Edition

USE Vivado HL System Edition INSTEAD

That's all!

;-)

[brycecrapse]

On 10/13/2016 at 0:22 PM, jpeyron said:

Hi brycecrapse,

While i look through your logs and see if i can find anything, what is you display settings from where you are supposed to be getting HDMI signal? 

thank you,

Jon

Resolution is 1024x768 on a Macbook Pro...  But I have tried 800x800 -> 1920x1080 and they all give the same Bar Pattern... Of course I can change that pattern using Putty to print blended test pattern...  And that seems to work so it really does seem like it is the inbound hdmi that I just can get recognized...

Hmmmmm

Thanks again for all your help!

[jpeyron]

Hi brycecrapse,

While i look through your logs and see if i can find anything, what is you display settings from where you are supposed to be getting HDMI signal? 

thank you,

Jon

[brycecrapse]

13 hours ago, brycecrapse said:

Excellent!  I will try again with 2016.2 as I would rather be on the later versions anyway.  Let me try and if it still does not work I will include screen shots etc...

QQ: Are you powering by Wall or USB? for this?

Thanks again Ill let you know how it goes this evening...

 

Bryce - - -

OK I tried using 16.2 but no-joy..., I am sure it is just something quite simple which I am forgetting, or I have wrong..

1) Board Files I am using are 15.3+ (I believe these are correct, I did not see 16.2 board files...)

2) I used the Project which you attached to the Response to Michael, I also tried to a new download from Git and both with the same results.

 

Attachements:

1) Log File for both .tcl Project Creations and Bitstream Creation

2) Screen Shots

Any clue would be kindly appreciated...

 

HDMI_DemoLog.odt

 

 

[brycecrapse]

10 hours ago, jpeyron said:

Hi Brycecrapse,

Could you please include screen shots and potentialy a picture of the vga screen. Also could you zip and upload your project. If you just downloaded the hdmi_in project today then you should be using 2016.2 . Today i updated the github zybo hdmi_in demo to work with 2016.2. I have included my project. Also in sdk, when copying files into the application make sure that you do not copy the lscript.Id or the README.txt to the scr folder.

thank you,

Jon

hdmi_in.zip

Excellent!  I will try again with 2016.2 as I would rather be on the later versions anyway.  Let me try and if it still does not work I will include screen shots etc...

QQ: Are you powering by Wall or USB? for this?

Thanks again Ill let you know how it goes this evening...

 

Bryce - - -

[jpeyron]

Hi Brycecrapse,

Could you please include screen shots and potentialy a picture of the vga screen. Also could you zip and upload your project. If you just downloaded the hdmi_in project today then you should be using 2016.2 . Today i updated the github zybo hdmi_in demo to work with 2016.2. I have included my project. Also in sdk, when copying files into the application make sure that you do not copy the lscript.Id or the README.txt to the scr folder.

thank you,

Jon

hdmi_in.zip

[brycecrapse]

Hi,  Michael and I are trying to work through this and I too am getting the same result as Michael.

 

I am using 2015.4 with my Mac plugged into the HDMI port and the VGA plugged into the monitor.  I am using Windows to program the Board, but still no go.  Show's me the exact result as Michael's.

Any hint would be appreciated.

 

Thanks!

[jpeyron]

Hi Michael,

Once you have the project generated in 2015.4 using the tcl script you can open the project with 2016.2 and then update ip's. I just did this and was able to generate a bitstream and program the board in sdk. Hope this helps! Also have you tried using a different HDMI cable? 

cheers,

Jon

[michaelcrapse]

9 hours ago, jpeyron said:

Hi micheal,

I initially had issues because i was using 2015.3 per the readme txt file. I looked into the system.tcl for the hdmi_in and it was built with and for vivado 2015.4 so I used 2015.4. I have fixed this difference in the readme txt. I would suggest to use vivado 2015.4 and it should generate a bitstream with no issues.

thank you,

Jon

 

I downloaded 2015.4 today, but I didn't install update 2(I'll try that tomorrow). I still have the issue with HDMI UNPLUGGED. Not to mention, If it only works with 2015.4, then how should I be able to build off of this example and have an HDMI sink for any future projects? Where should I change to see that it would work in 2016.2. This example seems a bit unfinished. I'll continue to try different configurations on my part, however the only thing I can't try is another computer to generate the bitstream due to my locked license.

[jpeyron]

Hi micheal,

I initially had issues because i was using 2015.3 per the readme txt file. I looked into the system.tcl for the hdmi_in and it was built with and for vivado 2015.4 so I used 2015.4. I have fixed this difference in the readme txt. I would suggest to use vivado 2015.4 and it should generate a bitstream with no issues.

thank you,

Jon

 

[michaelcrapse]

The Warnings that I get from building it.

Synthesis
[Synth 8-992] S_AXI_GP0_ACLK_temp is already implicitly declared earlier ["x:/projects/xilinx/hdmi_in/proj/hdmi_in.srcs/sources_1/bd/hdmi_in/ip/hdmi_in_processing_system7_0_0/hdl/verilog/processing_system7_v5_5_processing_system7.v":2701]

[Synth 8-1565] actual for formal port rst is neither a static name nor a globally static expression ["x:/projects/xilinx/hdmi_in/proj/hdmi_in.srcs/sources_1/bd/hdmi_in/ipshared/digilentinc.com/axi_dynclk_v1_0/src/axi_dynclk.vhd":225]

[Synth 8-312] ignoring unsynthesizable construct: assertion statement ["x:/projects/xilinx/hdmi_in/proj/hdmi_in.srcs/sources_1/bd/hdmi_in/ipshared/xilinx.com/fifo_generator_v13_0/hdl/fifo_generator_v13_0_vhsyn_rfs.vhd":33749]

[Synth 8-3848] Net PROG_FULL in module/entity wr_pf_ss does not have driver. ["x:/projects/xilinx/hdmi_in/proj/hdmi_in.srcs/sources_1/bd/hdmi_in/ipshared/xilinx.com/fifo_generator_v13_0/hdl/fifo_generator_v13_0_vhsyn_rfs.vhd":14714]

[Synth 8-614] signal 'pEyeOpenCnt' is read in the process but is not in the sensitivity list ["x:/projects/xilinx/hdmi_in/proj/hdmi_in.srcs/sources_1/bd/hdmi_in/ipshared/digilentinc.com/dvi2rgb_v1_6/src/PhaseAlign.vhd":318]

[Synth 8-350] instance 'w_buffer' of module 'blk_mem_gen_v8_3_0' requires 63 connections, but only 59 given ["x:/projects/xilinx/hdmi_in/proj/hdmi_in.srcs/sources_1/bd/hdmi_in/ipshared/xilinx.com/axi_dwidth_converter_v2_1/hdl/verilog/axi_dwidth_converter_v2_1_w_upsizer_pktfifo.v":1539]

[Constraints 18-619] A clock with name 'TMDS_clk_p' already exists, overwriting the previous clock with the same name. ["X:/projects/xilinx/hdmi_in/src/constraints/ZYBO_Master.xdc":117]

[Synth 8-565] redefining clock 'TMDS_clk_p'

[Synth 8-5396] Clock pin C has keep related attribute (keep/mark_debug/dont_touch) which could create extra logic on its net ["x:/projects/xilinx/hdmi_in/proj/hdmi_in.srcs/sources_1/bd/hdmi_in/ipshared/xilinx.com/axi_dwidth_converter_v2_1/hdl/verilog/axi_dwidth_converter_v2_1_a_upsizer.v":858]

Implementation
Design Initialization
[Constraints 18-619] A clock with name 'TMDS_clk_p' already exists, overwriting the previous clock with the same name. ["X:/projects/xilinx/hdmi_in/src/constraints/ZYBO_Master.xdc":117]

Place Design
[DRC 23-20] Rule violation (REQP-1839) RAMB36 async control check - The RAMB36E1 hdmi_in_i/axi_mem_intercon/m00_couplers/m00_data_fifo/inst/gen_fifo.fifo_gen_inst/inst_fifo_gen/gaxi_full_lite.gread_ch.grdch2.axi_rdch/grf.rf/gntv_or_sync_fifo.mem/gbm.gbmg.gbmga.ngecc.bmg/inst_blk_mem_gen/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[0].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.WIDE_PRIM36_NO_ECC.ram has an input control pin hdmi_in_i/axi_mem_intercon/m00_couplers/m00_data_fifo/inst/gen_fifo.fifo_gen_inst/inst_fifo_gen/gaxi_full_lite.gread_ch.grdch2.axi_rdch/grf.rf/gntv_or_sync_fifo.mem/gbm.gbmg.gbmga.ngecc.bmg/inst_blk_mem_gen/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[0].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.WIDE_PRIM36_NO_ECC.ram/ADDRARDADDR[10] (net: hdmi_in_i/axi_mem_intercon/m00_couplers/m00_data_fifo/inst/gen_fifo.fifo_gen_inst/inst_fifo_gen/gaxi_full_lite.gread_ch.grdch2.axi_rdch/grf.rf/gntv_or_sync_fifo.mem/gbm.gbmg.gbmga.ngecc.bmg/inst_blk_mem_gen/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[0].ram.r/prim_noinit.ram/ADDRB[4]) which is driven by a register (hdmi_in_i/axi_mem_intercon/m00_couplers/m00_data_fifo/inst/gen_fifo.fifo_gen_inst/inst_fifo_gen/gaxi_full_lite.gread_ch.grdch2.axi_rdch/grf.rf/gntv_or_sync_fifo.gl0.rd/rpntr/gc0.count_d1_reg[4]) that has an active asychronous set or reset. This may cause corruption of the memory contents and/or read values when the set/reset is asserted and is not analyzed by the default static timing analysis. It is suggested to eliminate the use of a set/reset to registers driving this RAMB pin or else use a synchronous reset in which the assertion of the reset is timed by default.

[Place 30-12] An IO Bus FIXED_IO_mio with more than one IO standard is found. Components associated with this bus are: 
	FIXED_IO_mio[53] of IOStandard LVCMOS18
	 FIXED_IO_mio[52] of IOStandard LVCMOS18
	 FIXED_IO_mio[51] of IOStandard LVCMOS18
	 FIXED_IO_mio[50] of IOStandard LVCMOS18
	 FIXED_IO_mio[49] of IOStandard LVCMOS18
	 FIXED_IO_mio[48] of IOStandard LVCMOS18
	 FIXED_IO_mio[47] of IOStandard LVCMOS18
	 FIXED_IO_mio[46] of IOStandard LVCMOS18
	 FIXED_IO_mio[45] of IOStandard LVCMOS18
	 FIXED_IO_mio[44] of IOStandard LVCMOS18
	 FIXED_IO_mio[43] of IOStandard LVCMOS18
	 FIXED_IO_mio[42] of IOStandard LVCMOS18
	 FIXED_IO_mio[41] of IOStandard LVCMOS18
	 FIXED_IO_mio[40] of IOStandard LVCMOS18
	 FIXED_IO_mio[39] of IOStandard LVCMOS18
	 FIXED_IO_mio[38] of IOStandard LVCMOS18
	 FIXED_IO_mio[37] of IOStandard LVCMOS18
	 FIXED_IO_mio[36] of IOStandard LVCMOS18
	 FIXED_IO_mio[35] of IOStandard LVCMOS18
	 FIXED_IO_mio[34] of IOStandard LVCMOS18
	 FIXED_IO_mio[33] of IOStandard LVCMOS18
	 FIXED_IO_mio[32] of IOStandard LVCMOS18
	 FIXED_IO_mio[31] of IOStandard LVCMOS18
	 FIXED_IO_mio[30] of IOStandard LVCMOS18
	 FIXED_IO_mio[29] of IOStandard LVCMOS18
	 FIXED_IO_mio[28] of IOStandard LVCMOS18
	 FIXED_IO_mio[27] of IOStandard HSTL_I_18
	 FIXED_IO_mio[26] of IOStandard HSTL_I_18
	 FIXED_IO_mio[25] of IOStandard HSTL_I_18
	 FIXED_IO_mio[24] of IOStandard HSTL_I_18
	 FIXED_IO_mio[23] of IOStandard HSTL_I_18
	 FIXED_IO_mio[22] of IOStandard HSTL_I_18
	 FIXED_IO_mio[21] of IOStandard HSTL_I_18
	 FIXED_IO_mio[20] of IOStandard HSTL_I_18
	 FIXED_IO_mio[19] of IOStandard HSTL_I_18
	 FIXED_IO_mio[18] of IOStandard HSTL_I_18
	 FIXED_IO_mio[17] of IOStandard HSTL_I_18
	 FIXED_IO_mio[16] of IOStandard HSTL_I_18
	 FIXED_IO_mio[15] of IOStandard LVCMOS33
	 FIXED_IO_mio[14] of IOStandard LVCMOS33
	 FIXED_IO_mio[13] of IOStandard LVCMOS33
	 FIXED_IO_mio[12] of IOStandard LVCMOS33
	 FIXED_IO_mio[11] of IOStandard LVCMOS33
	 FIXED_IO_mio[10] of IOStandard LVCMOS33
	 FIXED_IO_mio[9] of IOStandard LVCMOS33
	 FIXED_IO_mio[8] of IOStandard LVCMOS33
	 FIXED_IO_mio[7] of IOStandard LVCMOS33
	 FIXED_IO_mio[6] of IOStandard LVCMOS33
	 FIXED_IO_mio[5] of IOStandard LVCMOS33
	 FIXED_IO_mio[4] of IOStandard LVCMOS33
	 FIXED_IO_mio[3] of IOStandard LVCMOS33
	 FIXED_IO_mio[2] of IOStandard LVCMOS33
	 FIXED_IO_mio[1] of IOStandard LVCMOS33
	 and FIXED_IO_mio[0] of IOStandard LVCMOS33

Route Design
[DRC 23-20] Rule violation (PLIO-7) Placement Constraints Check for IO constraints - An IO Bus FIXED_IO_mio[53:0] with more than one IO standard is found. Components associated with this bus are: LVCMOS33 (FIXED_IO_mio[15], FIXED_IO_mio[14], FIXED_IO_mio[13], FIXED_IO_mio[12], FIXED_IO_mio[11], FIXED_IO_mio[10], FIXED_IO_mio[9], FIXED_IO_mio[8], FIXED_IO_mio[7], FIXED_IO_mio[6], FIXED_IO_mio[5], FIXED_IO_mio[4], FIXED_IO_mio[3], FIXED_IO_mio[2], FIXED_IO_mio[1] (the first 15 of 16 listed)); LVCMOS18 (FIXED_IO_mio[53], FIXED_IO_mio[52], FIXED_IO_mio[51], FIXED_IO_mio[50], FIXED_IO_mio[49], FIXED_IO_mio[48], FIXED_IO_mio[47], FIXED_IO_mio[46], FIXED_IO_mio[45], FIXED_IO_mio[44], FIXED_IO_mio[43], FIXED_IO_mio[42], FIXED_IO_mio[41], FIXED_IO_mio[40], FIXED_IO_mio[39] (the first 15 of 26 listed)); HSTL_I_18 (FIXED_IO_mio[27], FIXED_IO_mio[26], FIXED_IO_mio[25], FIXED_IO_mio[24], FIXED_IO_mio[23], FIXED_IO_mio[22], FIXED_IO_mio[21], FIXED_IO_mio[20], FIXED_IO_mio[19], FIXED_IO_mio[18], FIXED_IO_mio[17], FIXED_IO_mio[16]); 

Write Bitstream
[DRC 23-20] Rule violation (REQP-1839) RAMB36 async control check - The RAMB36E1 hdmi_in_i/axi_mem_intercon/m00_couplers/m00_data_fifo/inst/gen_fifo.fifo_gen_inst/inst_fifo_gen/gaxi_full_lite.gread_ch.grdch2.axi_rdch/grf.rf/gntv_or_sync_fifo.mem/gbm.gbmg.gbmga.ngecc.bmg/inst_blk_mem_gen/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[0].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.WIDE_PRIM36_NO_ECC.ram has an input control pin hdmi_in_i/axi_mem_intercon/m00_couplers/m00_data_fifo/inst/gen_fifo.fifo_gen_inst/inst_fifo_gen/gaxi_full_lite.gread_ch.grdch2.axi_rdch/grf.rf/gntv_or_sync_fifo.mem/gbm.gbmg.gbmga.ngecc.bmg/inst_blk_mem_gen/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[0].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.WIDE_PRIM36_NO_ECC.ram/ADDRARDADDR[10] (net: hdmi_in_i/axi_mem_intercon/m00_couplers/m00_data_fifo/inst/gen_fifo.fifo_gen_inst/inst_fifo_gen/gaxi_full_lite.gread_ch.grdch2.axi_rdch/grf.rf/gntv_or_sync_fifo.mem/gbm.gbmg.gbmga.ngecc.bmg/inst_blk_mem_gen/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[0].ram.r/prim_noinit.ram/ADDRB[4]) which is driven by a register (hdmi_in_i/axi_mem_intercon/m00_couplers/m00_data_fifo/inst/gen_fifo.fifo_gen_inst/inst_fifo_gen/gaxi_full_lite.gread_ch.grdch2.axi_rdch/grf.rf/gntv_or_sync_fifo.gl0.rd/rpntr/gc0.count_d1_reg[4]) that has an active asychronous set or reset. This may cause corruption of the memory contents and/or read values when the set/reset is asserted and is not analyzed by the default static timing analysis. It is suggested to eliminate the use of a set/reset to registers driving this RAMB pin or else use a synchronous reset in which the assertion of the reset is timed by default.

 

[michaelcrapse]

3 hours ago, jpeyron said:

Hi Michael,

I was able to get the HDMI_in project to work multiple times if i had all of my cables connected prior to programing the board and running the software. If i unplugged it after set up it would do as you described most of the times with stating !HDMI unplugged!. Sometimes it would lock the uart communication up while changing to the test display once i unplugged the HDMI after set up. Also I wasn't able to get it to work it if i left the hdmi unplugged until after set up and then plugged it in. Hope this helps!

cheers,

Jon

 

Thank you for your response. I have tried cleaning the project and rebuilding. I also tried what you did to no avail. The HDMI out project works fine though, just the IN is quite finickey. Perhaps it's because I'm using vivado 2016.2. Which version are you using? 

Edit: Tried in 2015.3 and I still have the same issue. I've also tried a different CRT monitor, a different computer/hdmi source, and also a different Zybo board. The issue continues to persist.

edit 2: Perhaps the warnings i get when i generate the bitstream may come into play??

[jpeyron]

Hi Michael,

I was able to get the HDMI_in project to work multiple times if i had all of my cables connected prior to programing the board and running the software. If i unplugged it after set up it would do as you described most of the times with stating !HDMI unplugged!. Sometimes it would lock the uart communication up while changing to the test display once i unplugged the HDMI after set up. Also I wasn't able to get it to work it if i left the hdmi unplugged until after set up and then plugged it in. Hope this helps!

cheers,

Jon