zygot

Oh, I didn't think about a mis-wired JTAG adapter... yeah, that'll do it. If you can't initialize the JTAG chain, then there's no use in trying to configure a device. Glad that the issue is resolved. Modern OSes can't run a number of ISE functionality, like IMPACT, but the abil;ity to create a bitsream from sources does seem to work. I do this with my Win10 box. Haven't tried to do this with Ubuntu. I do remember that the AMD/Xiliinx archived version of ISE didn't support all of the device families that I need when I tried it a few years back,so I used the DVD installer. Basically, ADEPT Utilities needs ID codes for all supported devices. In the Windows version of ADEPT Utilities, there is a text file jtscdvclist.txt file that holds all of the supported device codes. This is can be modified to add boards with unsupported devices. I've done this a few times. If the Linux version of the Utilities has this file I haven't found it; so Linux users might be stuck with the release device support. I haven't tried doing Spartan 3 development on a Linux OS.

My you are an adventurous person considering the differences between 32-bit ISE 14.7 and Ubuntu 22.04 Linux kernels. I'd start with getting answers to these questions: - Is the JtagHS3 compatible with Spartan 3E device JTAG signalling? - Does the Adept utilities support the 3SE500 device? I can confirm that the ADEPT Utilities for Linux work on Ubuntu 22.04, though I'm using an older HSx cable. ..$ sudo dadutil enum Found 1 device(s) Device: DCabUsb Device Transport Type: 00010001 (USB) Product Name: DCabUsb1 V2.0 User Name: DCabUsb Serial Number: 50003C040864 ..$ sudo djtgcfg init -d DCabUsb Initializing scan chain... Found Device ID: 0362c093 Found 1 device(s): Device 0: XC7A50T I suspect that the problem is that the utilities don't support your specific device. I know how to fix this on Windows, but haven't tried to find the proper file on Linux.

Perhaps I'm reading too much into your use of the words "failure", "resetting", "proves", "valid Ethernet connection", etc.. - Don't assume that all Ethernet PHYs behave the same. - Clocks can assume a quiescent state for a variety of reasons. That doesn't necessarily imply a reset or failure of some kind. Sclk in an SPI interface is and example of a clock that is only active during periods of data transmission. In Series7 FPGA devices internal clock signal can be driven with a clock buffer having an enable in order to put sections of logic into a quiescent state and save power dissipation. - the behavior of the PHY on your board might change depending on what kind of PHY it's connected to. - All PHY interfaces provide transmit and receiver error signals, though none are as simple to extract as the GMII interface. - The method that you chose to detect an absence of the PHY CLKOUT signal might be sufficient. Don't be too anxious to declare victory and move on. You might want to devise a second, more complex logic design to detect an absence of CLKOUT transitions. It wouldn't hurt to read the datasheet for the PHYs that you are working with. Not all Ethernet PHY vendors provide this documentation without an NDA. But one can get insight by reading OS driver code or other available information. All in all this is a good exercise and potential learning experience.

Even though the Ethernet PHY is connected to the MIO pins, and not PL pins, these boards to connect the PHY CLKOUT pin to a PL pin. Some Ethernet PHYs do have energy conservation designs that shutdown portions of the PHY when there is no activity on the receiver. Depending one the PHY, This behavior might be altered by changing certain registers in the PHY using the serial interface. So, can one detect a condition where the PHY CLKOUT signal is not toggling using PL resources on one of these boards? I can't think of a reason why not. The solution just might be a bit more complicated than you envision. There are ways to use a ZYNQ based FPGA board without any PS connectivity so that you can implement a logic design. One could make the case that having a minimal connection to the PS might be useful; for getting additional clocks into the PL for instance.

Well there are FMC mezzanine cards with mixed-signal (ADC/DAC) interfaces that provide for connecting a system reference clock via an suitable connector. These tend to be very expensive. So the Nexys Video or Genesy2 boards might be a suitable platform. Not providing the possibility of using an external reference clock is a major design flaw for any platform that claims to be a mixed-signal platform in my opinion. I don't believe that Digilent's SYZYGY carrier boards were designed wit customer needs in mind. Before Digilent came out with the Eclypse-Z7 and ZMODs Intel based boards with an HMSC connector were the only viable FPGA platforms around for doing mixed-signal applications at a price point for hobbyists. Terasic sells suitable hardware, though the cost of Cyclone V or Cyclone IV boards have become pretty burdensome ( twice what they were when introduced ) What you have to look out for when considering selecting hardware is the details. For instance Terasic's DCC has 2 ADC and DAC channels that exceed any of the ZMOD Fs and an SMA connector that accepts and external reference clock. What's less obvious is that the ADCs and DACs are connected through wide-band transformers, so you lose DC and low frequency response. The nice thing about the so called ZMODs is that they were designed for Digilent's transition into an instrument company. So, they provide really nice flexibility for most general purpose ADC/DAC applications. If I have my way all FPGA development boards would have at least on SMA clock_in and one DMA clock_out. Rarely, do I get my way...

All FPGA devices have clocking regions, and limitation for clocking infrastructure. Intel devices historically are more restrictive than AMD/Xilinx devices with regard to clocking options. That's why, most of the Altera/Intel development boards supply clocks to more than one region. Often they use one external clock module and a clock buffer with more than one output. Digilent FPGA boards are designed to be cheap... so they generally only have one external clock source. The problem with DDR is that signals require a Vccio that's well below what general purtpose IO signal need to be. It would be nice if they had provided separate clock for the DDR IO banks. This would make the boards a bit more expensive. Is the a design shortcoming? One could make an argument against a lot of design decisions that were made for Digilent FPGA boards, where a bit of extra cost would make the board substantially more useful. That's for another discussion My sense ( at least I don't remember running into this issue with in designs with older tool versions ) is that ISE and early versions of Vivado did not treat "sub-optimal clock module placement" as worthy of a bitgen error. But recent versions of Vivado do, so the only way to fix the board design limitations is by using the suggested constraint. Sub-optimal situations don't mean that you can't produce useful FPGA applications. Designing an FPGA board that is optimized for one specific purpose allow one the possibility of optimal performance. Designing a general purpose FPGA board, especially one that's cheap, and designed to work with PMOD add-on boards, pretty much dispenses with the notion of optimal performance. [edit] I realize that I could have provided a better answer to your question. If you really want to know how clocking works in Series7 devices then you should read UG472 the Series7 Clocking Resources User Guide. If there are any idiosyncrasies for Spartan 7 devices, this should be covered in the device datasheet. This guide informs you about clocking regions, clocking buffers, clock trees etc, plus the rules for using a clock across regions. Yu can also learn about the CMT backbone. It's somewhat complex and involve the clock-capable input pin assignments that board designers select. I will note that the user experience for Vivado IP that uses an AXI bus may be quite different than someone using the same IP with a native interface. Also user experience with Vivado managed design flow like IPI might be different than that for the HDL designer. When you instantiate an MMCM or PLL in your design and you can drive the input clock with an MRCC pin or SRCC pin or a clock buffer. Using a pin restricts the MMCM location placement. If you use one of the limited a global clock buffers and instantiate a specific buffer explicitly ( rather than relying on the tool to infer one ) then you might be able to end up with a better MMCM location placement. Generally, Digilent FPGA boards use the Multi-Region Clock Capable (MRCC) pin for external clock modules and oscillators on their designs. Even then there might be restrictions, as documented in the AMD/Xilinx user Clocking and Select IO User Guides that might determine you design choices. Generally, using the CLOCK_DEDICATED_ROUTE BACKBONE constraint will not be a problem in how the bitstream works on hardware.

One would think that a valid MIG .prj file for a particular platform, like the Genesys2, would be a suitable source file. The MIG Wizard let's your try and import one. The problem is that I've never had success doing this. Part of the problem is that constraint syntax keep changing with occasional Vivado releases. In fact I've had Vivado add constraints to my user managed constraints file that it then decides to ignore because of syntax errors. Unfortunately the MIG hasn't gotten much love over the years. No updates to the IP wizard. Same old bugs in every new Vivado version plus a few new ones. One way to handle Vivado bugs is to manually keep track of Ip settings. This is what I did for the Genesys2 Video demo. Whenever I want to add DDR to new project I just create a new project and replicate the setting. If you read the commentary in my video demo sources you can find all of the relevant settings that I used to create Vivado IP. Another, probably more appropriate, way to to use the MIG is to create a tcl script to create your MIG IP for a board. Neither of these are totally foolproof s there are bugs that are consistent through all of the Vivado versions; like trying to edit a MIG project file using the wzard and having the GUI change settings from what you initially made back to default settings. It's all a pain in the ars and the Vivado coder have no interest in fixing it. another problem unique to the MIG IP is that you could never modify the IP; you can only create a new set of IP product files. In my experience Vivado gets 'confused with having multiple MIG .prj files and generated IP products. Digilent usually supplies a ucf file for the MIG in setting up the location assignments. Often these have to be modified due to changes in a tool version. For the video demos I had to create a modified ucf file, which I included in the demo sources. n my opinion Vivado is trying to depreciate the HDL design flow and force users to use the IPI GUI and high resource IP that come with it. Also, managing source files has gotten harder, though it's not as bad as it is for Intel Quartus users. In ISE and early versions of Vivado one could open a generated IP and change the name and produce a variation of it. No more. As the years go by I find using Vivado less and less friendly to work with.

I strongly urge you to go to Opal Kelly's website and download the specifications for SYZYGY and SYZYGY DNA. This explains how to design SYZYGY compliant carrier boards and pods. They even have some (old) KiCAD templates. While the SYZYGY standard provides rules for how to design compliant boards, there is considerable room for making design choices that might limit what you can do with the interface. This is particularly true for carrier board voltage supplies, FPGA pin assignments etc. This is why you need to understand the specifications before doing the analysis of any particular SYGYGY carrier board to see it meets your requirements. With respect to differential signalling, SYZYGY pins 5-20 can be either single-ended or differential; i.e. pins 5:7 being the _p/_n pair for differential signal D0, or they could be two single-ended signals. Those are the logic signals available for differential signalling. In the FPGA world clocks are different than logic signals and have their own infrastructure. The SYZYGY specification supports 2 differential clock signals. Pins 33:35 are for a clock generated on the pod and being received by the carrier board. Pins 34:36 are for a clock driven by the FPGA on the carrier board and being received on the pod. Again, clocking can be single-ended but for Series7 FPGA devices not every IO pin can connect to the clocking infrastructure of the FPGA. Any of the pin pairs 5-20 could be used as clock signals that are generated on the carrier board. Any standard has to have some flexibility as there are a lot of possible applications that can be accommodated by a standard. For FPGA designs, the FPGA devices have their own rules, limitations, and quirks to understand and deal with. Do read the DNA specification to understand what the uC and EEPROM do and how they can be utilized. This is particularly important for the carrier board which generally supplies power voltages and in most importantly Vccio IO bank voltages necessary to implement a specific IOSTANDARD. Even still, there is considerable room for customization regarding DNA negotiation and accessing EEPROM data. Digilent designed boards are unique with thier implementation for the Eclypse-Z7. The USB104 is not a Digilent designed board. With respect to how you design a power supply on a system level, I'll just say that picking a carrier board and trying to adapt that to your needs is not likely to be a satisfactory path. Unfortunately, there are not a lot of SYZYGY carrier boards to choose from. If you stick to powering your pods separately, except for the Vccio rails, you have a good chance of getting to where you want to be. If you intend to use the USB power supply to power the USB104 as well as your pod, then you are in for a rough ride. Older USB 2.0 only allows for 500 mA @5V. Type C USB allows for the ability of a USB host to supply much more power to a USB downstream device, though there's no guarantee that any particular device supports this by design. USB is a whole other thing to know about.

Recently Digilent sent me an email about this new product. It so happens that ADI has a product with the same designation. Does anyone think of checking these kinds of things in advance? Given that Digilent has clearly gotten out of the FPGA development board business and will never encroach on the much higher priced products of its parent company, perhaps you should drop the "Pro" verbiage which is only confusing to the uninformed..

There have been -1L Arty boards with lower performance than -1 parts, so knowing the speed grade might be important. You should go by what Digilent claims. Still it would be nice if all device markings indicated the speed and temperature grade in an obvious manner. I've run into ICs where the only indication of what the part is consists of a code that you need to find a document to decipher.

I suppose that anything's possible; but it seems highly improbable that Vivado IP would create an instance where there are more channels than it is capable of creating. Without reading the IP documentation or doing simulation you have a challenging task in figuring out what's going wrong. Trying to debug something that you don't understand, and don't even have access to IP documentation, which can be sketchy at best, is tough. My guess is that you aren't seeing any, much less 10 channels with complete data frames. As the amount of data increases per frame it's reasonable to suspect timing and clocking as a source of your problems. Have you worked you way through the IP source code? My suggestion is to create your own IP using the HDL flow and abandon the VIvado IP if you can't read the documentation or do a proper simulation.

Well out of curiosity I tried to find the IP documentation that you are using. Without actually signing into my AMD account I was totally unsuccessful. Finding documentation for AMD/Xilinx products has definitely gotten harder recently, especially on a Linux host, unless you sign into your account. Using FPGA vendor IP is not as simple as configuring it in the IP wizard. That's why you need to read the documentation. While IP may support a wide range of configuration settings that doesn't mean that there aren't restrictions among all of the possibilities. Just because you had success with 6 channels doesn't mean that changing the number of channels from 6 to 8 automatically works without some modification. I've never used this IP so I have not experience with it. The first thing for you to do is read all of the synthesis and implementation warnings to see if there are clues to what's changed in your modified design Usually, Xilinx IP comes with a simulation testbench. Simulation is the key to all FPGA design flows. AXI based simulation is generally messier and more complicated than regular HDL simulation, especially for a ZYNQ target. If you can't figure out how to debug your design then this is a problem. FPGA vendor IP usually is very hard to unwind so that you can understand how it works. It you can't do an effective simulation of your design, then you need to be clever about figuring other ways of debugging what the tools are giving you. .

Gee, as someone who generally thinks that there are no stupid questions, yours should be close to being in that category... but it isn't. The answer ( but probably not ) is in UG475 where AMD Series7 packages are described. In the device marking section there's a long description of what you might encounter ( or not encounter ) while looking at the IC markings. There's no guarantee that there's any text telling you what speed grade a particular part is. There's probably a 2D bar code and like many AMD documents, instead of including the answer where you'd expect to see it, you get a reference to yet another document to find and read. This is typical of FPGA documentation. I can save you the trouble though as the cost of -2 or -3 speed grade parts makes it extremely unlikely that Digilent would use the more expensive device just to complete a production run without charging a premium for the finished product. The Genesys2 is the only Digilent board that I know of with a speed grade part faster than -1..

Have you read the IP documentation?

The inappropriately named differential PMODs found on Digilent's FPGA boards match n/p pair lengths for each IO bank pin pair. Digilent does not match pin lengths across all pin pairs ( i.e all 8 signals ). Furthermore, the matching only extends to the connector through-hole pads. The right-angled connector used on all PMODs is unsuitable for most differential applications. If you need the best common-mode performance, then none of these PMODs are suitable. Also, since none of the PMODs have signals connected to IO banks with a Vccio that isn't 3.3V, TMDS_33 is the only possible differential standard. Lastly, placement of termination resistors can never be ideal. If you need matched n/p pair lengths for an application where the FPGA pins are receivers you can always use IDELAY to compensate for mismatches, up to about a ns or so. In theory one could use a right-angle connector on an attached board that is in the opposite orientation to cancel out the connector length mismatch, but you still have to deal with the connector unsuitability for differential signalling. There might some low frequency applications where these PMODs might be OK. like RS-422. It would have been nice if Digilent actually put usable differential IO connectors on their boards that were connected to IO banks powered by a suitable Vccio; but they have refused to do so. I suspect that's because none of their PMOD accessory products use differential signalling or high speed signalling and the purpose of the PMODs is to sell PMOD products, not to make their boards suitable for custom user projects.