zygot

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.

"to see the discarded values on a second basys3, i need to connect a second basys3 to my computer." Your description makes no sense. Explain.

BMiller: "But looking ahead, how much longer will x86 be around? It's the IBM 360 in the age of VAX. " Hmmm... I remember when the PowerPC was going to kill of the x86 architecture. Today there are adults that have never heard of a PowerPC, yet, like a bad cold, new x86 CPUs and a slew of captive supporting products are being released by two companies every year. Sigh! ARM will one day be forgotten, as will us all. All hail progress, mystifyingly slow as it sometimes is. I'm not sure that a analogy comparing a "big iron" mainframe like the IBM360 to something like a VAX holds up well once you start thinking about it. But I get your point.

BMiller, There is no "tiny" version of either Vivado or the Lab Tools. With Vivado, you don't need to ever bring up the Vivado GUI if you like writing TCL scripts to all project activities up to and including building a bitstream. You don't even need the GUI to configure a device. If you need to use the Vivado debug IP, like an ILA, then you need a GUI interface. For professional work, TCL scripting is the only way to go. For short educational projects the GUI is generally quicker. I imagine that once you've created some TCL boilerplate one might want to avoid the Vivado GUI altogether. Unfortunately, given the bugs that always seem to be included in every Vivado release, I don't think that I'd want to do many designs without being able to open the GUI implementation deign views. If your organization has a few hundred FPGA engineers, all specialized to do one part of the development process, then you'd never use the GUI. If your organization has 1 employee, then adding layers of development might not be too efficient.

BMiller: " It would be very nice, though, if the (TcL-only?) version of Vivado ran on the Zybo" I remember, not all that long ago, reading a dismissive comment by Linus Torvalds about the ARM ecosystem. Never will be a viable platform for Linux.. in so many words. Boy was he wrong; I knew it when he said it, and this was before Apple transitioned from x86 to ARM. I happen to like the RPI4 ( and if one every gets delivered to me an RPi5.. been waiting for over 2 months now ). But really, it just isn't designed to run something like Vivado. It's not just the ARM cores, or the limited memory, but also mass storage for an OS and user files. A SDcard just won't cut it. Forget about ARM code portability. There are alternatives to the RPi4, like the OrangePi with a M.2 SSD capabilities. Still, wouldn't want to install VIvado on that. Both of these ARM based controllers are much faster than a Z70xxx FPGA by a wide margin; even faster than an Ultrascale ZYNQ... I've done them all. The big problem is that once you try doing something interesting on these platforms you start running into bottlenecks. Like poor USB 3.0 data bandwidth. Like DMA bottlenecks. Even if you are only using CLI mode all of this congeals into system design headaches. Personally, I prefer a cheap X86 Celeron based SBC like a X86J4125V2. Not that much more expensive, once you assemble all of the required hardware. It does have a 4-lane PCIe M2. port for connecting an FPGA board with PCIe, and a separate M.2 suitable for a SATA SSD, or if you like rotating storage a SATA port that can be directly connected to an SSD or HD. It's also in the same power dissipation tier as the RPI4-Rpi5. I have installed ( older versions of ) Vivado on that platform so that I can do everything that I need remotely. It's all about picking the right tool for the right job. Fortunately, as I pointed out in my first post to this thread, you can configure a Xilinx FPGA board from an RPI4 using the ARM version of the Adept tools.

Dan: "I'll wait for the forum request for help to arrive from the individual trying to install Vivado on an RPi before making such a declaration" One doesn't NEED to try and milk a bull without knowing how it's going to work out ( unless it's an order from the sarge...)** I've had enough experience to know that software built for an x86 processor isn't going to run on an ARM processor even if you manage to find some virtualization software that runs on an RPi4. Now... if anyone wants to prove me wrong, then I'd be more than happy to be proven wrong. ** OK, I can see a couple of endings here ( none of which gets me milk for my cereal: (1) really angry bull and lot's of pain (2) a really large animal who wants to be my BFF Trying to run Vivado on an RPi? That's just plain crazy talk...

1 GbE is quite nice. USB 3.0 can be 2-3x faster, with a few caveats, perhaps. PCIe can be a few orders of magnitude faster than the best USB 3.0 bridge, though it comes with a few warts. None of this is germane to the OP who wants to process 512x640x16-bit images that have to be transported on and off the FPGA ( an A35T ) on his BASYS3. One image is 655360 bytes; considerably more than 512 KB. You aren't going to create a single memory structure in an A35T that large. To make matters worse, the VGA display only supports 12-bit pixel depth. So, does this mean that the project goals are impossible? I don't know. If the image processing can be done on smaller sections of the image file in succession, then there's hope. I'm pretty sure that most of the time spent on doing this will be moving data onto and off of the FPGA board. That's not necessarily a show-stopper. Having to implement functionality with fewer resources than you need is the SOP of many an engineer.

With regard to the FT60x bridges, I've been using their FMC eval modules for many years. This past year I've gotten back to using them in new projects and discovered that the current D3XX driver performance is considerably slower than the version that was used when I did those old projects. Throughput is about half of what I was getting before. Even using the old bitstreams and rebuilding the software sources using the current driver doesn't help. Raw bandwidth is a nice metric, but not necessarily useful for predicting final software application performance. I've lost most of my interest in D3XX as a result. The Cypress ( NXP?) FX3 is a better bridge device. Opal Kelly's implementation of it is actually pretty good and reliable.

Dan: "There is no reason or need to install Vivado on a Raspberry PI. " NO one is going to install Vivado or even the Lab Tools edition that just includes the Hardware Manager functionality on a Raspberry Pi host.

@Dan, You too can get 12 Mbaud out of some of the FTDI UART bridge devices like the FT2232H. It's all explained in the "debugging with FTxxxx Mini-Modules" link that I posted above. You need to use the D2XX driver and D2XX API though. On some FPGA boards, like the Mimas-A7 you don't even have to buy any extra hardware. At 12 Mbaud, I suggest using hardware flow control. This is actually a positive thing for most applications. With a 4-channel bridge you can do 4 channels of 12 Mbaud UART transfers, though this requires 16 IO pins to support individual channel hardware control. Don't expect that you can bond four channels of 12 Mbaud UARTs into one 48 Mbaud UART though. Also, for the record, you don't need to use any Ethernet packet types to transfer data to an FPGA target from a PC. Just abstract away the Ethernet protocol layer by using another FPGA board with a good USB 3.0 interface and an Ethernet PHY. I've done this using an XEM7320 and a SYZYGY ETH PHY to stream packets ( data plus preamble ) between a Genesys2 and a PC software application. This isn't completely full duplex as packets are streamed out of the PC through the USB interface directly to the target FPGA board and simultaneously storing the return packets into DDR, where it can be retrieved later. The trip across the Ethernet cable is full duplex, though the overall application is not. Of course, one can make Ethernet as complicated as one would like if "virtual" Ethernet doesn't float your boat ( or you need all of the software layers for some reason ). 1 channel of 1 GbE Ethernet is "really fast" unless you are transferring 14-bit ADC/DAC samples at full duplex at 100+ Samples/s. But you can easily send transfer 2 25 Ms/ DAC and 2 25 Ms/s ADC data both ways simultaneously through 1 1 GbE Ethernet PHY. I've done it, it isn't hypothetical. Where there's a need, there's often a solution. I also use 7-bit ascii to transfer 4-bit data vectors. This is a nice debugging tool as I can just a common serial program like Putty to read or write an arbitrary number of n-bit registers in my HDL application just by typing in a simple command. This Ip usually ends up in all of my new designs for debugging or profiling purposes.

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.

As I mention above, the problem with COM or TTY devices is that operating systems want to treat them as 7-bit asii. You can get around this by using 2 ascii characters to create one 8-bit byte. This halves your data rate. It's also terribly inefficient. You have to include logic in your FPGA to do this in your FPGA application. Nonetheless, if you can wait a while to upload image data, this might be your best course of action. [edit] And yes, I've used Python with pyserial to make the software part of this easier. It's possible to use FTDI devices with the D2XX driver instead of the default VCOM driver, but according to their documentation you must change the configuration EEPROM to use the D2XX driver. There's no switching back and forth in just software. With the D2XX, you have to write you own PC software application; but you can use binary data instead of ascii. I believe that the two project links that I posted above should provide good information about some other options.

Attila: "This lets you capture up to 256Mi samples @ 125MHz on 1, 2 or 4 channels. " To be clear, I believe that what you intend to say is that a user can capture 256 Mi samples of 1 channel, 128 Mi samples on each of 2 channels, or 64 Mi samples on each of 4 channels at 125 MHz in one shot mode. How many samples of 3 channels can be captured? And these are guaranteed to be contiguous samples?

You're at the mercy of Digilent Staff for support for their demo projects. Here's where you can find an alternate HDMI project for the Nexys Video: https://forum.digilent.com/topic/25315-using-ddr-as-a-video-frame-buffer/ If you want help with the one that you started with, I suggest creating a new post in the FPGA section of the Forums and specifically reference the project source. Sometimes, someone on staff at Digilent can provide answers to your questions, occasionally a user can provide assistance. I don't use Digilent demo projects.

What example project are you referring to?

Digilent has some good engineers on staff. I'm just not sure what exactly it is that they do. They never review published Digilent documentation like reference manuals or constraint files for errors. It took me over 2 years of prodding to get them to fix the Genesys2 reference manual and constraints file, which had the incorrect pin assignments for it's PMOD headers. Anyone could see that someone had just modified the Nexys Video documentation and done a very bad job of it; no one checks the work of farmed out labor. This just has never been a priority for them. Here are two versions of the same file published by Digilent that I found on my development PC. Eclypse-Z7-Master dated 2/12/2020 ## Pmod Header JA #set_property -dict { PACKAGE_PIN H17 IOSTANDARD LVCMOS33 } [get_ports { ja[0] }]; #IO_0 Sch=ja1_fpga #set_property -dict { PACKAGE_PIN H18 IOSTANDARD LVCMOS33 } [get_ports { ja[1] }]; #IO_25 Sch=ja2_fpga #set_property -dict { PACKAGE_PIN E16 IOSTANDARD LVCMOS33 } [get_ports { ja[2] }]; #IO_L1N_T0_AD0N Sch=ja3_fpga #set_property -dict { PACKAGE_PIN F16 IOSTANDARD LVCMOS33 } [get_ports { ja[3] }]; #IO_L1P_T0_AD0P Sch=ja4_fpga #set_property -dict { PACKAGE_PIN D17 IOSTANDARD LVCMOS33 } [get_ports { ja[4] }]; #IO_L2N_T0_AD8N Sch=ja7_fpga #set_property -dict { PACKAGE_PIN D16 IOSTANDARD LVCMOS33 } [get_ports { ja[5] }]; #IO_L2P_T0_AD8P Sch=ja8_fpga #set_property -dict { PACKAGE_PIN D15 IOSTANDARD LVCMOS33 } [get_ports { ja[6] }]; #IO_L3N_T0_DQS_AD1N Sch=ja9_fpga #set_property -dict { PACKAGE_PIN E15 IOSTANDARD LVCMOS33 } [get_ports { ja[7] }]; #IO_L3P_T0_DQS_AD1P Sch=ja10_fpga ## Pmod Header JB #set_property -dict { PACKAGE_PIN G16 IOSTANDARD LVCMOS33 } [get_ports { jb[0] }]; #IO_L4N_T0 Sch=jb1_fpga #set_property -dict { PACKAGE_PIN G15 IOSTANDARD LVCMOS33 } [get_ports { jb[1] }]; #IO_L4P_T0 Sch=jb2_fpga #set_property -dict { PACKAGE_PIN E18 IOSTANDARD LVCMOS33 } [get_ports { jb[2] }]; #IO_L5N_T0_AD9N Sch=jb3_fpga #set_property -dict { PACKAGE_PIN F18 IOSTANDARD LVCMOS33 } [get_ports { jb[3] }]; #IO_L5P_T0_AD9P Sch=jb4_fpga #set_property -dict { PACKAGE_PIN F17 IOSTANDARD LVCMOS33 } [get_ports { jb[4] }]; #IO_L6N_T0_VREF Sch=jb7_fpga #set_property -dict { PACKAGE_PIN G17 IOSTANDARD LVCMOS33 } [get_ports { jb[5] }]; #IO_L6P_T0 Sch=jb8_fpga #set_property -dict { PACKAGE_PIN B15 IOSTANDARD LVCMOS33 } [get_ports { jb[6] }]; #IO_L7N_T1_AD2N Sch=jb9_fpga #set_property -dict { PACKAGE_PIN C15 IOSTANDARD LVCMOS33 } [get_ports { jb[7] }]; #IO_L7P_T1_AD2P Sch=jb10_fpga Eclypse-Z7-Master dated 11/02/2023 ## Pmod Header JA #set_property -dict { PACKAGE_PIN B15 IOSTANDARD LVCMOS33 } [get_ports { ja[0] }]; #IO_0 Sch=ja1_fpga #set_property -dict { PACKAGE_PIN C15 IOSTANDARD LVCMOS33 } [get_ports { ja[1] }]; #IO_25 Sch=ja2_fpga #set_property -dict { PACKAGE_PIN D15 IOSTANDARD LVCMOS33 } [get_ports { ja[2] }]; #IO_L1N_T0_AD0N Sch=ja3_fpga #set_property -dict { PACKAGE_PIN E16 IOSTANDARD LVCMOS33 } [get_ports { ja[3] }]; #IO_L1P_T0_AD0P Sch=ja4_fpga #set_property -dict { PACKAGE_PIN E15 IOSTANDARD LVCMOS33 } [get_ports { ja[4] }]; #IO_L2N_T0_AD8N Sch=ja7_fpga #set_property -dict { PACKAGE_PIN F17 IOSTANDARD LVCMOS33 } [get_ports { ja[5] }]; #IO_L2P_T0_AD8P Sch=ja8_fpga #set_property -dict { PACKAGE_PIN F16 IOSTANDARD LVCMOS33 } [get_ports { ja[6] }]; #IO_L3N_T0_DQS_AD1N Sch=ja9_fpga #set_property -dict { PACKAGE_PIN G16 IOSTANDARD LVCMOS33 } [get_ports { ja[7] }]; #IO_L3P_T0_DQS_AD1P Sch=ja10_fpga ## Pmod Header JB #set_property -dict { PACKAGE_PIN G15 IOSTANDARD LVCMOS33 } [get_ports { jb[0] }]; #IO_L4N_T0 Sch=jb1_fpga #set_property -dict { PACKAGE_PIN D16 IOSTANDARD LVCMOS33 } [get_ports { jb[1] }]; #IO_L4P_T0 Sch=jb2_fpga #set_property -dict { PACKAGE_PIN D17 IOSTANDARD LVCMOS33 } [get_ports { jb[2] }]; #IO_L5N_T0_AD9N Sch=jb3_fpga #set_property -dict { PACKAGE_PIN E18 IOSTANDARD LVCMOS33 } [get_ports { jb[3] }]; #IO_L5P_T0_AD9P Sch=jb4_fpga #set_property -dict { PACKAGE_PIN F18 IOSTANDARD LVCMOS33 } [get_ports { jb[4] }]; #IO_L6N_T0_VREF Sch=jb7_fpga #set_property -dict { PACKAGE_PIN G17 IOSTANDARD LVCMOS33 } [get_ports { jb[5] }]; #IO_L6P_T0 Sch=jb8_fpga #set_property -dict { PACKAGE_PIN H18 IOSTANDARD LVCMOS33 } [get_ports { jb[6] }]; #IO_L7N_T1_AD2N Sch=jb9_fpga #set_property -dict { PACKAGE_PIN H17 IOSTANDARD LVCMOS33 } [get_ports { jb[7] }]; #IO_L7P_T1_AD2P Sch=jb10_fpga As far as I know, the only schematic with errors, other than commentary like pin function, is the NetFPGA-1G-CML which, thankfully, Digilent no longer sells. The same can't be said for reference manuals and constraints files, where I've come across lots of errors; and not just pin function comments, but actual pin assignment errors for a number of their boards. The company just doesn't have the kind of professional standards and processes that you'd expect from a vendor. It's certainly worrisome when even the schematics have errors, even when they are simply pin function and don't necessarily affect the design process. Just a reminder that the user is responsible for confirming that the information that they read from a vendor needs to be checked for errors. Do go by the official AMD/Xilinx documentation for pin function. Don't rely on master constraints files to be correct, especially if they're from Digilent. If you find errors in a schematic, then consider if you really want to waste your time with a product.

Usually, Vivado is able to figure out what the toplevel entity or module in a design is. When it can't, that's a sign of something wrong. You can always set any of your source files as toplevel manually. Be sure that the toplevel module port signal names are identical to those in your constraints file. The correct way to do the HDL design flow is to write a testbench for every module in your design. At least start out with a testbench for your toplevel design. Simulation should help identify problems. Writing code and trying it out on hardware to see if it works is a really bad way to do FPGA design.

When you have no idea how to resolve a problem, then perhaps it's time to read the instructions. In this case the 'instructions" are in the Series 7 reference manuals, where descriptions of how the FPGA resources are organized, how they work, and what limitations for their use might have an impact on your design flow. So read though the Clocking and Select IO users guides. You can find them in the Documentation Navigator that was installed with Vivado. All FPGA devices have some manner of clock regions due to limited resources. Intel Cyclone devices have more restrictive clock region rules, so boards using those devices tend to have more external clock sources to cover the whole device. Series 7 devices have a different clocking architecture, but still have limitations. Often one external clock is sufficient to implement simple designs. Digilent. in order to cut costs, has always provided the minimal number of external clocks possible, which is often unsuitable for more complicated designs. When you are using IO pins on every IO bank this complicates clock resource placements, like buffers. I suspect that the tool version has something to do with the placer error that you received; I frequently run into this using recent tool versions but don't remember do so with older tool versions. You can try following the suggestion of the tools and add the constraint to your design. You can also manually place logic and clock resources, such as buffers and MMCM/PPL blocks. Whatever approach you take, you will be responsible for making timing closure, if it's a problem.

The answer to you question should be " look at the schematic". But Digilent doesn't show the schematic page for its Series7 board JTAG/UART interface. The next best answer is to read the master constraints file. If there is a section for DPTI/DSPI then the board supports these ADEPT interfaces. If not, then no, the board doesnt' support these Adept interfaces. The Nexys Video and Genesys2 master constraints files have DPTI/DSPI signal and pin assignments. The Arty S7-25 doesn't. So, no your board doesn't support ADEPT DPIT or DSPI interfaces.

Xband: "You should play tennis if you enjoy watching others suffer. :)" I used to play tennis.. to the amusement of everyone but me... No, I don't like to see people suffer. I just wish that either Digilent would honestly advertise the Eclypse-Z7 or change the support to match the marketing claims. Since I don't like to suffer, I've just moved on to other platforms for using my Zmod ADC/DAC pods. Life's too short to struggle with unnecessary complexity and design short-comings. You are aware of the discrepancy between Digilent's support of the Eclypse-Z7 for customers and their own proprietary Waveforms implementation for the same platform, right? But even Digilent Engineers, as the slow roll-out for Waveforms support of this board demonstrates, can't do "rapid development" for it's own board.

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.

I've been following this thread out of... well I don't know why, perhaps for the same reason that people like going to horror movies. Seems to portray something other than a "platform for rapid development" as the advertising claims for the Eclypse-Z7.

The options for transmitting data between an application in an FPGA and a PC are limited mostly by the board design. For the BASYS3, this pretty much means a UART. More expensive platforms might provide a MicroSD card, Ethernet, or higher speed USB interface. There are cheap FPGA boards that aren't designed to be limited rather old and tired PMOD boards. I like the Terasic DE0 Nano and variants. You can add you own high speed interfaces to them. The Cyclone 10 LP dev board has a 1 GbE Ethernet and external memory. All of these are in the same general price range of the Basys3. A UART at 921600 baud provides roughly 92K characters/s data bandwidth. For an application requiring a lot of data transfer, this might mean pretty slow processing times. You can look at this tutorial for ideas on how to speed up a USB UART interface to 1.2 Mbaud: https://forum.digilent.com/topic/24531-debugging-with-the-ftxxxx-mini-modules/ . This involves buying additional hardware, but can be used with any of Digilent's FPGA boards. You don't need to implement the whole debug design, just understand how the HDL UART interface works and how to control it with a PC software application. The nice thing about this approach is that you can transfer binary data easily which requires fewer bytes than 7-bit ascii, which is what most PC serial UART applications want to use. Another possibility that can be used with any Xilinx FPGA is the JTAG BSCAN capability. This project is a good lesson in using that method: https://forum.digilent.com/topic/17096-busbridge3-high-speed-ftdifpga-interface/ Sometimes people think that they need a big FPGA device with lots of resources to prove a concept. For the most part, this isn't true. A small device might just require doing the same task differently, piecemeal, or slower. Or you can just process smaller datasets. You don't need to spend a lot of money demonstrating that a concept works; unless you are trying to demonstrate the fastest way to do something.. perhaps. Not having external memory to hold large datasets might be inconvenient, and certainly will limit how fast you might be able to process the data, image processing in particular. That doesn't mean that you can't prove a concept. It might mean demonstrating a logic application that is different than one that would be used in a real world application.

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.

RyanW: "The goal is eventually to develop a daughter board for the Kria" Take the complexity of the UltraScale family and add custom device variants with no detailed documentation ( Aka Kria ) and you are asking for problems, in my humble opinion. As I mentioned do take the time to do a careful read of UltraScale documentation, particularly IO. Unless you have an NDA with AMD providing information about their Kria devices that isn't public knowledge, barging ahead with a custom design for those SOMs seems rather risky to me. Near as I can tell the Kria concept is to provide cheap application specific hardware that isn't open source friendly. [edit] Before pinning your hopes on the video codec found on certain UltraScale ZYNQ devices, I'd advise researching actual support and use cases for this capability. In general there are a lot of not well advertised restrictions on such functionality in my experience.