Nexys Video HDMI/DVI-D oddness.

[hamster]

I wanted to see what video standards my Nexys Video design would work with, so I took the board into work and connected it up to a Sencore Mediapro Multimedia Generator (e.g. https://www.testequipmentconnection.com/47221/Sencore_MP500.php). Strangely *nothing* worked 720p, 1080i 1080p, 50Hz, 60Hz - not even when it was generating DVI-D.  Equally strange, even the HDMI/DVI-D pass-though in the design in board's flash didn't work. 

However, the monitor worked just fine when it was plugged directly into the Sencore. Connecting up the logic analyser to debug signals showed unpredictable runt pulses on the HSYNC line, and after tracing and analysing an entire frame there are blocks of CTL symbols where they shouldn't be. Plugging the Nexys Video back into my Laptop or Media player everything is fine.

Not sure what is up, but something is. I tried a couple of different HDMI cables without success. It looks to be something at the physical layer... can anybody offer any advice? 

Test idea #1 - I'll put a HDMI splitter between the Sencor and the board.

Test idea #2 - I'll manually decode the 50MB of captured symbols (well, write a program to do it) and see if that shows anything...

 

[Alex]

Hi, sorry, I want to ask a dump question. Did you create an embedded / hardware design on Nexys Video and then use Sencore to generate the HDMI signal to test the board?

[hamster]

Yes. Exactly that - Sencore as HDMI source, NexysVideo as HDMI sink.

I've still got to borrow the HDMI splitter and see if that helps...

[Commanderfranz]

Hamster,

I have escalated this question to support so it can be answered. Just know you haven't been forgotten.

Kaitlyn

[hamster]

Finally got the board into the office for an hour....

Test 1:

Source: Sencore Pro Multimedia Generator

Mid stream: Generic HDMI Splitter

Uint under test: Nexys Video running default bitstream that ships from the board.

Monitor: Viewsonic VX2453MH

Results: Test patterns are displayed for  1080p @ 60Hz,  1080p @ 50Hz, 720p @ 60,  720p @ 50, No interlaced modes supported. Only RGB444 mode give image. No deep colour

Test 2:

Source: Sencore Pro Multimedia Generator

Uint under test: Nexys Video running default bitstream that ships from the board.

Monitor: Viewsonic VX2453MH

Results: No modes work.

Test 3:

Source: Sencore Pro Multimedia Generator

Mid stream: Generic HDMI Splitter

Uint under test: Nexys Video running default my HDMI bitstream

Monitor: Viewsonic VX2453MH

Results: Test patterns are displayed for  1080p @ 60Hz,  1080p @ 50Hz, 720p @ 60,  720p @ 50, 1080i interlaced modes supported, DVI modes. RBG444, YCC444 and YCC422 modes work. No deep colour

Test 4:

Source: Sencore Pro Multimedia Generator

Monitor: Viewsonic VX2453MH

Results: Test patterns are displayed for  1080p @ 60Hz,  1080p @ 50Hz, 720p @ 60,  720p @ 50, 1080i interlaced modes supported, DVI modes work, RGB444, YCC444 and YCC422 modes work, deep colour works.

Conclusion: The at the physical layer the Nexys Video inputs have interoperability issues with the Sencore MediaPro Multimedia Generator, and this can be resolved by inserting a inexpensive HDMI splitter in the path.

 

 

 

[mwingerson]

Thanks for the update Hamster!  

I will ask one of our engineers about this and see if he can tell why the issue is occurring.

Marshall

 

[elodg]

Hello Hamster,

If there are blocks of CTL tokens where there shouldn't be or non-tokens where there should be, most probably you are looking at an HDMI stream, rather than DVI. HDMI builds upon the DVI spec, but introduces out-of-band transmission (audio, for example) in the blanking periods. Therefore, HDMI Sources send less CTL tokens and mixes them with other data. This obviously only works if the Sink too is HDMI-compatible and not just a DVI Sink.

The pass-through mode in the Nexys Video demo is not passive. The Sink port actually decodes the video stream in the FPGA, re-encodes and transmits it on the HDMI Source port. The Nexys Video has to emulate a Sink (like a monitor) for the connected Source to begin transmission. This includes the handshake mechanism of hot-plug detection and EDID read. All Sinks have to provide identification and capabilities information in the EDID memory over the DDC bus. The demo project only supports DVI and should correctly advertise this in the EDID. The connected Source has to read this and adjust resolution and other parameters so that the Sink is compatible with it. Make sure the Sencore Pro Multimedia Generator does this and there is no manual override set on it.

This is not a limitation of the board itself, but that of the FPGA implementation. You should be able to implement HDMI in the FPGA without problems.

Let us know, if this helps.

[hamster]

Hi Elodg,

Fully agree with the comment - the problem is that a few characters in the active video area are being received as the CTL (e.g."0010101011"). This happens regardless of the source being set to configured for DVI-D or HDMI mode.

It might be a failing of the source (it might be designed to be pathological!), and putting the HDMI splitter cleans things up...

My design running on the Nexys Video supports both HDMI and DVI-D, and only has problem with this one source, so maybe it is being pathological (e.g. replacing the TMDS symbol which decodes to the same 8-bit value, just to be painful).

Mike

[elodg]

OK, so it's not a DVI-D/HDMI mismatch. It might be a bit error in this case. If you are using your own design, make sure you do phase alignment correctly. Do you have a way to measure how successful phase alignment was and what are your margins? Our demo project uses the dvi2rgb IP from our vivado-library GitHub repo. With our IP you could you try looking at the pEyeSize signal for each channel with the Vivado Logic Analyzer. This should tell you how wide (in number of IDELAY taps) the open eye was detected during the phase alignment step of the lock process.

[hamster]

At 1080p I have about 4 or 5 taps and position it on the tap following the one where bit errors drop below one in a big number that I can't recall at the moment.... 

Humm...

[elodg]

For 1080p, a bit period is covered by 8-9 taps (78ps per tap). We were getting 5 at least for the open eye in our tests. Our phase alignment algorithm seeks to the center of the eye delimited by tap values not getting the number of tokens and at the frequency listed in the DVI spec. Could it be that checking for bit errors < 1 results in suboptimal lock if the data set is not large enough?

[hamster]

At least we agree in the number of taps in the eye. 8)  

Both the reference design and mine work with all the other sources - and bit errors usually look like "sparkles" that upset a few pixel's MSBs.

However, it most probably isn't worth following up on, as I change jobs next week and no longer have access to the Sencore. Hopefully the post will help somebody else avoid wasting too much time when an easy workaround exists.