Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

Multicycle path and metastability

Status
Not open for further replies.
S

stanford

Full Member level 2
Joined
Feb 16, 2014
Messages
132
Helped
4
Reputation
8
Reaction score
6
Trophy points
1,298
Activity points
2,223
When we put a multicycle constraint of 2 for setup (or 1 for hold), we could still have metastability right? Say the data arrived near the receiving clk edge and the output of the flop becomes metastable, some receiving end could receive 0, another could receive 1.

How can we prevent this? This seems rather dangerous.
 
Last edited:
Re: multicycle path and metastability

stanford said:
When we put a multicycle constraint of 2 for setup (or 1 for hold), we could still have metastability right? Say the data arrived near the receiving clk edge and the output of the flop becomes metastable, some receiving end could receive 0, another could receive 1.

How can we prevent this? This seems rather dangerous.
Click to expand...

If you violate setup, even if it is a multicycle of 10, your flop will not behave reliably.
 

Re: multicycle path and metastability

So it would be dangerous to do multicycle a functional paths right?
 

Re: multicycle path and metastability

Hi,

it´s the (wrong) timing that makes it dangerous, not the multicycle.

Klaus
 

Re: multicycle path and metastability

@OP, are you trying to make a synchronizer with a multicycle path?

Multicycle paths have issues, but I'm not sure which issue I'm responding to.
 

Re: multicycle path and metastability

In the first order, multicycle and metastability are unrelated topics.

If a data transfer has been correctly identified as multicycle and respectively constrained, there can't be setup and hold violations and hence no metastability.

Getting metastability though proves that the multicycle constraint is inappropriate, either you are transferring between asynchronous clock domains, or data is launched or latched in the wrong clock cycle.
 

stanford said:
When we put a multicycle constraint of 2 for setup (or 1 for hold), we could still have metastability right? Say the data arrived near the receiving clk edge and the output of the flop becomes metastable, some receiving end could receive 0, another could receive 1.

How can we prevent this? This seems rather dangerous.
Click to expand...


The only issue with a 2 cycle path is what happens on the first clock. It's input will still be in transition so it could go metastable on the first clock before going to the correct value on the second. Since it is probably feeding another 2 cycle input cone then that flop will be totally wrecked.

To fix this we use a clock enable on every flop so that it only changes on the second clock.


John Eaton.
 

stanford said:
When we put a multicycle constraint of 2 for setup (or 1 for hold), we could still have metastability right? Say the data arrived near the receiving clk edge and the output of the flop becomes metastable, some receiving end could receive 0, another could receive 1.

How can we prevent this? This seems rather dangerous.
Click to expand...

Normally, each relevant register will have a clock-enable. If the receiving register does not have a clock enable, then the setup might not be met and there might be metastability. With a clock enable, the register is not enabled on cycles where metastability would be possible.
 

multicycle path and metastability

When we declare a path as multicycle of 2, we effectively time the max time with 2*period.

_______|--------------|__________|--------------|___________|--------------|___________
(launching edge) (1 st edge) (2nd edge)

But what happens if the data is changing near the 1st edge? The tool will say this path is ok because we multicycled it, but we could have metastability issue. What can we do and do we do anything to prevent this?
 

Looks like previously mentioned inappropriate multicycle constraint, the diagram isn't particularly clear.
 

The multicycle path constraint is used between synchronous clocks (same clock or divided clock).
If clocks are asynchronous then no need to define the multicycle path. But you can still define the max delay for that path.

Here, the setup violation means that tool is not able to meet the timing within N (constrained through multicycle path) clock cycles. So to fix the setup violation, either make it >N if feasible, or break the logic (pipeline) or re-architecture.
 
Last edited:

Multicycle constraint is not targeted to solve the metastability. It is used to make the coressponse between timing calculation EDA and Logic functionality.
Once you asure the STA check items ( hold, setup, slew ... ), you are safe.
 

Ashish Agrawal said:
The multicycle path constraint is used between synchronous clocks (same clock or divided clock).
If clocks are asynchronous then no need to define the multicycle path. But you can still define the max delay for that path.

Here, the setup violation means that tool is not able to meet the timing within N (constrained through multicycle path) clock cycles. So to fix the setup violation, either make it >N if feasible, or break the logic (pipeline) or re-architecture.
Click to expand...

This is not what I was asking.

I was asking if we make the path multicycle path of N, how do we prevent metastable issue that could happen within the N clk toggles?
In other words, we can make the tool happy by making it a multicycle path, but if we fail timing with single cycle path, we could have metastability issue if input is flopped when input is changing near the 1st clk toggle.
 
Last edited:

stanford said:
This is not what I was asking.

I was asking if we make the path multicycle path of N, how do we prevent metastable issue that could happen within the N clk toggles?
In other words, we can make the tool happy by making it a multicycle path, but if we fail timing with single cycle path, we could have metastability issue if input is flopped when input is changing after 1 clk cycle.
Click to expand...

See answer #9. But also remember that it shouldn't matter because the downstream logic shouldn't be reading a result that is 'not ready' yet. With some control logic around the multicycle path you can safely ignore any metastable state in the intermediate clock cycles that do not matter.
 

ThisIsNotSam said:
See answer #9. But also remember that it shouldn't matter because the downstream logic shouldn't be reading a result that is 'not ready' yet. With some control logic around the multicycle path you can safely ignore any metastable state in the intermediate clock cycles that do not matter.
Click to expand...

How can we guarantee this? This means we have to look at all the fanout of this output to make sure the logic will not look at this output until after N clk cycle. I bet most people in the industry are not doing the due diligence.

What if this was a control signal like a enable signal? We can't multicycle signals like this then?
 

stanford said:
How can we guarantee this? This means we have to look at all the fanout of this output to make sure the logic will not look at this output until after N clk cycle. I bet most people in the industry are not doing the due diligence.

What if this was a control signal like a enable signal? We can't multicycle signals like this then?
Click to expand...

Very easy to guarantee with enable-like signals.

Also remember that control signals typically do not require muticycle paths as they are somewhat trivial for timing purposes. It is the datapath logic that is deep and may require N-many cycles. Think of multipliers, not small FSMs.
 

ThisIsNotSam said:
Very easy to guarantee with enable-like signals.

Also remember that control signals typically do not require muticycle paths as they are somewhat trivial for timing purposes. It is the datapath logic that is deep and may require N-many cycles. Think of multipliers, not small FSMs.
Click to expand...

Thanks, I have seen people multicycle path purely on the basis of it not needing to be a single cycle path and not considering how it is consumed. e.g. like a done signal. It doesn't have to be single cycle path, but this signal can become metastable with multicycle path and affect the downstream logic that is triggering off of the done signal.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top