Stratix 10 reset_status asserted after FPGA is totally configured ? - Stratix 10 reset_status asserted after FPGA is totally configured ? The Stratix 10 Avalon Streaming Interface for PCI Express User Guide provides informations about the reset_status output of the HIP core. Is it safe to assume, that reset_status is deasserted (reset going to inactive state) after the FPGA is fully configured ? If yes, this reset is deasserted AFTER or WITH the reset (pin ninit_done) of the reset_release IP ? The reason why I am asking is, that if the HIP becomes operational before the user logic in order to reach the 100 ms boot requirement, then there might be the (theoretical) chance, that the deassertion of the reset_status is not detectable by the user logic, since the sector that contains the logic that analyses this output might still be frozen (inactive) at this time. Thanks for your assistance ! Replies: Re: Stratix 10 reset_status asserted after FPGA is totally configured ? If further support is needed in this thread, please post a response within 15 days. After 15 days, this thread will be transitioned to community support. The community users will be able to help you with your follow-up questions. Replies: Re: Stratix 10 reset_status asserted after FPGA is totally configured ? Yes, you are right. Replies: Re: Stratix 10 reset_status asserted after FPGA is totally configured ? Hi, I realized, that I was using an old version of the user guide (2019.09.30). After looking into the latest version I found that there is now a new input called ninit_done. Is it correct that this input cannot be tied to '0' but is required to be connected to the reset release IP ? Thanks Replies: Re: Stratix 10 reset_status asserted after FPGA is totally configured ? Yes, it is safe to use the reset_status for the AVMM or AVST interface. You can refer to the reset connection from the IP-generated example design. From the example design, it enabled the Avalone-ST reset output port (same function as reset_status) to connect with the reset of the on-chip memory and application interface. Replies: Re: Stratix 10 reset_status asserted after FPGA is totally configured ? Thanks for the additional informations. I think I haven't provided the whole picture, so I am trying once again: Due to the nature of the S10 architecture the safest approach is to reset the user logic with the reset release ip output after the FPGA is completely configured. Problem is, that we can't route the nint_done output of the reset release IP to the Avalon streaming masters / slaves that communicate with the S10 PCIe HardIP . According to the UG on page 80 of the HIP with streaming interfaces, there is the statement that reset_status can be used to reset the user logic. This seems to solve the problem for us, since those avalon streaming slaves/masters can now be reset with reset_status und the other parts of the FPGA with the reset release IP output. Is this a safe approach ? Replies: Re: Stratix 10 reset_status asserted after FPGA is totally configured ? At the initial power-up, you may use the nint_done signal together to hold the core logic in reset before entering the user mode. The reset_status will be helpful when you reboot the host or issue a perst from the host or trigger the npor, while the FPGA image is still alive, and that signal can use to reset your application logic. Replies: Re: Stratix 10 reset_status asserted after FPGA is totally configured ? The thing that concerns me, is the case where the HIP is configured in autonomous mode. In this case the HIP comes surely out of reset before the FPGA fabric. Now it is important to know, how "comes out of reset" is defined. In other words, the question is : Is it safe to use reset_status in this operation mode as high active reset for the user logic ? Is it safe to assume, that user logic will see reset_status = 1 and reset ? Replies: Re: Stratix 10 reset_status asserted after FPGA is totally configured ? Hi, The application layer can monitor this signal to determine when the IP core has come out of reset. This is not a concern for the application layer can't detect this signal during the initial power-up. The application layer should also monitor the tx_st_ready signal to determine when the transaction layer is ready to accept data. Regards -SK