elodg
-
Posts
343 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Posts posted by elodg
-
-
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.
-
-
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.
-
-
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_rOur published reference projects support both revs and you can ignore the "revB" in the constraint file name.
-
On 10/11/2022 at 4:37 PM, sarvan said:
Hi Kvass,
We didn't have HS1 connector with us.
We were trying to flash the target via USB cable(microUSB - J8 Port ) with help of xilinx tools (XSDB tool).
We are able to load BOOT.BIN binaries into RAM memory via USB cable from XSDB tool.
But we our requirement to flash the binary into QSPI flash memory via USB cable using XSDB tool.
Any idea on how to flash QSPI memory via USB cable using xilinx tools?
Thanks,
SaravananYour 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.
-
On 10/12/2022 at 6:37 PM, Eminem said:
Hi @elodg,
I'm working with @John J on this project.
- We copied the psu_init.* files from platform/hw/ folder and using the the test code provided by @JColvin Then we cleaned and rebuilt all projects without updating the Hardware Specification which seemed to work.
- I'm not finding a sw/src/checkout.tcl file. Can you post a link to the build process that uses that file?
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.
-
If the device enumerates momentarily with the proper driver loaded, it sounds like there is some other software forcing re-enumeration or configuration change. Maybe a USB debugger or packet monitor?
-
Hey @John J,
We could reproduce the issue and I wanted to share the debug process and the solution.
Checked out the 3eg/master hello_world reference project. Activated UART1 in Vivado, exported and imported into Vitis. Added driver init calls for UART0 and UART1. Calling SelfTest on UART0 works, UART1 does not.
Tried reading addresses 0xFF000000 and 0xFF010000 with mrd in the XSCT console. Reading 0xFF010000, which is the UART1 base address fails:
xsct% mrd 0xFF010000 Memory read error at 0xFF010000. Blocked address 0xFF010000. Block level reset, bit 2 in RST_LPD_IOU2Indeed register RST_LPD_IOU2 (CRL_APB) at address 0x00FF5E0238 reads with bit 2, uart1_reset, set to 1. UART1 is being kept in reset, which is the reason for SelfTest (and any other action) failing.
Block-level resets should be de-activated during PSU init by the FSBL. If UART1 is enabled in Vivado, there should be a corresponding write to its reset in the exported psu_init.c. The exported psu_init.c indeed de-asserts reset, but the 3eg_fsbl/src/psu_init.c does not:
$ diff /D/git/zuca/sw/ws/3eg_hw_pf/export/3eg_hw_pf/hw/psu_init.c /D/git/zuca/sw/ws/3eg_fsbl/src/psu_init.c 1064,1087d1063 < * Register : UART1_REF_CTRL @ 0XFF5E0078 < < * Clock active signal. Switch to 0 to disable the clock < * PSU_CRL_APB_UART1_REF_CTRL_CLKACT 0x1 < < * 6 bit divider < * PSU_CRL_APB_UART1_REF_CTRL_DIVISOR1 0x1 < < * 6 bit divider < * PSU_CRL_APB_UART1_REF_CTRL_DIVISOR0 0xf < < * 000 = IOPLL; 010 = RPLL; 011 = DPLL; (This signal may only be toggled af < * ter 4 cycles of the old clock and 4 cycles of the new clock. This is not < * usually an issue, but designers must be aware.) < * PSU_CRL_APB_UART1_REF_CTRL_SRCSEL 0x0 < < * This register controls this reference clock < * (OFFSET, MASK, VALUE) (0XFF5E0078, 0x013F3F07U ,0x01010F00U) < */ < PSU_Mask_Write(CRL_APB_UART1_REF_CTRL_OFFSET, < 0x013F3F07U, 0x01010F00U); < /*##################################################################### */ < < /* 16267,16269d16242 < * Block level reset < * PSU_CRL_APB_RST_LPD_IOU2_UART1_RESET 0 < 16272c16245 < * (OFFSET, MASK, VALUE) (0XFF5E0238, 0x00000006U ,0x00000000U) --- > * (OFFSET, MASK, VALUE) (0XFF5E0238, 0x00000002U ,0x00000000U) 16275c16248 < 0x00000006U, 0x00000000U); --- > 0x00000002U, 0x00000000U);
Vitis does not automatically update the psu_init.* local copies in standalone application projects. These should actually be linked from the platform, but Vitis does not do that.
There are three work-arounds possible:
- Overwrite psu_init.* in 3eg_fsbl after every xsa import.
- Export xsa to sw/src/3eg_hw_pf. Checkout Vitis workspace again using sw/src/checkout.tcl.
- Generate boot components in platform project, internalizing fsbl and automatizing psu_init update. This hinges on Xilinx fixing the FSBL BSP optimization flag bug, which is the reason for externalizing the FSBL in the first place.
-
So your board is a Digilent Arty A7-35T.
If the power LED is on (https://digilent.com/reference/programmable-logic/arty-a7/reference-manual#features) and you are getting a USB Error in enumeration, I would try a different cable and different USB port. If it still does not work there might be a fault with your board. Check warranty conditions and the possibility of a return to the place of purchase.
-
-
Xilinx Artix-35T FPGA (xc7a35ticsg324-1L) is the FPGA on the board/eval kit you have. What is the name and brand of the board?
The on-board USB controller seems to be failing, but without identifying the board there is nothing we can do.
-
On 8/16/2022 at 4:15 PM, BMC99 said:
Was pulled away from this task for a few days.
I'm using the P2 IIC.
Actually using the xilinx ZC702 board with the digilent FMC adaptor. That means the i2c traffic goes from the PS I2C port through an I2C mux PCA9548ARGER on the xilinx board to the FMC I2C port. The scope shot that I posted was taken right at the pins of the TCA9546A on the pcam adaptor, so I know the traffic is getting through that mux correctly.
So if the ZC702 mux is confirmed working and the I2C traffic is channeled to the FMC Pcam Adapter, the next step is addressing the mux on that, the TCA9546A.
If TCA9546A has address 1110000, why am I seeing 1010000 as slave address (first byte)? From the looks of it you are actually writing the FMC Pcam Adapter FRU EEPROM offset E0 with data 0F. It explains why the second addressing of the EEPROM is nack'd, it being busy with the internal write.
-
Do not confuse PMU-FW with Platform MCU firmware, as they are separate processors. The original issue, the PS UART1 controller failing internal loopback has nothing to do with those, is odd and should pass just like UART0 in my opinion.
Sources:
The error is a data comparison error between sent and received bytes. The test indeed seems to be using internal loopback. The only difference I can think of can be the ref_clk configuration, which is independent for the two UART controllers. We use UART1 in our manufacturing test mapped to EMIO and it works. Our https://github.com/Digilent/Genesys-ZU-HW/tree/5ev/oob/master repo shows this.
-
You found the voucher license. If it is in a separate file, delete the other one, Clear Cache and Refresh. If they are in the same file you will have to find a way in the Xilinx License portal to delete the eval license or download them separately.
The reference manual recommends Vivado ML Enterprise Edition.
-
What you requested there is the standard 30-day evaluation license available without any voucher.
I added a section to the RM on how to redeem the Genesys 2 voucher: https://digilent.com/reference/programmable-logic/genesys-2/reference-manual#software_support.
Let me know how it goes.
-
@Tparng,
Let's make sure I am understanding this. You redeemed the voucher in the Genesys 2 kit, got generated a Vivado ML Enterprise license tied to your MAC address, got to use it for 30-days and it stopped working afterwards.
Please open Vivado License Manager and look for the license you generated. It should look similar to the screenshot below.
If your license has an expiration date and you can confirm that is was generated with the voucher in the kit, let me know and we will look into it.
BTW, the license is valid for one year of versions. This means you can update your Vivado ML Version up to the version listed in the "Version Limit" column in Vivado License Manager.
Setting Up the DDR4 on the Genesys ZU5EV
in FPGA
Posted
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.