JColvin

Hi @JonD, I can't quite tell from your post, but I presume that you are referring to the various add-on boards for Analog Discovery 3 / 2 such as the BNC Adapter or Transistor Tester or whichever? The Analog Discovery 2 and 3 both come in their own case that has rubber feet. As for the various adapters, it is true that many of them do not have rubber feet (Impedance Analyzer does if I recall correctly), but they are all exposed circuitry. From my understanding, any metal standoff feet on Digilent devices, whether that is the BNC Adapter or Zybo Z7, are not electrically connected to anywhere else on the boards. Anecdotally speaking, as Digilent started out primarily making educational based boards, our devices tend to be fairly resistant to abuse, particularly the Test and Measurement devices as they were planned with classroom teaching and inexperienced students inadvertently shorting things in mind. The automotive support within WaveForms only became a thing less than 1 year ago (July 2023 according to the Beta download changelog). I'm guessing that in terms of automotive work, simply using rubber stops for kitchen drawers won't quite be sufficient (and dripping epoxy over the exposed material is a hassle). What style of enclosure would you be looking for? Just some covers like the for the Pynq Z1, Plexiglass Covers: Recommended Addition for the PYNQ-Z1 - Digilent, https://digilent.com/shop/plexiglass-covers-recommended-addition-for-the-pynq-z1/, a more robust enclosure like for the Eclypse Z7, https://digilent.com/shop/eclypse-z7-enclosure-kit/, or something else (I'm guessing not just a soft case that holds both the AD3 and whatever adapter, https://digilent.com/shop/analog-discovery-3-soft-case/)? Would this enclosure be form fitting to individual adapters, or more modular and workable among a wide range of adapters (this would be difficult as the adapters are all wildly different sizes). As a side point, as far as I remember, you're also the first person to request this sort of thing for the adapters, so the market for it is, presumably, relatively small which will make it hard to convince the various stakeholders to invest time into making such such a protective case. Thanks, JColvin

Hi @saman farhadi, What Digilent device are you using so that I can provide correct instructions? Thanks, JColvin

Hi @dh_ee, I am only familiar with the first part number listed; it is, as you indicated, a particular power supply that Digilent sources for Xilinx/AMD for some of their boards and is not compatible with any Digilent boards and so is more of a "hidden menu item". I don't think I've ever seen this power supply in person, though the pinout should be what is listed at the end of AR 67507, https://support.xilinx.com/s/article/67507?language=en_US. Regardless, I have sent you a PM for the Digilent contact that should be able help you get this supply. Thanks, JColvin P.S. I have no idea why this power supply receives this convoluted treatment.

Hi @Dniel.Schmid, What version of Vivado are you using? I just downloaded the latest 2022.1 release of the keyboard demo (linked in the Download and Usage Instructions Table available here: https://digilent.com/reference/programmable-logic/nexys-a7/demos/keyboard) and did not get this error. I know the project was made on a different computer, but Vivado should have largely mitigated for that. Within Vivado, if you go to Project Manger -> Settings -> IP -> Repository, you can remove the listed IP repository, though that should not cause this error. Thanks, JColvin

Hi @Joe306, I believe you need need the Adept Runtime drivers for the JTAG module to be detected correctly; normally some version of the driversare installed during the Vivado installation via a "Install Cable Drivers" checkbox, but you can get the latest version from the Adept Resource Center here: https://digilent.com/reference/software/adept/start. Let me know if you have any questions. Thanks, JColvin

Hi @francesca.marinoni, There is no specific recommended calibration and frequency schedule for the Analog Discovery 2 / 3. Personally, I calibrate the devices that are on my desk when the mood strikes me, which works out to every 1 to 2 years. For the actual calibration itself, I use the built-in WaveForms calibration procedure. Directions walking you through the calibration can be found on our reference site here: https://digilent.com/reference/test-and-measurement/guides/waveforms-calibration, with some additional information about calibration directly within WaveForms in the Help tab: Let me know if you have any questions. Thanks, JColvin

Hi @M. Hamza Öncüer, These are my personal testing results from a single ADP2230 on my work laptop with an M.2 SSD -- aka a single data point (albeit repeatedly tested from a pedantic engineer). Naturally, DDR is enabled on the ADP2230 during all the tests (the default option, though its worth noting that these rates are simply not possible when using the lower power BRAM only mode as the buffer size of 32 kS simply results in far too much USB overhead for all of those tiny transfers). All recording to file results saved as a 16-bit binary file, interleaving the data sources when more than one is recorded (analog1 analog2 analog1 analog2...). For a single analog input (the resolution is 14-bit at high sample rates, but each sample is recorded as a 16-bit value; you can get higher resolution if you sample at 1/2 or 1/4 of the set system frequency), I can repeatedly successfully record 5 G samples at 125 MHz (the maximum sampling rate). For two analog inputs (16 bits each, or effectively 4 bytes per 'sample'), I can repeatedly successfully record 5 G samples for each channel at 70 MHz. I'm not certain how much faster this could be pushed and remain consistent with USB bus activity. I know for example 100 MHz is not realistic as that would require transferring data at 400 MBytes/sec which isn't viable thanks to the USB protocol overhead. For all 16 digital inputs in the Logic Analyzer, I can repeatedly, successfully record 5 G samples at 125 MHz, with or without data compression enabled. Data compression meaning only data changes are occurred, rather than a sample at every 8 ns. Two 16-bit samples are recorded with data compression enabled, first the data at the change, then the timestamp. Using the Digital view within Scope instrument, and recording both analog channels and the 16 digital channels simultaneously, I can repeatedly successfully record 5 G samples for all three at 41.667 MHz (a third of 125 MHz). I would like to believe that 50 MHz is possible with further refinement, but expecting no issues for the mixed signal recording at the equivalent 300 MB/s is probably unrealistic. Currently I get a "samples could be lost" message, though it does complete the 27.9 GiB acquisition (3 data sources * 16 bits each * 5 billion samples = 30 billion bytes; 1024 bytes per kilobyte, 1024 per mega, 1024 per giga -> ~27.94 gigabytes). For clarity, I picked 5 G samples as a representative arbitrarily large number of samples that far exceeds the on-board memory. In principle, you could record far more samples, but I haven't personally tested it. Here's an example screenshot for recording all the two analog input channels at 62.5 MHz that I took today: Let me know if you have any questions. Thanks, JColvin

Hi @jhow, When you say older laptops, are you referring specifically to the hardware age of the laptop or the OS version? Additionally, what version of the WaveForms software are you using and do you have some more specific detail on what you mean by not being able to record the frequency response accurately, so that we can help provide some more troubleshooting insight. Thanks, JColvin

Hi @gagey, I've sent you a PM on the chance that the FTDI chip is somehow misconfigured and can be restored to a default working state. If this does not work, then based on the additional information you have given, I am inclined to believe that the board has a manufacturing defect of some kind. I have given some addition instructions on next steps for RMA in the same message if this is the case. Thanks, JColvin

Hi @gagey, Have you configured this board before? LED 8 indicates if the board has loaded the configuration from its onboard flash memory (which it will do on power up if JP1 just below the reset button is loaded); if not, does any configuration load if you have Vivado closed and then connect power to the board? LED 11 is of course the power good LED, but LED 10 would be indicating serial terminal/UART activity from the host computer and would not normally be constantly on. You also mentioned that when you connect the board to the host PC that it is not detected by the system device list; if you are not able to see it in the Windows Device Manager such as in this post, https://forum.digilent.com/topic/21713-brand-new-basys-3-user-cant-get-vivado-to-see-it/#comment-62685, nor Linux are detecting with dmesg with an output similar to this post, https://forum.digilent.com/topic/23708-arty-board-not-recognized-by-vivado-or-dadutil/, there are a few potential culprits. The USB cable itself not supporting data flow (most likely), the USB port (I have one on a hub that is finicky), or the FTDI chip itself (least likely, but I have no reason to rule it out yet). Please let me know the results if you get to try a different USB cable and, if the board has not had its flash overwritten with a different configuration, what happens if you have JP1 loaded and then power on the board with only an external power supply. The Arty A7 100T that I have does load its out of box demo when powered in this way, though it takes about 9 seconds before it loads. I'll have to look into why it takes awhile; I suspect the QSPI clock frequency is lower than I would have set it. Thanks, JColvin

Hi @Asad Rashid, Digilent did not create this material, but I believe NI has all of the course material and course labs available for download on their site here: https://education.ni.com/teach/resources/92/ni-myrio-project-essentials-guide. Thanks, JColvin

Hi @Jayman, It looks like the incorrect cable driver is being installed, based on how it is showing up. There are some instructions on how to fix this in this post on a similar forum thread here: Let me know if you have any questions. Thanks, JColvin

Hi @asdf, You will need a ground connection so that the voltage levels are consistent between the devices, and so that Vivado will actually detect a JTAG programmer and the downstream FPGA (presuming it is being powered separately), but if you connections are correct you will then be able to load a bitstream to the FPGA, as I have done in the picture below. PS_SRST_B is only needed if you are connecting to a Zynq device. For clarity, here is an alternate view of the pinout. Let me know if you have any questions. Thanks, JColvin

Hi @kbowling, I fear that source materials have been lost to time, or at least I am not able to find source files within Digilent materials. I have not gone through these materials (nor ever seen a XUPV5 in person), but it looks like there are some lab sources (the "no title" ones) on this AMD search result: https://www.amd.com/en/search/site-search.html#q=xupv5&numberOfResults=24. Briefly looking through one or two of those zip files, there seems to be some VHDL material in there, so hopefully one of them has material you are looking for. Thanks, JColvin

Hi @lee123, I have sent you a PM. Thanks, JColvin

I made an update to default notification behavior; users will now receive an email notification when they are deliberately tagged in a post or had their material directly quoted or shared (I don't have the option to adjust that separately), instead of only receiving an "in-app" notification when they are logged into the Forum. This update affects all users, so if you do not want emails of any kind, feel free to change the behavior in your own settings here: https://forum.digilent.com/notifications/options/ in the "Mentions & My Content" dropdown. Regular replies to threads that you are a part of but are not deliberately tagged in, will continue to have the default "in-app" notification with no email sent. You can, of course, change this behavior to your preferred settings in the "Followed Content" dropdown from the same url above. Thanks, JColvin

Hi @AndyJoe, I did not get the chance to reply yesterday, but I am glad to hear that you were able to restore functionality. Believe it or not, you are one of the very few people who have succeeded in restoring functionality on your own. Thanks, JColvin

Hi @user1123, The lsusb output looks fine. Could you also provide what dmesg shows when you plug in the device? An example of what you might expect to see is provided in this thread here: Though realistically if you have a second module that works, it is unlikely to be a driver specific issue. In anticipation of this, I have sent you a private message with some instructions on restoring the EEPROM. Thanks, JColvin

Hello, I haven't looked too closely at the circuit on your breadboard to see if it matches the circuit in your lab worksheet, but I'm presuming that this material wants you to use the Network Analyzer instrument within the WaveForms software, as this directly measures the magnitude and phase of the signals relative to your reference signal (Vs, as that the source) and of course uses both the analog inputs (the Scope) and the analog output (the AWG) to create and measure the frequency sweep across the circuit. Naturally, I don't know what your course professor is exactly looking for, but I would personally use the Network Analyzer with a setup similar to this: where I put the Start and Stop frequency both at 5 kHz (the percentage values at the bottom of the plot indicate how far the AD2 is with its 151 steps at the frequency) and set the amplitude to 4.5 V as that creates a +- 4.5 V sine wave. As per the diagram in the upper right, I would put W1 (wavegen channel 1) and the 1+ (scope channel 1+) at point Vs in your circuit and leave them there throughout the measurements as this source signal is what you would be comparing all of the other results with to see how the phase and magnitude have changed from the original (source) signal. 2+ (scope channel 2+) I would then put at V1. Scope Channels 1- and 2- would be connected to ground. Then run the Network Analyzer at the various requested frequencies and put Scope Channel 2+ at the various contact points (V1, V2, and Vr) until you have gotten all of the requested values. Thanks, JColvin

Hi @dwl, Could you attach a picture of your setup and how you are measuring it? I was presuming your setup was akin to: Multimeter Point 1 --> copper wire --> 'B' Terminal --> wiper terminal --> different copper wire --> Multimeter point 2 Which would be effectively just making your multimeter leads extra long. Such a setup would increase the overall resistance as, inevitably, the electric charge has a longer distance to travel and thus more molecules and irregularities to overcome. But you are reporting less measured resistance, which leads me to believe that I do not understand your setup correctly. Thanks, JColvin

Which Digilent board do you have so that I can provide the correct instructions? Thanks, JColvin

Hi @lee123, Are you using a custom board and want to license Digilent's solution on how to get Vivado to recognize the board, or do you already have a Digilent board that you erased the EEPROM configuration on? Thanks, JColvin

Hello, I'm not very familiar with how SDR is handled on the USRP boards (the Ettus mailing lists will be your best bet for accurate information), but I believe that they have their own hardware driver that handles it all for you here: https://files.ettus.com/manual/page_install.html. Thanks, JColvin

Hello, I used the Digilent board files and largely followed our Getting Started Guide, https://digilent.com/reference/programmable-logic/guides/getting-started-with-ipi, for setting up the block design; I put the clocking wizard downstream of the UI clock as recommended and added the Ethernet peripheral from the board tab at the same point I added the GPIO peripherals in the guide and edited the .xdc as needed to account for my sys_clk_i and the eth_ref_clk (you'll see them as the uncommented lines in the .xdc) UI clock is at the 81 MHz or so (whatever is listed in the dropdown) and is connected to the clocking wizard, which is configured to output 25 MHz. (note that there is a rounding error bug in Vivado that will report slightly different frequencies are being generated, rather than the exact frequencies). Regardless, I attached my archived Vivado project to this message so you can compare. It won't have the run results completed as that would have more than doubled the size of the file, but the corresponding .xsa is the vitis_export_archive a couple messages above. Thanks, JColvin AA35-EchoServer-23.1-notBuilt.xpr.zip

Hi @RCM13, I'm guessing that C339 and C340 are also at 0 V as they, like the VCC3V3 rail are also enabled by the 1.8 V rail (top left corner of page 15 of the schematic for Ref F, https://digilent.com/reference/_media/reference/programmable-logic/zedboard/zed_sch_rev_f1-public.pdf, other schematic versions are available on the Resource Center here: https://digilent.com/reference/programmable-logic/zedboard/start#documentation) which you reported as working. This will likely mean that something is wrong with IC27, or perhaps one of the individual passive components around the output circuitry have failed. If your board is outside of the 1 year warranty period, https://digilent.com/shop/shipping-returns/#warranty, then I would likely recommend that you attempt to replace that particular chip (after checking to see that the other passive components are at their listed values of course). If you purchased the board from Digilent and are within the warranty period, please send me a private message with the following information: - Order Number - Purchase Date - Serial number of the board (located on the barcode on the topside of the device starting with the character 'D') - preferred email address I will then get the information to our Sales team who will reach out to you to confirm any additional details that I don't have access to (such as shipping address). If you instead purchased the board form a distributor (Farnell, Mouser, Amazon, etc) you will need to contact them to determine their own RMA process. They will work with Digilent separately as needed, but feel free to use this thread as evidence as having worked with a Digilent engineer. Thanks, JColvin