artvvb

Hi @jmckinney I'm largely not familiar with FreeRTOS, but is there a chance that the data cache could be messing with the ability of the DMA to pull block descriptors from memory? https://www.freertos.org/FreeRTOS_Support_Forum_Archive/May_2016/freertos_Zync_UDP_TCP_with_DMA_IP_f531ef1cj.html seems potentially relevant. Caching issues are a pretty standard problem with non-scatter-gather DMA, where it just makes data unable to be seen by either side unless you flush or invalidate as appropriate. Pointers in block descriptors that aren't coming through as expected could cause all sorts of issues. If that's the cause, might be worth trying to disable the caches entirely, though I'm not sure how this affects the FreeRTOS setup. If you haven't, I'd also try putting an ILA on the DMA's AXI4-full master interfaces. Thanks, Arthur

You should manually update the hardware specification: https://digilent.com/reference/programmable-logic/guides/vitis-update-hardware-specification. Vitis generally won't see changes to the filesystem. When just overwriting the copy of the file buried in the platform project, I'd be concerned that Vitis might need to extract other files from it, which it might not happen automatically during a build - I expect it won't see the copy without the manual update. One common issue that could come up after this (though I don't think you'll run into it here) is that if your XSA file has a different name, the extracted bitstream name changes. In this case, you'd need to go into the system projects Run/Debug Configurations, and change the path to the file to reflect the name of the new XSA.

Hi Paul, Yeah, this is a result of the local memory being too small. It's come up in other threads, and as I understand it, you can adjust the memory size from the Address Editor: Thanks, Arthur

Hi RATHNA, Digilent currently doesn't support Code Composer Studio for any of our products. Thanks, Arthur

Hi Ellile, If the other end of your resistor is grounded, that should be correct - the "Energy through C1 100R C2" example, which seems to be what you're basing this on, calculates power from the current through the resistor multiplied by the voltage at the top of the resistor. Current is calculated as the voltage difference across the resistor divided by the resistance in ohms - so, if C2 would measure 0 by the other end of the resistor being grounded, the modified example is fine. Energy is calculated by integrating the power - summing it all up, with each sample multiplied by the amount of time between samples. There might be a little bit of error from the digitization process, but that's what having a sufficient sample rate is for. Thanks, Arthur Edit: Moved the thread to the T&M subforum, which is more appropriate for this topic.

Apologies for the delay. I haven't been successful in reproducing your setup. Some additional settings that might help are 1. the constant values applied to the CONFIG interface of the XFFT IP - I assume the tlast port is tied to a constant one. 2. XFFT settings - both the Configuration and Implementation tabs include settings that affect what values are provided to the CONFIG interface. I'd also be curious about why the XFFT S_AXIS_DATA interface's tlast port seems not to be connected - in simulation, not asserting tlast at the expected time causes the XFFT core to assert either an event_tlast_missing or event_tlast_unexpected error. If you haven't, please review the product guides for both of these IP cores: https://www.xilinx.com/support/documents/ip_documentation/xfft/v9_1/pg109-xfft.pdf https://docs.amd.com/v/u/en-US/pg141-dds-compiler

Hi @Kevin.C The betas are signed with the same key as a recent Adept Runtime release, here: https://digilent.s3.us-west-2.amazonaws.com/Software/Adept2+Runtime/2.27.9/digilent_public_key.asc. We've only recently started signing these installers. Your questions are very appreciated and should help us make sure these downloads are as clear as possible. Thanks, Arthur

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: