State A => State B multicycle path?

A multicycle applies when a register is clocked not at every edge but every other edge or so. In your case I assume by timer you mean clock_enable. If so you can apply multicycle to all registers activated by clock_enable.

Edit: Similarly a multicycle applies if data is known to change every other clock or so. However just having data delay is not a case for multicycle approach.

In my case, the target register is *using* the signal after two cycles. Therefore, the signal is being clocked on every tick but I only care about the signal state every other state (when my timer expires). In essence, it is not a clock enable but rather a delayed FSM transition.

I suppose the SDC 'set_multicycle_path' must be specified on each and every signal part of the multicycle path like above. I essentially wondered whether it would be possible to state something like:

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

Theorethically, then, the timing analyzer would know which signals are launched by Launch_FF and clocked in by Latch_FF and therefore know that all signals launched by Launch_FF would have 2T to reach the Latch_FF. But perhaps, it simply is not possible and I will have to specify each signal separately? I'm currently doing this (spec'd separately) and it is working fine.

Thanks.

--- Quote Start ---

In my case, the target register is *using* the signal after two cycles. Therefore, the signal is being clocked on every tick but I only care about the signal state every other state (when my timer expires). In essence, it is a form of clock enable but in the form of a delayed FSM transition.

--- Quote End ---

As I mentioned, the multicycle applies only in two cases: the register is not allowed to clock in at every edge through enable or the it is allowed but the D data is not allowed to transition at after every clock edge.

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.

So you are in best position to see which of your registers can be multicycled. If state registers transition every other clock then you can apply multicycle to state registers (rather than signals in between)

--- 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?

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.

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

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 ---

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.