artvvb

@GLC Are you trying to use the USB JTAG / USB UART microUSB port? If so, drivers are installed through the Vivado installer on Windows. See "Install Cable Drivers ..." here: You can rerun the installer via the "Help -> Add Design Tools or Devices" option in Vivado. Thanks, Arthur

To try to answer one of your questions today: Sharing projects is kind of a huge topic... Digilent has used these two sets of scripts to get projects packaged up for git - https://github.com/Digilent/digilent-vivado-scripts, https://github.com/Digilent/digilent-vitis-scripts - but there may be issues with various tool versions and certain unsupported features (RTL modules aren't handled automatically for example). GitHub's file size limits for files included in releases are pretty lenient, so it might be possible to attach full project archives for both Vivado and Vitis if you created a repo there. Starting points in the menus for creating ZIPs are File -> Project -> Archive in Vivado and File -> Export in Vitis, at least for 2021.1. The nice thing about using the auto export tools is that, at least in Vivado, it'll collect up all external dependencies like IPs and board files, and they can at least theoretically cut out a lot of the build outputs and other random files that show up in project directories.

Yes. The failure indicated by the error message that the calibration was not successfully read could come from a couple of different early exits from ZmodAwg_ReadCoefficientsFromDna. Please try bypassing this one, or modify the function it calls: https://github.com/Digilent/Eclypse-Z7-SW/blob/aa2f34efc4dc63317a58bbaeb02e946c4c2d68a9/src/mm2s_single_transfer_test/src/awg_calibration.c#L75.

No other hardware configuration issues, seeing as you're getting USBUART printouts. Could you send me the printout from the calibration reader? This could be related to a recently reported issue where the app was not able to determine the name and type of the Zmod correctly, due to names not matching expected values - see this comment: There's a more extensive fix in the works, but it has not yet been pushed out to Github. Thanks, Arthur

Hey @boesterle Could you confirm which Zmod port the AWG is plugged into? The hardware project is designed so that the AWG must be on port B and the Scope must be on port A. The calibration reader app would still be fine as it's just enumerating Zmods that are installed. Thanks, Arthur

I don't have the right angle 2x6 connector part number offhand but have reached out to see if we can provide it. In the meantime, here are a couple of assorted compatible products: https://digilent.com/shop/2x6-pin-pmod-cable/ https://digilent.com/shop/pmod-cable-kit-2x6-pin-and-2x6-pin-to-dual-6-pin-pmod-splitter-cable/ https://digilent.com/shop/2x6-pin-to-dual-6-pin-pmod-splitter-cable/ https://digilent.com/shop/2x6-pin-header-5-pack/ https://digilent.com/shop/pmod-cable-kit-6-pin/ https://digilent.com/shop/pmod-female-right-angle-6-pin-header-5-pack/ https://digilent.com/shop/6-pin-header-gender-changer-5-pack/ Thanks, Arthur

I think the clock should not start up until after the Zynq PS has been configured, yes. It ought to be possible to program the bitstream from Vivado and program only the PS from Vitis - some checkboxes in the Run and Debug Configurations allow you to bypass bitstream programming. Interesting, I'll need to do some debugging to confirm. Haven't had a chance the last few days. I'm not sure how to go about setting up UDP - the performance measurement application templates might have some hints.

Unfortunately, no Pmod IP was created for the Pmod RF2. You can see the full list of Pmods that have this kind of Vivado support in the "Pmods Supported" table of this guide: https://digilent.com/reference/learn/programmable-logic/tutorials/pmod-ips/start.

Hey Sven, The adapter won't come with them, but there are various banana plug to X connector adapters that can be sourced from other vendors online that should work, see below for an example of USB (note that I have not tried this particular product). Max current is listed in the specs in the reference manual (https://digilent.com/reference/test-and-measurement/current-and-power-adapter/reference-manual), there are a couple of different range selections, but the widest is up to 25 A. Thanks, Arthur

Look through the verilog source files for a line that says "`default_nettype none" and either comment it out or remove it. These lines are usually right at the top of a file. This is effectively a compiler directive that tells the tool that when it sees a signal that either doesn't have a declaration (a declaration meaning "wire my_signal;" for example) or a declaration with an unspecified type ("input my_input" isn't specified as a reg or a wire), then it should throw an error instead of picking one automatically. Using these default_nettype statements can be useful for catching other silly errors like typos in variable names - for example, if the default nettype is wire, as is default when it's not specified, then a simple typo in a signal name anywhere in a module will introduce a new signal with that alternate name. Alternatively, find each of the nets that it's complaining about, and make sure that they are specified as wires or regs. If it's complaining about signals in the block design wrapper, then I would be confused, it should be declaring all of the signals properly for this - could be a Vivado version difference or bug in 2023.1. Do note that a single signal could be defined across multiple lines - in the attached screenshot, DDR_addr is both defined in the module port list at the top, defined as an inout, and then finally declared as a wire. I don't entirely follow what you mean by this. Generally, files in a workspace are saved individually when you are working within the tool - The File -> Save operations only apply to the file currently open in the center pane. If you're trying to make a backup of everything in the workspace, exporting projects to a ZIP file might be an okay way to go. Getting your files into version control in git or something similar is also an option, but is an entire can of worms. When you launch the project from scratch, are you creating a new workspace?

This all makes perfect sense, thanks for the feedback!

That's correct. Sensitivity is fixed based on the sensor type. It may be possible to depopulate the sensor and replace it with another compatible sensor from the same line, however this would likely void the warranty. I sincerely apologize for the incorrect documentation and am working to make sure that we correct it. In the meantime, I will be reaching out shortly via direct message to provide contact information for our customer service team, in case you're interested in pursuing a return.

Hi @miketranch The input voltage range specs with the adapter are still ±25 V - it definitely shouldn't be connected to Mains. You can see specs in the manual, here: https://digilent.com/reference/test-and-measurement/current-and-power-adapter/reference-manual. That said, this is a great question and we really appreciate the feedback. I'm looking into improving the documentation to make this more clear. Thanks, Arthur

Hi, Unfortunately, Digilent doesn't provide any example code for the Pmod RF2. All material for it can be found here: https://digilent.com/reference/pmod/pmodrf2/start. Otherwise, there might be some third-party projects around online, but I cannot attest to any personally. Thanks, Arthur

Hi @rmac, welcome to the forums. The temperature counts need to have an offset and scale applied. Please review this technical note for the LPS25HB part describing how to convert from sensor counts to pressure and temperature in hPa and degrees C: https://www.st.com/resource/en/technical_note/tn1228-how-to-interpret-pressure-and-temperature-readings-in-the-lps25hb-pressure-sensor-stmicroelectronics.pdf. Thanks, Arthur

Hi @Abinav Welcome to the forum. Could you let us know what device you are trying to use and what sample rate you need to maintain? "Time" settings if using the WaveForms Scope instrument would tell us sample rate. Thanks, Arthur.

To the question on I2C, yes. The dpmutil sources are just a wrapper around the PS I2C controller that abstracts I2C communication with the PMCU and DNA. You could reimplement the same functionality with an alternate driver for the PS I2C device. I have minimal personal experience with Petalinux, and am not certain exactly what configuration needs to happen, but at a minimum, the expected PS I2C needs to be enabled with access to the xiicps driver. Reviewing the I2CHAL implementation may be helpful: https://github.com/Digilent/dpmutil/blob/master/I2CHAL.c - it looks for an I2C driver with the device name pmcu-i2c or defaults to /dev/i2c-0.

What GPS module are you using? Electrical standards used on the TX and RX pins will be relevant. Pins JA3 and JA4 of the Pmdo port would be fine for 3.3V logic with most UART baud rates.

Got some more information: The primary intent of the multivibrator circuit is to be able to control the length of output pulses. It was explained to me that this would be useful in scenarios where the output pin was connected to a microcontroller interrupt pin (or a GPIO connected to an interrupt pin), as the longer pulse would prevent multiple events from firing repeated interrupts, thus eating up CPU time. It could also be useful when using an FPGA development board, as it could impose less strict requirements on a project - it could effectively debounce the signal for you. As for the lines about sensitivity in the feature list, they seem to be unrelated to the multivibrator functionality. It's possible that they were included as, during the design of the product, Digilent was considering several options for the mounted sensor and whether multiple variants of the Pmod would be produced with different sensor variants. If this is the case, it would be an error in the datasheet - I'm still looking into it and we may cut these lines. You can find more information on the sensor used and its sensitivity in these documents: https://mediap.industry.panasonic.eu/assets/custom-upload/Components/Sensors/Industrial Sensors/Passive Infrared Motion Sensors/PaPIRs_Nutshell_Flyer_23.pdf https://mediap.industry.panasonic.eu/assets/custom-upload/Components/Sensors/Industrial Sensors/Passive Infrared Motion Sensors/ds_ekmc160111_v63_en.pdf Thanks, Arthur

Hey sinmo, welcome to the forums. I'm sorry for the delay, but I've reached out internally to the engineers who worked on this product to see if I can get some more information. Thanks, Arthur

Hi @Saturn, welcome to the forums. Do you have a datasheet for the part you're reading from? It should provide additional information like data formats and required baud rates. There are several examples built into Vitis. You can find them through the .spr file in the platform project - look for xuartlite in the list of drivers installed in your BSP. (Note that the UART driver shown in this screenshot is for the PS UART, not a UART lite IP.) Without the interrupt connected, a polled example will be the best bet. I may be able to provide additional guidance if these examples are insufficient. Thanks, Arthur

The AXI Quad SPI has an "ext_spi_clk" port, which is divided by the frequency ratio (which must also be at least 2) to derive SCLK. You probably have this pin connected to the AXI clock. See the "Frequency Ratio" bullet here: https://docs.xilinx.com/r/en-US/pg153-axi-quad-spi/SPI-Options.

Win10 is what I use and, anecdotally, 2023.1 is one of the more stable versions of the tools I've seen. For the specific error, this can show up when a platform project's hardware specification is updated with an XSA with a different filename than the one originally used - it could be something else, but this is my best guess. Run and Debug configurations name the bitstream after the XSA. The Run/Debug configurations aren't updated when an XSA is switched out, but the bitstream is, causing a mismatch that leads to this error. If you look in the folder listed, I would imagine you would see a bit file with a different name. To fix this, you can get to the configurations through the dropdowns next to the debug and run buttons: In the dialog, go to the Target Setup tab and check whether the "bitstream file" field matches what is actually in the folder: To work around this long-term, you need to either always use the same name for the XSA for your platform (maybe storing new exports in a different folder to prevent overwriting the original), or go in and update this field every time you change the name.

I know you've moved off of this route, but for future reference, once a PS peripheral is configured for EMIO, it shows up as a separate interface on the Zynq block: This can be connected to other IPs or to an external port as is normal for any interface of any block. If you just wanted to connect the interface pins to FPGA pins, you could make the interface external and add location constraints as appropriate. If you haven't done it before, see here for what "make external" looks like on another IP: https://digilent.com/reference/programmable-logic/guides/vivado-add-gpio.

Hi @connoisseur_de_mimi Asynchronous resets are also generally not recommended by Xilinx: https://docs.xilinx.com/r/en-US/ug949-vivado-design-methodology/Synchronous-Reset-vs.-Asynchronous-Reset. It seems that hold violations could be a result of this: https://support.xilinx.com/s/question/0D52E00006hpk6eSAA/hold-time-violation-on-asynchronous-reset. If that's the cause, synchronizing rst_n to the clock and removing the negedge rst_n from the sensitivity list could potentially fix it. You can also potentially find more information in the implementation reports. For example, report clock interaction could tell you if there are unsafe clock domain crossings: Thanks, Arthur