Tmds Hdmi 2.1

[Adriene]

Theproject will not generate a bitstream because it fails with the error: "[DRC IOSTDTYPE-1] IOStandard Type: I/O port hdmi_tx_clk_n is Single-Ended but has an IOStandard of TMDS_33 which can only support Differential". In fact this error shows up for any of the HDMI ports I use.

You want to use both ieee.std_logic_1164 and ieee.numeric_std libraries. These are not the best combination of choices. I suggest either using ieee.numeric_std, or ieee.std_logic_1164 and either ieee.std_logic_unsigned or ieee.std_logic_signed depending on what format your want to work with. As it stands, you will likely run into conflicts with the synthesis tools as it tries to figure out what you mean by the '+' or '-' operators; if not in this project then in more complex ones.

Let's presume that you comment out ieee.numeric_std and go with the 1164 and unsigned libraries. You are constrained to putting std_logic or std_logic_vector types on your toplevel port list. The problem with this is that Vivado synthesis interprets these as single-ended IO signals requiring single-ended output buffers. You are probably thinking that since your constraints file declares IOSTANDARD TMDS_33, synthesis would understand that it needs to instantiate a differential output buffer. Unfortunately, this isn't how VIvado works. Don' ask me why, ask your tool vendor. Your only recourse is to explicitly instantiate an appropriate differential output buffer, like OBUFDS, in your code to help out synthesis understand your design.

This part of your question makes no sense at all. Of course your question is about both your VHDL and constraints; it always is. Your question is about a bitgen error that you have no idea how to resolve. The answer to your question is in your VHDL source.

If your HDL source doesn't explicitly instantiate input or output buffers, then the tool will try and instantiate one for you based on your HDL source. A couple of other hints is that logic IO buffers are distinct from clock IO buffers, and single-ended IO buffers are not the same as differential IO buffers.

Part of your confusion is that HDLs like VHDL and Verilog were not designed for logic synthesis. You'd think that after 40 years or so of allowing VHDL as a source for tools like Quartus or Vivado or ISE that HDLs would have kept up. They haven't, probably because there isn't much incentive for FPGA vendors to push for it.

The result of all of this is relevant to your problem: VHDL doesn't know anything about differential signalling. This means that you can't specify a differential signal directly in your VHDL source code. VHDL doesn't know anything about IO buffers either. This is all vendor specific. A lot of things that you might want to include in your VHDL are things that VHDL is ignorant about. You have to instantiate vendor specific macros or primitives instead.

Notably, vendors do allow you to put some of their vendor specific specifications, directives, and other information into your source that VHDL doesn't understand but that the tools do. Unfortunately, it's all vendor specific and worse yet completely arbitrary. Timing specifications is another area where HDLs are inadequate.

So, there's a disconnect between what the HDL can do and what is required by FPGA vendor tools. None of them let you put location constraints in your source code, which in my humble opinion, is where they belong.

In other technologies, third parties set definitions for how devices are specified and conform; MSI or LSI logic being an example. The vendors then conform to those standards. In the programmable logic world, this never happened. FPGA vendors would much rather do their own thing and make it hard to change vendors. So, HDLs are still in the 20th century and vendors design their synthesis tools to be unique and hard to port to other vendors tools.

Over the years I've seen a lot of attempts at creating a framework for FPGA design that is vendor agnostic. Some of them have very impressive, but limited, application demos to get people interested. None of the one's that I've come across are suitable alternatives to what the FPGA vendors want the world to look like.

What the world needs is a good 21st century HDL that lets you do your entire design using the HDL keywords. This would require programmable logic vendors to conform to a 3rd party specification for synthesis. I don't see that happening any time soon.

Thanks for the response. This same error is happening in a more substantial project, with other HDMI ports in use and actual (useful) circuit designs - I'm doing it all, no IP, partly as a hobby project. It simulates and even synthesizes with no issues. So my hope was to cut through the noise and recreate in a minimum-viable way for presenting the problem.

You want to use both ieee.std_logic_1164 and ieee.numeric_std libraries. These are not the best choices. I suggest either using ieee.numeric_std, or ieee.std_logic_1164 and either ieee.std_logic_unsigned or ieee.std_logic_signed depending on what format your want to work with. As it stands, you will likely run into conflicts with the synthesis tools as it tries to figure out what you mean by the '+' or '-' operators; if not in this project then in more complex ones.

I can muddle through reading Verilog so this is appreciated. I'm at hobby level so I can afford to choose language based on personal preference. I tried getting into Verilog a while back but ended up favoring VHDL... that is, until the day the mysterious "perfect HDL language" materializes from forum discussions into reality.

I am considering purchasing a Nexys Video dev board soon, but I have noticed the HDMI port is not connected to the GTP ports on the FPGA, just the standard IO ports. So I am wondering, can this board do 1080p 60fps with 24-bit RGB colour?

HDMI uses the TMDS standard and the Nexus Video does a good job implementing it. The mDP ports however do use two GTP transceivers per port. The Genesys2 is even better with 4 GTX transceivers per mDP port. Both boards are good platforms for video projects. You are correct about the Artix clocking limitations. The Kintex on the Genesys2 does better. Even the Spartan6 on the ATLYS board does better.... though Series7 devices have superior clocking than Spartan 6.

You'll have to do you due diligence to determine what platform is best for your video needs. An alternative to the Nexys Video is the Numato Labs Mimas-A7 which is also an Artix board but with a smaller part than the Nexys Video A100T. I've used all of these for successful project development.

The IO banks on the Nexys Video and Genesys2 boards for the HDMI ports use Vccio = 3.3V so, even if the board design allowed for LVDS ( they don't) the Diligent boards can't so LVDS. It's complicated.. so do your homework if you have certain video requirements to meet.

The Genesys2 is even better with 4 GTX transceivers per mDP port. Both boards are good platforms for video projects. You are correct about the Artix clocking limitations. The Kintex on the Genesys2 does better.

Genysys 2 look great, but is about double the cost and if I am not mistaken the Kintex requires a Vivado licence which I believe is included for 1 year with the Genysis 2, but then requires to be paid for, so not really an option for me due to the cost.

An alternative to the Nexys Video is the Numato Labs Mimas-A7 which is also an Artix board but with a smaller part than the Nexys Video A100T. I've used all of these for successful project development.

3a8082e126