ajaykumar

Hi @elodg At this point, I understand that we have to do a clean board design following the necessary guidelines for a DVI sink design. I will try this and see how it flows. Thank you very much for extending your support through out. Thanks and Regards Ajay

Hi @elodg Did you get a chance to go through the waveform report? As another way to check for signal integrity or board integrity for the set up I am using for HDMI In, I have done a small experiment. I have used a test pattern generator which can generate 1920x1080P 60 fps RGB test pattern and connected it to RGB to DVI IP. Clocked the modules at 148.5MHz and mapped the TMDS IOs to the same pin numbers used in the HDMI/DVI input case. I connected this to the sink and I could see the expected test pattern at the expected fps without any glitches. I have repeated this experiment with two boards, with a slight difference in TMDS IO Pin map. It works well in both cases. The Difference in TMDS IO map is : Board 1 : TMDS IOs are all not in same byte group ( D0 +/-, D1 +/- in one byte group (T0) , D2 +/-, CK +/- in another byte group (T1)) Board 2 : TMDS IOs are all mapped in same byte group The RGB to DVI output worked very well in both mappings However, DVI2RGB IP exhibited different behavior in these two cases Board 1 : The issue we have been discussing so far. Board 2 : There is no output from DVI2RGB except for PCLK. (The eye size of D1 shows zero, eye size for D0, D2 are 5,6 respectively. PVLD is 5, PRDY is zero in the PIX CLK ILA capture) Can we draw any helpful inferences from these results? Thanks and Regards Ajay.

Hi @elodg Please find attached report with snapshots of data during blanking region DE high. I have looked into the source and net list and noted that its PC0, PC1 , PVDE and PdataIn coming out as data, hsync, vsync and DE. Hence, instead of adding them again i have captured the same with existing ILA. The data in almost all cases is like f1f100, 00f100. Also, there were weird cases like a short lived VSYNC pulse, hsync vsync active for more than 2000 clocks (active for full ILA capture window size) etc. In addition, i have verified if the EDID read by source is corrupted by any chance. This is not the case. I have tapped the I2C lines and verified that byte 20 (starting byte noted as byte 0) Video input bitmap goes as 0x80 (undefined bit depth, undefined interface) as in given EDID. I have verified that all the 128 bytes in base EDID are read properly by the source. I missed out sharing the hardware set up details so far. Please find the same below Hardware setup : I am currently using a HDMI cable with one (sink) end soldered onto boards, the other end connected to source using standard connector. I have pulled up TMDS IOs in XDC to match the schematic in Pynq board. I have left CEC pin of HDMI cable to float. I have to do this as I have not had a HDMI in connector in place. I have a generic input connector capable of receiving parallel data at 148.5M. The IOs used were compatible with TMDS. Hence, I have soldered the HDMI cable TMDS signals to respective pins. DDC and HPD signals levels taken care appropriately. Thanks and Regards, Ajay Artix3.docx

Hi @elodg I have upgraded the IP and attached the report with snapshots of refclk ila, pix clk ila and Vid IO ila for various scenarios. Summary: Checked reflck ila waveforms before and after input feed Checked pixclk ila waveforms before and after input feed Checked if any triggers happen on align error, bitslip, locklost rst, rdy change, pval change - no events triggered Checked the behaviour of DVI2RGB output signals as before (Slot 0) - similar behaviour noted Captured snapshots in all cases and added them to attached report. Design Changes: DVI2RGB IP upgraded from 1.7 to 2.0 All settings remain same apixclkLckd signal is used as earlier for proc sys reset module instead of pLocked signal Sink detection : Attached Displat Detect Status. It is same in both cases Thanks and Regards, Ajay Artix2.docx zybo2.docx

Hi @elodg Thank you very much for the quick response. The SLOT0 signals in both cases correspond to the VIDEO out aka RGB port of DVI 2 RGB IP. Can you please re check the same. The IP internal debug is not available with IPv 1.7. Regarding EDID, am not customizing them. Am letting the IP use its own EDID files, which it loads based on the preferred resolution and clock range settings. As mentioned, the IP settings are the same in working and non working cases. I will look into possible signal integrity issues. However, please let me know if there could be other causes for the same Thanks and Regards, Ajay Kumar G

Hi, I am using DVI2RGB IP v1.7 IP in my project for receiving video over HDMI/DVI and process the same for further use. I have a zybo z7 board, i have made a reference design for the same as PoC. This is a pass through design, receives 1920x1080 @ 60 fps. The output from DVI2RGB is fed back to RGB2DVI through AXIS Infra. A parallel video out is also mapped to PMOD Pins. This design had only one issue, the HPD has to be a delayed asserion, which i am doing through VIO. The design works very well without any issue. I fed in stream from PC and monitor the output in a display. The parallel stream is also verified by probing in DSO. Taking this design as start point, i have made a near identical design targeting a custom Artix 7 FPGA (XC7A35T-2XXXX) board. I have landed into trouble with the way DVI2RGB IP outputs come. In this case, i see issues with DE signal spurious behavior. The DE signal pulses intermittently during the horizontal and vertical blanking regions causing the downstream AXIS infra to misbehave. The same results in AXIS 2 VOUT repoting underflow and never locking. The DE pulsing in blanking regions is leading to false valid tlast resulting in short packets. The DE is also pulsing when vsync is active resulting in a short packet of Tuser, pixel, tlast. The DE pulses in VSYNC region can be filtered off by a simple logic. However, DE pulses in HBlank region cannot be (or I do not know). I have tried the below changes to see if anything works 1. Tried lowering Refclk freq from 200 to about 182 (zynq PS clock generates this value for 200M) - No change noted 2. Tried lowering the resolution in DVI2RGB config - No change noted with 720P config 3. Constrained TMDS clk to 148.5MHz in the top (for FHD@60fps) - No change noted 4. Verified if there is a diff in IDelayTap width and count between Artix and zynq - No difference noted 5. Verified the TMDS CLK Pin mapping between Zynq and Artix - Mapped to MRCC pins in both cases The differences between two designs are as follows 1. The refclk comes from PS in Zynq Design. In the Artix refclk is generated from MMCM whose input is driven by clock output from another MMCM in top level. 2. The ARST_N signal tied to DVI2RGB comes from proc sys reset controlled by 100M in Zynq design. Same structure is followed in artix design 3. The zynq design is with 2016.4 Vivado. The Artix design is with 2019.1 Vivado. I have tried 2015.4 tool flow also for Artix with same IP version. I have tried 2019.1 tool flow with latest version of DVI2RGB, all had same issue. I have attached snapshots of ILA for both Zybo and Artix cases, BD snapshots for both Zybo and Artix cases. Looking for more insights into understanding and resolving this issue. Thanks and Regards, Ajay Zybo.docx Artix.docx

Hi @JColvin In continuation to the effort, I was validating an architecture which is intended to work like a display broadcast solution. I take a DVI input into the FPGA using DVI2RGB IP. I then use this RGB output to multiple RGB to DVI IPs, with pixel clock and serial clock appropriately taken care. As a precursor to this, I have tried testing an input - output combination with this IP. I have taken the Zybo Z7 HDMI design , and connected the RGB output from DVI 2 RGB IP directly to RGB 2 DVI IP, with pixel clock and serial clock still coming from the dynamic clock wizard. I have ensured that input resolution and output resolution are specified to be same. In addition to this I have also tried a simple fresh design with just the 2 IPs connected in similar fashion, clocks taken care appropriately. I could not see any output on the display for both the cases. Is the RGB output from DVI2RGB not sufficient as an input to RGB2DVI IP? Or am I missing out anything here? Thanks and Regards Ajay

Hi @JColvin Thank you for the details. This clarifies most of the things for me. What I am going to do now is pick a spartan 7 break out board, and build a test board with HDMI IO ports. Will update you with the results. Thanks and Regards Ajay

Hi @JColvin Thank you very much for the details. I have edited the lines and created a Vivado project with these IPs as input and output of the pipeline targeting a Spartan device (xc7s6cpga196-1). I have not faced any issues with respect to versioning. I have also synthesized it, without IO mapping and it went well. I will try that as well and get back to you with synth and implementation results. I too do not have a board as of now to test it on hardware. Looking for options. Meanwhile, can you clarify on this-> The Arty S7 and Cmod S7 use CSG324 and CSG225 packages respectively and both of them have a decent number of IOs 100 / 150. When you mentioned lack of appropriate IO interfaces, is it that all these IOs were used for other purpose as the intent of the board design is different or is it that the IOs in these parts are not compatible with digilent TMDS IO type? Thanks and Regards, Ajay

Hi, Are the RGB2DVI and DVI2RGB IPs not supported in Spartan 7 for lack of supported IOs or lack of supported boards from digilent? If it is due to lack of supported boards, can we use the IP targeting a spartan device by add spartan to list of supported devices in IP file? Thanks , Ajay