State A => State B multicycle path?

--- Quote Start ---

You do not want this flop to go metastable.

--- Quote End ---

Why not? Since I don't care about whether the Latch_FF goes metastable at T1 and since Tsu is guaranteed at T2 I can't see what trouble this could cause? The Latch_FF.Q will be stable after T2 regardless if Latch_FF earlier went metastable at T1.

i'm assuming that a ff in a metastable state will still clock in a correct signal at the next clock cycle. as long as this holds true, i can't see why my design would not work okay.

rbugalho is correct about worrying about the metastability. You do not want this flop to go metastable.

To ensure this, since you don't have an enable on the Latch_FF, you need to make sure that your Hold multicycle is the more stringent 0 (which is the default), not 1.

set_mjulticycle_path -hold -end -from {Launch_FF} -to {Latch_FF} 0 # Default

Basically, your min time from Launch_FF must be at least one full clock cycle to make this hold time. This may be difficult to achieve.

--- Quote Start ---

Kaz,

multicycle exceptions are not restricted to clock enables.

Consider this example.

Let's say we a have a state machine that in one clock is in stateA, next clock in stateB and next clock in stateC.

always @ (posedge clk) begin
if (state == stateA) regA <= someValueA;
if (state == stateB) regB <= someValueB;
if (state == stateC) regC <= regA - 10 + regB;
end

The synthesis tool may use clock enables to implement this behavior. Or it may simply implement them by feeding back the registers' output via a mux.

But in both cases, we can set a multicycle exception of 2 for the path between regA and regC.

What the multicycle exception tells TQ is that the transitions from regA and regC have 2 clocks to propagate.

The transitions from regB to regC, however, still only have 1 clock to propagate.

--- Quote End ---

True and I said that multicycle applies in two cases only:

1) latch register is not allowed to clock in (clk enable)

2) launch data is not allowed to change every clock (latch register need not have enable), or both naturally. So yes your register A above is controlled not to change its data onto register C until state goes from A => B => C

--- Quote Start ---

The time a FF takes to resolve from meta-stability is not constant. Even for a modern device, there's a tiny but non-zero probability that it's long.

--- Quote End ---

But how long is 'long'? <= Tco accordingly to the Altera documentation. Where can i find Tco for internal FF's? Also, when the T2 clock edge comes along, Latch_FF.D will capture the input signal (which has been stable for at least 8 ns in my design) and output the new Latch_FF.Q signal. Surely, a metastable condition in Latch_FF at T1 will not prevent Latch_FF to correctly clock in a correct signal (with met Tsu) at T2?

--- Quote Start ---

But anyway, the problem is that you're saying one thing and writing code for another.

set_multicycle_path -setup -end -from [Launch_FF] -to [Latch_FF] 2

set_multicycle_path -hold -end -from [Launch_FF] -to [Latch_FF] 1

^^ This should be used when the output of Launch_FF is not used by Latch_FF until 2 clocks later.

On the other hand, you keep writing about the output of Latch_FF not being used for until 2 clocks later...

You need to be sure about what you're constraining.

--- Quote End ---

I'm quite clear (at least in my mind): The multi-cycle path simply tells TimeQuest that Tsu for Latch_FF is not met at T1 but at T2 it is. The output of Latch_FF is irrelevant at all times except at T2. Therefore, the source signal is launched by Launch_FF.Q at T0, captured by Latch_FF.D at T1 (Latch_FF.Q possible metastable but this is don't-care since Latch_FF.Q is only used at T2) and finally captured by Latch_FF.D at T2.

Downstream logic will ignore the output from Latch_FF.Q until t == T2.

The time a FF takes to resolve from meta-stability is not constant. Even for a modern device, there's a tiny but non-zero probability that it's long.

But anyway, the problem is that you're saying one thing and writing code for another.

set_multicycle_path -setup -end -from [Launch_FF] -to [Latch_FF] 2

set_multicycle_path -hold -end -from [Launch_FF] -to [Latch_FF] 1

^^ This should be used when the output of Launch_FF is not used by Latch_FF until 2 clocks later.

On the other hand, you keep writing about the output of Latch_FF not being used for until 2 clocks later...

You need to be sure about what you're constraining.

--- Quote Start ---

Thus, in this context, you cannot afford to have Latch_FF go metastable even for one clock.

--- Quote End ---

In my case it should work fine because Latch_FF.Q is guaranteed not to be used until T2. If Latch_FF goes metastable at T1 then it must mean that D will be stable for some 8ns before T2. In other words, Tsu is about 8ns with a multi-cycle path setting of 2.

--- Quote Start ---

Also, metastability is not ensured to last just one clock...

--- Quote End ---

The following documents say that a metastable condition will resolve itself in roughly tco of the FF.

http://www.altera.com/literature/wp/wp-01082-quartus-ii-metastability.pdf

ftp://ftp.altera.com/pub/lit_req/document/an/an042.pdf

I have not been able to find tco or internal flip-flops but logic says that it must be much, much less than 8ns.

--- Quote Start ---

The little mistake you had is that, in this type of application, if the -setup multiplier is N, then -hold muliplier is N-1. 2 and 1 in your case.

--- Quote End ---

Thanks. I will update my SDC.

Kaz,

multicycle exceptions are not restricted to clock enables.

Consider this example.

Let's say we a have a state machine that in one clock is in stateA, next clock in stateB and next clock in stateC.

always @ (posedge clk) begin
if (state == stateA) regA <= someValueA;
if (state == stateB) regB <= someValueB;
if (state == stateC) regC <= regA - 10 + regB;
end

The synthesis tool may use clock enables to implement this behavior. Or it may simply implement them by feeding back the registers' output via a mux.

But in both cases, we can set a multicycle exception of 2 for the path between regA and regC.

What the multicycle exception tells TQ is that the transitions from regA and regC have 2 clocks to propagate.

The transitions from regB to regC, however, still only have 1 clock to propagate.

I'm afraid your reasoning is incorrect.

What you're discussing is the path between Launch_FF and Latch_FF.

Not the path between Latch_FF and whatever comes next.

Thus, in this context, you cannot afford to have Latch_FF go metastable even for one clock.

Also, metastability is not ensured to last just one clock...

That said, although your reasoning is incorrect, your usage looks mostly correct.

IF the logic guarantees that transitions in Launch_FF's output happen 2 clocks before being captured by Latch_FF, then you can use a multicycle factor of 2.

The little mistake you had is that, in this type of application, if the -setup multiplier is N, then -hold muliplier is N-1. 2 and 1 in your case.

--- Quote Start ---

If the latch register cares about data every other clock but data may change every clock then you cannot apply multicycle because the register will be affected by violations.

--- Quote End ---

I see your point, but:

I understand that if Tsu/Th is not met at Latch_FF's D input at T1 (T1 = Tlaunch + 1) then it may go into a meta-stable state at T1. However, since the output of Latch_FF is ignored until T2 and since D is stable well before T2, I would assume that the latch FF would have recovered from a potentially meta-stable condition (at T1) long before T2 (where it needs to clock in the data correctly).

My clock is 125 MHz so there are 8ns from T1 to T2.

Is my reasoning incorrect?