zygot

I forgot to mention this. Assuming that your FPGA board FPGA device is configured with a working PCIe application you still might have hurdles to overcome.
There are likely BIOS chipset options that by default will not allow your OS to use your board's PCIe interface even if the BIOS detects it. One such setting is the PCIe switch that can be controlled by the chipset or by software. This really depends on how recent your PC hardware is and how up to date your BIOS is. There are a lot of duckies to get in a row before using PCIe with programmable logic.
Intel and AMD don't typically offer very good FPGA PCIe driver support except for their high-end accelerator card portfolio. What would be the business case for doing that?

The sales blurb for the Eclypse-Z7 still says "The Eclypse Z7 is specifically designed to enable the rapid prototyping and development of embedded measurement systems.. reducing the time it takes for engineers and researchers to develop innovative and powerful new high-speed instrumentation, control, and measurement systems for edge-computing, medical, and communications applications."
Curious as to whether this describes your experience with the board and support so far. I haven't cloned the repositories in quite a while and an hour ago I find that just getting basic information, like how many contiguous ADC samples does the AXI controller support, has gotten a lot harder to find. Still looking by the way.
If your application mostly is implemented in your PL logic and you only need a simple, low speed way to write control registers and read status registers to control your design, the simplest way might be to use the spare PS UART, through the EMIO, to connect your software to your logic. The basic idea can be found in the tutorial: https://forum.digilent.com/topic/22512-manipulate-pl-logic-using-ps-registers/ It might not be appropriate for your requirements, but if it is the effort to get your design working might be a whole lot easier. It might be worth looking at.
 

Vivado doesn't convert projects from later tool versions for a variety of reasons. That doesn't mean that you can't manually recreate the project in an older version. Projects created with older versions of tools can often, but not always, and usually with considerable effort be made to work in more recent tool versions.
For someone just getting started it might be nice to be able to replicate a demo project without a lot of hassle.

Most of the time when I read content on a site like the Digilent Forums, my browser has most scripting blocked. Most people are aware of the cat and mouse game involved in monetizing the internet as we know it.
Unfortunately, some websites are not completely friendly places to visit. For the this one, unfortunately, posts are presented either in an order that reflects how conversations evolve over time or something else that is loosely referred to as "by vote" I don't know what by vote means, particularly when a thread has no "votes". What I do know is that it's possible to influence how people understand what it is that they are reading by changing the context. It might be innocent.. it might not be.
I always choose to read threads having a lot of posts, especially where there is some back and forth, in chronological order as I believe that it pushes comprehension toward being more informative. Unfortunately, for Digilent's Forums posts are not presented by default in chronological order; in fact in some browsers with scripting blocked you can only see posts is the other format... whatever that is supposed to be doing.

First of all, Vivado ML or any recent version of Vivado is NOT the only choice. All versions of Vivado support Artix devices, though not necessarily all Artix devices.
Early versions of Vivado for installation on Windows or Linux hosts were distributed on a DVD. You might find that something like VIvado 2015.4 works just fine... perhaps even includes more free IP than current versions. A good way to figure out a version is to look at the Basys3 supporting demos provided by Digilent.
Lately, it's been a bit harder to get older, *archived*, versions of the tools, but you can browse the AMD/Xilinx website to see what's available. How easy installing one of these older tools on a current OS depends on what you are using. Windows might be easier than Linux. Tools that have 32-bit dependencies might be problematic.
You can reduce the amount of stuff that the installer downloads by selecting support for only the device on your board, but it's still going to be a lot more than any Vivado version that existed when the Basys3 was introduced.
How you intend to use your board and the tools is something to consider. If you want to learn the VHDL or Verilog design flow, then any version is good. If you want to put a MicroBlaze in all of your designs and use Vivado IP in a board design flow, then still any version is fine, though there might be an advantage to using a current tool version.
For a long time now Xilinx assumes that users have a broadband connection and almost unlimited resources. The way that they package and install the tools reflect this.

For the original AD1, Digilent provided an excellent write-up of the hardware design that allowed users a chance of figuring this kind of information out for themselves. I have been unable to find equivalent information about the AD3. In recent years Digilent has been moving toward more opacity and hiding more of the important details that are important for certain applications.
Perhaps, someone at Digilent will point you to an AD3 theory of operation document that will suffice. In general, Digilent products are geared toward general purpose use cases. Sometimes, someone who knows what the right questions are, for their application, post them to the forum. Thanks for doing that. I'm looking forward to the subsequent exchange. Details, details... can't do much without covering the details.  

This argument is certainly debatable.
Certainly there have been users reporting problems getting expected performance and use a RPi, which is a supported host.
I do a lot of USB work involving FPGA-PC connectivity, on a lot of different host platforms. In my experience the capabilities of the host as well as the OS, OS version, and other details do have a significant impact on performance. For USB 3.0, even the driver/OS combinations can be problematic. The major issue with USB is variable latencies, because USB is so tightly coupled to software support being involved in data transport. It's really hard to quantify USB performance for a given host. The basic concept of a large device buffer absorbing random latencies is OK, the problem is that, obviously, it's not sufficient. My sense is that the reason for buffer overflows in the device for long data streaming sessions is due to the host not being able to drain data fast enough. I may be wrong about this.
I'm betting that a lot of AD3xxx users aren't using high-end PCs with lots of available memory not taken up by the OS.  Obviously, streaming 8 GB of data into memory on a host with only 2 GB of available memory is going to be a problem.
For Ethernet, data transfers use DMA both in the device and host end. I'm guessing that the 70 MB/s limit here, where something closer to 120 MB/s might be expected, is due to the device architecture, not the host capabilities.
There are two basic ways to deal with data transport issues.
decouple the host from the instrument. This would mean that the instrument would either do everything, like an oscilloscope or waveform generator, without involving the host. That means a lot of potential storage capabilities in the instrument, less customization and certainly a higher cost. Allowing the user to pay for optional storage capabilities would make marketing simpler. If an instrument design can't accommodate "infinite" data acquisition or waveform generation, however you choose to define "infinite", then simply proudly advertise that the product doesn't support such a mode of operation. That's the simplest solution. However Digilent deals with marketing it's products, and this includes videos and demos that suggest use cases and performance that Digilent might not want to specify as guaranteed, one thing is for sure: customers who buy a product with an expectation based on what they read from the vendor and then get a product that can't perform to expectations are going to be unhappy. The real question is whether or not National Instruments cares about their customers or it's own reputation. Some customers are corporations or entities with a significant budget to spend on equipment.
The ADxxxx line of instruments is, largely due to the efforts of Atilla and his colleagues who supply really good responsive after the sale support, are fantastic niche products. It's this support that makes the products unique. As to whether the performance of the higher cost AD3xxx products represent enough "bang for the buck" justifying their cost, well that's up to the individual customer. Customer's can't make that analysis without clear performance specifications.  
For test instruments costing $50-200K clear guaranteed specifications is a requirement if you expect to sell anything. This costs money which then drives product cost. The Digilent AD3xxx instruments are a special class of low cost, but not insignificant cost market where you can sell stuff without the testing and hard specifications. That doesn't mean that you can abuse customers with impunity.

Don't spend money because you feel compelled to, spend money because you have a good reason to do so. With or without a physical FPGA platform you still need to hone your Verilog skills as well as your understanding of how to use the tools. You can do this with nothing other than Vivado... now, without consideration of what you anticipate that your future needs will be. I argue that this approach will make your anticipated future course work easier and more productive. 90% of FPGA development is spent in FPGA vendor tools, not using hardware; the exception is when your hardware becomes a tool for developing other FPGA designs.
There are a lot of assumptions about how your future will transpire. If you are required to purchase an FPGA board for your coursework that's one thing. I understand wanting the comfort of being able to work on assignments outside of the lab. Are your expectations really a good reason to make a decision now, rather then later? Are you really expecting to buy everything that you need in a lab once the lab assignment work gets assigned? Is that a reasonable plan? I don't know, but neither can I or anyone else help you with that analysis. When I was in school there were a lot of courses where the textbook and lectures were insufficient to compete in tests. I was expected to use the school library, and  hope that the material that was needed was available. I suppose that I could have just bought every textbook that I thought that I might need for future coursework in advance so that I could use them in the comfort of my domicile. I had enough trouble just buying the required textbooks.
In general, I'd advise that hoping that the possibility of add-on boards is a cost-effective and useful plan for future undefined FPGA projects is a poor one. Especially, for PMODs which are low performance, older technology, and haven't had new product introductions for a while now. This ecosystem is pretty good for educational institutions but perhaps not as good for users. This is a general thought as individual needs are different. You say that: "PMODs are much more cost-effective compared to the FPGA boards themselves". I disagree, as a general statement. Have you priced PMOD boards compared to the cheaper FPGA boards? I want to make it clear that my opinion on this should not be something that constrains your decision. 
I make my own add-on boards. It isn't for the budget constrained. Making a PCB can be cheap. Populating it for 1 copy of a board that has limited use is usually a very expensive way to to do things. If it's the only way to do what you need to do to complete a particular project, then that's what you have to do. Gardening is a similar endeavor. For most people the food that they get from a garden is more expensive, once you account for ALL of the costs, than what they could get from the local grocery store. Price is, in general, a bad reason to have a garden.
Marketing is about imagination... possibilities. Reality is about actual use of a product over years of use. Modern societies are dependent on economies and tend to encourage exchanging money for perceived possibilities. Just a thought....

So, you are saying that 1600 MB over USB 2.0 or 2800 MB over Ethernet is a guaranteed gap free session for streaming ADC samples as long as the total sample rate is 20 Msps for USB or 35 Msps for Ethernet? Do you have an example of this for Ethernet?  The only practical way to test for gap less data collection is to use the ADC triangle test waveform. It's hard to tell from the screen grab.
You don't provide any information about your host, like PC, OS, memory etc. Since this is part of your instruments, I'd imagine that performance has a dependency on such information. Certainly a RPi4 wouldn't be expected to provide the same results.
 

Gee, how did I miss all of that fine print in the product advertising? Since these types of products include a customer's PC, doing who knows what, in addition to being part of the functionality of the product isn't testing something that should precede marketing claims? How does the word "should" ever get into a sentence by a vendor describing performance of a product?

There isn't one kind of simulation, even for ISIM in VIvado.
What you are doing is behavioral simulation. This only simulates the behavior of your Verilog as the simulator understands it. There's no attempt to predict how it will be synthesized and placed into the logic elements. That means that it doesn't analyze signal delays inside your design. There's another kind of simulation that ISIM can do based on the actual netlist reflecting the implementation. This more accurately shows potential timing problems. Behavioral simulation helps debug bad logic and code. Timing simulation, usually done after the behavioral simulation appears to work, helps identify delay related issues. If your combinatorial logic and routing delay exceeds the clock period your design will either not work at all or have periodic failures. Timing issues for very complex designs, like Soft-processors, with almost no connections to IO can be difficult to debug. Even if you get your processor working, you might find that connecting to mode IO in order to add new external interfaces changes your placement and routing, and therefor timing, leading to a new round of timing closure effort.
I'm not sure why you are using positive edge and negative edge clocking for your memory module. Dual clock memory structures have a purpose, but not in the way that you are using it. Using both edges of your clock in a design makes timing, and therefore place and route twice as hard. as a general rule, only use one clock edge throughout your design.
Keep using your Document Navigator and keep reading. All FPGA vendors have information that help you write VHDL or Verilog so that synthesis produces common structures in a consistent manner. Alternatively, you can use the Block Ram memory Generator to produce FIFOs or RAM as a guide until you are more experienced.
The fact that you had to slow down the clock that drives your logic suggests a larger problem. One thing that you can do is increase the clock period excessively as a test to see if internal timing is the issue.
Another problem that you are facing is that you are troubleshooting HW and SW concurrently. Try to break up the complexity by working on smaller parts of your design and getting all of those working.
Timing issues are inherently difficult as the same logic structure can exhibit widely different delays depending on the state of the input, and possibly the last state of the structure. This means that a timing simulation that only test a couple of all possible combinations of inputs and states might work fine but your hardware experiences a scenario different than what your simulation did and hardware fails; or that a better testbench succeeds in finding the failure for you.
 

Sounds about right. For USB, which is not DMA oriented on the upstream host end but highly software coupled, software latencies can wreck havoc with attempts at streaming. There are a lot of moving pieces in any particular USB implementation. The hardware involved can be a factor, but host OS considerations might be an even bigger factor.
There's a lot of gamesmanship in high end data streaming instruments; shouldn't be too hard so see why there would be more for low-end instruments. No one wants to tell potential customers to look elsewhere to accomplish their goals. Most customers buy stuff with one application in mind and then are disappointed when it stumbles on the next application.  

All nicely done, entertaining, and informative. If you are new to FPGA development these are worthwhile resources to investigate. I've been doing programmable logic design for over 40 years and I've enjoyed reading what's being offered. Nifty keen.

Invalidating the cache for the range that the data has been placed in could also be sufficient. The xil_cache.h driver has the necessary functions. It's a pretty common issue folks run into with DMA as well.
Thanks,
Arthur

Yes, you can learn a lot without any hardware. You can even buy, sometimes very expensive, FPGA boards that don't connect to any external hardware other than a PC PCIe slot. But programmable logic has traditionally been used as a means for embedded processors to interact with external hardware in a way that they were not equipped to do. So, understanding how digital signals work in real-world circuits is a very important part of programmable logic design. Having a design operate on hardware is the best way to understand what happens to signals that are more complex than the ideal logic '1' or logic '0'. A hardware platform is the only way to refine your simulation "IQ". While most modern FPGA devices have internal ADC capabilities, none that I can think of offer a corresponding DAC resource. A lot of really interesting problems that can be solved in logic require conversion between the digital and analog realms. 
I am certainly not encouraging you to forgo using an FPGA development board, just pointing  out that there are more than one way to look at FPGA development. You can learn about how FPGA devices work and implement very complex algorithms in logic without having to consider how to use the IO resources. I'm sure that there are people who do this. On the other hand, designing interfaces, that connect those internal algorithm implementations to external devices is a different skill set. You don't have to be an expert in both areas, but it certainly  is nice if you are. Some people don't care about the low level details of how a problem gets solved, only about solving a higher level problem.
Digilent's PMOD ecosystem definitely is a place where you can explore digital design and connect it to the real world in a relatively inexpensive, but limited way. But the PMODs do some of the most important interface design tasks for you, and limit your boundaries. Is this the best place for you? I do not know the answer to that question. If you want to design your own custom creation, put it on a PCB that you design, and connect it to an FPGA platform then the PMOD connectors found on Digilent's cheaper FPGA boards will likely not be so useful. Is using a generic FPGA board as a way to implement an unbounded project like that what you want to do? Again, I can't venture a guess about that.
So, my point here is that if you don't have a specific project in mind that requires specific external hardware and interface resources don't worry about whether your first investment will be a wise one.
Want to learn programmable logic design, or how the tools work, or how FPGA devices work? Just download the tools and get going. Do this first regardless.
Want to implement complex data processing algorithms in logic? You can do that with just the tools.
Want to learn digital design and how to implement high speed interfaces and create you own custom hardware? Then you can start with a cheap FPGA board with easy to use IO connectors.
Want to understand how a particular light-to-digital IC works and do some real-world experimentation? Well, you will want physical hardware for that. You will still want your logic simulator.
Want to do all of that? Great! Want to buy a cheap FPGA board today that will let you pursue some project 5 years in the future based on the knowledge and interest of your future self? It could happen.... but the odds aren't very high.

The Eclypse-Z7 is not the ideal platform for this kind of project. Consider looking at something along the lines of the XEM7320. everything will be a lot easier and quicker once you get familiar with their closed framework. That said, you can certainly ignore all of the ZYNQ cores on the Eclypse-Z7 and do everything in the PL, without being tied to any vendor IP like AXI bus implementation ( which can be sketchy ). The old but venerable Z7020 PL is pretty much equivalent to an Artix 75T in terms of resources. Here is such a project that I did a while ago:
There's an XEM7320 version also posted.
If you are going to invest your time and effort into developing an application on an FPGA platform, why not choose one that allows you to use that effort to do more ambitious projects in the future?

You are limited by how the board is designed.
You can configure an FPGA with a software application of your own design. Here's a nifty project that shows how: https://forum.digilent.com/topic/17096-busbridge3-high-speed-ftdifpga-interface/
Of course, there are multiple are multiple tools for configuration via a USB cable.. Vivado Hardware Manager, Digilent Adept Utilitites, etc.
Most FPGA boards have a button to accomplish the same thing.
You threw me off with the reference to reset. 

To my knowledge Digilent has never published a design that changes the Nexys Video Vadj voltage.
According to the boards' reference manual, if VADJ_EN is low, then the regulator providing Vadj is disabled, so 0V. The reference manual is in error about any "default" value for Vadj. Once VADJ_EN is asserted to a logic high state, the regulator drives Vadj to be 1.2V, 1.8V. 2.5V or 3.3V according to the state of the 2 SET_VADJ output pins. There will be a delay before Vadj becomes stable. If you use the high impedance PULL_UP constraint on all of the output pins that control that regulator you will get Vadj = 3.3V, maybe.
According to the reference manual you should not change the state of the SET_VADJ outputs while VADJ_EN is asserted.
It's possible to assert pin outputs to  default value that isn't 0. If you don't want to do that then your design has to bring up the Vadj power supply explicitly.
One way to do this is to have an up counter control these pins after configuration.
  -- a counter to set the Vadj voltage
  -- Need to use a clock that is always available and isn't from the FMC connector !!!
  vadj_count_proc : process(clk100,areset)
  begin
    if areset = '1' then
      vcnt <= (others => '0');
    elsif (rising_edge(clk100)) then
      if vcnt < X"FFFFFFFF" then -- important to stop counting before overflow...
        vcnt <= vcnt + 1;
      end if;  
    end if;                                                                       
  end process vadj_count_proc;     

  -- To change Vadj we need to do this:
  --  VADJ_EN   <= '0'  disable the regulator
  --  SET_VADJ  <= sets the Vadj voltage: {0,1,2,3} --> {1.2V, 1.8V, 2.5V, 3.3V}
  --  VADJ_EN   <= '1'  enable the regulator
  --  VADJ_EN = '1' and SET_VADJ = "00" when the FPGA is not driving these signals
  -- We need Vadj to be 2.5V so                    
  set_vadj        <= "10" when vcnt > X"00FFFFFF" else (others => 'Z'); -- set to 2.5V 167 ms after configuration
  vadj_en         <= '1'  when vcnt > X"01FFFFFF" else '0';             -- enable the Vadj control 336 ms after configuration
Some designs using an FMC mezznine card may bot want to reset vcnt after configuration as shown above.T
This user selectable Vadj arrangement was poorly thought out. I can't think of case where one would want to change Vadj after configuration. The Genesys2 that followed the Nexys Video has a more practical and safer power supply design.
As for "enabling FMC pins", I assume that this is a translate into English artifact. The FPGA IO connected to the FMC connector are always enabled if your design provides proper location constraints and the toplevel entity of your design includes them on the IO port. The problem is making sure that the voltage powering the Vadj banks have compatible IOSTANDARD assignments as the logic on the FMC carrier board. That's the potential problem with how the Nexys Video board sets Vadj.                                              

@asmi,
Yes, I just finished another post about SYZYGY and somehow managed to forget about the SYZYGY equipped carrier boards that Digilent sells; 1 A-100T, 1 Z7020 and two UltraScale+ ZYNQ boards. The eminently forgettable Eclypse-Z7 has 2 SYZYGY ports and a rather bizarre PMOD design, all of the others have only 1 ( but in at least 1 case an FMC connector ). Opal Kelly's tiny Z7012S based Brain-1 Crowd Supply board has 3 standard SYZYGY and 1 transceiver ports.
Opal Kelly supplies KiCAD footprints for a basic pod design, though it seems that every time KiCad releases an update all of the older component footprints become incompatible. Nevertheless, SYZYGY might be a reasonable option if you are going to design a custom board that you want to connect to an FPGA carrier board. I suggest looking at the boards that Opal Kelly has in stock at the moment ( though I don't know if that guarantees immediate shipment ).
The Mimas-A7 has a lot of well matched IO with an A7-75T FPGA. You can change one resistor to make them 1.8V or 2.5V logic compatible for true differential IO. Unfortunately Artix Series 7 devices have no HP IO banks and thus no internal differential termination, which is the ideal place to put them for receivers. You can view the Mimas IO length report without having to request it and before you decide on a purchase.
But thanks for the correction. 

Impedance matching and PMOD are not compatible terms. Once you've gone through one right-angle 0.1" xn header and it male mate any impedance matching for the PCB traces between the driver and the receiver is pretty much destroyed. 
I've never seen any information from Digilent about their standard PMOD PCB trace characteristics. What they publish for the other PMOD headers without the series current limiting resistors varies but don't expect 50 ( I think that I've read 70-80 ohms one on of their board reference manuals, but I don't believe that this is consistent from product to product). They do provide trace lengths for FMC connector traces if requested. These are the only connectors requiring impedance matching that they use.
I do hope that someone from Digilent does provide the information that you are asking for though.

Gee, that's refreshing to read. Perhaps I'm not wasting my time trying to help people with their problems after all...

Is it possible that DwfState enumerated as 6 is not unused, but perhaps undocumented or reserved?

Think that you need AXI busses or complicated logic design to use the PL in your fancy ZYNQ device? Well, this demo proves that you don't. Find out how to read and write registers in your PL logic design just by reading and writing a few registers in the PS register set.
By routing an unused PS UART to the PL via EMIO you can have a full-duplex data path as well as 6 additional input or output signals. What could be easier?
EmioUartDemo_R1.zip

There's a HDMI demo here: https://forum.digilent.com/topic/25315-using-ddr-as-a-video-frame-buffer/ for the Genesys2 that you might find interesting. It does require building a Windows host program though. It doesn't use the IPI flow which makes it less vulnerable to depreciated IP and Vivado version issues.

Great. Questions are nice. Feedback is better. Critical suggestions useful. Discussion informative for many... The weak link in the project seems to be the software application. Let's see some turkeys out there people!