zygot

ESD is the most common way to abuse electronic devices, other than possibly trying to drive a pin that's shorted to ground or some voltage source. Either way, it's unlikely that only one pin has been affected. That doesn't mean that your board is unusable... just that you will not have certainty that your designs will work the way that they might on a healthy board. Another way to abuse an FPGA board is to connect an FMC mezzanine card to a carrier and try to use it without first mechanically securing the boards together, or worse yet trying to plug/unplug the mezzanine card while the carrier is powered.

Artix devices of any speed grade are more than capable of running your version of I2C at 1 MHz and above data rates. Digilent rates their standard PMOD interfaces at 10 MHz, though this might be conservative for some applications. I don't see any issues that can't be addressed. There's more to a standard, like I2C, than modes and data rates if you want to claim compatibility. As for licensing the name; that's not something I would dare comment on.

The pins on the FMC connectors can get bent, but I assume that you've already done an inspection on both the carrier and mezzanine boards for connector mechanical issues. I've used that pin on my board which is a Rev A version, so this isn't something that I've seen. Digilent isn't very good at providing explicit board revision change notices so I don't know what's different about REV A.0; but I'm assuming that is due to a component change due to availability. It's possible that there is a fault on your particular board, though I assume that Digilent has every board checked for connectivity. It's possible, but unlikely, that a gouge or mechanical stress has broken a PCB trace. It's possible something conductive has gotten under the FMC connector and is causing a short. It's also possible that the FPGA has had that particular IO abused and can't source or sink current. Those are things that spring to mind that I've come across testing out custom boards that I've designed and built. That's all I have at the moment.

I've used the Nexys Video LPC FMC connector for quite a number of projects using a few different mezzanine boards without issues. I've always taken the time to trace through pin connectivity. While Digilent has certainly messed up the master constraints and documentation for a number of its boards the schematic ( except for the NetFPGA-1G-CML board ) has always been reliable, in my experience. Generally, schematics are from the PCB layout tools so it would hard to make mistakes. Which pins are concerning you and why do you believe that the boards are different than the schematic ( assuming that the schematic rev level matches your hardware )?

DSP48E isn't a complete specifier as there have been a lot of variations among the various families over the years that have seen significant changes to the operation and performance of the hard core. But, if absolute maximum performance isn't a criteria and you have a netlist for the device you are targeting you are correct.

I2C is a proprietary interface and who knows who owns that IP now. There are of course tons of variations and implementations of the basic idea under various names ( to avoid a legal problems ) that do roughly the same thing same thing at various data rates not supported by the original specifications. The same applies to SPI. Both have ancient origins implemented with pre-FPGA technology but have have since been adopted, in one form or another, due to prevalence of the interfaces. I don't know if there even is an official specification for SPI. The simple answer to your question is that yes you can implement a design in an Artix based board that can communicate with any of the "I2C", twin-wire, or similar interfaces that are available in any of the myriad of IC devices currently being sold. At a maximum 400 KHz data rate you can certainly use any of the Diligent Artix boards and standard PMOD as a protoype platform. The larger question for someone developing an ASIC is defining exactly what its "I2C" interface is relative to all of the variations out there.

Well, that's the trick, isn't it; identifying the platform and tools that support the requirements of a particular project goal. One problem with being dependent on a MATLAB design flow is that you are dependent on their support for any platform that you choose. ( MATLAB/FPGA tool integration may well have improved since the days when I used it. ) If I were you I'd avoid restricting my platform choice criteria to one FPGA vendor. Intel has been in the MATLAB design game longer than Xilinx and better support for OpenCL and such adventures. They also have the devices, if you have a thick wallet, and platforms that are similar to the Versal family. Intel wants to squeeze more money from its customers than Xilinx has traditionally, but in the end the investment in cost and effort probably isn't all that different than for a Xilinx based effort if you are targeting high-end FPGA devices and platforms. You aren't going to avoid paying for tools with a Versal project either. There's a lot of homework to do, and it's likely more complicated for someone used to the convenience of using MATLAB for FPGA development. Simplicity and convenience cost a lot of money... and often end up not getting you across the finish line due to limitations of what can be supported by such a framework. If someone has a limited budget then they probably will have to scale their project goals to fit what is affordable. This is, of course, adds complications, and diminishes convenience and simplicity. It's always possible to implement enough of a concept to demonstrate ( not prove ) that you have a path to a larger goal. For someone who wants to get on with developing an idea without having to get mired in the details, I'd advise sticking with known platforms supported by MATLAB and used by other researchers in a particular field. This isn't likely to be the place to get such information, though perhaps you'll get lucky.

What FMC mezzanine Ethernet board are you using? Usually, quad Ethernet FMC cards provide a clock source. Is this an HDL or IPI project? While I have no argument with the first reply to your question, I've never seen this type of error, having done a lot of DDR based interfaces. What version of the tools are you using? I've used the UMFT601X USB 3.0 mezzanine card with the NetFPGA-1G-CML Ethernet PHYs and DDR in one design. Not sure why you need to add 4 Ethernet interfaces to a board that already has 4 of them. That's a lot of clock domains... The NetFPGA-1G-CML has disappointing DDR3 performance and not enough clocking options for a board that's supposed to provide a platform for its intended purpose. Of course, it's also a lot cheaper than any alternative that I'm aware of. The only thing that I haven't tried to use is the QDRII+ because the schematic is just plain wrong and even though Digilent claims to test every board won't provide any support to prove it. It's also a very power hungry device for 1 or 2 MB of pseudo-DPRAM.

It's certainly possible to provide the tools with placement constraints that cause conflicts and result in a P&R failure but I've never run into this. I suppose that this might be more likely in the IPI flow since the designer is relying on the tools to handle the details. I don't ever remember having the experience of the tools automatically placing resources that result in a failure to route, at least not for DDR IO. I've certainly run into tools bugs with respect to MGT placement; in particular for using the NetFPGA-CML-1G PCIe interface where the Kintex package is different than for the KC705 board device, Slogging through the warnings and information messages when a build can't get through bitgen is certainly a good standard practice to adhere to. When the error and warning message are confusing ( more often than I'd like ) opening the Implementation to peruse the reports and placement views can sometimes be helpful... if the tools get that far. I've done a lot of designs involving RGMII Ethernet PHY interfaces without getting stopped by the inability of the tools to route the design. Achieving timing closure for complicated designs in which clocking restrictions are likely to be run into is a more familiar experience. I can say that, in general, Xilinx devices and tools are easier to work with than Intel devices and tools as far as clocking regions are concerned. On very rare occasions I've been totally stumped by failure to create a configuration bitstream. Then it's off to hoping that a web search will provide a clue as to how to proceed. Different versions of the tools do have different bugs. It also doesn't help that Xilinx has a bad habit of depreciating the syntax for constraints every other tool version release and that the tools aren't always clued into the changes as far as the TCL and template features go. Still, there are a lot of (usually) helpful features in Vivado to deal with most issues once you learn where they are and how to use them.

Except for ZYNQ based UltraScale(+) devices there aren't many UltraScale(+) development boards available to choose from. I don't know if this is due to pricing or general availabliity, but the UltraScale family historically hasn't been much of an option for experimenters or small independent board vendors . It's possible that this could be the case for Artix UltraScale+ as well. There certainly has been an unusual time lapse from when hints of the Artix UltraScale+ were first made public and to when documentation and actual hardware was available. It's a curious thing. One problem with UltraScale is that for anything but simple IOSTANDARD interfaces these devices are a lot more complicated to use for the HDL flow. On top of this, the tools are enforcing an abstraction of the actual hardware implementation not seen with older device families. The line between what the HDL designer controls and what the tools control is more blurred. And on top of that the IP is more likely to hide the details in encrypted sources. UltraScale IO with DDR or IOSERDES for UltraScale is more restrictive and less "general purpose" than it is for Seried 7 devices. Even something as simple as DDR is a lot more complicated for board designers and board users. UltraScale has larger block memory, but it's restricted to 1 clock implementations, and thus has restricted utility. If the IPI design flow works for you none of these considerations might be an issue. For most FPGA based product vendors, in my experience, IPI is not a feasible option. There certainly are some advantages to UltraScale verses Series 7 but I'm not inclined to think of it as a positive evolutionary step the way that I've thought of Series 7 over previous families.

Xilinx, .. er AMD/Xilinx as of this week has been strangely mum about the Artix UltraScale+. I suspect FAB availability issues. As far as I can tell Opal Kelly is the only board vendor claiming to have a board based on this family. Do your homework as their board tend to be small and limited in terms of power dissipation. But you can check out their website for information. The good news is that they support MATLAB. The bad news is that they don't provide basic information such as schematics, and users are tied to custom netlist based IP for basic connectivity. Still, their proprietary development system can be fairly quick for some projects once you get the hang of it. I'd be surprised if Digilent doesn't have plans for some sort of Artix UltraScale+ board though I'm not privy to such information. They seem to be more open to selling 3rd party boards lately as opposed to developing their own. These are difficult times to be investing in such an enterprise. Having said all of that I'm not sure that I understand your question.

Generally, there is no requirement for using a differential external clock for all but the most critical designs. So, I suspect that yes... provided that you alter the source code, you can port a version of the KC705 UG936 design example to your board.. considering the limited IO of the design and the fact that it is mostly VHDL sources. As I recall, the KC705 external differential clock is 200 MHz and the Arty single ended external clock modules are lower frequency. I don't have the sources available to look through. Do get the Digilent master constraints file for your board as well as the schematic so that you can work out which pins to connect your toplevel entity to. I'd be surprised if the design didn't have an MMCM or PLL in it. If so that you mean some changes to instantiating that resource. The Kintex on the KC705 is a much more capable FPGA device so what runs at 200 MHz on that platform might have timing closure issues for your board. There might also be a shortage of other resources; it's hard to tell without looking at the source code. But there's no harm in trying. So, go for it. Just to be clear... you will have to use the schematic for your board to select the proper pin location constraints for any port to your board. All of the pin locations will have to be changed. Alternately, you could use the Digilent reference manual for your board but I'd advise against that because schematics are almost always correct and other documentation, even master constraints files, sometimes have errors. The only FPGA board that I've ever run into with an incorrect schematic is the FPGA-Net-CML-1G, which has a faulty symbol for the QDRII+ memory device. You should read the Series 7 SelectIO and Clocking resources reference guides before embarking on a design; even a port of a demo meant for a different board and device family. Last note: Make sure that the signal names on the toplevel port match EXACTLY the signal names on your constraints. If you manage to get through bitgen, check the pin assignments against the schematic to make sure that they are correct.

Also, make sure that you are setting the FPGA device and package correctly in your project. And, make sure that you have a license for the Kintex-325T device or you won't be able to create a bitstream file an configure the board.

Trying to follow a tutorial meant to target an FPGA device and board that isn't the one that you want to work with can be a problem for those just getting started with FPGA development. In the case of UG936 the pin locations are for the KC705 board. Normally, I'd mention that you can use the tools to build a design that targets most devices and boards. You just can't use the bitstream file to configure hardware that doesn't use the exact device ( and package ) or a different board. The free tools don't support all devices, notably Virtex and Kintex; and the KC705 uses a Kintex device. So, you can go through all of the steps of creating a bitstream, except the final step... which actually creates the bitstream file, unless you have a special device license. This isn't necessarily a show stopper. Reading through the Xilinx tutorials is good.. with limitations. You can learn how the tools work and how the preferred Xilinx IPI design flow works. Having said all of that you need to know if your board is an Arty A7 or Arty S7, as one uses an Artix device and the other a Spartan 7 device. Also, I believe that there are different versions of the boards that use FPGA devices with different packages; that is, different versions of the Arty board will have different pin locations. So, keep reading the Xilinx documentation. But when you want to see a design working on your board you will have to use the proper constraints for your board. This is important because you don't want to create a design that ties a pin to an output buffer if the hardware connects it to a external device that is driving the pin. Whether you want to use the master constraints file for your board or the board files depends on your design flow. For an HDL design flow you will likely use a modified version of the Digilent supplied master constraints file. For an IPI design flow you will probably want to use the Digilent supplied board files. In the former case you will be responsible for making sure that the constraints are correct. In the later case Vivado will control this. The truth is that either one is possible for either flow. The problem is that there is a lot of learning to do for someone just getting started and simpler is easier. Things can get pretty confusing very quickly, and Xilinx documentation is frequently confusing even for expert FPGA developers. Personally, I think that using the HDL flow is better for beginners.. as long as there is some guidance available. Unfortunately, finding good all HDL demos that users can build for a particular board are hard to come by. FPGA vendors and FPGA board vendors prefer the IPI design flow because it's less complicated and expensive for them as they can control use cases.

Your description of your setup makes it seem so simple. The reality is that there's a lot of layers of software happening on both sides of the Ethernet connection. You understand this as you suspect that the version Win10 affects reliability. The quickest way to solve very complex systems is to simplify the problem and establish some level of confidence in the basic parts. Is it an issue with the FPGA hardware, the switch, Win10, or a combination? One nice thing about an Ethernet client on an FPGA platform like the Genesys2 is that you can instrument the design. If a board expects to send or receive a packet every 500 ms or so then you can detect a failure of that happening and query the Ethernet MAC or PHY for statistics and possible fault conditions. Rx and Tx PHY errors can be detected outside of your Microblaze system. Faced with such a problem I would certainly want to know if the Ethernet physical layer was robust over a 24 hour period before trying to investigate other causes. One simplification of your setup would be to remove the switch and just work with 1 Genesis2 board to see what happens. You could also load the Genesys2 boards with an application that just echos incoming packets and create a custom test application that sends out packets and checks that a matching packet is returned. Timing for the Genesis2 Ethernet PHY is pretty straight-forward. I've never had to resort to IDELAY unlike other platforms that I've worked with. Still, it's not impossible that timing could be a problem over time; not likely though unless the boards are in a stressful environment. It's not unreasonable to consider whether there might be some sort of electrical power event that might be causing an issue. This could be handled by various means. Intermittent failures are difficult to debug even for a simple system; so try and remove potential suspects as best you can. Perhaps, everything I've mentioned is obvious.. perhaps helpful. It's unlikely that anyone reading this post will have a similar setup. No one really wants to embark on a whole new project to work out issues on the one that's needed, but sometimes this is the quickest way to do it.

This project is NOT related to the Digilent OOB Microblaze project! This project does not use the IPI flow or any soft processor. The nomenclature that Digilent uses for its USB UART can be confusing. It all depends on perspective. If you look at the sources for this project you may glean some helpful information. There are UART Verilog and VHDL implementations posted on this forum. Of course you have to sort out signal direction relative to the hardware to make them work. Unfortunately, since the project was posted Xilinx has changed a lot of syntax for constraints as well as well as how board files work and even basic Xilinx IP database structure making use of Vivado 2021.2 problematic for older version demos with source code. Up to Vivado 2019.2 any version of the tools could be used to build this project without work-arounds. Recent versions of Vivado have depreciated the older Digient board files method in favor of the xHub for Vivado 2020.2 and now the Vivado Store in Vivado 2021.2. Version compatibility was the main reason for this project being posted. You can find the source for this project at the top of the thread. This project was posted to provide a simpler alternative to the standard Digilent Microblaze demo for the CMOD. It still provides some nice functionality, like being able to read and write logic resources using a standard serial terminal application; but since the only comments being posted to this project are in reference to someone else's project I'm considering removing it. Every new version of the tools gets more and more problematic for developers using an HDL design flow.

You aren't supplying much information but likely it's an issue with your location constraints. When P&R fails you should look through all of the synthesis and implementation warnings and messages up to that point. Look for anything indicating that lines in your constraints file(s) were rejected. Look for any indication that logic was optimized out of your design ( though I don't think that this is an issue for you ). I've been able use all 4 Ethernet PHYs on the board using the HDL design flow. I had to manage Rx delays for all of them. I didn't find any of the open source material that's available to be of much use so I just developed projects as if it were a custom board prototype with no support.

In order to use JTAG boundary scanning devices must be in the JTAG chain and this depends on the board design. Typically, only the FPGA and configuration FLASH are available for Digilent boards. There are probably better ways to learn boundary scanning. FTDI has a few application notes for doing this with their USB bridge devices. Logic device vendors have application notes. FMC connectors generally allow JTAG connectivity to mezzanine cards.

Don't waste money having someone set up your board tools. Usually, Digilent FPGA boards are powered by an external power supply. A separate micro-USB PROG or JTAG connector is used for configuring the FPGA with build products like the HW bitstream ( and possibly software files if there is a processor in the project ). That's all you need to do basic FPGA development. You don't have to have a physical board to do development with Vivado; you can build a bitstream for any device that your tool version supports. For Digilent boards this includes all ZYNQ based devices and any Artix devices, like the board that you are using. Don't try an power your board using the HOST USB connector. I'm unaware of any Digilent FPGA board that use USB 3.0 cables ( except for ZYNQ Ultrascale boards with USB 3.0 HOST capability; and this only applies to a situation where the ZYNQ is the USB host connecting to a USB downstream device). Most Digilent boards come with at least 1 USB 2.0 cable with the micro connector on one end. To get started you want to visit the product page for your board and get the constraints file, the reference manual, and schematic. The RMs typically provide good information as to power supply design and using the board. If you are using the HDL design flow those are all you need. If you want to use the board design flow you can install the Digilent vivado-boards-master repository into your Vivado installation. To understand the tools, use the Document Navigator that should be installed along with the tools for device documentation, tool documentation, application notes, etc. Your System Engineer background likely is an impediment toward getting started with FPGA development so I recommend strongly that you start off by reading the Xilinx literature to understand what you have and are working with. I realize that there is a strong urge to see you board work. It should come with a default application if you configure the FPGA from FLASH, instead of JTAG. Unfortunately, most of Digilent's demos use the board design flow and are unlikely to be built without some work unless your version of the tools matches the version of the tools that the demo was built with. The HDL flow is generally simpler, though recent versions of Vivado have had the habit of breaking any HDL relying on specific versions of Xilinx IP. If you are using a soft processor, then expect to double your effort as the software tools have always broken anyting created with earlier tool versions. Your board does not use ZYNQ. For beginners learning FPGA development ZYNQ just means learning both HW and SW tool usage and techniques.. that is 4X the work. Unfortunately, Digient has very few HDL flow demo project to try and rebuild. The design flow that you choose depends on the device and project requirements, but eventually, for any real world application, you will need a solid HDL flow experience level to survive. Xilinx documentation has always been notorious for being out of date. Using the Xilinx Document Navigator might help keep versioning issues to a minimum.. so use that instead of searching online.

Your design, as far as the synthesis tool understands it, seems to be running out of resources. It's hard to make a conjecture about what the problem is without more information about the design. But, there are certainly things that you could try. You could try implementing a smaller version of the design. You could try restructuring the design. In the case of a flaw in your source, you could comb through the synthesis messages for clues as to what's causing the issue. What happens when you try an run your RTL testbench simulation? Is there any device target that works in simulation?

Aside from what's provided in the schematics and master constraints file, what exactly are you looking for?

As far as I know, this is the only attempt at a general purpose HDL flow DDR tutorial: https://forum.digilent.com/topic/22197-a-guide-to-using-ddr-in-the-all-hdl-design-flow/ I haven't used the Spartan 7 devices yet but the tutorial is supposed to be general and interactive. You will have to be familiar with the external memory controller IP for your device; that is you will have to do some homework. Perhaps the link will save you some time. My expectation is that there is different DDR IP for Spartan 7, just as the IP for UltraScale devices is different from Series 7 devices.

The ZYNQ GEM controllers are a bit arcane to use. As far as I know you have to set up DMA Buffer Descriptors to connect the Ethernet MAC to memory; there aren't GEM data registers to access directly. It may be possible to use AXI BRAM in the PL as a BD source or sink; I don't know because I've never tried. So, if you goal is to connect your PL logic to a PS GEM then you likely have a few design options to choose from. You'll have to figure out how to synchronize your PS code to with your PL design to make sure that Tx data is available and Rx data is consumed properly. Since your frames are short you shouldn't have to worry about AXI burst addressing issues as long as high data rates are not important. Read the ZYNQ 7000 TRM for details on how to use the GEM. The SDK has numerous example projects to compile and inspect. Expect to put some effort into it. The more that you can constrain your Ethernet connection operation the easier the HW/SW project can be. Depending on your project requirements, and how you choose to address them, things could get pretty messy. In general, FPGA vendors have a strong preference as to Ethernet use cases. Swimming against the flow will be hard work; but potentially worth the effort.

Nice!

As I tried to explain earlier, what you want to do is going to involve some design expertise that is more complicated than a simple logic or level shifter approach. I don't think that the purpose of this forum is to provide such design services [for free] or serve as a broker between client and designer.