elodg

The reference manual listing 25 MHz is correct. The comment in the xdc file was incorrect, which is now fixed and pushed to Github. You can use Clocking Wizard in the FPGA to generate 125 MHz or configure the Ethernet PHY over MDIO to output 125 MHz on the sysclk port.

This is a legacy IP of ours for which there is no formal documentation. The source code is here: https://github.com/Digilent/ZYBO/tree/master/Projects/sdsoc/repo/digilent/ip/axi_dynclk_v1_0/src.

There are several things that can go wrong and the sensor datasheet is indeed less than helpful. You seem to be having CRC error and framing error in the status register. Also the number of long packets is wrong, 0xCCB = 3275. It is definitely a config issue. We don't provide VGA resolution configuration, nor a demo project with the CSI-2 IP. I would first make sure that a known good resolution config works with the Xilinx subsystem IP and then try lowering the frame and window sizes but compensating with blanking so that timings are not affected.

Artix-7 (and thus Zynq-7000) clocking architecture and speed grade does not support 148.5 MHz x 5 = 742.5 MHz BUFIO clock. Therefore, 1080p is overclocking the FPGA. Although it is expected to work at room temperature it is possible that it won't work over the whole temperature range and across silicon.

@John J, Have you managed to figure out what the issue was with programming the flash?

The PIC24 has a bootloader which can load custom applications or firmware upgrades from a pen drive. The attached pdf tells you how a custom firmware should be linked to be loaded by the bootloader. We can provide the original application firmware upon request to load back original functionality. You can also use a Microchip programmer/debugger to overwrite both the bootloader and the application firmware of the PIC. You will lose original functionality and we do not provide a combined bootloader & application firmware. No other support is provided on custom firmwares. Digilent PIC USB Custom Firmware.pdf

There could be an underlying issue with the DDR where this code is running from, or with the cache or interconnect configuration of the Processing System. @gueste, you could try stepping into the XGpioPs_CfgInitialize function, once you add the debug flags to the domain BSP (-g3 -O0). Did you try the Hello World and Peripheral Test example applications?

I am afraid using direct register access would mask an underlying issue. I haven't seen the PS GPIO driver buggy in any way. Verify returned pointer for NULL for proper error handling. Verify the device id you are passing. Verify the driver instance structure returned after init for the proper base address.

Test other applications like hello_world, and the Zynq DRAM Test example. There could be an issue with your hardware platform, specifically with the PS configuration. Use our board files with the Zynq Preset for the hardware platform.

That's right, our patches can only be re-used in the versions they were rebased on. Since the 2020.1 branch contains important patches related to the DDR4 initialization, I would upgrade to that version. If you insist on 2019.1, you can try back-porting the 2020.1 embeddedsw commits. We were forced to expand the approved DDR modules we ship the Genesys ZU with and those can only be supported with the DDR4 init patches.

There are more ways to integrate FSBL changes in the Petalinux flow, but the easiest is probably re-using our patches from here: https://github.com/Digilent/Genesys-ZU-OS/tree/5ev/oob/release/v2.1/project-spec/meta-user/recipes-bsp/fsbl/files You can also change the git repo url Petalinux pulls the FSBL sources from to our fork, which is the other way of doing this.

Sorry, I missed the fact about 2019.1. Check out the proper branches: https://github.com/Digilent/embeddedsw/tree/genesys-zu https://github.com/Digilent/Genesys-ZU-OS/blob/5ev/oob/v2019.1/project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi The latest board files work in 2019.1.

Use the latest board files: https://github.com/Xilinx/XilinxBoardStore/blob/master/boards/Digilent/genesys-zu-5ev/C.0/preset.xml Use the patched FSBL: https://github.com/Digilent/embeddedsw/tree/genesys-zu-21.1 Use the device-tree from the OOB demo: https://github.com/Digilent/Genesys-ZU-OS/blob/3b57a9d2eac8f2788387bc1b147b67bcda0fc373/project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi Let me know how it goes.

The Adept GUI is obsolete, replaced by Vivado Hardware Manager. Assuming your board is the Genesys ZU-5EV, the USB-JTAG port requires Vivado 2020.1 or later as described here. All necessary drivers come with the Vivado installer and are installed as "cable drivers". All four ports of the on-board USB 2.0 controller are listed as "USB Serial Converter x", which is correct. The hardware connection is established by the Hardware Server (hw_server) component. All Xilinx tools launch this process if it doesn't exist and connect to it. Therefore, it is actually hw_server which needs to be >2020.1 for the Genesys ZU to be recognized as a valid target. This could be an issue if you have multiple Vivado versions installed. Please run <Xilinx install dir>\Vivado\2020.1\data\xicom\cable_drivers\nt64\digilent\install_digilent.exe, to make sure the drivers are properly installed. Make sure the hw_server process is not running, kill it if it is and open Vivado 2020.1 Hardware Manager. The target should be detected and be programmable. You can also check which version of hw_server is running in Task Manager:

All expansion connectors are tested in manufacturing for short to ground, short to neighbor, and then continuity with a loopback board. What you are experiencing sounds more like an ESD damage to the FPGA pin. If you were to drive current through there, you might produce more damage.

As I said in the other similar post too, this is due to clock primitives being placed in a different region than the I/O primitives it should clock. In your case, since the RGMII input pins are fixed by the FMC pinout, you have to figure out why is bufio_rgmii_rx_clk placed in a different region. You might be trying to clock I/O primitives across multiple regions, which the BUFIO cannot do.

Re-install drivers from<Vivado install dir>\data\xicom\cable_drivers\nt64\digilent.

Thanks for the contributions. Your fixes seem to work for the Nexys Video in combination with rgb2dvi. I will not be merging them now, but scheduling its extension to the dvi2rgb and all HDMI/DVI Digilent board definition files.

Unroutability of top-level ports to pins usually arises when the output primitives (ODDR/OSERDES) are placed in a different region than where the pins are. It can be due to explicit LOC constraint on the primitives or placed there automatically because of restrictions on the clock region (MMCM is in a different region). Usually there are other warnings/errors that help you figure out what is happening.

Our demo apps and IP support our own camera offering, which is limited to the Pcam 5C for now. There are no immediate plans to introduce new features to our CSI-2 IP. Xilinx's CSI-2 offering has become free in the mean time, which might be the solution for you. I don't fully understand your second query, you can always use Vivado Block Design to make the necessary changes.

The mini-DP connector on the Genesys ZU is not a Dual-mode DisplayPort (DP++). In other words, it does not send DVI/HDMI signals, that a passive adapter cable could wire into a DVI/HDMI Sink. Use mini-DP to DP cables.

It is clear that the decoded hsync/vsync/vde signals are incorrect as they do not conform to a known timing. The DVI Sink IP considers any 10-bit word different from the four tokens defined in the spec as video data with VDE high. That explains the VDE pulses. Also, Hsync and Vsync can latch high, if a correct blanking token is followed by a non-token for long periods, until the next token is detected on channel 0. Every capture is consistent with non-DVI data being sent by the Source. I asked you to scope pDataInBnd, the deserialized raw 10-bit word before it is incorrectly decoded as token or 8b10b. You have not done that and there is no point in looking at any of the decoded control signals and pixels further. With the custom board and the pin experiment, it confirms that Source is easier to implement on Series-7 user I/O pins. There is no channel deskew and phase alignment to do (less primitives used), no external termination (50-ohm pull-up) to add, and the quite high pin-capacitance and package delay does not affect the signal as much as on the Sink side. The Sink side needs all the above, special attention needs to be paid to termination and a PCB simulation at the die is in order. You either have non-DVI signalling or signal integrity issues.

The path should be relative, so that the higher-up repo's remote url is used: https://github.com/Digilent/Genesys-ZU-SW/blob/3eg/master/.gitmodules https://github.com/Digilent/Genesys-ZU/blob/3eg/master/.gitmodules The only way you could have ended up with the ssh protocol in the submodule is if you cloned the top-level repos with that. Or, if we committed absolute URLs by mistake. I noticed that on https://github.com/Digilent/Genesys-ZU-SW/blob/5ev/demo/hdmi/master/.gitmodules, which will be fixed. I just tried your branch and https everywhere (at least on Windows). It does not make any sense why it would be different for you: $ git clone --recurse-submodules https://github.com/Digilent/Genesys-ZU.git temp2 Cloning into 'temp2'... remote: Enumerating objects: 131, done. remote: Counting objects: 100% (131/131), done. Receiving objects: 10% (14/131)% (106/106), done. remote: Total 131 (delta 41), reused 95 (delta 21), pack-reused 0 eceiving objects: 58% (76/131) Receiving objects: 100% (131/131), 32.75 KiB | 1.13 MiB/s, done. Resolving deltas: 100% (41/41), done. Submodule 'hw' (https://github.com/Digilent/genesys-zu-hw.git) registered for path 'hw' Submodule 'os' (https://github.com/Digilent/genesys-zu-os.git) registered for path 'os' Submodule 'sw' (https://github.com/Digilent/genesys-zu-sw.git) registered for path 'sw' Cloning into 'C:/git/temp2/hw'... remote: Enumerating objects: 1604, done. remote: Counting objects: 100% (993/993), done. remote: Compressing objects: 100% (492/492), done. remote: Total 1604 (delta 434), reused 942 (delta 397), pack-reused 611 Receiving objects: 100% (1604/1604), 98.84 MiB | 11.28 MiB/s, done. Resolving deltas: 100% (667/667), done. Cloning into 'C:/git/temp2/os'... remote: Enumerating objects: 2443, done. remote: Counting objects: 100% (2443/2443), done. remote: Compressing objects: 100% (948/948), done. remote: Total 2443 (delta 1507), reused 2345 (delta 1420), pack-reused 0 Receiving objects: 100% (2443/2443), 63.46 MiB | 9.82 MiB/s, done. Resolving deltas: 100% (1507/1507), done. Cloning into 'C:/git/temp2/sw'... remote: Enumerating objects: 258, done. remote: Counting objects: 100% (258/258), done. remote: Compressing objects: 100% (189/189), done. remote: Total 258 (delta 80), reused 213 (delta 52), pack-reused 0 Receiving objects: 100% (258/258), 6.32 MiB | 4.90 MiB/s, done. Resolving deltas: 100% (80/80), done. Submodule path 'hw': checked out '1392e4f249ed2afc16d1bb4443a847f1803eaf51' Submodule path 'os': checked out 'db19a8786eae8326a6698c4ccbdd15376c1ea19b' Submodule path 'sw': checked out 'dfb43ab79b1d163e01245e18ff42c4cec326a849' $ git checkout --recurse-submodules 3eg/master Switched to a new branch '3eg/master' Branch '3eg/master' set up to track remote branch '3eg/master' from 'origin'. $ git submodule update --recursive --init Submodule 'digilent-vivado-scripts' (https://github.com/Digilent/digilent-vivado-scripts) registered for path 'hw/digilent-vivado-scripts' Cloning into 'C:/git/temp2/hw/digilent-vivado-scripts'... Submodule path 'hw/digilent-vivado-scripts': checked out '6c2de1c8e376c56d7cb4555eee801a051d5d6e4b' Submodule 'repo' (https://github.com/Digilent/embeddedsw.git) registered for path 'sw/repo' Cloning into 'C:/git/temp2/sw/repo'... remote: Enumerating objects: 14, done. remote: Counting objects: 100% (14/14), done. remote: Compressing objects: 100% (12/12), done. remote: Total 14 (delta 2), reused 11 (delta 2), pack-reused 0 Unpacking objects: 100% (14/14), 12.55 KiB | 279.00 KiB/s, done. From https://github.com/Digilent/embeddedsw * branch 6e9e2fa973f2c27d3f979f3c07afdbe616f694a4 -> FETCH_HEAD Submodule path 'sw/repo': checked out '6e9e2fa973f2c27d3f979f3c07afdbe616f694a4' The "Empty Application" thing is a version incompatibility, I have seen it with 2021.1. Use 2020.1, the supported version instead.

Fixed the first issue, it was due to a bug. Thanks for noticing! https://github.com/Digilent/Genesys-ZU-SW/commit/92fd70bb087d51c4a940838617f746a379d676dd https://github.com/Digilent/digilent-vitis-scripts/commit/06d87cf03521237ffc41ae612e9187dfb8e8410c Workaround is to use the [getws] form, or an absolute path to checkout.tcl. Command [getws] returns the path to workspace set when Vitis was started. The GUI asks the user for a path, so if XSCT is started from the GUI, it will have a workspace set. The wiki recommends "sw/ws" for a workspace (which has the right gitignore set), which makes the [getws]/../src/checkout.tcl form work properly If XSCT is started from the console, a workspace is not set and getws returns empty. Set the workspace manually, as you did. The second issue is due to repo being empty. As you can see here, repo is a submodule. Whenever you check-out a different branch, execute git submodule update --init --recursive to check-out any submodules too. The third error should have a preceding line which tells you exactly what to do: It means that the workspace already has projects in it, which checkout.tcl does not want to overwrite.

You are hijacking this thread with other issues, which will confuse others in need of help and us as we are debugging this. Our Git workflow is described here: https://digilent.com/reference/programmable-logic/documents/git?redirect=1#vitis_sw_workspaces. The error message should have a preceding line which tells you exactly what to do: If you are still having issues with the Git workflow, please start a different thread. ----------------- Getting back to the flash issue at hand. The FSBL I attached, your Vivado/Vitis installation, and the commands listed in the post are the only things needed to confirm whether you are having a hardware or a software issue. It is essential that we eliminate an improbable faulty board first.