TimeQuest issue need you help

[Altera_Forum]

There are two clock domains in my project, one is 100MHz, another is 250MHz. There are some time issue after full compilation as attached file shows. The issue is caused by one signal from 100MHz to 250MHz. I can deal with it by setting false paths constrain, my question is tha can i set multi-cycle paths constrain for these paths? Someone told me that multi-cycle paths constain is only used when the clocks frequecy are multiple times relationship between that two clocks. But, the relationship for my project is 2.5 times, which is not integral times related.

[Altera_Forum]

From your picture, which edge do you want launching(and what's it's time) and which edge is latching(and what's it's time)? You can usually get it with multicycles. 

That being said, I had a case where the conditions really weren't possible. Note that set_max_delay will override the setup relationship with whatever number you want, so it will do what you want.

[Altera_Forum]

--- Quote Start ---  From your picture, which edge do you want launching(and what's it's time) and which edge is latching(and what's it's time)? You can usually get it with multicycles. That being said, I had a case where the conditions really weren't possible. Note that set_max_delay will override the setup relationship with whatever number you want, so it will do what you want.  --- Quote End ---    Hi Rysc:  Thanks for you reply!  I can deal with this issue use two kinds of constrain.  The first constrain is as below, which just setting false paths constain. set_false_path -from [get_registers {*tdc_ctrl_set[0]}] -to [get_clocks {inst|altpll_component|pll|clk[2]}]  The second constrain is as below, which just setting multi-cycle paths constrian. set_multicycle_path -from [get_clocks {inst|altpll_component|pll|clk[0]}] -to [get_clocks {inst|altpll_component|pll|clk[2]}] -end -setup 4 set_multicycle_path -from [get_clocks {inst|altpll_component|pll|clk[0]}] -to [get_clocks {inst|altpll_component|pll|clk[2]}] -end -hold 3   My question is whether TimeQuest doesn't permit customer using multi-cycle path constrain when two clocks frequency aren't interal times relationship, like my case is (250/100) 2.5 time?

[Altera_Forum]

--- Quote Start ---  Hi Rysc:  Thanks for you reply!  I can deal with this issue use two kinds of constrain.  The first constrain is as below, which just setting false paths constain. set_false_path -from [get_registers {*tdc_ctrl_set[0]}] -to [get_clocks {inst|altpll_component|pll|clk[2]}]  The second constrain is as below, which just setting multi-cycle paths constrian. set_multicycle_path -from [get_clocks {inst|altpll_component|pll|clk[0]}] -to [get_clocks {inst|altpll_component|pll|clk[2]}] -end -setup 4 set_multicycle_path -from [get_clocks {inst|altpll_component|pll|clk[0]}] -to [get_clocks {inst|altpll_component|pll|clk[2]}] -end -hold 3   My question is whether TimeQuest doesn't permit customer using multi-cycle path constrain when two clocks frequency aren't interal times relationship, like my case is (250/100) 2.5 time?  --- Quote End ---    The purpose of any design is to pass timing rather than get a reported timing pass. You cannot freely apply deconstraints unless applicable to your case. To apply false path is applicable if you don't care about sampling your signal correctly at first edge. Then you may decide to use synchronisers to pick it up after one or two sampling attempts(double synchronisers). This could be the case of a signal that changes occasionally.   Similarly, multicycle is decided by you the designer after you decide which edge launches to which latch according to your logic and if it turned out that you have 2 or more minimum clocks in between (and always) then you can apply multicycle of 2.

[Altera_Forum]

The two constraints are mutually exclusive(set_false_path has the highest priority).  

You're 10ns clock has edges at 0, 10, 20, 30... You're 4ns clock has edges at 0, 4, 8, 12, 16, 20... TimeQuest will find the most restrictive relationship, which is launching at 10 and latching at 12, or 2ns. Note that right off the bat, that is a fraction of one of the periods. If you do a "multicycle -setup -end 2", then the latch edge moves out one of its periods and your setup relationship is 6ns. If you do a multicycle -setup -source 2, then it moves out one of the source periods, becoming a setup relationship of 12ns. Note that none of these are not necessarily multiples of either clock, so it's not true that it can only be a multiple of one of the clocks. What is true is that it moves a multiple of each clock.  So doing "multicycle -end -setup 2,3,4,5..." would give you setup relationships of 6, 10, 14, 18...  Doing "multicycle -source setup 2,3,..." would give you setup relationships of 12, 22,... So those values are your options with multicycles setups. (I'm ignoring hold right now, as well as what happens if any of your registers are falling edge, which is a whole other set of analysis.)  Those are your options, but the question is, how does the circuit work? Does it launch data at time 0ns? If so, which edge latches it? Does it launch new data at 10ns? Which edge latches that? Let's say you launch on every edge, but write your latching circuit to latch at time 8ns and time 16ns, and this repeats over time, i.e. you latch at 8, 16, 28, 36, 48, 56,... You're most restrictive one is the 6ns setup relationship. This can be achieved with a multicycle setup -end of 2. Let's say your circuit latched at times, 4, 16, 24, 36, 44, 56,... You're most restictive setup would be the launch at 0ns and latch at 4ns. In this case, multicycles can't do that. It's not one of the options, and you would have to do: set_max_delay -from [get_clocks ...clk[0]] -to [get_clocks ...[clk2]] 4.0 I've only seen the need to do this one time, but it did come in handy.

[Altera_Forum]

My personal advice regarding multicycle is this:  

avoid it unless you are really desparate with fmax then make it absolutely sure that it is applicable.  Unfortunately timequest has made it look like spreading chocolate anywhere one thinks and has diverted its concept for the sake of the tool's default behaviour. Let me explain this point:Multicycle is not just matter of applying it when it sounds so but the design sampling phase must match the launched data otherwise your logic will go stray while timing passes. Timequest borrowed multicycle idea to apply it whenever the default definition of current launch/latch edges are too restrictive such as clocks with different phases and rate. Timequest should also have been telling you that you the designer must in parallel make sure that you are sampling(latching) in sync with multicycle approach.

[Altera_Forum]

Hi Rysc, kaz: 

 You two gave me detail explanations. I think it's clear for me. Thank you very much!!!