artvvb

Hi @Riccardo, Unfortunately the currently released demos aren't able to perform acquisitions this large at the max sample rate without significant modifications. Data is buffered in circle buffers in BRAM, which are then streamed through DMA to DDR once they are filled and a trigger is detected. These buffers are by necessity pretty small, in order to not use up all of the BRAM resources on the chip. They were implemented in such a away that theu aren't able to accept new data while they are streaming to DMA. Additionally, the DMA bandwidth between PS and PL is limited by how the AXI DMA controllers were configured and clocked - the AXI_S2MM transfers are 32 bits wide and clocked at the sample rate. This means that the even just the AXI control and response beats in an AXI_S2MM burst are enough to drop the theoretical bandwidth below the max sample rate of the Zmod, let alone the round-trip time of the AXI4-lite transactions used to manage the DMA simple transfers. If you do repeated acquisitions by triggering, receiving data, and rearming the system, it's guaranteed that your data isn't going to be continuous - there will be time gaps. To answer your questions directly: You can >technically< allocate memory buffers longer than the ADC buffer and fill them with repeated acquisitions, but samples will not be continuous. When using malloc, you should be aware of the heap size defined in the linker script, to avoid overflows. You can modify this value to significantly increase the amount of memory available to malloc. Yes feel free to modify the Zmod libraries and the hardware platform to fit your needs, however, when doing so, be aware of what the hardware is doing, and check the corresponding IP user guides. There is no mechanism implemented for changing the sampling frequency from software. We've been working on a project which might better fit your requirements. It's not fully released yet, so documentation is currently minimal and the code is somewhat messy and might still have bugs, but it might work better than the existing materials for this. It attempts to solve the buffer size limitation by increasing the bandwidth of the AXI_S2MM interface and switching to using the Scatter Gather mode of the AXI DMA to minimize the amount of downtime between successive DMA bursts on a long acquisition. A prerelease for Vivado & Vitis 2021.1 is available here [https://digilent.com/reference/programmable-logic/eclypse-z7/demos/ddr-streaming] - see the "s2mm_cyclic_transfer_test" app. The longest buffer I've tested with is 1 second @ 100 MS/s, though that was some time ago. More recently, a 0x400000 sample-long buffer was successfully acquired. Data transfer rates from the board back to the host are still pretty slow, so for long acquisitions, expect to wait a while for things to come back, and for potentially large amounts of PC memory to be required to store acquired data. Unfortunately, it also does not currently have a method for changing the sample rate without modifying the hardware design. Thanks, Arthur Edit: Either way, the hardware platform will still need modification to add something that can reduce the sample rate. The PL/PS data transfer mechanism in the newer project is likely better suited to this kind of thing since it can take a large number samples into a large DDR buffer.

Hey! It looks like you've run across a currently-in-development feature that we aren't quite ready to release yet. Some documentation on how to control the board with WaveForms should be coming in the next couple weeks.

Hi @Haiyan, Unfortunately, I can't say for sure, but it's unlikely. The Nexys 2 and Nexys A7 use entirely different FPGA parts (Spartan E3 versus Artix 7, respectively), so Microsoft would have needed to update their software with new bitstreams for the new board in order for it to be compatible, which the documentation you linked shows no evidence of. Thanks, Arthur

If you haven't yet, you could verify whether sin is the issue by checking the function calling sin by either throwing in some prints or stepping through it in the debugger. How are you converting data from floating point to u16s to load into the transmit buffer? (edit, just noticed getSignedRawFromVolt, ought to be fine, but verifying this in the debugger may be useful) It looks like m may not be required for C++ after all, as I ran the snippet below, successfully printing some nonzero values. This is the Xilinx AR I was referencing earlier: https://support.xilinx.com/s/article/52971 #include <math.h> #include <iostream> int main() { for (float i = 0.0f; i < 1.0f; i += 0.1f) { std::cout << sin(i) << std::endl; } return 0; }

Hi Zynq, The max value is 0x3FFF. The function sets a 14-bit field of the Axi Adapter's control register. See the IP user guide for more info: https://github.com/Digilent/vivado-library/blob/zmod/v1/2019.1-2/ip/Zmods/AXI_Zmod_DAC1411/doc/ZmodDAC1411AxiAdapter.pdf Yes, the sample rate for the DAC output should be 100 MS/s for any of the initially-released projects for Eclypse. Thanks, Arthur

File I/O isn't supported by default, as the demo uses a standalone (baremetal) OS. You'd need to add some way to either mount a file system or import the same data through some other mechanism (like including it in the text of a source file like a C header, as in your method of using arrays). Sending files over a serial connection is also possible, tera term (for example) has some built in features to support this, but you'd need to use something like the xuartps driver to implement something to buffer the received data in Eclypse software. To include and use the functions in the math.h header, you need to modify the C/C++ Build Setting of your application project by adding "m" to the list libraries to link in, see the screenshot below. You can use arrays as needed. If they are large (maybe larger than something like 4096 bytes by default), you may need to check that the linker script has sized the corresponding memory regions appropriately - to avoid stack overflows and such. It matters whether your array is a global, defined inside a function, or dynamically allocated. dacRampDemo seems to just be instantiated in place in the main.c file in the article you linked. Thanks, Arthur

Sure, sharing your solution so that others who run across this thread can see how you solved the problem is always appreciated. Thanks, Arthur

Hi @Udayan Mallik I'm not extremely familiar with this particular guide, however, at a glance, the Zmod IPs and DMA setup will be providing two channels of data simultaneously. Each 32-bit word in the acquisition should have data from both channels packed into it. The acquire functions in zmodlib only take in the channel index for the purposes of setting a trigger on that channel. The same goes for DAC transfers, data from both channels is packed into each word of a DMA transfer. Thanks, Arthur

Hi Markus, I'm yet to look into why the command might be failing to find the I2C device in Petalinux, however, there's a workaround. If you include the source code of dpmutil (it was renamed a while back) in a baremetal SDK or Vitis project, you can print the calibration coefficients using the FDisplayZmodADCCal and FDisplayZmodDACCal functions. You can find the sources in the dpmutil repo on GitHub. I've attached a Vitis 2021.1 project which implements that, and the source code of the main file is below, in case you are using a different version. vitis_export_archive.ide.zip (Edit: there may be some mistakes in this code, looks like the port info array is supposed to be 8 long instead of 2. I tested it with a Scope and AWG attached to the Eclypse and it prints out their calibration coefficients.) Hope this helps, Arthur #include "./dpmutil/dpmutil.h" int main () { dpmutilPortInfo_t pPortInfo[2]; dpmutilFEnum(FALSE, FALSE, pPortInfo); u32 ScopeIndex = 0; // Zmod Port A u32 AwgIndex = 0; // Zmod Port B printf("========= ZmodScope Calibration Coefficients =========\r\n"); FDisplayZmodADCCal(NULL, pPortInfo[ScopeIndex].i2cAddr); printf("\r\n"); printf("========= ZmodAWG Calibration Coefficients =========\r\n"); FDisplayZmodDACCal(NULL, pPortInfo[AwgIndex].i2cAddr); printf("\r\n"); return 0; }

Hi @Quello To confirm, are you booting from SD using the v0.3 release? Thanks, Arthur

Presumably you're already using this or something similar to build the project, but you can also run Vivado in batch mode from the command line to source a tcl script to perform any task that you could do in the GUI. There's a script called "program_flash.tcl" in the "ZIP Download" of this demo project that ought to be able to be adapted to work with any non-zynq board: https://digilent.com/reference/test-and-measurement/analog-discovery-studio/cmod-s7-demo The command to call it would be something like `vivado -mode batch -source ./program_flash.tcl`. Edit: The script has some values hardcoded for the Cmod S7, including the FPGA and flash part numbers, so you would need to edit it to get it to work with the Basys 3. Thanks, Arthur

Sorry for the belated reply, I'm looking into trying to replicate this bug, and have reached out to a colleague for more information. Thanks, Arthur

Hi @Zynq Were you able to get the projects up and running? This other thread indicates that you were able to get the projects running on the board (even if there are other issues presenting)? Thanks, Arthur

Hi @Eran Zeavi A coworker informed me that this error could be occurring when trying to program the board over JTAG while the programming mode select jumper is set in the QSPI position. Thanks, Arthur

Hi @Zynq It seems the linux platform dependencies are missing. The zmodlib sources appear to be in your workspace, since receiveCommands is there. However, the Linux-specific function implementations which are located in C sources down in zmodlib's linux folder aren't being found. If you haven't yet, I'd recommend running through the project settings described in the Linux Environment Project Setup section of the base library user guide to make sure that the project settings are correct: https://digilent.com/reference/zmod/zmodbaselibraryuserguide#linux_environment_project_setup1 Thanks, Arthur

Good to hear that it's working. It's still strange that the Zmod ADC IP might have been causing it. It might be possible that a hardcoded buffer address range in the software overlapped with the SPI driver. The version difference between 2020.1 and 2021.1 shouldn't be causing the issue. I haven't tried EMIO SPI with 2020.1, so *maybe* there's a critical difference in the xspips driver, but it's unlikely. Thanks for sharing your fix. -Arthur

Hi @Eran Zeavi Could you provide screenshots of the AXI4-Stream FIFO IP's configuration wizard? Thanks, Arthur

Hi @Hamed The Zybo Z7 uses a CLG400 part instead of a CLG225. The note in the TRM is referring to a different part with a package with less MIO pins (and pins in general) that doesn't include the physical connections required for SD card boot. The Zybo Z7-10 supports SD card boot through the process shown in this guide: https://digilent.com/reference/programmable-logic/guides/zynq-baremetal-boot. Thanks! Arthur

Hi @Eran Zeavi, Could you provide a link to the materials on Github that you are working on getting up and running so that I can try to reproduce the issue? Thanks, Arthur

Hi @gueste, I've been looking into it and haven't been able to reproduce the error. I've attached the Vivado/Vitis 2021.1 projects I've been using to try things out. It has some differences, but nothing that should be showstopping: primarily I made the entire SPI interfaces, as opposed to individual pins, external and constrained them to Pmod ports, including all of the _ss pins. I also disabled the Manual Start option in software. This project is functioning reasonably well on a board with the SPI pins hooked up to a logic analyzer and a loopback jumper installed from MOSI to MISO on SPI1. I've only tried JTAG debugging, which is working; I'm not getting the error you are seeing. I'm fairly confused as to where issues could be coming from. Looking through the selftest function, which claims to be "destructive", it looks like it should not be causing problems at the point in the code where it is being run, as the SPI hardware is reset both at the end of the selftest and at the end of CfgInitialize. What arguments are you passing to setupSPI? How are you initiating transfers, or are you not getting to that point with SPI1? Thanks, Arthur vitis_export_archive.ide.zip project_16.xpr.zip

Hi @kamalem2000, welcome to the forums! These warnings shouldn't affect using the Nexys A7 in a project in any way. They are related to board files for several Xilinx-produced dev boards. I suspect what happened is that you did not install Virtex or Zynq Ultrascale parts during installation of Vivado, and either these board files came installed by default, or you later installed them. The warnings are saying that you can't use those particular boards, since the models for the FPGA parts loaded on them aren't installed. Thanks, Arthur

Hi @Jim Brady You could potentially use the Pmod Bridge IP core in our vivado-library repository to wire an AXI IIC core to a Pmod port and set up some internal pullups (note you'd need version 1.1 of the core). The following is similar to the way that the Pmod Bridge handles it: Make the entire IIC interface external, then constrain the associated _io ports that get inferred - check the HDL wrapper for their specific names. IOBUFs ought to be inferred. Then you can use pull type constraints with these _io ports in your XDC file to enable some internal pullups in their buffers. I've attached a couple of screenshots of this, below. Alternatively, to avoid the inferred stuff, you could write a custom RTL module that instantiates IOBUF primitives directly and add it to your block design. Thanks, Arthur Block design with an external IIC interface Wrapper including inferred IOBUFs set_property -dict {PULLUP TRUE} [get_ports out2_T] Sample line of an XDC enabling pullups

Digilent hasn't gone through the process of updating and validating any of our projects in 2021.2 at this time. When running git_vivado.py in a version of the tools other than the version that the project was checked in with, it is expected that the block design would not be recreated. The Vivado project, represented on disk by the XPR file, once fully checked out will contain a block design including the Zynq PS, DMAs, and Zmod IP, configured so that they can be used to capture data. If you'd like to use the projects in a later version of Vivado than the one that they were created for, rather than using the git scripts, you can potentially work with a project ZIP archive. Vivado projects can be opened in higher-numbered versions as long as you have the project archive, so you can download the 2020.2 project I provided above, open it in 2021.2, and potentially upgrade any Xilinx IP that might have changed through Report IP Status. This isn't 100% guaranteed, because Xilinx IP and underlying properties of the tools can differ between versions, however, it would be a start. Unfortunately this won't include support for the Linux projects. The same goes for importing Vitis projects exported in a different version, though I'm less sure here. Thanks, Arthur

Hi Udayan, The Zmod ADC in this bundle is equivalent to the -105 variant (max 105 MS/s) of the (since-renamed) Zmod Scope. The Zmod DAC is equivalent to the AWG 1411, which runs up to 100 MS/s. Thanks, Arthur

The grounding scheme is suggested to reduce crosstalk that might appear with higher speed signals than you would be using with the Pmod RS232. I don't have numbers on when the crosstalk may become an issue, but don't expect that there would be issues with connecting the Pmod directly - I ran a Pmod VGA with an ~25 MHz pixel clock off of the Cora's Pmod ports successfully a couple of years ago.