zygot

The Adept tool only supports certain devices and packages. Fortunately, it uses a text based file that can be modified to support other device IDs. IMPACT and ChipScope don't work on modern Windows PCs (Win10 or newer) or 64-bit Linux distributions. I don't have an HS2 cable but my HS1 and HS3 work with ISE 14.7 on my Win7 box.

The MaxLinear devices are certainly interesting. Marvel makes 1/2.5/5/10 GbE PHYs that work over copper as well. Asmi, have you tried any of those? I looked into MaxLinear as they are available in distribution but haven't been able to contact anyone who will send me the required information. 2.5G Ethernet provides a nice data rate for FPGA/PC connectivity. Let me know if you make any of GPY212 designs. Populated boards would be preferred.

I'm betting that Questioner is chasing a ghost and that there's nothing to see here. Part of this is based on the scope picture and comments in the original post. What I see in the scope screen shot doesn't look like an output tied to GND through a 4.7 Kohm resistor going into a high-impedance state. What I see is a valid active signal tens of us after some quiescent state and even longer before it goes back to a quiescent state; no sigh of mis-behavior. The demo bitstream wouldn't be "managing to send packets, somehow" if the PHY or board was defective. From what I've read in the PHY datasheets, these devices don't strictly adhere to 'normal' logic level standards, especially when sensing pin states for power=on configuration of internal registers. I don't have any projects that use 10/100 link speeds, but all of my projects using the Genesys2 or Nexys Video boards with the RTL8211E-VL PHY are (eventually) rock-solid on all of them. Personally, I use an FPGA board that serves 1 GbE packets continuously, with <300ns inter-packet delay, as a testbed to verify that new FPGA projects using an Ethernet PHY on a different board has a robust PHY interface. The DUT just echos packets as received with a small delay so that there is full-duplex data transfer during most of the packet transfer. These test involve PHYs from Marvel, Realtek and TI and FPGA devices from multiple vendors, and generations spanning Spartan3 to UltraScale.. If one of them enters a low-power quiescent state when the test isn't running, I really don't care about that. The only time I've had to resort to using the MDI is for UltraScale platforms using Vivado IP due to the bizarre way that the IP works ( or when a board with a PHY comes up in an unusable state so that the I have to program it for desired operation). Every FPGA board with a 1 GbE PHY, regardless of FPGA vendor has a Tester and DUT bitstream to make settign up testing as easy as possible. If you can report seeing random failures during actual packet transmission, with pictures, then perhaps there's something to discuss.

I looked at the information that I have for the RTL8211 and don't see a power saving bit in any of the configuration registers. The device might power down if the cable is disconnected. Broken off plastic retention clips on the cable could do this. Make sure that ETH_PHYRESET_N isn't getting asserted. The RTL8211E supports Energy Efficient Ethernet. You might want to read about that. One way of interpreting your scope picture would be the PHY entering a low-power mode when there's nothing to transmit over the RGMII RX pins. Sounds plausible...

Fortunately for you, you don't need to sign an NDA to get documentation on how the Ethernet PHY on the Genesys2 or Nexys Video boards work. This wasn't the case with the ubiquitous Marvell PHYs that appears on other FPGA boards from almost all FPGA vendors. Download the datasheet. The first step in using a device is reading about how it operates. The Marvel PHY information can be gleaned from software driver code and a few other sources, but the Realtek documentation is freely available. [edit] CORRECTION! Evidently, ReadTek doesn't provide its datasheet freely either. I believe that I got the datasheet from another FPGA board vendor. Reading about the RTL8211E-VL PHY registers and power-on configuration might be informative. I'm not sure why you believe that "electrically, the pin behavior is incorrect". If after reading the datasheet and you haven't figured this out you still think that the PHY is mis-behaving, you could try asking Realtek support. You aren't driving the PHY outputs are you?

I have a couple of Genesys2 boards that I use for various projects using the onboard Ethernet PHY. I've had no issues with either one though my PHY IP needs to use IDELAY on receiver RGMII data pins using the default configuration. I don't use Vivado Ethernet IP or a soft processor for any my designs, just the default 1 GbE link speed and DDR primitives. I don't use a MAC, especially the encrypted MACs that are embedded in FPGA vendor IP. I also have no use for 10/100 link speeds, but that isn't exactly your problem. Since you are able to use your Genesys2 Ethernet PHY using someone else's bitstream, there's no point to anyone probing anything on a different board as you are telling me that your board is working... you just don;t know why. Your assumptions about how Ethernet works is a bit naive. 10, 100, and 1000 Mbsps Ethernet each use different modulation schemes. Clocking the RGMII interface at different frequencies isn't sufficient to using all of the link speeds. I never hurts to learn about the interfaces that you want to use in a design. You don't need to know all of the packet types and structures to use an Ethernet PHY on an ( non-ZYNQ ) FPGA board in order to do basic point-point communication between boards or even your Genesys2 to a PC. All of the relevant hardware layer, protocol and packet information is readily available on-line. You don't need to be an expert ( I'm certainly not ) but understanding basic concepts won't hurt either. FPGA vendors are all happy to provide an alternative, as long as you are dependent on their IP. I advise against that approach if you want to do anything useful with Etherent connectivity for a number of projects. I recently created an Ethernet Appliance using the XEM7320 and a SYZYGY Ethernet PHY pod that allows one to transfer data at 1 GbE data rates between an FPGA board and a PC using a USB 3.0 interface. No OS Ethernet processes involved. No soft-processors. No ZYNQ software development. No Soft-processor software development. No MACs. No Vivado Ethernet IP. I like to have full control of my FPGA projects and I hate doing unnecessary work. I've done similar projects using PCIe instead of USB PC connectivity. Because of the way that PCIe works on modern PCs, USB is a lot easier to work with and USB 3.0 is plenty fast enough if implemented correctly. Perhaps you know more about this than I do. In that case I can't help you. I'm not sure about this but what you are seeing on the scope could be associated with the power saving setting in the PHY. I've never had a reason to look at the receiver control signal on a scope. Regardless, I'm pretty sure that this has nothing to do with your design not working as you intend it to.

You don't provide any clues as to how you are doing 100 Mbsp link speed. What I can tell you from the information provided so far is that the PHY comes up on power-on configured to do 1000 Mbsp and will auto-negotiate with another PHY at that speed. My guess is that you need to modify some of the PHY registers using the serial interface in order to do 10/100 Mbsp link speeds. Certainly having access to the registers might help you debug your PHY interface. Tri-speed Ethernet IP from FPGA vendors use a clock switch to support the three link speeds as there is a difference in operation. Likely, the soft-processor project that you can run is using the MDI interface to configure the PHY. Potentially, the PHY status indicator LEDs on the Genesys2 might be helpful. No one needs to be constrained by obtuse and licensed FPGA vendor IP to use the Ethernet PHYs on Digilent FPGA boards.

I saw that you requested my help with this thread on a previous thread. I spent quite a bit of time composing a reply, but it never got posted and I lost all of what I composed. I've decided that I won't be making posts to the Digilent Forums if I have to enable scripting so I'm not sure what the future will bring. Anyway, I'm not going to recreate what I wrote, but will try to shorten it to the minimum. You can try and use the HW debug tools, such as ILA and VIO IP, to see what's going on in the PL. This would be part of a 'divide and conquer' strategy to separate SW from HW. Digilent engineers apparently don't do 'best practice' methodologies for code support of their products such as simulation, so you are on your own with that. I haven't bothered keeping up with Digilent support for the Eclypse-Z7 as it's not worth my time to hunt down all the information required to use it; so I can't help with Digilent IP sources. As long as I can post without limiting scripting in my browser I might be able to help with other aspects of helping you with your project. When creating a project that is heavily dependent on 3rd party sources and documentation you have to decide whether the support is good enough to use; otherwise you can waste a lot of time getting nowhere. Personally, I use a non-ZYNQ platform with Digilent ZMODs because development time is greatly reduced and less complicated. As I see it your problem is not being able to figure out a good debug strategy for your project. The ZYNQ platform is complicated in that both SW and HW needs to be working a some level before you can debug unexpected behavior. I agree with you that reading all zero data is unexpected. Before making assumptions, try and verify the HW and then work on the software.

You say that you use your own constraints, but at the top of the log file that you provide is this: BOARD=genesys2. Vivado project settings allow for specifying a specific device in a specific package, or using board files. If you use the first option, then you have total control, as well as responsibility, over constraints that don't involve Vivado IP. If you specify a board, then you are giving Vivado control and responsibility over aspects of your design. Trying to have it both ways can create problems. You appear to be using a project controlled by tcl scripts. This complicates your ability to control, or figure out what's going on when making changes. Personally, I try and avoid, to the extent possible, design flows and sources where tool versions can break a design. Unfortunately, the board file approach to specifying a target has gone down the path of abstraction and where both vendor supplied sources and tool version dependencies can cause problems. If letting Vivado manage your project works out then creating a bistream file is easy; if it doesn't work out, then finding the source of problems can be extremely difficult. If you are working with a complicated design that you don't control or understand, then you are at the mercy of the sources. When Vivado manages your project you are shielding yourself from information, that could be irrelevant or extremely useful. As a general rule, I find that whenever you see this message: "Synthesis finished with 0 errors, 0 critical warnings and 0 warnings." you should assume that the tools have been instructed to hide information from you. Even Vivado IP generated sources usually result a raft of warnings. It's easy to get rid of warning messages, which might mean getting rid of helpful information as well. I stopped using board files in my project settings as a convenience many versions of Vivado ago as it just causes more problems that are harder to resolve. If you are running into problems with DRC then the first thing to do is open the Implementation and sniff around and generate reports. You won't find a clue as to why constraints have been ignored, but you quickly identify timing and constraint related problems. The fact that you are supplying constraints that are being ignored and there are no warning messages from Synthesis or Implementation indicates that your project is set up in a way that is not telling you what is going on. This is a dangerous way to live. You are, unfortunately, a prisoner of your sources, which in this case are scripts. Live by the scripts, die by the scripts....

Very often what we think is the problem is really a symptom of a more complimented problem. Sometimes trying to figure out how a design source is supposed to work is instructive, perhaps even usable for the current project. Sometimes it's just quicker to write your own source. I find this to be true even when using my own IP from past projects. There are a lot of levels of complexity to figure out for even modestly complex designs. Experience is the best teacher when it comes to FPGA development.

Where did you come up with the pin assignments for your PMOD? You certainly didn't get them from the Genesys2 schematics. A problem with complex designs that use tcl to setup a project and create a design is that they often setup the tools in a way that restricts warning messages; if they aren't produced than you can't use them to figure out the source of errors in the last bitgen process. Running tcl scripts to do all of the hard work is great... when there aren't any problems, but created more work when problems are introduced. Modifying the design without modifying the source tcl scripts might create problems.

Good news for Intel FPGA users! Intel has announced their intention of spinning off the Altera business. This is likely a step forward for programmable logic developers if it means more commodity product like MAX10 will get into distribution channels. Time will tell.

Before you can figure out how to resolve bitgen constraint errors. you need to make sure that your constraints are even being used. You need to check synthesis warnings to determine this. Constraints could be ignored if: - your constraint name does not match the toplevel entity ( module ) port name exactly - your version of Vivado uses different syntax than you are using I avoid using board files as they are now version (vendor and tool) dependent and hard to debug, also I usually find extraneous constraints that I need to manually correct; better to maintain your own user constraints files. User constraints should over-ride any constraints created by Vivado, and you should see a warning from synthesis.. as long as they aren't rejected for some reason, such as listed above. Unfortunately, it pays to scan though all synthesis and implementation warnings and errors regardless of whether or not DRC passes. When DRC fails, you need to read tool messages.

Well, you probably want to start with using a device that's supported by your FPGA vendor. Spartan 6 and ISE are not. I'm not sure what your product is supposed to consist of. Surely, you don't intend to use PMODs or third party hardware.

You might want to re-think that premise. You need to use a newer of the AMD/Xilinx tools if you want to use a particular device that isn't supported by earlier versions. In general newer versions of tools require modification to project sources developed on earlier versions. It might be IP that's changed, IP that's been depreciated, a change in constraint syntax, etc. It depends on what devices you use. Personally, I find that I need those older host boxes, with older OS versions, and older tool versions to keep what little sanity I have left. I have never detected any advantage that a newer tool provides for projects targetting older devices on older FPGA platforms, in terms of timing closure, better performance, more efficient use of resources etc. My new box has an i7-13700K with those performance and efficiency cores architecture. I'm not sure that my kernel even supports that architecture all that well. I doubt that this is the issue. If you can't figure out what the problem is by looking at the OS or kernel version, then what's left is the CPU/Motherboard/Chipset/BIOS. If there was PCIe involved, then I could see BIOS setting tweaks that need to be performed. For USB related functionality, I don't know of any reason why this would matter. Still, you are having issues that I don't seem to have.

Think of verification as more of an iterative process than a once and done task. Verification involves working out design and implementation deficiencies on a number of levels. The most basic level is this: "does your design, as expressed in your HDL code, behave as expected?" Simulation is a quick way to find syntax and silly errors, like mismatched std_logic_vector assignments or type incompatibilities. The first iteration of the design phase testbench usually is a rudimentary view of what you want your design to do, how external hardware behaves, and all of the possible conditions that the design needs to account for. Once in a while, for trivial designs, this is sufficient. For more complicated designs, this is usually just the beginning of the journey. Once you are confident about how well your initial testbench covers all possible scenarios you implement it in hardware. At this point you are assigning timing constraints to IO and getting feedback from the tools in the form of timing reports. Once you've resolved timing issues with your implemented design, it's time to try out your design on physical hardware. More often than not, this is where you discover deficiencies in both your initial design and testbench as well in how you understood the problem. Did you understand the problem to be solved? Does your design theory actually solve the problem and address all operational scenarios? When your behavioral design in simulation and implemented design in hardware are in disagreement, then it's time to re-think the premises that led to your initial design approach. OK, that was a lot of preparatory verbiage that lets me address your question. Sometimes, an ILA or in the case of Quartus SignalTap let's you see what's going on in your implemented design in order to gain insight about where you went wrong. It could be design deficiencies or testbench deficiencies. For complicated designs, especially when they connect to software controlled external hardware, it's usually both. The ILA can be very effective, if you want to capture a cycle-by-cycle snapshot of a few signals following an event in your design. Sometimes the ILA is deficient because capturing a few thousand signal state samples isn't going to provide the answer that you need, or setting up and controlling an ILA to capture the event that exhibits a behavioral failure is too complicated. This is where you need to develop your own hardware debugging tools. Personally, I like to use a couple of spare IO pin and external USB UART cables or breakout boards to aid hardware debugging. On the most basic level you can read/write registers in your HDL on real hardware. it's an easy way to verify states after events, setup events and operation of your design as well as profile performance. For some designs that have lots of clock domains and FIFO storage performance measurement might lead to errors in your design theory. Having the UART debug option ( one that is independent of the UART/JTAG circuitry on Digilent boards, is also a path to finding where the design fails that might be really complicated to do in simulation ( until you know where to look ). I've written a LOT of custom UART based debug tools in HDL to help with this. Each one has a different approach to capturing periodic or "random" failure events and their use depends on the design. As an example, I've recently completed an FPGA Ethernet based appliance that can transfer large amounts of data between a Host software application and a target FPGA design on a different board. The design uses DDR and a lot of elastic storage. Data transfers can take several seconds to complete. I'm not going to simulate a whole transfer in this case. An ILA might not provide the capability to capture the event where the design fails in hardware. So this is where some custom approaches work. It's not too hard to create an entity that look for bit changes in a std_logic_vector and records them in a FIFO that I can read after a long transfer via a UART. The std_logic_vector might be a register in the design, but more likely it's a concatenated number of std_logic signals that are related to an element of the design so that I can see relationships between processes. If the Debug FIFO captures timestamped bit changes this can help find where the design is failing. Obviously, I have a limited number of events that can be captured, but those events can happen over seconds of operating time. That's one example. All simulation approaches have the same goal; exercising your design in a way that exposes deficiencies or misunderstanding of the problem that the design is supposed to solve. Getting to that goal is very design dependent. An example is a design that uses a MIG DDR interface. Not only is this temperature dependent but initial calibration takes ages, in simulation time, to get past. There are ways to short-circuit the calibration phase, even then the time-step requirements for simulating the high speed PHY signals really start to overwhelm the ability of simulators, especially ISIM, to simulate the overall design behavior. As far as closed-loop simulation, that is connecting two UARTs together, this is just a convenience that suits one simulation exercise. It might not really be closed-loop, as the second UART just confirms that, as connected in your testbench, what one UART sends can be received by a second copy. However, if you develop your own UART based debug IP, you can see how a UART can control your design and behave in simulation just as it should in hardware. That's the level where a loop gets closed. The more tools that you have in your toolbox, the better you get at cracking difficult hardware debugging problems. Simulation, unfortunately involves writing HDL code. Fortunately, it usually involves HDL code that can't be synthesized; so you can take advantage of your HDLs full capabilities. It's a skill and art form in itself. Testbench code and read and write files on the host HD. It can be controlled by TCL, OCTAVE or Python scripts. You can't create a standard ToDO list for writing effective testbench code. You can only debug yourself; that is train yourself to anticipate testbench approaches to effectively reduce the amount of hardware debug time.

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

I'm not sure what documents you are looking at, but the schematic covers all of the signals that connect the FPGA to the FMC connector on the Genesys2. The master constraints file covers all of the non-transceiver pin location and IOSTANDARD assignments. The Genesys2 has an HPC FMC connector. You are saying that you want to use the FMC transceiver signals. For the Genesys2, these are connected to MGT banks. Vivado transceiver IP tends to define MGT pins by MGT quad (bank) rather than pin locations. I imagine that this is why the master constraints file doesn't mention these. Also, there are no other constraints that can be applied to these pins, unlike normal IO bank pin. MGT banks on the Genesys2 are 115 through 118 as shown in the schematics. MGT resources, including clocking, are separate from CLB clocking and resources in Series 7 devices. Occasionally, as is the case of PCIe functionality and transceiver assignments you may have to over-ride Vivado assignments because, oddly, the PCIe cores don't let you do it when defining the core. This is the case of the NetFPGA-1G-CML board. I'm a bit mystified as to why you would consult a different document for the LPC FMC connector to figure this out. Also, the Genesy2 doesn't have any SMA connectors. The KC705 is a K325T board with SMA connectors.

Unfortunately, Vivado/Vitis installers do not attempt to check for installed dependencies. You discover missing dependencies by having installed applications misbehave. I wish that I could tell you that this isn't a common theme with random Linux distributions using any particular desktop, an a random state trying to install new applications. Again, I'm afraid that the question is: "do you want to be at the mercy of a not-very-benevolent overlord who has complete control over an OS ( or whatever Win11 is ) or loosely constrained group of open-sourced maintainers. For an OS like Win10 that is up to date installers don't need to know what's been installed previously; dependency isn't a huge issue, other than 3rd party drivers. This just isn't the case for any particular Linux OS system. I don't have Vivado 2023.x so I can't recreate your experience. It certainly seems like a bug, or change, in Vivado 2023. All I can do is confirm that Vivado 2022.2 works on my Ubuntu 22.04 box. You could try installing Vivado/Vitis 2022.2 and try to resolve kernel related issues if any. If you don't need to do debugging in Vivado Hardware Manager using ILA or VIO components then configuration using the Adept Utilities might be an option. One option is to create a user account with AMD/Xilinx and pose your issues to them. Good luck with that. I'm sad that I don't have better advice to offer.

If you want to use XADC to read the FPGA device substrate temperature, or internal voltages this project may help: https://forum.digilent.com/applications/core/interface/file/attachment.php?id=20979&key=ecf05ae9f2efc17f938585b22eea9a0d I've used this board for a few projects using the PCIe, DDR and Ethernet PHYs, and strongly suggest adding a heat sink with a fan. If you want to manage temperature, then this is almost a requirement. A passive heatsink with no forced air flow is isn't a lot better than nothing... Monitoring substrate temperature is a good idea for all Series 7 project, especially if a heat sink and fan aren't present.

I've been using Vivado 2022.2 on an i7-13700K box, Ubuntu 22.04.3, Kernel 6.2.0-26-generic with a number of AMD/XIlinx FPGA boards. Don't forget to give yourself dialout privileges: sudo adduser $username dialout. I don't use the Vivado board files to target devices for a number of reasons. Recent versions of Vivado have been exhibiting odd behaviors on both Windows and Linux hosts for me. When you say that Vivado 2023 can't connect to your board, what exactly, is the behavior? Have you tried the "Open a New Target" option? It's unfortunate that Vivado has depreciated the JTAG debug option that was available in older versions. [edit] Always read the release notes when installing Vivado or Vitis as there are usually some references to dependencies for Linux hosts. It's unfortunate, but there is no standard Linux distribution on hosts due to the lack of standards in creating distributions, desktop GUI options, etc. Still, now that Microsoft no longer is in the OS business ( I don't consider Win11 to be a real OS ), there are no real alternatives. I'm too embarrassed to mention how much time it took to make Ubuntu with MATE desktop usable with my HD monitor... All in all it's pretty amazing how close the VIvado user experience is on both Windows and Linux hosts.

I suspect that there are newer and better GNSS receiver chips available these days. The MAX2769 seems to be in the DSP era, so a ZYNQ replacement shouldn't be too hard of a project. I'm reading the thread as possibly something different... don't know yet.

You mention the MAX2769 receiver chip and the HMC833 PLL. It isn't clear to me what exactly your project goals are. Are you trying to use you own custom RF to IF circuit to produce digital signals that you will then process in an FPGA? Or, are you trying to use the MAX2769 and use the ZYNQ to process its output?

I want some indication that you are human; the question is that odd for this forum. On your todo list might be to start with reading many of the AMD/XIlinx documentation available in the Document Navigator that was installed with Vivado. These include the Series7 User manuals, Select IO, Clocking, CLB as a start, as well as User Guides and tutorials for Vivado. Pay close attention to the HDL design flow discussions. Understanding Verilog or VHDL concepts is not the same as understanding how to use them as a design description methodology for use by FPGA vendor tools. Trying to learn both without coursework or at least a good textbook is challenging. Perhaps the best way to answer you question is for you to post your Verilog code and Vivado's warning/error message. That way we can discuss specifics instead of generalities. VHDL and Verilog were designed for simulation, not synthesis. Both are event driven. Posedge in Verilog or rising_edge in VHDL are events. Events are not necessarily clocks. For modern FPGA devices and tools clocks are treated as a unique signal with its own resources and routing fabric. Don't be embarrassed by asking questions. Everyone starts at the same level. Even seasoned FPGA developers learn new things and gain new insights as they go.

You don't mention what version of Vivado you are using. The implementation of the CMOD UART/JTAG interface is not the same as for the other boards. Moreover, the CMOD is unique in terms of size and PCB stack-up. I do believe that the behavior of Vivado hardware manager ( with respect to JTAG activity ) has changed in recent years. I've seen evidence of this using even more robust designs like the Nexys Video. I use Vivado 2019.1 through 2023 on both Windows and Linux hosts consistently using a variety of FPGA boards from vairous vendors. It shouldn't be too hard for you to investigate you hypothesis and get a better answer than you are likely to obtain here. I never use any version of Vivado Hardware Manager with any of my ( original version ) CMOD-A735T boards.