artvvb

Yes, use LVCMOS33. Per the manual, https://files.digilent.com/resources/programmable-logic/zedboard/ZedBoard_HW_UG_v2_2.pdf, the PL Pmod pins are connected to bank 13, which is run at 3.3V. The master XDC sets the bank voltage for bank 13 to LVCMOS33 at the bottom of the file - https://github.com/Digilent/digilent-xdc/blob/fa60017608b914b6765c8620e85a3b97a36179bf/Zedboard-Master.xdc#L374C75-L375C75. You can also see that bank 13 is powered at 3.3 V in the schematics - https://digilent.com/reference/_media/reference/programmable-logic/zedboard/zed_sch_rev_f1-public.pdf.

Hi @CEEJ38, welcome to the forums. There are two versions of the Zedboard board files, one from Avnet and one from Digilent. Please make sure you are using the Digilent version as the Avnet version does not include Pmod interfaces - installation instructions can be found here: https://digilent.com/reference/programmable-logic/guides/installing-vivado-and-vitis#install_digilent_s_board_files. Alternatively, you can manually constrain your Pmod ports instead of relying on the board files. The "Add GPIO Peripherals to a Block Design" section of this guide discusses how to do this, in the context of some button inputs: https://digilent.com/reference/programmable-logic/guides/getting-started-with-ipi#add_gpio_peripherals_to_a_block_design. I would recommend this approach over the board files for this kind of I/O interface, as the board files and IP presets can obscure some important details of what is going on that are better to learn sooner rather than later (I/O constraints, configuring IP as necessary for the peripherals you're talking to, etc). Thanks, Arthur

I've attached a 2023.1 project with a simple simulation of the core configured for 10 MHz from a 100 MHz clock. Open it in Vivado 2023.1 and click Run Simulation. Make sure your data radix is signed decimal and waveform style is analog. dds-compiler.xpr.zip

There are no plans at the moment to update GitHub sources and the getting started guide on reference, but it's on our radar. In the meantime, as Attila mentioned, please refer to the Python samples that come in the WaveForms installer - they're comprehensive and actively maintained.

Hey Julii, Are you using Eclypse and Zmods or some other Zynq + ADC setup? The rest of my comments below assume Eclypse along with the IP cores provided for it that handle the ADC interface. If you're looking for the ADC configuration portion of this, the low-level low-pass filter demo might be helpful: https://digilent.com/reference/programmable-logic/eclypse-z7/demos/low-level-low-pass-filter. The ZmodScopeController IP used in the demo is specifically targetted to the Eclypse and the Zmod products that support it, but its architecture might be relevant for implementing a similar controller for another ADC and board - depending on the vendor of your parts, you may find similar controllers and examples provided by them. For designing the HLS module, Digilent doesn't have much if any material for it on the web. I'd recommend starting out by finding a passthrough example that you can work from and modifying it to suit your needs. This might be suitable (and the rest of UG1399 is also relevant): https://docs.xilinx.com/r/2023.1-English/ug1399-vitis-hls/AXI4-Stream-Interfaces-without-Side-Channels. How data is packed in the source AXI stream interface is also extremely relevant. For example, for the ZmodScopeController, the data format is defined in the IP Top Level Port Description table of the user guide on page 21 (particularly cDataAxisTdata), and in the ADC Calibration section, pages 7-9: https://github.com/Digilent/vivado-library/blob/master/ip/Zmods/ZmodScopeController/docs/ZmodScopeController.pdf. Thanks, Arthur

Could you share the rgb_gen source and IP configuration settings? Looking at the block design, please check your reset polarity. The "locked" outputs from the clocking wizard IPs are active high - when high, they indicate that the clocks are working. It looks like rgb2dvi and your rgb_gen module are working, but the data path through dvi2rgb may not be. Both dvi2rgb and rgb2dvi have active high resets by default, which are used in your design. What Digilent provides to test and debug the core is described in the "Debugging" section of the dvi2rgb IP core user guide, there are some internal logic analyzers that can be optionally instantiated and used to check signals while a board is programmed, but no simulation sources are provided (though you can still create testbenches yourself, as you are doing). Based on its datasheet, rgb2dvi doesn't have similar debugging logic.

@Abdullah1 The record configuration dialog includes this note for AD2: Unfortunately, this means that this recording is likely not possible with AD2, as USB 2.0 and buffer sizes limit the throughput over USB. The approx 3 MHz maximum rate is too close to your signal frequency, and you would only get one sample per period of the 2.5 MHz signal. Unchecking the "Noise" box may also help, as indicated by the note in the dialog, but I suspect that it won't help enough. Newer devices like the AD3 would be capable of this measurement due to improvements in the hardware - AD3 can do 32 kS at up to 125 MS/s or record for longer at up to ~10 MS/s, as opposed to the AD2's 16 kS at up to 100 MS/s or up to ~3 MS/s recordings. @attila may have additional suggestions. Thanks, Arthur

Hi @T106A81 Do you need the output sine wave to be 100 MHz or just the clock input? If the former, a 100 MHz input clock will not be able to produce it. Ultimately this IP iterates across an array of predefined values and you would need to provide a clock adequately faster than the output waveform. If a 400 MHz clock is used to generate a 100 MHz sine wave (as an example, I'm not positive the core can hit that speed on your board), the "sine wave" output would still only consist of four distinct samples and still appear as a triangle wave. For example, in simulation, a DDS core with a 16-bit output and phase angle increment set to "1" loops after approximately 65536 one-ns clock cycles. This is the amount of time it takes a 16-bit counter with 1 added each clock cycle to roll over. All this to say, to see a sine wave on the output, try to feed the core a higher clock frequency, drastically reduce your phase angle increment, or both. If you haven't, to select the correct configuration parameters, please review the IP datasheet (https://docs.xilinx.com/v/u/en-US/pg141-dds-compiler) and think about how the hardware it represents is architected. As a caveat, I don't have much experience with the DDS compiler. Thanks, Arthur

Hi @rarow Using AXI GPIO to control module ports works fine, for example: https://forum.digilent.com/topic/28261-qol-script-for-vivado-block-design-and-ps-pl-communication/, https://forum.digilent.com/topic/22978-axi-dma-help-on-cora-z7-10/#comment-85544. Could you provide a screenshot of how your GPIO IPs are connected to your nets, as well as some source code that controls the GPIOs? There are some gotchas, for example, if the AXI GPIO doesn't use "All Outputs" for the appropriate channels and the tristate pins are set to input, output signals are not driven - as workarounds for this specific issue, you could either use the All Outputs setting or you could drive your module ports with the _t pin within the GPIO interface, and use SetDataDirection calls instead of DiscreteWrite (assuming you're using the xgpio driver). Thanks, Arthur

Hi @bryan78 Try a custom waveform. The screenshots below show the equivalent for an amplitude sweep, but the principle would be the same for frequency. Frequency modulation could also do it. The equivalent using amplitude modulation is below. It would be easier if you don't need to worry about a consistent frequency at each stage of the sweep, as you could use a normal signal type like a triangle wave instead of a custom one. Thanks, Arthur

If your application allows you to reduce the sample rate below 3 MHz, you could use record mode, as seen below. I was able to successfully capture 60 ms of data at 2 MHz using AD2: The "base" setting in the config dialog lets you specify how long to record for.

Hi @yingju Apologies for the delay. A couple of additional pieces of information would help: What boot mode are the configuration mode select jumpers set to? They're described on page 27 of the manual: https://files.digilent.com/resources/programmable-logic/zedboard/ZedBoard_HW_UG_v2_2.pdf. Do you have an SD card with a boot image installed and have you programmed SPI flash? Thanks, Arthur

So there's a lot to it. The "UltraFast Design Methodology" document might be a decent thing to go through, as it describes Xilinx's recommended workflow: https://docs.xilinx.com/r/2023.1-English/ug949-vivado-design-methodology/Introduction. That said, the PDF version is well over 300 pages and the document assumes quite a bit of knowledge, though it does link to some summaries in the intro. UG903 also has a lot of info related to timing: https://docs.xilinx.com/r/2023.1-English/ug903-vivado-using-constraints/Introduction. A lot of what I've personally learned has come from clicking around in the tools, googling everything I see (which mostly results in finding various forum threads and answer records), and skimming any pertinent documentation I can find.

Hi @Manik Dautta I believe you need to update WaveForms and WaveForms SDK. Installers can be found via the WaveForms resource center - http://reference.digilentinc.com/software/waveforms/waveforms-3/start. The AD3 is supported by 3.20.1 and higher (3.21.3 is most recent). We've also updated the compatibility list for SDK on the reference site and appreciate the feedback - it had been missed during the launch of the AD3. Thanks, Arthur

Hi @SGdigi, welcome to the forums. The localhost connected in the hardware list means that the hardware server is up and running but it can't find your device. There are a couple of possibilities. 1. Please try using an alternate USB cable - some charging cables are not capable of transferring data. If you are using a cable that came with the board, it should be okay. 2. Drivers may not be installed correctly: Assuming you are using Windows - if not, please let me know what OS you are using - please use the Device Manager to check whether cable drivers are installed. You should see two USB serial converters as in this comment: If the device doesn't show up correctly, you should attempt to install the drivers either by installing Adept from this page - https://digilent.com/reference/software/adept/start - or by rerunning the Vivado installer from the Tools -> Add Design Tools or Devices menu option, as there's a checkbox on one of the screens that installs drivers (documented in this guide - https://digilent.com/reference/programmable-logic/guides/installing-vivado-and-vitis). 3. If neither of the above works, the programming circuitry on your board may be damaged, in which case you may need to pursue an RMA. Thanks, Arthur

Hi @Ppspendse Digilent doesn't provide example simulation sources for this core. If you haven't, please refer to the user guide: https://github.com/Digilent/vivado-library/blob/master/ip/dvi2rgb/docs/dvi2rgb.pdf. Sections on clock recovery and designing with the core should be helpful. Several other documents it references, including DDWG's DVI spec, may also help. Thanks, Arthur

Hi @Abdullah1 There are several options depending on which Analog Discovery device you're using. Assuming AD3, you could reduce the sample rate below ~10 MHz and should be able to record all 120 frames to the screen, using "Mode: Record". You would need to specify an appropriate samples count and sample rate in the Time settings to make sure all 120 events are recorded. Assuming 2 events per millisecond, 120 events takes 60 ms, and 600 kS at 10 MS/s should cover it. If information about the voltage signal between events is not important, you could use repeated triggers - if you are using the 3000-series Analog Discovery Pro, device buffering would let you capture every pulse. This guide was put together recently: https://digilent.com/reference/test-and-measurement/guides/waveforms-buffers. The gear dropdown next to the "Buffer" field near the Scope's Run button lets you configure the device to acquire multiple buffers of data sequentially, from repeated triggers. That said, each buffer may need to be individually exported. Thanks, Arthur

Hi @T106A81 I have not personally used Xilinx's DDS or FFT IPs. If you haven't reviewed their documentation, you should. pay attention to sections that talk about the formats of AXI stream interfaces in and out. FFT seems to be described in PG109, DDS in PG141. PG141's "AXI4-Stream Considerations" section (page 30) and the corresponding section of PG109 are both relevant. On an initial read of these sections, you likely need to introduce additional logic to the hardware design that can frame packets for the DMA; that can assert the TLAST signal at the appropriate time. For the DMA software side of things, you may find the example and common stumbling blocks that I described in this thread helpful: How you configured each IP is also relevant - the software described in the link above makes various assumptions about the configuration of the DMA core. Thanks, Arthur

A common issue that new users tend to run into, particularly with Zynq devices, is how to control custom modules in FPGA fabric from software. There are various techniques for this, including implementing custom AXI IP, using AXI GPIO controllers (what this post relies on), or using EMIO to control your modules via common communication interfaces (GPIOs, UART, SPI, etc). The goal of this post is to present a method for implementing this kind of communication that is relatively quick to set up and use, and that fits into a “standard” block-design-based workflow. Custom commands in Vivado can be used to run TCL scripts via a button press or hotkey. Attached is a script that when run, will take all selected ports on IP in your block design and create an AXI GPIO for each of them. These pieces together make it so that module ports can be wired up to a processor with only a couple of clicks. Note: This is intended as a way of building out a project quickly and potentially makes inefficient use of FPGA resources. It also doesn’t account for clock domains. I'd be curious for any suggestions for improvements that could be made. Setup: Download this script:create_register_file_from_selection.tcl. As is normal with downloading arbitrary code that will be run on your system from the internet, be careful and read through it before running it. In Vivado, open the Tools -> Custom Commands -> Customize Commands dialog. Click the plus button at the top of the list field to create a new command. Pick a name, shortcut, etc. Importantly, select “Source Tcl file” and fill the path to your downloaded copy of the script into the corresponding text field. The script is now installed. To run it for the first time, create a block diagram with some ports that you want to control. Select these ports by clicking on each of them. Use your hotkey or new button, found in the toolbar at the top of the screen, to run the script. You should see a new hierarchy created with several AXI GPIOs included, one connecting to each of your ports. Before: The start and high_count ports of a custom counter module are selected. After: GPIOs have been created for each of these ports. They can be connected to the PS as normal via connection automation. It should also be noted that control-Z will undo the actions performed by the entire script (as startgroup/endgroup commands are used). These GPIOs can then be used as normal from software, either by directly accessing their DATA registers or by using the xgpio driver. The following snippet of code could be used to toggle the start bit seen in previous screenshots. #include "xgpio_l.h" #include "xparameters.h" // ... u32 *start_reg = (u32*) (XPAR_CONTROL_0_START_GPIO_0_BASEADDR + XGPIO_DATA_OFFSET); *start_reg = 1; *start_reg = 0; I hope this helps someone out there be a little more productive in Vivado, and as mentioned previously, am interested in feedback/suggestions. -Arthur

Hi Martin, Strange characters showing up in the terminal could indicate a baud rate mismatch between your terminal and the board, I'd at least try to see if they become something intelligible with 115200 or 9600 baud, possibly some others. If there's a baud rate that works, printed statements could help us figure out what's going on. Your JTAG boot mode behavior sounds perfectly normal. I've asked some colleagues for ideas on what could be causing the failure to boot from SD - the DONE LED not lighting up means that the bitstream is not being loaded. Since the OLED is controlled from fabric, no bitstream means that the OLED wouldn't be controllable, so there isn't necessarily damage to the physical part. Thanks, Arthur

Hi @Julii The following describes a minimal PL -> PS transfer example. Code was tested on an Eclypse in Vivado/Vitis 2023.1. An AXI stream counter module is used to generate stimulus for the DMA's AXIS_S2MM port and Verilog source code for it is attached. It has a couple of control signals - when start is asserted, it asserts tvalid and counts whenever tready is asserted until it reaches a software-specified limit, at which point it asserts tlast, sends a final beat, and pauses until start is sent again. AXI GPIOs are used to hit the counter's control ports from software. Source code: axis_counter.v The DMA was configured as follows. Scatter Gather was turned off, the width of buffer length was maximized, and the read channel was disabled. Width of buffer length is an important parameter, as it defines the maximum number of bytes that can be sent in a single transfer (2**26 in this case). I didn't touch "allow unaligned transfers" but it would be helpful if you're working with u8 arrays, as it allows the software to be more flexible in where DDR buffers are located. \ The Zynq PS had the HP0 port enabled so that the DMA could use it to push data to DDR. For software, registers are directly accessed via pointers that are pointed at the corresponding addresses, to showcase how to avoid using the xaxidma and xgpio drivers. It follows the process outlined in the Programming Sequence -> Direct Register Mode section of the DMA product guide: https://docs.xilinx.com/r/en-US/pg021_axi_dma/Direct-Register-Mode-Simple-DMA. The software sets the Runstop bit in the DMA's S2MM control register, sets the destination address and buffer length, then configures the AXI stream counter and starts it. Once the S2MM status register's Idle bit returns to "1", it invalidates the cache and verifies that data has been successfully transferred. main.c This system accounts for several potential stumbling blocks: 1. The DMA S2MM interface's tready bit cannot be relied on to prevent data from flowing into the DMA before software initiates a transfer. It comes up as soon as the DMA comes out of reset. This means it's important to manually start upstream IP after setting up the S2MM transfer. 2. The module upstream of the DMA must assert tlast at the right time. If tlast is not asserted before the buffer that the DMA is pointing at would overflow, the DMA will lock up and needs to be manually reset to continue being used. 3. If the PS cache is enabled, data you're trying to write or access from software may not be the same as that seen by hardware. Manually flushing and invalidating relevant ranges of addresses ensures that the two are in sync. 4. Lastly, pay attention to where your buffers are placed in memory. If the memory segment they're placed in is not located in DDR, the DMA may not be able to access them. If the memory segment is too small, you may see issues like stack overflows. Hope this helps, Arthur

Hi Scary66, welcome to the forums. Unfortunately, Digilent doesn't provide a Petalinux example or other embedded Linux designs for the Genesys 2. Thanks, Arthur

Hi @Sergio Lopez, I2S data is signed, twos complement. I suspect that when the signal is ~0, it's toggling back and forth between numbers slightly above (~0x0000) and below zero (~0xFFFF), resulting in the wild swings you're seeing. This might also be obscuring the peak you're trying to detect - especially if the peak is a peak in signal amplitude with zero offset, which would still be switching back and forth between positive and negative. Thanks, Arthur

Hi Davide, To confirm whether it's an issue with the board or physical ethernet setup, does running the LwIP Echo Server example suggested by the guide work for you? I don't have much experience with the freertos OS and haven't tested that particular example as of yet. Thanks, Arthur

To be clear, yes, this concept is sound. I'm only concerned about doing it for both channels simultaneously and passing data up to software through a single DMA controller. Simulation for this kind of project would be best served by pulling apart the different pieces. Keeping it likely way too vague, you might write a wrapper and a testbench for everything in the stream between the ZmodScopeController and DMA, and verify that it responds to control signals correctly - for example, you'd set an "enable" bit in a testbench that simulates the pipeline instead of trying to include the software and PS in simulation through cosimulation. Doing simulations of small components regularly and on a small scale before integrating them together would be helpful to verify that assumptions we're making are correct. It's at a really low level compared to the entirety of the project, but this guide might help for starting to poke around the simulator UI, in case you haven't touched it yet: https://digilent.com/reference/programmable-logic/guides/simulation.