12-19-2019 01:53 AM - edited 12-19-2019 02:24 AM
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.
12-19-2019 03:55 AM
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).
12-20-2019 06:44 AM
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:
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.