zygot

What, exactly are you referring to by USB data rate?

Are you trying to use the UART? The FTDI *H USB bridge device UARTs can support up to 12 Mbaud, though you will need to use the D2XX driver and API on the USB Host side. Most other USB bridge devices support up to 3 Mbaud. Windows COM devices go up to 921600 baud if you set the baud rate from Windows Device Manager. This is suitable for USB UART communication without any flow control. I've used Putty on Win10 to communicate to an Orangepi board at 1.5 Mbaud with no flow control. All of this information pertains to ascii data, not binary data.

If you want to pass data between your board and your PC you might find this tutorial interesting: https://forum.digilent.com/topic/24531-debugging-with-the-ftxxxx-mini-modules/

The short answer is that 921600 baud rate ( ~ 90K Bytes/s ) with no flow control for ascii text characters is pretty easy for a host TTY or COM device. Above that the answer gets complicated. I don't know of any USB bridge device that supports baud rates over 12 Mbaud. Note that FTDI devices that support high baud rates can do 8 Mbaud and 12 Mbaud but nothing in between without baud rate aliasing.

I think that it might be helpful if you provided some information about what you want to do.

Note: The Nexys Video and Genesys2 boards support DPTI mode for binary data communications at 30+ MB/s. Unfortunately, trying to add this capability to the Arty A7-100T uis difficult due to the limited IO pins.

I hope that you didn't think that my thoughts were being critical. You are right that using tcl scripts to generate FPGA projects, and obtain configuration files, that work for any version of one vendors tools can be complicated and frustrating. That's why it's great that you started a thread on the subject. I don't know about you, but I'm hoping that it generates some constructive posts from a variety of people bothering to read it. Gems are usually easy to miss lying in the grass.
FPGA design flow for a published project meant to enlighten a wide range of readers or just pose a concept to think about is generally different than that for paid commercial work. For me, it's usually get an idea implemented with a reasonable amount of time and effort and publish it or never get around to the publish part. Sharing a project that only requires running a script to reproduce may be ideal.. or maybe not. I guess that it depends, depending on what your aim is.
I agree with you that an all text source HDL project is a preferred goal. It generally involves a lot more work. Sometimes, the GUI IP is informative and might make for better designs. I believe that this is the case for MMCM or PLL clocking resource instantiation. Of course you can always do a design using a clocking "wizard" and then instantiate a macro or primitive in your published design. The same argument can be made for hard multipliers or DSP blocks; perhaps more so as tool support for these has gotten worse and more constrained, in terms of feature use, over the years. Vivado doesn't even support primitive instantiation of DSP blocks officially anymore. Then there are external memory controllers. There are transceiver based interfaces like PCIe and serial communications.
Push-button bitstream creation ( running one script ) hides a lot of details that might be good to be aware of... even for the designer who might want to update an old design in a newer tool version, even when they think that they've previously covered all of the details. There are usually a lot of unseen things going one behind the scripting text that have more importance or risk then one might reasonable assume. And a really complicated set of scripts can be as hard to follow as any other project flow.
All of those thoughts are for one FPGA vendor projects. Trying to create vendor agnostic projects can drive one crazy.
One thing that I know for sure, my preference is to have all sources for a project in a text format ( not HTML ) that I can read through and run utilities that help manage text files.
I'm more comfortable designing in VHDL. I think that, for a variety of reasons, Verilog design is superior. VHDL just hasn't gotten the love, and updating, that it deserves....
Last thought for now is that Quartus will be happy to create a tcl script for your project, if you like excitement. But it will help with the boilerplate.

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

For some endeavors, the distance between two points, such as starting from zero experience and ending up with a completed working design running on hardware, is usually not a straight line. Everyone learns differently and at a different pace. Be prepared for the unexpected and you'll be fine. Mere mortals like me have learned that starting off simple and adding complexity as I gain experience generally works out to be the quicker route to success. But that's what seems to work best for me, most of the time....

[edit] It's always tempting to ask yourself "can X platform be used to accomplish Y goals?" instead of "is there sufficient evidence that I can use X platform to complete Y goals within my budget and time constraints?" What you don't know can hurt you. When evaluating suitability for a particular platform it helps to see what the platform vendor demos for their products offer, and what version of the tools were used to implement them. I tend to be cautious because I know that facts out of context, and advertising promises rarely hold up when I'm doing actual real-world project development. Bord capabilities and board functionality are not the same. There are a lot of "ifs" and "exceptions" lurking in the details that the advertising doesn't cover. Again, I'm me doing "me projects". Your mileage, or download speed, or whatever may vary...

Most people who visit this site use the IPI flow, because that's what the FPGA vendors want to promote, and it's for product vendors to easily to throw a simple demo together.

For simple HDL flow designs, with no vendor IP ( not even BRAM or FIFOs ) a simple tcl script is a great idea. If you have any sources that are subject to vendor tool version changes then the tcl build script can get very messy. Digilent has proven that over and over with IPI demo tcl scripts that only work with one Vivado tool version. You don't even have to have any vendor dependent sources in your design as Xilinx has a habit of rendering projects created in one tool version into a whole new project by changing the syntax of constraints, or changing the tool database structure, etc., etc. Still, even for simple projects that don't need timing closure effort, even for hobby use, avoiding the GUI can be a really good idea. Of course, for commercial development text based build scripts are the only reasonable option.

My view is that posts like this are only useful for getting people to think about things that they might not have experience with, or didn't think that they had time to explore. With that thought, great post. Someone should have started it long ago. even on an IPI, MicroBlaze oriented forum like this one.

Not necessarily. For most Digilent FPGA boards an older version of Vivado is fine to use; perhaps even better than a newer version. Newer tool versions may not have the free IP that you want, and older versions have. If you are contemplating a board purchase look around to see what version of Vivado the demos for your board use. There's a big problem with Digilent demos and tool versions. Installers for older versions of Vivado fit on a DVD. Current versions of the tools ban be a 60+ GB download.
As to why you are using Win8, that's another issue as that hasn't had Microsoft support for a while now.
An alternative is to install a supported version of Linux for Vivado onto a second HD and boot to either Win8 or Linux via BIOS boot options. Windows has a tendency to interfere with Linux boot block code. I like to keep the separate to the extent possible. Personally, I'd be worried about exposing a PC with unsupported an OS to the internet. 
If all you want to do is learn how to do FPGA development and learn how to use the tools you can install any version of Vivado, pick any FPGA platform, and simulate your designs. Just be aware that newer Vivado tool versions might have changes making porting projects built in earlier versions a bit of effort, and that constraint syntax changes. If you want to use a ZYNQ device, tool version earlier than 2019.2 have quite different software development frameworks. This is the only real downside to using an older version of the tools... you are learning how to use a tool that is not current. Generally this is not a big issue, especially for a beginner who just wants to start off.
The Vivado doesn't need "activation". The free version provides most of the functionality the you will need. You will need create a user account with AMD/XILINX to download and get access to most of the documentation. This is free to do. Most Artix devices and most ZYNQ devices are supported with the free tools.

Could you be more specific? What kind(s) of sensors are you talking about? It's hard to provide a good answer without enough information.
In general Digilent FPGA boards are designed to support their PMOD ecosystem, and are IO pin deficient. They do sell a couple of boards with 1 FMC connector but finding an off-the-shelf mezzanine card that supports 128 undefined sensors is going to be a problem. Even if you can list all of the exact sensors by part number an answer is not likely to be a simple one.
Usually, for low Fs, multiple channel ADC applications, analog inputs to the sampler(s) are time mutiplexed. Are you prepared to do some digital and analog design and prototype construction?

Hello,
I've posted a new tutorial on Project F covering Tcl build scripts with Vivado:
https://projectf.io/posts/vivado-tcl-build-script/
It's surprisingly easy to automate building your design with Tcl. I wish I'd known this when starting out with my Arty board back in 2018. Anyway, I hope you find this useful, and please do let me know if you have any suggestions or spot any errors.
Cheers,
Flux

Amen. How many times have I posted the same thought? The AD product support is excellent beyond all expectations, why do stupid things to engender consternation among your customer base that has no benefit to anyone? Please resist old habits and make life easier for your customers... and yourselves in the process.

The results of using source code attributes like KEEP vary from vendor to vendor, and I suppose depends on the source. Glad that you resolved your issue despite my attempt at "assistance". Except for when I use Quartus, I rarely run into problems with synthesis optimizing away my source signal names and a large chunk of my design. Such synthesis and implementation commands don't always resolve tool issues.

What do you mean by "dual channel mode"?

Hmm, 28 clocks sounds about right. The Mig core with DDR memory is really slow for random read operations. It's pretty good for reading large block of sequential memory. This is why modern processors fetch instructions and data out of onboard cache instead of external (DDR) memory.
Even if you design a core that attempts to random read and write operations with minimal latency the controller in the DDR has it's own latency which will discourage that kind of use..

I agree with the notion that keeping copies of documentation with projects is important. What's worse than no PDF? A PDF with errors and misinformation, and boy, Digilent has had their share of those. I'm not picking on Digilent because I've never worked at a place where documentation was up to date, always correct, and readily available. Same for vendor tools and products. Same for stuff that I've created... Digilent isn't the best at providing documentation, but certainly isn't the worst. Some FPGA board vendors don't supply even a minimum.. to the point where they aren't going to sell me anything. Altera documentation used to be pretty good.. but those days are long gone. Xilinx documentation has always been pretty bad, but if anything there's been some improvement over the years.

Ultimately, documentation, like valid constraints files, are living things that have to change with board revisions and part swapping for a production of product when a part on the original BOM isn't available, and in a meaningful time frame. It's a big problem.. for everyone... and there's no perfect solution. Heck, I keep notes on everything that happens during a project development cycle and even those notes sometimes have errors. I've been around the merry-go-round more times than I care to acknowledge and the scenery never changes.

Quite a while ago Xilinx stopped supplying PDF documents. They do have the Document Navigator that keep a catalog of document versions related to tool versions. While I hated this at first, I've come to see it as a positive step. Now, if they could just get those version specific documents accurate and meaningful. As I mentioned.. it's a big problem. I'm sympathetic to document providers everywhere.

These days most browsers can create PDF versions of HTML pages, unless they specifically are written in a way to not work with browser page printing software. Digilent has never produced a PDF of the Genesys2 reference manual ( to my knowledge ) but I still have a PDF included in the /doc folder of all of my Genesys2 projects courtesy of Firefox. So, perhaps asking for PDFs isn't wxactly what we want. Perhaps, what we want is on-line documentation that can be turned into a PDF with any commonly used browser. (Yeah I know that I'm a hold-out with respect to Firefox ).

I feel more comfortable mentioning what I don't want.

I don't want documentation in a form that can have hidden malware embedded in it.
I don't want documentation that tells me stuff that isn't accurate or relevant
I don't want to go online to use a product because there's no way to create viewable documentation ( generally in the form of a PDF ) that I can use off-line. 90% of what I do is on a PC that's not connected to the internet ever, much less all day while I'm working.

I'm sure that there's more to what I don't want... but this is a good start.

[edit] Oh, last complication to the topic that I forgot to mention. Adobe won't like it but the term 'pdf' has become the 'xerox' of the past. These days there are multiple products that create pdfs and even more that render pdfs. Browsers, like the on in Firefox, may not render a pdf the same way as a different browser does. I've seen this. As wonderful as the pdf format is, it's not perfect or even necessarily consistent.

There are some nice tutorials available for anyone wanting to do FPGA based video using an HDL. Most of what I've come across, for HDMI at least, is based on work that Mike Field has published. None of them use external memory as a video frame buffer. This tutorial demo project aims to change that. Enjoy. Thanks Mike.
I've added a demo for the Genesys2 that implements a True Color 32-bit RGBA video frame buffer in DDR for 24-bit RGB HDMI displays. It's the obvious extension of the Nexys Video 8-bit indexed color demo.
 
NexysVideo_Demo_R1.zip
 
Genesys2VideoDemo_R1.zip

@BMillerThanks for the correction. UG909 has a list of supported devices and all of the ZYNQ-7000 series are included. I was aware of DFX but hadn't connected it to partial reconfiguration.

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.

As I recall, if you damaged your board, it was because you connected an external 5V power source to one the of the PMOD 3.3V rail pins. This has nothing to do with pin functionality.

Most ZYNQ based FPGA boards only use one of the PS UARTs so you can connect the unused one through the EMIO to the PL and then to any IO pin connected to a header on your board. Or you can just connect the unused UART to your PL logic. It's also possible to implement a UART in the the PL logic and allow your PL design to connect to an external device using a direct connection or through a USB UART cable. Any two pins on a PMOD on any FPGA board made by Digilent can be used as a UART interface.

Connecting a PS UART to the PL allows you to use one of the PS cores to implement a UART. The PS UART has some limitations, like very shallow data FIFOs. You can get around FIFO limitations by connecting a PS UART through PL logic. You have even more flexibility by designing your own UART in an HDL, though, if you want to connect this UART to the PS you need to use a AXI bus transport to move data between the PS and PL.

There's clearly a language barrier here so everyone appears to be having a difficult time communicating.

If LED13 is lit then that means that the 3.3V power supply on your board is still working. I probably shouldn't have suggested trying to power the board with an external power supply until you've tried JColvin's test first. This was my mistake. You haven't disturbed me at all. I just wish that I could help you.

When using USB TTL UART cables, make sure NOT to connect the Power wire ( I'm assuming that this is the Red wire in the picture shown above ) to your board. Doing this may indeed prevent you from configuring the devices on your FPGA board. These cables are designed to allow powering an external board from the USB power pin from the cable. DO NOT try driving the VCC pins on your PMOD connectors externally.

I frequently use such UART cables and breakout boards and make sure to tape the Vcc wire back so that it can't accidentally get connected to my FPGA board. You do want to connect the GND wire to one of the GND pins on your PMOD header.

I suspect that you didn't damage your FPGA board if you used the Red wire.

It's a good idea to have FPGA boards un-powered before attaching external devices. Then connect your UART cable ( make sure that it supports 3.3V logic and not 5V ) to the FPGA board and then the other end to your PC. If the FPGA board is off and there's any sign of it being powered ( such as a faint glow of an LED ), then stop and disconnect whatever you just connected. For some boards this can happen with HDMI cables because they have termination resistors that connect to the power supply on whatever the other end of the cable is connected to. If everything looks good, then go ahead and power your FPGA board and configure the FPGA device.

What happens if you remove the USB cable from your ZYBO and power the board from an external power supply? Be sure to follow the instructions in the ZYBO-Z7 reference manual and set the jumper on JP6 correctly for using VJACK instead of VBUS. Make sure that the power switch is on.

You've posted a lot of pictures representing connections other than you've described so it's hard to tell what's happened.

VBUS from a USB 2.0 port can supply up to 500 mA, which is enough to do some damage if it's driving pins that are also being driven by onboard power supply regulators. Generally, the VCC wire on USB TTL UART cables come from a small regulator instead of directly from VBUS which limits its ability to supply current.

I forgot about the fact that the ADC converters on the ZMODs can be programmed to output a reference signal instead of conversion data. In fact, I'd recommend that the first objective of anyone wanting to implement their own ADC capture design start off using this capability to verify connectivity between their design and the ADC device. In addition, no external signal is required. That means no offset or gain scaling is required. It's a good starting point for working with the signed output code of the converter. If you can't properly interpret the ADC test output, then trying to work with actual conversion data is going to be a rough ride. Before you hop on top of a real bull you might want to try a few practice runs on a mechanical bull at the local tavern. Similar concept for FPGA development.

Experiments that I've done with Digilent so called high speed differential headers suggest that expecting to implement 68 Mbsp toggle rates to an external device is probably overly optimistic. Below 50 Mbps? Sure, if you are careful. Of course there are a lot of considerations involved:
There's no consistency with these PMODs between Digilent's boards, except that _n/_p pairs are length matched to within about 20 mm. The traces connecting the FPGA to the PMOD headers are laid out differentially with 100 ohm impedance beween pin pairs ( at least on the boards that I've used). This is might be problematic for single-ended designs. Since none of the boards with these PMODs support any differential IOSTANDARD they are constrained to single-ended logic. It's possible to implement TMDS33 IOSTANDARD logic if you add 50 ohm termination. You won't be able to place termination at an optimal point for receiving signals and TMDS has its own set of issues to deal with. If you are going that route you might as well use HDMI connectors designed specifically for TMDS. Some boards expose a clock-capable pin to at least one of these PMODs. Some boards don't. The Arty S7 does for JB[3:4] The lack of a clock-capable pin makes receiving signals impossible for source-synchronous designs. Digilent doesn't attempt to match all eight pairs. This might be a problem for bussed interface lines when the FPGA is driving signals to the external device. For most Series7 devices you can use IDELAY features of the IOB to correct minor skew for signals driven into the FPGA. The amount of delay is very limited. I have no experience with Spartan7 devices in this regard. The Spartan7 is a low performance Series7 family. It matters whether your application is source-synchronous with a reference clock or if the data sink is using oversampling asynchronously to receive data. Achieving tight signal timing across multiple signals from source pin to sink pin, even for a higher performance family would be non-trivial at 68 Mbps toggle rates. Above 50 MHz maintaining high signal quality PCB trace characteristics becomes important. PMOD connectors are not optimal, but should work at your rates. The problem is that Digilent PMODs aren't designed for any particular purpose so you don't have optimal transmission lines just between the FPGA and the PMOD header. Then you have to go through another similar header to the device that you are connecting to. Impedance discontinuities and capacitive loading start becoming important considerations needing control. It's a mystery why these "differential PMODs" keep appearing on Digilent boards that don't support differential signalling. The Spartan6 ATLYS s the only exception as it has 1 PMOD connected to an IO bank that can be powered by 2.5V. Digilent has never made a product for use with these things. It's sad, but Digilent, since Series7 came out, just has no interest in making the kind of FPGA development board that you want. It wasn't that way with their Spartan 3 or Spartan 6 boards. It certainly wasn't that way for boards that designed for third parties in the past.
I am not saying that you can't do what you want to do with a Digilent FPGA board, but you might want to look into boards with FMC, HSMC or SYZYGY connectors for your project.  

No mystery here: you selected a bistream file created  for a ZYNQ device and your board is not a ZYNQ device. If you started off with a demo for your board and selected the correct device your bitstream would be correct. There's very little likelihood of getting past synthesis, implementation or bitgen targeting the wrong device as pin assignments would not match.
Where are you finding these?
If you look in the Vivado Project Settings, what device is listed?

I recently posted this: https://forum.digilent.com/topic/24531-debugging-with-the-ftxxxx-mini-modules/
If nothing else, it might give you some ideas about how to boost that 921600 baud rate by 27x ( in terms of bytes/s data rates ). The Eclypse-Z7 PMOD design is unlike anything that Digilent has done so far. I haven't tried using the DBUG_CONTROLLER with the Eclypse-Z7, but had some ideas about a possible demo for that board. All you need is 4 pins of one of the PMODs to implement a similar concept. As it stands, my implementation is limited to blocks of 64 KB, but this isn't hard to get around.
The only alternative is the PS Ethernet. If you design has a data path to the PS, you can implement a simple Ethernet application using the PS GEM. As I recall, it's used by software tools for communications. The board also supports USB OTG, but you can't use the standalone software development path with the OTG stack. The truth is that you need to be using a Linux-like OS if you want the PS to use OTG or Ethernet in a user friendly mode. But Linux will have to run out of the limited PS DDR memory, along with the Etherent, the ARM cores, and any AXI DMA connecting the PS to the PL resources. All in all the Eclypse-Z7 platform is much harder to develop on than a good SYZYGY platform should be.  
So far no one has posted any questions to the thread in the link so I haven't had any incentive to update it.
Trying to use Ethernet with the standalone support is not trivial because of the way that the GEMs work. I think that Xilnx has just decided that anyone really interested in using ZYNQ PS Ethernet will be running on Linux, where open source code support is available. It's certainly the case for USB connectivity. Since ZYNQ is supposed to be ideal for cheap embedded applications, this strategy doesn't make a lot of sense to me; but it is cheaper for Xilinx.

The A7-35T is probably a bit small for video applications, even low resolution VGA ones, but you can do simple display things with the Basys3, as this tutorial points out: https://forum.digilent.com/topic/19910-basys3-game-tutorials-beeinvaders/

A problem with small devices like the A7-35T is that Vivado IP and MicroBlaze will use up a lot of its resources if you have to use that design flow. For an all HDL design you can fit a lot of functionality into even the smallest A7 device if it doesn't use external DDR3 memory.

Someone with a very tight budget has to be very careful before spending money. These days boards don't necessarily come with all the stuff that you need to use them; like USB 2.0 cables, power supplies, etc. Also, because of global chip shortages process for even old board have gone up 50-100% over what they sold for when originally released.

I'd recommend that you take an inventory everything that you will need to actually enjoy the fruits of your labor and add up the costs. It might be cheaper to spend more money on something that provides most of it than starting off with a minimal expenditure and buying add-ons as you go. For any kind of game experience you not only need a video output, and cable that's compatible with a monitor that you have handy, you need some way for the user to interact with your application. Do you expect to have audio? Do you need joystick inputs? Make a list and add it all up.

Lastly, and perhaps more importantly, how are you going to proceed with your project goals? Do you want to learn FPGA development, or are you more interested in bootstrapping projects that you've found on the web? If it's the latter, then buying a platform for which project code has been written for might make more sense.

Be careful of making an investment in something that may not allow you to get to your end goal, or will be a lot more expensive getting there by the time that you've purchased all of the extra stuff that's needed... only to find that you have a platform with very limited potential. Most cheap FPGA boards are designed to sell you more stuff. If it's a trap, avoid it, if it gets you to your goal within your budget, then do your homework and go for it if it makes sense. Even some cheaper Intel FPGA boards have PMOD connectors these days. Be cautioned that Intel has restricted the free version of Quartus to Cyclone 10LP and earlier and that some of it's free IP, like DDR interfaces, are broken or very hard to use.

Cheaper Xilinx FPGA boards might not be the best choice, in terms of value for cost. The Cyclone V Start Kit is available for about double what it originally costs, but comes with a lot more features than a really cheap A35T board. I'm not recommending that as an option, just as an example of something different that's currently available from distributors. Unfortunately, this is not a good time to dive into cheap FPGA board development on a very tight budget.