12-03-2018 05:42 PM
I have an embedded systems application where I'm using several DCMs and PLLs to generate all the clocks required by my design. My design also uses the proc_sys_reset IP to generate the PLB, Peripheral and processor resets. The Locked output from the last DCM is driving the "DCM_Locked" input to the proc_sys_reset IP as recommended by the datasheet.
Based on my simulation it appears that the proc_sys_reset synchronously asserts/de-asserts the outputs. I would think it would asynchronously assert and synchronously de-assert the outputs otherwise, it's going to start using Slowest_Clk input before the DCMs have locked.
Is the the correct behavior for Proc Sys Reset IP? If so, what is the functional difference between driving Ext_Reset_In, Aux_Reset_In and DCM_Locked inputs?
12-05-2018 11:34 PM
As the name slowest_sync_clk input says it should be connected to the slowest synchronous clock used in the system.
DCM locked from clock generator to processing system reset is connected when clock from the DCM is used for system.
Whereas external reset is asynchronous input which is synchronized with clock used in system.
Same is with auxiliary reset but is used as assistant to main reset.
12-07-2018 11:06 AM
Thanks for your feedback! I have attached a block diagram and simulation screenshot for reference. In the block diagram, the output of a DCM is driving the "DCM_Locked" input of the Proc Sys Reset module. I was thinking that anytime a DCM loses lock it would cause Proc Sys Reset to asynchronously activate the reset outputs. So I expected to see the three outputs toggle high to the left of the red circled area in the sim screenshot). However, based on my simulation a clock has to be present for the module to activate the reset outputs (see red circled area in sim). I wanted to confirm that's the correct behavior or perhaps I don't have an accurate simulation model for the Proc Sys Reset module.