zygot

Reading CN0276.pdf might clarify things that you might need to address. If you are going to create a circuit, simulation or physical, you should start with the requirements of the devices in the circuit. Simply trying to make the connections in your simulation circuit might be informative. It looks like you've asked some of the questions that you need to ask. Before embarking on a project doing a bit of thought experimentation to expose pertinent questions is a good practice. Getting to a project goal without knowing and resolving all pertinent questions is an unlikely occurrence. The AD2 is an amazing and useful product... all the more reason to understand it's limitations before assuming that it can perform any particular task. Simulation is not easy, especially if it involves hard to quantify behavior of physical elements and you need good accuracy. Hardware-in-the-loop simulation is even harder. Given the right approach and implementation what you want to do is certainly possible. It probably involves a lot more work than you are bargaining for. You might consider starting off with a total software simulation prototype to get your bearings before spending time mucking about in fleshing out the details that you think might be part of a solution.

It appears that AMD might be taking Xilinx in the same direction that Intel took Altera. I'm curious about your Vivado Enterprise installation. Since this is a paid subscription version does this mean that you installed it as a 30 day evaluation? Vivado license manager should indicate how long your subscription lasts. I interpret the language on the AMD-Xilinx Vivado product page as meaning that the free tools no longer support anything except the listed devices. They aren't clear about how what this means for new customers purchasing FPGA boards requiring a node-locked device license going forward. It certainly appears that AMD intends to mimic the Intel model of forcing customers into annual license fees for all but a few older devices. If what I surmise is correct this is bad news for students and small companies. The free version of Quartus, for releases of the past few years, has been riddled with bugs that make it useless for some features like external memory controller IP, on certain OS hosts. If programmable logic is going to have a 2 tier system, in which there's the free tools that may or may not actually perform according to advertisement, and annual paid subcrtiption tools that just have the typical tool release bugs bugs then a lot of businesses will be in peril. Not many individuals or companies can afford $3K-7K per seat for the privileged of using a vendors product in their own products.

Your issue may well be a problem with the tools. A leading zero error is a typical software gaff. Since the tool claims that your ID doesn't match what's in the license ( though it did for the earlier tool versions ) such a scenario is a reasonable guess as to what's going on. You should be able to resolve this through AMD-Xilinx support ( if that's even possible these days ). It might be difficult but try and resolve this through yoru AMD-Xilinx user account. Personally, I think that fewer tool releases are good for everyone now that the cadence of new devices has slowed. Unfortunately, the 1 year period for migrating node-locked licenses means that you are limited to fewer tool releases. Given the quantity of bugs in new tool releases verses typical benefit, that's not a bad thing; unless you need the functionality inly found in the latest... BTW, the license is user readable and might help resolve what's going on.

I wasn't trying to 'upsell' you. I've rowed many a dingy into hostile waters and have come to the conclusion that if a project is worth doing wasting time trying to overcome design limitations on the wrong platform just isn't worth the hassle. I don't think that you'll have trouble figuring out your plan B. I do encourage you to take advantage of one thing that Vivado does offer; that is you can create a design for any board that exists and see how the resource match up to your project requirements. You can't generate a bitstream for the Genesys2 without a device license or the full-fat ( high-priced ) tool version but you don't have to in order to prototype an idea and see hwo it might work out on a platform that you might consider splurging on. If you do the HDL design flow you can simulate everything. Creating good simulation models for external hardware is generally a iterative process but you can still learn a lot by simulating even a crude approximation of your external hardware. All it takes is time. If you know what you are doing most of the work will be an investment in the final project effort. Seem to me that you know what you are doing; even better know what to do to get to where you know how to do something that you've never done before.

You piqued my interest with your issues with the FT2232H_Mini_Module, since I've used this one and its siblings on many an occasion, so I looked at the schematic. Sure 'nuff, it shows a 0 ohm resistor connecting the USB shield (shell) to DGND. This is not good; but simple to correct. Depopulate R8. Shield grounds are intended to absorb transient energy sources, like ESD, [ and keep it from affecting ] the electronics and dissipate that energy to earth ground. Normally, this is chassis ground and isolated from any power supply ground.. or it can't server its purpose. Every FPGA board that I've used ( and that is a very high number as I use FPGA development boards as prototyping platforms or even system components for one-off designs ) , has either an FTDI or Silicon Labs USB-UART bridge device serving as a serial interface port. I've never been unable to use any of these in full-duple mode. Somehow your world and mine don't appear to be connected. The Silicon Devices CY21xx devices don't use a startup configuration EEPROM like the FTDI. I believe that for no flow control they require the CTSn input to be low. Such devices from both vendors support hardware, XON/XOFF and no flow control, but use cases with FPGAs might be different. The FTDI FTxxxxH devices support 8 and 12 Mbaud rates. The other FTDI and Silicon Devices UART bridges support up to 2-3 Mbaud depending on the IO voltage. See this post: https://forum.digilent.com/topic/2866-cmod-a7-35t-demo-project/ This is a CMOD A7-35T doing full-duplex using the on-board FT2232H bridge. Check it out. It's a 100% VHDL project ( though I've encapsulated part of it into a netlist because I didn't want to post the source code ). No Xilinx or 3rd party IP. I don't count the Xilinx clocking Wizard as IP. You can instantiate it as a macro, but the Wizard helps keep you from jitter issues. Except for FIFO and BRAM Wizards all of my projects are HDL code that I write myself. It's amazing what you can do just using VHDL or Verilog and no processor. Again, the Adafruit TTL-USB Cable doesn't support hardware flow control and only uses Txd, RxD and DGND connections to implement a UART. The only issue with them is that I keep forgetting which color wire is which signal... but I've taken to adding comments to my code to help. Personally, my time is more valuable than the price of the cable.. and using it truly is straight-forward. With the FTDI modules you have to read schematics, understand drivers and their issues, know what the configuration EEPROM contents are and slog through not particularly high quality datasheets and design notes. ugh! If you need a (up to ) 40 MB/s PC-FPGA connection and are willing to write your own application, plus go though the exercise of changing the EEPROM contents this might be worthwhile. Rarely does a 921600 baud UART NOT get the job done. If I really need high speed I'll use an FPGA platform with a PCIe connector. But, it certainly shouldn't be an arduous journey to get your FT2232H Mini-Module doing 921600 full-duplex when connected to 2 FPGA GPIO pins and a good DGND reference. I salute you for your service ( to both country and mother ). A salute to your home grown lab too.

And... the umpires calls a strike. I did indeed swing and miss on a curve ball. One thing that I can say is that the ISE 14.7 tools in the AMD-Xilinx archive are not the same as the last DVD from Xilinx releasing ISE 14.7. I know this because I've tried both and ended up using the DVD version installed on WIn10. I don't use Impact on Win10. Hopefully, someone else at bat gets a hit.

If you read your own post you should notice the first thing that I did: a reference to "64-bit". Is there a reason why you are using such an ancient version of Linux? Linux has even worse issues accommodating applications and compiled libraries written for 64-bit verses 32-bit than Windows as there are a lot more versions of libraries floating about. The exception is for an OS that doesn't support 64-bit applications and compiled libraries. Even in the old 32-bit only days Impact on Linux was a great source of consternation as I recall. The Linux kernel has changed a lot since your OS was the latest and greatest...

I have two of the original CMOD A7-35T boards and have used the onboard FT2232H UART as a full-duplex 921600 COM using the VCP driver and Putty. I don't know why you have been unable to do so. When I use the CMODs I rarely use the enumerated UART though because, for me they don't work with Vivado Hardware Manager running due to detachment issues. Digilent has added a design change a few years ago due to other complaints and I haven't noticed many posts about problems for quite a while. Perhaps your CMODs are older? Digilent has always maintained that customer issues with the CMOD USB issues are due to "bad cables". This doesn't jibe with my experience and vast store of USB 2.0 cables. Also, I've never had an issue configuring the FPGA on a CMOD. Anyway, when I do use the CMODs I always have 2 spare pins for a TTL USB UART cable or breakout board to provide connectivity to a PC. I've used the FT2232H mini-module UARTs as a COM or TTY device at 921600 baud, no flow control, using the VCP driver ( Windows and Linux automatically use the VCP driver unless you go through the steps necessary to make them D2XX devices ). I've also used used the FT2232H mini-module UARTs at 12 MBaud with hardware flow control using the D2XX driver and API plus my own C software application. I am unaware of any serial Terminal application that uses D2 drivers.I suppose that I should have added a 5th point to my previous list as I sometimes forget to set Putty to "FLOW CONTROL = NONE" for standard VCP operation. Putty is a good serial Terminal application because you can find versions that work with Windows and Linux. For my experiments I use a custom PCB that connects a Terasic DE0 Nano to the mini-module and has headers to connect an RPI and the two "high speed" PMODs commonly found on Digilent Boards. I've also used the synchronous 245 FIFO interface with this setup. The CMODs do not have a robust design for such applications using it as a component, unlike the DE0 Nano. Besides the power supply design, the single DGND pin is very limiting. I didn't see anything amiss in the schematics that you posted. Be aware that a number of FTDI bridge device pins have functionality that is tied to settings in the configuration EEPROM. FTDI has a utility to examine what these settings are. PWRSAV# is one of those and I don't use that functionality. FTDI bridge devices with multiple channels have each enumerated by the OS that they are connected to. I've never had an issue with one enumerated device causing a problem with the other enumerated device. I have run into a lot of OS issues and use the appropriate utilities to debug OS issues. Windows Hardware Manager is generally uninformative as Microsoft 'doesn't play well with others'. The COM settings that WHM show don't necessarily have anything to do with actual application settings for the device. 921600 baud is the maximum that you can expect for a UART applicatin without flow control. If you HAVE to make your project work and are frustrated the the $10 investment in an Adafruit 'USB to TTL Serial Cable - Debug / Console Cable for Raspberry Pi' would certainly seem like a good investment. If you want a higher data rate then you are into more effort and things to work out.. and also some software work to create an application that works on your OS. Your experience with different results when using a laptop verses standard PC is something that I've never run into... and rather bizarre. Perhaps this is a red flag that your issues involve something else?

The AMD-Xilinx Wiki: https://xilinx-wiki.atlassian.net/wiki/spaces/A/overview?homepageId=18844350 is their source for processor related support. They have example projects with limited support for ZYNQ USB HOST mode applications using Linux, but I don't recall seeing anything for the StandAlone OS. You can see if the SDK or Vitis offers anything. Don't expect full-blown USB HOST functionality.

No, you came to the wrong conclusion. Most UART issues are related to: Confusion with what device is driving the TxD and RxD pins... the FPGA or the USB UART bridge device. OS enumeration issues. For Windows add driver issues. A COM or TTY device already being used by another application ( like Xilinx tools ) If you also work with Intel FPGA devices Windows has a problem deciding if an FT232x device is an Altera ByteBlaster or a COM device. It can get to be quite problematic if not addressed Historically, CMODs have had issues with the COM device, especially if used at the same time as the JTAG device as one might do in Vivado Hardware Manager using an ILA or VIO. Shield signals are meant to be isolated from Digital Ground. I've used plenty of FTDI bridge device modules like the one that you are using. Good for high speed parallel data modes. Expensive as an alternate USB UART. Using these modules just adds complexity to a standard UART operating at 921600 or less. By far the easiest to use for any FPGA board is the USB to TTL Serial Cable from Adafruit. All you need is two FPGA GPIO pins and a DGND pin. I never use the VBUS wire. It's also the cheapest way to add a UART to an FPGA design at the moment, that I know of. Adafruit and Sparkfun both have cheap USB TTL UART breakout boards. They are all a lot cheaper than an FTDI module. Make sure that your UART is compatible with your FPGA board. Usually this is 3.3V logic. UltraScale boards might require a lower logic voltage. There are TTL USB UART adapters to work with other voltages. Unfortunately, this is a bad time to be buying these solutions; but you can still find some somewhere. Don't pay more than what the product maker charges. I'm always using all 4 of my USB to TTL Serial Cables on some board or another. They are an essential debug tool.

If you think that ths is an issue I advise that you mitigate it. For ESD issues there are specialized devices to mitigate this. You might be surprised how much ESD a gear spun by a toothed elastic band can create. Large inductive loads, like motor windings and some relay windings are alos a problem that can be mitigated using diodes. The GPIO on Digilent FPGA boards only provide current limiting resistors on the standard PMOD interfaces as a form of FPGA protections. You can look at the schematics from other FPGA board vendors to see seamples of ESD protection. When connecting your FPGA IO to highly reactive loads you have some design work to do. Modern FPGA device have internal protection diodes but these are not meant to address abuse by user application design failings.

My suggestion is not to keep trying to do what you've been doing; that is modify one of the demos for the board. The Ecypse-Z7 is not a good platform for someone without good HDL design and development flow skills. I've done quite a few for the platform. It's complicated for even seasoned programmable logic developers. To my way of thinking, the board design and supporting code exposes the basic problem with the IPI design flow, which is especially problematic for a ZYNQ platform. If you can't create a fairly simple toplevel VHDL or Verilog source file, connect it to the Digilent low level DAC code, simulate it, and get satisfactorily results, then you are in for a very frustrating experience. This involves basic programmable logic skills and is about as simple as it can get. I urge you to take the time to try that approach. Personally, I created and tested on hardware no less than 15 projects for the Eclypse-Z7 just to evaluate the platform's capabilities and suitability for the kind of things that I'd want to do with such a platform. Taking the time to experiment with intermediate designs can shorten the time to get to where one intends to be, especially if struggling with the basic operation. [edit] So, if you choose to accept my advice, you have two things to work out before your project can move forward. For now abandon the Digilent Eclypse-Z7 demos. Abandon the ZYNQ PS. Execute a basic HDL design that instantiates the low level DAC code from Digilent as a start and complete a proper simulation. 1) Figure out how to replace a complicated problem with a simple problem. 2) Figure out if your project project goals are compatible with the hardware that you are using. If you do this, then a solution to completing your project will become clearer. You might gain some good feedback as to what your FPGA development skills and competency are. As simple as driving a DAC might seem, this involves a lot more knowledge than a lot of people would suspect. If you have the basic sklll set this shouldn't take more than a day or two. You might struggle with how to initialize BRAM in simulation verses hardware if you haven't done this before. You might struggle a bit with signed binary math if you haven't worked with it before. You'll have a very hard time completing your project without these skills.

What would make you think that? I'm confused. Is this the DAC that you want to hold a voltage for 30 ns before progressing to another voltage?

I think that what you mean to say is that looking at a plot of the output of your MATLAB and C simulation appears to look like what you want. Perhaps the situation is better than that, I don't know.This level of simulation represents a mathematically optimal representation of your algorithmic output, not necessarily what your hardware is capable of performing. This is a good student project ( don't be offended as we are all students, or should be ). I supposed that you've read the Zmod1411 reference manual. It provides good guidance as to what you can expect out of that pod. You've only presented a bit of information about what the parameters of your objectives are, and that's fine, but limits the efforts of anyone trying to answer your queries. The manual suggest to you what the analog bandwidth of of the pod is at the output connector. A bit harder to work out are the maximum slew rates and settling rates to an acceptable precision of the desired output voltage. The example that you just provided suggest that you are already thinking in terms of sample periods. Perhaps, you want to be thinking in terms of sample periods representing Fs/2? What is the minimum realistic dwell period for any output sample? If sample n = Voutmax/2 and has a dwell of 100 Fs/2 periods, and sample n+1= Voutmax and has a dwell of 1 Fs/2 periods, and sample n+2 = -Voutmax and has a dwell of 1000 Fs/2 periods what would expect to see on a high bandwidth scope? This should be pretty easy to try out. Create a design that doesn't use the PS. It would have a small BRAM filled with Vout values and dwell periods that your design would send to the DAC low level controller. BRAM can be implemented as a PROM or just a regular RAM with a default contents such as a table that you create in a spreadsheet. Add a couple of counters and a bit of control logic and you are in business. Use one of the GPIO inputs to control the design. See what comes out. Trigger your scope with the start signal and capture the DAC output. If you really like the extra work and challenge of doing PS programming you can use an AXI GPIO for control. I haven't read anything that makes me think that your project needs a processor. It's a place to start. There's no harm in experimenting.

I haven't found Digilent's demo projects particularly useful for anything that I wanted to do with the Eclypse-Z7. If you are competent in using an HDL design approach with the AMD/Xilinx tools it shouldn't be too hard to figure out a way to get your project done. Perhaps a bit less involvement of the PS and more work for the PL?

Perhaps you can better explain what it is that you want to do, or perhaps believe that you need to do. Figuring out how to implement something that seems to be impossible has been a the heart of embedded software design since the first microprocessors were first used. Sometimes one over estimates or misinterprets the requirements. Usually something "close enough" will do. Solving the wrong problem might be impossible. Finding the correct problem to solve might be the key. What I'm imagining is that you want to produce a very long duration analog pulse using a DAC. An unsigned 16-bit DAC has exactly 65536 possible output values. Would you expect that the voltage at the output of the analog buffer that the DAC drives will maintain a value over long time periods to Vmax/65536? Keep that in mind as you ponder your design approach ( and the fact that you are using a signed 14-bit DAC. Time is relative. Defining what exactly it is that one needs to do isn't always easy. The solution to finding an implementation to such problems usually starts off with a prototype, often done in MATLAB or OCTAVE starting with any available canned functions. Plot it out to visualize it. Then implement a second prototype using only keywords and structures that you know how to implement in logic or code ( you've already figured out how long a particular implementation takes ). Think about a way to implement something similar that still works for your ultimate design goals. The design loop gets closed when you collect output data that matches, within acceptable limits, to the prototype simulations. Usually hardware simulation is an intermediate step. When hardware involves a combination of logic and software it might be easier to just skip the hardware simulation. Sometimes that step has to be done even when it's hard. Sometimes the brute force approach works. Sometimes it doesn't. [edit] My answer mentions that "Usually something "close enough" will do.". As a matter of perspective, this isn't quite true. Actually, every design solution that humans or even "Mother Nature" creates is an approximation. Sometimes we forget to keep that in mind. So, any engineering solution really involves correctly identifying a level of precision and accuracy in our solution. It's often useful to start at the end product, in this case a DAC output voltage and work backwards to establish reasonable design specifications. Embarking on an engineering effort without good specifications is a recipe for failure.

Once your signals get into the microwave part of the spectrum the analysis for connecting them between devices on a PCB or devices on different PCBs changes into a substantially different beast than for lower frequencies. It is an interesting subject, as you've found out. Back in the days of ECL/PECL there were a lot more players in logic vendor space.. as well as good application notes for implementing good transmission lines. The consolidation in the semiconductor field is not going to work out well for anyone in the long run. I think that having 2 behemoths own 90% of the programmable market is even worse... especially when those companies also own a bulk of the PC chip market... depressing. As some of us have learned recently JIT is great, for some companies, when everything in the world is normal and threat to social order when there's a global crisis. Going FAB-less may sound great today, when you make the committment.. not so good tomorrow when you can't buy FAB resources anywhere. ARRGH! A while back I did a board-board interface using the MAX9122/MAX9123 using CAT7 cable for use with the "high-speed" PMODs. At least the receivers have integrated termination and the footprints are easy to work with. I didn't try anything like 500 Mbps/channel. Now there are very few logic component vendors ( ADI has gobbled up most of the old ones ) and fewer design options. It's one way to overcome the stupid mistakes ( or perhaps purposeful since Digilent has never corrected them ) of those *** "high-speed PMODs though... if your PMODs have at least one clock-capable pin. You might find that the limited PL resources in the XC7Z010-1CL coupled with a limited DDR performance isn't really the platform that you want to struggle with for your project. Unfortunately, this is a really bad time to buy cheap FPGA boards, or devices, or well... anything. If you can find it the price is double or quadruple what it should be and that's from nor so reputable sources making the investment extra dubious. Well, we gotta do with what we got when we need to get things done... The Mimas A7 might be a better platform. It comes with 3.3V supplied to the IO Banks connected to the headers but you can turn that into 2.5V with just one resistor change. I've done that and it works. Don't know if you can buy any at any price currently. FMC mezzanine card PCBs are not trivial to do but might be a better option. Paired with a Nexys Video or better yet Genesys2 your interface would be a lot cleaner and straight-forward as you can use LVDS_25 or lower and internal termination. Working in your favor is the IDELAY feature that will allow you to compensate for mismatched pairs of differential signals in wider busses. Do understand the material in the Series7 clocking reference manual and any relevant information in the SelectIO reference manual as you plan out such a board... if that's an option. Perhaps you can trade in your dinghy for a more sea-worthy vessel. The Intel/Altera ( shouldn't these marriages end up with hyphenated names? ) space is kinder to the kind of projects that you want but alas the low end parts that the free versin of the tools support are hard to come by, as are the development boards sporting them. A year ago you could have purchased some decent sized MAX10 devices at a reasonable cost and created your own FPGA board with an interface to your image sensor. I have a couple of MAX10 project on hold because distributors claim no knowledge of such a device now. Hey, I've spent the last 30 years trying to make programmable logic development boards, purposefully designed to have limited capability and having unnecessary design errors, that I can afford ( a few that I couldn't ) perform feats that they were designed not to do but that I needed to get done. Rube Goldberging isn't pretty.. but if it gets the job done, pretty isn't terribly important. Almost always starting off with a platform that allow you to express your design intentions ends up saving time and money, even when the initial cost iis above your budget. Thanks for the story... been there... many times.

In general the advice that your refer to is correct... assuming that the _p/_n pairs are routed out on the PCB as true differential pairs. In this case coupling is a desirable feature of differential signalling. I don't have your board but the many Digilent boards that I do have show no evidence of having the signal traces being routed as differential. I've used the differential PMODs on the Nexys Video, Genesys2, Genesys, Zedboard at 50 mbsp for single-ended signalling without noticeable cross-talk data corruption. I have taken advantage of the 10 mil _p/_n length matching in those designs. 500 Mbps is another animal, especially for single-ended signals. First of all, did you check the ZYNQ datasheet for your device and speed grade to confirm that the FPGA can deal with such data frequencies? Even if the clocking resources can deal with such rates ( 500 MHz is near the top end for low speed devices ) internally that doesn't mean that you are guaranteed to close timing on a real world design... especially using an external signal toggling at 0.5 GHz. But that's only half the battle. You won't likely be able to create a transmission line suitable for such a signal as any terminate will be situated in a less than optimal location and you have no control over signal integrity characteristics over the whole signal path. 500 Mhz is pushing the capabilities of the PMOD headers alone; then add other factors and you are in trouble quickly. Even with connectors designed for high-speed signalling like FMC and having internal termination for supported IOSTANDARD differential signals ( your board doesn't support this ) you are pushing your luck. Even if you manage to get a usable signal into your FPGA how are you going ot use it? You aren't going to over-sample a 500 Mbps signal for asynchronous operation so this means that you need a clock capable pin in your interface so that your add-on board can implement a source synchronous interface. Digilent doesn't specify maximum length differential between _p/_n pairs for its boards ( but they will provide that information if you ask ) Before rowing your boat off shore it's wise to check for leaks.. that is do you due diligence before making decisions that can't be unmade. As to connecting FPGA pins that are connected to true differential signals; when you drive the _n pin to ground in your design this happens inside of your FPGA. This prevents cross-talk between single-ended signals on differential pair pins but does nothing to assist with a design that involves connecting an external board. Unfortunately, this technique halves the number of available GPIO on a board that's already been set in stone.

I've read the linked content. In the interest of clarity and and honest advertising Digilent needs to provide more information. It already does this with it's Zmod boards. The HW that Digilent uses in it's (relatively) high cost instrument product are not doing anything novel or patent worthy so why not just explain how you actually implement what you coyly, and misleadingly, refer to as an oversampling Fs. And fix up the wording on any advertised specifications so that any potential user can understand what they are buying. Considering the cost of these instruments relative to the Zmods ( and It's reasonable to assume that they share the same circuitry ) they would seem to deserve the same, or at least similar, level of documentation That's all I'm suggesting. BTW in the linked documentation the 25 MHz clock graphically rendered example purportedly demonstrating the difference between 125 MHz and "oversampled" only serves to raise questions instead of serving as an explanation. There's certainly a place for this class of instrument considering the substantial added-value engineering that comes with them. It's that added-value that makes them worth buying... but only if the customer gets what they are expecting after reading the advertisement and available documentation. I can't see the down side to being completely up-front about the details that are need in order to evaluate a potential purchase.

The standard PMODs have 200 ohm series resistors as a level of protection for the FPGA. This limits the usable bandwidth for any signals on their pins considerably. The so called "high-speed" PMODs don't have these and thus higher capability as individual pins. If you are comfortable using an HDL what you want to do is pretty easy. Create a source and assign it to one of the 'high-speed" PMODs and create a sink and assign it to the other 'high-speed" PMOD ( assuming that you have one of the boards with 2 of these ). Be sure to simulate your design first. For source-synchronous interfaces you will need a clock capable pin on the sink PMOD. Such a design where both the source and sink use a related clock isn't very useful if you want to use your experiment as a starting point for connecting an interface from an external board. Digilent boards come with a very limited supply of external clocking sources bt generally you can find 2 somewhere in the schematic. If you want to study an example of a board to board interface that's already been done you can look here: https://forum.digilent.com/topic/20479-inter-board-data-transfer-project/ The Digilent forum sections are pretty cluttered with extraneous postings so it's not easy finding ready made projects with source code; still it's worth looking around. Digilent makes FPGA boards supporting their PMOD ecosystem, not FPGA boards for the kind of projects that you want to do. There are better options available ( well, perhaps not at the moment as the world supply chain is completely broken ). Personally, I like the Terasic DE0 Nano as a general purpose FPGA platform that can be incorporated as a dedicated component in a custom design or as a board for this kind of project. It's Cyclone IV based so you have to use Quartus. Recent version of Quartus are completely broken if you want to use Intel high data rate IP like DDR/LPDDR2, but the Nano doesn't have any resources requiring Intel IP so it's well suited for any pile of doodoo that Intel releases as a tool version. Altera ModelSim is superior to Xilinx ISIM as a real world logic simulator( though it's so old that it doesn't have the right to be ). Trying to teach the old-dog FPGA board that you have in hand to do something that it's wasn't design to do is usually just an exercise in frustration. For about 2x the cost of the DE0 Nano the Cyclone V GX Starter Kit is a nice alternative and you might actually be able to find one to buy somewhere ( I just did ). It has a 40-pin GPIO header and an HSMC header making it particularly useful for a variety of projects. The LPDDR2 is almost useless as the tools don't support burst operation. Be aware that most electronics like this are unavailable or cost 2X-4X what they should... it's supply and demand without cost controls.

When you advertise a specification the words that you use are important in order for a prospective customer to understand what it is that they are buying. Historically, companies presenting products that do funky things to increase Fs specifications would use terms like 'equivalent time sampling' to indicate that something different is happening with their product in a particular mode. It would be entirely reasonable for a customer, or potential customer, to assume that 0.5 GS/s oversampling refers to an actual Fs at the sampler. It certainly wouldn't occur to the not-so-sophisticated customer to even ask what that means. If the specification referred to 0.5 GS/s Equivalent Time Sampling, then at least this might prompt some questions. When something is sold as an instrument it's entirely reasonable for customers to draw inferences to specifications for high priced instruments of a similar function. In the context of these instruments 'oversampling' has no real meaning but is likely to be misinterpreted. As it turns out, even 'equivalent time sampling' isn't very useful as there are a lot of ways to do that, not all of them particularly useful. So, more information needs to be provided. Let's say that a company offers two oscilloscope products. They both use the same sampler, but different speed grades, and the same sampler analog front end. I contend that the performance of the product using 1 sampler at Fs=500 MHz is not equivalent to a different product using 4 samplers at Fs=125 MHZ. Moreover, how the 4 sampler product implements it's clock management matters. If control IC ( let's says that it's an FPGA ) outputs 4 separate sample clocks to each of the samplers, that is quite different than if it outputs 1 sample clock to an external programmable clock generator device with phase control over individual clock outputs, each going to separate samplers. This scenario is part of the analysis, but still indicates that more information is needed in order to avoid misleading advertising claims. The top commercial instrument vendors provide detailed performance specifications and in general have good application notes for customers wanting to interpret those specs. Their performance is usually generally commensurate with the cost. ( at least there was a time when this was true ). Part of the high cost is not only performance verification but meeting a lot of EMC and other requirements. Seasoned engineers generally have some level of expertise to make a reasonable purchase choice given the proper amount of information. Other people aren't as fortunate. The low end instrument market is a black/grey area where guaranteed specs are traded for a lower cost. This isn't so obvious to everyone. If you are going to market inexpensive products to an unsophisticated public then perhaps you can dispense with detailed guaranteed performance specifications, but then, I believe, that you need to be more careful about causing confusion, intentional or otherwise.

Perhaps you should ask how Digilent achieves and defines 0.5 GS/s oversampling; and even more importantly, how they measure and validate this, and what effect it has on ENOB and noise. This is concept that has been around for low cost scopes and digital analyzers and has been much abused. Few companies using it actually provide enough information to allow prospective users the opportunity to evaluate the claims.

It means that you get to create your own pseudo-random number generator. Creating an LFSR in logic is fairly trivial. Creating the proper LFSR for a particular application is not so trivial. Blindly relying on a rand() function in hardware or software to be appropriate is risky. There are only a few hardware number generators that claim to be random. The rest are pseudo-random at best and not necessarily appropriate for every application. I (think) that the Xilinx standalone OS has a C/C++ version of rand() if you don't want to create the ideal one in hardware. If you are running Linux on your Eclypse-Z7 then you have more software options. Advertisement claims about products and device capabilities are frequently optimistic and sometimes just plain incorrect. Even when correct in a particular context they can be open to misinterpretation by customer, whether intentional or not. Users can't make assumptions. This is true for everything that can be purchased. Some markets are worse than others; ADC/DAC devices, low cost FPGA boards, storage devices, etc.

The best way to do this would be to bypass the Digilent DAC1411 AXI controller IP and control the DACs with your own PL design. You can still use their low level controller IP to simplify your project.

You can monitor the FPGA core temperature in your software applications to see if that's an issue. I've seen similar problems due to AXI bus faults. In this case you have to power down the board and start over. Certain Xilinx AXI IP can have bus faults if the PS core tries to do read or write accesses too fast. The AXI GPIO IP has this issue. You can insert usleep() calls between accesses to see if this resolves your problem. This slows down the AXI bus transaction. It's a crude method but might work. The PS cores on all Series 7 ZYNQ device are fast enough to expose buggy IP. I don't know that a bus fault is your problem but this is hard to debug as the tools and the device stop communicating once a bus fault occurs.