Differences
This shows you the differences between two versions of the page.
| programmable-logic:genesys-zu:reference-manual [2021/08/24 14:38] – [12.2 Platform MCU] Ioan | programmable-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 " | + | 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: |
| Want to dive deep into development? | Want to dive deep into development? | ||
| 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: | 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: | ||
| + | |||
| + | 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" | + | For more details about JTAG see "JTAG Functional Description" |
| ==== 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/ | + | For more details about SD boot mode see "SD Boot Mode" section in [[https://docs.xilinx.com/ |
| ==== 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 " | + | For more details about Quad SPI boot mode see " |
| ==== 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/ | + | 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/ |
| ==== 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/ | + | The bundled module up until rev B.1 is a 4GiB Kingston HyperX HX424S14IB/ |
| Although some modules support > | Although some modules support > | ||
| 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' | + | 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' |
| 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/ | + | 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/ |
| ---- | ---- | ||
| 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/ | + | To enable UHS-I support and speeds up to SDR104, see the following Answer Records from Xilinx: [[https://support.xilinx.com/ |
| ==== 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/ | + | * 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/ |
| * 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 505: | Line 511: | ||
| For high-speed interfaces implemented using <wrap hi>GTH transceivers*</ | For high-speed interfaces implemented using <wrap hi>GTH transceivers*</ | ||
| - | There are two main modes this oscillator is meant to be used: free-running or jitter-cleanup. The free-running mode synthesizes a frequency suitable for the protocol implemented in the <wrap hi>GTH quad*</ | + | There are two main modes this oscillator is meant to be used: free-running or jitter-cleanup. The free-running mode synthesizes a frequency suitable for the protocol implemented in the <wrap hi>GTH quad*</ |
| One of the oscillator' | One of the oscillator' | ||
| 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 " | + | For more details about configuration pins see " |
| ---- | ---- | ||
| 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/ | + | 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/ |
| - | The Genesys ZU-5EV board provides a <wrap hi> | + | The Genesys ZU-5EV board provides a <wrap hi> |
| {{ : | {{ : | ||
| 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/ | + | The received video and audio streams can be decoded and properly interfaced with PHY layers via [[https://docs.xilinx.com/ |
| 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:// | + | More details about the supported resolutions and color spaces can be found by accessing the [[https:// |
| | | ||
| | | ||
| 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/ | + | For FMC designs which use FMC_LA_07_P/ |
| === 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/ | + | 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/ |
| //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< | Each SYZYGY Standard interface contains 14 single-ended I/O pins (2 of which I< | ||
| - | 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/ | + | 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/ |
| Template constraints for the Zmod port can be found in the Genesys ZU's Master XDC file, available through Digilent' | Template constraints for the Zmod port can be found in the Genesys ZU's Master XDC file, available through Digilent' | ||
| Line 1144: | Line 1150: | ||
| //Table 12.2.1: Platform MCU Firmware revisions// | //Table 12.2.1: Platform MCU Firmware revisions// | ||
| - | ^ Board Revision | + | ^ Genesys ZU Board Revision |
| - | | Rev.B | + | | Rev.B |
| - | | Rev.D | + | | Rev.D |
| The Platform MCU program memory has two sections: | The Platform MCU program memory has two sections: | ||
| Line 1172: | Line 1178: | ||
| 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. | ||
| - | If VADJ_AUTON pin (G10) from FPGA is LOW, the Platform MCU establishes the correct | + | --> VADJ Setting for Firmware Version 1.0 # |
| + | In the Firmware Version 1.0 implementation, | ||
| + | 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. | ||
| + | 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, | ||
| + | </ | ||
| + | |||
| + | If VADJ_AUTON pin (G10) from FPGA is HIGH, the Platform MCU establishes the correct | ||
| VADJ voltage value based on VADJ_LEVEL1 (AC13) and VADJ_LEVEL0 (AC14) input pins, | VADJ voltage value based on VADJ_LEVEL1 (AC13) and VADJ_LEVEL0 (AC14) input pins, | ||
| regardless of whether a SYZYGY pod and/or FMC mezzanine module is connected. | regardless of whether a SYZYGY pod and/or FMC mezzanine module is connected. | ||
| Line 1183: | Line 1203: | ||
| | 1 | | 1 | ||
| | 1 | | 1 | ||
| + | |||
| + | 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 | ||
| plug-and-play and their detection needs to be done only at board power-up, the | plug-and-play and their detection needs to be done only at board power-up, the | ||
| VADJ voltage value can still change during board operation. Due to this, | VADJ voltage value can still change during board operation. Due to this, | ||
| - | VADJ_AUTO | + | VADJ_AUTON |
| 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 | + | actual VADJ_LEVEL1 and VADJ_LEVEL0 pins state. The voltage rail will reach its power good threshold in maximum |
| - | To set the desired VADJ level you have to: | + | \\ |
| - | - Drive the VADJ_LEVEL1 and VADJ_LEVEL0 to encode the desired VADJ level. | + | On Genesys ZU there is an LED labeled with PMCU (LD21). This is the status |
| - | - Generate a falling edge condition on VADJ_AUTON. | + | |
| - | + | ||
| - | <WRAP center round important 90%> | + | |
| - | In the Firmware Version 1.0 implementation, | + | |
| - | 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 LOW by the FPGA. If VADJ_AUTON is HIGH, | + | |
| - | the VADJ power rail is disabled. | + | |
| - | </ | + | |
| - | + | ||
| - | --> 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 HIGH or TRISTATE (default with the PL unprogrammed), | + | |
| - | <-- | + | |
| - | + | ||
| - | + | ||
| - | On Genesys ZU there is an LED labeled with PMCU (LD21). This is the status | + | |
| used by the Platform MCU to display the system fault that has the highest priority. | used by the Platform MCU to display the system fault that has the highest priority. | ||
| The blinking pattern for each fault is presented in Table 12.2.1.2. | The blinking pattern for each fault is presented in Table 12.2.1.2. | ||
| Line 1217: | Line 1225: | ||
| * A “short blink” and a “short pause” last for about 200ms each; | * A “short blink” and a “short pause” last for about 200ms each; | ||
| - | //Table 12.2.1.2: Fault blink patterns// | + | The Platform MCU can detect a number of faults which can occur on the board. In case such a fault occurs during board operation, the PMCU LED would blink in a specific pattern, described in Table 12.2.1.2 below. If multiple errors have occurred, only the error with the highest priority will be shown on the PMCU LED. |
| + | |||
| + | --> Fault blink patterns for Firmware Version 1.0 # | ||
| + | ^ Blink Pattern (Repeated) | ||
| + | | Long Blink – Long Pause | ||
| + | |||
| + | <-- | ||
| + | |||
| + | //Table 12.2.1.2: Fault blink patterns | ||
| ^ Blink Pattern (Repeated) | ^ Blink Pattern (Repeated) | ||
| - | | Long Blink – Long Pause | + | | Short Blink – Long Pause | PMU #1 or Power Stage Fault | 0 (Highest) | Logic OR between used bits in registers 0x10 through 0x14 | |
| + | | Short Blink - Short Pause – Short Blink –Long Pause | PMU #2 Fault | 1 | Logic OR between used bits in registers 0x15 through 0x18 | | ||
| + | | 2x (Short Blink - Short Pause) - Short Blink–Long Pause | PMU #3 Fault | 2 | Logic OR between used bits in registers 0x19 through 0x1B | | ||
| + | | Long Blink – Short Pause – 2x (Short Blink – Short Pause) - Short Blink – Long Pause | FPGA Overtemperature Fault | 3 | Register 0x06 Bit 1 | | ||
| + | | Long Blink – Short Pause – 3x (Short Blink – Short Pause) - Short Blink – Long Pause | Clock Stretching Timeout | 4 | Register 0x0F Bit 3 | | ||
| + | | Long Blink – Long Pause | Fan Speed Fault | 5 | Register | ||
| + | | Long Blink – Short Pause - Short Blink – Short Pause - Short Blink – Long Pause | UART Framing or Parity Error | 6 | Logic OR between FE and UPE bits in UCSR0A register corresponding to UART interface tied to the FT4232H | | ||
| + | | Long Blink – Short Pause - Short Blink – Long Pause | SYZYGY or FMC Fault | 7 (Lowest) | Logic OR between bits in register 0x70 | | ||
| The Platform MCU exposes to the PC a register interface, accessible via UART. | The Platform MCU exposes to the PC a register interface, accessible via UART. | ||
| The full register map is shown in Table 12.2.1.3. | The full register map is shown in Table 12.2.1.3. | ||
| - | //Table 12.2.1.3: | + | --> |
| ^ Offset | ^ Offset | ||
| | 0x00 | | 0x00 | ||
| - | | 0x01 | + | | 0x01 |
| | 0x02 | | 0x02 | ||
| | 0x03 | | 0x03 | ||
| Line 1236: | Line 1259: | ||
| ^ 0x10-0x70 | ^ 0x10-0x70 | ||
| - | --> Register Map for Firmware Version 2.0 # | + | <-- |
| - | ^ Offset ^ Register Name ^ Size [bits] ^ R/W ^ Description ^ | + | //Table 12.2.1.3: |
| - | | 0x00 | ID Register | 8 | R | It contains a fixed value, used for determining if the Platform MCU is alive and responding over UART. The value for RevC is D6 from (DiGilent) | | + | |
| - | | 0x01 | Firmware Version | 8 | R | It contains the firmware major version on bits 7-4 and the minor version on bits 3-0. For RevC it is 0x20 | | + | |
| - | | 0x02 | Scratch Register | 8 | R/W | Read/write register used to test both the write and the read register interfaces. | | + | |
| - | | 0x03 | Measured FPGA Core Temperature | 8 | R | FPGA Temperature value, as computed by the Platform MCU based on the thermal diode measurement. | + | |
| - | | 0x04 | Measured Fan Speed | 16 | R | FPGA Fan Speed value, as computed based on the fan feedback pin. | | + | |
| - | | 0x06 | FPGA &Fan Speed Faults | 8 | R | Bits 7-2: Unused \\ Bit 1: FPGA Overtemperature fault: set this bit to ‘1’ if FPGA temperature increases over 100oC. \\ Bit 0: ‘1’ if fan speed is outside the expected range; ‘0’ otherwise | | + | |
| - | | 0x07 | Board Variant | 8 | R | It contains a fixed value representing the board variant: \\ - 0x33 for 3EG; \\ - 0x35 for 5EV. | | + | |
| - | | 0x08- \\ 0x0E | Reserved for future functionality | | | | | + | |
| - | | 0x0F | Platform MCU Control | 8 | W | Bits 7-6: Unused \\ Bit 5: Poll Current Consumption: | + | |
| - | | 0x0F | Platform MCU Status | 8 | R | Bits 7-6: Unused \\ Bit 5: Poll Current Consumption: | + | |
| - | | 0x10 | PMU #1 Rail #1 & Power Stage Faults | 8 | R | Bit 7: Power Stage overtemperature fault \\ Bit 6: PMU input voltage, current or power fault or warning (PMBus STATUS_WORD High Byte -> Bit 5) \\ Bit 5: PMU output overvoltage fault(PMBus STATUS_WORD Low Byte -> Bit 5) \\ Bit 4: PMU output overcurrent fault(PMBus STATUS_WORD Low Byte -> Bit 4) \\ Bit 3: PMU input undervoltage fault(PMBus STATUS_WORD Low Byte -> Bit 3) \\ Bit 2: PMU temperature fault or warning(PMBus STATUS_WORD Low Byte -> Bit 2) \\ Bit 1: PMU Communication, | + | |
| - | | 0x11 | PMU #1 Rail #2 Faults | 8 | R | Bit 7: Unused \\ Bit 6: PMU input voltage, current or power fault or warning \\ Bit 5: PMU output overvoltage fault \\ Bit 4: PMU output overcurrent fault \\ Bit 3: PMU input undervoltage fault \\ Bit 2: PMU temperature fault or warning \\ Bit 1: PMU Communication, | + | |
| - | | 0x12 | PMU #1 Rail #3 Faults | 8 | R | Bit 7: Unused \\ Bit 6: PMU input voltage, current or power fault or warning Bit \\ 5: PMU output overvoltage fault \\ Bit 4: PMU output overcurrent fault \\ Bit 3: PMU input undervoltage fault \\ Bit 2: PMU temperature fault or warning \\ Bit 1: PMU Communication, | + | |
| - | | 0x13 | PMU #1 Rail #4 Faults | 8 | R | Bit 7: Unused \\ Bit 6: PMU input voltage, current or power fault or warning \\ Bit 5: PMU output overvoltage fault \\ Bit 4: PMU output overcurrent fault \\ Bit 3: PMU input undervoltage fault \\ Bit 2: PMU temperature fault or warning \\ Bit 1: PMU Communication, | + | |
| - | | 0x14 | PMU #1 Rail #5 Faults | 8 | R | Bit 7: Unused \\ Bit 6: PMU input voltage, current or power fault or warning \\ Bit 5: PMU output overvoltage fault \\ Bit 4: PMU output overcurrent fault \\ Bit 3: PMU input undervoltage fault \\ Bit 2: PMU temperature fault or warning \\ Bit 1: PMU Communication, | + | |
| - | | 0x15 | PMU #2 Rail #1 Faults | 8 | R | Bit 7: Unused \\ Bit 6: PMU input voltage, current or power fault or warning \\ Bit 5: PMU output overvoltage fault \\ Bit 4: PMU output overcurrent fault \\ Bit 3: PMU input undervoltage fault \\ Bit 2: PMU temperature fault or warning \\ Bit 1: PMU Communication, | + | |
| - | | 0x16 | PMU #2 Rail #2 Faults | 8 | R | Bit 7: Unused \\ Bit 6: PMU input voltage, current or power fault or warning \\ Bit 5: PMU output overvoltage fault \\ Bit 4: PMU output overcurrent fault \\ Bit 3: PMU input undervoltage fault \\ Bit 2: PMU temperature fault or warning \\ Bit 1: PMU Communication, | + | |
| - | | 0x17 | PMU #2 Rail #3 Faults | 8 | R | Bit 7: Unused \\ Bit 6: PMU input voltage, current or power fault or warning \\ Bit 5: PMU output overvoltage fault \\ Bit 4: PMU output overcurrent fault \\ Bit 3: PMU input undervoltage fault \\ Bit 2: PMU temperature fault or warning \\ Bit 1: PMU Communication, | + | |
| - | | 0x18 | PMU #2 Rail #4 Faults | 8 | R | Bit 7: Unused \\ Bit 6: PMU input voltage, current or power fault or warning \\ Bit 5: PMU output overvoltage fault \\ Bit 4: PMU output overcurrent fault \\ Bit 3: PMU input undervoltage fault \\ Bit 2: PMU temperature fault or warning \\ Bit 1: PMU Communication, | + | |
| - | | 0x19 | PMU #3 Rail #1 Faults | 8 | R | Bit 7: Unused \\ Bit 6: PMU input voltage, current or power fault or warning \\ Bit 5: PMU output overvoltage fault \\ Bit 4: PMU output overcurrent fault \\ Bit 3: PMU input undervoltage fault \\ Bit 2: PMU temperature fault or warning \\ Bit 1: PMU Communication, | + | |
| - | | 0x1A | PMU #3 Rail #2 Faults | 8 | R | Bit 7: Unused \\ Bit 6: PMU input voltage, current or power fault or warning \\ Bit 5: PMU output overvoltage fault \\ Bit 4: PMU output overcurrent fault \\ Bit 3: PMU input undervoltage fault \\ Bit 2: PMU temperature fault or warning \\ Bit 1: PMU Communication, | + | |
| - | | 0x1B | PMU #3 Rail #3 Faults | 8 | R | Bit 7: Unused \\ Bit 6: PMU input voltage, current or power fault or warning \\ Bit 5: PMU output overvoltage fault \\ Bit 4: PMU output overcurrent fault \\ Bit 3: PMU input undervoltage fault \\ Bit 2: PMU temperature fault or warning \\ Bit 1: PMU Communication, | + | |
| - | | 0x1C- \\ 0x2F | Reserved for future functionality | | | | | + | |
| - | | 0x30 | PMU #1 Output 1 Current | 16 | R | Current is in Amps; Fixed-point representation, | + | |
| - | | 0x32 | PMU #1 Output 2 Current | 16 | R | Current is in Amps; Fixed-point representation, | + | |
| - | | 0x34 | PMU #1 Output 3 Current | 16 | R | Current is in Amps; Fixed-point representation, | + | |
| - | | 0x36 | PMU #1 Output 4 Current | 16 | R | Current is in Amps; Fixed-point representation, | + | |
| - | | 0x38 | PMU #1 Output 5 Current | 16 | R | Current is in Amps; Fixed-point representation, | + | |
| - | | 0x3A | PMU #2 Output 1 Current | 16 | R | Current is in Amps; Fixed-point representation, | + | |
| - | | 0x3C | PMU #2 Output 2 Current | 16 | R | Current is in Amps; Fixed-point representation, | + | |
| - | | 0x3E | PMU #2 Output 3 Current | 16 | R | Current is in Amps; Fixed-point representation, | + | |
| - | | 0x40 | PMU #2 Output 4 Current | 16 | R | Current is in Amps; Fixed-point representation, | + | |
| - | | 0x42 | PMU #3 Output 1 Current | 16 | R | Current is in Amps; Fixed-point representation, | + | |
| - | | 0x44 | PMU #3 Output 2 Current | 16 | R | Current is in Amps; Fixed-point representation, | + | |
| - | | 0x46 | PMU #3 Output 3 Current | 16 | R | Current is in Amps; Fixed-point representation, | + | |
| - | | 0x48- \\ 0x6F | Reserved for future functionality | + | |
| - | | 0x70 | SYZYGY & FMC Faults 1 | 8 | R | Bits 7:5: Unused \\ Bit4: FMC EEPROM parsing error/EEPROM empty/EEPROM not responsive \\ Bit 3: SYZYGY EEPROM parsing error/ | + | |
| - | | 0x71 | SYZYGY & FMC Faults 2 | 8 | R | Bits 7:4: Unused \\ Bit 3: SYZYGY + FMC Maximum operating VADJ load exceeds Genesys ZU spec \\ Bit 2: SYZYGY + FMC Maximum operating 3.3V load exceeds Genesys ZU spec \\ Bit 1: SYZYGY Maximum operating 5V load exceeds Genesys ZU spec \\ Bit 0: FMC Maximum operating 12V load exceeds Genesys ZU spec The contents of this register are latched upon board power-up, after FMC & SYZYGY card detection is performed. The register contents are cleared only upon a board power cycle. | | + | |
| - | <WRAP center round important 90%> | + | ^ Offset |
| - | If I2C communication to PMUs is disabled (i.e. Bit 0 from Platform MCU Control register | + | | 0x00 | ID Register |
| - | </WRAP> | + | | 0x01 | Firmware Version |
| - | <-- | + | | 0x02 | Scratch Register |
| + | | 0x03 | Measured FPGA Core Temperature | ||
| + | | 0x04 | Measured Fan Speed | 16 | R | FPGA Fan Speed value, as computed based on the fan feedback pin. | | ||
| + | | 0x06 | FPGA &Fan Speed Faults | ||
| + | | 0x07 | Board Variant | ||
| + | | 0x08- \\ 0x0E | Reserved for future functionality | ||
| + | | 0x0F | Platform MCU Control | ||
| + | | 0x0F | Platform MCU Status | ||
| + | | 0x10 | PMU #1 Rail #1 & Power Stage Faults | ||
| + | | 0x11 | PMU #1 Rail #2 Faults | ||
| + | | 0x12 | PMU #1 Rail #3 Faults | ||
| + | | 0x13 | PMU #1 Rail #4 Faults | ||
| + | | 0x14 | PMU #1 Rail #5 Faults | ||
| + | | 0x15 | PMU #2 Rail #1 Faults | ||
| + | | 0x16 | PMU #2 Rail #2 Faults | ||
| + | | 0x17 | PMU #2 Rail #3 Faults | ||
| + | | 0x18 | PMU #2 Rail #4 Faults | ||
| + | | 0x19 | PMU #3 Rail #1 Faults | ||
| + | | 0x1A | PMU #3 Rail #2 Faults | ||
| + | | 0x1B | PMU #3 Rail #3 Faults | ||
| + | | 0x1C- \\ 0x2F | Reserved for future functionality | ||
| + | | 0x30 | PMU #1 Output 1 Current | ||
| + | | 0x32 | PMU #1 Output 2 Current | ||
| + | | 0x34 | PMU #1 Output 3 Current | ||
| + | | 0x36 | PMU #1 Output 4 Current | ||
| + | | 0x38 | PMU #1 Output 5 Current | ||
| + | | 0x3A | PMU #2 Output 1 Current | ||
| + | | 0x3C | PMU #2 Output 2 Current | ||
| + | | 0x3E | PMU #2 Output 3 Current | ||
| + | | 0x40 | PMU #2 Output 4 Current | ||
| + | | 0x42 | PMU #3 Output 1 Current | ||
| + | | 0x44 | PMU #3 Output 2 Current | ||
| + | | 0x46 | PMU #3 Output 3 Current | ||
| + | | 0x48- \\ 0x6F | Reserved for future functionality | ||
| + | | 0x70 | SYZYGY & FMC Faults 1 | 8 | R | Bits 7:5: Unused \\ Bit4: FMC EEPROM parsing error/ | ||
| + | | 0x71 | SYZYGY & FMC Faults 2 | 8 | R | Bits 7:4: Unused \\ Bit 3: SYZYGY + FMC Maximum operating VADJ load exceeds Genesys ZU spec \\ Bit 2: SYZYGY + FMC Maximum operating 3.3V load exceeds Genesys ZU spec \\ Bit 1: SYZYGY Maximum operating 5V load exceeds Genesys ZU spec \\ Bit 0: FMC Maximum operating 12V load exceeds Genesys ZU spec. \\ The contents of this register are latched upon board power-up, after FMC & SYZYGY card detection is performed. The register contents are cleared only upon a board power cycle. | ||
| When the PC wants to access a Platform MCU register, it needs to respect the following protocol: | When the PC wants to access a Platform MCU register, it needs to respect the following protocol: | ||
| * It needs to send at first the address byte. Bits 7 to 1 of this byte contain the register start address (found in the first column from Table 12.2.1.3). Bit 0 of this byte is logic ‘1’ for read transactions, | * It needs to send at first the address byte. Bits 7 to 1 of this byte contain the register start address (found in the first column from Table 12.2.1.3). Bit 0 of this byte is logic ‘1’ for read transactions, | ||
| - | * It then needs to send a second byte, containing the number of bytes to read/write. | + | * It then needs to send a second byte, containing the number of bytes to read/write, in hex (e.g. for 12 bytes, the user would need to send “0C”). |
| * For write transactions, | * For write transactions, | ||
| * For read transactions, | * For read transactions, | ||
| + | * Finally, the PC needs to send a Line Feed character to the Platform MCU to finish the transaction. | ||
| + | * A diagram of the bytes sent via UART for a write transaction would look like this: | ||
| + | |||
| + | ^ Address Byte + R/W ^ No. of Bytes to Write ^ Data Byte(s) to Write (1…256 maximum) ^ Line Feed ^ | ||
| + | |||
| + | * A diagram of the bytes sent via UART for a read transaction would look like this: | ||
| + | |||
| + | ^ Address Byte + R/W ^ No. of Bytes to Read ^ Data Byte(s) to Read (1…256 maximum) ^ Line Feed ^ | ||
| + | |||
| * For write transactions, | * For write transactions, | ||
| * For consecutive write transactions, | * For consecutive write transactions, | ||
| - | * All bytes to be sent to the PMCU need to have their nibbles converted to ASCII characters prior to being sent; e.g.: 0x0C in hex needs to be converted to “0C” in ASCII. | + | * All bytes to be sent to the PMCU (except for the Line Feed) need to have their nibbles converted to ASCII characters prior to being sent; e.g.: 0x0C in hex needs to be converted to “0C” in ASCII. |
| - | * All characters received from the PMCU need to be converted from ASCII to hex nibbles after being received; e.g. “0C” received in ASCII format needs to be converted to 0x0C in hex. | + | * All characters received from the PMCU (except for the Line Feed) need to be converted from ASCII to hex nibbles after being received; e.g. “0C” received in ASCII format needs to be converted to 0x0C in hex. |
| Write transaction example. | Write transaction example. | ||
| Line 1298: | Line 1327: | ||
| * Byte 1: 01 (i.e. the PC want to write 1 byte) | * Byte 1: 01 (i.e. the PC want to write 1 byte) | ||
| * Byte 2: 02 (value to write to register at address 0x0F - Clear all faults) | * Byte 2: 02 (value to write to register at address 0x0F - Clear all faults) | ||
| + | * Byte 3: Line Feed. | ||
| Read transaction example. | Read transaction example. | ||
| Line 1303: | Line 1333: | ||
| * Byte 0: 0D (i.e. Bits 7-1 = 0x06 which is the address of Fan Speed Fault register; Bit 0 = ' | * Byte 0: 0D (i.e. Bits 7-1 = 0x06 which is the address of Fan Speed Fault register; Bit 0 = ' | ||
| * Byte 1: 01 (i.e. the PC wants to read 1 byte) | * Byte 1: 01 (i.e. the PC wants to read 1 byte) | ||
| - | The Platform MCU will then send 1 byte back to the PC, containing the value of the Fan Speed Fault register. | + | * The Platform MCU will then send 1 byte back to the PC, containing the value of the Fan Speed Fault register. |
| + | * Byte 3: Line Feed. | ||
| To read a 16-bit register like Measured Fan Speed the PC will send to the Platform MCU: | To read a 16-bit register like Measured Fan Speed the PC will send to the Platform MCU: | ||
| * Byte 0: 09 (i.e. Bits 7-1 = 0x04 which is the address of Measured Fan Speed register; Bit 0 = ' | * Byte 0: 09 (i.e. Bits 7-1 = 0x04 which is the address of Measured Fan Speed register; Bit 0 = ' | ||
| * Byte 1: 02 (i.e the PC wants to read 2 bytes) | * Byte 1: 02 (i.e the PC wants to read 2 bytes) | ||
| - | The Platform MCU will then send 2 bytes back to the PC. The first byte that is sent is the least significant one. If one receives 150C one have to swap the first byte with the second one and to convert the value to decimal: 150C -> 0x0C15 -> 3093 RPM. | + | * The Platform MCU will then send 2 bytes back to the PC. The first byte that is sent is the least significant one. If one receives 150C one have to swap the first byte with the second one and to convert the value to decimal: 150C -> 0x0C15 -> 3093 RPM. |
| + | * Byte 4: Line Feed. | ||
| The UART baudrate should be set to 115200/ | The UART baudrate should be set to 115200/ | ||
| Line 1343: | 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 | + | ^ Product Name ^ Variant |
| - | | Genesys ZU | -3EG | B | DAD9C39-DAD9D32, | + | | Genesys ZU | -3EG | B | DAD9C39-DAD9D32, |
| + | | Genesys ZU | -3EG | B | All | [[programmable-logic: | ||
| + | | ::: | -3EG | D | D000000-DAF7EEC | ||
| + | | ::: | -5EV | D | D000000-DAF7F25 | ||
| ==== 1 Fan Assembly Error ==== | ==== 1 Fan Assembly Error ==== | ||
| Line 1361: | Line 1397: | ||
| A step-by-step description of the clip (dis)assembly is described here: http:// | A step-by-step description of the clip (dis)assembly is described here: http:// | ||
| + | ==== 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:// | ||
| + | and | ||
| + | [[https:// | ||