elodg

The IP conforms the AXI4-Stream Video IP and System Design Guide https://www.xilinx.com/support/documentation/ip_documentation/axi_videoip/v1_0/ug934_axi_videoIP.pdf, sub-section "Encoding Multiple Pixels - Static TDATA Configuration": LSB corresponds to leftmost pixel in a scanline.

CSI-2 can carry different data types, but uncompressed video data rarely deviates from raster order in the industry. The PCAM 5C is configured for RAW10 format. Each pixel (bayer filtered) takes up 10 bits. Pixel are transmitted consecutively for a complete horizontal line. Horizontal lines are transmitted consecutively for a complete frame. The horizontal resolution is the number of pixels in a line. The vertical resolution is the number of lines in a frame. This is how the CSI-2 Receiver block gets data from the PCAM 5C and outputs on AXI-Stream all the same. There can be exceptions for interlaced frames, compressed data like JPEG, or status information. None of these are in use in our demo.

I will have a look at this as soon as I have some time.

Black screen as in not locked to an input or locked, but the pixels are black? There are several reason why such a passthrough design wouldn't work. Since there is no frame-buffer, the source and the sink have to support a common resolution and the source would have to output at that. Does the cam work when connected directly to the TV? If yes, the resolution is 720p, choose that for both preferred resolution and clock ranges in the IP wizards. Connect pLocked to aRst_n of the next IP and to ILA or a LED to confirm the input side is working. Enable debug module in dvi2rgb and do a capture in Vivado Hardware Manager on the logic analyzer. Constrain the TMDS input clock in the top-level constraints file (check dvi2rgb.xdc).

Sent you a PM.

You have to understand the errors are not given by the sensor or the board, but rather the synthesis/implementation tool Vivado. I do not know what design you trying to create, but the errors are generic: the top-level ports listed there are not mapped to any FPGA pins. You either want to use those XADC ports to read out temperature data and process it inside the FPGA, or expose the bus to an external device wired to the FPGA pins and let it do the readout.

What is the status of the BUSY LED (LD11): https://digilent.com/reference/programmable-logic/genesys-2/reference-manual?redirect=1#usb_host_and_micro_sd_programming?

You most probably triggered the over-temperature protection of one of the power supply ICs. Depending which one, a power rail getting disabled can shut down the FPGA. The Kintex-7 itself has over-temperature shutdown enabled by default during pre-configuration only. After configuration it is only enabled if explicitly done so by the designer. Doc ug480, Thermal Management.

The ML Standard edition (formerly WebPACK) does not install device support for bigger parts. You will need to re-install the ML Enterprise edition with Kintex-7 support. The license you generated will be needed upon Synthesis or Bitstream generation.

Would you please make sure when using 2020.1 that the "hw_server" process is also from 2020.1? Just make sure the process ends when closing a different version, so that launching in hardware from 2020.1 launches the proper hardware server. Why do you say the download address is incorrect? If the application is linked to the DDR memory, offset 0x0 is the correct one. Before the elf is downloaded the PSU needs to be initialized. Xilinx recommends the FSBL flow instead of the psu_init.tcl init flow . One advantage of the FSBL flow is that it supports dynamic DDR init. Our Reference Manual lists the different memories the Genesys ZU can be shipped with and links to the FSBL that should be used: https://github.com/Digilent/embeddedsw/tree/genesys-zu-20.1. Please download the embeddedsw repo, add it to Vitis (Xilinx -> Software Repositories -> Local), and generate a new ZynqMP FSBL application. Once built, you can try launching it in hardware by itself to verify you are not getting a launch error. If it goes well, you can add it to your application's launch configuration as the FSBL to use. Watch the UART terminal for FSBL output.

Other than the R-2R resistor ladder for VGA output, there are no other DACs or ADCs on-board. You can extend it however with a Pmod: https://digilent.com/reference/pmod/start

XDC full of syntax errors. Get your act together. [Common 17-161] Invalid option value '#Package' specified for 'objects'. ["scr/constraint/xdc/clock1.xdc":7] Once fixed, both the MMCM and the input clock are placed in clock region with bank 34.

Are you using 2020.1?

There should be something more in the logs about this. It is either an unroutable situation, like the mmcm/pll placed in a different region than the input clock or a different xdc overwriting your constraints. Check the implemented design and its logs for the former, write_xdc command in the tcl console for the latter. Attach archived project here if all else fails.

Those are the correct primitives to use and 50ohm termination is required. Signals _P and _N should typically be swinging between 3.3V and 3.3V-0.5V. Differential swing between +0.5V and -0.5V. Vdiff_pp = 1V. I am thinking you might be looking at the wrong pin with the scope. Connect the ODDR output to a secondary OBUF (LVCMOS33) to debug this further. Open the implementated design and confirm placement.

I second zygot's idea. The Arty A7 has auto-negotiation enabled in the PHY. An unprogrammed but powered board should establish link to any Ethernet switch or auto-crossover supporting computer and light up the link LED. That would confirm that the MDI interface is working. If it does, the next step is seeing whether the MDIO interface towards the FPGA is working and if the PHY registers can be read and written. If that works too, data traffic on the MII interface should be analyzed, perhaps with ILA.

2021.1 seems to be working fine. Try that.

The error messages say that you have told Vivado neither the pin LOCation for the pllfout input port, nor the IOSTANDARD LVCMOS33. Is there an XDC file with those constraints?

Are you using the on-board USB/JTAG programmer? Our current supported version is 2020.1. I have never experienced that error in the two versions we supported: 2019.1 and 2020.1. I would suggest a downgrade and try the hello world example we have: https://github.com/Digilent/Genesys-ZU/releases/tag/3EG%2FHELLO-WORLD%2F2020.1-1.

The DSDB predates Vivado and board flow. You will have to make due with xdc and Zynq preset files. Board files bring a bit of convenience with the simplest of interfaces, but not by a lot.

https://digilent.com/reference/dsdb/dsdb#design_resources

https://digilent.com/reference/programmable-logic/genesys-zu/getting-started#rebuilding_the_out-of-box_image

For anyone else encountering this issue, there is an entry in the errata about it with an easy workaround: https://digilent.com/reference/programmable-logic/genesys-zu/reference-manual?redirect=1#bundled_microsd_card_missing_factory_oob_image

I added a new paragraph to the G-ZU reference manual JTAG section on the particularities of the FMC JTAG implementation for future reference. When you insert the XM105, the JTAG chain is broken, because the on-board switch looping back MPSoC TDO (FMC TDI) to FTDI TDO (FMC TDO) is de-activated. FMC TDI needs to be shorted to FMC TDO for the chain to be intact. If your probe does not do that, nor does it drive FMC TDO itself, it explains why the line is contant high. Again the FMC JTAG header is not the place for a JTAG programmer/debugger/tracer target connection. Your probe outputs on TDI, because it should connect to the input of the chain. Your probe expects input on TDO, which is the output of the chain. The FMC JTAG connection is part of the scan chain, ie. TDI input, TDO output. The Genesys ZU functions as intended.

Is the probe you are connecting a passive probe or an actual JTAG host adapter (programmer/debugger)? The user guide for XM105 states about the J5 FMC JTAG connector that "this interface is not intended to provide a means to program the FPGA on the board". FMC JTAG functionality provides a way to insert additional devices into the chain, not a programmer. FMC_TDO goes both to IC25 (FTDI) and J28 (external programming header).