set_clock_groups vs. set_max_delay/set_min_delay

[Altera_Forum]

We are currently having a discussion in my company on whether to use set_clock_groups -asynchronous or set_max_delay/set_min_delay for constraining asynchronous clock domains. 

 I did find some other discussions on this, most notably this one (http://www.alteraforum.com/forum/showthread.php?t=18790). Our concern with using set_clock_groups is that one bit in a group of signals will end up having a much longer delay than the other signals in the group, between two registers clocked with different clocks. (e.g., several latch clock cycles more) My thoughts is that even if this will never occur normally, it should certainly be possible to make a design where it does happen. And if someone were to do that in one of our designs, wouldn't it be nice to get a timing violation, rather than no warning at all?  On the other hand, what are the advantages of using set_clock groups over set_max_delay/set_min_delay?

[Altera_Forum]

Good topic. From my experience, most users use set_clock_groups and I've never heard of a problem(at least one that would have been caught by set_max/min_delay). I believe it's a cleaner constraint(easier to read when properly formatted).  

That being said, I understand the concern. What value would you go with for set_min/max_delay? Remember that clock skew is used in this calculation, which can be many ns, so what might seem like a loose constraint suddenly gets tighter. My feeling is if the set_max/min constraint is really loose, it probably doesn't hurt anything, i.e. if you do a min of -10 and max of 20, it's not going to have an effect on the design. I'm sure there are cases where I'm wrong, and I tend to assume there's not comb logic between unrelated domain transfers. If there is, the max may go higher. I've seen users want to do something smaller on the max. The question I ask is "what does a failure look like?" For example, if you put in something small like 8ns for set_max_delay, can you show how a delay of 8.5ns causes a failure?

[Altera_Forum]

> The question I ask is "what does a failure look like?" 

 Say I want to transfer a two bit gray counter from a 125 MHz domain to a 150 MHz domain. In this case I would set the min delay to -1 ns and the max delay to 7 ns. If you instead set the max delay to 8 ns, you potentially risk that the difference in delay between the two bits is 9 ns, in which case you could miss a count value and go straight from 00 (0) to 11 (2) or even to 10 (3) then back to 11 (2).  I suppose if this is something that will never actually happen as long as there is no logic between the CDC registers (?), it would be fairly safe to start using set_clock_groups. But I'm skeptical.

[Altera_Forum]

Good example, but I don't think it requires a general constraint from 125MHz -> 150Mhz domain. Instead it should be a constraint on that specific gray -> retime_reg transfer. And set_max/min_delay isn't really what you want but set_max_skew.  

Set_max/min_delay covers across timing models, which can become very restrictive because of this, yet different timing models would never occur at the same time in hardware, i.e. one path won't be at the fast timing model while another is at the slow. Now, with set_max_skew you still have to put a set_max/min_delay that is really loose(say +/-100) because set_max_skew doesn't overwrite the setup/hold relationships. Personally I would like to see that changed. Also, in this scenario, you can't do a set_clock_groups between the domains because it would also cut set_max_skew analysis. So if there are other paths that can be cut you have to manually find them and false path them. I'm debating if that behavior is incorrect too. That all being said, most designs either cut the path or do a set_max/min_delay constraint(but on the actual paths, not the clock transfers).

[Altera_Forum]

The point you are making is that if you set false path then the tool wouldn't check if the delay of bits of same bus(bus skew) across domains is so bad that errors will occur without being reported. I agree that in a bad design this is a potential problem but you should pick it up in your company's regression testing. If you set min/max delay instead o false path would the tool then tell you if your delays have been achieved or not? it will certainly tell you there are violations due to asynchronous tranfer across clocks. 

 One way to prevent such delay is to insert registers right at the end of clk1 signals so there would be no comb. logic any further.

[Altera_Forum]

The path perchrc describes is register to register, so there's no combinatorial logic. The assumption is that there should never be 8ns of skew between multiple bits, and I would say that's a pretty safe assumption. You can usually go across chip and meet 8ns, and the fitter is going to put these paths pretty close together just to reduce routing(even if it doesn't care about timing). That all being said, I understand that without a constraint, how do you really know for sure. 

(Another option is to run report_skew on the paths in question on the back-end. You would have to load an .sdc that doesn't do the set_clock_groups, but it would be a pretty easy test.)

[Altera_Forum]

--- Quote Start ---  And set_max/min_delay isn't really what you want but set_max_skew.  --- Quote End ---    That does in fact sound like a better alternative, especially after hearing that set_max/min_delay constrain the domains for distinct timing models. I have to say though, it would be a lot cleaner to be able to combine set_max_skew with set_clock_groups rather than adding loose max/min constraints.    --- Quote Start ---  The assumption is that there should never be 8ns of skew between multiple bits, and I would say that's a pretty safe assumption.  --- Quote End ---    Then is there really any harm in specifying general constraints between all asynchronous clock domains? It's easier not having to specify a bunch of individual path constraints.

[Altera_Forum]

Let's say one clock domain comes in on a clock and drives a global, and has 4ns of clock delay. The other domain is on a PLL and has 0ns of clock delay due to PLL compensation. So there are 4ns of skew. In one direction, that skew could cut into the set_max_delay of 8ns, so the datapath has to be 4ns. That should still be pretty do-able, but it's no longer a slam dunk. Now let's say it cuts the other way, so the set_min_delay of -1ns suddenly looks like a positive 3ns requirement. Now the router has to add at least 3ns of delay to the datapath at the fast corner. At the slow corner this same path may be 6-7ns. Suddenly it's barely meeting timing, and every path has to thread that needle. That's why it gets tricky.

[Altera_Forum]

We are encountering issues in a design where gray counters are used on a big ArriaV device which could be related to this. Currently the constraints are simply set_clock_groups constraints so in theory the skew between the different bits could be too large. 

 How can I check this as report_skew doesn't find any paths because of the set_clock_groups constraint? Is there now a way to constrain busses (such as gray counters) for a max delay without 'breaking' the clock_groups constraint (as set_max_skew cannot be used with set_clock_groups)? It will be quite cumbersome if we need to constrain every path which crosses clock domains. An option could eventually be added which makes set_max_skew as a higher priority than clock_groups_constraint...

[Altera_Forum]

Are you sure the issues are related to the gray code counters? (Every design has gray code counters crossing domains...) The fitter does naturally pull them together just to reduce routing resources used. Something has to go drastically wrong for them to get a skew greater than one clock period. I've attached a .tcl file that analyzes the gray code paths in FIFOs and can be used to analyze skew on other paths you set custom. It only runs in TimeQuest and doesn't drive the fitter, but can help determine if there's a problem. (It also doesn't take clock skew into account). Hopefully it helps determine if you really have this problem or it's something else.