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.
So it would be dangerous to do multicycle a functional paths right?
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.
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.
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.
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.
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.
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?
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.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?