coldfiremc

Yes, please create a pull request.

There was a time when I paid for Altera and Xilinx tools. As an independent contractor the level of support that I got wasn't particularly useful for solving most issues. Back then I could (possibly) get help from distributor or vendor sales offices or FAEs for whom I had contact information. It was a matter of luck, but sometimes I'd get a hold of someone with the necessary answers to a particular problem. I just don't put much hope in getting useful assistance from large vendors any more. Even when I worked for companies purchasing large** volumes of product the level of technical support available to them wasn't that impressive, unless you had direct contact with the right person outside of the normal support chain.
Anyway, as I mentioned in the tutorial, I mentioned issues I encountered because I think that it's beneficial for those without a long history of dealing with FPGA or semiconductor vendors. Sometimes, it's not you; it's the vendors causing problems. Integrated tools like Vivado have a lot of software dependencies which makes virtually every PC  unique and hence tool behavior unique.. to a degree. Things that I encounter may not be what anyone else encounters.
If you encounter issues that appear to be tool related by all means use whatever path for resolving these is available to you. I wish you only good fortune.
As for the working poor*** it seems that the best way to get assistance with tool issues is to talk about them and share experiences, much the way that local organic user's groups have done in the past.  I suspect that a huge percentage of users of the Digilent forums are pretty much on their own when it comes to obtaining shared technical knowledge that isn't readily available from vendor resources.
** I don't know what this means to a company like Xilinx these days but I'm guessing that it's north of $100 million to get top notch support.
*** You can be an employee of a very large manufacturer and find yourself in the catagory

I just looked at Spartan 7 to see if it uses the same MiG as the other Series 7 devices; it does. Follow the tutorial with regards to checking the datasheet for DDR PHY clocking rates. This will likely dictate whether you have a  4:1 or 2:1 controller ( assuming that the MiG for Spartan 7 is the same as Series 7 devices ). I'd advise going to the Digilent product page for your board and using any MiG ,prj and .ucf files that are provided as a starting point. You want to at least start with a working DDR design before trying to add external memory to another project. You will have to edit the ucf file as the Mig gets confused with anything but pin location assignments as I mentioned in the tutorial. Even though the Mig project file is in HTML format you can read it in a text editor to see what settings you should start off with. I've request that Digilent provide a pin location constraints file for their boards that is compatible with the Mig tool but haven't gotten a response.
 
Any logic connected to the UI, such as issuing read or write commands to the DDR controller UI, will need to use the ui_clk. But the rest of your design can use any clock rate. The NexysVideoDdrDemo.vhd project in the 2nd part of the tutorial shows how to do this and pass data between clock domains. The more clock domains you have, the more complicated will be timing closure, especially of the clocks are unrelated. I'd suggest following the example in part 2 of the tutorial. You should spend some time reading the  clocking reference manual for your device. There are a lot of rules and limitations. Once a board has been laid out and pins are assigned to external clock module inputs you can't change them. Often the tools will issue a warning or bitgen failure and you might have to add a constraint such as CLOCK_DEDICATED_ROUTE constraint to your toplevel project constraints file to over-ride the tool behavior. This is due to the board design.

For designs that need to issue commands to the MiG DDR controller as fast as possible you might have to restructure you design to use the ui_clk for the bulk of your design in order to achieve timing closure. Most of the board test results that I added posts about were done with a modified version of the NexysVideoDdrTest.vhd code to issue commands to the DDR as fast as the Mig IP allows. The problem for timing has to do with the behavior of the UI app_rdy signal. For the third part of the tutorial I wanted to simplify the design to emphasize the UI operation so that anyone could add an ILA and see how it operates. For NexysVideoDdrTest it should be obvious that this design can only issue write or read commands once every 4 ui_clk periods. The DDR interface is fast enough that this is often sufficient for most projects. That design was changed considerably for the performance posts of other boards. How one goes about doing that is left as a personal assignment for the reader. The MiG example project is one wy to do it but is almost unreadable. Parameters can be useful or a hindrance.

For really high throughput external memory designs such as the UltraScale+ DDR4 the high data rate might be a problem requiring a design approach that is more complicated than you want to do.

Don't hesitate to ask questions about the code if you are struggling. It seems pretty straightforward to me, but then again I wrote it.

I haven't found the official Xilinx User Community Forums to be particularly helpful... especially with tool version bugs.
I agree. Intel boards tend to have more clock input options, even on cheaper boards. But of course the Intel clocking tends to be more restrictive than Xilinx devices. Still, for the higher end Digilent boards there's no excuse for not having at least one high quality programmable clock module, and more IO banks connected to external clocks. this wouldn't have to add much expense to the board but would significantly improve board application usefulness. I don't think that Digilent's boards are designed by engineers who actually want to use them for real world project design... sigh! The Eclypse-Z7 is the worst example of hamstringing a board by making poor design decisions.
For UltraScale+ PL connected DDR4 you simply can't feed the DDR4 controller a MMCM or PLL generated clock.. it hast to be a high quality clock on clock capable pins.
Unfortunately, I don't design the boards.. I just have to make the best of what I get. Xilinx branded boards tend to be more realistically designed for actual use but they cost a lot more too ( not because of the better clocking options ).

Lol What makes you think that this issue won't affect some other parts of your project? Did you run simulations to see what's going on - like does your data actually reach memory controller intact, and all byte enables are set properly? The latter is very common mistake, I myself screwed it up more times than I'm willing to admit, even though I know of this trap all too well.
Lower frequencies won't help you because whatever issue you've got is going to manifest itself anyways. If anything, it's good that you have a clear way to reproduce that issue. Now run some sims to see where exactly your data is lost on it's way to the memory controller (or on the way back from it - the issue just as well might be on a reading side of things).
 
AXI can't possibly have any overhead - it's just a bus, which is simply a bunch of wires.

This is absolutely wrong way to do it. Leave DDR3 at nominal frequency, and use AXI Interconnect/crossbar or a FIFO to move the data from your application clock domain to the memory clock domain. Also check that you've properly constrained your design - there might be undiscovered timing issues. Whatever the issue is, it's definitely got nothing to do with DDR3 controller, so look for issues in your own code.

The Mig IP doesn't allow you to assign the system_clock as the reference_clock input unless the Input Clock period is set to 5000ps ( 200 MHz ). Why is that?
According to the Series7 Select IO manual the reference clock for IDELAY can be 190-210 MHz or 290-310 MHz. According to the Artix datasheet we should be able to use either a 200 MHz or 300 MHz IDELAY reference clock for the -1 speed grade. So why doesn't the IP allow for using a 300 MHz system clock as the reference clock for the Nexys Video? The answer is that I don't know.
Interestingly, for the Nexys Video board, if you go with the Vivado 2019.1 default 2:1 controller PHY clock period of 3225ps this translates to a PHY clock of 310.0078 MHz. The MMCM math starts to become a problem, especially if you want a high quality clock for your DDR; and you do.

I will have a look at this as soon as I have some time.

thank you for your answer,
yes the TV shows no input signal, it's like the camera is not connected to the TV. when i connect the camera directly to the TV it works fine so the camera is functining.
I changed the dvi2rgb and rgb2dvi to 720p, the camera is also 720p but nothing changed also connecting pLocked to aRst_n of the next IP doesn't work. dvi2rgb.xdc also no success. I will try to debug and let you know.  @coldfiremc the block is not optimized or deleted.
thanks

Hello everyone,
i am trying to make an HDMI passthrough but i get only a blackscreen. Any idea why?
the camera used is Sony action cam HDR- as200v res 720p, 24p, tcout mp4, and connected to ZYBO HDMI RX. Output from ZYBO HDMI TX to TV.
all settings are in attachment
constant0 st set on 0 value.
constant1 is set on 1 value.
thank you in advance.

I've spent many an hour over the years looking into connecting various converter EVMs to Digilent FPGA boards and I can tell you that this is tricky and requires a lot of work, even if the EVM has a compatible FMC connector.
The first place, before you start thinking about timing constraints, is to understand the advanced IO features of the FPGA you will be using. This means reading the Series7 Select IO and clocking reference manuals very carefully. There are rules and limitations to understand that aren't obvious to someone without prior experience. Xilinx offers a number of application notes with sources that can be informative, but you need to know what questions to ask as you go over them. These will help you understand the mechanics of how to get LVDS working. 14x LVDS isn't the same as 7x LVDS.
Since you already have the FPGA platform decided on the easiest path would be to use an ADC EVM that has an LPC FMC connector and comes with demonstration support. Since you didn't mention your converter requirements, I won't mention the subject except to say that not all converters are appropriate for all applications, especially those aimed at comms. Be aware that a lot of vendors use the connector that the FMC standard uses. This doesn't necessarily mean that they are compatible with Vita57 or any particular standard... just that the connector was used. Even if the EVM is Vita57 compatible there are still potential issues for LVDS greater than 8x data rates. You need to confirm not only connectivity of signals between the EVM ADC and the FPGA but that the data and clocks make it to the right IO bank according to the rules for your device. ADI has a number of EVMs that come with demonstration projects to work with specific FPGA platforms. ADI has better FPGA support than other vendors. It's typical, especially for high speed converter devices, for vendors to require that EVMs be used with another expensive control board. Understand that most converter EVMs are designed for confirming specifications only, not for use in a real world project application. The vendors don't want to be in competition with their customers for obvious reasons.
If you are going to select an ADC EVM without an FMC connector then you have to figure out how to connect the two boards. Working with even the LPC FMC connector isn't trivial. Expect to use at least 4 signal layers on any adapter PCB you might design. Differential routing for very high speed signals requires more than just matched _n and _p length matching. You likely need to implement proper differential signal routing. If you use wires or cables then you need twisted pair cabling. Even if you find a cheap way to do this routing signals to a custom cable assembly header isn't trivial. Be aware that converter EMVs may be set up is a way that isn't compatible with your application needs.
Assuming that you've worked out all of the connectivity issues you should read everything that Xilinx documentation has to offer concerning timing closure and constraints. The material tends to be out of date with respect to the tool versions. The main GUI page of Vivado offers templates for all manner of constraint syntax if you plan on writing your own constraints; that's how I prefer to do things. In my experience though the templates aren't necessarily that helpful as I've followed them on many occasions only to have the tools reject the syntax, and constraint, without sufficient guidance. Usually though you can do enough googling to figure out how to correct the syntax to work with your VIvado version. You can also use the Vivado TCL console to get help with just about any detail including syntax. Personally, I don't I don't find the constraints wizard to be all that helpful.
The real head-scratchers come when you get into the details.
My main point here is that figuring out what the vital details are and working out a solution often can't be worked out after selecting hardware, so get it right before you commit to hardware. All of the observations above assume that you've already worked out the timing according to the AC specifications for your FPGA device.

I'd be surprised if the single-ended signals for the Eclypse-Z7 ZMOD ports are "laid out as differential" based on other boards that they've done. There's more to high speed PCB trace routing than just trace dimensions and relative spacing.
Start another post asking for someone at Digilent to provide the trace length report for Eclypse-Z7 ZMOD signals. I doubt that Digilent wants to publish Gerber files.

Make sure that you understand the SYZYGY DNA process and how it's implemented on the carrier board that you want to connect your add-on board to. Go to Opal Kelly's web site to get the pertinent SYZYGY standard documentation.

It look like you board flow interfaces are not picked up. Dig further.

If you open the synthesized design and navigate to the InputBuffer cell of dvi2rgb you will probably see the input tied to a constant, which causes placement to complain. Check the block design where the TMDS port of IP is tied to. It must go to a top-level port and it has to be constrained to a pin. If you are using board flow and it connects to a board interface, it should be set. Check the top-level wrapper vhd to confirm the top-level ports are generated for the HDMI/DVI input.

The assertion that a newer version of Vivado has a different idea of which pins for a particular device are appropriate for clock inputs than earlier ones is a makes for a valid question.
@BYTEMANare you sure that you have selected the correct device, including package, in the Vivado device settings for both versions of the tools correctly when generating a bitstream from the sources?
I haven't tied to replicate your observation but suspect that something other than a tool bug is going on.
[edit] While sometimes vendors lay out PCBs with inappropriate routing of external clock inputs, this is not the case with the CMOD-A7.  As you can see in the master constraints file: "#IO_L12P_T1_MRCC_14 Sch=gclk" gclk is on an MRCC pin which is perfectly valid. Always refer to the schematic for location constraints.
I just looked at a project from last year for the CMOD-A735T built with Vivado 2019.1 and didn't run into this error message.
[edit2] When confronted with unexpected error messages from synthesis, implementation or bitgen you can often find clues to the root of the problem in the vast list of warnings. Start with the synthesis warnings first. Sometimes, constraints are ignored; sometimes due to changes in syntax incorporated in newer versions of the tools. Again, reading the warnings will help.

Thanks for all the info, seems that if I want proper timings at 1080p, 60Hz, 24-bit colour I am best just using the ADV7513 (or similar). Considering the IC's are only £14 from RS Components and they are purpose built for the job, it seems going that route is first of all, less headache and second of all, likely to yield superior results. Not to mention the cost saving vs a Genesys 2! Just need to make up a custom PCB so it can interface to the FPGA via the FMC connector, not a big deal.
 
As for the Geneys 2, I cannot justify an extra £600 over the Nexys Video, it's just not worth it, even future projects I have involving FPGA's are likely to require lesser devices than the Nexys Video, probably stuff I can do with my current Basys 3. Maybe in future I can re-visit the Genesys, but not just now.
 
However I might re-visit this topic after I get everything fully functional with my project and have completed boards made up and the project is all but finished. Just to see how well I can make it run without the ADV7513 for my own curiosity.
 
Seems that the Nexys Video should be able to do 720p & 1080i at 60Hz with 24-bit colour without too much hassle, even 1080p 30Hz with 24-bit colour depth should be fine, but getting it up to 1080p, 60Hz & 24-bit colour I think will have her running a bit hot.
 
Thanks for all the info so far, especially that IP core! Really good to have that, but I think the answer as to "how did Digilent do it on their demo" (for anyone who finds this thread in the future) is that if they are indeed outputting 24-bit colour, then the only solution has to be running the FPGA out of spec and effectively over-clock it.

Download "vivado-library" and the constraints repo. Nexys video has its own ip to get hdmi output based on oserdese2, its source code is available in the IP itself. It's called "rgb to DVI". It's enough to get 1080p withut problems. You have to put a clock wizard with pixel and serial clocks to make it flexible for any hdmi or DVI mode. I Have a "bare bones" design to get video from hdmi with that. I will upload it to my repo soon