Differences

This shows you the differences between two versions of the page.

Link to this comparison view

programmable-logic:genesys-zu:reference-manual [2021/08/25 12:09] – [12.2 Platform MCU] Ioanprogrammable-logic:genesys-zu:reference-manual [2022/10/04 11:38] (current) – external edit 127.0.0.1
Line 7: Line 7:
 There are two variants of the Genesys ZU mentioned in this Reference Manual: 3EG and 5EV. These two variants are differentiated by the MPSoC model and some peripherals. As compared to the 3EG, with the 5EV you get slightly faster DDR4, more FPGA, a video codec, and GTH transceivers allowing HDMI Source, Sink and SFP+ 10G. There are two variants of the Genesys ZU mentioned in this Reference Manual: 3EG and 5EV. These two variants are differentiated by the MPSoC model and some peripherals. As compared to the 3EG, with the 5EV you get slightly faster DDR4, more FPGA, a video codec, and GTH transceivers allowing HDMI Source, Sink and SFP+ 10G.
  
-Used stand-alone with a hearty bundle in the box, powered by the 12V power supply, it straight up boots Linux from the microSD card. Connect the USB micro B cable to a PC and open a terminal (115200-8-N-1) to the first COM port out of the two that appear. Login and password are both "root". The red button labeled "POR" always resets the MPSoC and starts the boot process again. +Used stand-alone with a hearty bundle in the box, powered by the 12V power supply, it straight up boots Linux from the microSD card (whoops, [[programmable-logic:genesys-zu:reference-manual#bundled_microsd_card_missing_factory_oob_image|erratum]]). Connect the USB micro B cable to a PC and open a terminal (115200-8-N-1) to the first COM port out of the two that appear. Login and password are both "root". The red button labeled "POR" always resets the MPSoC and starts the boot process again. 
  
 Want to dive deep into development? Head over to our [[https://github.com/Digilent/Genesys-ZU|GitHub page]] and use the repos there as a starting point. Check out our [[programmable-logic:genesys-zu:getting-started|Getting Started Guide]] for a step-by-step. Build your own boot image on the SD card and boot it like the OOB demo. Not enough? Connecting the micro USB cable to header J8 will allow for on-the-fly programming and debug using Vitis or Vivado. Want to dive deep into development? Head over to our [[https://github.com/Digilent/Genesys-ZU|GitHub page]] and use the repos there as a starting point. Check out our [[programmable-logic:genesys-zu:getting-started|Getting Started Guide]] for a step-by-step. Build your own boot image on the SD card and boot it like the OOB demo. Not enough? Connecting the micro USB cable to header J8 will allow for on-the-fly programming and debug using Vitis or Vivado.
Line 327: Line 327:
  
 You need a JTAG programmer to connect into the JTAG chain of the Genesys ZU. There is an on-board USB-JTAG controller with built-in support starting Vivado 2020.1. Connect the bundled USB 2.0 A-micro B cable to J8 labeled PROG/UART (no. 3 in [[programmable-logic:genesys-zu:reference-manual#features|callout diagram]]) and a PC. This same connection will double as a USB-UART converter too, instantiating a virtual COM port on the PC. You need a JTAG programmer to connect into the JTAG chain of the Genesys ZU. There is an on-board USB-JTAG controller with built-in support starting Vivado 2020.1. Connect the bundled USB 2.0 A-micro B cable to J8 labeled PROG/UART (no. 3 in [[programmable-logic:genesys-zu:reference-manual#features|callout diagram]]) and a PC. This same connection will double as a USB-UART converter too, instantiating a virtual COM port on the PC.
 +
 +Up until rev B.1, the on-board USB-JTAG controller and USB-UART converter are powered from the Genesys ZU board, not from USB. This means that power-cycling the Genesys ZU board, with the USB 2.0 A-micro B cable connected from the PC to J8, will result in the UART and JTAG controller connections going away on the PC.
 +
 +From rev D.1 onwards, the on-board USB-JTAG controller and USB-UART converter are powered from the PC, via their micro B USB connection; they do not share supply lines with the rest of the Genesys ZU board. This means that power-cycling the Genesys ZU board, with the USB 2.0 A-micro B cable connected from the PC to J8, will not result in the UART and JTAG controller connections going away on the PC. Also, disconnecting the USB 2.0 A-micro B cable from J8 and reconnecting it, with the Genesys ZU board powered on, will not result in the Zynq Ultrascale+ SoC getting reset; this means that a project running on the SoC will not go away as a result of this reconnection.
 +
 +The JTAG chain includes the FMC connector too as required by the standard. Any JTAG device on the FMC mezzanine card is daisy-chained to the MPSoC using the TDI and TDO pins, thus extending the JTAG chain with additional devices. The standard mandates that if JTAG functionality is not used on the mezzanine card it must still loop back TDI to TDO, thus completing the chain. Some debug cards, like the Xilinx XM105, expose signals on pin headers but do not provide the loopback themselves. This will cause JTAG programmers (either on-board or external) to not detect the JTAG chain and the MPSoC anymore. When there is no mezzanine card in the FMC slot, an on-board switch loops back TDI to TDO, again completing the chain.
  
 External programming cables can connect to the 6-pin header J28. External programming cables can connect to the 6-pin header J28.
Line 352: Line 358:
 <-- <--
  
-For more details about JTAG see "JTAG Functional Description" section in [[https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf|Zynq UltraScale+ Device Technical Reference Manual (UG1085)]].+For more details about JTAG see "JTAG Functional Description" section in [[https://docs.xilinx.com/v/u/en-US/ug1085-zynq-ultrascale-trm|Zynq UltraScale+ Device Technical Reference Manual (UG1085)]].
  
 ==== 2.2 microSD Boot Mode ==== ==== 2.2 microSD Boot Mode ====
Line 365: Line 371:
   - Turn the board on. The board will now boot the image on the microSD card.   - Turn the board on. The board will now boot the image on the microSD card.
  
-For more details about SD boot mode see "SD Boot Mode" section in [[https://www.xilinx.com/content/dam/xilinx/support/documentation/user_guides/ug1137-zynq-ultrascale-mpsoc-swdev.pdf|Zynq UltraScale+ MPSoC Software Developer Guide (UG1137]]).+For more details about SD boot mode see "SD Boot Mode" section in [[https://docs.xilinx.com/v/u/2020.1-English/ug1137-zynq-ultrascale-mpsoc-swdev|Zynq UltraScale+ MPSoC Software Developer Guide (UG1137]]).
  
 ==== 2.3 Quad SPI Boot Mode ==== ==== 2.3 Quad SPI Boot Mode ====
Line 374: Line 380:
   - Turn the board on. The board will now boot the image stored in the Quad SPI flash.   - Turn the board on. The board will now boot the image stored in the Quad SPI flash.
  
-For more details about Quad SPI boot mode see "QSPI24 and QSPI32 Boot Modes" section in [[https://www.xilinx.com/content/dam/xilinx/support/documentation/user_guides/ug1137-zynq-ultrascale-mpsoc-swdev.pdf|Zynq UltraScale+ MPSoC Software Developer Guide (UG1137]]).+For more details about Quad SPI boot mode see "QSPI24 and QSPI32 Boot Modes" section in [[https://docs.xilinx.com/v/u/2020.1-English/ug1137-zynq-ultrascale-mpsoc-swdev|Zynq UltraScale+ MPSoC Software Developer Guide (UG1137]]).
  
 ==== 2.4 USB Boot Mode ==== ==== 2.4 USB Boot Mode ====
  
-It is the only boot mode apart from JTAG where the MPSoC takes a slave role. It shows up as a DFU (Device Firmware Upgrade) USB device to the PC, waiting for a configuration. Using this boot mode you will be able to load the newly created image on Zynq UltraScale+ via the USB Port. For more details see the "Boot Sequence for USB Boot Mode" mode in [[https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_1/ug1209-embedded-design-tutorial.pdf|Zynq UltraScale+ MPSoC: Embedded Design Tutorial (UG1209)]].+It is the only boot mode apart from JTAG where the MPSoC takes a slave role. It shows up as a DFU (Device Firmware Upgrade) USB device to the PC, waiting for a configuration. Using this boot mode you will be able to load the newly created image on Zynq UltraScale+ via the USB Port. For more details see the "Boot Sequence for USB Boot Mode" mode in [[https://docs.xilinx.com/v/u/2020.1-English/ug1209-embedded-design-tutorial|Zynq UltraScale+ MPSoC: Embedded Design Tutorial (UG1209)]].
  
 ==== 2.5 Status LEDs ==== ==== 2.5 Status LEDs ====
Line 392: Line 398:
  
 Main memory is a single-slot populated DDR4 SODIMM, always upgradeable by the user. It is wired to the PS (Processing System) side using the hard-core memory controller.  Main memory is a single-slot populated DDR4 SODIMM, always upgradeable by the user. It is wired to the PS (Processing System) side using the hard-core memory controller. 
-The bundled module up until rev B.1 is a 4GiB Kingston HyperX HX424S14IB/4. From rev D.1 onwards the following additional modules are approved to be bundled with the Genesys ZU without advance notice to customers: Micron MTA4ATF51264HZ-2G6E1, Integral IN4V4GNEUSX, and Kingston {{ :reference:programmable-logic:genesys-zu:cbd26d4s9s1kc-4規格書.pdf |CBD26D4S9S1KC-4}}. Accompanying software relies on dynamic DDR initialization code in the custom [[https://github.com/Digilent/embeddedsw/tree/genesys-zu-20.1|FSBL]] to configure the memory controller at runtime. More information can be found in [[https://www.xilinx.com/support/answers/75768.html|AR# 75768]] from Xilinx.+The bundled module up until rev B.1 is a 4GiB Kingston HyperX HX424S14IB/4. From rev D.1 onwards the following additional modules are approved to be bundled with the Genesys ZU without advance notice to customers: Micron MTA4ATF51264HZ-2G6E1, Integral IN4V4GNEUSX, and Kingston {{ :reference:programmable-logic:genesys-zu:cbd26d4s9s1kc-4規格書.pdf |CBD26D4S9S1KC-4}}. Accompanying software relies on dynamic DDR initialization code in the custom [[https://github.com/Digilent/embeddedsw/tree/genesys-zu-20.1|FSBL]] to configure the memory controller at runtime. More information can be found in [[https://support.xilinx.com/s/article/75768|AR# 75768]] from Xilinx.
  
 Although some modules support >DDR4-2400, the data rate is limited by the MPSoC and the board. The 5EV board variant supports <wrap hi>DDR4-2133*</wrap>, while the 3EG supports DDR4-1866 in single-rank configuration. In dual-rank configuration the maximum data rate falls to <wrap hi>DDR4-1866*</wrap> on the 5EV and DDR4-1600 on the 3EG. Although some modules support >DDR4-2400, the data rate is limited by the MPSoC and the board. The 5EV board variant supports <wrap hi>DDR4-2133*</wrap>, while the 3EG supports DDR4-1866 in single-rank configuration. In dual-rank configuration the maximum data rate falls to <wrap hi>DDR4-1866*</wrap> on the 5EV and DDR4-1600 on the 3EG.
Line 400: Line 406:
 ==== 3.1 Implementation ==== ==== 3.1 Implementation ====
  
-There is a single SODIMM slot on the top side of the Genesys ZU just north of the MPSoC. It is wired to the PS-side memory controller and supports any SODIMM module complying with the memory controller's restrictions. These are detailed in the [[https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf|Zynq UltraScale+ Device Technical Reference Manual (UG1085)]], but common modules of 1R/2R, x8/x16, 64b/72b are supported.+There is a single SODIMM slot on the top side of the Genesys ZU just north of the MPSoC. It is wired to the PS-side memory controller and supports any SODIMM module complying with the memory controller's restrictions. These are detailed in the [[https://docs.xilinx.com/v/u/en-US/ug1085-zynq-ultrascale-trm|Zynq UltraScale+ Device Technical Reference Manual (UG1085)]], but common modules of 1R/2R, x8/x16, 64b/72b are supported.
  
 The serial presence detect (SPD) interface is wired to MIO8 (DDR_SCL) and MIO9 (DDR_SDA), accessible through the I2C1 controller.  The serial presence detect (SPD) interface is wired to MIO8 (DDR_SCL) and MIO9 (DDR_SDA), accessible through the I2C1 controller. 
Line 415: Line 421:
 CRC is calculated both by the controller and the DRAM to avoid data corruption in the the write data burst. It can detect single bit, double bit, odd count and one multi-bit UI vertical column errors. Upon error detection, DRAM will assert the ALERT_n line. The controller should retry the write upon error. CRC is calculated both by the controller and the DRAM to avoid data corruption in the the write data burst. It can detect single bit, double bit, odd count and one multi-bit UI vertical column errors. Upon error detection, DRAM will assert the ALERT_n line. The controller should retry the write upon error.
  
-It should be enabled in systems that expect a high amount of signal integrity issues and where high reliability is desired. It trades data rate for reliability. CRC support is optional in SODIMM modules. Even if the module supports it, implementation is not easy. For CRC to work the controller must know what pin swaps were performed on the memory interface. In case of SODIMM modules, there are some restricted pin swaps possible and must be documented in the SPD EEPROM. The controller is expected to read these, combine it with pin swaps on the system board and assign the bits to CRC inputs accordingly. According to [[https://www.xilinx.com/support/answers/68788.html|AR# 68788]] this can be achieved through the DDRC.DQMAP registers, not well documented.+It should be enabled in systems that expect a high amount of signal integrity issues and where high reliability is desired. It trades data rate for reliability. CRC support is optional in SODIMM modules. Even if the module supports it, implementation is not easy. For CRC to work the controller must know what pin swaps were performed on the memory interface. In case of SODIMM modules, there are some restricted pin swaps possible and must be documented in the SPD EEPROM. The controller is expected to read these, combine it with pin swaps on the system board and assign the bits to CRC inputs accordingly. According to [[https://support.xilinx.com/s/article/68788|AR# 68788]] this can be achieved through the DDRC.DQMAP registers, not well documented.
  
 ---- ----
Line 480: Line 486:
  
 The microSD connector J9 located on the top side has a hinge-based mechanism. It is compatible with UHS-I allowing 1.8V signalling and speeds up to SDR104, or 104MB/s. The microSD connector J9 located on the top side has a hinge-based mechanism. It is compatible with UHS-I allowing 1.8V signalling and speeds up to SDR104, or 104MB/s.
-To enable UHS-I support and speeds up to SDR104, see the following Answer Records from Xilinx: [[https://www.xilinx.com/support/answers/69978.html|]] and [[https://www.xilinx.com/support/answers/70062.html|]].+To enable UHS-I support and speeds up to SDR104, see the following Answer Records from Xilinx: [[https://support.xilinx.com/s/article/69978|]] and [[https://support.xilinx.com/s/article/70062|]].
  
 ==== 4.3 mSATA slot ==== ==== 4.3 mSATA slot ====
Line 498: Line 504:
  
 The PL on Genesys ZU has a clock source of (by default) 25 MHz on pin E12 (SYSCLK), coming from the CLK_OUT pin of the Ethernet PHY IC36 (DP83867CRRGZR). This LVCMOS18 I/O standard clock can be used for any purpose in the PL, with certain restrictions: The PL on Genesys ZU has a clock source of (by default) 25 MHz on pin E12 (SYSCLK), coming from the CLK_OUT pin of the Ethernet PHY IC36 (DP83867CRRGZR). This LVCMOS18 I/O standard clock can be used for any purpose in the PL, with certain restrictions:
-  * It enters the FPGA via HDGC (High-Density I/O Bank Global Clock) pins. These can only directly drive BUFGCE primitives, not MMCM/PLL primitives. See Global Clock Inputs in [[https://www.xilinx.com/support/documentation/user_guides/ug572-ultrascale-clocking.pdf|ug572]]. It can still drive MMCM/PLL indirectly, but this will need a CLOCK_DEDICATED_ROUTE FALSE constraint, otherwise Vivado DRC will fail.+  * It enters the FPGA via HDGC (High-Density I/O Bank Global Clock) pins. These can only directly drive BUFGCE primitives, not MMCM/PLL primitives. See Global Clock Inputs in [[https://docs.xilinx.com/v/u/en-US/ug572-ultrascale-clocking|ug572]]. It can still drive MMCM/PLL indirectly, but this will need a CLOCK_DEDICATED_ROUTE FALSE constraint, otherwise Vivado DRC will fail.
   * Is available whenever the PHY is out of reset and is not specifically configured through its registers to disable this clock. By default it is synchronous to the crystal input of the Ethernet PHY (25 MHz).   * Is available whenever the PHY is out of reset and is not specifically configured through its registers to disable this clock. By default it is synchronous to the crystal input of the Ethernet PHY (25 MHz).
  
Line 515: Line 521:
 The Genesys ZU provides several different methods of resetting the Zynq Ultrascale+ device, as described in the following sections. The Genesys ZU provides several different methods of resetting the Zynq Ultrascale+ device, as described in the following sections.
  
-==== 6.1 Power-on Reset ====+==== 6.1 Power-on Reset Signals ====
  
 The Zynq Ultrascale+ PS supports external power-on reset signals. The power-on reset is the master reset of the entire chip. This signal resets every register in the device capable of being reset. The Genesys ZU drives this signal from the PG_ALL signal of the power supplies in order to hold the system in reset until all power supplies are valid. The Genesys ZU also has a red push button, labeled POR, which can toggle the power-on reset of the Zynq Ultrascale+. The Zynq Ultrascale+ PS supports external power-on reset signals. The power-on reset is the master reset of the entire chip. This signal resets every register in the device capable of being reset. The Genesys ZU drives this signal from the PG_ALL signal of the power supplies in order to hold the system in reset until all power supplies are valid. The Genesys ZU also has a red push button, labeled POR, which can toggle the power-on reset of the Zynq Ultrascale+.
Line 527: Line 533:
 The external system reset button, labeled SRST, resets the Zynq Ultrascale+ device without disturbing the debug environment. For example, the previous break points set by the user remain valid after system reset. Due to security concerns, system reset erases all memory content within the PS, including the On-Chip-Memory (OCM). The PL is also cleared during a system reset. System reset does not cause the boot mode strapping pins to be re-sampled. After changing boot moode jumpers a power-on reset is needed to act on the new setting.  The external system reset button, labeled SRST, resets the Zynq Ultrascale+ device without disturbing the debug environment. For example, the previous break points set by the user remain valid after system reset. Due to security concerns, system reset erases all memory content within the PS, including the On-Chip-Memory (OCM). The PL is also cleared during a system reset. System reset does not cause the boot mode strapping pins to be re-sampled. After changing boot moode jumpers a power-on reset is needed to act on the new setting. 
  
-For more details about configuration pins see "Clock, Reset, and Configuration Pins" section in [[https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf|Zynq UltraScale+ Device Technical Reference Manual (UG1085)]].+For more details about configuration pins see "Clock, Reset, and Configuration Pins" section in [[https://docs.xilinx.com/v/u/en-US/ug1085-zynq-ultrascale-trm|Zynq UltraScale+ Device Technical Reference Manual (UG1085)]].
  
 ---- ----
Line 639: Line 645:
 ==== 9.2 HDMI Source* ==== ==== 9.2 HDMI Source* ====
  
-The PL side of the Genesys ZU-5EV ZynqUltrascale+ can forward the incoming video and audio streams to the PHY layer via [[https://www.xilinx.com/support/documentation/ip_documentation/v_hdmi_tx_ss/v3_2/pg235-v-hdmi-tx-ss.pdf|HDMI 1.4/2.0 Transmitter Subsystem]] from Xilinx. The subsystem bundles a collection of HDMI TX-related IP sub-cores and outputs them as a single IP, providing an out-of-the-box ready-to-use HMDI system. For better performance and quality, the subsystem can be configured through the [[https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_2/ug893-vivado-ide.pdf|Vivado®Integrated Design Environment (IDE)]]. +The PL side of the Genesys ZU-5EV ZynqUltrascale+ can forward the incoming video and audio streams to the PHY layer via [[https://docs.xilinx.com/r/3.1-English/pg235-v-hdmi-tx-ss|HDMI 1.4/2.0 Transmitter Subsystem]] from Xilinx. The subsystem bundles a collection of HDMI TX-related IP sub-cores and outputs them as a single IP, providing an out-of-the-box ready-to-use HMDI system. For better performance and quality, the subsystem can be configured through the [[https://docs.xilinx.com/v/u/2020.1-English/ug893-vivado-ide|Vivado®Integrated Design Environment (IDE)]]. 
-The Genesys ZU-5EV board provides a <wrap hi>High-Definition Multimedia Interface (HDMI™)* video output using a TI SN65DP159RGZR HDMI retimer at IC41*</wrap>, on a receptacle at J23. This device is a dual-mode DisplayPort to transition-minimized differential signal (TMDS) retimer supporting digital video interface (DVI) 1.0 and HDMI 1.4b and 2.0 output signals. The device supports data rates up to 6 Gb/s per data lane to support Ultra HD (4K x 2K / 60 Hz) 8-bits per color high-resolution video and HDTV with 16-bit color depth at 1080p (1920 x 1080 / 60 Hz). A convenient characteristic is its ability to automatically configure itself as a redriver at data rates <1 Gb/s, or as a retimer at more than this data rate. This feature can be turned off through I2C programming. The SN65DP159RGZR HDMI retimer data inputs are wired to <wrap hi>GTH Quad 224*</wrap>. The necessary logic for properly interfacing the HDMI Tx Subsystem media access control and the serial transceiver is incorporated by the [[https://www.xilinx.com/support/documentation/ip_documentation/vid_phy_controller/v2_2/pg230-vid-phy-controller.pdf|Video PHY Controller IP]] from Xilinx. The core enables simple connectivity for each TX path, together with some domain-specific configurability. The HDMI video transmit and receive block diagram is shown below, where the Video Phy Controller and the HDMI Transmit Subsystem are bundled as IP-sub cores by the HDMI Subsystem.+The Genesys ZU-5EV board provides a <wrap hi>High-Definition Multimedia Interface (HDMI™)* video output using a TI SN65DP159RGZR HDMI retimer at IC41*</wrap>, on a receptacle at J23. This device is a dual-mode DisplayPort to transition-minimized differential signal (TMDS) retimer supporting digital video interface (DVI) 1.0 and HDMI 1.4b and 2.0 output signals. The device supports data rates up to 6 Gb/s per data lane to support Ultra HD (4K x 2K / 60 Hz) 8-bits per color high-resolution video and HDTV with 16-bit color depth at 1080p (1920 x 1080 / 60 Hz). A convenient characteristic is its ability to automatically configure itself as a redriver at data rates <1 Gb/s, or as a retimer at more than this data rate. This feature can be turned off through I2C programming. The SN65DP159RGZR HDMI retimer data inputs are wired to <wrap hi>GTH Quad 224*</wrap>. The necessary logic for properly interfacing the HDMI Tx Subsystem media access control and the serial transceiver is incorporated by the [[https://docs.xilinx.com/r/en-US/pg230-vid-phy-controller|Video PHY Controller IP]] from Xilinx. The core enables simple connectivity for each TX path, together with some domain-specific configurability. The HDMI video transmit and receive block diagram is shown below, where the Video Phy Controller and the HDMI Transmit Subsystem are bundled as IP-sub cores by the HDMI Subsystem.
 {{ :reference:programmable-logic:genesys-zu:gzu_5ev_hdmi_diagram.jpg |}} {{ :reference:programmable-logic:genesys-zu:gzu_5ev_hdmi_diagram.jpg |}}
  
Line 689: Line 695:
 ==== 9.3 HDMI Sink* ==== ==== 9.3 HDMI Sink* ====
  
-The received video and audio streams can be decoded and properly interfaced with PHY layers via [[https://www.xilinx.com/support/documentation/ip_documentation/v_hdmi_rx_ss/v3_1/pg236-v-hdmi-rx-ss.pdf|HDMI 1.4/2.0 Receiver Subsystem]] on the PL side of the Genesys ZU-5EV ZynqUltrascale+. The subsystem is a soft IP incorporating all the necessary functionalities through a collection of HDMI RX-related IP sub-cores. For better performance and quality, the subsystem can be configured through [[https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_2/ug893-vivado-ide.pdf|Vivado®Integrated Design Environment (IDE)]]. The Genesys ZU-5EV board accepts <wrap hi>HDMI video input on the 19 pin edge connector with shield at J26*</wrap>. All the TMDS RX signals are connected to <wrap hi>TMDS181IRGZT retimer*</wrap>. This device supports four TMDS channels, an audio return channel, and digital control interfaces together with signaling rates up to 6 Gbps+The received video and audio streams can be decoded and properly interfaced with PHY layers via [[https://docs.xilinx.com/r/3.1-English/pg236-v-hdmi-rx-ss|HDMI 1.4/2.0 Receiver Subsystem]] on the PL side of the Genesys ZU-5EV ZynqUltrascale+. The subsystem is a soft IP incorporating all the necessary functionalities through a collection of HDMI RX-related IP sub-cores. For better performance and quality, the subsystem can be configured through [[https://docs.xilinx.com/v/u/2020.1-English/ug893-vivado-ide|Vivado®Integrated Design Environment (IDE)]]. The Genesys ZU-5EV board accepts <wrap hi>HDMI video input on the 19 pin edge connector with shield at J26*</wrap>. All the TMDS RX signals are connected to <wrap hi>TMDS181IRGZT retimer*</wrap>. This device supports four TMDS channels, an audio return channel, and digital control interfaces together with signaling rates up to 6 Gbps
 to allow for the highest resolutions of 4k2k60p24 bits per pixel and up to WUXGA16-bit color depth or 1080p with higher refresh rates. It will automatically configure itself as a redriver at lower data rates (<1.0 Gbps) or as a retimer above this data rate.  to allow for the highest resolutions of 4k2k60p24 bits per pixel and up to WUXGA16-bit color depth or 1080p with higher refresh rates. It will automatically configure itself as a redriver at lower data rates (<1.0 Gbps) or as a retimer above this data rate. 
 In redriver mode, the device supports HDMI1.4b with data rates up to 3.4 Gbps. In redriver mode, the device supports HDMI1.4b with data rates up to 3.4 Gbps.
-More details about the supported resolutions and color spaces can be found by accessing the [[https://www.xilinx.com/products/intellectual-property/hdmi.html?_ga=2.264970319.1703298844.1624347413-547716515.1596446816#documentation|HDMI Subsystem]] documentation. The TMDS181IRGZT retimer/redriver outputs are wired to <wrap hi>GTH Quad 224*</wrap>. Same as for the TX path, the connectivity with the serial transceivers is made by the Video PHY Controller. Thus, the Video PHY Controller IP is not intended to be used as a stand-alone IP. To understand the behavior, use, and any limitations of the transceivers, please see [[https://www.xilinx.com/support/documentation/user_guides/ug576-ultrascale-gth-transceivers.pdf  | UltraScale Architecture GTH Transceivers User Guide (UG576)]].+More details about the supported resolutions and color spaces can be found by accessing the [[https://www.xilinx.com/products/intellectual-property/hdmi.html#documentation|HDMI Subsystem]] documentation. The TMDS181IRGZT retimer/redriver outputs are wired to <wrap hi>GTH Quad 224*</wrap>. Same as for the TX path, the connectivity with the serial transceivers is made by the Video PHY Controller. Thus, the Video PHY Controller IP is not intended to be used as a stand-alone IP. To understand the behavior, use, and any limitations of the transceivers, please see [[https://docs.xilinx.com/v/u/en-US/ug576-ultrascale-gth-transceivers| UltraScale Architecture GTH Transceivers User Guide (UG576)]].
      
      
Line 827: Line 833:
 The pin-out of the FMC connector can be found in the XDC constraints file available on Digilent Reference. The schematic also shows the mapping between FMC connector pins and FPGA pins. Keep in mind that pin designators for the connector are not the same as pin designators for the FPGA specified in the XDC constraints file. For example, the connector pin with designator H28 and named LA24_P is wired via net FMC_LA24_P to the FPGA pin with designator AF7 and named IO_L11P_T1U_N8_GC_64. In the constraints file FMC_LA24_P will need to be location constrained to AF7. The pin-out of the FMC connector can be found in the XDC constraints file available on Digilent Reference. The schematic also shows the mapping between FMC connector pins and FPGA pins. Keep in mind that pin designators for the connector are not the same as pin designators for the FPGA specified in the XDC constraints file. For example, the connector pin with designator H28 and named LA24_P is wired via net FMC_LA24_P to the FPGA pin with designator AF7 and named IO_L11P_T1U_N8_GC_64. In the constraints file FMC_LA24_P will need to be location constrained to AF7.
  
-For FMC designs which use FMC_LA_07_P/_N and/or FMC_LA15_P/_N lines with an I/O standard which needs DCI, please make sure you add the DCIRESET primitive to the respective designs. Refer to the UltraScale Architecture SelectIO Resources User Guide ([[https://www.xilinx.com/support/documentation/user_guides/ug571-ultrascale-selectio.pdf|ug571]]) chapter "Special DCI Requirements in Some Banks" for more information.+For FMC designs which use FMC_LA_07_P/_N and/or FMC_LA15_P/_N lines with an I/O standard which needs DCI, please make sure you add the DCIRESET primitive to the respective designs. Refer to the UltraScale Architecture SelectIO Resources User Guide ([[https://docs.xilinx.com/v/u/en-US/ug571-ultrascale-selectio|ug571]]) chapter "Special DCI Requirements in Some Banks" for more information.
  
 === 10.2.1 Gigabit Data Signals* ===  === 10.2.1 Gigabit Data Signals* === 
Line 840: Line 846:
 The FMC user defined pins are not affected by this limitation.  The FMC user defined pins are not affected by this limitation. 
  
-Table 10.2.1.1 shows how the FMC gigabit signals are mapped to pins and GTH primitives. Refer to the UltraScale Architecture GTH Transceivers User Guide ([[https://www.xilinx.com/support/documentation/user_guides/ug576-ultrascale-gth-transceivers.pdf|ug576]]) for more information.+Table 10.2.1.1 shows how the FMC gigabit signals are mapped to pins and GTH primitives. Refer to the UltraScale Architecture GTH Transceivers User Guide ([[https://docs.xilinx.com/v/u/en-US/ug576-ultrascale-gth-transceivers|ug576]]) for more information.
  
 //Table 10.2.1.1: FMC Gigabit Signals Mapping// //Table 10.2.1.1: FMC Gigabit Signals Mapping//
Line 960: Line 966:
  
 Each SYZYGY Standard interface contains 14 single-ended I/O pins (2 of which I<sup>2</sup>C), 8 differential I/O pairs (which can alternatively be used as 16 additional single-ended I/O pins), and two dedicated differential clocks - one for input and one for output. The Zmod port is wired to PL-side MPSoC banks powered by the VADJ rail, sharing them with FMC signals. Therefore if both an FMC mezzanine card and a Zmod are connected to the Genesys ZU, a common voltage supported by both needs to be chosen for VADJ. Each SYZYGY Standard interface contains 14 single-ended I/O pins (2 of which I<sup>2</sup>C), 8 differential I/O pairs (which can alternatively be used as 16 additional single-ended I/O pins), and two dedicated differential clocks - one for input and one for output. The Zmod port is wired to PL-side MPSoC banks powered by the VADJ rail, sharing them with FMC signals. Therefore if both an FMC mezzanine card and a Zmod are connected to the Genesys ZU, a common voltage supported by both needs to be chosen for VADJ.
-The differential pairs were prioritized and wired to HP banks, allowing the maximum data rates supported by the SelectI/O architecture. However, the single-ended pins are wired to an HD bank, limiting the data rate to 250 Mb/s according to the Zynq UltraScale+ MPSoC Data Sheet: DC and AC Switching Characteristics [[https://www.xilinx.com/support/documentation/data_sheets/ds925-zynq-ultrascale-plus.pdf|(ds925)]].+The differential pairs were prioritized and wired to HP banks, allowing the maximum data rates supported by the SelectI/O architecture. However, the single-ended pins are wired to an HD bank, limiting the data rate to 250 Mb/s according to the Zynq UltraScale+ MPSoC Data Sheet: DC and AC Switching Characteristics [[https://docs.xilinx.com/v/u/en-US/ds925-zynq-ultrascale-plus|(ds925)]].
 Template constraints for the Zmod port can be found in the Genesys ZU's Master XDC file, available through Digilent's [[https://github.com/Digilent/digilent-xdc|digilent-xdc]] repository on Github. Template constraints for the Zmod port can be found in the Genesys ZU's Master XDC file, available through Digilent's [[https://github.com/Digilent/digilent-xdc|digilent-xdc]] repository on Github.
  
Line 1171: Line 1177:
 connected to Genesys ZU and signals this to the FPGA. If a SYZYGY Pod was detected, connected to Genesys ZU and signals this to the FPGA. If a SYZYGY Pod was detected,
 the SYZYGY_DETECTEDN pin (H11) is driven LOW. Otherwise the pin is driven HIGH. the SYZYGY_DETECTEDN pin (H11) is driven LOW. Otherwise the pin is driven HIGH.
 +
 +--> VADJ Setting for Firmware Version 1.0 #
 +In the Firmware Version 1.0 implementation, the FPGA must detect the correct VADJ level required
 +by SYZYGY and FMC modules and must set the VADJ_LEVEL1 and VADJ_LEVEL0 signals
 +accordingly. The VADJ_LEVEL1 and VADJ_LEVEL0 signals will be taken into account by the 
 +Platform MCU only if the FPGA generates a rising edge on VADJ_AUTON signal. If VADJ_AUTON becomes LOW, 
 +the VADJ power rail status (on or off) is unaffected. To turn off the VADJ power rail, the FPGA must set the VADJ_LEVEL1 and VADJ_LEVEL0 signals LOW and generate a rising edge condition on VADJ_AUTON.
 +<--
 +
 +\\ 
 +
 +<WRAP center round important 90%>
 +In the Firmware Version 2.0 implementation, the firmware detects if FMC mezzanine module or SYZYGY pod are connected at power-up, and if VADJ_AUTON pin (G10) from FPGA is LOW or TRISTATE (default with the PL unprogrammed), it parses their EEPROM memories and sets the VADJ value to the highest common value. If there is no common value a fault is indicated using the PMCU LED. This is the default functionality. One is still able to set another VADJ level using the VADJ_AUTON, VADJ_LEVEL0 and VADJ_LEVEL1 signals.
 +</WRAP>
  
 If VADJ_AUTON pin (G10) from FPGA is HIGH, the Platform MCU establishes the correct If VADJ_AUTON pin (G10) from FPGA is HIGH, the Platform MCU establishes the correct
Line 1183: Line 1203:
 |  1           |  0           |  1.5V           | |  1           |  0           |  1.5V           |
 |  1           |  1           |  1.8V           | |  1           |  1           |  1.8V           |
 +
 +To set the desired VADJ level you have to:
 +  - Drive the VADJ_LEVEL1 and VADJ_LEVEL0 to encode the desired VADJ level.
 +  - Generate a rising edge condition on VADJ_AUTON.
  
 Although neither FMC mezzanine modules nor SYZYGY pods are designed to be Although neither FMC mezzanine modules nor SYZYGY pods are designed to be
Line 1190: Line 1214:
 detect the pin change and will adjust the VADJ voltage level according to the detect the pin change and will adjust the VADJ voltage level according to the
 actual VADJ_LEVEL1 and VADJ_LEVEL0 pins state. The voltage rail will reach its power good threshold in maximum 1.5 seconds after the rising edge of VADJ_AUTON. The power good threshold is set to 100 mV less than the nominal voltage. actual VADJ_LEVEL1 and VADJ_LEVEL0 pins state. The voltage rail will reach its power good threshold in maximum 1.5 seconds after the rising edge of VADJ_AUTON. The power good threshold is set to 100 mV less than the nominal voltage.
- 
-To set the desired VADJ level you have to: 
-  - Drive the VADJ_LEVEL1 and VADJ_LEVEL0 to encode the desired VADJ level. 
-  - Generate a rising edge condition on VADJ_AUTON. 
- 
-<WRAP center round important 90%> 
-In the Firmware Version 1.0 implementation, the FPGA must detect the correct VADJ level required 
-by SYZYGY and FMC modules and must set the VADJ_LEVEL1 and VADJ_LEVEL0 signals 
-accordingly. The VADJ_LEVEL1 and VADJ_LEVEL0 signals will be taken into account by the  
-Platform MCU only if the VADJ_AUTON signal is driven HIGH by the FPGA. If VADJ_AUTON is LOW,  
-the VADJ power rail status (on or off) is unaffected. To turn off the VADJ power rail, the FPGA must set the VADJ_LEVEL1 and VADJ_LEVEL0 signals LOW and generate a rising edge condition on VADJ_AUTON. 
-</WRAP> 
- 
---> VADJ Setting for Firmware Version 2.0 # 
-The firmware detects if FMC mezzanine module or SYZYGY pod are connected at power-up, and if VADJ_AUTON pin (G10) from FPGA is LOW or TRISTATE (default with the PL unprogrammed), it parses their EEPROM memories and sets the VADJ value to the highest common value. If there is no common value a fault is indicated using the PMCU LED. This is the default functionality. One is still able to set another VADJ level using the VADJ_AUTON, VADJ_LEVEL0 and VADJ_LEVEL1 signals. 
-<-- 
  
 \\  \\ 
Line 1367: Line 1375:
  
 Although we strive to provide perfect products, we are not infallible. The Genesys ZU is subject to the limitations below. Although we strive to provide perfect products, we are not infallible. The Genesys ZU is subject to the limitations below.
-^ Product Name  ^ Variant  ^ Revision  ^ S/N                                ^ Problem                                                                                                                                       ^ Status           ^ +^ Product Name  ^ Variant  ^ Revision  ^ S/N                                ^ Problem                                                                                                                                            ^ Status           ^ 
-| Genesys ZU    | -3EG     | B         | DAD9C39-DAD9D32, DADA13A, DADA13B  | [[programmable-logic:genesys-zu:reference-manual#fan_assembly_error|Fan assembly error resulting in sub-optimal mechanical hold.]]  | Fixed in rev C.  |+| Genesys ZU    | -3EG     | B         | DAD9C39-DAD9D32, DADA13A, DADA13B  | [[programmable-logic:genesys-zu:reference-manual#fan_assembly_error|Fan assembly error resulting in sub-optimal mechanical hold.]]                 | Fixed in rev C.  | 
 +| Genesys ZU    | -3EG     | B         | All                                | [[programmable-logic:genesys-zu:reference-manual#bundled_microsd_card_missing_factory_oob_image|Bundled microSD card missing factory OOB image.]]  | Fixed in rev D.  | 
 +| :::           | -3EG     | D         | D000000-DAF7EEC                    | :::                                                                                                                                                | :::              | 
 +| :::           | -5EV     | D         | D000000-DAF7F25                    | :::                                                                                                                                                | :::              | 
  
 ==== 1 Fan Assembly Error ==== ==== 1 Fan Assembly Error ====
Line 1385: Line 1397:
 A step-by-step description of the clip (dis)assembly is described here: http://www.malico.com.tw/index.php?option=com_content&view=article&id=451&Itemid=406&lang=en. After the yellow clip is in place, the fan can be screwed back in the same place as before. A step-by-step description of the clip (dis)assembly is described here: http://www.malico.com.tw/index.php?option=com_content&view=article&id=451&Itemid=406&lang=en. After the yellow clip is in place, the fan can be screwed back in the same place as before.
  
 +==== 2 Bundled microSD card missing factory OOB image ====
 +Due to a mistake in the kitting process some Genesys ZU boards were shipped with the microSD card missing the correct Out-of-Box Demo image. The issue does not affect the quality of the board itself, which is tested rigorously including with the OOB image. Only the serial numbers listed above are affected and the kitting process has since been corrected.
  
 +=== Workaround ===
 +The microSD card can be re-imaged on any Windows or Linux machine. The same process that updates card contents to the latest OOB version can be used. The latest OOB images are available on our github repository, which at the time of writing are:
 +[[https://github.com/Digilent/Genesys-ZU/releases/tag/3eg%2Foob%2Frelease%2Fv2.1|3EG Out-of-Box SD Image v2.1]]
 + and
 +[[https://github.com/Digilent/Genesys-ZU/releases/tag/5ev%2Foob%2Frelease%2Fv2.1|5EV Out-of-Box SD Image v2.1]].