artvvb

Hey @peterhu There are a couple of options, you can flash the device using Vitis or Xilinx SDK (depending on the tool version you're using), or you can boot from an SD card. See this guide: https://digilent.com/reference/programmable-logic/guides/zynq-baremetal-boot. In either case, you would use the boot mode jumper (JTAG/QSPI/SD) to select which source you want to boot the board from. Thanks, Arthur

Hey @baywil, QSPI settings would potentially be helpful, either as screenshots of the configuration wizard or copied from the Block Properties pane's Properties tab (everything in the Config dropdown). Xilinx doesn't specify Fmax for ext_spi_clk for Spartan 7 in the AXI QSPI user guide (https://docs.xilinx.com/r/en-US/pg153-axi-quad-spi/Performance), but you may need to pass it a 50 MHz or slower clock instead, which can further be divided down. 25 MHz may also be too fast for the chipkit header pins. Common settings we've had work for Pmod connectors would be a 50 MHz ext_spi_clk with an x16 frequency ratio (3.125 MHz). Thanks, Arthur

Hi @Niranjana Please check your uploaded image, looks like it didn't come through correctly. Digilent doesn't provide any examples of an I2C slave at this time, but it should be possible to configure an AMD/Xilinx AXI I2C IP, or the Zynq PS itself via EMIO, to act as a slave. There's some info here which may be helpful: https://support.xilinx.com/s/question/0D52E00006hpi0rSAA/zynq-i2c-slave-readback?language=en_US, https://docs.xilinx.com/r/en-US/ug585-zynq-7000-SoC-TRM/I2C-Controller. Thanks, Arthur

Hi @Xband The ZMODADC1410 class is defined in the zmodlib sources https://github.com/Digilent/zmodlib/blob/master/ZmodADC1410/zmodadc1410.h#L82. The hello Zmod tutorial should show you how to import these sources. I'd also double check whether your application is using C++, C and C++ don't necessarily play nicely together in the same Vitis project. Thanks, Arthur

Hi @Razvan1203, I'm unaware of a feature in serial terminal applications like Tera Term or PuTTY that would signal key release events. One option is to put together a custom app or script capable of detecting keypress events and forwarding them to the board over USBUART. A script using the python pygame and pyserial modules would be capable of this. Plenty of guides exist online for getting keyboard input in pygame and sending data to a board via a serial port with pyserial. Alternatively, the Nexys A7 has USB keyboard support via an emulated PS/2 interface that you can use instead of UART. Check out the appropriate section of its reference manual for more information. There's also a demo that shows the use of a keyboard: https://digilent.com/reference/programmable-logic/nexys-a7/demos/keyboard Thanks, Arthur

Hi @OmerKv, Assuming you are using an Opal Kelly SZG-ADC-LTC2264 pod, Digilent doesn't provide example designs for it for the Eclypse, which means that you'd need to port an example design targeting another board (probably some Opal Kelly board) to Eclypse. I would expect that the B7 pin you are looking at is for a demo targeting another board, where the physical pin connections between various peripherals and the FPGA could be different. B7 is likely connected to some pin of the other host board's Syzygy connector. You need to compare the pin locations for the Eclypse and for the other host board, and modify the example design constraints so that the design's ports connect to the physical pin locations for the Eclypse. There could be other issues that come up as you port the design as well, for example, if the example design includes a Zynq PS configuration, you'd need to make sure to use relevant settings from the Eclypse Zynq preset as well as any relevant settings from the example configuration. Clocking architecture and various other things might also differ, depending on the feature sets of the two boards. Thanks, Arthur

Hi @dravenchrist The Nexys 4 and Nexys 4 DDR aren't pin-compatible, which means that any designs for one board need to have their constraints updated to match the new pin locations. The FPGAs on both boards are physically connected to the other components on the PCBs in different ways, and the tools need to be informed of this via the constraints. The Nexys A7 and Nexys 4 DDR should be the same as each other though. Check out the following resources: Nexys 4 template constraints: https://github.com/Digilent/digilent-xdc/blob/master/Nexys-4-Master.xdc Nexys 4 DDR template constraints: https://github.com/Digilent/digilent-xdc/blob/master/Nexys-4-DDR-Master.xdc Schematics: https://digilent.com/reference/_media/reference/programmable-logic/nexys-4/nexys4_sch.pdf There's also an old Nexys 4 to Nexys 4 DDR migration guide here: https://digilent.com/reference/nexys4-ddr/migration_n4 Various other resources on the reference site, here's the Nexys 4 resource center: https://digilent.com/reference/programmable-logic/nexys-4/start The Nexys 4 should be supported just fine in recent versions of Vivado. Thanks, Arthur

This is a pretty sketchy error - unintended clock domain crossings and missing location constraints. If you'd like help with issue, please provide additional information on the clocking scheme for your Zmods. Otherwise, I'm looking forward to hearing if the ILA design provided in another thread works for you. Thanks, Arthur

Hi @silverdiamond The following should work: WaveForms' Script Editor is based on JavaScript. Thanks, Arthur

Welcome to the forum, and thanks for sharing your solution!

Posted a project and some constraints over here: Just means that you are trying to use the same location constraint for two different pins - more incorrect constraints. sADC_Sclk_1 should probably be at AA13.

See attached. Two ZmodScopeControllers are wired up to external ports and an ILA. Ready and enable signals are tied high so that data will stream into the ILA on startup. After launching the software project from Vitis, the Vivado hardware manager can be used to verify that data is coming in, by connecting to the board and setting up a tvalid & tready trigger for the ILA, see attached screenshot of the ILA - note only 1 Zmod is active in this case, since I only tested with one Zmod plugged in, that said, I checked the same Zmod in both ports. There are a couple of warnings related to clocking, that are not issues in practice - a duplicate clock constraint in the ScopeController IP that could cause issues if the two Zmods used used different clock frequencies, and a redundant IBUF (I forgot to set the clocking wizard input to something other than single ended input clock). I think other warnings are either related to these, or unimportant. The error is irrelevant - related to powering off the hardware. I've also attached constraints and an export of the block diagram (design_1.pdf). Thanks, Arthur vitis_export_archive.ide.zip DUAL_ADC.xpr.zip ZmodScope_ZmodA.xdc ZmodScope_ZmodB.xdc design_1.pdf

I'm back in the office and am going to be looking into this when I get a chance - the XDCs missing these settings should definitely have them added, just not sure which yet. Likely all spartan and artix boards. It's a change we likely should have made years ago. Bitstream compression and as high of a config rate as possible are also no-brainers. To add on to board behavior, it should be the case that boards that have been programmed in a way that they don't boot from Flash on power on can still be booted from flash by pressing a prog button, assuming the board features one. Doesn't help when there is no prog button though, like on the Cmod A7. Thanks, Arthur

Hi @222mzb There are a few different ways to go here depending on how you're setting up your project, but, assuming you're working with Verilog source files, you can describe a memory and fill it with data using commands like readmemh. See here: https://projectf.io/posts/initialize-memory-in-verilog/. Whether this is implemented using block RAM or some other form of memory will depend on how the tools choose to go with it. Thanks, Arthur

Hi @Todd-Kairos Really sorry for the delay. I tried reproducing this using Opal Kelly's pinout for the Brain-1 and preset from their Hello World project on Github and was unsuccessful. The attempt is attached, though I can't confirm whether it would work in hardware. There are some details that could be helpful in diagnosing what's going on, in particular, I'd be curious what other clocks are being used in the design, and if other clocking wizards / MMCMs / PLLs are instantiated. Is there a chance you could share an archived project? Paraphrasing the quoted part of the IP manual: The Zynq core automatically generates FCLK constraints and the Clocking wizard automatically generates constraints for the downstream clocks based on its params. Additional constraints shouldn't be necessary. Thanks, Arthur brain-scope.xpr.zip

Merged in, thanks! -Arthur

Hi @rainwater As you see, yes. One way to approach this would be to use Xilinx's AXI DMA controller to write data passed to it via an AXI stream interface into memory, and to read it back out into a separate AXI stream. In this scenario, the MCU coordinates transfers. Just so you are aware - for someone just getting into FPGAs, this is non-trivial. Quoting the manual, "Both low speed and high speed cards are supported, the maximum clock frequency being 50 MHz. A Class 4 card or better is recommended.". In addition to any limits imposed by the PCB design, SD card, and Zynq chip itself, the level translator used limits the data rate to 15 MB/s. I'm not certain of the actual max rate, which may be lower than this. No, just Zmods and Pmods. Thanks, Arthur

Hi @Xband The AXI port names in the list of unplaced ports make me think that you have the wrong top module. Please make sure that the block design HDL wrapper is set as the top module for your project in the sources pane. It should be bolded, like here: You can change which module is selected as the top module by right-clicking on the one you want and selecting "Set as Top". Thanks, Arthur

Using the newer IP would be recommended. It at least handles clock constraints internally - no need to include things like the create_generated_clock constraint. Additional ports you are seeing are likely just some FIFO empty flags getting combined internally into the data overflow signal and the grouping of the data output into a stream interface with a valid/ready handshake. sEnableAcquisition did get added to the newer IP though, which can be used to delay when the DataStream interface starts pushing data, in case other IP downstream of it aren't ready to start receiving yet. That all said, shouldn't make too much difference which you use. Ah yeah, right. The usual way I've seen this kind of error come up is if the HDL wrapper hasn't been selected as the actual top module for the design, or if it hasn't been created yet, and Vivado is defaulting to using some other HDL module in the project as the top level.

There are some name mismatches: M20 showing up twice is fine in this case - both lines where it appears are commented out, and the Zmod Scope doesn't use that pin on the SYZYGY header. Some location constraints are still using Port A locations. Update to: Also, both create_generated_clock commands are sourced from the same pin, I'd expect the second instance to be pointing to a different cell in the block design, maybe "ZmodADC1410_Controll_1". I'm looking into creating a project that instantiates two ZmodScopeControllers for reference, but it may not be ready until next week.

Editing the wrapper is possible. Also, any changes to the block diagram should cause the wrapper to update, though it can be finicky. That said, duplicate names likely mean that things are connected to the same net - this is hardware design, all signal names represent some wire somewhere in the FPGA - if both Scope 1410 controller IPs are connected to the same input port, the design won't work correctly, since the inputs need to be connected to the actual physical Zmods.

Please review your HDL wrapper module, and confirm that all port names in XDCs match names in the wrapper. The issue with the github source that you linked is that it is intended to be used with a script that reproduces part of a block design, which also finds and replaces all of the "nameHier" text in the XDC. It then has the correct names of ports, since it creates the ports in a known way, as long as ports aren't manually renamed later. Thanks, Arthur

Hi Xband, Even using the script, you need to add location constraints to the template. Your best bet for Syzygy Port B constraints is to copy the Syzygy Port A constraints and switch out PACKAGE_PIN locations and port names for the port B equivalents. Going by the master XDC file, this would mean: Would be become: Where <sCh1CouplingL_portB> is your second Zmod ADC's equivalent external port's name. I'm also unsure as to why the Zmod DAC would be being referenced. It may help to reset IP output products in the Sources -> IP Sources pane, but I'm not certain. I'd probably need to see at least part of your sources hierarchy to say more. Thanks, Arthur

Hi @Zlxt Xilinx/AMD support may be able to provide more info about the DMAC than Digilent can. If I understand correctly, you want to repeatedly write to the same 8-bit register in a PL peripheral, using DMAC to copy data from an array in DDR. From what I can tell, this ought to be possible with DMAC. The actual typing of the array doesn't matter so much, since it's still fundamentally bytes in memory. As long as they are aligned and consecutive, there's no issue with casting a u8 array to a u16 pointer or a u16 array to a u8 pointer. So, the following should transfer a DMA_LENGTH length array located at Src to a single address. In this case, I tested it by DMAing to an AXI GPIO peripheral, gpio.BaseAddress is the data register for channel 1. A screenshot of a logic analyzer capture is attached. However, if there are gaps between the bytes you want to copy from the source array, XDmaPs_Cmd doesn't have a way of describing a way of describing an address increment other than the burst size. Either source data needs to be consecutive in memory, or you need to write your own version of XDmaPs_BuildDmaProg, effectively hand-coding your own DMA microprogram. AXI DMA should have some mechanisms to support this, but the drivers are structured very differently. Couple extra notes: You can also see in XDmaPs_GenDmaProg that the product of burst size and burst length for source and destination must match: Also, you might need to make sure that your AXI peripheral has a FIFO to buffer the data you're DMAing into it. The Zynq TRM has a couple of sections on how to approach this. See 9.4.3: https://docs.xilinx.com/r/en-US/ug585-zynq-7000-SoC-TRM Thanks, Arthur

Hi Michael, Thanks for the PR, we're looking into it, and I will update here once we've had a chance to review. -Arthur