TimeQuest timing relationship for unrelated clocks

[Altera_Forum]

Hi, 

 I would like to know the best way to handle a particular TimeQuest situation.  I have two clocks whose nominal frequencies are related (either the same or some rational multiple) but they come from different sources, so they need to be treated as asynchronous clocks.  There is a limited number of signals that cross domains and I want to be alerted to each one and cut the path for each one individually. This way I can be sure I don't have unintended domain crossings.  Rysc's very useful "TimeQuest User Guide" mentions this situation in the section titled "Relationships between Unrelated clocks". However, I do not see a solution described in the document.  For instance, say I have two clocks, both with 10 ns period. If I plug that into TimeQuest, I will get a 10 ns setup relationship. In reality what I want is a setup relationship that cannot be met, say 1 ps.  What is the best way to do this? I do not see an obvious approach. Maybe specify setup and hold uncertainties equal to an entire clock period? I have also considered making a small adjustment to the period of one of the clocks so it is different than the other. However, this does not always result in a setup relationship as small as one might think. So that is not a sure thing, especially if the clock frequencies might change in the future. Plus, it changes that frequency from it's desired nominal value.  Does anybody have a "best practice" suggestion?  Thank you!

[Altera_Forum]

I'm not expert on this subject, but I think the only way to handle this is to use multicycles.  

Clearly, at design stage, signals of unrelated clock domains must add waitstates or any other synchronization circuitry to make sure to meet the timing of the other clock. If frequency are different I guess you need to add at least F_high/F_low+1 synchronization cycles and define multicycles constraints accordingly.

[Altera_Forum]

Thank you for the response, Cris72. I think I did not clarify my question well enough, as you have answered a question I did not intend. 

 I am not interested so much in techniques to properly constrain the signals. Where a signal crosses a clock domain, I will add a register-to-register false path and cut the timing analysis for that signal altogether. And I will use anti-metastability registers.   What I am looking for is a way to be certain that TimeQuest will give me a timing violation if I have not put the false path constraint on a domain crossing signal.

[Altera_Forum]

--- Quote Start ---  Thank you for the response, Cris72. I think I did not clarify my question well enough, as you have answered a question I did not intend.  I am not interested so much in techniques to properly constrain the signals. Where a signal crosses a clock domain, I will add a register-to-register false path and cut the timing analysis for that signal altogether. And I will use anti-metastability registers.   What I am looking for is a way to be certain that TimeQuest will give me a timing violation if I have not put the false path constraint on a domain crossing signal.  --- Quote End ---    I don't see you have a problem if you apply clock groups to exclude all paths across domains. I will trust the tool for that

[Altera_Forum]

I have not used clock groups but my understanding of how they work is that it would specify that ALL signals from clock A to clock B will be excluded. I am trying to take a conservative approach where signals are excluded only by specific constraints for each signal. Clock groups would automatically exclude all signals and thus accidental domain crossings would no longer fail timing. Is my understanding of clock groups correct?

[Altera_Forum]

--- Quote Start ---  I have not used clock groups but my understanding of how they work is that it would specify that ALL signals from clock A to clock B will be excluded. I am trying to take a conservative approach where signals are excluded only by specific constraints for each signal. Clock groups would automatically exclude all signals and thus accidental domain crossings would no longer fail timing. Is my understanding of clock groups correct?  --- Quote End ---    It will exclude signals that cross domains (not all signals naturally). If your clocks are asynchronous then you need to exclude all signals that cross domains rather than select some of them.

[Altera_Forum]

--- Quote Start ---  I have not used clock groups but my understanding of how they work is that it would specify that ALL signals from clock A to clock B will be excluded. I am trying to take a conservative approach where signals are excluded only by specific constraints for each signal. Clock groups would automatically exclude all signals and thus accidental domain crossings would no longer fail timing. Is my understanding of clock groups correct?  --- Quote End ---    Yeah, that sounds about right.  I'm not sure that you can get TimeQuest to give you a warning about unconstrained paths between clock domains, but you can probably write a Tcl procedure to generate a warning.  Start by seeing if my idea works "manually", and then figure out how to do it using Tcl.  1. Synthesize your design with missing clock crossing logic  2. Start the TimeQuest GUI  3. Run the "Report clock transfers" report  Look at this report. Then go back and add a cut timing path, or create an asynchronous timing group, and you'll see the clock crossing paths reported as "false path".  Your custom clock report could be to loop over all entries in this report, and check that each entry matches whatever crossings you allow.  What you're essentially trying to do is to manually/explicitly cut the timing-paths between the clock domains at the logic level.  Personally I prefer cutting clock domains using clock groups, since I know that I have clock-domain crossing logic across the necessary paths (typically bridges, or dual-ported RAMs).  Cheers, Dave

[Altera_Forum]

Dave, 

 Thank you for the suggestion. I have given it a try using the manual approach. It looks like this would work if I was using false path constraints that specified clocks instead of registers as the from & to arguments of the command. However, when I run the "Report Clock Transfers," there is a footnote at the bottom that says:  "Entries labeled "false path" only account for clock-to-clock false paths and not path-based false paths. As a result, actual path counts may be lower than reported."  In other words, it ignores my register-to-register false paths.   It seems that I am trying to do something uncommon and that it is standard practice to just cut all paths across clock domains where signals are not expected to cross. Perhaps I should do the same.  Thanks everybody for the help.  Martin

[Altera_Forum]

Hi Martin, 

  --- Quote Start ---   It seems that I am trying to do something uncommon and that it is standard practice to just cut all paths across clock domains where signals are not expected to cross. Perhaps I should do the same.   --- Quote End ---   Its not unusual to find that you are doing something uncommon ... it happens to me all the time :)  In this case, I would typically define clock groups with the asynchronous clocks in different groups, so that TimeQuest cuts all the paths.  If a design is nicely implemented, with synchronous logic in their own blocks, and blocks connected via bridges/synchronizing logic, then I feel safe using this TimeQuest feature.  If however you're trying to constrain a design written in the "spaghetti style" of coding, with numerous clocks, then I suspect you'll have other issues than just TimeQuest constraints, and a thorough review of that design would be advised before trying to setup timing constraints.  Cheers, Dave

[Altera_Forum]

If you use "Report Timing" to report timing on all paths between those two clocks, I think it will exclude all false paths. 

So, it should give you a list of paths you have yet not added a set_false_path for.  IIRC, get_path -from [get_clocks clkA] -to [get_clocks clkB] -nworst XX also won't list false paths.