Forum Discussion
Hi Sumanth,
Sorry for the delay. To address your query:
- Purpose of Reconfiguration: If your aim is to trigger reconfiguration, it is best to initiate it by pulling the nCONFIG pin low to at least the minimum tCFG low-pulse width. This method is more reliable and avoids the dependency on the reset signal within the IP core, which primarily resets the IP core itself rather than triggering a full reconfiguration.
- Reset Signal Pulse Width: While the reset signal within the Remote Update IP is asynchronous, your observation that increasing the pulse width to more than 100 ns results in consistent reconfiguration suggests that the shorter pulse width might not have been reliably detected. Ensuring a longer pulse width (as you have done) seems to provide the necessary stability.
- Clock Dependency: The 10 MHz clock for the Remote Update IP should generally be sufficient. However, any asynchronous reset signal must be synchronized with the clock to avoid metastability issues. This synchronization might explain why a longer reset pulse width results in more reliable operation.
For your specific application, I recommend continuing with the longer reset signal pulse width if you choose to use the IP core's reset signal. However, for more robust reconfiguration, using the nCONFIG pin as suggested is the best practice.
Please let me know if you need any further assistance.
Best regards,
Fakhrul
- FvM1 year ago
Super Contributor
Hi,
reset input isn't the intended input to trigger a reconfiguration, it's reconfig input. All remote update IP ports need to meet timing constraints, as any FPGA IP. Reset e.g. is an asynchronous input that need to be released synchronous to clk, otherwise arbitrary erratic behaviour may be observed. Nothing specific to remote update.If you e.g. consider to trigger reconfig with a push button, the signal should be debounced and synchronized to clk.