zygot

You can likely get away with 0 ohm series resistors, or a wire shunt, on GPIO pins. Tacking a solder bridge across an 0402 SMD resistor should be fairly east to accomplish ( intentionally or not ). Given the small PCB area of the CMODs an 0201 resistor is more likely to be what you are looking at, but Digilent needs to conform this. It would be swell if Digilent would provide a BOM for their FPGA boards like some other FPGA board vendors do. For a CMOD, the biggest problem might be finding the correct part on the board. Just be aware that removing the series resistor increases the likely-hood of an accident or bad judgement damaging your FPGA device. You might want to just try using the board as is. Start with a slower SPI SCLK and if that works increase it to your desired frequency. That would be a no cost experiment. 40 MHz isn't super high but you probably want to create SCLK from the FPGA clocking resources and use a clock output buffer with an enable. Slow slew rate settings and low current source capabilities to start might be a good idea. Have you every tried soldering an 0201 size part before? It's not easy even with expensive soldering equipment.

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!

I tried Hyper-V on my Win10 box and quickly abandoned it. For the kinds of development that I do it's pretty worthless. Lot's of downsides and no upside. If one does simple software development it might be Ok, I imagine, but probably not enough ok to put up the the negatives. Humor is good for keeping one's sanity ( or perhaps hiding the lack of it ). Sleep is even better. I've on occasion done my best thinking while asleep. Over the years I've found a good solution to a problem that was eluding me for many days. Of course I've also awoken in the middle of the night with a really silly solution to a problem that was just embarrassing once I had time to think about it. About the time when Microsoft needs another cash infusion Windows always seems to get really slow on what use to be a fast machine. Linux seems to make old PCs, even with limited memory, seem perfectly usable. An advantage of two OSes on two separate machines is that if one is being obstinate you can always use the other one. I have a lot of PCs that I need to use for particular work and so far none of them seems to be clingy or jealous if my attention wanders to another one. I suppose that in the near future AI could change that.

I'm guessing that in 5 years the only people doing FPGA development, outside of the market where cost is of no object and certain government agencies have some clout, will be AMD and Intel employees. The future is desktop PCs with CPUs having remotely controlled computing capabilities and metered pay per use ( or perhaps QOS depending on who the customer is ) models. Think HP inkjet printers but less customer friendly. is it too late to claw back the commodity programmable market? What interests AMD and Intel have in programmable logic isn't too hard to decipher.

It sure doesn't. In fact it makes me question why I'd want to contribute to such an enterprise by offering free user support. If NI doesn't care about how it treats its Digilent customers then why should anyone else? I do care about the needs of people wanting to learn how to do FPGA development. It would be nice if NI had a similar interest. I do understand reasons for big companies buying small ones. It's pretty rare that prey gets cared for and nurtured for a long term positive relationship. The customers are usually the ones who suffer.

This refers to the Artix 35T version which has been discontinued. The DDR clocking capabilities of the L part are slower than for the regular speed and power grades. Asmi is correct that there are lower limits to how fast you want to run your DDR3 memory CLK. It's how DDR3 works. It wouldn't be a bad idea for anyone wanting to use DDR in a design to educate themselves about such things. For some Artix devices you are limited to a 2:1 MIG controller design, which is what the reference provides for. For the reference that you are using the 6000ps input clock is the source clock for the MIG controller clocking. So, if you provide a 166.7 MHz input clock and have a 2:1 memory controller design your DDR CLK will be 333 MHz and you will have a 667 Mbps DQ data rate. That's as good as it gets for the XC7A35TICSG324-1L part. If you've purchased you board recently check the part number on the FPGA device as it's likely a larger part that isn't low power. I'm fairly certain that the "Max. clock period" in the reference manual is a poor choice of words because not many customers want to know how slow they can run the DDR PHY clock. For the XC7A35TICSG324-1L I suppose that max clock period and min clock period are pretty much the same as this is the lower end for the DDR3 chip and the upper end for the FPGA device. Feel free to ignore all of the posts to your question so far and wait for someone from Digilent to tell you the same things.

You're funny; at least you made me laugh. You do realize that path delimiters ( / \ ) in Linux and Windows go in opposite directions right? Was that the context for your edit? Really, you can add years to you life by building Linux targets on embedded systems if you do it on a Linux host. As I recall the original Eclypse-Z7 release also had an issue with the compressed FS image. This is a lot harder to do on a Win11 box than on a Win10 box but really, consider dual booting to either Win11 or Linux, and put them on separate drives. Windows really doesn't play nice with Linux, especially if GRUB is on the Windows drive MBR. Alternately, resurrect an old Windows PC or laptop an install Linux on it. Alternately, you could just choose to age prematurely and lose you sanity well before you friends. Windows just isn't a friendly environment for doing FPGA development. Linux has it's issues ( sometimes freedom of choice is counter productive ) but the more development that you do on a Linux host the less you will want to use Windows. As Microsoft migrates to their annual paid subscription with unwanted advertising model the situation won't be getting any better.

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.

Gee, when you described your environment VM didn't come to mind? It would've made it easier for anyone trying to answer you post. Anyway, glad to hear that you are past JTAG connection issues.

Have you looked at the AMD/Xilinx wiki? https://xilinx-wiki.atlassian.net/wiki/spaces/A/overview There are a lot of ways to create a Linux FS that runs on a ZYNQ board. How you connect the HW design resources to the kernel starts getting complicated. This is a very complicated subject to master as it tends to change with kernel releases. I'm no expert on the subject. I suggest starting off by learning how to use interrupts to control hardware on a PC running one of the popular Linux distributions like Ubuntu or Arch. Sometimes the kernel has support for devices that you can control in device mode. Sometimes you need to create a kernel driver or loadable module. For a platform, like ZYNQ, where the hardware is subject to change, before boot or even live, things get complicated. Everything connected to the PS pins should be relatively simple. Everything connected to the PL pins is likely to involve a steep learning curve. Unfortunately, the best learning resources are not necessarily easy to find. It takes a bit of luck.. and lots of effort.

I've been using Digilent designed stuff since before they started selling their own products. Now, if I want to get the latest version of software, I have to fill out a form as if you have no idea who I am ( I have an account and user name ), check my email for a one-time download, and then download one file. In the case of Digilent Adept and the Adept SDK, I had to do the same ritual twice. This happens even while I am signed into the Digilent Forums, which by the way has no link to software downloads. Does anyone at Digilent actually put themselves through the customer experience to see what message they conveying to them? I find this change to be completely unacceptable.

The Arty has a 100 Mbps Ethernet PHY, which has its own hurdles to jump over. If all you need is a point-point connection, I'd encourage you to figure out how implement it without having to be dependent on Xilinx MAC IP or a soft processor.

If you can configure the FPGA on your Nexys A7 board then it would seem to point to the Genesys ZU board. What exactly happens when you try and connect Vivado Hardware Manager to your Genesys board? Is any target listed under the localhost?

I've been setting up a new PC and the Xilinx tools have been problematic. I had to download and install Vivado ( all 65 GB of it ) twice because of missing dependencies. Before trying to install Vivado on a new Linux PC make sure to install libtinfo5 and libncurses5. This is an old issue that's never been addressed. Before installed those I spent about 3 hours installing Vivado only to have it hang creating a list of the installed devices. I had to cancel the install, install the dependencies and do it all over again. Same, thing for PetaLinux. It completely installed and then threw an error for missing dependencies. Once I installed net-tools, libtool, texinfo, and gcc-multilib, it installed correctly with no errors. What a mess and waste of my time.... There's no reason that an install script can't check for dependencies before wasting my time, but, evidently, that asking too much from AMD/Xilinx. At least the introduction give you a heads up on how the relationship is going to proceed.

Today is your lucky day as I've recently installed Vivado 2022.2 on Ubuntu 22.04 wiht a MATE desktop My first attempt at connecting hardware to Vivado had the same results as you, You started out correctly by seeing if your board is enumerated by Linux. lsusb should show a device like the one you found: Bus 001 Device 027: ID 0403:6010 Future Technology Devices International, Ltd FT2232C/D/H Dual UART/FIFO IC lsusb -d 0403:6010 -v will report the particulars of this specific device. You used dmesg and that works too. Now that we know that the Digilent JTAG cable has been enumerated, we are off to debugging Vivado. I created a test project in Vivado and tried to use Vivado Hardware Manager to connect to the target. Got nothing listed under localhost. So, the first question is "did the cable driver get installed?" I followed this procedure: Goto the VIVADO installed directory on your Ubuntu Machine -In this tutorial, we assume installed directory as /opt/Xilinx/Vivado/2019.1 , you can take your’s. $ cd /opt/Xilinx/Vivado/2019.1/data/xicom/cable_drivers/lin64/install_script/install_drivers $ sudo ./install_drivers If this command reports that you've successfully installed the driver , make sure that you have dialout privileges $ sudo adduser $USER dialout Now, unplug the USB cable and get out of Vivado Hardware Manager. Plug the cable back in with the board powered on and retry Vivado Hardware Manager. When you try to automatically connect, you will probably end up with the target being disconnected, but you should at least see something listed under localhost. Right-click on that and connect. You should see the board device and the Program Device options appear. I forgot the exact sequence here as Vivado doesn't show consistent dialog options depending on the context. I suspect that you need to install the cable drivers, and Vivado Hardware Manager can be tricky to deal with, especially if you use a lot of different boards.

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.

As I mentioned, letting Windows automatically update drivers can have bad consequences. If you use Linux and let it automatically update drivers ( like nVidia ) you can find yourself spending hours trying to get your system usable again. Unfortunately, I know all of this from experience. Tools that allow you to modify USB configuration EEPROMs are dangerous if you don't understand what the potential side effects are. The program lsbview only provides informational information. I often find, on a Windows host, that it's a valuable tool for troubleshooting issues. There are a lot of fields in the EEPROM that can be used to identify a product or vendor when an OS enumerates a USB device. Not all USB product have their own VID. This is a potential problem. The Intel USB Blaster has had an issue with device confusion for a very long time, particularly on Windows. Windows Device Manager does allow you to see the driver version for USB devices. If the one on your PC is newer than the one one FTDI's website, then there's a problem.

"Seriously high voltages" and reactive loads are not to be trifled with. If a voltage source, like ESD or other high voltage source is introduced into a circuit, it's going to find the least resistance path(s) to ground or arc to where ever that is. This is why there are high isolation step down transformers and hgh impedance FET probes. Some lessons are expensive, as you've found out. On the positive side, your willingness to post about your experience may encourage other readers think carefully about how to deal with dangerous circuitry. I've seen capacitors fail explosively and blow large holes through circuit boards when the logic power supply can source enough current. So today's lesson is: reactive loads, high voltage or high current power supplies are things you don't want to take risks with. Flying leads connected to ground or power supplies will find their way to places where you don't want them. As Ben Franklin said, "an ounce of prevention is worth a pound of cure". Smart guy Ben was...

Ouch! Unfortunately, the picture, as gruesome as they are, don't tel the rest of the story. A diagram showing the circuit that you are trying to measure might help. Points of contact for your measurement would be good. It's easy to forget things and do something stupid... with bad consequences. I can't tell from the information provided but it certainly seems like a power source issue on the face of it. Powered USB HUBS are wonderful things. While not a 100% safety guard against unexpected or silly operator errors, they do offer significant protection for expensive things, like a PC. Replacing a $30 hub is painful but not as painful as replacing a burned out PC. USB 2 PC ports can source about 500mA at 5V. USB 3.2 maybe 100 W. Either one has the potential for serious damage if abused. When I read "measuring the output of a vacuum tube circuit" I'd think about being very careful about what I'd do.. and think it over a few times with protecting my investments as a high priority. As you now know forensic analysis is not something that anyone should want to do.

Yikes! Well the place to start is with Windows because that's where USB enumeration happens. Windows Device Manager is pretty useless for seeing what's going on. I use usbview, which can be obtained from the FTDI downloads as a utility. This is much more informative about what exactly is attached to the USB host hubs. You might give that a try. I also use the excellent Digilent Adept Utility for Windows to configure Xilinx FPGA boards. You might try that, though if WDM is confused about what endpoint is connected this is likely to fail as well. If you haven't installed a new version of Vivado, then it's unlikely that Vivado is the problem. It's unlikely that your board developed a problem sitting around in an unpowered state. I use Win10 but found a way to keep Microsoft from installing the final 22H2 version as it tries to make Win11 not seem so bad**. If you allow Windows update to automatically update drivers that could be a problem. I've disabled that feature as well from past experiences. Do you have access to a Linux PC? It might be informative to see what that says about your Eclypse-Z7 when you plug it in. ** I recently wanted to use a laptop that had a very out of date Win10 version and 22H2 is the only thing that windows update would install. I thought that it was going to destroy my HD for sure.. After a very long time and multiple restarts I finally got to use my laptop but after seeing the new "feature enhancements" I quickly uninstalled it. At least that's what Win10 update told me it did, but wiht Microsoft who knows what I was left with. At least the crazy ads went away.

Oh, I forgot to mention that ADI has some pretty good information for scientists and engineers who don't have a lot of experience with converter design concepts. Unfortunately., what they don't offer is help deciphering the sometimes cryptic, often misleading, or missing information in the datasheets and marketing hype ... and unfortunately, there's a lot of that... (including their own). Anyway, ADI has some E-books in pdf format that are free to download and read through. At least you get an introduction to the basics, and converter types that are available. I don't know what's happened ot Texas Instruments. They offer a few converter products, but last time I tried to search for products I couldn't find any useful website. I don't consider myself to be an A/D converter expert. I do have a fair amount of experience though and know enough on the subject to (usually) ask the right questions. Asking the wrong questions is no help. Before you can ask the right questions you need to be fairly well read and informed, at least for many engineering topics.

I have not found a good general purpose, reasonably priced, A/D card that I've wanted to use for either the Nexys Video or Genesys2 for signals > 10 MHz for any of my project needs. Digilent makes excellent SYZYGY compatible A/D pods for signals in the 0-30 MHz range. This is why I made a reference to them in my first post. Unfortunately, they don't make an FPGA board that's suitable for your needs. Is 50 MHz the sampling frequency or the high end of your bandwidth of interest? Some converters, like those using wide-band transformer coupling have no DC response and poor low frequency response. This may or may not be a problem. Often A/D cards from component vendors selling evaluation hardware have analog front ends that aren't suitable for general purpose applications. This is especially true for converters sampling at 100 MHz and above. A lot of those converters are for communications and are for narrow-band sampling applications. There aren't a lot of A/D cards supporting an Fs of 100 MHz or higher that accept 10V pk-pk inputs. The analog conditioning circuitry that sits between a signal and the converter is as important, or even more important than the converter specs. There just aren't many FMC A/D mezzanine cards, that aren't really expensive, to choose from for general purpose use. Some A/D converters have full-power analog bandwidths that are much lower than the supported sampling frequency. Input impedance seen by the signal you are trying to capture is usually very important to take into consideration. Can your signal source drive a 50 ohm terminated load? Out of curiosity, I did take a look at the limited information for the FL9627. This is supposedly available through Amazon in western markets. Personally, I don't trust Amazon as a seller for big ticket technology purchases. On the face of it, the price is reasonable. It appears to be compatible with 1.8V LVDS logic which the Genesys2 can support. Getting detailed specifications is a problem, which would put me off. It might be worth your time to check it out. You need to understand Series7 clocking rules, LVDS, IO etc, all of this information is available through the Vivado Documentation Navigator that was installed. You will also need schematics for both the Genesys2 and the FL9627. Diligent provides schematics for the Genesys2. [edit] you will also need the converter datasheet fo understand the data interface. I haven't gone to the trouble of looking at the datasheet for the converter on that board. LVDS interfacing can be pretty straight-forward or very complicated for high data rate to clock rate ratio if SERDES is involved ( 8:1 and above ). It all has to be checked out. SERDES be problematic depending on the FPGA device and pin assignments. I haven't tried making an exhaustive discourse on everything that you might need to consider in picking a suitable converter card, but these are the basics. Beware that most A/D converters have an EOB that is much lower than the data width. Ideally, you want the ability to make the signal that the converter sees as close the pk-pk input range as possible or you lose dynamic range. Do you need a 4 quadrant signal range? AC or DC coupling? The list goes on and on. Unfortunately, like everything else in recent years, there's been a huge consolidation in the converter vendor market. ADI is pretty much the only game in town for newer converter products in the 10 MHZ or higher range. Fortunately, for a few products they do have reasonable EVM offerings, sometimes with an FMC connector, and make a reasonable attempt at providing FPGA support. So I'd suggest seeing what's available, with projec support for Vivado there. You will still need to do you homework, though the Genesys2 borrows a lot from the KC705. So, gee, wouldn't it be great if Digilent made an FMC mezzanine card with SYZYGY ports that worked with their own FPGA boards?

You have the right to ignore any posts that you don't want to read. You don't have the right to choose who posts on a public thread. You also have the right to abuse people who try to be helpful. This will not be a good long term strategy for someone needing help to resolve their problems. This is not consistent with the terms of Digilent's forum use. If you want to have a private conversation, then Digilent allows you to send private messages to any other user. I suggest that you do that instead of embarrassing yourself with these kinds of childish outbursts. It's not a good look. You have posted a lot of statements that a reasonable person would associate with poor mental health issues. There's no shame in getting help for that. I don't necessarily post answers for the benefit of the person starting a thread. Lot's of people read public posts. Anyone can join the conversation.

Large data file transfers via a UART may expose issues on either end. Transferring small amounts of data may not. The first thing to confirm is that you can receive and transmit small messages. This is where trying to echo characters as they are received can help debug your MicroBlaze UART code. One way to test only the FPGA side would be to connect the Tx signal to the Rx signal in your board schematic instead of the USB UART pins. This is one form of loopback. You could send messages and see if you receive them. If there are no problems doing that, then go back to using the USB UART, and change your MicroBlaze application to echoing received characters to the transmitter and type into Tera Term or your serial terminal application on the Windows host. If that works, most likely there is an issue with the MicroBlaze application getting characters out of the UART quickly enough. Make a plan for short steps that will provide a clue as to what's working. Yes, if the polling interval isn't short enough. Interrupts add complexity but there should be example software projects to help. You need to understand that there are a lot of levels of hardware going on here. In the MicroBlaze UART you have small Rx and TX FIFOs. If your code writes to the UART Tx FIFO faster than they can be sentout over the Tx pin then you will lose data. For a USB UART the bridge device has Tx and Rx FIFOs. PC host drivers take care of making sure that receive data is being emptied fast enough. The default driver for FTDI COM devices is the VCP driver. It does have limitations and might have problems with really larger amount of continuous data at higher baud rates. That's why UARTs have flow control. Data going the other way is similar. Serial terminal applications like Putty or Tera Term, in concert with the driver should handle both hardware or XON/XOFF flow control if you set up the serial port to use it. On the MicroBlaze side you need to handle that in your software. You can get a fairly cheap USB UART cable or breakout board as a alternative to the UART/JTAG FTDI device found on most Digilent boards. I am always using a few of these. These support hardware flow control. I find them to be invaluable for debugging FPGA designs. 9600 baud is a pretty low data rate, 960 characters/sec for 1 start bit, 1 stop bit and no parity. For short messages it would seem like this would present no problem for even a soft processor implemented in logic. When there's constant stream of characters over a long time period it's easy to overlook operating conditions that might cause data loss. The safest way to avoid problems is with hardware flow control.

Good catch. I failed to notice that part of the question. FTDI USB UART bridges have 1 KB or 2KB FIFOs, so this is something to think about. You can configure COM devices in Windows to have, I believe that it's up to 4KB, additional temporary Tx/Rx storage. It shouldn't be too hard to figure out some simple test to point to where the problem lies. I you can send short ( 8byte ) messages to the MicroBlaze from Windows using a terminal program like Putty without issues, that tells you something. A simple test would be to have your MicroBlaze echo everything it receives from the USB UART and type short messages into Putty on your host machine. You can also modify your VIvado HW design to do a loopback test. There should be an example polled loopback software application in Vivtis that one could try. The slowest FTDI UART Bridge devices support up to 3 Mbaud. I've used WIn10 to communicate to an Orangepi5 at 1.5 Mbaud ( an odd but fixed choice ), with no flow control using an FTDI breakout board through Putty. But this didn't involve large amounts of data. I doubt that there's a hardware baud rate issue. Since everything in the IPI design is in logic, one could add a sizable external FIFO between the UART pins and the MicroBlaze UART. This would allow an additional way of checking for overflow or underflow issues. This is a lot easier to do using the HDL design flow instead of the IPI flow I'd imagine. Since Vivado Hardware Manage uses the same FTDI device for JTAG connectivity, I'd try operating the UART functionality without Vivado Hardware Manager active. It's not the first thing that I'd check.