asmi

What do you mean by "dual channel mode"?

I can certainly put that in as customer feedback, though with the SD cards current location, I fear it would entail an entire PCB spin to put the SD card on the side with regards to rerouting. Maybe it could simply be rotated with minimal PCB routing rework though (I'm not a hardware engineer, so my perspective is limited on this front).
I don't know the story of why the SD card is in the middle of the board, but I would like to to think that the decision wasn't made lightly, considering that every other Digilent board (including multiple made by the same lead engineer on the Genesys ZU boards).
But at the same time, I also just noticed that the SD card housing has the open and lock instructions with arrows directly etched onto it... Regardless, it's at least clear to me that it is not a well received design choice, so I will do my best to help make sure it is not the housing of choice in the future.
Thanks,
JColvin

You might want to consider uploading a Zynq preset (.tcl file) for those who don't want to use the board files for some reason, as that preset file will let them configure Zynq to the board specification. If you open Zynq's IP dialog, there are options to save/load presets, that's how you can generate this file.

You might want to consider uploading a Zynq preset (.tcl file) for those who don't want to use the board files for some reason, as that preset file will let them configure Zynq to the board specification. If you open Zynq's IP dialog, there are options to save/load presets, that's how you can generate this file.

I had these issues in the past, and I traced them to a realtime backup solution I used (OneDrive). Apparently the likes of OneDrive (also Dropbox, Synology Drive and others) somehow interfere with MIG, but once I've gotten rid of it (by moving my projects outside of OneDrive replicated folder), all problems went away. To make sure my projects are still backed up, I set up the Synology Drive (I have a Synology NAS in my network, so using their solution was an obvious choice for me) to perform backup daily during the night when I'm not using my PC instead of realtime backups. So if you still experience those and use any of those things I mentioned above, try moving your projects outside of them and see if problem still persists.

I'm pretty sure it's an active-low, but you can measure it with a multimeter just to be sure. As for duration, it's an asyncronous reset, so it can be of any length.

As per manual:
So no 1.5 Gbps. Also watch out for the pinout - it seems like each MIPI device's manufacturer feels an obligation to invent his own pinout and ensure it's not compatible with any other devices.

Thanks, fixed it!

Some of us can't handle the high glycemic index beverages...

P.S. The "secret" is explained in detail by Xilinx in Appendix E of User Guide UG908: 
https://docs.xilinx.com/r/en-US/ug908-vivado-programming-debugging/JTAG-Cables-and-Devices-Supported-by-hw_server
For FTDI devices to be recognized as a USB-to-JTAG interface in Xilinx® JTAG software tools such as XSDB or the Vivado® Hardware Manger the EEPROM on the FTDI device must be programmed with a custom firmware provided by Xilinx. Programming the FTDI is accomplished by using the program_ftdi utility included in the Vivado install as a Tcl command. Once programmed, the FTDI device will be recognized as a valid programming cable in Vivado.
Note: For on-board implementation details including FTDI connectivity, please reference the Xilinx VCK190 Schematics available in XTP610 on https://www.xilinx.com/products/boards-and-kits/vck190.html.
The program_ftdi utility supports the following FTDI devices: • FT232H • FT2232H • FT4232H
The "program_ftdi" utility may be used to read out configuration information from the board/cable.  When used with read, the command reads back the content of FTDI EEPROM to standard out. if -fileout option is used, the read back information is written to the file specified.
The connection is using ABUS0..ABUS6 for JTAG signals, sensing the power and resetting the board. The pin assignment for JTAG interface and the descriptions of the signals are shown in Table 3.7 of FT2232H and FT4232H datasheet.
Again, it is a shame that the board intended to help Xilinx in selling their products attempts to confuse users by hiding the information. 

You can install "Enterprise" version if you want, as all license checks are performed when you start synthesis/P&R. You can use Enterpise without a license as long as you only use it for devices which are included into WebPack license (or devices covered by separate device-locked licenses you have). There is no real difference between "WebPack" and "Full" version, except the latter has support for all devices.

Right now there is only one devboard available, from Opal Kelly with AU25P device. I've sent them enquiry about acquiring some 10/15U devices to build a devboard for our internal evaluation, we'll see what they say, but I suspect with the semiconductor shortages it won't be easy, though if I would be them, I'd reserve a chunk of the first batch specifically for samples to get them out to the field to secure future volume orders.

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.

Nexys Video houses Artix FPGA and so can only drive DDR3 up to 400 MHz (for DDR3) or 333 MHz (for DDR3L). I would love to know how have you managed to run it at 600 MHz.

It's not something I'm really proud of, but I know next to nothing about Yocto and yet I was able to build Linux images for both Zynq and Microblaze just fine. So while it no doubt will be helpful to know about these things, this is not a strict requirement.
You can boot Linux via JTAG without ever touching any of non-volatile memory. This is how I do it during design, because it's faster than programming flash every time I want to change something.
That I fully agree with. Playing with Petalinux can be fun, but it's a deep rabbit hole in it's own right. It's better to get to grips with the actual FPGA side first.

I don't know for sure, you need to check if there is a driver for that chip in Petalinux.

PCI Express has insane latency compared to AXI HP bus available for Zynq. It also requires, well, actual PCI Express host, while Zynq solution is self-contained on a single chip. Zynq DDR3 controller peaks at a bit over 4GB/s, which is enough for a lot of applications. If your design need more, you can add another memory controller in PL, but I suspect that fabric speed will become a limiting factor somewhere in that area. You can step up to Zynq-030, which sports faster Kintex fabric and can implement 933 MHz DDR3 controller, which will give you all the bandwidth you'll ever need, and you can set up your design such that ARM CPUs will have access to part (or all) of that memory as well as that of the hardIP side - the limiting factor here is address space, but this can be side-stepped by banking.
Seriously? External board with PCIE and a PCIE card with FPGA is cheaper/better/easier than just a single chip?
I don't have any commercial experience with it myself, but some of my customers did some designs on a board I built for them, so my experience is only anecdotal. That said, these customers were super-happy with results, with the main advantage being time to market, so there is definitely a place for it. Again, yet another tool in our toolbox to learn about so that we can use it when a need arises.
That is one possible use case, but Vitis HLS basically produces IP blocks that can be connected to any other logic in Vivado, you can use them even with pure FPGAs like Artix. HLS is great for stuff like advanced math, FFT, image processing via OpenCV, as Xilinx includes a library of these functions ready to be used in your C/C++ code, allowing for extremely fast iterations - as you can debug your code as a regular C/C++ application, with compilation being pretty much instant, and only move to hardware once you've ensured that your code works properly - and even here you can use the very same C/C++ testbench you used to debug your code, to run a co-simulation to verify that generated core still works properly.
If you are interested and have some time, I recommend you to watch the following YT playlist: https://www.youtube.com/playlist?list=PLo7bVbJhQ6qzK6ELKCm8H_WEzzcr5YXHC They are one of the best video tutorials I've seen on this subject, even if they are a bit dated.

Nothing is swapped around here - PMF part just uses different naming - Micron uses DQxx names for both first data lane (DQ0-DQ7) and the second one (DQ8-DQ15), while PMF use per-lane notation - DQL0-DQL7 for the first data lane, and DQU0-DQU7 for the second one. The actual pins ball locations are still the same. Which is why it should not matter if you use one or the other - FPGA pinout should remain the same.

What? DDR3 pinout is a JEDEC standard, all memory modules have identical pinout.

At this point I can only offer any help if you can publish the full project with all sources, as the problem can be anywhere.

XC7Z030 is included in the free WebPack license.

XC7Z030's fabric is based on Kintex-7 FPGA, while XC7Z020 and below are based on Artix, and Kintex fabric is significantly faster. So I guess if you get your design to work in 020 and below, it will guarantee that it will work in 030, but there is a whole bunch of projects which will only work in 030. In that sense, some Kintex-based devboard would be more adequate for prototyping, unless your design leans heavily on CPUs and so using Zynq is absolutely essential.
You can also do quite a bit in a simulation without ever having a board in your hands - using qemu for the Linux part (it's directly supported by Petalinux toolchain provided by Xilinx) and whatever HDL sim of your choice for FPGA part.