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

Hi @Jack Priddy, Realistically there isn't much else you can try; if you have tried both externally powering the device and other cables, presuming the board (likely the regulator) was functional, you would have seen at least the Power Good LED (next to the barrel jack) light up as it only turns on once the other voltage rails are successfully enabled. Since you purchased the board last December which is within the 1 year warranty, https://digilent.com/shop/shipping-returns/#warranty, and have otherwise not used the board in a non-intended fashion, I would consider the board to be eligible for replacement. Presuming you purchased the board from Digilent, 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 underside 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 (Element14, RS Components, 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

HI @Jones, I have been recommended by the Ettus team that support questions regarding Ettus products should be directed to the their mailing lists, https://kb.ettus.com/Mailing_Lists, where Ettus Research engineers, Ettus support, and customers themselves have been active for the last 10+ years. If anything, this will at least reduce the time it takes for you to receive an accurate response since the Digilent staff will end up reaching out to the Ettus team about this anyway and relaying the answer back to you. I can at least let you know that GPIO headers are either 3.3 V or 1.8 V depending on which header you are looking at based on this section of the manual, https://files.ettus.com/manual/page_usrp_b200.html#b200_switches, but I do not readily know if it is a good fit for your intended application. Thanks, JColvin

I just want to clarify that the USB104 A7 is a Digilent designed board, but the PC/104 form factor that it uses is, of course, not Digilent designed. Regardless, the specifications for both SYZYGY and the SYZYGY DNA will be the one of the most valuable resources in your endeavor to create a pod as relying on word of mouth is always susceptible to (unintended) misinterpretation. Opal Kelly also has some additional information in their Design Guide(s), https://docs.opalkelly.com/resources/syzygy-design-guide/, that you may find helpful as well as it addresses some of the questions you had (such as does the pod need have have its MCU pre-programmed). To be clear, to my knowledge, the SYZYGY details that zygot provided are accurate. But it's still prudent to verify for yourself before investing time and money into developing a new product. Thanks, JColvin

Hi @Reuel Joshua, What do you mean by LCD demo? I'm guessing the OLED demos you are referring to was the OLED demo that is linked from the the Genesys 2 Resource Center, https://digilent.com/reference/programmable-logic/genesys-2/demos/oled#download_and_usage_instructions, but that of course uses the on-board OLED screen. There is no on-board LCD screen, so I am not certain what hardware setup you have in mind. Thanks, JColvin

Hi @steven balicanta, I have uploaded the Statement of Volatility for the JTAG SMT2 to the right hand side of it's Resource Center here: https://digilent.com/reference/programmers/jtag-smt2/start. Let me know if you have any questions. Thanks, JColvin

HI @jarvis, I modified the xadapter.c as that was the file Vitis showed as having the error. (updated my post to clarify that file as it wasn't listed originally) I attached my Vitis export and a pdf view of the corresponding block design for convenience. Thanks, JColvin AA35-EchoServerBD.pdf vitis_export_archive.ide.zip

Hello, I have moved your thread to a more appropriate section of the Forum where the WaveForms developer may be able to provide some insight into this. Thanks, JColvin

Hi @cactuskooler, The power switch (SW8) on the Zedboard is a MS12ANW03 from NKK Switches. Let me know if you have any questions. Thanks, JColvin

Hi @arang, The voltage setting is for all pins; this is a hardware limitation as the Supplies sets the VCCIO_PROG voltage for the banks that all of the pins (DIO and DIN) are connected to. Let us know if you have any questions. Thanks, JColvin

Hello, I got the lwIP Echo Server example working for Arty A7-35 in 2023.1. There were a couple of gotchas that I ran into that you may have already addressed, but I'll list them anyways. - In the Vivado block design, I forgot to connect the AXI EthernetLite interrupt, which caused problems getting an IP addressed assigned via DHCP - In Vitis, I needed to fix the conflicting status error. Basically, comment out the “u16_t status;” line 399 in /design_1_wrapper/microblaze_0/standalone_microblaze_0/bsp/microblaze_0/libsrc/lwip213_v1_0/src/contrib/ports/xilinx/netif/xadapter.c save, then rebuild the project. I learned this from Adam Taylor's mention of it on his tweet here: https://twitter.com/ATaylorFPGA/status/1666347512687411200. - I modifying the Platform BSP settings to have lwip213 → temac_adapter_options → py_link_speed be set to 100 Mbps rather than autoconfig (needed if you are not using a DHCP server such a router and are instead manually connecting) After that, I was able to build the project, open up a Telnet connection on port 7 and then had data echo back to me. The longest waiting was for getting the DHCP to assign the IP address, but that didn't take more than 5 seconds or so. Let me know if you have any questions. Thanks, JColvin

Hi @jarvis, I'm a little surprised to hear that the TCP echo server is starting at port 1022 since from my knowledge the lwIP echo server template used in Xilinx SDK/Vitis is port 7 The long delay sounds symptomatic of two potential problems. One is that there is a delay function in place whose time base is off by a few orders of magnitude. The other, which seems more likely to me based on the 60 second timing, is that the echo server reaches an internal timeout and resets itself. I'm working on creating a MicroBlaze based design to test the Echo Server in 2023.1 to see what results I get. Thanks, JColvin