zygot

For the umpteenth time... ( do a search of the Forums to see how many people have asked the exact question ) NO, Since going to the FTDI USB bridge for configuration and UART connectivity, Digilent has omitted this interface from it's schematics. There isn't a good reason for this as there's nothing particularly imaginative going on. Perhaps, a few people are willing to pay for the privilege of using the "Digilent JTAG" that the Xilinx tools recognize.

Some historical context. A long time ago, Digilent made JTAG modules. Xilinx even used these on its Xilinx branded FPGA boards like the KC705. Curiously, Digilent never used them on any of its own FPGA boards. The Spartan boards used the Cypress USB bridge that had an embedded ARM processor. At that point the "Digilent JTAG" was more of a software thing than a specialized interface. When the Series 7 boards came out, Digilent went to the FTDI bridge devices like the FT2232. Cheaper and no programming. The Digilent JTAG interface is merely a few bytes of EEPROM these days. There are a couple of small details that anyone can work out.

Unfortunately, clipping information out of published schematics seems to be a Digilent thing now, having migrated to its Zmods.

If Anyone at Digilent has a good reason for slighting their customers by doing this, no one is talking. For what it's worth, some vendors don't publish any schematics their FPGA boards. Not even a hint about how to turn LEDs on or off properly.

You say that your Arty is not an A7 or S7 or Z7? Really? What FPAG device is on it?

Not having your UART project appear to be working is a great opportunity to learn how to debug designs on hardware. This is a thing for your development.
The first issue that I see with your source code is the lack of a testbench. Before trying to implement your design on hardware, you need to do some level of verification in simulation. Vivado has a simulator, so no excuses.
An easy simulation is to instantiate two of your UARTs in a testbench. One would transmit a message to the other. This simulation can be repeated in hardware and confirmed with an ILA once you know that your design is behaviorally correct. Closing the loop of simulation and hardware, that is having both do the same thing, should be part of your project design ToDo list. For both things, you don't need to use the onboard UART device, just a couple of pins shorted together with a resistor or wire. Since a UART has two unidirectional pins, TxD and RxD, you must make sure that you don't try to drive output pins into each other. 
The issue of which direction TxD and RxD go when using the onboard UART that all Digilent FPGA boards have is probably the most common mistake that beginners have with the UART. It's actually a problem that plagued serial interfaces for years back in the day of RS-232. A good way to start thinking about this is to make a simple diagram of all the hardware that's between your FPGA application and a PC serial terminal program....
You might think that all of this simulation and extra effort stuff is a waste of time, I suggest that you think of it as training for when you want to do really challenging designs. If you have no idea how to figure out a plan on finding what's wrong with a design, or if it works all the time, then creating complicated designs isn't very useful. For you current design, you have the source code, which presumably you understand, and a rather simple entity to test.
BTW, even after you get a design appear to work on all of your Xilinx Series 7 FPGA boards, this doesn't mean that your design will work as expected on, say an Intel Cyclone V FPGA board, or even a Spartan 6 board, under all possible circumstances. This is how complicated verification might get. Just when you think that you've works out all the possible levels of behavioral issues that can affect a design, the more that you use it, the more levels that you find that can pose problems.
You might be thinking that comments about your code or theory of design would be helpful. I think that the opposite is true because learning how to figure all of this out on your own is the best possible outcome of your project.

Well I wanted to see your response before getting more explicit.
Due to the limitations of VHDL you are only able to specify signal types as is defined by the IEEE libraries that you use.
You want to use both ieee.std_logic_1164 and ieee.numeric_std libraries. These are not the best combination of choices. I suggest either using ieee.numeric_std, or ieee.std_logic_1164 and either ieee.std_logic_unsigned or ieee.std_logic_signed depending on what format your want to work with. As it stands, you will likely run into conflicts with the synthesis tools as it tries to figure out what you mean by the '+' or '-' operators; if not in this project then in more complex ones.
Let's presume that you comment out ieee.numeric_std and go with the 1164 and unsigned libraries. You are constrained to putting std_logic or std_logic_vector types on your toplevel port list. The problem with this is that Vivado synthesis interprets these as single-ended IO signals requiring single-ended output buffers. You are probably thinking that since your constraints file declares IOSTANDARD TMDS_33, synthesis would understand that it needs to instantiate a differential output buffer. Unfortunately, this isn't how VIvado works. Don' ask me why, ask your tool vendor.  Your only recourse is to explicitly instantiate an appropriate differential output buffer, like OBUFDS, in your code to help out synthesis understand your design.  
While you can get away with letting Vivado synthesis instantiate IO buffers for you, it's a much better idea to do this for yourself.
Read UG472 Series7 Select IO User Manual for more information.

UltraScale is built in a more advanced fab technology that earlier families, which is what most of the PMODs were designed to work with. IO bank voltage ranges for UltraScale are lower. Just make sure that any hardware that you buy is capable of working with IOSTANDARD levels that the ZCU104 provides for its PMOD headers..
[edit] Some voltage translator devices have complicated application details to consider. It's wise to read the documentation for any particular device.

The only differential IOSTANDARD that is supported for Series 7 devices is TMDS_33. TMDS_33 is intended for specific applications, mostly video.
There are a lot of discrete LVDS standards and ICs out there so you have to figure out how to meet all of the dc specifications for the LVDS receiver that you want to use. These devices cover a range of logic voltages. Maxim-ic ( ADI ) has some nice LVDS <-->Single-ended interface devices that are easy to use ( some with internal termination for the receivers )
While you can create plenty of issues driving a signal through an ill-conditioned transmission line i wouldn't call 23 MHz high speed. The best path might be to use a single-ended to LVDS driver IC between your LVDS sink and one pin of the FPGA. You can eliminate many issues by using the lowest drive current possible and reduced slew rate constraints for your FPGA outputs.
Digilent PMOD headers are not designed for custom applications. Digilent so called high speed differential PMOD header do not support differential signalling. I haven't seen any indication that this is going to change, or that Digilent customers will stop being confused as to the suitability of their FPGA boards for a particular purpose.
You've probably seen this recent thread: https://forum.digilent.com/topic/26376-gensys2-diff-clock-route-to-pmod/
One out of many over the years.
There are cheap FPGA boards that support differential signalling if that's what you need.

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.

The simplistic answer is, of course. It's just a software effort.
A more complete answer follows:
PS UARTs aren't great and have very shallow RxD and TxD FIFOs. There are example projects to help get started.  A bigger problem is that the Ethernet and UART interfaces have very different data rates( 125 MiB/s for 1 GbE; less than 100 KiB/s for a UART operating at 921600 baud with no flow control ). Ethernet data transport is packet oriented, UART is not. Ethernet works with binary data; UARTs are designed for ascii text data ( though it's possible to do binary ). There are a lot of differences to resolve.
ZYNQ Ethernet using the GEM requires DMA, and this is complicated using the Standalone Xilinx OS libraries. Still, there are examples to read through. What you want to do is fairly complicated, even for someone with experience using ZYNQ devices and the tools. You mention the SDK. This was depreciated in favor of the more integrated Vitis software development tools since Vivado 2019.2.
Can you provide a bit more details about what, exactly you want to do?
Ethernet PHYs and UARTs connected to PS pins can't be connected to the PL via the EMIO. Ethernet PHYs and UARTs can be connected to unused PS GEM and UART modules vis the EMIO if they are connected to PL pins. Ethernet via EMIO is restricted to a GMII interface.
In general, ZYNQ is designed to use DMA to move data between the PS and PL, or PS connected external memory and PL using AXI bus resources. Vivado has some free IP to do that, though it in't always very robust. AXI interfaces are beyond the capability of most people just starting out learning the HDL development flow.
ZYNQ development can make even simple designs more complicated and time consuming than it might be in an FPGA without the ARM processors.

If you are working with the Nexys Video board, I recently posted this tutorial: https://forum.digilent.com/topic/25315-using-ddr-as-a-video-frame-buffer/
I used the VHDL sources ( modified for that demo )  from Digilent's ADEPT SDK for the DPTI implementation. Recently, Digilent has been all in on the IPI/MicroBlaze design flow. Finding good HDL sources in their GIT repositories can be difficult.
Unfortunately, the ADEPT SDK library software is a bit old and can't be compiled on modern versions of Visual Studio without quite a bit of editing. Perhaps the link posted above will help.  The ADEPT SDK has some documentation that's required to use it's features.
For some reason Digilent seems to be unable to create tcl scripts that build their projects across Vivado versions. Their customers expect a better effort....

IO Bank 500 is connected to the PS directly, so the PL doesn't have direct access to the pins on JF. This is explained in the ZYBO reference manual. The PS ARM cores can manipulate these pins directly.

As I mentioned in your other post, I use these kinds of USB UART cables all the time.

You need to connect TxD, RxD, and DGND to use these without hardware flow control. NEVER connect an external power supply to any PMOD Vcc pin. Just make sure that you figure out which direction the TxD and RxD signals are driven. You need a common ground reference between your FPGA board and an external device to guarantee signal voltage levels and as a current return for single-ended signals that are being driven out of the FPGA device and the external device.

I don't know the rules of your competition but it would seem, from what you've mentioned, that an FPGA board that doesn't have a ZYNQ device would be easier to work with.

The timing diagram is from the AD7991 Datasheet, so I assume that this is where you got it. If not you will want to read the datasheet very carefully because the operation of the device can be a bit confusing.

According to the datasheet, once the device is in high-speed mode it stays there until it receives a stop condition. Once conversions are started, you probably want to continue back-back conversions unless power consumption is a great concern. After a stop condition the device returns to fast mode. Be careful not to inadvertently send a stop condition by changing SDA while SCL is high. When forcing repeated conversions for one operation only frames 2 and 3 are repeated.

ADI digital interfaces for analog and mixed devices tend to be simple in implementation but complicated to use. The documentation could be clearer as well. The I2C standard uses a minimum of signals but has evolved to be somewhat complicated as well. And then not all "I2C compatible" interfaces work exactly the same way either.


Sometimes it's just easier to select a device based on how the digital interface works.

I do not have any experience with Digilent's Genesys ZU boards, though I do have quite a bit with FMC.

The first thing to be sure of, before connecting your FMC mezzanine card and powering up your system, is to make sure that the Vadj voltages are compatible: 1.2V, 1.5V or 1.8V for the Genesys ZU platforms. If not then don't connect your FMC mezzanine card.

You won't find PMCU information in the AMD/Xilinx documentation because it's a Digilent thing. For SYZYGY, which is somewhat "plug and play" there's a whole configuration process that happens before the power supplies on the interface are brought up. This involves a specific DNA chat between uProcessors on the SYZYGY pod and the Digilent PMCU. Digilent has chosen to implement SYZYGY DNA a bit differently than other SYZYGY vendors, though they do abide by the tandard. FMC isn't a plug and play interface though most FMC mezzanine cards have an EEPROM that can be accessed on the carrier board to identify certain parameters about the card. Not all FMC mezzanine cards use this facility.

I don't have a clue as to how Digilent uses the PMCU to set Vadj for the FMC interface but there might be a document that tells you how to interpret PCMU LED blinking messages. Hopefully, someone with better information will reply to your question.

FMC, as used on FPGA platforms, require extensive due diligence to ensure compatibility before trying to use them, especially if LVDS clocking is involved. There are a lot of older FMC mezzanine cards the are not compatible with most UltraScale based boards having an FMC connector due to a need for Vadj to be 2.5V or 3.3V. Don't assume that any FMC mezzanine card can be used with any carrier board having an FMC interface.

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

The EMIO allows one to route GMII Ethernet signals from the Pl to one of the 2 GEM interfaces in the PS. In order to do that you need an Ethernet PHY connected to PL IO pins. I'm not sure how you could do that with your board. The EMIO doesn't work the other way around; that is you can't route PS MIO pins to the PL.
Using any recent version of Windows for Ethernet connectivity to development boards can be a painful experience. The fact that Win10 requires you to install an iperf3 client application is generally a sign of impending troubles. My Win10 box has 2 Ethernet ports. I use one for keeping the OS up to date and rare internet connectivity, and the other is set up with a static IP address. I use the static port to communicate with FPGA boards.
I do remember trying to do what you are trying to do a while back. The only thing that that I found was a test of the ZC702 PS Ethernet running the Standalone iperf server application.  I too installed the iperf3 for Windows x64 application and had no success. I did manage to run an iperf client on Centos6 however with success. For that test I used a USB 3.0 Ethernet dongle assigned a static IP. According to my notes this was the Centos6 commend to the iperf client:
iperf -c 192.168.1.10 -i -t 20 -u -b 1G -B 192.168.1.20
The first IP address is what the Z7020 Ethernet was using and the second is the Centos Ethernet static address. If you have multiple Etherent ports on your PC you must specify which port to use with the iperf client.
The first thing that anyone wanting to connect something to their computer via Ethernet should do is make sure that the 2 nodes are talking. This is best done in a terminal window or Windows command window using ping. If the addresses aren't compatible you usually get a message about the target address being 'unreachable'. Sometimes this can be resolved by correctly setting the address mask.
Based on what I know so far though, I'd say that your biggest problem is no Ethernet connectivity in your ZYNQ platform. You might want to try building the iperf client or server application for you PS connected Ethernet port.
 

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.

921600 baud is the highest value that most terminal applications will run at, and certainly if you don't use hardware flow control. FTDI has a terminal application for its USB-UART bridge devices and that only works up to 921600. I believes that this is the limit of the VCP driver capability that Windows wants ot use by default for USB serial devices. Of course you can do higher baud rates up to the limit of the bridge device which is 3 Mbaud or 12 Mbaud for H devices. For FTDI devices you need to use a different driver, write your own software application, and use hardware flow control. I've don't this but it's tricky. For a device like the FT232H 8 Mbaud is more practical.

I don't know how it works on MicriBlaze, but for a ZYNQ device you can set the UART baud rate in the board design ZYNQ subsystem block. I doubt that the Vitis console supports baud rates of 921600 as the SDK doesn't, but you can always use a different application for UART communications with your FPGA.

While high baud rates via UART connections seems to be desirable there are a lot of issues to address complicating real world application.

Xilinx has a few application notes for using the XADC feature of its Series 7 FPGA devices. Yes, it is complex.
The first question to ask is what method of FPGA design flow are your using? Any answer will be different for HDL or block diagram flow.

The naming convention for Xilinx tools in regard to differential signals is "<name>_p", "<name>_n". The tools are sensitive to this convention. But this isn't your only problem. You are assigning single-ended IOSTANDARD LVCMOS33 to pins that you intend to be differential. But, that's likely not the biggest problem. The only differential IOSTANDARD for pins on IO banks powered by 3.3V is TMDS, which requires external 50 ohm terminators to ground.
Before trying to do a design using a particular logic standard you need to understand the capabilities and limitations of the device. For Xilinx Series 7 FPGAs almost everything that you need to know is in the ug471_7Series_SelectIO Reference Manual. This is no different than trying to use any electronics componet; it's just that FPGA devices are a bit more complex.
It's unfortunate that FPGA board vendors are confusing customers by implying that their products can support differential signalling when, by design, they can't. Digilent isn't the only one doing this. To my knowledge the ATLYS is the only FPGA board sold by Digilent that has a PMOD connected to and IO bank that can be driven by a user selected Vccio compatible with differential signalling IO other than TMDS. The FMC equipped boards do provide this, but only for the FMC pins. Even the CMOD product line only offers 3.3V IO.
If you want to use a PMOD pin to drive or receive differential signals then your best option is to use en external differential driver/receiver device that converts differential signals to single-ended 3.3V signals and visa versa.
So how many years is it that I've been trying to get Digilent to allow their customers the freedom to use Xilinx FPGAs to their full capability to no avail? Well, they do have 2 SYZYGY capable FPGA platforms that do this. Unfortunately, not all users are able to design custom SYZYGY pods. Connecting external interfaces to high density SMT connectors is beyond the capability of most FPGA board users.
There really isn't a good excuse for not providing at least one 2.54mm or 2mm header with pin connections suitable for differential signalling so that customers can at least experiment with it. Ultimate performance isn't so important and is unlikely to be achieved anyway unless the FPGA has HP IO banks and internal termination options.
 

The DAC1411 hardware design doesn't support selection of AC or DC coupling directly.