artvvb

Personally, I would try to use AXI GPIO to push data into a shift register and try to do as much of the design as possible in an RTL module - using Microblaze to handle the UART interface and GPIO and not much else, with a single RTL module included in the block design at the top level. Saving writing and reading data from the BRAM until after you have a functional UART -> GPIO bridge would be appropriate, after which you could implement that BRAM in RTL instead of using IP for it. A first step would be to get a project set up that can receive a single UART character, then use an AXI GPIO to forward it to an RTL register that drives some LEDs.

AIN15 and AIN16 correspond to XADC auxiliary channels 4 and 12, respectively. These are tied to addresses 0x1c (Aux 12) and 0x14 (Aux 4) in the DRP interface. This is where the XADC demo selects addresses to read from using the DRP interface: https://github.com/Digilent/Cmod-A7-HW/blob/859446665e06c3ccc88fa57b4697477ec922a0d7/src/hdl/XADCdemo.v#L75. Thanks, Arthur

Hi @pepeok So I'm not sure about AXI BRAM, it may be possible, but I recall running into some issues (quite some time ago) with trying to control the same AXI BRAM from an HDL module and by PS through an AXI BRAM controller at the same time. If going this route, I'd assume the AXI BRAM would be configured as a true dual-port RAM. Using an AXI interface to write to block RAM is still a good approach though - I'm just not sure about how well the IP in block design would handle the use case. The first lab in this series might help if you're using this approach though - it at least shows wiring up the PS -> BRAM part of this communication path: https://digilent.com/reference/programmable-logic/arty-z7/intro-to-fpga. 200 ms is plenty of time for any number of different interfaces. Controlling a custom module with an AXI GPIO ought to work, though you need a way for the module you're controlling to tell when new data is available - using a second GPIO channel to toggle a bit back and forth whenever new data is available on the first GPIO channel would work fine. Hope this helps, Arthur

Hi Razvan1203, BRAM and DDR memories are available on the board and can be used to store data until it's requested by some external system. BRAM provides less storage space compared to DDR but is easier to use - both how often events occur that need to be stored and how many bits you need to store per event are relevant for determining the amount of memory necessary. There are various ways of connecting to the board to offload data, but UART communication might be enough for your application - it would be reasonably straightforward to put together a system that allows software on a host computer to request X number of bytes from the board via UART, and for the board to reply with that many bytes. Apologies if this is overly vague, it's a pretty open-ended question. Thanks, Arthur

Apologies, I haven't had a chance to take a look at your project yet, and may not tomorrow either. This is interesting, I would expect to see some kind of "multiply defined" error indicating that the same definition occurs more than once. It's still possible that there could be issues like this that don't generate that specific error though.

Hi Jeff, Welcome to the forums. There's no board file support or connection automation for the Zmod controller IPs. They're provided through the vivado-library repository on Github, but it's expected that you would base your designs on existing demo projects. I'd refer you to the following demos: https://digilent.com/reference/programmable-logic/eclypse-z7/demos/zmod-scope - Supports Petalinux and baremetal software, but is limited to Vivado & Xilinx SDK 2019.1. https://digilent.com/reference/programmable-logic/eclypse-z7/demos/zmod-awg - Supports Petalinux and baremetal software (and uses the same hardware platform as the above Scope demo), but is also limited to 2019.1. https://digilent.com/reference/programmable-logic/eclypse-z7/demos/low-level-low-pass-filter - PL-only demo that loops the input to the output using updated versions of the frontend controller IPs. https://digilent.com/reference/programmable-logic/eclypse-z7/demos/ddr-streaming - Baremetal software only, under construction as it's lacking some documentation, but improves on a limitation of the above demos where BRAM buffers can't record more than a couple of thousand samples. The release archives are for 2021.1, but ought to be usable in more recent versions. Hope this helps, Arthur

If you have multiple ethernet connectors on your computer, you might try each of them, updating an IP through the network and sharing center, like in step 11 here https://digilent.com/reference/programmable-logic/guides/zynq-servers#testing_the_server_without_a_dhcp_router, corresponds to one of them rather than all. The DHCP timeout is expected - there's no router there to handle DHCP. Based on the mention of RTL8211F in the printouts, did you update xemacpsif_physpeed as described in the prereqs section? https://digilent.com/reference/programmable-logic/guides/zynq-servers#update_ethernet_support_boards_with_rtl8211f_chip. I'm not sure what happens when the fix isn't installed, but will check with a colleague.

There's a utilization report that tells you where BRAM is being used, Implementation -> Open Implemented Design -> Report Utilization, in the Flow Navigator. Cutting the AWG output hardware from the design would get you some BRAM back that could be used in the Scope inputs. There might be some other places where BRAMs are being used, like in FIFOs for clock domain crossings. If you need substantially more record length, you'll need to switch to a different architecture that doesn't rely on BRAMs or downsample in hardware. This is an example utilization report from another project, 15 out of 16 BRAMs are being used by an ILA, out of the total 140 available:

I believe the echo server just implements a server - the serial console or python script acts as client. A board at my desk uses an SDC10/8GB Kingston microSD card, formatted as FAT32, which works fine. It's likely the equivalent of this one on our site: https://digilent.com/shop/microsd-card-with-adapter/. All sections of program memory are placed in DDR. The LWIP sources should be using malloc under the hood, which allocates memory in heap. A related question was answered here: https://support.xilinx.com/s/question/0D52E00006iHli2SAC/raw-lwip-memory-management-zynq?language=en_US. Yes. The linker script defines what parts of the compiled project get placed at what addresses. The AXI DMA has a register that the processor writes in order to specify the buffer's memory address. Using the xaxidma API, this is done through a call to XAxiDma_SimpleTransfer. The same call also sets the length of the memory buffer so that the hardware knows when it might overflow the buffer and corrupt things if it continues writing. See here: https://github.com/Digilent/Zybo-Z7-SW/blob/c21218c91e7d6dfd2018d35932a5f0d9d38eec9a/src/Zybo-Z7-20-DMA/src/audio/audio.c#L383 - the function call specifies that the DMA should transfer into a buffer located at MEM_BASE_ADDR, which is five times the number of samples bytes long.

The mask here represents pulling out one of two 14-bit values packed into a 32-bit word, so it should stay 3FFF. For the DMA, please confirm the width of buffer length register setting is large enough, it's an IP setting in the block design. I'm not sure where else to look, it looks like the window position register width in the AXI controller is also controlled by kBufferSize in the VHDL source, and the corresponding definition in the C++ sources defines it as up to 26 bits wide: https://github.com/Digilent/zmodlib/blob/f2f491971aa43fa23d3d2a1d6640d6f97ad69318/ZmodADC1410/zmodadc1410.h#L49C9-L49C40. Same for the S2MM length register width in software: https://github.com/Digilent/zmodlib/blob/f2f491971aa43fa23d3d2a1d6640d6f97ad69318/Zmod/zmod.h#L46C9-L46C45. I would also consider adding an ILA to the design (if possible, it also requires BRAM...), to take a look at the AXI stream signals going into the DMA. Thanks, Arthur

The idea is that folks would use development boards to start testing out IP that might be included in a design on their own boards while those boards are still being designed - verifying that some algorithm written in RTL will work, or that a firmware architecture concept is viable. That said, we're potentially interested in this kind of custom work and I've reached out internally.

Hi Paul, Yes, though to reiterate, I'm hedging about whether writing VHDL might be harder than a MicroBlaze design - if I was doing the design, it's what I'd personally look at first, but I have my own biases. This guide would be the recommended starting point within stuff Digilent hosts: https://digilent.com/reference/programmable-logic/guides/getting-started-with-ipi. Avoid DDR if possible, which would also mean avoiding some larger drivers or C libraries like stdio. You also need a way of moving data between the processor and the rest of your design. For low speeds, AXI GPIOs work (https://forum.digilent.com/topic/28261-qol-script-for-vivado-block-design-and-ps-pl-communication/) - I think I mentioned earlier, but latency and throughput for a microblaze based system will probably be fairly poor relative to a pure-VHDL-based solution, so the amount of data you need to move matters. When typing out an @, a dialog pops up with usernames, clicking on the user adds in a button, which sends the person a notification. It's helpful in case the person isn't subscribed to the thread. Thanks, Arthur

The block should be echoed back. If the TCP example receives a block of characters at once, it sends them all back at once. To confirm, you could print p->len in the recv_callback function. Yes, the echo server includes an internal buffer, which is located in DDR - all buffers and variables in the software application should be in DDR, you can check the linker script (lscript.ld) to confirm. I don't have personal experience with the UDP API. There are several template applications that should use it, but potentially no echo server example. Please review this guide: https://digilent.com/reference/programmable-logic/guides/zynq-baremetal-boot.

Hi Paul, If it was me, I'd likely try building out a microblaze system first, just because there are more drivers and example sources available. If too many FPGA resources are used, or if the latency involved in the processor receiving a request from hardware, reading data from flash, and forwarding it to the hardware, is too much, then I'd look into building out a custom controller or AXI master. In either case for custom RTL, there would be a fair amount of time spent with either the flash datasheets or AXI QSPI datasheets and simulating the design before going to actual hardware. I'm not sure which would be easier between the AXI design and SPI design - SPI itself is straightforward, but the complexity is in understanding the flash device's command set. I also admittedly have a bias towards processor-based designs. Thanks, Arthur

Looks like it updates a bit in SEQ04 and two bytes in SEQ05. This probably corresponds to the VP/VN channel and sixteen aux channels. The XADC documentation is a little bit frustrating, as it's typically talking about the DRP interface rather than AXI. Quote below is from the "Automatic Channel Sequencer" section of UG480. Offsets and addresses seem to be different for the AXI interface than DRP though, so those "4Ch and 4Dh" don't necessarily apply. It looks like PG019 is the actual document to be referencing: https://docs.amd.com/v/u/en-US/pg019_axi_xadc. I'm still reading, but haven't spotted if it details exactly what is in the SEQ04/SEQ05 registers yet.

Hi @alexplcguy There's no true standalone configuration for Digital Discovery - Analog Discovery Pro 3000-series is the only device that currently supports it. That said, you could run WaveForms on a cheap single-board computer: https://digilent.com/reference/test-and-measurement/guides/getting-started-with-raspberry-pi Thanks, Arthur

For others reading this in future, this thread continues over here:

Hi @stc Leuven Branch names in git are case sensitive - try the following for the out-of-box demo: Docs for it including setup instructions are here: https://digilent.com/reference/programmable-logic/eclypse-z7/demos/oob. Same for demos for the AWG and Scope 1410 Zmods: https://digilent.com/reference/programmable-logic/eclypse-z7/demos/zmod-awg, https://digilent.com/reference/programmable-logic/eclypse-z7/demos/zmod-scope. See the "setting up the baremetal projects" dropdowns. Thanks, Arthur

Hi @pdw For your outline as presented, in terms of complexity level, these steps concern me as they'd require building a custom AXI-lite master. If you're dead-set on using AXI Quad-SPI instead of a custom SPI controller, I would first put together a MicroBlaze design that uses it with the xspi drivers, so that you can build an understanding of what the IP's registers are doing and how you need to access them. It's currently undocumented on our reference site, but this demo was put together last year to write and read data from flash on a Nexys Video: Demo software main: https://github.com/Digilent/Nexys-Video-SW/blob/0987e797293f60b3caa27a400868bcf51b22c6a4/src/quad_spi/src/Flash_Memory_Test.c Demo release page: https://github.com/Digilent/Nexys-Video/releases/tag/QSPI%2F2023.1-1 A similar demo page which should include the bare bones for opening the project from a release: https://digilent.com/reference/programmable-logic/nexys-video/demos/axi-ps2. Generic git documentation: https://digilent.com/reference/programmable-logic/documents/git. Thanks, Arthur

There might be devices out there that can do the appropriate level translation, but that could get to the point of designing your own adapter from scratch. I'd recommend using a board with the connector.

Hi @Sergio Lopez How are you allocating buffers? If using something like malloc, you can increase the amount of memory available to the stack and heap in the linker script (lscript.ld). If you're using the predefined memory base address the demo uses, could you describe the errors you're running into? Thanks, Arthur

Hi digility, I'm not aware of performance impacts based on coding style, but the Language Templates in Vivado seem to use a single process (see the screenshot below). I'd recommend going through UG949, as it includes various other recommendations with definite performance impacts, like proper clocks, resets, RAM inference: https://docs.amd.com/r/2021.2-English/ug949-vivado-design-methodology/RTL-Coding-Guidelines. Thanks, Arthur

Hi @Bobsaito The Pmod specification is pretty loose about what can be defined as a GPIO Pmod. If something supports the defined electrical specifications, it's likely fine. Thanks, Arthur

Hi @Eran Zeavi Do other demo projects run successfully on your board? I would also confirm that the programming mode select jumper is set to JTAG and power cycling, as it could be related to a project actively running on the board while attempting to program it. Others have reported similar errors with other Zynq boards, and other threads may have useful troubleshooting tips, like here: Thanks, Arthur

Hi @Dniel.Schmid Digilent generally doesn't provide PCB design files for our products. Apologies. Thanks, Arthur