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

Forum Discussion

State A => State B multicycle path?

23 Replies

Recent Discussions

Cyclone-V SCFIFO - adding ECC to M10K/MLAB/Auto memory

Will serialization factor of 6 in LVDS serdes IP be supported in the future on Agilex5?

System PLL of Agliex5 PCIE example design cannot be locked after configuration

JTAG Chain Broken on Agilex 7-I Dev Kit

Request for Cyclone V Pinout File Information