zygot

For the most part Digilent has its' own add-on board ecosystem that competes with ( or perhaps I should say is similar to ) the Arduino ecosystem and they design their boards to work with PMOD interfaces. Obviously, the PMOD connector isn't pin compatible with the Arduino connectors but that doesn't mean that you can't use any Arduino boards with Digilent FPGA boards; you just have more work to do. Terasic makes a number of Intel low cost FPGA boards with Arduino connectors if you want something easier and simpler to work with. If you pay attention to the schematics there are a lot of Xilinx based FPGA boards that could work with anything, though you might need to do some bread-boarding or digital interface design for compatibility. It doesn't sound like that's of interest to you. If you go with Terasic be sure to choose a board based on the Cyclone 10 LP or earlier Cyclone devices to avoid having to pay for Quartus development software. I should point out that analog functionality on FPGA plaftorms with Arduino 'compatible' connectors tend to rely on the FPGA internal ADC and are not straight-forward in replicating implementation. Do your homework. Rather than select an FPGA platform and hope that it works with any future project, choose your project or intended use and select an FPGA platform that supports that use.

The DAC1411 hardware design doesn't support selection of AC or DC coupling directly.

Last thought, for now. Sending the same packet contents repeatedly might not be a good exercise for a UDP demo. It doesn't address potential real-world behavior. I realize that the idea is to improve what you've read in the material that your links point to, but there's still work to do before you have a useful application. If all of these comments seem hyper-critical or dismissive, I can assure you that they aren't. I'm a big fan of MAC-free, vendor IP-free, Ethernet physical layer FPGA HDL point-point communication. It's my way of urging you on...

You could have saved time by just adding commentary to the original Verilog and instantiating the Verilog module as a component in a VHDL entity, if that's your preferred HDL. Still, the exercise has been valuable to you. The biggest issue that I have with the post is the hardware interface. I'm not interested in selling PMODs for Digilent but that solution is cheap, has an RJ-45 Ethernet connector, will do 100 Mbps and will work with any FPGA board having PMOD connectors that aren't the low speed variety... they might even work with those, I haven't tried. I think that this would be useful and of interest to a lot of people using the Digilent forums. I suggest concentrating on a limited Ethernet capability, especially for UDP as there's no guarantee that packets are delivered in the order in which they are sent.

Ok, I have bad eyesight but even I can see that the link to your project in your first post is different than it is in your last post. In the link in your last post states: "We are using a Pluto board here with an external 20MHz oscillator." Also, there's this: "Also even if that works in practice, we are not compliant to the Ethernet electrical requirements by just connecting the FPGA to a cable (we would need a filter and a transformer). So let's just consider that a "lab" experiment." I don't know what kid of a switch you are using but in my experience Ethernet switches require periodic ARP packet handshaking to determine what node addresses are active, or they don't pass along incoming packets. I assume that you are using the software described in your last post. When I tried looking at the link you provided in your original post I saw a static page and none of the information in the link provided most recently. Neither shows a Basys3 connected to your home network switch. But at least the link in your last post provides some of the information that should be there. What do you suppose is the effect on the FPGA pins driving a "short" Cat5 cable into the magnetics of a switch Ethernet receiver? What if you used a 30' or 100' Ethernet cable? But what you've posted here doesn't match the information on any of the links that you provide. That's why writing up a short description of exactly what you've done isn't at all silly.. but necessary. As a purely learning exercise I suppose that porting someone's Verilog code into VHDL is worthwhile. But how many people want to do 1-way UDP over 10BASE-T? Using a switch implies that multiple Ethernet sources (Basys3 boards) can communicate with your PC application. What's going to happen when collisions occur or you decide to send longer packets and they get fragmented by the switch? I suggest that trying to receive packets on your Basys3 will be pretty hard to accomplish. Your documentation should address these questions to avoid confusion from your readers. To be clear, I haven't stated an opinion on the merit of your post; I've just presented my reaction to reading it and the links that you've provided along with your other post that you haven't replied to. I'm just trying to figure out what it is that you are presenting and what you think that it could be used to do. But yes, I have been following along as best I can given what you've presented. That silly project description write-up might have saved us both a lot of typing. All of this would be easier using the PMODNIC100 and using a PHY instead of limiting yourself to 10BASE-T and Tx only communication ( and possible abuse of your Basys3 FPGA pins ) . Since Digilent doesn't actually provide any FPGA support for that product you might have a larger audience. You've already got the basic packet structure down. In fact I was contemplating using the ENC424J600 as the basis for a Project Vault project before I realized that they already had such a product. It wouldn't be too hard to modify your project to demonstrate a simple true 2-way point to point 10 Mbps Ethernet project using that PMOD and avoid the hardware issues at the same time. BTW, if you look around, this isn't the first or only UDP project posted to the Digilent Project Vault...

Not really. I think that projects posted here should be confirmed as working on hardware before being posted. When you say that your code is complete, what do you mean by that? Have you connected the output pins to an old PC with a 10BASE-T Ethernet card? Have you even gotten around to receiving packets on something attached to the output pins? What external hardware sits between your Basys3 output pins and the receiving hardware? You've posted in two different places in the Digilent Forums about this project and you seem to prefer that they be taken as referring to different projects. The other post references Ethernet Rx hardware. I think that I've addressed the concept that simply referencing a link to a related project or even one that is the basis for your work isn't very meaningful. It doesn't take much effort to write up a short description of how you verified that your code works on hardware, how you tested it, and how users can replicate your results. Perhaps all of this is missing because you haven't 'closed the loop' by implementing a receiver yet? There's nothing wrong with posting 'code projects in progress', I suppose.. if you are honest and careful in advertising it for what it is. I'd just rather see it posted somewhere else. This is just my personal opinion. I'm not the Digilent Project Vault Overseer. My personal preference would be that people submit projects to Digilent for posting here. Digilent staff would replicate and vet the projects and post those that are good along with editorial commentary and corrections as needed. That isn't going to happen so we're left to post and comment as desired. If someone experiments on their own hardware and ruins it but doesn't post about it then blowing up a board is the worst that can happen. If they post about it then they can induce people who know even less than they do to ruin their hardware and that's not a very nice thing to do. Posting project code that is incomplete, ignores pertinent details, and involves connecting FPGA pins to external hardware is more apt to cause real harm to those who might not know enough to be selective about what to try out for themselves. That's my thinking... Mostly, I'd have preferred if you chose other statements in my earlier post to react to as they are relevant to the project material.

I've always thought of the Project Vault as a place where completed projects with sources are posted, but I guess that there's no one enforcing that. I love the idea of doing projects just for the sheer self-guided educational enjoyment as I do this myself. The idea of flying blind has a certain romantic cachet to it but if you have at least one working eye if might preferable to use it. So, I have a few reactions to the post: For FPGA projects the place to start for all work is with the FPGA device vendors datasheets and user manuals. You can't use a device properly if you don't understand how it works. As the tools are closely coupled with the device capabilities you should at least speed read though that material as well. For Ethernet projects the place to start is with the official documentation. It's freely available and has a description of all of the layers. 10BASE-T, 100BASE-T, Gigabit, and multi-gigabit Ethernet physical layer implementations are very different things. The differences are important. If your intent is to propagate knowledge then don't just throw out some 'code' but add a description of how the code can be used for a particular purpose. Partially completed code snippets can be very misleading to those who don't know enough to ask the right questions about concepts. The answer to this question can be found in the Series7 SelectIO Reference Manual and the Basys3 schematic. Don't assume. Don't do experiments without first doing your prep work. Even for 'just for home entertainment' projects the same level of discipline that one might employ on a 'work' project is more productive. I briefly read through your transmitter code. If you use a common, or even a related derived clock source for Tx and Rx, you will be fooling yourself about how well your design works. Personally, I have a problem with offering code examples that suggest a broader usefulness or state of completeness than it provides, so perhaps my reactions seem a bit harsh.

Perhaps that's the purpose but it isn't a description of how the design is supposed to work. No one can help you debug your purpose but perhaps they might have some insight into how you can debug the design. So... again, how's the design supposed to work as you envision it? There are a lot of ways to replace the ADC devices in your simulation testbench. The easiest would be to have a process that spits out incrementing data. You don't have to worry about output code formats... just refer to the ADC datasheet and make sure that the data is transferred accordingly. One of the nice things about Verilog for simulation is that you can use parts of Verilog that aren't supported by synthesis. You can read a file with ADC sample words and feed that into your testbench. Trying to see "actual real-world ADC sample data" in a simulation probably not a good choice for a number of reasons. Really, the more important thing about the simulation is getting confirmation that, on a behavioral or RTL level at least, the whole design is doing what you think that it's doing. Simulating ADC formats isn't necessarily the first thing that you want to do. I realize that there isn't a lot of texts available on good simulation techniques but you need to develop your verification chops in step with your design flow skills. One problem with designing testbench code is that you are adding another thing to debug. It's analogous to unit testing software modules. The point is that, as your designs get more complex and hard to follow, your verification skills need to get more sophisticated and crafty as well. Your problem isn't that your design isn't working.. it's that your debugging skills aren't up to the task of figuring out how to find the cause of it's not working.

I appreciate that throwing code over the wall and hoping that someone spots the (hopefully) one or two defects that will fix the problem is an easy and quick solution... it's a common approach around this forum. Perhaps there is a more productive way. First, since you want to do an all HDL design your sources are missing at least one key element... a Verilog testbench. Part of the design process is verification, and at a minimum behavioral simulation is one part of verification. Simulation will help figure out what's going on with your design. To my way of thinking, if someone claims to have a design and there are no testbenches among the sources, then my first thought is to suggest that they still have some work to do before trying to implement an unfinished design in hardware. If someone came to me in person with such a question as yours the first question, even before "where's the testbench?", would be "start by providing a brief description of how your design is supposed to work". Perhaps, you could start with that. I can't tell you how many times just asking that question has produced answers to questions; as having to put into words a representation of an amalgam of concepts often reveals bad assumptions and missing elements. Having someone stop, mid sentence as the lightbulb turns on, is most satisfying for everyone.

The answer provided by @JColvinprobably should be sufficient. Before connecting external hardware to your FPGA pins make sure that signals driven into the pins are compatible and don't exceed input specifications. That's the place to start. But as your project hopes are based on a project that seems to be based on another project.. none of which were completed, this should give you pause. The person who provided the HDL that was the basis of your coding efforts didn't seem to have much faith in his interface circuitry so why would you? More to the point though is that if you don't understand how the circuitry operates and works then perhaps it's not ready to experiment with. More importantly, you should understand how, at least for 100Base-TX and above, Ethernet PHYs operate. Information on the physical layer for Ethernet is freely available. Do understand that Ethernet is a full duplex communications scheme and that on one end is a PHY driven through magnetics. Both of the projects you alluded to are geared to 10BaseT Ethernet. You can have similar data rates using an FTxxxH USB UART bridge device at 8 or 12 Mbaud ( though sending binary data is a bit more complicated ). I understand the pleasures and intrigue of experimentation as an educational experiment but if you have a project that needs an Ethernet connection then there are simpler ways to go about it. One possibility is the PMODNIC100. This approach offers higher data rates and a simple SPI interface. It's kind of amusing, in a way that brings a wince to your face, how someone posts an incomplete description of of an unfinished project that concentrates on one aspect of an idea and that gets partially consumed by someone else who posts about an unfinished project based on the first one, but concentrates on another aspect of the idea, with little attention to the other parts. And then later someone else decides to try it out without having verified if any of the parts are really ready for implementation. I suppose that the title of the post, referencing CAT5 Ethernet signals, is more informative about the plausibility of design concept than you imagine.

I'm not sure why you think that. Can you provide a brief description of what you want to do in your project? For a small FPGA like the CMOD-A7 it certainly seems like a waste of resources to use a MicroBlaze processor. Of course it depends on what you want to do.

Yeah, but now that you know how to do it the next time will be easy. I strongly encourage using the XADC for all more serious Series7 projects, fan with heat sink, heat sink without fan or nothing at all. If you don't check on things you are just operating on assumptions. In electronics ignorance is rarely bliss ( for long ), especially of you are pushing your hardware. I kind of agree with you that LUT52% FF68% usage, with minimal or no IO being driven ( I assume ), and clocked at 200 MHz shouldn't cause your platform power supply to roll over and play dead... but that's the nature of this class of boards. As I mentioned the more expensive FPGA hardware comes with a more robust power supply design. Regardless, I'm pretty sure that 1 unhappy customer out of a thousand isn't going to change the way that these boards are designed. I'm betting that 90% of the projects done on them use less than 20% of resources... just a guesstament. I hate to mention it at this point but there's still that outside, low probability chance that something has gone wrong with the 12-pipeline 200 MHz build. At this point, personally, I might be curious enough to try a few builds sliding from 100 MHz upward to see the power dissipation curve... but I can get overly curious. Most likely it's the hardware platform. Thanks for keeping us informed about your experiences.

Since you are using the ATLYS I feel that it's appropriate to warn you about those USB Type-B plugs. The only thing holding them onto the board is a thin strip of copper on the mounting surface of the PCB. I've had about a 50% failure rate with these over repeated use; that is the connector, and copper signal traces being ripped off the board. One problem is that some of these have a fairly high insertion force requirement and the surface mount USB connectors just aren't up to the task over time. It isn't only cheap FPGA boards with the problem. I have a couple of 'not cheap' nVidia dev boards that are now useless. At least the ATLYS has a JTAG header as an alternate configuration method... which my ALTAS is now dependent on to be useful. A generous dollop of non-conductive epoxy around the mounting tabs provides some added mechanical stability... if applied before there's a problem. I'm always on the lookout for this kind of mistake by vendors... but really, there's no excuse for saving a few cents by using SMT USB connectors. Don't do it!

It's kind of a shame that Digilent was historically so sloppy with their PMOD designs on the FPGA boards. Very few PMODs are connected to clock capable pins on the FPGA. A problem is the 12-pin connector... it really limits what you can do with it, and I think that the decision to double the GND and Vcc pins is generally not all that useful and certainly exacerbates the issue. A simple PMOD with holes for an external clock module would make the whole ecosystem better... but what's the point when almost none of the FPGA boards can make use of it? I strongly advise Digilent to reconsider their product vision with respect to their unwavering commitment to the 6-pin 12-pin PMOD lock-in strategy. They still can support this ecosystem and make boards that suits their customers' interests at the same time... to me that's a win-win for everyone.

TMDS requires 50 termination to function. The HDMI INput connector J3 uses the TMDS141 TMDS re-timer device to accomplish proper termination. You need to be careful with HDMI. Because of those 50 ohm terminators you end up with a path for external devices to pump current into the ATLAS Vccio rails... so the system power-up sequence is important. You don't want to drive current into the FPGA rails before the ATLYS board has been powered an it's own power rails are stable. Just connecting supply rails between two independently powered boards without carefeul current management is scary. Ideally, you'd have a switch that disconnects input TMDS terminators until the receiving board has powered on ( and in the case of the ALTYS the FPGA device has been configured ). This is an added expense that no FPGA development board, that I know of, with HDMI inputs is burdened with. This is a real concern that needs to be addressed, and it's really an HDMI issue. Having said that it's conceivable that you could use J3 as an external clock source.... but of course there's no clock on the sink end before the external source is running... and you don't want the external TMDS driver running until the ATLYS is powered on... it's a dilemma. I wouldn't advise using the JA mini-HDMI connector for HDMI connections as there is no proper TMDS termination on those signals. There are 50 ohm series resistors between JA and the JA-Dx and JA-CLKx signals into the FPGA, but not between JB and the same FPGA IO pins. The JA/JB connector pins go to IO bank 2 which happens to have a user-selectable Vccio of either 3.3V for single-ended signals or 2.5V for differential signals. Be aware that your choice of Vccio will affect every signal connected to IO bank 2 leading to potential conflicts ( you can't have conflicting IOSTANDARD constraints on the same bank ). JB on the ATLYS is the only PMOD on a Digilent board ( as far as I'm aware of ) that has user configurable Vccio options. This makes it unique. I don't see an easy, no effort, way to get you your preferred clock signal.

That's a tall order. Digilent made a few breadboard cards for the VHDC connectors on the ATLYS and original Genesys boards but they aren't ideal. I think that your best bet is to use the PMOD connector and make your own external clock module card. If you go to Mouser (or convenient distributor for you ) and search for "74.25 MHz clock module" you will find a few 3.3V single-ended modules available. This would be the simplest way to go. Fortunately, your frequency isn't odd so there are possibilities. For sing;e-ended clock inputs you'll need to use the _p pin. The only peripheral for the VHDC connector that I'm aware of from Digilent was a dual camera board... all in all this was mostly a dead end interface. It's also darn hard to work with using simple layout PCB software if you want to design your own add-on board. It's certainly caused me much frustration as I use both of those Digilent FPGA boards on a regular basis.

No. Timing constraints help the synthesis and P&R make good decisions about routing and placing logic, it can't magically select the best clocking scheme for you and implement it. You can make a large number of DMC clock output frequencies from a given clock input frequency; the impacted variable is jitter. The ISE and Vivado clock wizards allow you to specify output jitter, so you can increase the odds of getting a frequency close to the desired one by relaxing the jitter spec. You can also just instantiate a DCM as a primitive and choose your own multiply/divide factors. This approach lets you select more ouput frequency possibilities... but the burden of determining the quality of your final clock is up to you. Again, the best way to get the clock frequency that you want is to add external hardware. The ATLYS has a VHDCI connector that supports this; at least 2 pin pairs are connected to clock capable FPGA IO pins. Also, JB shares signals with one of the PMODA HDMI connector and has a clock capable IO pair. You'll need to pay close attention to the bank IO Vccio and the external clock module output logic for compatibility.

I like the idea of cascading DCMs. You will not get ISE or Vivado Wizards to evaluate you own IP, so you will have to do this for yourself. I don't think that the Wizard even knows about cascaded DCM designs anyway. You might be able to get an idea of the feasibility of your concept by trying to use the Wizard to create your clock outputs from the given input clock and see what it produces. Unfortunately, while the Spartan 6 device is still a great device it has inferior clocking capabilities than the more recent Series 7 devices. Getting an arbitrary clock out of any input clock can be problematic if jitter is of concern. The best approach might be to use an external programmable clock module, possibly with with another clock source. One feature lacking in the higher end Digilent FPGA platforms is a good programmable external clock source. This is a shame because cocking is critical to the success of many designs.

Well, no. A 12-pin or even 6-pin PMOD cable would violate the 2nd tip: Don't connect Vcc rails between boards. They are fine for PMODs because the add-on boards need Vcc. It's very easy to create big problems with cabling; you have to verify that the cabling is connecting the proper pins together, and nothing else. For 1 MHz signals it's probably ok to use flying leads. You can buy 6" leads with female-female headers, male-female headers or male-male headers from places like Adafruit. You want male-male wires. To be safe you might stick both ends of a male-male lead into each of the mating PMOD connectors; that is connect pins 6 and 12 together for each PMOD. That way you won't accidentally make contact with the Vcc pins with your cabling. The best way to do this is to make a custom cable. Since the PMODs are not keyed it's pretty easy to get things wrong. Verify connectivity with an ohmmeter before powering anything. Never connect or disconnect inter-board cabling while either boards is powered on. I use the HDL design flow so I just need to declare a signal as in, out or inout on the toplevel port declaration. The best way to handle external signals is to instantiate the appropriate buffer in the toplevel entity using a primitive. If you don't do this the tools will automatically instantiate one for you, as long as your constraints file has the same name as the toplevel port declaration. If you are using the board design flow you can just make a signal external and the tools will instantiate a buffer. If you want a particular buffer type then you need to instantiate it in your design. Frankly, I don't use the board design flow, except for ZYNQ designs and my toplevel module or entity is always a VHDL or Verilog source file.. so I've never tried selecting a buffer from the IP catalog. As preparation, make sure that you read the Series 7 Select IO User Guide. There is also a guide for instantiating primitives in HDL, I think that it's UG768. Once you start doing designs that don't use the limited Xilinx IP or Digilent PMOD IP you are much better off using the HDL design flow. This not only gives you more control over your design but forces you to think about the details.

Yeah, I sometimes get sloppy with some projects. But here's a different way to think about making the best use of your very limited time; it's one that I keeps getting thrust into my mindset by complicated projects. For 'side' projects this is all about self-preservation and self-defense. Spinning my wheels is more frustrating than forcing myself to do some sort of code version preservation. There are no hard rules and you don't need versioning tools. Just zipping up a project when you know that there are going to be major changes is often sufficient. Developing some good, simple, habits and processes might only pay off big every so often.... but when they do it saves you so much time. Archiving whole project snapshots is good because you can compare messages, reports, simulations easily. You can also add measurement instrumentation to both the old and new project. If there's an unexpected major change in behavior it might help find unintended changes. Anytime you're using Vivado board design to create code there is that potential. I've seen Vivado do some very strange things when I make minor changes. (I should mention that I never use the board design flow except for ZYNQ projects ). Somewhere, there's some good balance between working on a project and doing what's needed to evolve a project without encountering undue pain. What works for me doesn't necessarily work for you. Some projects turn out to be as simple and straight-forward as expected. Others, not so much. If you think about it, projects done for personal growth are no different than those done for work ( aside from the usual noise associated with a team project having a strict deadline ). They both take up your time; so why not make the time you have as productive as possible? Just some personal thoughts on the subject.

I thought of something that I forgot to mention. The standard PMODs are good for low toggling rate interfaces. Also they have 200 ohm series resistors that, to some extent, help protect from ESD and shorts, both temporary and long term, and to a lesser extent transmission line issues. Even still try and keep cabling as short as possible, especially with flying leads.

I've done this many times. What boards are your using? Tips: make sure that you have a good bonding of the GND reference for both boards, especially for single-ended signals. PMODs have 2 GND pins. Don't connect any power rail of both boards together Before configuring both boards as a connected system take extra precautions to be sure that your have assigned the pin locations correctly; that is check the post route pin assignments. Make sure that there is no possibility of contention. The pin on the sink side should be an input only and the pin on the source side should be an output only. For relatively slow signalling assign output driver SLEW as slow and output drive at 4 mA or the minimum available for the first test. Open-drain or open collector outputs are one way to connect drivers safely. The safest way to connect external hardware is through external buffers as a protection for the FPGA pins. Before powering anything double or triple check the interface wiring and design. Be aware that the PMODs are not keyed... so it is possible to have connection/cabling issues with potentially disastrous consequences. You don't want to tie the GND and VCC together or drive output buffers into either of those rails. What exactly are your concerns?

This is where simulation can help, especially when making major modifications to a 'rock solid' design. I've found that, when not confined to a code versioning system, archiving a project that is at a 'good stopping point' before making changes is a good practice. This make is easy to refer back to a previous known state in the project. Sometimes it just makes sense to keep archived snapshots of just the HDL source. Sometimes, it makes sense to save the project as a new one so that I can open either the old 'working' version or the new 'in progress' version. This is really no different than standard software development except that the FPGA tools create way more intermediate files on the HD. Not everyone works the same way but I thought that this was worth mentioning... you know, for future readers who might find it interesting.

I second that motion. If you open the Xilinx Document Navigator and do a search for XADC you will see quite a few references, some with code examples. On the subject of your temperature measurements. I also have an IR thermometer as a quick 'safety' check when I connect new external hardware. I do this mostly in case there is bus contention or driving outputs to ground**. As a more general measurement as to how your components are faring when there aren't any defects in a design I would caution against putting too much faith in such measurements. Fortunately, the Series 7 devices all have the capability of measuring substrate temperature using the XADC. This, in my view, is the proper way to assess thermal conditions. All of the components on your board have maximum operating substrate temperature limits that need to be adhered to. Let's recap the post so far. As I understand it, your initial observation was that once your PL design started running 2 LED indicators indicating the health of the power supply and FPGA configuration status indicated that both immediately indicated failure conditions. After this your communication between the SDK debugger and the ARM cores stopped. It's certainly reasonable, barring other considerations, to suspect that a drop out of some of the power supply rails precipitated these events. The next step might be to try and prove this hypothesis, and perhaps find a way around the root cause. The ZYNQ has a number of PLLs on the PS side that generate derived clocks for all of the internal peripherals like DDR controller, Ethernet PHY, UART baud rates and of course AXI bus clocks. You can export these clocks to your PL. You can also use the PL MMCM and PLL clock generators to generate PL logic clocks. There's no wrong way to go as long as you adhere to basic clock domain principals for passing signals between clock domains. There are a lot of ways to do this correctly, but of course there are a lot more ways to do it incorrectly. Most high speed data transfer involves elastic storage, like a circular buffer or a FIFO. If there are two clock domains involved then the FIFO and buffer must have 2 clocks. The full AXI BUS is not trivial to work with and there are a lot of ways to cause bus faults. Bus faults will certainly terminate your debugger session but I have no idea how they could cause the power supply controller to fail to regulate an output rail or cause the logic to lose configuration. ( I also don't do a lot of ZYNQ design work so I haven't had the need to do some serious investigation into all of the details about those devices... and the interesting details are usually not easy to find in the literature ) I'm not at all surprised by the push-back to my suggestion that expecting a cheap general purpose FPGA board aimed at the educational sector be able to handle the full capabilities of the FPGA devices is unreasonable. The Series 7 devices are really quite capable. What separates expensive commercial or military grade products from something like the Arty Z7-20 is testing and guaranteed specifications. That's what you're paying for when you buy expensive products. It's easy to underestimate the cost of over designing a power supply for a low profit margin product. I don't know of any vendor of general purpose FPGA boards in the educational market that provide a demo project that even attempts to explore the maximum operating conditions of their boards. In fact, it seems to me, that for most of these boards the vendors are banking on the user to create projects that use only a small subset of the external interfaces, and IO, and FPGA resources available and that few will ever need to do timing closure because of high clock rates on most of the logic resources. Beyond simply using a beefier power supply other ancillary costs usually go with enhanced performance, like more PCB layers, heavier copper planes, etc. , etc. Estimating production costs verses profit is a complicated business... and many companies don't do it well. ** You might think that this is the result of bad design processes, and in the end I suppose that you'd be correct. But it's a lot easier to get into these conditions than you might realize. A location constraint might be wrong or ignored by the tools ( always , always check the post route pin assignments) or perhaps you didn't get the timing constraints correct. Sometimes the tools automatically resolve a misunderstanding between your source and what they infer as your intent; and the only indication is a warning, among hundreds of messages, that something is terribly amiss. There are a lot of critters in the swamp of FPGA development waiting to take a bite out of you if you fail to notice their presence...

Xillinx branded boards typically have more robust and heftier power supply designs.. at a cost premium. The ZC702 is a Z7020 board with 2 FMC connectors and might work. Unfortunately, these are no longer in production and the ones in distributor stockrooms have undergone a dramatic price increase over what the originally sold for. I don't know it Xilinx sells them directly anymore. The older Ti power module designs though can be a pain when things go wrong and are a bit clunky. I've had experience with this. Always refer to the schematic as part of your pre-purchase analysis. I do like the idea of going with a non-ZYNQ platform if you don't need the ARM cores. It is indeed frustrating to find out that your purchased platform can't keep up with your project requirements. Doing your due digilence before purchasing hardware is goo practice and, as you've likely found out an expensive lesson. Fortunately, the Vivado tools can help with power estimation though when a design has lots of output pins being driven accurate estimation requires some detailed analysis.