Similar frequency clocks

[shaiko]

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_]

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 -all
set_clock_groups -asynchronous -group {clk_a} -group {clk_b}

[shaiko]

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 ?

[Nurina]

Hello,

Can you provide the following information:

• Quartus version
• OS (Linux/Windows?)
• Target device

To 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.html

Report Asynchronous CDC: https://www.intel.com/content/www/us/en/docs/programmable/683243/21-3/report-asynchronous-cdc.html

Report CDC Viewer: https://www.intel.com/content/www/us/en/docs/programmable/683243/21-3/report-cdc-viewer.html

Does this help?

-Nurina

[shaiko]

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]

Hello,

Report Asynchronous CDC is available starting Quartus 21.1Pro.

Do you have any further questions?

[shaiko]

That's all I needed.
Thanks.

[Nurina]

Hello,

I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, please login to https://supporttickets.intel.com , view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.

p/s: If any answer from community or Intel support are helpful, please feel free to mark as solution, give Kudos and rate 4/5 survey

Regards,

Nurina