artvvb

Hi @ManiS Sorry for the delay. I've passed your question on to another engineer with more Petalinux experience. For some more information, decutil (Digilent Eclypse utility) was renamed to dpmutil (Digilent platform management utility) some time back. You could potentially use it without the command line utility. Source code and an API that should be usable for both Petalinux and baremetal projects can be found in this repo: https://github.com/Digilent/dpmutil. You can find a baremetal example using it here: https://digilent.com/reference/programmable-logic/eclypse-z7/demos/ddr-streaming, source code here: https://github.com/Digilent/Eclypse-Z7-SW/blob/b42fb15a8ab4c52a38db2c15918cd7263e84f65e/src/calibration_reader/src/main.c. Thanks, Arthur

DNA refers to an EEPROM on the daughter board connected to the Eclypse via I2C. If it exists - which it does for all Zmods - then the PMCU will read it before the Zynq is up and running. Mentioning pods without DNA was only intended to cover a case where a custom pod was in development and the EEPROM for it hadn't been added to a prototype yet, or its contents were still being worked out.

This thread is pushing the bounds of my knowledge a bit, so grain of salt, but yeah, it's possible. DDR is "just memory addresses", you can access peripherals via interconnect while in an ISR as well. I would just be aware that you're potentially either blocking other interrupts from starting for as long as you stay in the ISR (by disabling interrupts), or you're potentially getting interrupted by other things coming through. This isn't super relevant until you're pushing the processor hard. Like if you have an interrupt that requires that the processor intervenes within a short time, while the processor happens to be busy copying a big array of data from one location to another with interrupts disabled.

C sources should include xil_cache.h and call Xil_DCacheInvalidateRange before accessing the memory that the IP has written into. I think what's happening is that the data written on the first pass is being cached and the cached values are being read instead of new stuff in DDR on every subsequent pass. https://github.com/Digilent/Zybo-Z7-SW/blob/c21218c91e7d6dfd2018d35932a5f0d9d38eec9a/src/Zybo-Z7-20-DMA/src/demo.c#L262 is where the audio demo invalidates cache for received data. Your base address and byte count for the call will differ. You might call this in the handler or wherever in your C source you're reading that data.

Hi @Jerin James The PMCU handles configuring the adjustable voltage rails as the board is powered on. After powerup, the PMCU can be communicated with to change settings if necessary and to do things like control fan speed. If SYZYGY pods with DNA are installed, the PMCU reads out their power requirements and uses that to configure the supplies appropriately - in this case, no changes are necessary. If SYZYGY pods are installed that do not have DNA, their power rails will not be turned on, and the decutil/dpmutil utility will need to be used to set the voltages for relevant VIO supply groups. Thanks, Arthur

Without having read the verilog sources yet, it sounds like you might not be invalidating the cache across the range of addresses that you're transferring data into before accessing them.

IRQ_F2P interrupts are all "SPI", shared peripheral interrupts, from p45 of the Zynq TRM:

Since the interrupt output is connected to a port, are you checking it with a logic analyzer? You could also wire up various signals to an ILA and view them via the hardware manager. To add an ILA to the design, you'd right click on any nets you want to test, select debug (screenshot below), then run connection automation to connect them all to ILAs. Then, when the bitstream is loaded onto the board (maybe while debugging in Vitis), you can open the Vivado hardware manager, and once the board is connected, some internal logic analyzers should pop up. This would let you take a look at the waveforms for the interrupt signal and any AXI traffic into or out of your module (I think by default the window size is 1000 clocks, centered on a trigger). Apologies if this is vague, we don't currently have any step-by-step content on the topic.

Ah, yeah, my bad, looks like it's rising edge sensitive. I'll need to see if I can reproduce. The acronyms are defined in the Zynq TRM: https://docs.xilinx.com/r/en-US/ug585-zynq-7000-SoC-TRM/Private-Shared-and-Software-Interrupts

XScuGic_SetPriorityTriggerType's last parameter sets the trigger type - active-high level sensitive. Given this, I would expect that the interrupt handler would access the peripheral that triggered the interrupt to clear the interrupt bit, which would remain high until this access happens. I don't see the custom_int port in the verilog source, so can't confirm when it is cleared, but the behavior sounds like the interrupt goes high and stays high.

The DMAs are configured to handle 32-bit streams, increasing the width is possible, but would likely make it so that samples might be dropped. Adding another DMA configured to receive another 32-bit AXI stream is possible but involved. 1. How many bits wide are the concatenated stream and the accumulator outputs? 2. Do you *need* to move data from both channels and both accumulators into DDR, or is it acceptable to only send some of it up? Even using all of the AXI stream signals wouldn't be necessary if you aren't trying to pass stuff to the processor - the ready signal in the interface passing data to your logic could be tied high (or to a software enable bit if there isn't another one further upstream), and the valid signal could be used as an enable for your logic.

@engrpetero This doesn't sound like an issue I've run across before, any specific steps to reproduce on a fresh machine would be helpful. All I can immediately think of to check is whether you used Tools -> Report IP Status to do any kind of additional upgrading past what happened when you opened the project before editing the IP in the packager. Edit: Also, any TCL logs from the project might be helpful. Either console output from when you were working with the project, or log and journal files (found in the working directory, C:/Users/(user)/AppData/Roaming/Xilinx/Vivado on windows). Thanks, Arthur

Hi @GSAS - Karthick You can find warranty terms for all boards purchased through the Digilent web store here: https://digilent.com/shop/shipping-returns/#warranty. Please let me know if you have further questions about this. Thanks, Arthur

I spoke to the engineer who maintains Adept, and he indicated that programming SPI Flash devices indirectly through an FPGA is generally not supported. The way that Vivado handles indirect programming of these devices relies on it shipping with bitstreams for different FPGA devices that provide bridge logic to various flash memories, with a wide variety of combinations supported, Adept doesn't have the same support (largely due to development cost and redundant features compared to the existing Vivado support). Platform Flash devices directly attached to the JTAG interface ought to be supported. As I understand it, XCFS Platform Flash is not the same thing as general QSPI memories and refers to a largely-EOL line of programmable memories offered by Xilinx. https://www.xilinx.com/products/silicon-devices/configuration-memory/platform-flash.html. For some more context on what you are trying to use Adept to do, what device are you trying to program? Thanks, Arthur

Welcome to the forums! USB Standard-A, via something like a USB A to C cable, will work with some caveats. There's some more information in the spec sheet: https://digilent.com/reference/test-and-measurement/analog-discovery-3/specifications#usb_interfaces. Depending on the combination of cable and laptop port, you may need an external power supply: https://digilent.com/shop/5v-4a-switching-power-supply/. Digilent doesn't carry an appropriate A to C cable on the web store. Hope this helps. Thanks, Arthur

This list is made up of "module name (filename)" pairs, and two module names in the list match. One of the files needs to be edited to change the module name so that Vivado can tell which module should be used when it is instantiated in other sources.

I reproduced this and I think fixed it. Below 1446 bytes, the system only actually sends a single burst, indicated by the sent_callback only being entered once per client request. Above it, multiple callbacks would occur, but some data would be lost. What seems to be happening is that submitting more data to tcp_write than fits in a single segment (typically 1500 bytes, slightly lower for a reason I'm not sure of here) maybe causes the additional data to be lost or ignored. What worked for me to fix it was to replace the tcp_sndbuf(tpcb) calls in the sent and recv callbacks with tcp_mss(tpcb), so that no more data than fits into a single segment is included in a single tcp_write call. "MSS" in the function name stands for max segment size. I've revised the code in the blog post. Thanks! Arthur

Hi @aied Board files presented in the create project view show both those from the XilinxBoardStore and those that you've downloaded and installed manually. I suspect that you are selecting the uninstalled board store version. You can also install these files within Vivado by clicking the download button, but when doing so, you might not get the most recent version, as a specific version of the board files is locked in with a particular Vivado version, and changes may have occurred after that board file version was submitted. See the attached screenshot: Thanks, Arthur

Hi @Rich E From what I can see, MCS files are only supported for programming Platform Flash devices that are connected to a JTAG programmer directly. This means that MCS files are not supported for programming the SPI flash devices typically found on Digilent's 7-series FPGA boards. Hope this helps, Arthur

Hi @hsaad The user manual mentioned by the JTAG-USB is available in the Adept install directory, "C:\Program Files (x86)\Digilent\Adept\Adept Application User's Manual.pdf" on Windows, for example. It has, however, not been updated in some time. Thanks, Arthur

Hi @Deffe The constraint comments have been fixed in the digilent-xdc repo and I've confirmed that the schematic pin names are correct. I've attached the spreadsheet used to compare against xc7z020clg484pkg.txt, in case you want to double-check. Eclypse Pmod Constraints.xlsx Thanks, Arthur

Hi Dante, Apologies for the delay. QSPI_SCK is also connected to pin L16. Access to CCLK_0 could also be achieved using the STARTUPE2 primitive. https://digilent.com/reference/programmable-logic/arty-a7/reference-manual#quad-spi_flash We'll need to look into why a location constraint for L16 is missing from the template XDC file. I would expect the following to work: Thanks, Arthur

Hi @Mania, Some of the demos talk through booting a prebuilt petalinux image from SD: https://digilent.com/reference/programmable-logic/eclypse-z7/demos/zmod-scope. Thanks, Arthur

Also, Whitney Knitter recently posted some tutorials for the Arty Z7 in 2023.2 that will likely be helpful: Vivado - https://www.hackster.io/whitney-knitter/getting-started-with-the-arty-z7-in-vivado-2023-2-26051a Vitis - https://www.hackster.io/whitney-knitter/getting-started-with-the-arty-z7-in-vitis-unified-ide-2023-2-1a8ee5

Hi @bloggins666 The xgpiops driver is used to control multiplexed input/output (MIO) GPIO pins in the Zynq Processing System (PS). These MIO pins are physically distinct from FPGA pins and are separate physical IOs on the chip. The xgpio driver is used to control an AXI GPIO peripheral. If you're using the board files to add an AXI GPIO to a block design, then that will control LEDs connected to FPGA pins on the programmable logic (PL) side of the chip. It's also possible to enable EMIO (extended MIO) pins that allow the hard GPIO controller in the Zynq PS to control pieces of the FPGA design, and then tie the EMIOs to FPGA IOs in the block design, so that LEDs that would normally be controlled by AXI GPIOs can be controlled by the PS GPIO controller. Probably clear as mud. All that is to say that, since you have axi_gpio controllers, use the xgpio (not xgpiops) drivers. Thanks, Arthur