Honored ContributorI am planning on using the altclkctrl block to switch between two unrelated clocks, and was wondering if there were any restrictions on the clkselect pin.
Specifically, will there be any hazards generated if the logic used to drive this pin is based off the resulting clock? What about if it is generated off either of the input clocks? Will the timing analyzer be able to properly handle these cases?
Honored ContributorWell how often do you plan on switching the thing/ Obviously if the clocks are not related, then using either of the clocks to control that signal will make it asynchronous to at least one of the clocks. But I would think that's not really an issue. I mean, if you're switching your clock hopefully you've got your downstream logic in reset anyway (or it's tolerant to a clock glitch).
With regards to the timing analyzer, I don't know if it will even get analyzed. However, since it's going to be asynchronous anyway, it seems you could just tell it that it's a false path. JakeHonored ContributorI was planning on switching it relatively rarely, but the downstream logic would running and not be in reset. The module has a "glitch free" option that would have been enabled.
However, It ended up including this module made the fitter unhappy (the Fitter produced an error message saying it couldn't fit in PLL2, with no explanation why) so I reverted back to the previous implementation, a simple register based clock divider. It works and met the Recommended Clock-Generation Technique diagram as shown in Figure 5-4 in http://www.altera.com/literature/hb/qts/qts_qii51006.pdf
