--- 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.
Honored Contributor
