Hdmi Sink On Zybo Zynq?

[digicloud14]

Hi there, I recently purchased a Zybo Zynq 7000 development board and have been working through tutorials to familiarize myself with Vivado, IP blocks, etc (not a ton of experience with FPGAs).

I have used the base system design included and successfully was able to display images from the HDMI out on the board using an included demo. For the project I have in mind, however, I really want the HDMI port to function as a receive/sink port rather than transmit/source. All the other peripherals configured in the base system design are perfect for my application aside from the HDMI.

 

Is there a way to change the base system design to have the HDMI configured as receive rather than transmit? Or can someone direct me as to how to configure an IP block in Vivado for HDMI receive for the Zybo? I have no experience with Vivado or IP blocks or p cores or what have you, and while I have a basic understanding how the design flow in Vivado,a guide with beginners in mind would be appreciated.

 

This next part may sound dumb, but is just an idea: while looking through the schematic for the HDMI port, it seems that there is an HDMI_OEN pin (hdmi output enable?), and in Vivado a similar block that says HDMI_OEN is present above the IP block for the HDMI TX. Is it as simple as flipping the value on the HDMI_OEN pin? I feel that is too simple too work but just thought I'd include the info anyways in case it is useful or relevant.

Thanks,
Chris

[sbobrowicz]

Our only demo available for Video input on the ZYBO is the Gopro project described here: http://www.instructables.com/id/Quick-Start-Test-Demo-Zybo-Xlinx-Zynq-7000-Image-F/. The source for that project is found here, but unfortunately there is no tutorial currently for building the source: https://github.com/LariSan/Digilent-Maker/tree/master/Zybo/zybo_video_demo.

 

We are currently working on a project that uses Xilinx's Video Timing Controller IP and VDMA cores for video input from the HDMI port and Video output on the VGA port. It will also incorporate the dvi2rgb core found here: https://github.com/DigilentInc/vivado-library. This design will be targeted for Linux applications, and have video input/output drivers (DRM for output V4L2 for input). Its initial release will not likely have the easy to use Bare-metal libraries that the Base system design has, but future releases might incorporate something like that. The design has been a long time coming, as we've figured out how to make the drivers work properly. Can't give a definite timeline here, but it is not far from working on my machine. I will make another post here when it is completed. If you (or someone else) wants an update on this project, email support@digilentinc.com. If you have any questions on the current status, please ask them on this thread.

 

As for the HDMI_OEN pin, that simply controls whether the HPD and 5V rails on the HDMI connector are inputs or outputs. Driving it high causes the port to operate like a source, and driving it low causes it to act like a sink. Simply changing the value of this signal will not work because the rest of the design will still be trying to spit out video data instead of receiving it.

[digicloud14]

Thanks for your reply, Sam. In another post I made, someone else pointed me to that same DVI2RGB IP that you linked, and I've been working on incorporating that into my design. To expand a bit on my hobby project, what I'm trying to do is take in video input from the HDMI port on the Zybo and have access to the video data in a Linux environment on the board so that I can then send the HDMI video over the internet. Basically, I'm trying to create my own HDMI over IP type system (Like a reverse Chromecast). The project you described seems like it would go a long way towards helping me accomplish my project. I would love to receive updates on how that project is coming along. I'll definitely be sending an email to support@digilentinc.com. What should I put in the subject line so that my e-mail doesn't get buried?

[sbobrowicz]

Very cool application, perfectly suited for the ZYBO

 

Should be pretty straightforward once you get the HDMI port looking like a webcam (which the project we're working on does). There's plenty of third party linux software out there for hosting webcams on a server.

 

I've been monitoring the forums a lot more now, so I think the best way to request status updates is right here, not through the support e-mail. I'll still post here once it is completed.

[digicloud14]

Once I'm able to get the HDMI port working as input and somehow access the data in Linux, I agree the rest should be straight forward. Right now I'm working on using the DVI2RGB IP that's in the Digilent library you linked to with a VDMA core to hopefully write the video stream into memory. From there I'm hoping I can use V4L2 or MJPEG Streamer to take the video data in Linux and use VLC to stream over RTP to an Android app that I've been writing.

I know I've been asking a lot, but based on what I've told you about my project, and from your knowledge of the project you guys are currently working on, do you have any tips/advice/suggestions for me? If there's anything you could share from your project I would really appreciate it! I look forward to seeing what you guys have been working on!

Thanks,
Chris

[s35]

Hi Sam!

 

Could you please give us an update on the progress of the HDMI input V4L project? I hope you are very close on getting it running.

 

Tank you!

[digicloud14]

Hi,

Same as the poster above, wondering if there are any updates on the project you guys have been working on? Any information would be appreciated. Thanks!

Chris

[Anant]

Hi Sam,

 

Thank you for your insightful comments.Thanks to Chris as well for raising this interesting query.

While the project is in progress, I would greatly appreciate if you could kindly comment on the connections between [HDMI sink/source port], [dvi2rgb], [Xilinx VTC], [AXI VDMI] etc. The best help would be if you could share a snapshot of the XPS/Vivado block diagram. I am interested to learn how HDMI video data is transferred to Linux userspace via FPGA.

Another question is: are there any functional similarities/differences in dvi2rgb and hdmi_rx_0 (used in go pro bare-metal video demo)?

 

Thanks,

Anant

 

[digicloud14]

Anant,

Here is a snapshot of my current Vivado block diagram (there's a lot going on in it so the picture only shows the relevant HDMI components: DVI2RBG, Video In To AXI4 Stream, AXI VDMA). Image is here http://i.imgur.com/rdXtuOf.png

Also, check out my other post for a bit more info on the general design, found here: https://forum.digilentinc.com/topic/560-help-with-a-zybo-video-design/

 

[sbobrowicz]

Hey all,

Thanks for your patience, I got a chance to dig into this a bit more last week... I was able to put together the proper block diagram in Vivado IPI, but it looks like getting the Xilinx V4L2 driver to work is going to take more effort than I originally hoped. I need to write a driver that implements an endpoint for the HDMI input. In the Xilinx reference designs this is handled by the driver for the external HDMI decoder (ex. ADV7611), but we don't have such a decoder on the ZYBO. This means it is up to us to write an equivalent driver for the DVI2RGB IP core. My plan here is to look at what Xilinx has done for the Test pattern generator, and then implement a more simple version of that driver that doesn't allow you to change the resolution (since it will have to be locked to whatever the source is providing). Another wrinkle here is that it doesn't look like the VTC Linux driver implements any of the "detector mode" functionality, so detecting the frequency of the incoming video signal will require a bit more work. Here are a couple of the solutions I can think of:

1) Hardcode the resolution of the incoming signal in the  devicetree. Probably will break if the actual signal doesn't match, but would be the easiest to implement. 

2) Add detector mode functionality to the VTC core. Will need to work with Xilinx to make sure this is done in a way they would be willing to accept into their tree. This would likely be the cleanest, and would work well if using additional Xilinx Video Pipeline cores. Definitely much harder though.

I just stumbled upon some device tree bindings for what appears to be a very simple hdmi connector endpoint (Documentation/devicetree/bindings/video/hdmi-connector.txt), I'm going to try looking into this as another example for implementing a simple driver for the DVI2RGB core. 

Considering that this will take an unknown amount of time to figure out, I've decided to release the Video input project as just a simple bare-metal design first, before pursuing the Linux driver (similar to the ZYBO base system design software). I'll keep you posted on this, and post on the Wiki when completed.

Anant, Here is a shot of the block diagram for the project: 

It's pretty cluttered, mainly because it also has the cores for the Video output over VGA. There is a clock gen core we haven't released yet, and an additional pixel clock output on the DVI2RGB core (for those interested, its the same frequency as the regular pixel clock, only on the BUFG network, not the BUFR). 

Digicloud, Your block diagram looks good, though you might want to hook up one of those VTC cores in detector mode, so that you can detect the incoming resolution. I think this is necessary in order to set the VDMA up properly (unless the input resolution is known and fixed). 

[digicloud14]

Thanks for the update, Sam! The information is very helpful, thanks for providing your block diagram as well. I had a feeling the V4L2 driver would be the tricky part. I'll probably try and take the easy way out and just hardcode the resolution as you suggest. Will you come back and update here when you release the bare-metal design or will that be its own post? Also could you provide a link to the wiki you mention? Can't seem to find it through Google. Once again, thanks very much Sam, you have been incredibly helpful!

One more thing: You mentioned that there is an additional pixel clock output on the DVI2RGB core. The core I am using does not have that additional clock output, but you did say its the same frequency as the regular pixel clock. In my design, since I don't have that clock, do I just connect anything that would be connected to that to the regular pixel clock? I hope my question makes sense.

[Max]

Any updates on this?

 

Am interested in capturing DVI, and doubting between using a FPGA based solution like this, or trying to see if I can re-purpose one of those cheap Chinese Android/Google TV boxes that have HDMI input for the purpose.