State A => State B multicycle path?

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

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

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.

--- Quote Start ---

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.

--- Quote End ---

This doesn't look good..

This is what it looks like to me:

T0: Launch_FF latches a new value

T1: Latch_FF latches a bad value, as the previous transition from Launch_FF hasn't completely propagated yet

T2: Latch_FF latches a good value as the previous transition finally had time to propagate; downstream_FF latches a bad value, from the bad value Launch_FF had before.

T3: Downstream_FF finally latches a good value.

Or making it short.

An exception like "set_multycycle_path -from [launch_FF] -to [latch_FF]" concerns the path between launch_FF.Q and latch_FF.D.

If you're making considerations for stuff downstream of latch_FF or upstream launch_FF, and coming to an exception that like, then you're getting it wrong.

If a FF hasn't resolved to a stable state by the next clock edge, it's normal timing characteristics (tSU, tH, tCO) may not apply.

Hence, it's not 100% sure that it will behave normally.

--- Quote Start ---

If a FF hasn't resolved to a stable state by the next clock edge, it's normal timing characteristics (tSU, tH, tCO) may not apply.

Hence, it's not 100% sure that it will behave normally.

--- Quote End ---

Once again, I agree. The metastability may settle out on the next clock edge, but in the mean time, it may cause other registers down stream to go metastable. In addition to that, it also creates noise in a circuit which can cause crosstalk to other nearby traces. As I said before, set your multicycle hold to 0, then if you meet timing it won't go metastable. If you can't meet the hold time, then add a clock enable.

--- Quote Start ---

This is what it looks like to me:

T0: Launch_FF latches a new value

T1: Latch_FF latches a bad value, as the previous transition from Launch_FF hasn't completely propagated yet

T2: Latch_FF latches a good value as the previous transition finally had time to propagate; downstream_ff latches a bad value, from the bad value launch_ff had before.T3: Downstream_FF finally latches a good value.

--- Quote End ---

My point is that the statement in bold doesn't apply. The reason is that downstream combinational logic will block the metastable signal from reaching the next register. Only at T2 will the combination logic let the Latch_FF.Q signal through to the next register. At T2 the Latch_FF.Q will not be metastable.

--- Quote Start ---

If a FF hasn't resolved to a stable state by the next clock edge, it's normal timing characteristics (tSU, tH, tCO) may not apply.

Hence, it's not 100% sure that it will behave normally.

--- Quote End ---

Where can i find documentation to back up this statement?

--- Quote Start ---

Once again, I agree. The metastability may settle out on the next clock edge, but in the mean time, it may cause other registers down stream to go metastable.

--- Quote End ---

As explained, this cannot happen in my design since combinational logic will block the metastable signal from reaching the target register at T1.

--- Quote Start ---

In addition to that, it also creates noise in a circuit which can cause crosstalk to other nearby traces.

--- Quote End ---

Crosstalk inside the FPGA? This is a new concept I have not come across before. If FPGAs were susceptible to crosstalk internally, how can signals belonging to different clock domains be mixed inside the FPGA. This would surely cause internal signal paths belonging to one clock domain to switch randomly with regards to other signals belonging to other clock domains, causing havoc?