Honored Contributor
Honored ContributorClock 16 is divided down based off the 5khz which is based off the 20Mhz. The clk16 is created by a counter that counts up to 16 and creates a pulse that is one 5khz pulse wide.
How do I know I have a failure? Well I don't. We have some data glitches with this signal once in a while. I am learning ripple clock based designs have some downsides and clock enables should instead be used. I guess I'm still having trouble understanding or clearly seeing the delay between 20Mhz and clk16, which is my concern. But based on your suggestion, I do see the Data Path showing the end data going all the way back to the input clock and the delay is not very much. Maybe I just needed some convincing. I should mention, that this design previously had a mistaken set_false_path constraint which seperated the 20Mhz and clk16: set_false_path -from [get_registers {component_1|clk_16}] -to [get_clocks {20_Mhz}] Would this have changed the actual fitter or place and route? That constraint has since been deleted and my analysis above is a new place and route with the false_path statement deleted. I'll throw in my generated clock statements (simplified) just for additional checking: create_generated_clock -name 5Khz -source [get_pins {pll|20_Mhz}] -divide_by 4000 [get_pins {5khz_generator|regout}] create_generated_clock -name clk_16 -source [get_pins {5khz_generator|regout}] -divide_by 1 [get_registers {Component_1|clk_16}] Rsync, your wiki tutorial has been invaluable to me. I hope you find time to add the additional sections - including the section planned on ripple clocks.
