Jump to content
  • 0

Nexys Video HDMI input struggle


SIsForSam

Question

Folks,

I was able to get the HDMI demo to build (using the library hint provided elsewhere in this forum).  The two different test patterns work but I can not get HDMI input/passthrough to work.  The green LED next to the HDMI port lights up when I plug it in but I consistently get the message "!HDMI UNPLUGGED!" after Video Capture Resolution.

I have tried different resolutions -- my only other guess is to try different computers.

Any hints??

Sam

 

 

Link to comment
Share on other sites

6 answers to this question

Recommended Posts

@SIsForSam,

What a coincidence!  I'm also trying to build an HDMI pass through for the Nexys Video board.  My particular goal, though, is to do it from scratch and in all Verilog.  I just got the EDID portion working last week using this I2C controller I just built for this purpose.

Is this the example you've been working from?  You commented about a hint you found elsewhere on the forum, so I was wondering where that was.

When I got stuck last week, I went and found @hamster's code here.  Sadly, that code appears as though he posted it before he got it working, as Vivado is giving me implementation errors when I try to use his approach to controlling the I/O's.

Some of the things I've been doing that've helped:

  1. For the EDID, I've plugged the monitor into another computer so I can read the EDID off of it, and I have an Raspberry Pi 2B driving the Nexys,  That's really helped.  At least ... it has given me "truth" to work from.
  2. The green light you reference is driven by the HDMI_RX_HPA wire (page 6 of the schematic, region A4 of that page).  You're not going to get anything going without this wire turned on, but just having it turned on doesn't give you all that much indication of anything more than you have this pin turned on.
  3. I built a really simple clock counter that I've used to measure the input clock speed.  You might wish to do something similar as well.  Using that input clock counter, I can tell 1) when/if the RPi is producing a signal, and 2) which of the monitor's various mode's it is transmitting in.  Indeed, this was how I discovered how important that HPA signal was.  :)
  4. I've been successful using my wishbone scope (you need a wishbone bus to use this ...) to capture sections of the input HDMI stream to help "see" what's going on.  Sadly, ... I'm not sure I've got the input stream right (yet).  Still working on that one.
  5. I put an "example" section into the wishbone scope code, showing some of my (failed) work on the I2C driver.  If you want to read about that, you can find it here.
  6. I took one piece of advice from examining @hamster's code: He digitized the clock as well as the input samples, so ... I've been trying to get that working.  Still not there yet.  Apparently there's a lot of constraints on how you use the wires associated with ISERDESE2, IDELAYE2, and PLL_BASE2 blocks, and ... I'm only just learning them.

Beyond that, I'll look forward to hearing a response from someone who has actually done the project and is familiar with the result.

Dan

Link to comment
Share on other sites

D@n,

Your project sounds very interesting.  I'm still at step 0 -- trying to get the example to work:

This is the design that I was trying to compile

https://reference.digilentinc.com/learn/programmable-logic/tutorials/nexys-video-hdmi-demo/start

This post provided critical information that I was missing the library - I then switched to the provided .zip file:

https://forum.digilentinc.com/topic/4050-generating-bitstream-in-hdmi-demo-fails-vivado-20164

I see this post (for a different board) which suggests the design is resolution sensitive:

https://forum.digilentinc.com/topic/4087-arty-z7-20-hdmi-in-demo-unable-to-use-1280x1024-resolution-as-input-hdmi-signal

I think this may be the answer

https://forum.digilentinc.com/topic/991-zybo-hdmi-sink

My plan today is to force on of these resolutions and see what happens.  Once I can get the basic demo going I too would like to get pass-through going in Verilog!

Sam

Link to comment
Share on other sites

@SIsForSam,

I'll keep you posted as I go along if you'd like.  Unlike you, I didn't start with a working example.

Right now, I think I just managed to get past a "misleading" description within Xilinx's SelectIO user's guide, so ... I'm moving forward (again).  (For those interested, figure 3-8, the block diagram of ISERDESE2 width expansion, doesn't work for the 1:10 expansion needed for HDMI.  At least the paragraph above tries to explain it, which is what I missed before.)

Oh, and I'm trying to do this for 1920x1080 @60Hz.  ;)

Dan

Link to comment
Share on other sites

D@n,

Definitely want to follow your progress... The example is now working for me ---For anyone else who lands on this thread: I switched to a different computer to generate the HDMI stream and it seems to work fine and seems very capable.

Sam

Link to comment
Share on other sites

@SIsForSam,

The other day, I described this to a significant another in a four part fashion, laying out the steps I'd like to take for this project:

  1. Be able to transmit without the FPGA board from a RPi to my monitor.  Further, I'd like to be able to place, onto that monitor, an image of my choosing--even without using the X11 display on the RPi.  This is done.
  2. This step is basically the one you are doing--only without the Xilinx IP.  Success will be if I can get the HDMI to pass through the board unmolested and display on the monitor.  It's the step I'm working on right now.  My problem is ... I've had to add a lot of logic into what I'm doing, scaffolding if you will, so I can figure out what's going right (or wrong in this case).  This may be my hardest step, especially because it's hard to know what component is failing at this point and why.
  3. This is the same as two above, with the exception that I'd like to decode the HDMI signal and re-encode it before sending it back out again.  This will verify that I understand the encoding properly.
  4. Finally, I'd like to dump the input into memory, read and or modify the memory from an onboard CPU, and then read it back out again for the display.  Bandwidth will be an issue here, so ... we'll see how I solve that problem when I get there.

So ... right now, I'm still trying to get the direct pass-through working.  I'm currently trying a trick @hamster used.  He digitized the clock along with the data.  It's taken me several days to figure out how to get the project to build using this approach, but now that it's building I can now tell you that my HDMI high speed and logic clocks ... aren't aligned with the input yet.

So, basically, I have my input wires going through an IBUFDS, to turn them from differential to single.  They then go through an IDELAYE2.  I have this IDELAYE2 set to be programmable, so I can experiment with how things look if I modify the phase.  From the IDELAYE2, they then go into an ISERDESE2.  From there, they go into some analysis logic I have.  One such piece of analysis allows me to grab any section of 2^N data inputs.  Another allows me to look at the clock wire's output, having gone through this same processing path.

The clock wire, though, is special.  While the clock wire is doing the same thing as the data, I'm also running a wire bypassing the IDELAYE2 and then bypassing the ISERDESE2 as well (the wire has to go through these two components, but through their bypass ports ...).  This clock wire then goes into a PLL_BASE2.  The PLL generates three clocks: two at 5x the input clock rate for driving the ISERDESE2 and OSERDESE2 (when I get to it), and one at the input clock rate.  These three are phase locked, with the second of the two high speed clocks running at a 180 degree difference from the first one.  The feedback wire goes from the PLL, through a BUFG, and back to the PLL.  This guarantees that the BUFG has the right phase, but not the data lines.

Since I can read how the clock wire looks when sampled through the ISERDESE2, I can use that (this is what I'm working with now) to adjust the phase of the feedback clock within the PLL to align all my pixels up with the input clock.  (I may need to adjust this, if I switch from a 148.5MHz pixel clock ...)

Hmm ... am I going to need to use the bitslip?  I was hoping to avoid it ... :huh:

My next measure of success will be whether or not I can read the synchronization words from the HDMI input port.  Sadly, I haven't manged to read any of those validly ... yet.  So, while I'm not there, I am getting there.  ;)

Dan

Link to comment
Share on other sites

@SIsForSam,

Well ... I may have gotten lucky, but I finally got an image to display through my Nexys Video board.  My setup included a Raspberry Pi 2B transmitting an image to the HDMI sink on my Nexys Video, followed by decoding that image and then sending it out the HDMI source port to an HDMI to VGA converter, and from there to one of my two monitors.

Some of the problems I had include:

  1. The ISERDESE2 bitslip module, while it works as described in the SelectIO user's guide, doesn't work intuitively.  (shifts by one bit in one direction, then by three bits in the other, and once done cannot be undone ...)  I needed something programmable and reversible (having shifted by 5, I'd then like to try shifting by 4 and 6 while being able to return to 5).  I also wanted to be able to delay or advance the pixel stream by one bit at a time and each of the three streams individually (i.e. shift one stream by +1, and another by -1).  Hence, I built a very simple bitslip module of my own that is easily programmable to do the operation.
  2. I still don't know quite how I want to handle finding fractional bit alignment automatically.  For me, an IDELAYE2 delay of 16 out of 32 did the process just right.  Unfortunately, I arrived at that value by sending numbers to the FPGA by hand and then IDELAYE2 component within it until I arrived at something that worked.  (Yes, by hand ... I was controlling the bit slip from an external interface running across the UART much as I do all my FPGA designs)
  3. I had set the first bit received to be the most significant bit in any HDMI pixel word, however the HDMI spec places the first bit received as the LSB.  While I was aware of this, and thought I knew what I was doing, this difference only confused things as I tried to lock up to the sync.
  4. And, of course, I had to deal with lots and *lots* of your traditional errors ... you know, where you think you programmed one piece of logic, only to find what you actually wrote didn't mean what you thought it mean, or where you thought you were following the spec only to come back to it later and get a new realization about what the spec meant, you get the idea.

I would never have been able to get this far without being able to read/record streams of 10b pixel values from the interface via the wbscope that I tend to use in all of my projects, nor would I have been able to do it without a means of controlling that wishbone bus, and hence all of my HDMI logic, without a UART to wishbone converter.  Using the two of these, I was able to capture 16k consecutive pixel samples, and then use C/C++ code to find the synchronization pixels within them, and evaluate whether or not I had the right understanding of the spec that I thought I had.  This is why I always counsel new FPGA designers to start their projects by building the scaffolding they need to 1) understand what's going on within their design, and 2) to experiment with difficult configurations when you don't know which is the one you will ultimately want.

Future work will involve finding the synchronization automatically without user fiddling.  But after that, my next step is going to be to dump all of this video image data to RAM.

Dan

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...