artvvb
-
Posts
1,067 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Posts posted by artvvb
-
-
26 minutes ago, boesterle said:
Could something similar be going on with the mm2s project?
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
-
On 1/24/2024 at 4:08 PM, evers4 said:
I've managed to resolve the issue with the factored out signal. As well as another problem involving the ILA. I found that I couldn't connect to the ILA debug core when programming the FPGA in Vivado, only when I ran the Vitis Project (programming the FPGA with both the bitstream and app) could I connect. I suspect that this is related to having the Zynq in the design which provides the Fabric clock driving the core.
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.
On 1/24/2024 at 4:08 PM, evers4 said:Now, I'm having success with the entire data path. From fabric to remote PC. However, I'm seeing errors in the data received. The error rate is low and is observed when sending large quantities of it (I'm sending 64MB at a time). What I'm finding is the combined summation of the len argument in sent_callback is greater than what I'd expect. I'm suspecting that this could be due to TCP retransmissions. As it turns out the callback indicates an acknowledgement from the receiver side of data to be sent, not that it was successfully transmitted.
Interesting, I'll need to do some debugging to confirm. Haven't had a chance the last few days.
On 1/24/2024 at 4:08 PM, evers4 said:I'm still sending a counting value 0->UINT32_MAX_VALUE, and verifying that each value received is value[i+1]=value[i] (Except on overflow). That data is mostly correct, but there are some segments with errors. I'm suspecting data reordering, retransmission, or transmission errors.
I'd like to try using the UDP protocol and compare the results. Is this straight forward? How would I go about modifying the Vitis project & script?
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
-
50 minutes ago, Xband said:
To try and diagnose and understand more wanted to run the simulation and ring out the triggering and clocks to help with understanding, but am getting a silly error that I've found others having in the AMD forums, "default_nettype is none" issues with a couple of clock signals.
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.
50 minutes ago, Xband said:Another problem is that the Vitis project seems to be locked and will not allow me so save my changes, thus every time I launch the project from scratch I need to go back and redo.
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:
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.
On 1/18/2024 at 2:46 AM, Saturn said:I want to read nmea data coming from GPS receiver module(u-blox) and display on the pc.
Do you have a datasheet for the part you're reading from? It should provide additional information like data formats and required baud rates.
On 1/18/2024 at 2:46 AM, Saturn said:I tried writing c-code to instantiate the uart. I struck here.
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
-
44 minutes ago, engrpetero said:
For the AXI Quad SPI (version 3.2), looking at the documentation, it seems the SPI output clock frequency is the AXI clock frequency divided by the 'Frequency Ratio'. If I use a Frequency ration of 16, it appears the output clock pulses happen about every .332 us which would correspond to an undivided frequency of 50MHz. From my review, it *seems* the AXI clock frequency is this one?
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.
-
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
Implimenting Etherent on the Zybo Z7 development board
in FPGA
Posted
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.