elodg

You tore some SMD pads from the top layer, those cannot be repaired. However, the outward row of 4 pads are shield, so two will have to suffice. The inward smaller torn pads are floating (1 and 4) so they don't have to be connected to anything. The two smaller pads with solder on are the differential pair (2 and 3) and must be connected. Pad 5 is ground and must be connected too. Good luck!

It look like you board flow interfaces are not picked up. Dig further.

If you open the synthesized design and navigate to the InputBuffer cell of dvi2rgb you will probably see the input tied to a constant, which causes placement to complain. Check the block design where the TMDS port of IP is tied to. It must go to a top-level port and it has to be constrained to a pin. If you are using board flow and it connects to a board interface, it should be set. Check the top-level wrapper vhd to confirm the top-level ports are generated for the HDMI/DVI input.

Yeah, ISE is no good as it does not work on Win 10. It last worked on Win 7, but that is outdated as well. You need to go with Vivado. OPTION#1 Vivado 2021.1 can pull in the board catalog form XilinxBoardStore, which is has the Zedboard defined. Just click Refresh. The XilinxBoardStore lists it under avnet.com as vendor: OPTION#2: You can install our board files using the steps from https://digilent.com/reference/vivado/installing-vivado/2018.2?s[]=vivado&s[]=init&s[]=tcl#installing_digilent_board_files.

We do not support non-Petalinux flows. However, I am attaching the final dts that results from the Petalinux build of https://github.com/Digilent/Genesys-ZU-OS/tree/3eg/oob%2Frelease%2Fv2.1. Do as you please.system-top.dts.pp

There are two separate issues related to flash device support on Xilinx platforms: Vivado support and software support. It seems that you are looking for the former, while this whole thread is about the latter. Vivado support is documented for each version in ug908, Appendix E: https://www.xilinx.com/support/documentation/sw_manuals/xilinx2021_1/ug908-vivado-programming-debugging.pdf#_OPENTOPIC_TOC_PROCESSING_d114e38049. It refers to the capability of Vivado hardware manager to be able to erase and program the memory device. There are no steps involved, Xilinx either supports it or not. I added a note to the reference manual about the minimum requirement for the Vivado version that supports the Macronix part. What others were discussing in this thread is flash support in software running on the FPGA device using the xilifs library. This is an open-source library that Xilinx includes in their Vitis tools and has a seperate list of supported devices. This we can edit and extend, which the documentation is referring to.

I would recommend using Michael's step-by-step guide (which is also in https://reference.digilentinc.com/learn/programmable-logic/tutorials/htsspisf/start) and editing the files in-place if you are not comfortable with versioning tools and patching sources.

Will update this thread when we have a conclusion.

Current consumption is not limited by the FPGA. Furthermore, thermal dissipation coefficients are board-dependent. Vivado has no way of knowing what the limitations of the board are. The board was designed with a 2.6 A current limit because that is what it can safely dissipate. All the power components are sized accordingly. You should refer to the board reference manual for power supply limitations: https://reference.digilentinc.com/programmable-logic/arty-z7/reference-manual#power_supplies, not the individual datasheet of the on-board regulator. We do not recommend you changing the current limit in TPS65400RGZ and drawing more current than the designed maximum. It will void your warranty.

I am sorry to hear about your troubles. Unfortunately, we only tested (m)SATA with 2019.1 and it looks to me that Xilinx changed the GTR calibration procedure in the FSBL since then. I suggest using 2019.1 with the Genesys-ZU-OOB-os/hw repos, which is the supported version. In the mean time we will investigate how the GTR link training changes affect SATA in 2020.1. May I ask what other issues needed fixing in the devicetree?

FMC modules are inserted in series into the JTAG chain. FMC modules must make sure to insert a device there or loop TDI back to TDO if JTAG is not used. According to the schematic jtag signals go to a header: https://www.xilinx.com/support/documentation/boards_and_kits/xtp078.pdf Just short the TDI and TDO pins on the module with a jumper.

If you are on external power already, then you are hitting most probably the current limit of one of the power supplies. Since it sounds like you are increasing the frequency of the programmable logic, most probably the VCCINT supply (1.0V) is getting limited. Since power consumption is project-dependent, do a power analysis in Vivado with the implemented project. However, only very complex designs should be hitting the 2.6A current limit on the 1.0V rail. Your project might not even meet timing constraints anymore with high logic utilization and high operating frequency. In other words, you might be having functional problems too with your project, apart from the current limit.

You are most probably hitting the USB port power limit (you did not specify how you are powering the board). The Arty-Z7 RM applies to the PYNQ-Z1 as well: https://reference.digilentinc.com/programmable-logic/arty-z7/reference-manual#power_supplies.

I added the maximum theoretical data rates for SATA (600MB/s) and PCIe (500MB/s) to the reference manual. I do not have benchmarks at the moment, but I recommend mSATA. Good mSATA modules should bench at least 200MB/s read speed.

The Genesys ZU was validated with a 16GB 2Rx8 ECC module (SQR-SD4I16G2K4SEBB). The PS DDR4 controller is limited to 34GB, so theoretically a sixteen-component 2Rx8 module (32GB) would also work. Keep in mind that dual-rank components max out at a one step lower data rate (1600-3EG; 1866-5EV).

A quick note here. The source files that need editing are part of a library (https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841939/xilisf) compiled into a bsp/domain. By navigating to the source files in SDK/Vitis, the local copy of the library's source files are opened. Any modification is done on this local copy and built into the static library (and application) upon build. However, when the source files of the bsp/domain are re-generated (context menu, Regenerate BSP sources), the changes are overwritten from the originals in the Xilinx install directory. Take care this does not happen. A more permanent solution is forking the library repository (https://github.com/Xilinx/embeddedsw) editing the sources there and including a path to the modified repository in SDK/Vitis Xilinx->Repositories->Global.

1. Table 8 from the datasheet shows how pins HSx_P and HSx_N can be swapped by the level translator: http://www.meticom.com/resources/Datasheets/MC20901-V1_08.pdf. It has been done for easier routing in layout. 2. LPx_LANE1 and LPx_CLK and uni-directional because the MC20901 can only do low-power reverse communication on either channel A or E, but only on a single channel. This is a transmission mode part of the MIPI D-PHY spec. The decision was made to make LANE0 the one supporting this mode. This is described in https://reference.digilentinc.com/reference/add-ons/fmc-pcam-adapter/reference-manual?s[]=fmc&s[]=pcam#low-power_reverse_communicationbus_turn-around_bta. Our Pcam 5C does not support low-power reverse com, but some other sensors might. The direction of communication is opposite of what you described. IC10 with DIR to GND transmits from B to A, or Pcam to FMC.

Is a known issue in our D-PHY IP. If you are getting nothing on the terminal I suspect you messed up something in the Vivado project while porting to 7010. I do not want to sidetrack you, but you could try the latest version of the project (2020.1), which has a 7010 port too: https://github.com/Digilent/Zybo-Z7-SW/tree/10/Pcam-5c/next. It uses a new project structure and versioning rules. Read this: https://reference.digilentinc.com/reference/programmable-logic/documents/git#vitis_sw_workspaces

I sent a PM to @manboy and @Paul Chang on this matter.

Frustratingly, I could never find the equation that worked consistently across resolutions for the HS values the camera uses. The sensor datasheet is not exactly verbose on the matter. Xilinx MIPI DPHY IP support is expected together with UltraScale+ support in a month or so. You can try setting a large value in the sensor for HS_ZERO, and try increasing HS_SETTLE in D-PHY Rx until it works.

You are on the right track. The settings that control the timing of the low-power high-speed transition need to match between the transmitter and receiver. It is easier if you scope it, triggering on an LP-10 state and measuring the time it takes for the sensor to switch to high-speed. The following registers control the camera timing: //MIPI timing // [5]=0 T_LPX global timing select=auto pclk2x {0x4805, 0x10},//Default=0x10 //T_HS_ZERO = MIN HS ZERO + T_UI*MIN HS ZERO_UI //MIN HS ZERO H (ns) {0x4818, 0x00},//Default=0x00 //MIN HS ZERO L (ns) {0x4819, 0xFF},//Default=0x96 //MIN HS ZERO_UI {0x482A, 0x05},//Default=0x05 //T_HS_PREPARE = MIN HS PREPARE + T_UI*MIN HS PREPARE_UI //MIN HS PREPARE H (ns) {0x4826, 0x00},//Default=0x00 //MIN HS PREPARE L (ns) {0x4827, 0x32},//Default=0x32 //MIN HS PREPARE_UI {0x4831, 0x04},//Default=0x04 We will get to publishing a Xilinx MIPI IP demo project eventually.

@hendog82, give us some info on your setup. What Petalinux version are you using and what kernel and apps recipes you configured for ptp?

The schematic can be found on this page: https://reference.digilentinc.com/reference/programmable-logic/cora-z7/start. The USB OTG Controller in the Zynq and the USB3320 PHY are versatile and support all USB roles, which is why you see it working. Your concern must be with the VBUS pin that can be supplied by the host or the OTG-A device. The power switch/current limiter NCP380 on the Cora Z7 is controlled by the USB PHY and ultimately by the driver running on the Zynq. Make sure VBUS power control CPEN of the PHY is inactive. The second concern is the amount of capacitance on the on VBUS. The Cora Z7 has a 150uF cap on VBUS (reference manual erroneously says the contrary) which is required for a host, but not allowed for a device. A device with big load capacitance can cause the current limit of the host to kick in during a hot-plug or power-cycle event. It is out-of-spec and functionality is not guaranteed.

$ git clone https://github.com/Digilent/Zybo-Z7-20-pcam-5c.git $ git checkout v2018.2-2 $ git submodule init $ git submodule update $ python digilent-vivado-scripts/git_vivado.py checkout This will re-create the Vivado project for the block design sources. Documentation for the scripts here: https://github.com/Digilent/digilent-vivado-scripts/blob/7b4d88aaa3c2c760167b2c563942f56e4a4cfce1/README.md.

This is a bug in Vivado which does not properly re-generate all the sources for the IP when it's re-customized. Resetting output products, clearing cache does not help. One possible workaround is to export bd to a tcl, delete the block design and source the tcl to re-create it from scratch. However, I already gave another possible way of doing this: checking out the source files and using the Python digilent-vivado-scripts to re-create the project. This workflow seems to work, as opposed to using the generated project from release. I created a commit to disable the debug module in future releases, as it makes more sense for the majority of our users. This will be picked up only in the next release cycle.