zygot

Jcolvin: "though the naming convention (perspective of host computer as the DTE) isn't always ideal." UART signal directionality has always been a confusing mess. Between cables with different number of pins, confusion about which equipment is DCE and which is DTE, one needed a drawer full of adapters, and cables, and gender changers to switch in/out signalling, just to connect PCs or equipment together. Picking a schematic signal name that clearly identifies directionality isn't hard to do. Digilent just has never chosen to do it. Using schematic/constraint references in the board reference manuals isn't hard to do either. The problem with Digilent board UART documentation, like many other aspects, is due to the disorganized way that Digilent does design and support for its products. At least it's consistent with the UART signal names, confusing as it is.

The Genesys XU-5EV has one Vadj rail out of its power supply design. It has two interfaces requiring Vadj; 1 FMC and 1 SYZYGY. The concept of SYZYGY is that the carrier board is supposed to supply independent logic supplies for each SYZYGY port that it has. SYZYGY has a negotiation protocol between the carrier board and each SYZYGY pod that allows the carrier board to set each Vadj in a way that is within the limits of each pod and the capabilities of the carrier board power supply. This implies that with a number of different SYZYGY pods you aren't guaranteed a specific Vadj for all of them, just that itmight be possible for some combination of Vadj voltages to accommodate different pods at the same time, FMC mezzanine cards might have an EEPROM or not. There is no DNA protocol for negotiation of Vadj rail voltages. Not all FMC mezzanine cards for FPGA boards closely conform to Vita standards. The fact that Digilent conflated the SYZYGY and FMC interfaces with into one Vadj may well be problematic if you need to use both an FMC carrier card and a SYZYGY pod requiring different Vadj voltages. This is something to consider before making a purchase. Another thing to consider is that IO on UltraScale devices is not the same as on Series 7 devices. Even DDR is more complicated and is dependent on vendor IP and behind the curtains vendor tool software. Before considering UltraScale for a project I highly advise reading though the UltraScale IO documentation.

So there it is. Asmi has produced the definitive answer to the Digilent FTDI configuration/UART mystery. If you want to make your own FPGA board design you don't need to license anything from anyone. If you buy a Digilent FPGA board, you deserve to have complete schematics. Bookmark this thread. May this little "scam" rest in peace.

The Zmod DAC Reference Manual uses a ZMOD ADC to create what it publishes as the board's "spectral characteristics". This should tell you something. What you are measuring over the usable published bandwidth of the AWG is almost all below 100 dBm. Is this anomaly really a problem for your needs? Anyone who's spent some time reading over the "spectral characteristics" of DAC and ADC converter devices... not complete converter circuits with high/low range and multiple variables... can see what lengths and games the vendors go to to make their devices appear to be as "pretty" as possible. It's really a long running game. Of course, it's possible that your application needs to take into consideration a very careful analysis of how the hardware and logic interface for your ZMOD behaves over a bandwidth of interest. Sounds like a good student project with lab and simulation exercises... and a lot of time. Start adjusting the variables and continue your tests. I'm pretty sure that you'll have more questions to ask about why you are surprised about your measurements. This ADC/DAC stuff is complicated.

No, I'm not frustrated with you asking the question, I'm frustrated with Digilent's lack of honesty and responsibility in dealing with a problem that keeps appearing so often in their forums. But do search the forums for posts about this topic as you might learn something interesting and useful. Only I can waste my time, though on occasion I get suckered into an exchange that I'd have avoided if I knew how it would evolve. Even then, it's not a waste of time, just an avoidable episode. No one makes be spend the time to post to threads, though a few people have tired to prevent me from doing so. Your post doesn't fit that category. Once upon a time, Xilinx and Digilent had a key relationship. Digilent provided cheap design resources for Xilinx or distributor FPGA boards, and Xilinx used Digilent's JTAG interface, even incorporating it into their tools. Both the times and the companies have changed since then, though the tools still recognize a "Digilent JTAG". Altera had it's Byte Blaster in various forms that for a long time is based on FT2xxx bridge devices. There are a lot of issues with Windows or Linux getting confused between a "Byte Blaster" interface and an COM device. Mostly, the problem can be traced back to FTDI; now that's a company that the terms "bizarre and paranoid" might be connected with.

For the umpteenth time... ( do a search of the Forums to see how many people have asked the exact question ) NO, Since going to the FTDI USB bridge for configuration and UART connectivity, Digilent has omitted this interface from it's schematics. There isn't a good reason for this as there's nothing particularly imaginative going on. Perhaps, a few people are willing to pay for the privilege of using the "Digilent JTAG" that the Xilinx tools recognize. Some historical context. A long time ago, Digilent made JTAG modules. Xilinx even used these on its Xilinx branded FPGA boards like the KC705. Curiously, Digilent never used them on any of its own FPGA boards. The Spartan boards used the Cypress USB bridge that had an embedded ARM processor. At that point the "Digilent JTAG" was more of a software thing than a specialized interface. When the Series 7 boards came out, Digilent went to the FTDI bridge devices like the FT2232. Cheaper and no programming. The Digilent JTAG interface is merely a few bytes of EEPROM these days. There are a couple of small details that anyone can work out. Unfortunately, clipping information out of published schematics seems to be a Digilent thing now, having migrated to its Zmods. If Anyone at Digilent has a good reason for slighting their customers by doing this, no one is talking. For what it's worth, some vendors don't publish any schematics their FPGA boards. Not even a hint about how to turn LEDs on or off properly. You say that your Arty is not an A7 or S7 or Z7? Really? What FPAG device is on it?

Digilent's naming convention for its USB UART Bridge interface is a confusing mess. It views the TX and RX pins from the viewpoint of the bridge UART pins; not a problem so far. But then it names the signals on schematic and constraints as uart_tx_in and uart_rx_out; from the perspective of the FPGA.. except that uart_rx_out is really the FPGA UART Tx signal and uart_tx_in is really the FPGA UART Rx signal. Of course the manual doesn't mention the schematic and constraint signal names at all. Not ideal for people trying to use the interface for the first time. The Arty A7 reference manual has the Tx and Rx directionality shown correctly, so go by that. It says that D10 should be the Tx pin on a UART implemented in logic, so that's not your problem. The first step should be to write a Verilog testbench to confirm that your control of the UART is functionally correct. It's a simple matter to use the same UART in your FPGA design as a separate component in your testbench to spit out 8-bit data. If you've gotten the baud rate all wrong, then the serial terminal program on your PC might not show anything coming from the FPGA UART. You can check baud rate pretty easily in the simulation waveform window. After that, you could try using an ILA to capture signals and verify that the hardware is behaving the same as the the simulation. If you fail to get the directionality correct in your toplevel port list matching the wiring in your design, I'd expect a warning from synthesis or at least a bitgen error. You might have a baud rate issue between your HDL and serial terminal program. Going through the effort of doing a simulation should resolve your issues. Of course it's possible to get the testbench all wrong. [edit] If you don't know how to write a testbench and can tolerate VHDL, here's a link with source code that should help: https://forum.digilent.com/topic/4348-a-uart-based-debugger-tool/

Well, I don't want to be overly pessimistic. One possible ray of hope is that Intel has recently announced plans to spin off it Altera division.. though who knows what that will mean to product designers needing commodity level programmable logic. Because FPGA devices have gotten so complex, and the tools so bloated and complicated and subject to constant change, it's just not realistic to expect to read a couple of articles or tutorials and create/develop/implement unique logic designs that are terribly useful, in a couple of weeks or months of part time effort Yes, you can replicate an IPI demo project that turns a concept into mainly a processor software effort... if you use the same tool version ( and with Quartus, perhaps the same host OS ). But then what do you do when you need significant changes in functionality? Xilinx and Altera, for decades, had 90% of the programmable market. For the most part their tools have been designed mostly to exclude customers from switching vendors rather than provide real productivity for designers. In the 40 plus years of programmable logic, the best design flow is still the HDL flow, if you want as much control over your designs as possible. And, yet in all that time, no one has created a language or design framework that's complete. You can describe your concept to the synthesis tools but you can't provide constraints, implement vendor agnostic, device agnostic design elements that uses the various resources consistently. I think that the reason is that the major vendors don't want to design devices that meet standards or a common framework.. a concept that has defined electronics packaging and functionality for the past 50 years. Even still, if you eliminate as much complexity a possible, that is use only the best version of the tools for your device, use one vendor to start, and put in the time to learn the basics ( HDL design, HDL simulation/verification ), exclude hard and soft processor based designs, there's plenty of opportunity ( for now ) to do some exciting FPGA projects.

Yes, get the SYZYGY standards from Opal Kelly's website. They also have KiCAD PCB samples, though you might have some difficulty with KiCAD version issues. When you say that you want to have a SYZYGY USB type C port... what exactly are you wanting to do? BTW. Opal Kelly sells standard pod and transceiver pod breakout boards for prototyping. They aren't perfect for any project but, you might find them useful as a way to connect a USB 2.0 bridge to your platform. Be aware that SYZYGY requires a uC for DNA negotiation to set power supply voltages among other things.

Terasic has a PCIe demo for it's C5P Cyclone IV and Cyclone V boards that implement 512 KB memories, which is a substantial percentage of the total BRAM for those devices. They are the slowest speed grade devices. So, it depends on the device, the device speed grade, and perhaps the tool version. For the Artix 200T in the Nexys Video I've implemented 128 KB storage elements like DPRAMs and FIFOs. For the speedier Kintex on the Genesy2 I've implemented 256 KB storage elements. I've done this using Vivado IP. This doesn't represent a hard limit, just a boundary that the tools set at a limit. Can you instantiate multiple 128 Kb FIFOs on your board? Perhaps. Can you make timing for the complete design? I can't venture a guess about that. Usually, there are design approaches for achieving performance that a simple straight-forward approach doesn't allow. If one way doesn't work, consider an alternate design approach.

In practical terms, there are only so many BRAMs that one can combine to create a large memory that meets timing reliably at a reasonable data rate. If your needs are for an asymmetric memory, that is different ports widths then this complicates things. If you are creating a true DPRAM with read/write ports using a different clock, then this also complicates the design. I suppose that if you use really low frequency clocks, or have many clock periods between read and write operations, then you might be able to bypass the guard rails of the vendor IP and create a memory using HDL without the IP. FPGA vendor documentation describes HDL syntax that the tools will infer various types or memory structure from. There's no harm in doing some experimentation to see what results you get. You'd probably agree that a memory that seems to work some of the time isn't very useful, so extra effort in verification is required when you bend the rules. In theory, one could use 100% of the BRAM of a device for one giant memory. In practice, this might not be a good idea. If your application needs a really large amount of storage, there's always the external DDR memory.

Doug: "Do you know of a book or article that talks about Vitis/vivado from a conceptual standpoint, but still goes into some detail? " Well, Vivado installs Document Navigator. It's the best way to find relevant datasheets, device and Ip documentation, application notes, tutorials etc. that are **hopefully** in sync with the version of the tools installed. There's a lot of documentation. FPGA vendors haven't been very good at keeping up with it. The tools are complex. I mean, Vivado 2022.2 uses about 140 GB of hard disk space once installed... and that is for a reduced device support options at install time. There's always the Xilinx Wiki. Again, a lot of tool specific information and rarely content that you can implement without difficulty; but it is a learnng experience. Tool version incompatibility has always been a huge problem for Altera and Xilinx. Even the vendors can't keep up with the changes. Recent versions of Vivado have been happy to write constraints for me, only for the tools to reject what the tool has just added to my constraint files because of syntax. It's a problem. Once in a while I run into, in the internet, a cogent, well written write-up of how the author implemented a project in the tool version that I'm using that's informative and useful. Once in a while... So there's always hope and luck. I make sure to write down that author's name and save the url. Currently, the former Altera and former Xilinx are owned by companies with no interest in programmable logic other than perhaps making their consumer CPU products "functionality as a paid service". I doubt that either company writes code for their tools in-house. In my experience, new tool versions bring new bugs, annoyances, and disappointment far more reliably than improvements. That, and having old project broken, and node-locked device licenses is why I rarely install new tool versions anymore. So one way to reduce the pain is to use a tool version that was released when the device that you are using was a hot new thing... if you can for your OS. In one way, things have improved. Instead of quarterly updates and new device families every couple of years we now get one or two tool releases and many years between new families. I guess that one could view that as an improvement....

Doug: "My thinking was that I should be able to learn enough with option B (the easy way) to gauge the viability of a project and whether then I, or a "real" hardware engineer would take it on. In that event I was anticipating that option A would be required" Nothing wrong with that plan. A lot of important work gets done "playing around", especially when it's done with a purpose. Doug: " Why reinvent the wheel and just rediscover the pitfalls that were sorted out decades ago?" You'll get no argument from me, at least on a philosophical level. In terms of cost, I've found that most of the time I can create my own IP that accomplishes the same functionality as vendor IP and with much lower resource usage. Plus I understand how it works. Sometimes resource usage isn't terribly important. In commercial practice it always is. Vendor IP just isn't available to implement the kinds of projects that I do. Implementing functionality in logic is very different than doing so in software, where compiled machine code can sit around in memory somewhere and be used in different contexts at run time. As far as software goes. ZYNQ devices or even soft-processor-in-logic approaches can use the basic tool "OS" or some version of Linux. ( this is a simplification for discussion purposes ) For a ZYNQ platform, running Linux, you could use any third party ARM library to do an FFT. There are a myriad of hurdles however for such an approach. - Running Linux on a Zedboard requires development on a Linux host PC and involves a LOT more work - There aren't many FPGA boards that are well suited for supporting a large OS, plus user code - ARM performance in an FPGA is much lower than, say, an RPi 4 - ARM implementations in FPGA devices aren't equivalent to, say a Broadcom uC in a RPi for which there is third party support for software development FPGA vendors aren't going to promote the short-comings, limitations, exceptions, problems, etc. that comes with using their devices and tools. They know how hard FPGA development is. So, the only way to figure this out is to do what you've been doing; play around with a unique-enough application and see what happens. One alternative development approach is, if you have a lot of money, the MATLAB framework. I think that you'll find this to be as problematic... just more expensive. Again, more levels of code that may make development easier.. or perhaps not. That's why companies have technical employees with specialized training and experience.

According to the PMOD Standard ( such as it is, and it's quite dated ): The amount of current that a peripheral module is allowed to draw from the host is not specified, but it is assumed that the Pmod will not draw more than approximately 100mA. The document can be found here: https://digilent.com/reference/pmod/specification Different boards with a "PMOD" header support varying levels of 3.3V current draw. It depends on how many PMODs are being used, and the specific board power supply design for any given board. There are plenty of boards, FPGA based or not, AMD or Intel or other, that have adopted the PMOD form factor, but not necessarily the 3.3V/GND pinout. For the schematic shown, what's important is to ensure that the resistor values for open-collector ( open-drain ) or signals that can be Hi-Z, the pull-up resistors are consistent with the standard. This is complicated by the fact that there are a number of knock-offs of the original I2C interface standard. Digilent has never been organized enough to produce anything that might be appropriate to be called a "standard". That hasn't prevented it from becoming ubiquitous, unfortunately.

Doug: "Then I get "clever", and try to do some benchmarking of a simple FFT in software before then (more ambitiously) seeing if I could implement the FFT in the PL. Sounds like a fun Saturday night project (yes, I'm of a certain age....). So, I drop in some C code for a simple FFT, #include math.h because I have a sqrt" So, part of my reply to your post concerned the topic of "design flow". This is important because some design flows are more dependent on tools versions and support than others. The design flow that is least dependent on a specific tool or device vendor is the HDL flow using no vendor IP. It's also the hardest to learn and requires the most work. Then, there's the IPI board schematic or Platform Designer method where most if not all "coding" is connecting vendor or user IP blocks. This can be useful for experimentation or prototyping but is ultimately very limiting to the user. And... vendor IP is here today, and gone tomorrow.. or is changed. If you are "dropping" some C code to implement an FFT in the PL, this suggest that you are using the HLS version of the tools. Sounds promising, if you are new to programmable logic. Notably, HLS is a different tool than Vivado. I did experiment with it many years ago but soon dropped it as more of a curiosity than a serious design flow. Ever since programmable logic left the PAL concept for LUT based implementation, the vendors have tried to make using their devices **appear** to be easier to use that they actually are. The NIOS was the first step, because it made an FPGA look like a micro-processor in terms of functionality, and everyone knows software development. But vendors aren't the only ones to do this. There have been many attempts, by third parties, to circumvent all of the FPGA vendor tool complexity. Notable are frameworks like LiteX and Migen. But many years ago a number of people created C-Verilog tools that would implement designs in BRAM. These efforts can have impressive "showcase" demo projects as selling points. But, do they make for a robust, general purpose design flow? I think not. Since you have micro-controller design experience, you know that vendor tools are not quite the same as other tools designed for any target. You have to read the documentation, to see if the tool supports your requirements; that is if the documentation bothers to mention the topics of interest to you. Personally, I view the HDL design flow as the only viable long term and robust way to do programmable logic. Even then I have to read the vendor support for VHDL, Verilog or System Verilog as it applies to synthesis and simulation. If you are doing any logic synthesis, then you also need to read the documentation for the architecture of the devices that you are using to understand its limitations and "personality". SOP.. The fact is... FPGA devices are very complex, and are designed to allow implementing almost unconstrained behavioral concepts. This is unlike a micro with a fixed architecture and set of machine codes. Within a small subset of design possibilities, HLS, IPI, or even MIgen have a place and might be useful for some purpose. They certainly have the potential to shorten design time and complexity for some endeavors. What they don't do is replace the most basic programmable logic design flow for demanding projects, or help the user debug problems, or help the designer conceptualize how an implementation works to the extent that is required. For FPGA development and design your choices are: A) the long, arduous, hard way B) the (sometimes) quick, easy way If all you want to do is tweak a demo project, or prototype a concept, then perhaps choice B is OK. Maybe. Your post suggest that, even as an intellectual exercise of investigation into FPGA design flows, choice B hasn't been quite the experience that the advertising has suggested that you should expect. Many people have no interest in learning the details of programmable logic deign. They just want to abstract away the complexity of the devices and tools and do something useful. Intel and AMD have taken notice and have OpenCL type initiatives that work with really expensive boards and devices using PCIe in a PC. But, in the end these are just more levels of complicated scripts, tools, and supporting code, much of it proprietary and not available to the user, and subject to change at the whim of the vendor.

Question" "How can I most efficiently get to the point where I can become competent with the Vivado/Vitus flow? " Statement: "I want to get to the point where I can debug my own problems more effectively. " Doug, I expect that you are looking for a variety of viewpoints regarding the two quotes extracted from your post. Personally, I view Vitis FPGA development that contains either a hard ARM block or a soft-processor block as a different exercise than an all HDL design flow. A design that consists of 90% vendor IP connected in a GUI block connection format is also different than an all HDL design flow. So, I think that a useful response to your post depends on how you want to use the AMD/Xilinx tools, or the Altera/Intel tools, or any programmable logic vendor tools for that matter. The above statement tells me that you are already an advanced student in FPGA development because you realize something that a lot of people don't; If you can't debug or understand the work product of your labors, then you aren't in a very good place. The design flow preferred by FPGA vendors is is the Vivado board design, or the Quartus Platform Designer, where one connects vendor specific IP blocks together and lets the tool manage most of the work flow. This doesn't seem to me to be a good way to develop the kinds of experience and skills where one can develop competency in creating unconstrained logic that one understands and can debug efficiently. Even if you become proficient at the HDL design flow, using no or minimal vendor IP, you still need to develop more sophisticated development/debug skills as the complexity of your designs grows. This is easier to do with the HDL design flow, but requires a lot more work. I've been doing programmable logic design for 40 years so I've created a lot of custom debugging IP and approaches to fit a lot of use cases. But, your question isn't specifically about FPGA design flows... I'm reading it as more to do with the tools themselves. The bad news is that the tools are constantly changing, and becoming more complicated, and buggier. If it's not the user interface of the hardware or software tools, then it's the syntax for constraints.. or some other aspect that makes life hard. If you you have old projects created in older tool versions they are broken in newer toll versions. If you are learning FPGA development and trying to follow example designs, or tutorials from earlier tool versions, then it's confusing because the IP or the tools have changed. I use both Intel and AMD tools and devices using the HDL design flow and the least amount of vendor IP that I can get away with. In theory, implementing a design using nothing but VHDL or Verilog text sources on any device from any vendor should be easy, if not trivial. In practice this isn't even usually true for porting a design from one device to another device from the same vendor, or for the same device using different versions of the same vendors tools. That's just the way that it is. Unfortunately, modern FPGA devices are complicated and there are a lot of restrictions in how the basic structural elements and resources of the FPGA can be used. Often you can ignore the subtle rules or limitations with simple designs, but have to deal with them in more complicated designs.

You are probably a bit frustrated that no one has replied to any of your posts... so here goes. I'd suggest looking up Espressif. This company makes Bluetooth modules with an embedded MCU. They provide a number of modules and toolochains for software development. Their modules appear on a number of products letting you experiment using a number of simpler frameworks, like Python. Check out Adafruit and Sparkfun or even Seeed Studio to see what they offer in terms of support and ease of use. I suggest learning about Bluetooth revisions. Bluetooth might not be the best way to do what you want to do. There are alternatives, like LoRa. Understand Bluetooth security concerns.

For what it's worth, I've been using FMC mezzanine boards with a number of FPGA boards for years. This means that I've gone through attaching/ detaching cycles with 8-9 mezzanine boards on 5-6 FPGA boards many times. The good thing about FMC is that the pin/socket insertion force is low, which is a factor in how many times one can expect to do this. I have yet to damage either an FPGA carrier or any of the mezzanine boards over many years of use. I am also very careful about mechanically securing add-on boards requiring it; this includes HSMC, FMC, SYZYGY, etc. Having said this, I would agree that having all of the supply rails shorted in the FPGA is rather puzzling. It's not that I haven't damaged boards. I have a KC705 with unusable PCIe transceivers after having plugged it into a PC incorrectly ( quite an embarrassing feat of stupidity in of itself.. ) and I still use the board for other things ( like the FMC connectors ). It's the oldest FPGA board with FMC connectors that I own. The FMC connector doesn't connect to the Vccint rail directly, but does so for the Vaux rail. I suspect that a highly unusual event ( perhaps power surge? ) **could** cause such damage. The only thing that I can say for sure is that following best practice procedures is the best way to avoid problems: - secure boards properly - double check orientation and seating if these can be misaligned - double check voltage assignments in FPGA projects ( after bitgen ) - use good ESD precautions, especially in a non-lab environment - visually inspect connect high density connector pins for issues

Digilent would like to forget about one of their Spartan 6 FMC products that had serious FMC design deficiencies. I had two of them and even though I was careful using them both suffered catastrophic failure. In those cases a large chunk of the Spartan 6 devices blew out of the plastic encasement... lot's of smoke and foul odor...

I would suggest that under no circumstances should anyone ever attach an FMC mezzanine board to a carrier board and power on the system unless the mezzanine board is firmly connected to the carrier board and secured with the appropriate standoffs and capture screws. It's just too easy for the board connectors to get mis-aligned and allow very bad things to happen. Unfortunately, neither Digilent nor many FMC mezzanine board vendors bother to supply the appropriate hardware ( screws, standoffs, etc ) so it's tempting to roll the dice and proceed without a proper mechanical capture. I came back to add this to my last post, only to find, that you've brought up the same thought between the posts. FMC connectors have high density pin connections are if allowed to "flex" while in use might be subject to neighbor shorts.

I would agree with Asmi that catastrophic damage such as you report is unlikely the result of ESD. You say that you are constantly changing mezzanine board on the FMC connector. It's not impossible to damage pins on these connectors. You could do a careful inspection of the connectors on your carrier and mezzanine boards with a lupe or other magnifying glass in search of misaligned pins. A short of a power rail to ground could certainly do some damage to the power supply. A bit less likely is a short between signal pins that are power or ground pins and FPGA outputs for one of your applications.

I looked at the link in the email that certainly looked like something official. In part the link goes to ...ac.digilent.com/Prod/link-tracker?redirectURL= 'a large string'. Could be the usual Digilent screw-up, or could be something less benign. This is why I don't mindlessly allow my browser to execute rafts of untraceable code. A problem with the way that Digilent has always operated is have a minimum staff with limited technical skills and farm out 90% of the technical work to the lowest bidder. Seems like a bad business model in this day and age, especially when no one bothers to check the quality of the work... not that any of the Wonderland inhabitants would care. Unlike the poor bloke who decided to take Wonderland staff's advice and pack up his now worthless toys and go home, I'm quite used to being ignored, so complain I will, at least as long as it's possible.

It turns out that the Digilent has decided to force customers who've purchased an ADxx product to have a user account in the cloud with a profile, if they want to download the latest official Waveforms release for their hardware. That's why, even with my browser script blocker disabled the link provided by the email sent to me doesn't work. I checked because I was curious about what the 'terms and conditions' of the hidden contract that was alluded to by the unhappy customer who started this thead. Couldn't get that far. What else should Alice expect from the Wonderland experience. Yes, it's too much to hope that anyone at Digilent would go to the trouble of trying to see what Alice sees. In Wonderland the only problems are the visitors who complain about the experience. Can anyone point me to where I can view the 'terms and conditions' of being an ADxxx customer without having to travel the maze that is the wonderful Digilent Customer Experience? Coda: When posting to the Digilent website with scripting blocked in your browser, don't compose posts in the HTML editor because everything will be lost...

Of course there are JTAG pins on your FPGA board; it would be pretty useless without them as you couldn't be able to configure the FPGA. All programmable devices have dedicated pins for configuration on power-on so they don't appear on user constraints. The tools know where they are. I'd tell you to look at the schematic for your board, but Digilent has been removing that circuitry from it's schematics since it went to the FTDI USB bridge from a Cypress one. As to how you might use MATLAB with this board, you'll have to pose that question to MATLAB technical support I'd imagine.

I had to read this thread 3 times to figure out if I want to add to it. It's truly been an 'Alice in Wonderland' experience, and I know that I haven't been ingesting psycho-active drugs. Basically, we have one customer complaining about his user experience and all of the Wonderland characters telling him that no one else in Wonderland shares his dismay at how the Wonderland experience is changing. On top of that the Wonderland characters are telling said customer that if he doesn't like Wonderland he can throw out all of his Wonderland toys and go home.. because, well not only is Wonderland wonderful but it's always getting better even if one grumpy resident is unhappy. According to Wonderland residents more complicated, poorer internet hygiene, less access to important product information, and more hoops to jump through is what all visitors to Wonderland want. Is this about right? That's a rhetorical question as clearly said grumpy customer and no Wonderland managerial representative is going to change their tune. It's not what's in the thread that's interesting so much as what's being avoided. Personally, I don't like having all of my on-line activity monetized by companies that I've never heard of who amass and sell information about me, accurate or not , especially when the end result ends up costing me in ways that I have no way of knowing about. But, I admit that perhaps there are people who feel differently. But really, this thread is all about the sordid personal dossier industry that Google created... printing money and merchandising the customer. Having read this thread, I just tried using the link from the email telling me that I can update my ADxxx software. Unless I have Scripting enabled the link doesn't work. When I try this link https://files.digilent.com/ as provide above, I get the same experience. When I try the next link that follows, I get a download. As I write this, script blocking is enabled, because I've made the decision that I won't be using Digilent's website without script blocking in my browser, just like I do for 90% of the other websites that I use on a normal basis. Now, I realize that a lot of people, and a few companies, don't think about security, protecting personal information, or the dark universe run by legitimate and illegitimate entities for profit an my expense, but I seriously doubt that I'm an oddball. What people do when given no other choices is not a measure of what they would prefer to do. Since becoming an NI property, my Digilent experience has not been better. I might be the longest running Digilent customer posting to the forums, so I have a long time frame to measure this by. Finding the information that I need about products and supporting code bases have gotten harder and more time-consuming, and while Wonderland management can write about the great experience that this is for all of the other customers, this isn't going to make me feel better or change my mind. Personally, I can tell you that I won't be buying an AD3 because of Digilent's 'new and improved user experience'. It's not just the confusing and inconsistent path to getting software updates ( better than the hoops that I had to jump through a few months ago.. as long as the one link in this thread works... ), it's not just how Digilent tries to hide information about how the software and hardware works by putting the information in a place where you have to download and run the software in order to find it, it's not just that the current WaveForms software isn't what I generally download ( it's the ***latest*** having a brand new feature for one of the WaveForms supported platforms, so I generally need to go through this multiple times ( that is if I can get someone from Digilent to post a link to it) , it's all of this plus a growing sense that Digilent isn't the kind of company that I want to deal with. I've got it, if I don't like the new regimen then I shouldn't buy Digilent stuff; so OK I won't and you could care less. But tell me Wonderland Management, how sure are you that the new and improved Wonderland is going to keep most of their other customers? Are you willing to bet the company on it? Perhaps NI couldn't care less. My personal opinion is that NI didn't buy Digilent in order to increase their product portfolio so much as to protect an aging business model, which might explain a lot. Digilent certainly hasn't been integrated into the main NI public presence and the FPGA side of the business is pretty much a thing of the past. [edit] BTW the external clocking feature of the AD3 might be useful enough to get me to want one if it's supported properly; it's that noteworthy in my opinion. I visit the forums daily and it seems that recently each month brings new undesirable features. So, for instance, I can still compose posts with scripting blocked in my browser once I've logged on, but now I get logged out before saving the post if it takes too long and everything that I wrote is lost. For this post, I had to copy/past the text to a local editor. hit the save button, lose the text because that's when I learn that I've been logged out, log back in copy/past the text back into the forum editor and save... pretty much sums up my experience in the improving Wonderland.. oh, and I notice that when logged in without scripting I'm not listed as logged in unless I post something. No doubt a feature that will be improved by preventing me from logging in without scripting sometime soon...