• 0
hamster

Nexys Video HDMI/DVI-D oddness.

Question

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...

 

Edited by KaitlynFranz

Share this post


Link to post
Share on other sites

11 answers to this question

Recommended Posts

  • 0

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?

Share this post


Link to post
Share on other sites
  • 0

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...

Share this post


Link to post
Share on other sites
  • 0

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.

 

 

 
Edited by hamster

Share this post


Link to post
Share on other sites
  • 0

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.

Share this post


Link to post
Share on other sites
  • 0

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

Edited by hamster

Share this post


Link to post
Share on other sites
  • 0

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.

Share this post


Link to post
Share on other sites
  • 0

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...

Edited by hamster

Share this post


Link to post
Share on other sites
  • 0

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?

Share this post


Link to post
Share on other sites
  • 0

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now