HDMI / DVI-D input for an FPGA.

[hamster_nz]

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 on http://forum.gadgetfactory.net/index.php?/topic/2023-hdmi-input/ if anybody is interested.

[miguelvp]

Nice 

[Scrts]

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?

[mikeselectricstuff]

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.

[hamster_nz]

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?

I'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 :-).

[hamster_nz]

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.

It'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 IP

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

[mikeselectricstuff]

* it's in Verilog - not that that makes any real difference

Not 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 ago

* 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 IP

Is 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 anyway

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

I'm sure it will be a good learning experience and could produce something useful/different/better - good luck with it!

[hamster_nz]

Is 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 anyway

Just things like these random notes found in coregen created files:

Code: [Select]

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

and
 

Code: [Select]

--    (c) Copyright 1995-2014 Xilinx, Inc.                                    --
--    All rights reserved.                                                    --

and

Code: [Select]

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

[mikeselectricstuff]

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.

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

[mrflibble]

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.

I'm not too familiar with Xilinx but isn't there some sort of config file for each IP core that  effectively does that?

There is. You just distribute the .xco file, and then people can regenerate the core. And there will always be 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.

[T3sl4co1l]

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?

I'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 :-).

Beware 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

[miguelvp]

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

[marshallh]

Lattice has a ref design you might be able to lift some info from. No reg required

[hamster_nz]

[Beware 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

Hi 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

[darrell]

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.

I'm not too familiar with Xilinx but isn't there some sort of config file for each IP core that  effectively does that?

There is. You just distribute the .xco file, and then people can regenerate the core. And there will always be 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.

I 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/hififo
Running 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.

[vvanders]

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

[darrell]

I'd far rather just write a little bit more code than be seeking legal advice...

You 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

[mrflibble]

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:

- the generated HDL 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 files

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

[Rigby]

reinventing the wheel makes sense only so many times...

Yup.  Sometimes you just have to let them slide, choose another solution, or abandon the project in very rare circumstances.  Gotta pick your battles.