Clock group vs. clock false path

[Altera_Forum]

I have a couple of clocks coming in that are not related to each other. Before I put them in a group, I ran TimeQuest and it was complaining about some setup slack violation. I know I should have used set_clock_groups for these two clocks, but TimeQuest gives me the option of declaring a false path between the two clocks - what is the difference between setting a false path between clocks and putting them in a group? 

 Thank you

[Altera_Forum]

They are two equivalent methods. 

In either case, timequest is told that clocks are unrelated(asynchrnounous or exclusive).

[Altera_Forum]

Thank you kaz! 

So, if I have all my domain crossings taken care of, can I safely ignore all timing related issues involving separate clocks, or am I making a bad generalization - by ignore, I mean use clock groups and clock false paths, which usually makes TimeQuest not show those as violations.

[Altera_Forum]

Er.. you sound like you're making a bad generalization. 

 You can(should) use set_clock_groups to tell TimeQuest about unrelated (asynchronous) or exclusive (that are not active at the same time).  You must not use it to lie to TimeQuest, telling it that some clocks are unrelated when they are actually related.

[Altera_Forum]

If timequest knows some clks are unrelated then it should not care about the register timing violations across the interface between those clks. 

 It is up to you then to transfer signals across safely i.e. two stage synchronisers. If you are using dc fifos then that implies two stage synchronisers.   The idea is that unrelated clks will suffer violations inevitabley but you absorb them through two stage synchronisers.   Apart from unrelated clks, you may also add false path to other signals that change state occasionally e.g. system setup values from software(provided you use synchronisers on them whether they change clk domain or not). This may help lessen the burden on timing closure.   If timequest reports violations then it will be those within one clk domain.

[Altera_Forum]

kaz, that makes a lot of sense. funny you mention it, I have a reset signal that changes very rarely that is also causing some timing issues. A false path there should solve that issue - the reset signal is valid for multiple cycles of the slowest clock. 

 rbugalho, I have a number of clocks in the system and no matter what they are (even 1:1 plls), I don't trust their relationships and I either double flop or use dcfifo for CDC. Would I still be lying to TimeQuest if I put all those clocks in groups?

[Altera_Forum]

Ah. If you are 100% sure that all the clock domains have proper interfaces, it's ok. 

 Beware of modules written by others, though.. :) Even Altera's DCFIFO can be configured to have a single synchronization stage, for use with related clocks.

[Altera_Forum]

One of these days I will stop listening to my OCD... in the mean time, all the dcfifos I use have 5 or more stages... :) 

 Thank you for all the help!

[Altera_Forum]

--- Quote Start ---  kaz, that makes a lot of sense. funny you mention it, I have a reset signal that changes very rarely that is also causing some timing issues. A false path there should solve that issue - the reset signal is valid for multiple cycles of the slowest clock.   rbugalho, I have a number of clocks in the system and no matter what they are (even 1:1 plls), I don't trust their relationships and I either double flop or use dcfifo for CDC. Would I still be lying to TimeQuest if I put all those clocks in groups?  --- Quote End ---     Anything but reset... if your reset means that signal for register reset then you can't put false path since every path will need synchroniser and this defeats the purpose. It is practical for few registers,

[Altera_Forum]

All of my resets are handled asynchronously; i.e. 

 always @(posedge clock or negedge reset_n) begin  if (!reset_n)  ...  else  ... end  Now, granted that reset_n is not an input pin. It is generated from a counter -- basically after the FPGA is programmed, the reset_n is held low for a number of clocks before it is release.  Do you still see issues with the reset_n as implemented here?

[Altera_Forum]

Your reset if generated in a different clock domain need to be synchronised by two stage registers before using it in another clk domain. Then you can apply false path on both synchronisers. applying clk groups or cut path betwen clocks implies first synchroniser only which is over zealous. 

 By the way let me reword my previous post.  For occasionally changing signals such as software commands or reset ...etc. it is possible to set false path if that is going to help timing(irrespective of clk domain change). The false paths must be on the synchroniser registers and not beyond.

[Altera_Forum]

Got it now! The reset signal should be synchronized like any other async signal should. I have been so diligent with CDC where it is obvious, but neglected others such as reset inputs. 

 Thank you for the clarification.