If MIO34 is configured in Vivado to be PMU GPO1, a glitch on this line is possible when PS_POR_B gets asserted low.
The PMUFW actively drives GPO1 (MIO34) high by default and a PS_POR_B assertion briefly drives GPO1 low before changing MIO34 to tristate.
Zynq UltraScale+ MPSoC/RFSoC
Customer should use the methods listed below to evaluate for potential impact of this glitch.
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 and drive it low.
This behavior is forced by making the CONNECT_PMU_GPO_2_VAL macro equal to 0 in xpfw_config.h.
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.