artvvb

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

Hi @d3x0r, welcome to the forums! Manually constraining AXI GPIO interfaces is covered in this section (https://digilent.com/reference/programmable-logic/guides/vivado-add-gpio) of this guide (https://digilent.com/reference/programmable-logic/guides/getting-started-with-ipi), which uses GPIOs with the default "not all inputs or all outputs" configuration. In this case, the tristates need to be manually set in software (XGpio_SetDataDirection). You can alternatively change the AXI GPIO configuration to set either all inputs or all outputs, which doesn't require you to set the tristates, however the pin names that need to be constrained are different as only that pin direction is associated with a port on the block. I believe you'd be constraining a port named like "led_tri_o[0]" instead of "led_tri_io[0]" here. So, you can either configure the AXI GPIO for all input/output, change the default tristate value to match the intended port direction, or you can set the tristates in software. It sounds like you have it working correctly. Thanks, Arthur

Hi @davidhergueta Welcome to the forum. The max rate isn't specified. You can find other users trying to get Pmods going as fast as possible in various places around this forum, going back quite a while: We've comfortably been able to push 10+ MHz serial clocks for SPI interfaces through Pmod ports, but I would not expect 100 MHz to work. Thanks, Arthur

Happy new year! I'd recommend checking the elaborated design to make sure, but does the bresp register drive any other logic? It could be getting removed during synthesis due to Vivado thinking it is unimportant and unused - this is a normal step that the tools take and is important for reuse of modules, as, otherwise, plenty of unused logic could remain and eat up FPGA resources. One suggestion for keeping the signal around, according to this thread, https://stackoverflow.com/questions/30676741/how-to-cheat-synthesis-to-keep-an-unused-signal-without-using-special-compile, would be to use it to drive some otherwise unused FPGA pins, maybe on the Pmod headers.

No SREC bootloader required. They're typically used to copy a larger application from flash into DDR and then jump to start running the copied application. In that scenario, the bootloader would be merged with the bitstream similar to how the ELF file is merged here (though I believe Vitis/SDK will do that part under the hood, not positive) so that it starts running as soon as the bitstream is programmed into the FPGA. Whatever program runs on startup has to fit in Microblaze local memory, which an SREC bootloader can, but those larger apps running out of DDR cannot. Hope this helps.

Welcome to the forum!

Hi @jaberroteran10, Welcome to the forums! I ran through this guide with a Cmod A7-35T today and it worked fine in Vivado/Vitis 2023.1 for me: https://www.instructables.com/Flashing-a-MicroBlaze-Program/. A couple of notes: 1. It's easy to miss the bitstream configuration settings, like setting master SPI x4 mode, so please be sure to pay close attention to those steps. 2. A "Tristate CCLK pin during configuration" setting has been added to the Edit Device Properties -> Configuration screen. I left this as default. 3. The ELF file can be found in the application project binaries folder in Vitis after build: 4. I built the software app for Debug configuration, which could make a difference, and haven't tested building for Release. Thanks, Arthur

Looking into it. The calibration reader app expects the names to be "Zmod ADC 1410-105" and "Zmod DAC 1411-125", based on the original names of the products before a rebrand. The EEPROM contents that store the product model name must have been changed. Changing lines 23:27 and 53:57 of main.c in the calibration_reader app as follows should clear the issue, using this as the point of comparison if you've made any changes: https://github.com/Digilent/Eclypse-Z7-SW/blob/ddr-streaming/src/calibration_reader/src/main.c. Thanks, Arthur

I'm not sure if I understood your question - a SYZYGY pod is a separate physical PCB from the Eclypse baseboard, and is mounted on top prior to the board powering on. If no pods are present, there is no DNA, and the VADJA and VADJB rails aren't enabled by the PMCU, as they aren't used to power anything on the baseboard other than FPGA banks that aren't used when there are no pods present. The diagram from the manual refers to DNA located on pods connected to the corresponding Zmod ports - the I2C bus passes through the SYZYGY connectors.

My two cents: Zygot has posted about using EMIO for this kind of communication before and IIRC had posted a guide in the project vault. There are several different CSR generator tools floating around online that make it quite a bit easier to create AXI peripherals and drivers. From personal experience (personal opinion about the subset I've tried), cheby (https://gitlab.cern.ch/be-cem-edl/common/cheby/-/blob/master/doc/cheby-ug.pdf?ref_type=heads) and rggen (https://github.com/rggen/rggen) are easiest to use when also doing block design work, since VHDL files can be added to a project and directly instantiated as RTL modules, and generated drivers can be directly copied into a Vitis workspace. Cheby uses pretty simple YAML definitions of a register map and can be invoked from a command line like git bash (I'm primarily a Windows user at this point). AXI GPIO can also be used to directly control ports of RTL modules as well. This one is clunky and feels like a workaround though. See the screenshot below.