zygot

How do the ADxxx instruments achieve sample rates of, say 10 KHz? Is this the sampler clock frequency? Is the ADC clock fixed and samples are thrown away? Some combination of this?

What does the schematic tell you about Vccio that powered the IO bank for the pins connected to JA and JB? What does the Series 7 Select IO User Guide tell you about the available IOSTANDARD types that can be used for signals connected to an IO bank powered by Vccio for the Genesys2 PMOD connectors? @artvvb, It's easy to fix documentation mistakes, so why won't anyone change Digilent's habit of telling users of their boards that PMODs can be used for differential signalling when they can't? I've only been trying to get Digilent to stop this for about 10 years by now... and this is obviously a common problem of confusion.

For the original AD1, Digilent provided an excellent write-up of the hardware design that allowed users a chance of figuring this kind of information out for themselves. I have been unable to find equivalent information about the AD3. In recent years Digilent has been moving toward more opacity and hiding more of the important details that are important for certain applications. Perhaps, someone at Digilent will point you to an AD3 theory of operation document that will suffice. In general, Digilent products are geared toward general purpose use cases. Sometimes, someone who knows what the right questions are, for their application, post them to the forum. Thanks for doing that. I'm looking forward to the subsequent exchange. Details, details... can't do much without covering the details.

I know a few people with better credentials and more focused objectives who would disagree with that assessment and found the Arty A7-35 to be enough to keep themselves busy for quite a long time. If your background is software, be prepared to re-invent yourself in the world of programmable logic. Seriously....

A lot of FPGA devices come with embedded ARM cores ( actually, for Xilinx it's more like ZYNQ has ARM cores with a connection to programmable logic ). Do you want to do software development or learn logic design and development? This is important because a ZYNQ device just complicates the development effort ( you have to do a HW stage and then a SW stage using different tools ). There's a steep learning curve to using both the HW tools and SW tools. If you want to learn "FPGA" I'd advise starting off with an FPGA device with no ARM cores. If you want to do software development, then why do you need programmable logic? I'm just trying to suss out what you are imagining that you are getting yourself into here.

Your budget limit is the controlling factor here. But let's back up a bit. In order to learn FPGA development the same advice applies to every one; you don't need to spend any money to do this. You can spend a good year reading the AMD/XILINX documentation, learning how the devices work, how to use the tools, how to use an HDL to create designs, how to simulate designs, etc, etc. I'd interpret your use of "programming" as an indication that you are short on knowledge about how programmable logic works and what's in it. This not a good position to be in when spending money. Until you have a specific purpose in mind, forget about IO and "most powerful". Figure out an objective first. Before you can do that you need to have a good sense of what's involved in getting to that objective. Take my advice and learn the basics and tools before setting objectives. You can make better decisions in that position. Self-education is going to require some effort, so start off willing to put in the work. What makes an FPGA suitable for a particular purpose is the internal resources and IO capability. FPGA devices in higher speed grades and having more resources cost more money, no surprise there. Then there are the IO. For using advanced IO features like LVDS, SERDES, transceivers, etc. the cost is in the board design. The PMOD ecosystem is for low performance IO. SYZYGY, FMC HSMC, PCIe, etc, is for high speed IO. You pay a good premium for being able to use these, and connecting FPGA carrier board connectors to add-on boards is well beyond your budget.

Most USB UART bridge devices top out at 3 Mbaud. The FTDI devices with an "H" can do 12 Mbaud using D2XX drivers. You might find this tutorial interesting: https://forum.digilent.com/topic/24531-debugging-with-the-ftxxxx-mini-modules/ FTDI has a number of application notes that help explain the usage of of the VCP and D2XX drivers. Most OSes enumerate USB Bridge devices as COM or TTY devices which have a limited range and number of supported baud rates.

Good questions, and someone who works for Digilent should be giving you a reasonable answer since they designed the original board and later revisions, or had the board designed for them. I can only speculate as to what their goals were. It's entirely possible that the faster memory part just happened to be the cheapest one or only one available when the parts for the last board production run was ordered.

When incompetence is rare, random and quickly addressed then I certainly see it as an honest mistake. When it's endemic and there's a general refusal to address mistakes, especially when they tend to be in favor of the selling party, then I tend to need some convincing evidence that that it doesn't exist for monetary gain. The appearance of Incompetence is sometimes a used as a cover for bad behavior. The Digilent engineers who post to the forums are certainly capable of separating fact from fiction. I'd be surprised if they create marketing content. So, do I expect that what gets seen by consumer eyes to be factual and not misleading? Yes, especially when the primary market is consumers who are not able to know how to figure all of this out for themselves. You have pointed out 2 issues in the last couple of months and Art has resolved them quickly. That's great! I've been pointing out similar misrepresentations over the past 8 years or so and largely they've been ignored. It's not about me, who has no excuse for being mislead by confusing or blatantly incorrect information expressed as official Digilent marketing or documentation. It's about people who don't have the knowledge to protect themselves. Do I expect a company like Digilent to care about those customers as much as I do? Well, yes I do. I'm not talking about things like sloppy, non-professional documentation that sometimes creep into things like user guides and master constraint files here. I'm talking about things that make a company that have the appearance of being a less than trust-worthy company to do business with. I've bought an awful lot of Digilent products over the years. I'd like to continue to do so. I'm not accusing anyone of fraud or malice. I'm just pointing out that there's a simple way to convince everyone that those intentions aren't at work. Frankly, I we shouldn't even be having this discussion. If I were running such an organization it wouldn't be a continuing issue that reflects badly on its engineers who, I believe, are really just trying to do their job as best the can, given the environment in which to do it.

Python is a general language and is currently a lot more popular than C which is my preferred language. OCTAVE and Scilab are attempts to provide users with a free alternative to MATLAB. These are not general purpose languages, per se, but tools for simplifying all sorts of complex problem solving in the "DSP" realm or otherwise. Still, using Octave, MATLAB or Python ( the non-compiled varieties ) is very similar. OCTAVE/MATLAB, as has been mentioned incorporate visualization as a more fundamental part of its core. What you get with OCTAVE or MATLAB is the ability to do hard mathematical problem solving with minimal mathematical competency; basically it abstracts most of the hard stuff away so that you can work on a higher level of conceptualization. Of course, sooner or later if you will be doing this seriously, you will have to develop an understanding of the underlying principals. It's very similar to using Vivado. Because it's so popular you can find free libraries in Python that simplifies complex mathematical solutions in any field of science that you can imagine. Be aware that because it's so popular Python is currently subject to supply side malware attacks. Finding similar support for the same mathematical tools is harder to come by with other languages, at least for no cost. There are languages specifically designed for science, like R. If you want to learn "DSP" as it relates to communications, filtering, video processing, or whatever area interest you, these tools are the best way to do that. Once you have some idea as to how to implement DSP algorithms without worrying about arithmetic and number base representations you can start thinking about how to implement high level algorithms in digital logic; in logic you will need to know a lot of very low-level details to effectively implement complex algorithms. I use OCTAVE and Python extensively. Python is less concerned about math and science and more of an alternative to C or Fortran. To my constant consternation, Python, uses array indexing from 1->n instead of 0->n-1, like C does. It's a real pain for modulo arithmetic, addressing and counters which are a lot easier to implement in digital logic. Oh, Python , OCTAVE, and MATLAB are used in interpreted form as opposed to compiled executable form so they tend to be a bit slower. There are people creating Python-like languages that are used in compiled format to speed it up. Recently, the people who maintain Python has been working on integrating performance into the language. [edit] last thought on Python. People even use Python to do FPGA development. Do a web search on Migen. I'm not suggesting that learning Python should be something that you need to work on, but seeing how people use it might be an interesting short-term pastime. As far as Migen and all the other attempts at making FPGA development simple and easy to understand, I'm not a believer... but there are a few interesting demos that have some people interested. There have been a lot of attempts at making logic design simple.

You mean like the PC CPU/GPU industry? It's all relative. Virtex, which can easily be in the $50K+/unit price range, isn't cost optimized. It's also not for customers who care about cost. Digilent isn't going to be selling a Virtex 7 or Virtex UltraSale+ board anytime soon. Digilent isn't going to selling a board with anything from the higher end of the "cost optimized" portfolio. Digilent isn't even going to be selling a Artix UltraScale+ board. Digilent does sell the Genesys2 with a -2 Kintex 325T. In low quantities these are more than $800 a pop. No doubt that Digilent gets preferred pricing for those devices. KIntex isn't cost optimized. Is a -1 Kintex 160T better than a -1 Artix 200T? I suppose the answer depends on what you want to do with it. GTH transceivers are certainly better than GTP transceivers, if your board lets you take advantage of them. What I don't find particularly humorous is that the free version of VIvado support the following Kintex, Kintex UltraScale and Kintex UltraScale+ devices: XC7K70T,XC7K160T,XCKU025,XCKU035,XCKU3P and XCKU5P. Quick, name all of the reasonably priced FPGA boards with one of these that you can buy today. I know of a couple of XC160T, and these aren't cheap. How about Artix? Quick, name all of the boards with a XCAU10P,XCAU15P,XCAU20P or XCAU25P, other than Opal Kelly ( assuming that you happen to be lucky enough that they have any ready to ship to you with a delivery date upon order ) that you can buy. It's always been the case that "cost optimized" means whatever FPGA vendors want the phrase to mean. I the past FPGA vendors have always wanted to be in the commodity or low cost programmable space. I believe that those days are, for the most part gone.

I don't know what you will be telling people who ask about transceivers, but here's some context. Before Series 7 devices, a T in the family device part number meant that it had a transceiver. So you could buy a board with the XC6SLX45T and knew that the device had GTP transceiver(s), even if the board didn't. You could also buy a board with a XC6SLX45 device and know that it had no transceivers. For reasons unknown, when Xilinx released the Series 7 product line, it decided that it would be less confusing if all family part numbers would include a T in the product number, whether transceivers were available or not. I suspect that it's cheaper to make all of the devices with transceivers even if you have parts in packages that don't provide them to pins or balls. AMD/Xilinx currently has a different cost optimized product selector guide that shows this ( separate from its Series 7 version ) that includes the Spartan6 through Ultrascale families. At least AMD is careful to include the fine print that says, and I quote: "Important: Verify all data in this document with the device data sheets.". This is splattered all over most pages providing an overview of the part capabilities. By the way there are no Spartan 7 "T" devices and no transceivers on any Spartan 7 device. So, that's where the confusion comes from. Then there are product vendors using these devices who really couldn't be bothered with figuring out if what they are telling potential customers in their advertising is true or not, even though whoever designed the products certainly knows. Is this what you will be telling people who keep asking why they can't get access to GTPs? So, Digilent has gotten customers posting this very question, to Digilent's forums, about how to use the transceivers in their CMOD A35T ( since at least a year ago ) and no one has thought that perhaps they should change their marketing to clarify that no, you can't use the transceivers on the CMOD A35T or most of their other Series 7 boards. @asmi you should feel special, because at least someone at Digilent is "proactive" when you point this out. @artvvb, if you really care about whether or not your company is misleading its customers with its promotional documentation and demo links, all you have to do is spend more time pretending to be a customer and reading what's in the links to Digilent products. Evidently, fixing errors isn't a big deal.

Why does a customer have to call this to your attention in order to get misinformation corrected, in a piecemeal fashion? Someone at Digilent should be doing this, hopefully before it appears on your websites. Isn't anyone who works for Digilent embarrassed enough to want to do this instead of waiting for a forum post?

Quite a bit. Spartan 6 has a hard multi-channel external memory controller, Series 7 makes you implement it all in logic resources. For small devices this can be significant. In a few metrics Spartan 6 is superior to Artix. Artix has more memory and a better clocking resources. That's only a few differences. It all depends on what you want to do. Same advice for choosing an FPGA board applies to selecting an FGPA device; do you homework. I doubt that designing a new product with Spartan 6 would be a very good move.

I doubt it. Between the hardware description file that Vivado produces and gets exported to the software tools. creating a BSP, adding library support for hardware, and the standalone libraries there's a lot of room to swap references ( like uart0 and uart1 ) and generally introduce confusion by each of those pieces of the process... and Xilinx, in my experience, seems to dislike missing any opportunity to confuse its users. Until you get used to the tools and their quirks, and there are a lot of quirks and bugs, you just need to simplify and carefully manage ( check ) everything that's produced by the tools. My approach to ZYNQ is not appropriate for most people. I put all of the hard stuff, timing dependent functionality into the PL and make the PS as stupid as possible. I don't use the drivers and library functionality ( to the extent possible ) for controlling simple hardware like UARTs. I avoid interrupts to the extent that is possible. Really, the PS cores are plenty fast enough for a lot of applications. I write code as if I were programming a micro-controller in C. I read about the hardware, learn what registers are available and what the bits mean. For me this is easier and ultimately quicker than banging my head against the opacity of the tool libraries. (actually, you can work out exactly what the libraries are doing if you have a LOT of time on you hands. ) Basically, it comes down to this. If all you want to do is replicated simple demos or the functionality of the libraries is good enough then the tools, as they are, can be a quick way to do something. If you want to do something that's substantially different than the pre-baked cookies that the tools provide ( VIvado or VItis ) then be prepared to do some heavy lifting just to get to a point where you are productive. I have no doubt that many people will disagree with this opinion, but it's as good as I can provide. Figure out how to slay the dragon, or it will slay you.

If you can't afford anything that's available but are determined to buy something now , regardless of any rational, ... the Cmod S7 lets you do complete FPGA development right through learning how to do timing closure. If you can find a cheaper FPGA board that works with Vivado Hardware Manager, then buy that one.

Digilent has been doing this since the Genesys Virtex 5 days. Who'd make a Virtex FPGA board and not allow users access to the transceivers? Oh,Oh... I know... Never never buy technology without doing your homework. Sometimes, this is a LOT of reading...

Along the lines of over-promising marketing, you only need to read one document to be confused. If all you look at is the 7 Series product selection guide, Xilinx tells you that every Artix device has a PCIe Gen2 block and 6.6 Gb/s GTP transceivers. Of course, if you keep downloading more documents you find that not all packages have MGT banks or transceiver pins, or that PCIe Gen2 with a maximum data rate of 3.75 Gb/s or without any transceivers isn't possible. That's no excuse Digilent.

As for Select IO pin being "probably good enough for most purposes" I'm flummoxed by that statement... it's just so wrong in so many ways. If connecting PMOD headers to PMOD boards is "good enough" then, yeah perhaps this is correct. As for the confusion with the 6.6 GB/s GTP transceivers. The maximum rate for Artix GTP transceivers is 6.6 Gb/s, but this is only for speed grades that don't appear on any Digilent Artix FPGA board. One might be tempted to assume that that this is an innocent mistake... reading the wrong Xilinx brochure. The problem is that suggesting a capability that isn't a possibility for their products happens way more often than one would think that simple mistakes are involved. The problem is that Digilent sell cheap boards to a mostly student or hobbyist clientele. Asmi, knows the answer to his questions because he knows to read the schematics and is familiar with how many Xilinx documents it takes to really know what you can to do with any particular FPGA device in a particular package. What kind of company tries to take money from kids in exchange for promises that can't be kept? Are students supposed to find all of the relevant documentation to figure this out for themselves? Professional engineers? Yeah, if you buy something that can't do what the advertising says ti can do, then shame on you. But students who can't afford textbooks? Really? With respect to vias that have no purpose; surely even Digilent does automated PCB connectivity and short testing. ??

Who should do this? Governments? Consumers? Industry Trade Associations? Corporations? Does anyone care, other than short-term profit motivated executives? I think that small vendors who's products use programmable logic care. Their customers? Perhaps not... now.... The point of this thread is that perhaps more people should care, even if they can't connect the dots between their interests and the interests of a very small group of people who's decisions affect a huge part of the global economy, either directly or indirectly. The once high-flying Intel Corporation may not even make into the 3rd decade of this century as an independent entity. Their motivation for Software Defined Silicon isn't too hard to suss out. But even if SDSi comes to fruition, what do people who's businesses are affected by the interests of AMD and Intel, and their customers think about the immediate impacts of decisions by companies who aren't interested in serving their needs? Obviously, this thread is mostly a philosophical discussion, but one with very practical implications. No one knows the future with certainty. Not thinking about the future, may not be good for anyone.

The Zybo is one of the few ZYNQ boards that make the 2 PS UARTs available to physical pins without going through the PL. Sometimes the BSP swaps the UART references and causes confusion. This has an impact on the supporting libraries. It can get confusing. Fortunately, all of the relevant hardware related information is available in text format ( at least in the pre-Vivado2019.2 SDK... honestly I don't about Vitis; I've only used it for Linux operation. The first thing to do, when confronted with unexpected behavior is to make sure that all hardware addresses, and software assignments are in agreement about what they are referencing. I typically have the xparameters.h, and hdf ( SDK ) files handy for viewing. I'm a hardware guy so I personally would rather use PL UARTs implemented in logic as I know what's going on and can easily debug issues with an ILA if need be. I don't typically use the Xilinx standalone libraries for things like UARTs. I'd rather use a C-style pointer coding style. If the ZYNQ is running Linux or an RTOS, then I have to abide with the rules of the OS. Do make sure that both of your UARTs are set up properly and aren't stepping on each other. The Xilinx software tools want you to do thing their way. You might find that reading the hardware description for PS UARTs and understanding the registers is a better approach. I can't advise one way or the other because everyone has a different development flow that they prefer. The JTAG and UART USB endpoints are enumerated as separate devices by your host PC. The Zybo reference manual claims that you don't have to worry about either interfering with the other. I'd disagree since I've experienced just that using an ILA while using the UART port at high baud rates. Anyway, the two devices are separate; the fact that one is working doesn't imply anything the other. If your host OS isn't seeing one of them as the appropriate device then you've got problems. There seems to be a LOT of UART related issues in the past year or so posted the Digilent's forums. I don't know of Win11 is the culprit, or bad drivers, or some other thing is the cause. I use Win10 and Linux as hosts and generally don't have connectivity issues for my FPGA board. I also don't let Win10 automatically install drivers. I can't tolerate wasting time with petty UART issues cause by other peoples tools or decision making. There are a number of cheap USB TTL UART cables and breakout boards available. I use these a lot since there's no fuss, once you figure out how to use them. Even for non-FPGA work, like the OrangePi that has a UART running at a non-standard 1.5 Mbaud rate these things come in handy. Control what you can so that you have more time killing bugs... and hopefully a bit of time actually doing development work....

It's hard to say if this is a bug ( Every new version of Vivado introduces new bugs, but doesn't necessarily fix old ones ), or user confusion. There can be conflicts with setting AXI space starting addresses and size, but the tools should detect and prominently prevent you from completing your board design until errors are fixed. I've seen really obnoxious errors with clock frequency specifications ( stupid stuff like round-off differences to the 3rd decimal place ). The only way to deal with such things to so figure out how to avoid them. Sometimes you have to re-open an IP or board design after thinking that everything is OK to see that actually there is a problem. The tools are overly complex, especially the GUI tools. It's not uncommon to spent hours debugging the tools, thinking that it's the design. Usually by the time I see weird behavior for the 3rd time or so I get the message that it's the tools, not me, that's the problem. I've never encountered an AXI bus fault producing PS UART failures. Generally these have a much more dramatic ending to a software debugging session that involves a power cycle and reconfiguration to move forward. I can see having data problems with the PS UART and faulty AXI bus behaviors, but not the UART just not talking. Aside from checking connectivity of the software console, if you are using that, you make sure that the OS is still connected to the USB UART device. UARTs don't stop working. UARTs garble data if there's a baud rate problem. USB devices stop working on a host if the device gets detached for some reason.

This argument is certainly debatable. Certainly there have been users reporting problems getting expected performance and use a RPi, which is a supported host. I do a lot of USB work involving FPGA-PC connectivity, on a lot of different host platforms. In my experience the capabilities of the host as well as the OS, OS version, and other details do have a significant impact on performance. For USB 3.0, even the driver/OS combinations can be problematic. The major issue with USB is variable latencies, because USB is so tightly coupled to software support being involved in data transport. It's really hard to quantify USB performance for a given host. The basic concept of a large device buffer absorbing random latencies is OK, the problem is that, obviously, it's not sufficient. My sense is that the reason for buffer overflows in the device for long data streaming sessions is due to the host not being able to drain data fast enough. I may be wrong about this. I'm betting that a lot of AD3xxx users aren't using high-end PCs with lots of available memory not taken up by the OS. Obviously, streaming 8 GB of data into memory on a host with only 2 GB of available memory is going to be a problem. For Ethernet, data transfers use DMA both in the device and host end. I'm guessing that the 70 MB/s limit here, where something closer to 120 MB/s might be expected, is due to the device architecture, not the host capabilities. There are two basic ways to deal with data transport issues. decouple the host from the instrument. This would mean that the instrument would either do everything, like an oscilloscope or waveform generator, without involving the host. That means a lot of potential storage capabilities in the instrument, less customization and certainly a higher cost. Allowing the user to pay for optional storage capabilities would make marketing simpler. If an instrument design can't accommodate "infinite" data acquisition or waveform generation, however you choose to define "infinite", then simply proudly advertise that the product doesn't support such a mode of operation. That's the simplest solution. However Digilent deals with marketing it's products, and this includes videos and demos that suggest use cases and performance that Digilent might not want to specify as guaranteed, one thing is for sure: customers who buy a product with an expectation based on what they read from the vendor and then get a product that can't perform to expectations are going to be unhappy. The real question is whether or not National Instruments cares about their customers or it's own reputation. Some customers are corporations or entities with a significant budget to spend on equipment. The ADxxxx line of instruments is, largely due to the efforts of Atilla and his colleagues who supply really good responsive after the sale support, are fantastic niche products. It's this support that makes the products unique. As to whether the performance of the higher cost AD3xxx products represent enough "bang for the buck" justifying their cost, well that's up to the individual customer. Customer's can't make that analysis without clear performance specifications. For test instruments costing $50-200K clear guaranteed specifications is a requirement if you expect to sell anything. This costs money which then drives product cost. The Digilent AD3xxx instruments are a special class of low cost, but not insignificant cost market where you can sell stuff without the testing and hard specifications. That doesn't mean that you can abuse customers with impunity.

! doubt that anyone will post that argument since AXI busses are the only possible way to connect the PS and PL in a ZYNQ device ( well except for the EMIO but that is limited ). Now, for logic completely contained in the PL, or for designs completely contained in logic... that's a different matter. I may have misread the problem, but it seems to be related to setting AXI address spaces, which is done in Vivado which produces the HDF file ( or for Vitas the xsa fie) , not the software tools. I'm thinking that problems with the PS UART are not AXI related. ARM UART blocks are a bit limited in terms of FIFO storage and flexibility. I don't know how much VItis or SDK work Dan has done, but I sure agree with the OP that ZYNQ development, and using the tools can be overly complicated, especially to someone learning how to use the tools and the architecture at the same time. The easiest way to deal with the Xilinx software tools might be not to use them. Any ideas on that? I've not used Vitis much but console in the software tools can be set to connect to a USB UART device, in this case other applications can't use the same device. Before freaking out about the possibility that the HW has failed while using the hardware in the software tools, make sure the the connection is still valid. Personally, I prefer using Putty connected to my PS or PL UARTs instead of the software tools for a variety of reasons. For one, you can use a higher baud rate than 115200 that way. For another, the software tools get confused and it isn't always easy to see that a UART is no longer connected. This might just be something that plagues me tho...

So, you are saying that 1600 MB over USB 2.0 or 2800 MB over Ethernet is a guaranteed gap free session for streaming ADC samples as long as the total sample rate is 20 Msps for USB or 35 Msps for Ethernet? Do you have an example of this for Ethernet? The only practical way to test for gap less data collection is to use the ADC triangle test waveform. It's hard to tell from the screen grab. You don't provide any information about your host, like PC, OS, memory etc. Since this is part of your instruments, I'd imagine that performance has a dependency on such information. Certainly a RPi4 wouldn't be expected to provide the same results.