artvvb

Some project releases require that you source a script in the TCL console, usually located in a "proj" folder in order to recreate an XPR file. Readmes you might find in the extracted ZIPs can provide more info. In the case of the Nexys 4 OOB, the process is documented online, start here: https://digilent.com/reference/learn/programmable-logic/tutorials/nexys-4-user-demo/start Note that pretty much all project releases are supported only in specific versions of the tools. Thanks, Arthur

The only substantial difference between the two revisions is which flash parts may be loaded on the board. This is described in the PCN document linked from the same page and in the reference manual's QSPI Flash section. There are stickers placed on new boards that indicate which part is used. https://digilent.com/reference/programmable-logic/arty-a7/reference-manual#quad-spi_flash Thanks, Arthur

Hi @exsurgo_ankit Not out of the box - the high range mode of the Zmod AWG is +-5 V. Output current may also not meet your spec. Refer to the AWG reference manual and the AD9717 datasheet for more info: https://digilent.com/reference/zmod/awg/reference-manual#arbitrary_waveform_generator, https://www.analog.com/en/products/ad9717.html Your pulse width and frequency range is achievable, either with a custom HDL design, or with something like the WaveForms software support for Eclypse Z7. Thanks, Arthur

These are ignorable. See the hardware errata section of the reference manual As seen in the thread you linked, either loop the fclk back to the GP0 clock port, or disable the GP0 interface. GP0 is normally used to control AXI peripherals, so it's enabled in the board files and normally the clock is connected when you use connection automation to connect peripherals, but since GP0 isn't being used here the clock isn't getting connected. Digilent isn't currently able to provide much help with Petalinux, but you might have some luck with these materials: https://digilent.com/reference/programmable-logic/zybo-z7/demos/petalinux https://digilent.com/reference/programmable-logic/documents/git Based on the linked forum thread, it sounds like the error commonly arises when you use a preconfigured project that is trying to support peripherals not in the hardware design. The petalinux project could be configured to remove those missing peripherals. Presumably, you would also need to make sure that the MIO SPI controller is represented in the petalinux project with a driver attached. Thanks, Arthur

There are a lot of resources around on how to learn Verilog, this one seems decent at a glance: https://www.chipverify.com/verilog/verilog-tutorial. Folks may also be able to recommend some good textbooks. Thanks, Arthur

For the constraints, use the Zybo-Z7-Master.xdc file instead of the Zybo-Master.xdc file. The latter is for an older version of the board, before a rebrand, and there are some pin location differences, including the clock pin. Thanks, Arthur

Hey asmi, Thanks, we'll get it updated. There's some history of using MHz when MT/s or an equivalent really should have been used instead. Cheers, Arthur

The XADC Setup section of Xilinx PG091 describes what the txt file consists of and how to use it. The design.txt file is an automatically generated default, that can be edited. See page 41. Thanks, Arthur

Hi @Cheeku, The port names used in the XDC file need to exactly match the top-level port names used in the project's top-level verilog module. This means that the "clk" and "led" signals that show up in the blinky module must be referenced by name in the get_ports parts of the constraints. The critical warning indicates that there might be a mismatch. Thanks, Arthur

Correct, the MIO Pmod port is not accessible from PL. You can potentially connect various PS controllers to its pins through the Zynq block's MIO configuration. Refer to this section of the reference manual to see which MIO pins are connected to it: https://digilent.com/reference/programmable-logic/zybo-z7/reference-manual#zynq_apsoc_architecture Thanks, Arthur

Hi @zoodle You are correct, that looks to be a mistake in the guide. If you continue through the guide to the point where an HDL wrapper is created and open the HDL wrapper, you will be able to see the top-level port names in the port list, these top-level ports are the names that the constraints must match. The port will appear as either gpio_tri_io, gpio_tri_i, or gpio_tri_o, depending on whether the GPIO IP is set to tristate, all input, or all output. The three ports you see on the IP end up getting automatically connected to a tristate buffer in the final design. Thanks Arthur

Hi @Cheeku At least Vivado and likely Xilinx SDK or Vitis are required to use the board. Installation instructions and guides can be found in the Zybo Z7 resource center, here: https://digilent.com/reference/programmable-logic/zybo-z7/start#tutorials Thanks, Arthur

Hi @Deepa V The page referenced by the title is part of a longer tutorial, found here: https://digilent.com/reference/programmable-logic/guides/getting-started-with-ipi Thanks, Arthur

Cheers, thanks for updating. I personally hadn't run across JTAG to AXI master before, it's pretty interesting for this kind of thing. Tried the IP out with a Nexys A7-50T and an AXI GPIO with the following script, and the connection worked fine. Issues in the constraints make sense. Thanks, Arthur

Check the linker script in the Vitis project source files, lscript.ld. Memory regions for each executable section can be assigned there. It will list either MIG or local memory for each section, if local memory is selected for all, should be good. In addition to associating the elf, the Vivado project needs to enable the Master SPI x4 programming mode in order to boot directly on power-up. I think currently, without it enabled, you can still boot the project by pressing the PROG button. See steps 2.3 - 2.7 here: https://digilent.com/reference/learn/programmable-logic/tutorials/arty-programming-guide/start - the guide is written for an older board and older versions of the tools, however, the process is largely the same in recent versions. Thanks, Arthur

Hi Miguel, A makefile error just means the build failed somewhere. There's typically a more informative error message in one of the build consoles, found here: One thing to check would be for spaces in any folders in the path to the Vitis workspace. Thanks, Arthur

If dip_elf is to run out of DDR memory, a bootloader would be needed. Assuming it's running out of microblaze local memory, the flow of associating the elf file with the Microblaze IP ought to work - the elf file needs to get merged into the bitstream to create a boot binary. Please check the position of the programming mode select jumper, JP1. Thanks, Arthur

Hi @Hamza Oncuer "Minimum speed" is the default speed setting for the installed fan and "Maximum speed" is the default for the case fan. Leaving it connected is recommended, but how hot the device would actually get would depend on the design that is running. If you're working with Vivado and Xilinx SDK or Vitis, fan settings can be checked and modified using dpmutil. Auto speed isn't supported for the case fan, but you ought to be able to decrease the speed. Sources, which can be used with pretty much any Vivado project, are here: https://github.com/Digilent/dpmutil/. Documentation is here: https://digilent.com/reference/_media/reference/programmable-logic/eclypse-z7/decutil.1.pdf Thanks, Arthur

We can't speak to everything yet, but here are a couple of pieces from the specs, and please let us know if you have more questions: Sample memory is improved by about 2x over the AD2, max 32 KiS internal storage per channel in various instruments, and the Scope can use 64 KiS with a single channel. Buffers can still be traded around between instruments depending on the device configuration, so the actual size depends on the selected configuration. There's a 7-series Xilinx FPGA inside instead of a Spartan 6. The maximum sample rate can be increased to 125 MS/s from a default of 100. Connectivity is USB 2.0 over a USB-C® connector, so don't necessarily expect a drastic change in record mode maximum rates - it is still improved, I believe some folks internally have hit 10 MS/s on one channel to PC RAM with the scope. Voltage ranges are the same 5 V peak-to-peak low range and 50 V peak-to-peak high range as the AD2, selected in the app depending on the range setting of the channel. Thanks, Arthur

Hi @serenekoala All of the IP in the vivado-library repository falls under the root level MIT license: https://github.com/Digilent/vivado-library/blob/master/License.txt Thanks, Arthur

Hi @feplooptest Even in older tool version, IP cores for each Pmod are generally only compatible with the corresponding Pmod. We haven't worked with the TPM20 internally, but I'd recommend running through this guide, which will show how you can connect Xilinx cores to external ports and constrain those ports to any pin on the FPGA (it uses AXI GPIO instead of some SPI controller, but the process is largely the same). You might be able to use a Xilinx AXI QSPI IP core to control this Pmod, however, it will require close attention to the timing requirements of the IP core and the Pmod, as well as the serial interface structure of the main IC on the Pmod's registers. A PS SPI controller connected to a Pmod port through EMIO might also work, but again depends on the specifics of the TPM SLB 9670. Thanks, Arthur

@ale.fdezsuarez How much faster do accesses need to be? Using two AXI GPIO channels as described should require two AXI4Lite transactions, one for the address write, and one for the data read - at least if you perform address reads and writes manually, the xgpio driver could introduce extra overhead. A custom AXI4Lite peripheral with an address space mapped to it would only require one AXI4Lite read transaction (there's a built-in example of this, and potentially some guides around the web). This isn't exactly the same as being twice as fast, but is probably close. DMA, and/or a custom AXI4 (not lite) controller, like zygot mentioned, would be necessary if you want to go faster than this. Xilinx's AXI DMA IP could also work, but has some catches/limitations and a potentially steep learning curve of its own. There's additional complexity with this if you want to use burst transactions, which are required if you want to significantly beat the performance of a custom AXI4-Lite core, or match DMA: https://support.xilinx.com/s/question/0D52E00007FSWkfSAH/zynq-axi-master-gp-burst-access?language=en_US Thanks, Arthur

Is the SRAM connected to the board via some Pmod ports or other IO? If you want to be sure about what the top level ports that need to be constrained for any particular design are, check the generated HDL wrapper's port map, it includes all of the individual names for ports that need to be constrained for each interface. GPIO are a common example, since the pins' actual port names differ depending on whether the interface is output only, input only, or use tristate buffers. Thanks, Arthur

Yes, boot image file size. The default offset from the flash base address used in the FSBL and flash programming wizard should be 0x0, referring to this Xilinx documentation. If you create your own boot image with a BIF rather than relying on the autogenerated one, you might also be able to append additional files to the end of the image, if desired. Thanks, Arthur

The input clock from the external oscillator is 100 MHz. The "450+ MHz" internal clock speed listed is based on maximum switching speeds within the FPGA fabric. The 100 MHz input clock can be used with clocking resources, MMCMs and PLLs, to generate various other frequencies of clocks including ones faster than the input. More info can be found in this Xilinx thread and in the Artix 7 datasheet. Thanks, Arthur