zygot

@jb9631
I don't think that your post fit the category of derailing, or even hijacking, the thread started by @escou64. Most if the content is directly applicable. Some are tangential... but still relevant. Personally, I find that the tangential can be more informative than people tend to realize. Usually, people posting to a site like this one have a single-minded desire to get past a wall blocking them from completing a project, and have no interest in learning about the details, much less the tangential ones. But it's those tangential bits of knowledge and perspective that make dealing with the next hard challenge a bit easier to tackle. So, based on your post, here are a few thoughts that may be worth reading, or not, depending on how you approach FPGA development.
Historical context can be very informative and helpful in dealing with FPGA vendor tools and IP that are hard to decompose. The vendors would rather have customers that are only interested in completing the task before them now, preferably using the handful of vendor IP that the tools offer, not concerned with the details of how they work. There's nothing wrong about wanting the tools to do your work for you, and not caring about learning details... as long as the tools get the job done. If you are going to spend a lot of time doing FPGA development, particularly using the 'advanced' features of the devices, then you are likely to get idisabused of that model very quickly. If you understand the features of those old Spartan 3 devices, it's a pretty fascinating journey comparing those ancient families to the most recent ones. I have no doubt that implementation design improvements and FAB node evolution has made the basic clocking and IO features better, in most ways. But not better, necessarily, for all customer needs. I don't just use one FPGA vendor. It's interesting how the two giants in the market have copied what the other does, both in terms of device capabilities and features, and tool experiences. There was a time when Altera tools were so much more stable and bug free, compared to its rival, that many companies selected programmable devices on the merits of the tools alone. Those days are gone as all of the software that makes the tools has gotten too complex to manage. There are two spheres of reality concerning the tools. There's the stuff that the customer can see, that is the GUI, the tcl, pearls and other scripts that setup and create the vendor IP and connect all of the sources together, and the executable software where the 'magic' happens and sources are turned into bitstreams. In my lengthy experience,regardless of the silicon device documentation in the way of datasheets, application notes, and such have always been a bit short of details, or just plain wrong, when the customer is faced with difficulties using a device for a particular purpose. Undeniably, part or most of this is due to how difficult it is to write, much less maintain documentation that's error free. Also true, is that this is an opportunity to game the customer experience with vendor devices in favor of the vendor. I won't elaborate because this discussion is more worthy of book writing than forum posting. My point is that sometimes one just has no option other than embarking on a quest for the holy grail, which in this context means understanding details and conducting an extensive hunt for relevant information that separates the nonsense from the necessary facts. There is no 'conspiracy theory' at work here... just the unfortunate side of how people and companies make money and compete in the marketplace. I mentioned that one facet of programmable logic that the customer can't ever parse, the inner workings of the executable(s) that grind out loadable bitstreams used to configure programmable logic devices.. that is the tool software. It's always been the case that what goes on behind the curtain isn't exactly what the documentation and all of those IP, timing and project related scripts would suggest. If one wants to use the advanced features of UltraScale devices, this becomes all the more clearer. A lot of control and implementation details are really done in the tool software. This most certainly puts the advantage in favor of the vendor in terms of what a customer can do with vendor devices and, in the end, how income gets generated. In my experience there has always been, for certain projects a disconnect between what vendor documentation says and actual implementation experience when using some device features. With UltraScale this boundary between what the documentation says about how certain features are implemented and what's actually controlled behind the curtain is just more apparent; never mind the trend to more encrypted sources and less control for the user. In the case of the other major FPGA vendor there's no embarrassment about using the vendor documentation, tools and scripts to 'encourage' customers toward a path that results in greater dependency on the part of the customer and a greater income stream for the vendor. All of these things are interconnected. I'm a bit less capable of being succinct, but I do think that for some people there's a lot more to consider than just being able to use vendor supplied resources to complete a particular objective for doing programmable logic development effectively and efficiently. Hopefully, my thoughts are worth thinking about. If not, you've probably not gotten this far and that's OK with me. What's boring or meaningless to one person might be a helpful spark of insight to another.

Yes, I understand what you are trying to do. For background, the Spartan 6 devices had a hard external memory controller supporting multiple channels. When Xilinx abandoned the hard controller in the Series 7 family it also abandoned the multi-channel external memory model, now implemented in logic. That might tell you something. I believe that there might be a path to a multi-channel external memory controller using AXI IP, which is completely at odds with an all HDL design flow in my opinion. I haven't explored this avenue. In theory you might be able to achieve your VDMA goals but it's likely a bit harder than you imagine. That's why I suggest starting off with a basic design project using the Mig IP as at start. In my experience, vital knowledge is gained by struggling with incremental changes in design complexity. Knowledge isn't just what you read; it's how you connect the basic details conceptually, how you understand the subtle interactions and minutiae of what's going on in your logic. You can't get that by skipping ahead to the final result for complex designs. I'd put DDR in the complex design category. The content in your post tells me that you are stuck. To me that says that your experience and debugging skills haven't quite prepared you for this project. Sometimes you can get lucky and solve problems without having an intimate knowledge of the details of the inner workings... usually you don't get to be lucky.

Simulating a design using the Mig IP is certainly not impossible. It is a vital skill however, just hard to do due to the way that the IP was implemented. I do encourage you to simulate a basic design usiing the IP. The fruit of the effort will be more than worth the time and energy that it will take. Do use Verilog for your toplevel module if you want to succeed in simulating the Mig.

You can read the Mig IP user manual for details about it's debug facility to determine if it's worth the added complexity in source code and implementation.

The ILA is a quick and relatively painless way to peek into your hardware as it operates. It's also very limited in triggering capability to capture specific events related to complex logic states. It's amazing what a state machine, a FIFO and an a UART can to to aid complicated debugging that the ILA can't or has a hard time with. Vivado debug facilities can become unusable debugging some designs. I know this from experience.

I realize that you see a fairly simple and straight line for accomplishing your project goals. This might be because you lack the comprehension and understanding of how the logic actually operates. Start with a careful reading of the Mig IP user's manual to get a sense of what the moving parts are. Gain skill and knowledge by starting with someting that works and progressing toward your ultimate goal. Broaden range of tools in your debugging toolbox to include simulation and custom debug IP that you've written and tested.

The tutorial isn't completed byt the way. I haven't yet included the simulation part. I've simulated Xilinx Mig designs but haven't worked out how to present the information the way that I want suitable for rest of the tutorial. It's complicated and not well documented. One hint is to have an all Verilog design and testbench. Another is to short-circuit the calibration phase as this encompasses too much simulation time to the point where the simulator is too slow to be functional. Some knowledge is available in things that you can read and some knowledge only comes from doing, failing, figuring out an way around obstacles and 'rinse and repeat until success'.

FPGA devices don't have 'internal' clock' sources.

You can use an MMCM or PLL to take the only external clock available on CMODs, the 12 MHz USB clock, and create suitable clock of just about any frequency ( there are limitations due to how the clocking resources in the MMCM and PLL work ) to clock your logic.

Read the Series 7 reference manuals for information. The material for your VIvado installation are available through the Xilinx Document Navigator.

Read the datasheet for information about capabilities of any particular device and speed grade. Expecting to clock a design at the maximum clock frequency in the datasheet is likely to be overly optimistic. I heartily recommend taking advantage of the FPGA substrate temperature sensor for Series 7 designs as most boards aren't designed to support the power supply needs or heat dissipation requirements for all designs that can fit in the FPGA. This is particularly true for the CMOD boards.

I wasn't trying to 'upsell' you. I've rowed many a dingy into hostile waters and have come to the conclusion that if a project is worth doing wasting time trying to overcome design limitations on the wrong platform just isn't worth the hassle.

I don't think that you'll have trouble figuring out your plan B.

I do encourage you to take advantage of one thing that Vivado does offer; that is you can create a design for any board that exists and see how the resource match up to your project requirements. You can't generate a bitstream for the Genesys2 without a device license or the full-fat ( high-priced ) tool version but you don't have to in order to prototype an idea and see hwo it might work out on a platform that you might consider splurging on. If you do the HDL design flow you can simulate everything. Creating good simulation models for external hardware is generally a iterative process but you can still learn a lot by simulating even a crude approximation of your external hardware. All it takes is time. If you know what you are doing most of the work will be an investment in the final project effort. Seem to me that you know what you are doing; even better know what to do to get to where you know how to do something that you've never done before.

Separating the marketing hype from the facts always requires a bit of spelunking. Often the answers are hidden in some deep remote crevice of the cave.

OTG Host mode requires quite a bit of software to support the hardware capabilities. If it were easy Xilinx would have application notes and design examples. They don't. That says something about their commitment to their products and customers. Unfortunately, it doesn't stop them from providing hope in the form of unreasonable expectations. I suppose that these days, that's par for the course.

Anyway, before selecting a design architecture, it's always good practice to find evidence supporting idea that a feature, implied or stated, can actually be implemented with a reasonable effort, using the vendor design and development tools.

Sometimes, a trip to the ARM website for technical information can provide clues to a path around obstacles.

I suppose that you've looked this post over: https://forum.digilent.com/topic/22197-a-guide-to-using-ddr-in-the-all-hdl-design-flow/

Debugging a complex design using the ILA is going to be a slow and arduous sled ride.

First, you've gotten a basic design to work in a manner similar to what the tutorial presents, yes? If not that's the place to start.

The Mig IP nice because it gives you all of the sources in Verilog. It and the example project, unfortunately, are written in as obtuse and difficult to rost out manner as possible. Trying to turn it into a multi-channel DDR controller is going to be difficult. The first phase of pain will be to simulate the working vanilla Mig-based design as a baseline. You will have to do your design in Verilog. If you can't work out how to do that step, then you are in for some hard times. This is the only rational way to know if your own Verilog modules are working as expected.

If you can't do that step then you will have to slog through the IP code and instrument it. Starting from something that doesn't work is most likely going to take more time than starting with something that does work and that you can enhance bit by bit.

If you are interacting with the Mig controller properly I wouldn't expect to see the kinds of behavior that you are experiencing. That kind of points to your VDMA code. The Mig has a debug feature that you might want to enable. This may or may not help. I suspect that you are expecting the DDR controller to operate in a linear manner, and that is probably not what it is doing. If you aren't managing all of the read/write bytes per burst operation this would lead to problems. If you aren't monitoring fault or error signals deep within the IP then it's going to be hard to figure out what's going on using an ILA. The ILA isn't ideal for all debugging needs. Sometimes you have to create your own LA IP to capture elusive events and present them in a form that you can understand.

Once your signals  get into the microwave part of the spectrum the analysis for connecting them between devices on a PCB or devices on different PCBs changes into a substantially different beast than for lower frequencies. It is an interesting subject, as you've found out. Back in the days of ECL/PECL there were a lot more players in logic vendor space.. as well as good application notes for implementing good transmission lines. The consolidation in the semiconductor field is not going to work out well for anyone in the long run. I think that having 2 behemoths own 90%  of the programmable market is even worse... especially when those companies also own a bulk of the PC chip market... depressing. As some of us have learned recently JIT is great, for some companies, when everything in the world is normal and threat to social order when there's a global crisis. Going FAB-less may sound great today, when you make the committment.. not so good tomorrow when you can't buy FAB resources anywhere. ARRGH!
A while back I did a board-board interface using the MAX9122/MAX9123 using CAT7 cable for use with the "high-speed" PMODs. At least the receivers have integrated termination and the footprints are easy to work with. I didn't try anything like 500 Mbps/channel. Now there are very few logic component vendors ( ADI has gobbled up most of the old ones ) and fewer design options. It's one way to overcome the stupid mistakes ( or perhaps purposeful since Digilent has never corrected them ) of those *** "high-speed PMODs though... if your PMODs have at least one clock-capable pin. 
You might find that the limited PL resources in the XC7Z010-1CL coupled with a limited DDR performance isn't really the platform that you want to struggle with for your project. Unfortunately, this is a really bad time to buy cheap FPGA boards, or devices, or well... anything. If you can find it the price is double or quadruple what it should be and that's from nor so reputable sources making the investment extra dubious. Well, we gotta do with what we got when we need to get things done...
The Mimas A7 might be a better platform. It comes with 3.3V supplied to the IO Banks connected to the headers but you can turn that into 2.5V with just one resistor change. I've done that and it works. Don't know if you can buy any at any price currently. FMC mezzanine card PCBs are not trivial to do but might be a better option. Paired with a Nexys Video or better yet Genesys2 your interface would be a lot cleaner and straight-forward as you can use LVDS_25 or lower and internal termination. Working in your favor is the IDELAY feature that will allow you to compensate for mismatched pairs of differential signals in wider busses. Do understand the material in the Series7 clocking reference manual and any relevant information in the SelectIO reference manual as you plan out such a board... if that's an option.  Perhaps you can trade in your dinghy for a more sea-worthy vessel.
The Intel/Altera ( shouldn't these marriages end up with hyphenated names? ) space is kinder to the kind of projects that you want but alas the low end parts that the free versin of the tools support are hard to come by, as are the development boards sporting them. A year ago you could have purchased some decent sized MAX10 devices at a reasonable cost and created your own FPGA board with an interface to your image sensor. I have a couple of MAX10 project on hold because distributors claim no knowledge of such a device now.
Hey, I've spent the last 30 years trying to make programmable logic development boards, purposefully designed to have limited capability and having unnecessary design errors, that I can afford ( a few that I couldn't ) perform feats that they were designed not to do but that I needed to get done. Rube Goldberging isn't pretty..  but if it gets the job done, pretty isn't terribly important. Almost always starting off with a platform that allow you to express your design intentions ends up saving time and money, even when the initial cost iis above your budget.
Thanks for the story... been there... many times.

The standard PMODs have 200 ohm series resistors as a level of protection for the FPGA. This limits the usable bandwidth for any signals on their pins considerably. The so called "high-speed" PMODs don't have these and thus higher capability as individual pins.

If you are comfortable using an HDL what you want to do is pretty easy. Create a source and assign it to one of the 'high-speed" PMODs and create a sink and assign it to the other 'high-speed" PMOD ( assuming that you have one of the boards with 2 of these ). Be sure to simulate your design first. For source-synchronous interfaces you will need a clock capable pin on the sink PMOD. Such a design where both the source and sink use a related clock isn't very useful if you want to use your experiment as a starting point for connecting an interface from an external board. Digilent boards come with a very limited supply of external clocking sources bt generally you can find 2 somewhere in the schematic. If you want to study an example of a board to board interface that's already been done you can look here: https://forum.digilent.com/topic/20479-inter-board-data-transfer-project/

The Digilent forum sections are pretty cluttered with extraneous postings so it's not easy finding ready made projects with source code; still it's worth looking around.

Digilent makes FPGA boards supporting their PMOD ecosystem, not FPGA boards for the kind of projects that you want to do. There are better options available ( well, perhaps not at the moment as the world supply chain is completely broken ). Personally, I like the Terasic DE0 Nano as a general purpose FPGA platform that can be incorporated as a dedicated component in a custom design or as a board for this kind of project. It's Cyclone IV based so you have to use Quartus. Recent version of Quartus are completely broken if you want to use Intel high data rate IP like DDR/LPDDR2, but the Nano doesn't have any resources requiring Intel IP so it's well suited for any pile of doodoo that Intel releases as a tool version. Altera ModelSim is superior to Xilinx ISIM as a real world logic simulator( though it's so old that it doesn't have the right to be ).

Trying to teach the old-dog FPGA board that you have in hand to do something that it's wasn't design to do is usually just an exercise in frustration.

For about 2x the cost of the DE0 Nano the Cyclone V GX Starter Kit is a nice alternative and you might actually be able to find one to buy somewhere ( I just did ). It has a 40-pin GPIO header and an HSMC header making it particularly useful for a variety of projects. The LPDDR2 is almost useless as the tools don't support burst operation. Be aware that most electronics like this are unavailable or cost 2X-4X what they should... it's supply and demand without cost controls.

In general the advice that your refer to is correct... assuming that the _p/_n pairs are routed out on the PCB as true differential pairs. In this case coupling is a desirable feature of differential signalling. I don't have your board but the many Digilent boards that I do have show no evidence of having the signal traces being routed as differential. I've used the differential PMODs on the Nexys Video, Genesys2, Genesys, Zedboard at 50 mbsp for single-ended signalling without noticeable cross-talk data corruption. I have taken advantage of the 10 mil _p/_n length matching in those designs. 500 Mbps is another animal, especially for single-ended signals.

First of all, did you check the ZYNQ datasheet for your device and speed grade to confirm that the FPGA can deal with such data frequencies? Even if the clocking resources can deal with such rates ( 500 MHz is near the top end for low speed devices ) internally that doesn't mean that you are guaranteed to close timing on a real world design... especially using an external signal toggling at 0.5 GHz. But that's only half the battle. You won't likely be able to create a transmission line suitable for such a signal as any terminate will be situated in a less than optimal location and you have no control over signal integrity characteristics over the whole signal path. 500 Mhz is pushing the capabilities of the PMOD headers alone; then add other factors and you are in trouble quickly. Even with connectors designed for high-speed signalling like FMC and having internal termination for supported IOSTANDARD differential signals ( your board doesn't support this ) you are pushing your luck.

Even if you manage to get a usable signal into your FPGA how are you going ot use it? You aren't going to over-sample a 500 Mbps signal for asynchronous operation so this means that you need a clock capable pin in your interface so that your add-on board can implement a source synchronous interface. Digilent doesn't specify maximum length differential between _p/_n pairs for its boards ( but they will provide that information if you ask )

Before rowing your boat off shore it's wise to check for leaks.. that is do you due diligence before making decisions that can't be unmade.

As to connecting FPGA pins that are connected to true differential signals; when you drive the _n pin to ground in your design this happens inside of your FPGA. This prevents cross-talk between single-ended signals on differential pair pins but does nothing to assist with a design that involves connecting an external board. Unfortunately, this technique halves the number of available GPIO on a board that's already been set in stone.

It means that you get to create your own pseudo-random number generator. Creating an LFSR in logic is fairly trivial. Creating the proper LFSR for a particular application is not so trivial. Blindly relying on a rand() function in hardware or software to be appropriate is risky. There are only a few hardware number generators that claim to be random. The rest are pseudo-random at best and not necessarily appropriate for every application. I (think) that the Xilinx standalone OS has a C/C++ version of rand() if you don't want to create the ideal one in hardware. If you are running Linux on your Eclypse-Z7 then you have more software options.
Advertisement claims about products and device capabilities are frequently optimistic and sometimes just plain incorrect. Even when correct in a particular context they can be open to misinterpretation by customer, whether intentional or not. Users can't make assumptions. This is true for everything that can be purchased. Some markets are worse than others; ADC/DAC devices, low cost FPGA boards, storage devices, etc.

Usually "high-speed" interfaces use source synchronous interfaces requiring a reference clock. This requires a clock capable pin to be available. Also, it depends on logic signal compatibility. What is the ADC that you want to evaluate? The interface details are important for providing an answer.

"It may be possible to change from software through the use of some configuration register associated with the PS UART core"

Indeed it is. See the following link: https://forum.digilent.com/topic/22512-manipulate-pl-logic-using-ps-registers/

Be aware that, inexplicably, The tools ( at least the SDK for 2019.1 and earlier ) are limited to 115200 baud, which might complicate debugging, using the terminal console in the software GUI tools. A workaround, if you want to do 921600 baud is to use a separate UART terminal program such as Putty to interact with your hardware. 921600 is the highest baud rate that such programs can do without hardware flow control. For the Z7020 10 Mbaud is the upper limit and is useful as described in the tutorial. NOTE: the tutorial uses the standalone Xilinx OS. For those running Linux you'll have to work out how to access the PS UART registers. Direct access is highly discouraged in this case. But the general principal is still valid. PS UART FIFOs are fairly shallow, negating to an extent the benefits of using a high baud rate for some applications.

Trying out the tutorial is pretty straight-forward and easy so worth the time to explore.

"It may be possible to change from software through the use of some configuration register associated with the PS UART core"

Indeed it is. See the following link: https://forum.digilent.com/topic/22512-manipulate-pl-logic-using-ps-registers/

Be aware that, inexplicably, The tools ( at least the SDK for 2019.1 and earlier ) are limited to 115200 baud, which might complicate debugging, using the terminal console in the software GUI tools. A workaround, if you want to do 921600 baud is to use a separate UART terminal program such as Putty to interact with your hardware. 921600 is the highest baud rate that such programs can do without hardware flow control. For the Z7020 10 Mbaud is the upper limit and is useful as described in the tutorial. NOTE: the tutorial uses the standalone Xilinx OS. For those running Linux you'll have to work out how to access the PS UART registers. Direct access is highly discouraged in this case. But the general principal is still valid. PS UART FIFOs are fairly shallow, negating to an extent the benefits of using a high baud rate for some applications.

Trying out the tutorial is pretty straight-forward and easy so worth the time to explore.

One of the great things about the Digilent Zmod converter pods are the excellent supporting information provided in the reference manuals. This topic is discussed for the original DACA1411. You should get the datasheets for all of the components when using these boards. SFDR for the converters can be found in the respective datasheet for a particular converter device. DAC specs are not enough of course when post-converter conditioning is present. The reference manual is a good read for everyone crossing the analog/digital divide and provides sufficient information for most applications. The documentation that Digilent provides for its converter products is a refreshing high bar for the market that they serve.

Understanding converter specifications, and how device vendors abuse and confuse product performance is whole field of study....

I'm not quite in agreement with your transmission line analysis. Back in the dark days before programmable logic I had no problem creating overshoot and undershoot using common LSI/MSI logic on much shorter signal paths. Advanced Shottkey logic was particularly good at this, and at producing EMI which, for commercial products, needs to be constrained. I've re-worked many a PCB design to meet EMC requirements... Today, simulation is automated and even integrated into the PCB layout tools.

I view almost any signal path as a transmission line. There are two considerations here. One is discontinuities in impedance along the transmission line and the other is bandwidth. If you transmit a clock along a transmission line the duty cycle is not unimportant for the analysis of whether or not your signal will be ill-behaved, but the slew rate is even more important and relates directly to the transmission line bandwidth.

Good to hear that you've gotten past your initial problem though you still have some work to do to verify what you observe with the current termination.

[edit] You wrote that you were using a 250 mm cable and I keep thinking that it's a 250 cm cable... so this alters the comments here somewhat, but the concepts are still valid..

What you want to do is, from a security viewpoint, very dangerous. Microsoft can't even figure out how to harden it's own Windows OS against bad actors using the internet to abuse its users. One might assume that the 'cloud' is safe. One should probably stop assuming that. There are just too many point of entry, not all of which are obvious.

FPGA software tools for Xilinx OS for ZYNQ and MicroBlaze simply ignore this aspect of internet connected devices. If you are using a ZYNQ platform you could run a custom version of Linux and have that as a potential way to do this a bit more safely, but Linux has become a prime target because of the prevalence of Linux based IoT connected devices. In theory, one could harden Ethernet in logic to mitigate external threats, but this would require a lot of expertise and effort.

An easy way to do what I hope you will decide not to do is to use a chip based interface like the ESP32... but again you are back to a processor running code that is open to being abused. I get the attraction and glamor of internet connected custom hardware but I don't appreciate the consequences of having so many poorly thought out, poorly implemented, and out of date devices posing such a threat to everyone's health and well-being.

I wish that things were different, but economic considerations will always be on the side of evil until connectivity comes in a very different form... given the way that the world is headed the next internet will likely be worse for the common user.

I do a lot of processor-less FPGA based Ethernet connectivity, using even the latest version of Vivado ( the IP is less friendly to the HDL design flow ). I (almost) never allow any of my platforms be exposed to the internet even when there's nothing there to exploit, as is the case for all logic Ethernet.

You are correct. You can use the free version of the tools and there are no IP licenses required to develop for that platform.

In terms of maximum data bandwidth either LPC or HPC FMC beats SYZYGY by virtue of the availability of transceivers and shear number of IO available on the FMC connector. Both FMC and SYZYGY have a limited number of mezzanine cards or pods available. SYZYGY pods are generally cheaper, but are smaller. SYZYGY does provide for a transceiver pod type, but unlike FMC it's a separate pod from the standard pod. The Opal Kelly transceiver pods are geared toward the lower data rates of Artix devices.

I've not used the USB104 A7 platform, but it is an interesting non-ZYNQ possibility. Not a lot has been posted about this platform however. I would imagine that this platform could provide most of what you want in terms of PC connectivity and interfaces.. particularly if yo are prepared to design your own custom add-on card. Cost wise it appears to be a reasonable platform for anyone starting out in FPGA development. The fact is that any Series 7 or UltraScale platform lets you explore using the FPGA DSP functionality in any level of detail, from "simple" macro instantiation to the most abstract HDL usage.. if that's your main interest as your post suggests. One SYZYGY port is pretty limiting if you want to add interfaces like ADC/DAC etc. As far as I know there are no pods with both ADC and DAC functionality.

Opal Kelly uses a proprietary PC interface for configuration and PC connectivity ( not Digilent's go-to FTDI USB 2,.0 solution ) . This makes it incompatible with the ADEPT API. Their boards do usually include a JTAG header compatible with the ADEPT Windows Utility and Digilent JTAG cables but you will likely have to add a specific device ID code to the utility in order for it to recognize a device. This is a way to get around using Front Panel for both configuration and using VIO or ILA debugging, and I have done that when not needing the USB connectivity. Front Panel isn't integrated into Vivado Hardware Manager, so debugging isn't seamless. I've used the XEM7320 with the Digilent Zmods and found it to be quite superior to the Eclypse-A7 for the kinds of projects that I tend to do. The USB 3.0 interface is very nice. The Nexys Video and Genesys2 both deserve the higher bandwidth of USB 3.0. There is a lot to dislike about Opal Kelly's closed approach to products ( such as no schematics ) but they do integrate great PC connectivity via USB 3.0 to a variety of software frameworks which is, I suppose, their customer draw. It's certainly nice to be able to write a single PC executable in C that does both configuration and data transfers. But there aren't a lot of options as Opal Kelly only supplies encrypted netlists of the required components for doing that.

Intel FPGA programmable devices also have DSP functionality ( perhaps superior to the Xilinx ones ) and a pretty rich HSMC ecosystem. It is worth the time to explore as an alternative. Personally, I prefer the AMD/Xilinx world but frequently find myself using Intel world hardware and tools when they are a better fit for my purposes. Unfortunately, Intel has taken programmable logic toward a higher cost path in deference to low budget applications. The free tools are pretty much limited to Cyclone V and earlier. Cyclone 10 LP is pretty pointless but also supported.. to a limited extent by the free tools. Intel has always been committed to wrangling the most money out of customers as possible, even to the extent of losing customers.

If this is your first venture into FPGA development I'd advise against giving in to the urge of trying to find a cheap platform that will support your interests for years to come. This almost never works out. Better to start off as cheap as possible and then decide on specific project goals and buy the best platform that fits the goals.

Use the Xilinx Document Navigator. There are application notes for non-ZYNQ and ZYNQ devices. The SDK has additional support for the XADC in the Standalone OS. I'd expect that so does Vitis, though I don't use Vitis very often.

Xilinx abandoned the SDK with the 2019.2 version of the tools. You need to use Vitis which makes your tutorial out of date.

You might consider using an earlier version of the tools to get started.. perhaps Vivado 2019.1. The Zedboard has been around for longer than Vivado so really any tool version will work. If you are just trying to learn how to use the tools it would be easier to use the version that your tutorials and demos are using. The basic concepts haven't changed but lots of things get depreciated with tool version releases, and this can complicate and confuse anyone trying to follow an out of date tutorial. ZYNQ based development is doubly affected by tool version incompatibilities because it always involves a HW plus SW design effort. Though Vitis was supposed to integrate all of the software tools better than previous versions, if you want ot use Linux, you still need to install Petalinux separately and use a Linux based OS Host for developments. Microsoft has been trying to subsume Linux into Windows for a while now so, in theory, this situation might eventually change.

As for new releases of FPGA tools breaking old design source code as well as vendor IP; this is just the way that it is, and has always been across the programmable device market space.

Well, that's the trick, isn't it; identifying the platform and tools that support the requirements of a particular project goal. One problem with being dependent on a MATLAB design flow is that you are dependent on their support for any platform that you choose. ( MATLAB/FPGA tool integration may well have improved since the days when I used it. )
If I were you I'd avoid restricting my platform choice criteria to one FPGA vendor. Intel has been in the MATLAB design game longer than Xilinx and better support for OpenCL and such adventures. They also have the devices, if you have a thick wallet, and platforms that are similar to the Versal family. Intel wants to squeeze more money from its customers than Xilinx has traditionally, but in the end the investment in cost and effort probably isn't all that different than for a Xilinx based effort if you are targeting high-end FPGA devices and platforms. You aren't going to avoid paying for tools with a Versal project either. There's a lot of homework to do, and it's likely more complicated for someone used to the convenience of using MATLAB for FPGA development. Simplicity and convenience cost a lot of money... and often end up not getting you across the finish line due to limitations of what can be supported by such a framework.
If someone has a limited budget then they probably will have to scale their project goals to fit what is affordable. This is, of course, adds complications, and diminishes convenience and simplicity. It's always  possible to implement enough of a concept to demonstrate ( not prove ) that you have a path to a larger goal.
For someone who wants to get on with developing an idea without having to get mired in the details, I'd advise sticking with known platforms supported by MATLAB and used by other researchers in a particular field. This isn't likely to be the place to get such information, though perhaps you'll get lucky.

DSP48E isn't a complete specifier as there have been a lot of variations among the various families over the years that have seen significant changes to the operation and performance of the hard core. But, if absolute maximum performance isn't a criteria and you have a netlist for the device you are targeting you are correct.

I don't think that you understood my first answer. In the case where the PS controls the external DDR memory ( all of the Z7000 boards sold by any vendor that I'm aware of ) the MIG IP is completely irrelevant; you can't use it. The MIG IP is for external memory interfaces connected to logic pins ( as for the Arty A7 board ). The only way for the PL to get access to the PS DDR is through one of the master or slave AXI busses. There are a number of Xilinx AXI IP that might be usable, though the best way would be to write own AXI master or AXI slave interface; this is not for the inexperienced FPGA developer ). The AXI streaming IP can DMA data between PS external memory and the PL. You will still need to have some understanding of how AXI works.

There's always the limited, but still potentially alternatives, like using Xilinx AXI BRAM controllers in a configuration that allows access to DPRAM to both the AXI IP and your own PL code. This is conceptually the easiest method but requires PS software to either copy data to PS memory or use the ZYNQ DMA controller to do it.

As I mentioned the only ZYNQ FPGA board that I know of with PL connected external memory is the ZCU106. In this case, UltraScale+ external memory controller IP is not the same as Series7 MIG IP.

The DDR in ZYNQ based boards are controlled by the PS so you can't control it from the PL. You can use an AXI master to transfer data between the PL and PS DDR however. There aren't a lot of Xilinx boards with external DDR connected to the PL.The ZCU106 is the only one that I'm aware of.

The pins on the FMC connectors can get bent, but I assume that you've already done an inspection on both the carrier and mezzanine boards for connector mechanical issues. I've used that pin on my board which is a Rev A version, so this isn't something that I've seen. Digilent isn't very good at providing explicit board revision change notices so I don't know what's different about REV A.0; but I'm assuming that is due to a component change due to availability.
It's possible that there is a fault on your particular board, though I assume that Digilent has every board checked for connectivity. It's possible, but unlikely, that a gouge or mechanical stress has  broken a PCB trace. It's possible something conductive has gotten under the FMC connector and is causing a short. It's also possible that the FPGA has had that particular IO abused and can't source or sink current. Those are things that spring to mind that I've come across testing out custom boards that I've designed and built.
That's all I have at the moment.