zygot

If you are implementing your own MAC design in logic then the MAC address can be anything that you want it to be. It doesn't even have to be static.

This of course presents a problem if your hardware is connected to a LAN or the internet as there are not supposed to be any two MACs with duplicate addresses. Assuming that the address in the Genesys2 FLASH is unique somewhat strains credibility, as does the notion that all of the internet connected devices out there might be unique.

In truth you don't even need to incorporate a formal "MAC:" structure in an Ethernet design implemented in logic.

Sampling rate isn't specifically an FPGA issue. Having external clock inputs and outputs isn't just about clock synchronization.

Imagine that you a system with one of the components an FPGA based board with ADC and DAC capability. There are a number of reasons why you might need coherent system wide sampling. If your ADC is converting a signal generated by a system DAC you might have phasing requirements. An external clock input allows your FPGA platform to have an Fs that is more accurate or steady over time or environmental fluctuations than what the board vendor can provide for a reasonable cost. Sytem Fs might not be constant over the measurement interval. Fs might not originate on one FPGA board. You might not have only one FPGA based board with converters in a system. Clocking is the very basic place where systems engineering starts.

As a purely educational platform not having external clocking access might be fine, for a limited set of purposes. As a working platform this might be a huge problem. A couple of SMA connectors certainly isn't a prohibitive additive cost for something that the Eclypse-Z7 aspires to be. Not all customers of low cost FPGA platforms have simple educational projects in mind.

The Eclypse-Z7 is Digilent's foray into SYZYGY compatibility. SYZYGY is a standard that let's Xilinx customers use the Series 7 IO to all of its capabilities with relatively low cost and high performance headers. Customers can use pods available in the market place or create their own custom pods within a tight budget ( not that these connectors are trivial to lay out using free PCB tools or for low layer count board design ). Digilent is free to pursue whatever market strategy they choose to. FPGA board users are a diverse group and just want to be able to use FPGA device features to accomplish a task. I don't speak for Digilent or any other vendor. I speak on behalf of their customers and users. As a user I don't want to buy a platform that is designed to limit its usefulness, especially when there isn't a cost or technical justification for doing so.

The MIG example design is fully synthesizable and can be run on hardware as long as your platform has the resources to support the ILA and VIO components. The example design is, in my opinion, overly complicated and hard to follow. The tutorial remedies some of that.
The MIG IP, like many of the Xilinx IP, could use some cleanup and love. I've never found the Xilinx User Forums to be particularly helpful. Xilinx's position on its tools seems to be: Everything works as it should, and if it doesn't you can try tracking down all of official errata and design advisories ( that may or may not be germane to your tools version, and if you still can't figure it out then it's your fault, because everything that we provide is as it should be, and while we don't actually address all of the issues presented by customers with official design advisories that's not our problem. 
If you have any questions regarding following the tutorial, I'd appreciate you posting them there. I've made it clear why I don't think that it's possible to create a general tutorial to fit all platforms and designs and why the tutorial needs to be interactive.
 
 

I've started a thread for people wanting to know how to use the DDR memory on their FPGA boards. I want this to be interactive as it's not possible to provide  a single demo project that works for all boards and all versions of Vivado. To get this started, I've provided a tutorial in the file XilinxDDR_Tutorial_Part_1.txt. As, the name implies this is just the beginning of the tutorial, but if you get through it, you will have a working DDR design running on your hardware.
Not everyone ( perhaps no one? ) will be happy with having to plow through a long text file but there are reasons for why I am presenting this material in this format. Perhaps, I will try and pretty the content up at a later time, if the topic is popular enough.
[Update] I've posted part 2 of the Tutorial. You can follow steps to creating a more useful DDR design by reading the file XilinxDDR_Tutorial_Part_2.txt. This isn't the end.
[Update] I've posted part 3 of the Tutorial in which we look at performance and simulation.
 
imp_top.v imp_top.xdc
XilinxDDR_Turorial_Part_1.txt
NexysVideoDdrDemo.vhd NexysVideoDdrDemo.xdc UART_DEBUGGER2.vhd XilinxDDR_Turorial_Part_2.txt YASUTX.vhd
 
NexysVideoDdrTest.vhd XilinxDDR_Turorial_Part_3.txt

@jb9631,
Thanks for the information. Interesting....
Xilinx has no incentive to make their IP resource thrifty. They do have an incentive to make their IP consume lots of resources. Just an observation.
IO SERDES can be tricky to implement. Fortunately, there are application notes to help. Before trying out a design on hardware I suggest doing a timing simulation ( after the RTL simulation ) on the implemented design.

Just for fun, I tested the venerable KC705 DDR3 SODIMM:
the KC705 4:1 controller with an 800 MHz PHY clock and 64-bit DQ bus has a ui_clk of 200 Mhz with 512-bit data
00012C53 = 76883 --> wtimer --> 0.000384415 seconds
00010000 = 65536 --> wcount --> 4194304 bytes --> 10,910,874,966 bytes/s to write 4 MB
000117BC = 71612 --> rtimer --> 0.00035806 seconds
00010000 = 65536 --> rcount --> 4194304 bytes --> 11,713,969,726 bytes/s to read 4 MB
00000000 = 0 errors

Done in VIvado 2019.1. The KC705 is lacking a few amenities but certainly has an external memory worthy of the Kintex -2 part. Getting a bitstream with Vivado was an adventure due to a design flaw with the board, and poor support by Xilinx, it's vendor.

Also, all of the Kintex boards that I've tested: KC705, Genesys2, and NetFPGA-1G-CML have the global clock in the wrong half of the FPGA (relative to the DDR pin assignments) so you have to use a CLOCK_DEDICATED_ROUTE_BACKBONE constraint and settle for less than ideal clock routing for designs using the DDR. Intel FPGA evaluation boards tend to have more external clock inputs... but their devices also have a more restrictive clocking infrastructure than the Series 7 devices. Still, for high performance boards like the Genesys2 it would seem prudent to add at least one extra, perhaps programmable, clock input. The difference in cost would be minimal but greatly enhance usability.

Again, all of the test results that I've posted are for a design pushing the MIG DDR3 controller to it's maximum data throughput and not necessarily appropriate for all designs.

@reddishI appreciate the feedback. I still have (at least) one more part to complete, but haven't decided how to approach it yet. Hopefully, more to follow....
Since most FPGA boards have some external memory it shouldn't be as daunting a task to use for projects as tools and board vendors make it out to be. Still, as with the KC705, it can be very difficult to resolve obstacles. I am unaware of any community effort to deal with exposing "hidden" information needed to complete an HDL project using the MIG. Vendor IP shouldn't be so difficult
Thanks for overlooking the typos and rough presentation...
 

To complete the board test results for the boards that I have access to here's something that might be of interest.
There aren't too many ZYNQ based boards with external memory connected to the PL. The ZCU106 happens to be one. For some reason Xilinx has decided not to support it with recent versions of its tools....
    the ZCU106 4:1 controller with an 1200 MHz PHY clock and 64-bit DQ bus has a ui_clk of 300 Mhz with 512-bit data
    013B5577 =    20665719  --> wtimer  --> 0.06888573 seconds
    01000000 =    16777216  --> wcount  --> 1073741824 bytes --> 15,587,289,617 bytes/s to write 1 GB
    011087E7 =    17860583  --> rtimer  --> 0.05953528 seconds
    01000000 =    16777216  --> rcount  --> 1073741824 bytes --> 18,035,387,152 bytes/s to read 1 GB
    00000000 =           0  --> errors
It's almost astonishing, to me at least, that the test runs at 300 MHz on hardware; but there it is. Again, you get an average data rate of about 90-94% of the 19200 million bytes/s peak.
The UltraScale+ uses the DDR4 SDRAM MIG 2.2 in Vivado 2019.1. pg150-ultrascale-memory-ip now covers this version. There's no flexibility in the IP design due, in part to the extreme clocking and timing specifications for the DDR4 memory. The MIG constraints files now abstracts pin constraints by using BOARD_PIN instead an actual pin number, and doesn't define any of the other pin constraints so that it's very difficult to find, or more importantly manage, the source code. This is the way that Xilinx is moving; less control for you over your projects and source maintenance, and more obfuscation of the details. Like it or not, you get a MicroBlaze embedded in your design to accomplish the calibration.  The only good news is that the Hardware Manager can find and report the calibration status and results. If, for some reason it can't find the embedded processor, then you can't download code or run any application on the UltraScale+ processor(s)... and yes, I managed to do that briefly. But who can argue with 16 GB/s of data storage bandwidth?
The DDR4 core is a very complex IP and good luck to anyone having to debug it for a custom board.
I had to restart the project a few times. If you start with a board design and include the DDR4 block you HAVE to connect an AXI interface to the memory. Who want's to do that? The whole purpose of having the PL get access to external memory is for your HDL design to use it. But you can create a basic board design with just the ZYNQ and then create the DDR4 core as general purpose IP. Then your code can instantiate the ZYNQ and MIG core with the UI and run the design without doing any SW design of any kind.

The inappropriately named differential PMODs found on Digilent's FPGA boards match n/p pair lengths for each IO bank pin pair. Digilent does not match pin lengths across all pin pairs ( i.e all 8 signals ). Furthermore, the matching only extends to the connector through-hole pads. The right-angled connector used on all PMODs is unsuitable for most differential applications. If you need the best common-mode performance, then none of these PMODs are suitable. Also, since none of the PMODs have signals connected to IO banks with a Vccio that isn't 3.3V, TMDS_33 is the only possible differential standard. Lastly, placement of termination resistors can never be ideal.

If you need matched n/p pair lengths for an application where the FPGA pins are receivers you can always use IDELAY to compensate for mismatches, up to about a ns or so. In theory one could use a right-angle connector on an attached board that is in the opposite orientation to cancel out the connector length mismatch, but you still have to deal with the connector unsuitability for differential signalling.

There might some low frequency applications where these PMODs might be OK. like RS-422.

It would have been nice if Digilent actually put usable differential IO connectors on their boards that were connected to IO banks powered by a suitable Vccio; but they have refused to do so. I suspect that's because none of their PMOD accessory products use differential signalling or high speed signalling and the purpose of the PMODs is to sell PMOD products, not to make their boards suitable for custom user projects.

Is the RPi5 suitable for paring with an FPGA?

You may have noticed that the latest generation of RPi5 uses an asic, referred to
as a Southbridge, for IO. All of the IO, Ethernet, USB connectivity etc. are implemented
in the RP1 Southbridge whic is connected to the BCM2712 processor though a 4-lane PCIe
Gen2 interface. This makes it substantially different from the RPi4 or RPi3
boards. So you might be wondering if the new version can be connected to an FPGA. That
is a question that I decided to investigate for myself.

The RPi5 has a single lane PCIe Gen2 ( perhaps even a Gen 3 ) header on it that someone
will eventually create an FPGA add-on board for. Most people will want to use that interface
as a higher performance alternative to the SD card. But the RPi3 and RPi4 could always
connect to an FPGA board using a USB 2.0 bridge device like the FT2232H supporting synchronous
245 mode operation. I've done this and performance for the RPi3 and RPi4 is OK for moving
small blocks of data between the processor and the FPGA. As the amount of data being transported
increases the performance drops off considerably, unlike an x86_64 processor.

For my experiments I'm using a Genesy2 board with a FMC_UMFT601BX mezzanine board. This
allows the HDL application in the FPGA to act as a USB 3.0 endpoint with a peak data rate
of 400 MiB/s. The design of the Genesys2 application used for my tests is pretty straight-forward.
All data uploaded to the FPGA from the USB Host gets stored in DDR3 that functions as a very
deep FIFO. The USB Host can retrieve the upload data once it's been downloaded. The HDL expects
n sectors (4096 bytes/sector), to be uploaded and then downloaded. The DDR3 interface in combination
with sufficient FIFO storage can accept up to 1 GB of upload data and return it without delays.
In addition to the simple up/down data scheme the HDL has performance timers to timestamp the
important events in the tests. These are: the time that the first 32-bit word is uploaded, the
time that the last 32-bit word is uploaded; and the same events for download. Since it's a
free-running counter, I can calculate the total time that has elapsed between reading the
first 32-bit upload word from the FT601 FIFO to the last 32-bit word written to the FT601 FIFO.
This provide a much more accurate picture of the USB Host OS/Software behavior and performance
than typical software timing methods provide. It must be noted that from the perspective of the
USB Host data rate performance is more complex than just time spent in the driver filling or
emptying the FT601 FIFOs. I have my own Software application that is mostly identical for Windows
and Linux platforms. The D3XX drivers for these platforms are not the same however.

The FT601 is not the only way to connect an FPGA to the RPi5 via USB 3.0. I also tested the
XEM7320 with the Infineon FX3 bridge.

For the FT601 Test I used this setup:
- Genesys2 FPGA board
- RPi5 8 GB w/ heatsink/fan
- Raspios Bookworm 64-bit
- libftd3xx-linux-arm-v8-1.0.5
- FT601_245.cpp Host Application
- G2_FT601_TESTER.vhd

In FT601_245.cpp I do software elapsed time calculation. The test runs in this manner:
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &start);
ftStatus = FT_WritePipe(ftHandle, 0x02, pBufOut, SectorSize*up_sectors, &BytesWritten, NULL);
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &start);
ftStatus = FT_ReadPipe(ftHandle, 0x82, pBufIn,RxBytes,&BytesReceived, NULL);
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &stop);

So, there is some processing between the upload and download calls to the D3XX driver.


Without further ado, here is a sampling of results for the Genesys2/FT601/RPi5 testing

Test Upload Average Download Average
Length Time Upload Time Download
Bytes Data Rate Data Rate
------- ------------ --------- ----------- ---------
16384 42.09 us 389 MiB/s 44.68 us 367 MiB/s
65536 170.66 us 384 MiB/s 196.35 us 334 MiB/s
262144 682.51 us 384 MiB/s 848.43 us 309 MiB/s
1048576 2.73021 ms 384 MiB/s 3.37639 ms 311 MiB/s
4194304 10.92282 ms 384 MiB/s 12.13967 ms 346 MiB/s
8388608 21.84317 ms 384 MiB/s 24.26676 ms 346 MiB/s

This is rather surprising that the upload data rate is consistently around 380+ MiB/s
for blocks of data ranging from 16 KB to 8 MB. Download rates were less consistent from
run to run but still near 350 MiB/s. For USB 3.0 the RP1 Southbridge performance is
outstanding. I believe that the low rates in 310 MiB/s range were outliers, but within
the range that one should expect. BTW the performance with the same setup, but using my
Ubuntu 22.04 i7-13700K box was dismal; about 44 MiB/s up and down for 1 MB test.

I also tested the RPi5 using this setup:
- XEM7320
- RPi5 8 GB w/ heatsink/fan
- Raspios Bookworm 32-bit
- FrontPanel-Raspbian10-armv7l-5.3.0
- EthAppliance.cpp Host Application
- EthAppliance_1.vhd
- Genesys2 configured with Genesys2_Eth_DUT.vhd ( Ethernet echo application )

A few months ago Opal Kelly had posted a 32-bit beta ARM driver for FrontPanel; it's
since disappeared from their download website.

I didn't try to do do a performance test with this setup. All I wanted to know was
if I could run the application on the RPi5 and see if it worked as well as on my
x86_64 Windows and Linux platforms. The application streams TX Ethernet 1 GbE packets
through a SYZYGY Ethernet pod. It stores RX packets simultaneously into a DDR3 buffer
that can be read later. I was able to run the HDL and software applications with
performance that was equal to that on x86_64 Win10 and Ubuntu 22.04 platform; that is
sustained 120+ MiB/s full-duplex Ethernet.

So, do I think that an RPi5-USB 3.0 FPGA could be interesting? Absolutely I do! The RPi5
is an impressive bit of gear with some interesting possibilities.

"The max rate isn't specified. You can find other users trying to get Pmods going as fast as possible"
It's hard to argue with a statement that doesn't make any assertions.

Be aware that all of the PMODs on the Basys3 are the "low speed" variety; that is they have 200 ohm series resistors between the FPGA pins and the PMOD connector pins.

If all you want to do is toggle pins at 100 MHz, yes you can do that. if you want to use such a signal to transmit information, then there's a lot more to consider.

Only the so called high speed differential PMODs have any PCB trace length matching. That's only between the _n/_p pin pairs. And no PMOD, except on n the ATLYS can do differential signalling.

None of the PMODs that I know of have length matching across all 8 pins.

Most PMODs don;t have a clock capable pin connected to any of the PMOD pins. This might be a problem for high speed interfaces.

10 MHz toggle rate is what most of Digilent's Reference Manuals suggest for the standard low speed PMOD. That's probably very conservative. I'd certainly implemented SPI interfaces using PMOD connector to external devices via a custom PCB adapter that exceed 32 MHz; on the high speed PMODs. I'm guessing from past experimentation that ~50 MHz is practical limit for useful educational work. Of course the termination on the receiving end, the quality of the transmission line from FPGA pin to receiver pin, the current drive, slew rate, etc will determine the quality of your signal. Large amounts of overshoot or undershoot will degrade performance and potentially reliability.

Basically, what I'm trying to say is that if you want a good answer to your question, then you need to ask a better question. A nebulous question invites a nebulous answer.

I suppose that what you really want to know is whether or not your design idea will work with a Basys3 PMOD connected to some external circuit. A good answer requires more information about what you are trying to do.

I looked over the current Basys3 Reference Manual and was surprised to see that it didn't mention a useful toggle rate for the PMOD connectors. Since that board is pretty old I assume that this information was scrubbed from the original manual. This seems to be consistent with the new Digilent policy of removing important information from easy access when it doesn't reflect well on the product capabilities and replace specifications with ill-defined comments that suggest something more positive.

In the forum Guidelines section there is this recommendation: "If you have a completed project or tutorial you want to share, a subforums titled “Project Vault” and “Tutorials” are available in the General Discussion section.".

As someone who's posted projects to both of those sub-forums over the years, I'm happy to see that stated. Unfortunately, both sub-forums are places where users continually post questions or other content. This reduces the chances of other users finding content that might be helpful or of interest. The quality of experience for readers and people posting projects would be much better served if Digilent made a better effort to curate those sub-forums, by moving irrelevant posts to a more appropriate sub-forum area. Occasionally, someone on the Digilent staff does this; but there is no obvious on-going effort to do so that might be call "curating".

I've mentioned this before; nothing's changed, so I'll mention it again.

Digilent is certainly good at promoting such work materials when if makes for good sales pitch... even when they aren't quite as advertised.

I think that Digilent should be proud of its forums as a place for educational enlightenment, not just for selling stuff. A sign of pride might be better oversight and maintenance.

Generally speaking, harmonics are features of a synthesized signal that the designer gets for free.. and doesn't particularly want.

I guess that the answer depends on how you intend to go about constructing your 50 Hz signal, as well as what the specifications for the signal ( other than harmonics ) are.

There are a number of ways to synthesize signals. There are a number of ways to implement them in logic. Usually the prominent implementations are using a look-up table that contains pre-calculated samples, using a DDS type structure, or direct calculation using some algorithm. All of these will produce harmonics in the logic output samples. Then, once they are fed into a DAC and go through the analog circuitry that follows the DAC additional artifacts will be added to the signal. Then there's the transmission to whatever is receiving the signal... etc., etc...

I suppose that you want some control over the prominent frequency components that aren't a 50 Hz pure tone.

The way that one does any project like this is to simulate a prototype of their algorithm and implementation. This would be done first in MATLAB or OCTAVE using all of the high level features that these tools provide. Then, once you have a promising candidate, if using a algorithmic approach, redo the OCTAVE, but only using structures and simple keywords that can be implemented using an HDL such as VHDL or Verilog. Then you write your HDL implementation and simulate that using the Vivado simulator or your favorite alternative. Ideally, all of your simulation more or less agree ( accounting for differences in numerical dynamic range ). If you are using a look-up table implementation then your pre-calculated samples are what your output will be ( except of course for hardware dependent effects ) and the OCTAVE simulation is a lot easier.

Only after you are happy with all of these simulations would you even attempt to create a bitstream and try it out on hardware. That's the basic idea.

As for how one might synthesize a signal that meets some set of requirements.. this is a whole field of study. It really depends on on the specifications and what you are tryng to accomplish. If 50 Hz is just a reference to the signal cycle period, then there are a lot of possibilities that have been used. Instead of trying to manipulate a 50 Hz tone, you might combine multiple tones... similar to DTMF.

Oh, and do you intend to construct a fixed signal or want to manipulate it on the fly in hardware?

BTW. This is the kind of project that the Eclyspe-Z7 isn't bad for. You might find this project interesting: https://forum.digilent.com/topic/20299-fun-with-phasors/
You can read through the source code and documentation to get the idea of what's going on. There's even OCTAVE code. I wouldn't recommend buying an Eclypse-Z7 based on just one application, but you can see that for some applications, it's an acceptable platform.

I'll bite..
First can you provide a more specific description of what you mean by "adjustable harmonics" ?

asmi,
If you want to defend bad design choices, that's your privilege; I choose to call them out.

There's no point to continuing this little debate, so I 'll just stop with this thought, in the context of all of your arguments. The Raspberry Pi3 has a micro USB connector... with through-hole tabs. The RPi4 has 2 micro HDMI and a USB C connectors, all with through-hole tabs. These products are on very densely populated, very small PCBs, and retail for under $50 in single quantities. No one's complaining about connectors being ripped off of these products. That's just on example of well thought out product design, because the people making them care about their customers. I have lot's of cheap development boards with quality components that counter your arguments.

asmi: "I meant what was you doing with it that caused USB port to be ripped out? That's gotta require some serious force. This devboard is designed to be used in a lab, as it doesn't even have mounting holes if my memory serves me."

I can't tell you how many development boards I have in which those surface mount USB connectors have ripped off. For some, it's definitely stress from insertion/removal of a USB cable over time. You can't leave the cable plugged in them because that'll put stress on the flimsy top layer copper pads. Even putting a duplicate pad on the opposite side of the pcb and inserting lots of vias would help somewhat... though would negate the cost of the proper connector. You can't perform lots of insertion cycles for the same reason. I don't buy boards with USB connectors, unless they have through-hole tabs anymore.

Using smt connectors that don't have through-hole tabs saves almost nothing in production costs and greatly hinders the product lifetime.

A different opinion.

Unfortunately, the FPGA vendors have decided that this has to be a very complex and challenging thing to pull off, even though it should be trivial. The best way to connect the PS and PL would be to write your own AXI slave or master IP. This is difficult and beyond the scope of many peoples ability. FPGA vendors like this arrangement because their limited function AXI IP uses up huge amounts of PL resources and confines many within the walls of the IP garden.
Putting aside questions as to why you'd want to do what you propose here's one perspective.
Generally, in order to connect the PS with the PL you need to use the AXI bus interfaces provided in the ARM hardware. There are exceptions and a simple UART is one of them. The PS has a lot of interfaces that aren't being used on most ZYNQ boards. One happens to be a 2nd PS UART. You can 'export' the spare PS UART through the EMIO through the PL. Normally, one would connect EMIO signals to PL pins but you can just connect the TxD and RxD to logic in your PL.
From an HDL point of view there are alternates to complex AXI infrastructure. You can instantiate a BRAM controller in your board design and add a dual clock BRAM with one side exposed to the PL. Your HDL just uses the BRAM as normal and your PS can do read/write operations like any other memory connected to the PS. You are still wasting PL resources on AXI infrastructure but it does ease your PL design burden.
While if makes no sense to me I understand why it might be tempting to have a design with an embedded hard ARM processor complex and an additional soft processor in the PL. Conventional software design is just a lot more familiar and comfortable than logic design. The FPGA vendors know this too and will make you pay an exorbitant price for the convenience. But that's the way technology has always been; fast, cheap, simple, convenient has always been over-priced.
Here's a suggestion. Ditch the ZYNQ board. Buy an FPGA board like the ARTY-A7. Learn how to design logic in the HDL or your choice. It's like learning how to break horses. The first attempts will be a rough ride, but eventually you will end up having a greater appreciation for horses and a usable skill that doesn't rely on crutches like a MicroBlaze....

It turns out that there's a version of Digilent's ADEPT2 utilities available for an ARM host like the RPI4.

You can also use the BSCAN interface to configure a Xilinx FPGA board using your own custom software application. Look over this project:https://forum.digilent.com/topic/17096-busbridge3-high-speed-ftdifpga-interface/

The latter option might prove to be more useful and easier to maintain in the end. The busbridge tutorial uses C# unfortunately, but the main idea is worth pursuing.

I'd recommend putting a lot of thought into how you expect your project will evolve and design a robust scheme before getting too far down the road. You don't want to spend a lot of time developing a scheme that works for a few iterations and then discover that you need to re-think your basic concept later.

You can find all AMD/Xilinx device package pinout names and assignments here: https://www.xilinx.com/support/package-pinout-files.html

I'm not sure what you mean by RESET with regards to package pin names for FPGA devices.

The tools will recognize any of the Digilent JTAG cables, whether connected to a target device or not.

As to whether you can program any Xilinx device using the Adept tools depends.
- Make sure that the cable and the JTAG interface are electrically compatible
- Make sure that the pin assignments are compatible. I've resorted to making adapters to connect HSx cables to non-compatible JTAG headers that work
- The Adept tools don't support every device ID that spans every device that Xilinx makes. Fortunately, the Adept tools are written so that you can add new device support by modifying a text file. I've also done this for using the Windows Adept Utility to program FPGA devices that Digilent doesn't support by default.

The cables, as do the asic modules that Digilent used to sell, work with any Xilinx device. It doesn't have to be a Digilent board.

When working with multiple targets I find the Adept Utility for Windows to be much easier to work with for configuration than Vivado Hardware Manager. Of course, if you want to use the ILA or VIO interface then you need to use Vivado Hardware Manager.

Of course there are JTAG pins on your FPGA board; it would be pretty useless without them as you couldn't be able to configure the FPGA. All programmable devices have dedicated pins for configuration on power-on so they don't appear on user constraints. The tools know where they are. I'd tell you to look at the schematic for your board, but Digilent has been removing that circuitry from it's schematics since it went to the FTDI USB bridge from a Cypress one.

As to how you might use MATLAB with this board, you'll have to pose that question to MATLAB technical support I'd imagine.

You say that you use your own constraints, but at the top of the log file that you provide is this: BOARD=genesys2.

Vivado project settings allow for specifying a specific device in a specific package, or using board files. If you use the first option, then you have total control, as well as responsibility, over constraints that don't involve Vivado IP. If you specify a board, then you are giving Vivado control and responsibility over aspects of your design. Trying to have it both ways can create problems.

You appear to be using a project controlled by tcl scripts. This complicates your ability to control, or figure out what's going on when making changes.

Personally, I try and avoid, to the extent possible, design flows and sources where tool versions can break a design. Unfortunately, the board file approach to specifying a target has gone down the path of abstraction and where both vendor supplied sources and tool version dependencies can cause problems. If letting Vivado manage your project works out then creating a bistream file is easy; if it doesn't work out, then finding the source of problems can be extremely difficult. If you are working with a complicated design that you don't control or understand, then you are at the mercy of the sources. When Vivado manages your project you are shielding yourself from information, that could be irrelevant or extremely useful.

As a general rule, I find that whenever you see this message: "Synthesis finished with 0 errors, 0 critical warnings and 0 warnings." you should assume that the tools have been instructed to hide information from you. Even Vivado IP generated sources usually result a raft of warnings. It's easy to get rid of warning messages, which might mean getting rid of helpful information as well.

I stopped using board files in my project settings as a convenience many versions of Vivado ago as it just causes more problems that are harder to resolve.

If you are running into problems with DRC then the first thing to do is open the Implementation and sniff around and generate reports. You won't find a clue as to why constraints have been ignored, but you quickly identify timing and constraint related problems.

The fact that you are supplying constraints that are being ignored and there are no warning messages from Synthesis or Implementation indicates that your project is set up in a way that is not telling you what is going on. This is a dangerous way to live. You are, unfortunately, a prisoner of your sources, which in this case are scripts. Live by the scripts, die by the scripts....

Part of the debugging process is trying to figure out why you aren't getting expected results. It could be your coding implementation or it could be that your design doesn't understand how the hardware works well enough.
I don't see any harm in putting a 100 ms sleep() delay between the lines where you set the DAC and read the ADC. If that produces results that are more like you expect than you've learned something. You can always tweak the delay to be as short as possible. You can also read the last voltage by getting an ADC sample prior to setting the next one. This is a bit more complicated but might result in a much faster test.
As to whether or not the AD2 is suitable for your application.. I don't know enough about your application to form an opinion.
Generally, expecting some delay between when a voltage source is commanded to change the output level and when it settles on a new value is important to keep in mind. It's possible that due to the timing of transmitting commands to your test hardware, the AD2, makes that update/settle time irrelevant. From the information that you've provided so far, your approach suggests that it isn't irrelevant.
Adding delays between test steps is easy enough to add, and remove later if there's no effect on results.

For what it's worth, this is my reaction to the statement above.
Changing a voltage source and expecting it to settle to another level instantaneously is not a good idea, even if the output is a fast DAC plus some analog circuitry. This is especially true if reading the actual value involves some analog circuitry plus an ADC. So, some settling time is required to determine if the desired change happened and is stable. In practical terms a couple of ADC samples is required.
The question is whether or not the interface is slow enough to provide a time lag between setting the DAC, having the output buffer settle, and obtaining a new ADC sample. I don't know the answer to that question, but as a general rule adding some short delay between setting an output of a voltage source and reading the input of the same source makes sense to me.
However you do this, you need a good scope with a very high analog bandwidth to verify slew rates. Even then actual performance will depend on the input impedance of the load on the voltage source if it's not just the ADC input circuitry.
Conversion between analog an digital realms is not a trivial endeavor.

I have no experience with your board specifically. I have used a number of FPGA boards with a PCIe slot edge interface with numerous PCs using a wide range of motherboard/CPU/Power supply generations. What I'm saying is that you can't assume that your PC can power an FPGA board, in particular a Virtex board from the PCIe connector on your motherboard. You need to read the documentation for your NetFPGA SUMI and your motherboard ( at least ) in order to determine if PCIe slot power is sufficient. Newer motherboards might only provide 25W of 12V to the PCIe slot. If you have an expensive GPU card in your PC then there might be other things to consider, such as if you even have a way to power your FPGA card from the PC power supply.
You can power your NetFPGA SUMI in 3 possible configurations:
From the PCIe slot 12V and 3V pins. Not all motherboards can accommodate this option. From the external power connector on your board and an external power supply. From the external power connector connected to a PC power supply PCIe connector. In this case you MUST verify that the 12V/GND pins are compatible and that your board only requires external 12V supply. If you are using configuration 1 or 3 then you must setup your board to configure the FPGA from FLASH and hope that configuration takes place prior to when your BIOS detects PCIe devices. If you are using option 2, then you typically power your FPGA board prior to turning it on. You then configure the FPGA. Then you restart your PC so that the BIOS detects a working PCIe device. As long as the external power supply never shuts down, you won't lose FPGA configuration.. which is needed to allow the BIOS to detect it.
I'm talking about general concepts, not providing specific instructions for your board.
One thing to keep in mind when using PCIe for FPGA applications is that you OS likely makes heavy use of the PCIe bandwidth for display purposes.
Another thing to consider is the gap between OS and motherboard/BIOS vendors. I have a i13/Z790 CPU/Chipset motherboard running Ubuntu 22.04. This combination has issues with suspend/resume that occasionally cause the GPU to fail to come out of suspend mode. That's just baseline operation. When I add a PCIe FPGA card things can get crazy.
A lot of very unhappy consequences can arise from debugging PCIe HW/SW applications, such as having to reboot your PC by using the power button. In this case Linux file corruption issues can be a pain to deal with. I prefer using a cheap SBC like the ODYSSEY and an M.2-PCIe adapter cable where really bad days don't mean losing lots of money or years of work.
The biggest problem with cheap PCIe FPGA cards ( including the NetFPGA SUMI ) is the drivers. Good Windows drivers are rarely provided and Linux driver code is rarely up to date with the latest OS distributions or motherboard chipsets. Rarely do they have full PCIe functionality.   
One option is to use Xillybus for PCIe and communicate with your board in device mode. Unfortunately, the free demo versions are limited in performance. The good news is that the PCIe drivers are incorporated in the Linux distribution and are robust ( though I have been unable to build them for Ubuntu 22.04 as yet...)