cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
adatatw
Contributor
Contributor
650 Views
Registered: ‎12-06-2011

Zynq US+ MPSoC - Reset PS using PSPCIE perst_n (MIO pin)

Hi all,

I have some questions about how to get the Zynq US+ MPSoC PS to reset along with the PSPCIE block, in an endpoint application, when PCIe reset is asserted (one of the MIO29 to MIO37 pins).

Is there a simple way to set things up so that the PCIe reset for the PSPCIE block also resets the PS as well?

If not, what would be the recommended way to allow the PSPCIE reset to reset the PS, in hardware, in a new board design? The obvious way is to include the PCIe reset in the generation of the PS_POR_B signal.

Is it feasible to configure the MIO or EMIO such that it generates a NMI to any or all CPUs, where the NMI handler triggers a PS reset?

Thanks in advance for any pointers.

 

0 Kudos
2 Replies
pmarise
Xilinx Employee
Xilinx Employee
623 Views
Registered: ‎10-25-2018

One solution is that, when ever you give a reset to PCIe by triggering one of the MIO29 to MIO37, same time assert soft reset to processor

Second solution is that, using PCW enable PL to PS APU/RPU FIQ (Fast Interrupt reQuest) on connect these interrupts using GPIO EMIO (Enable GPIOs to PL), so when you want to reset PCIe first trigger GPIO to PL then you will receive FIQ (FIQ is low level triggered?), in the FIQ handler first make the GPIO to high, then you can trigger PS reset.

make sure GPIO EMIO is set to high before enabling the FIQ (considering FIQ is low level triggered).

0 Kudos
adatatw
Contributor
Contributor
570 Views
Registered: ‎12-06-2011

@pmarise

Thank you for the reply.

On further thought, allowing the PCIe fundamental reset (that is, the physical signal) to reset the PS isn't enough.

PCIe Hot Reset (the in-band reset mechanism) also needs to be supported, and the requirement is that asserting Hot Reset should not take down the PCIe link. I think that resetting the entire PS in response to PCIe Hot Reset would cause a link down event and thus be a protocol violation.

It seems to me that, in an endpoint application, something like the PMU must be used to constantly monitor the registers in the PS that indicate (a) whether or not perst_n is asserted and (b) whether or not Hot Reset is asserted. Then:

  • If the PMU sees perst_n is asserted, it can fully reset the PS and allow the FSBL to reconfigure the PSPCIE. It does not matter if the full PS reset causes link down as long the FSBL executes quickly enough.
  • If the PMU sees PCIe Hot Reset is asserted (and perst_n is not asserted), it must partially reset the PS such that most things are brought to a known good state, but it must not destroy the PSPCIE configuration in order to avoid link down.

The drawback of the PMU approach is that if the switching infrastructure in the PS hangs up for any reason, the PMU will be unable to monitor for PCIe/Hot Reset, and the result would be a PCIe endpoint that does not return to a known good state when the host asserts perst_n. That's a bad thing, if it can happen.

0 Kudos