Honored ContributorHi,
I'm integrating an independent FPGA which doesn't have a master CPU associated with it. I need to reset the FPGA right after it enters user mode. Will using Init_done signal Anded with Conf_done and looped back to a dedicated reset pin do the job? Am I missing something here? Should delay be added? Thanks, Boris Bakshan.
Honored ContributorWhat are you trying to reset? Are you trying to wipe the FPGA? Or the user logic internally?
Honored ContributorHi,
The user logic in the code.Honored ContributorHi Boris,
--- Quote Start --- I need to reset the FPGA right after it enters user mode. Will using Init_done signal Anded with Conf_done and looped back to a dedicated reset pin do the job? Am I missing something here? Should delay be added? --- Quote End --- My preference is to route the CONF_DONE signal to the input of a reset supervisor IC. For example, see p95 http://www.ovro.caltech.edu/~dwh/carma_board/gda06rb004_carma_v0.87_dec03.pdf The tri-state buffer is used to isolate CONF_DONE from the other reset sources. Using a reset IC ensures that the reset signal is asserted for a reasonable amount of time. Inside the FPGA, the reset signal is synchronized to each of the different clock domains using the standard asynchronous assert, synchronous deassert scheme seen in various Altera documents (which derive from some Cliff Cummings papers on the subject). Cheers, DaveHonored Contributora slightly different tactic is to drive a counter from a clock you know will be active when the FPGA is configured. run the counter for the desired length of time (count value), and reset your user logic based on this signal. this is sometimes done to wait for the input clock to stabilize before coming out of user reset
Honored ContributorHonored Contributorthe counter can power up to 0 upon configuration. is there a reason that won't work?
Honored ContributorHonored Contributorcan you point me to the docs where they recommend reset circuitry?
if there aren't any async signals to the reset counter, there isn't any recovery/removal to worry about, is there? interesting discussion, thanks :)Honored ContributorHonored ContributorThe problem of internal reset controllers or "self-reset" has been previously discussed. My conclusion is that you can generate a synchronously released reset signal by an internal reset generator with sufficient metastability MTBF. I'm using the method in a number of production designs where the hardware guys didn't provide a hardware reset signal.
http://www.alteraforum.com/forum/showthread.php?t=6067 http://www.alteraforum.com/forum/showthread.php?t=6621 http://www.alteraforum.com/forum/showthread.php?t=18591 The essential point in the metastability analysis is (if I remember the previous discussion right) that possible metastable events (= POR release violating clock setup/hold requirements) in the reset counter can't occur for all counter bits simultaneously, so you can caculate with multi-register MTBF.
