New Contributor
New ContributorIt's just strange that this is the default behaviour of Quartus since you almost never want this to happen.
It is only in very rare cases so I would think that there maybe was a setting for this.
But independent from the different user preference, I would expect Quartus to do some kind of analysis to know which clocks can be active at the same time. Or at least some simple checks. That could already solve many unnecessary timing fixes in the design.
P.S.: I do not see how your references can simplify my example case. If so, please explain to me
Occasional ContributorThink of it this way - I have 2 inputs to a mux (clkA and clkB), and you're right only one clock will be selected. Let's assume for a specific scenario, clkA is selected and somewhere in the the downstream logic, it will need to perform a transfer to clkB and this will need to be timing-analyzed.
If the tool where to cut all clkA <--> clkB paths, then the mentioned path will be affected, which is not what we want.
New ContributorSo you are confirming that these needlessly complex constraints need to be constructed to describe this almost standard expected behaviour?
I' m not saying that the case with one mux is complex but the complexity increase exponentially when you have more muxes in a row. I needed to define almost 20 extra generated_clocks for just 4 muxes in a certain clock tree. On top of that I needed to analyse very carefully how to set the false_paths for each of these clocks individually.
Frequent ContributorThere are many variables (such as selector's variable, launch register clock and latch register clock relationship and etc) to be considered for timing analysis. If constraints doesn't exist, unnecessary timing report details might got generated.
Eng Wei
Frequent ContributorHi there
I am transitioning this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.
Eng Wei
