As clarified in the answers of another question, our carrier card will extend reset time on the input PERIPHERAL_RESET_N pin.
Then we have a question regarding to the timing details: How much delay between input signal PERIPHERAL_RESET_N and output PEX_Cn_RST_N? Do you have timing specifications (Min/Max) of the delay on both falling edge and rising edge?
As you can see in the DG: When PERIPHERAL_RESET_N is asserted, the SoC, eMMC, & QSPI are reset, and so the PEX RST. There is no timing spec on that.
When PERIPHERAL_RESET_N is asserted, the SoC, eMMC, & QSPI are reset, and so the PEX RST
From your answer, at the falling edge of PERIPHERAL_RESET_N input, the SoC, eMMC, & QSPI will immediately fall into reset. My concern was, upon receiving the falling edge of PERIPHERAL_RESET_N, the SoC would possibly still do some urgent winding-down process, then enter into true reset state and assert its outputs PEX RSTn. That delay could be substantial (in ms). As long as you can confirm this is not a concern, it will be perfect to us.
Please confirm above reset behavior (in Bold text)
(FYI: the reason I asked this question is, most commercial desktop processors will not enter into reset immediately upon receiving a hardware reset input, which has been a great headache to the real-time embedded system. Hardware guys have to spend a lot of efforts on the reset structure to handle this behavior)
The devices will be reset at once as the reset pin of them is connected to PERIPHERAL_RESET_N but there is no timing on this can be shared as there is not so strict timing request/usage on Orin.
And for real-time design as you said, it should be cautious on this since maybe your design needs more strict timing, you may need to measure that to check if it can be used to the real-time design.
Thanks for confirming the devices “will be reset at once as the reset pin of them is connected to PERIPHERAL_RESET_N”.
Yes we will scope out the relationship between PERIPHERAL_RESET_N and PEX RST outputs. Leave this thread open for a couple more days, in case we have some new findings. If no question after a few days, I will request to close this topic…
Again, thanks a lot for your answers