Is there a way to tell TimeQuest that all signals launched by State A and captured by State B are part of a multi-cycle path? My combinational path delay is too large so i'm adding a timer to delay my FSM state transition by one extra cycle. Previously, I have been using the SDC per below but I wonder if there is a way to tell TimeQuest that any signals travelling between the launch and latch FF's are multicycle? set_multicycle_path -setup -end -from [get_keepers {main_controller:main_controller_inst|reg_rx_regs_offset[*]}] -to [get_keepers {tx_tlp_buffer:tx_tlp_buffer_inst|mem[*][*]}] 2 set_multicycle_path -hold -end -from [get_keepers {main_controller:main_controller_inst|reg_rx_regs_offset[*]}] -to [get_keepers {tx_tlp_buffer:tx_tlp_buffer_inst|mem[*][*]}] 2 Thanks

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)

Yes, you can multicycle from register to register as you have proposed and it will behave the way you expect.

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

State A => State B multicycle path? | Altera Community

23 Replies

Altera_Forum
Honored Contributor
14 years ago
--- Quote Start ---
But if the output of Latch_FF isn't considered to be 'valid' until T2 then
the Downstream_FF won't be 'using' this value until T3 at which point it
will be a solid '1' or '0'.

--- Quote End ---

It is very unsafe design to violate register timing and then wait until it recovers. A register may not end up in the right state if it is violated.
This practice is unavoidable across clk domain transfers (but two synchroniser stages are needed in this case)
Altera_Forum
Honored Contributor
14 years ago
--- Quote Start ---

So, after T2 clock edge, Latch_FF will (most likely) have a correct value.
But what Downstream_FF will be latching at the T2 clock edge is based on what Latch_FF had prior to the clock edge -- a bad value.
--- Quote End ---

But if the output of Latch_FF isn't considered to be 'valid' until T2 then
the Downstream_FF won't be 'using' this value until T3 at which point it
will be a solid '1' or '0'.

?

I think I'd rather find a work around to this but think that what the OP says is true (with the caveat about registering the correct output at T2).

Nial.
Altera_Forum
Honored Contributor
14 years ago
--- Quote Start ---
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 End ---

I think you got confused on something basic.
This may be simpler to understand if, instead we assume Latch_FF will go metastable at T1, we simply assume the delay is so long that it totally overshoots the tSU/tH window at T1 and Latch_FF simply latches the old value.

At the T2 clock edge, two things happen at the same time:
- Latch_FF latches the value at it's input prior to the clock edge
- Downstream_FF latches the value at it's input prior to the clock edge.

So, after T2 clock edge, Latch_FF will (most likely) have a correct value.
But what Downstream_FF will be latching at the T2 clock edge is based on what Latch_FF had prior to the clock edge -- a bad value.
Altera_Forum
Honored Contributor
14 years ago
--- 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?
Altera_Forum
Honored Contributor
14 years ago
--- 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?
Altera_Forum
Honored Contributor
14 years ago
--- 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.
Altera_Forum
Honored Contributor
14 years ago
I think we'll both agree that trying to rely on behavior that involves metastability is dialing Murphy's number.
Altera_Forum
Honored Contributor
14 years ago
--- 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.
Altera_Forum
Honored Contributor
14 years ago
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.
Altera_Forum
Honored Contributor
14 years ago
--- 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.

Forum Discussion

State A => State B multicycle path?

23 Replies

Recent Discussions

Subject: [Arria 10 SoC] QSPI Flash Macronix Compatibility (MX66U2G45GXRI00)

CycloneIV PCIe HIP: fixedclk_serdes generation

A5E(B) EMIF : LPDDR4 minimum memory clock

Check COD for ICs

CXL Type 2 DMA/Mem Access Triggers CPU MCE on Sapphire Rapids