elodg

The dynamic init feature is only enabled on Xilinx dev kits in the Xilinx FSBL. It can be easily enabled for other boards by patching the FSBL sources. The HyperX DIMM shipped with the G-ZU *should* work with the preset and static init. We will look into why this is not the case.

As explained in the RM, the DDR4 modules require dynamic DDR init, which is enabled in Vivado (sets a config parameter), and performed by the FSBL. The Xilinx FSBL code has conditional compiles only for Xilinx dev boards and our patches add the Genesys ZU too. You may use the pre-compiled FSBL from https://github.com/Digilent/Genesys-ZU/releases/tag/5EV%2FHELLO-WORLD%2F2022.1-2 with your own application. Or you can add the following repo to your Vitis workspace: https://github.com/Digilent/embeddedsw/tree/genesys-zu-22.1. This latter has the patches applied to the FSBL and will pull those in whenever you generate an FSBL project.

Seeing the issues we still haven't fully worked around in the latest versions, I recommend 2020.1.

J10 can be used instead of the on-board USB programmer to connect to the scan chain of the FPGA. These are dedicated pins and cannot be used for anything else. However, the scan chain can be used to transfer data in/out of the FPGA logic through the BSCANE2 primitive.

Finding shorts on power rails is problematic, since ICs are in parallel. There might be multiple shorts on the board, so it is probably toast.

From pg201: Port sdio_data_out[4] is SDIO_SEL in our schematic. It is a control signal for the level translator instead of SDIO interface proper. We determine drive levels using board-level simulation and prototype validation.

The USB-JTAG programming circuit is the only exception to our otherwise open schematic policy. The components you are now inquiring about have been redacted from the the schematic page with the note "This Page Intentionally Left Blank". This applies to all revisions and Digilent rev boards. If you want to copy our programming solution, you may license it from us. Or you can refer to Xilinx documentation for a different solution that might work for you.

There is a possible bug in the Vivado/Vitis 2021.1-2022.1 mini u-boot image used to program the flash. The mini u-boot image does not set a valid clock frequency, clock delay and data delay in certain cases. A workaround for the Genesys ZU is to use a hardware platform with a QSPI reference clock <= 250 MHz, which should make the flash programming work again. Taking a 2020.1 mini u-boot image and overwriting the one in later versions also works. This has been reported to Xilinx, let's see what fix they come up with.

Your board revision is written on the silkscreen just below the barcode. Our published schematics are generally correct. Designators do not have to be sequential and some components can be left not loaded. Digilent does not publish board layouts.

Some SD cards work better than others, and we tested the one in the kit for compatibility at the maximum data rate supported. Your failing images get stuck in u-boot after the BootROM and the FSBL have already successfully read the SD card. I suspect it has to do with the u-boot driver trying for UHS-I speeds at 208 MHz. Something fails during line tuning and results in errors. Going back to High-Speed mode at 3.3V should work with any SD card out there. This can be done from the device-tree: https://support.xilinx.com/s/article/69978?language=en_US. There are plenty of bugs in the SD controller driver and you can check Xilinx's changelog here: https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842090/SD+controller.

Hey @John J, Could you tell me where is the FSBL you are using with "Program Flash" is coming from? I noticed you are using Vitis 2021.2, but the FSBL is 2020.1.

We are trying hard to avoid changes between revisions that might break gateware/software compatibility. Our repo for xdcs is https://github.com/Digilent/digilent-xdc. Here are the differences between the two revs: $ diff Genesys-ZU-3EG-D-Master.xdc Genesys-ZU-3EG-Master.xdc 1c1 < #### This file is a general .xdc for the Genesys ZU-3EG Rev. D --- > #### This file is a general .xdc for the Genesys ZU-3EG Rev. B 261,263d260 < < ## Power-good input for VADJ supply rail < #set_property -dict {PACKAGE_PIN AA12 IOSTANDARD LVCMOS33 } [get_ports { pg_vadj_r }]; #IO_L12N_AD8N_44/24 Sch=pg_vadj_r Our published reference projects support both revs and you can ignore the "revB" in the constraint file name.

Your best bet is using Vitis and its Program Flash feature from the GUI. You can then record the tcl commands it executes in the XSCT console. Repeating the same commands in the XSCT console should yield the same result. The command you are looking for is program_flash and is described somewhat in https://www.xilinx.com/support/documents/sw_manuals/xilinx2021_1/ug1400-vitis-embedded.pdf.

Glad it worked. Umbrella repo: https://github.com/Digilent/Genesys-ZU/tree/3eg/master SW submodule with script instructions: https://github.com/Digilent/Genesys-ZU-SW/tree/38d18e311bf41830ad22bec9dfad83f6e2a3b6ee/src

In MIG designs where the processor and system clock is dictated by the DDR frequency and its clock ratio, the MIG should be the first to reset which stops the clocks, issues resets down the line, re-establishes clocks and releases resets. Do NOT use the processor system reset block to reset MIG. Either tie the external reset to MIG, or not reset the MIG at all, just the rest of the system.