AR# 71952


Design Advisory for Zynq UltraScale+ MPSoC/RFSoC: A glitch might be observed on the PMU GPO1[2] (MIO34) following assertion of PS_POR_B


If MIO34 is configured in Vivado to be PMU GPO1[2], a glitch on this line is possible when PS_POR_B gets asserted low.

The PMUFW actively drives GPO1[2] (MIO34) high by default and a PS_POR_B assertion briefly drives GPO1[2] low before changing MIO34 to tristate.



Device Affected:

Zynq UltraScale+ MPSoC/RFSoC


Customer should use the methods listed below to evaluate for potential impact of this glitch.

Configuration Affected:

  • Is MIO34 configured in Vivado to be PMU GPO1[2]?
    • If NO, then there is NO RISK
  • Is MIO34 connected on the board to a circuit that is sensitive to glitches?
    • If NO, then there is NO RISK
  • The function of MIO34 is triggering a specific board response. Is this response relevant when PS_POR_B is asserted?
    • If NO, then there is NO RISK
  • Measure the MIO34 glitch voltage. Does it fall below the Voh(min) described in DS925 (PS MIO Output Levels)?
    • If NO, then there is NO RISK

If the answer is YES to ALL above questions, Xilinx recommends changing the PMUFW behavior by following the work-around below.


Staring from the 2019.1 release, it will be possible to change the behavior of the PMUFW so that it uses MIO34 like an open-drain output with a pull-up to achieve the default high signal.

In this case, only when MIO34 needs to go low, the PMUFW will enable GPO1[2] and drive it low.

This behavior is forced by making the CONNECT_PMU_GPO_2_VAL  macro equal to 0 in xpfw_config.h.

Important Note

The pull-up to guarantee the default high signal can be internal or external.

 Because the rise time after de-assertion of the open-drain is a function of pull-up strength vs load, the user should decide if the internal pull-up is sufficient or an external pullup is required.

AR# 71952
Date 04/26/2019
Status Active
Type Design Advisory
People Also Viewed