Forum Discussion
Occasional ContributorSimilar frequency clocks
Frequent ContributorFirst, for your second clock, you meant to write:
create_clock -name clk_b -period 1.0 [get_ports clk_b]
correct? Otherwise your clocks are derived from the same source.
In any event, you want to tell the timing analyzer NOT to check setup/hold across the clock domain boundary, because it is not meaningful to do so between two asynchronous clocks.
So then TimeQuest will not analyze signals that cross the clock domain boundaries, and obviously not generate any timing violations.
And you should use a dual rank synchronizer for any signals that cross the clock domain boundaries. If you don't you are just asking for trouble in having intermittent circuit behavior.
So add this to your .sdc file:
remove_clock_groups -all
set_clock_groups -asynchronous -group {clk_a} -group {clk_b}
hostYes, I did mean: clk_b. Thanks for the correction.
About this:
you want to tell the timing analyzer NOT to check setup/hold across the clock domain boundary, because it is not meaningful to do so between two asynchronous clocks.
I understand that...and I agree that the paths of signals crossing asynchronous shall be declared as false with. However, this should be done only AFTER a proper CDC mechanism is implemented.
But consider the following scenario:
A designer forgot to implement a safe CDC mechanism and didn't declare the false paths.
Now, if the asynchronous clocks have an unrelated SDC waveform (frequency and phase) the tool will analyze transitions across multiple cycles and eventually will discover timing violation - The design would fail timing with a clear warning to the user to correct his ways.
But in the special case of the asynchronous clocks having the same waveform - the tool won't find out the problem and the user would think his design is clean.
A proper design methodology should of course involve reviewing the various clock domains and their interactions - but errors do occur and I'm trying to put a fail safe mechanism in place to discover such scenarios.
In other words:
I'm looking for a way to model (with SDC) the "frequency and phase uncertainties" between these clocks such that the tool DOES fail timing (because this is what will happen in real life) and alarm the user.
Any idea what other SDC commands can be added to achieve this goal ?
