GPIO Reset to PL - 2020.2 English

Vivado configuration allows you to enable fabric resets from PS to PL. The following figure shows that the Zynq UltraScale+ block outputs pl_resetn0 and pl_resetn1 signals with Fabric Reset Enabled and the Number of Fabric Resets set to 2, can be used to drive reset pins of PL components.

Figure 1. Resets from PS to PL

The pl_resetn signals are implemented with PS GPIOs. Pl_resetn pins are released after bitstream configuration in software using the psu_ps_pl_reset_config_data function. In the case where a subsystem also uses GPIO for purpose other than reset, the GPIO block is included in the subsystem definition. The image below shows an example of an APU subsystem with GPIO as a slave peripheral.

Figure 2. APU Subsystem with GPIO

In the case where GPIO is a subsystem slave peripheral, the entire GPIO component will be reset as part of the restart process when the subsystem is being restarted. Since pl_resetn are implemented with GPIOs, pl_resetn will be forced low during subsystem restart. This behavior may be undesirable if the pl_resent signals are being used to drive PL IPs in subsystems other than the one being reset. For example, if pl_resetn0 drives resets to PL IP for APU subsystem and pl_resetn1 drives PL IPs for RPU subsystem.

During APU subsystem restart, both pl_resetn0 and pl_resent1 will be forced into the reset state. Consequently, PL IPs in RPU subsystem will be reset. This is the wrong behavior since APU-restart should not affect the RPU subsystem as the GPIO is implicitly shared between the APU and RPU subsystem via pl_resetn signals. Since sharing of peripherals is not supported for subsystem restart, pl_resetn causes problems during subsystem reset. The work-around is to skip idling and resetting GPIO peripheral during any subsystem restart even if the component is assigned in the subsystem/isolation configuration.

To skip the GPIO reset during the node Idling and reset, build the PMU firmware with following flag:

REMOVE_GPIO_FROM_NODE_RESET_INFO