HDMI / DVI-D input for an FPGA. - Page 1
Forum section: electronics / general

author: hamster_nz
author_rank: Super Contributor
timestamp: August 25, 2014, 08:59:16 pm
content: I've got HDMI (well, DVI-D) input to my FPGA from a real source up and running, in this case a Western Digital HD Live.It is currently running 640x480, but can run at 720p if the bit clock phase is manually tuned.Next steps are to automatically detecting and adjusting the bit clock phase and then EDID support.There is a bit of a build log onhttp://forum.gadgetfactory.net/index.php?/topic/2023-hdmi-input/if anybody is interested.

author: miguelvp
author_rank: Super Contributor
timestamp: August 25, 2014, 11:49:46 pm
content: Nice

author: Scrts
author_rank: Frequent Contributor
timestamp: August 26, 2014, 10:34:59 am
content: Cool!What frequency the input is running at? You only use simple LVDS inputs and you don't need the buffer in between? No transceivers?

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 26, 2014, 10:42:36 am
content: Which FPGA?Xilinx have a reference design for DVI and and out on a Spartan 6, and I think also S3, though ISTR the latter was a bit marginal.

author: hamster_nz
author_rank: Super Contributor
timestamp: August 26, 2014, 10:47:53 am
content: Quote from: Scrts on August 26, 2014, 10:34:59 amI'm actually using the FPGA's TMDS inputs, and the design is constrained for 13ns (75MHz) pixel clock (750Mb/s bit clock) - enough for 720p, I'm not using an transceivers or cable hiders (e.g.http://www.ti.com/product/tmds141), doing it cheap :-).

author: hamster_nz
author_rank: Super Contributor
timestamp: August 26, 2014, 11:15:51 am
content: Quote from: mikeselectricstuff on August 26, 2014, 10:42:36 amIt's currently using a Xilinx Spartan 6 LX9, but the design is tiny enough (3%) that it could fit in anything.Xilinx's reference design is in XAPP495 IIRC. However* it's in Verilog - not that that makes any real difference* all XAPP code is filled with (c) Xilinx headers - if you are going to put code out to the public then at least let us use it!* usually leverages some Coregen IPSo if I'm going to publish something I try to do everything myself. Yeah, I know I'm nuts to do that, but I find I actually find all the interesting problems that way, and I have no restrictions on distributing my code.So I also find if anybody asks me anything I can usually give a more sensible answer than "I just did what was in the AppNote" - things like setting up the clocking for the serializers, which is particularly gnarly the first time you try it.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 26, 2014, 11:29:08 am
content: Quote from: hamster_nz on August 26, 2014, 11:15:51 amNot a big deal unless you want to tweak it - I know no Verilog but managed to get it running in a VHDL design a while agoQuoteIs this an issue ? The whole point of publishing it is to get people to buy their FPGAs - Don't know what their exact terms are but I can't see that they'd have a problem with it being integrated into a design or redistributed with acknowledgement- it would be hard to argue that you're not allowed to uses sometheing they've published ass an appnote!What's the problem with Coregen? anyone implementing it on an S6 will be using their tools anywayQuoteI'm sure it will be a good learning experience and could produce something useful/different/better - good luck with it!

author: hamster_nz
author_rank: Super Contributor
timestamp: August 26, 2014, 11:51:02 am
content: Quote from: mikeselectricstuff on August 26, 2014, 11:29:08 amJust things like these random notes found in coregen created files:Code:-- This file is owned and controlled by Xilinx and must be used solely ---- for design, simulation, implementation and creation of design files ---- limited to Xilinx devices or technologies. Use with non-Xilinx ---- devices or technologies is expressly prohibited and immediately ---- terminates your license.andCode:-- (c) Copyright 1995-2014 Xilinx, Inc. ---- All rights reserved. --andCode:-- This file contains confidential and proprietary information-- of Xilinx, Inc. and is protected under U.S. and-- international copyright and other intellectual property-- laws.---- DISCLAIMER-- This disclaimer is not a license and does not grant any-- rights to the materials distributed herewith.I'd far rather just write a little bit more code than be seeking legal advice...If I do have to use Coregen IPs (most likely for FIFOs or memory) I usually leave them out, and say "generate your own XYZ, with these settings". This also resolves more practical issues like tools moaning about IP generated on a different versions.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 26, 2014, 12:16:03 pm
content: Quote from: hamster_nz on August 26, 2014, 11:51:02 amI'm not too familiar with Xilinx but isn't there some sort of config file for each IP core that effectively does that?I know in Lattice Diamond, it will recognise a version change and prompt to recompile cores.It can be hard to tell which of the gazillion files created by FPGA tools does what......

author: mrflibble
author_rank: Super Contributor
timestamp: August 26, 2014, 01:20:44 pm
content: Quote from: mikeselectricstuff on August 26, 2014, 12:16:03 pmThere is. You just distribute the .xco file, and then people can regenerate the core. And there willalwaysbe the practical issue of different versions, even if you do it the manual way. For a large enough version change you will have the problem of "generate your own XYZ, with these settings" not being unambiguous. In much the same way that automatically converting between versions can have it's issues.That said, rolling your own comes with the benefit of you learning something. As long as it's something worth learning go for it.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 26, 2014, 02:06:05 pm
content: Quote from: hamster_nz on August 26, 2014, 10:47:53 amBeware that FPGA pins are some of the weakest structures in modern electronics. Plug in a cable one day, POOF, every single pin driver turns into a nanoscopic puff of magic smoke! At the very least, put a good round of TVS and filtering on those pins to isolate them from outside nasties -- this isn't just production advice, you'll probably blow it sooner or later just in development alone -- it's a time saver!The biggest downside to high-speed signals is, you can't usually filter them that well, and you can't tolerate much capacitance from ESD protection diodes. So you have to use the low-C kind, that respond slower. 75MHz shouldn't be too bad to take the edge off those, though.Tim

author: miguelvp
author_rank: Super Contributor
timestamp: August 26, 2014, 03:31:35 pm
content: So, after you implement the Vesa EDID.... Audio, CEC?A bit off topic and not that you'll need it now that you are at this stage, but a while back I did find a paper about converting from TMDS to LVDS and it's somewhere in this forum, a quick search didn't find it so I'll dig deeper to find the paper.Edit, found it:http://m.eet.com/media/1135468/330072.pdf

author: marshallh
author_rank: Unknown
timestamp: August 26, 2014, 06:54:17 pm
content: Lattice has a ref design you might be able to lift some info from. No reg required

author: hamster_nz
author_rank: Super Contributor
timestamp: August 26, 2014, 09:55:28 pm
content: Quote from: T3sl4co1l on August 26, 2014, 02:06:05 pmHi Tim,I've been surprised just how robust the pins are. When tinkering with FPGAs my bench is my sofa, and my boards end up getting a lot of abuse - sitting on armrests, falling on carpet, lots of power cycles and I just have to try things 'ugly' out, like measuring short circuit currents for different drive strengths and IO standards.I've yet to break any of my FPGAs of the years I've been using them.About the only thing I am very careful about is to never connect any 5V logic to the pins, even indirectly. I was really, really careful with testing the TMDS board before I plugged it into the FPGA as it uses a mix of 5V and 3.3V signals. I might be a little bit dumb sometimes, but hopefully I'm not that stupid :-)Mike

author: darrell
author_rank: Regular Contributor
timestamp: August 27, 2014, 01:45:35 am
content: Quote from: mrflibble on August 26, 2014, 01:20:44 pmI like using TCL scripts to generate my project files and cores. With PlanAhead or Vivado, there is a TCL journal file written as you run GUI commands. I use that to guide creating the script. This is great with version control.Here is a Vivado example:https://github.com/HarmonInstruments/hififoRunning the Makefile results in a bitstream and Vivado project file that can be opened in the GUI. I do similarly in ISE, but don't have anything public.

author: vvanders
author_rank: Regular Contributor
timestamp: August 27, 2014, 01:58:33 am
content: Surprised the .1 headers don't add too much capacitance to the trace, I always thought that stuff was out of the range of mortals(and those with only ~100Mhz Scope).

author: darrell
author_rank: Regular Contributor
timestamp: August 27, 2014, 02:16:58 am
content: Quote from: hamster_nz on August 26, 2014, 11:51:02 amYou are taking the right approach. They don't allow distributing source code from coregen with very few exceptions.http://www.xilinx.com/support/documentation/sw_manuals/end-user-license-agreement.txt

author: mrflibble
author_rank: Super Contributor
timestamp: August 27, 2014, 06:00:29 pm
content: If you look at the contents of an .xco file however, you'll see that there are no particular restrictions on distributing that. So that boils down to:- thegeneratedHDL files do come with restrictions, so you don't distribute those- the .xco (source file if you will) does not come with restrictions, so distribute that- user runs "regenerate all cores" after importing your sources and tada, HDL filesThis does of course require that the user also has a license for this core, to be able to regenerate it. But that should not be an issue for at least the large number of cores that come with the free webpack edition. I suspect that the situation will be similar with Altera.That said, if you have the time to implement the entire IP portfolio included, go for it!But reinventing the wheel makes sense only so many times...

author: Rigby
author_rank: Super Contributor
timestamp: August 27, 2014, 06:12:49 pm
content: Quote from: mrflibble on August 27, 2014, 06:00:29 pmYup. Sometimes you just have to let them slide, choose another solution, or abandon the project in very rare circumstances. Gotta pick your battles.