Similar frequency clocks

Question

My design has 2 clock domains defined as follows with the same waveform:create_clock -name clk_a -period 1.0 [get_ports clk_a]create_clock -name clk_b -period 1.0 [get_ports clk_a]
The 2 clocks come from different sources and although they are define as having the same frequency and phase - they are asynchronous to each other.

Question:
How will timequest analyze these clocks ?
WIll it be able to find timing violations on paths between them ?

_ak6dn_ · Answer

First, 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 -allset_clock_groups -asynchronous -group {clk_a} -group {clk_b}

nurina · Answer

Hello,Can you provide the following information:Quartus versionOS (Linux/Windows?)Target deviceTo answer your question about uncertainties, the closest that I know of would be derive_clock_uncertainty. You may find the below reports to be useful:Report Clock Transfers: https://www.intel.com/content/www/us/en/docs/programmable/683243/21-3/report-clock-transfers.htmlReport Asynchronous CDC: https://www.intel.com/content/www/us/en/docs/programmable/683243/21-3/report-asynchronous-cdc.htmlReport CDC Viewer: https://www.intel.com/content/www/us/en/docs/programmable/683243/21-3/report-cdc-viewer.htmlDoes this help?-Nurina

host · Answer

Yes, 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 ?

host · Answer

I'm using Quartus 18.1 on Windows and my question isn't device specific.
With what Quartus version did you introduce the "Report Asynchronous CDC" command ? 
I can't find it in Time Quest...

nurina · Answer

Hello,Report Asynchronous CDC is available starting Quartus 21.1Pro.Do you have any further questions?

Forum Discussion

Similar frequency clocks

7 Replies

Recent Discussions

Quartus Prim Pro: "Fatal Error: Segment Violation, Access Violation"

timing violation fix

log signal to signal tap

Docker image for Quartus Pro 26.1 missing ?

Licensing ‘Know-How’ Guide