I have an issue which I think maybe related to internal timing issues.

I know that crossing clock domains can cause metastability, because setup and hold timing not being kept.

But I was thinking that this could also be an issue with the internal signals (within same clock domain).

If ex. an signal to an FF is passed through some logic, and thereby delay an amount that will cause the sampling FF to sample on transition.

Or will the tool given the timing constraints always warn / catch this?

  • 1
    \$\begingroup\$ If, as you say below, you are getting warnings of negative slack for your timing constraints then your design is likely to fail. It may be metastability or logic errors without metastability, but what difference does it make? \$\endgroup\$
    – Joe Hass
    Feb 7, 2014 at 19:22
  • \$\begingroup\$ Good point, I was changing some component, and some other component started failing, which I normally have seen during metastability. \$\endgroup\$
    – JakobJ
    Feb 7, 2014 at 19:44

2 Answers 2


The output of a register whose input does not change within a specified margin of the clock will switch within a specified period of time of the clock. The output of a register whose input changes too close to a clock may change at some arbitrary time in future which might, though is generally not likely to, be near the next clock.

If a register's input is derived from signals that are all clocked by the same signal as the register itself, and if the maximum propagation time is sufficiently shorter than the time between clocks, then provided the earlier registers switch as specified, the derived input will not change within the forbidden window. If the maximum propagation time is longer than the time between clocks, however, a bad situation will arise. When latching truly asynchronous events, it's possible that events may occasionally put a latch into a metastable state, but feeding the output from that latch into a second latch will usually clear things up. If the first latch goes into a metastable state about once a minute, and one in ten million metastability events on the first latch will cause the second latch to go metastable, problems on the second latch will only occur about once every twenty years. If rather than being asynchronous, however, the signals arriving at a latch switch at times which combinatorial logic delays by a time close to a clock period, it's possible that rather the first latch going metastable once a minute, it may go metastable millions of times per second. Adding a second latch may improve things, but even a with 10,000,000:1 improvement the downstream latch would still go metastable many times per minute.

If your propagation time is too long relative to your clock period, you need to either add registers to ensure that the propagated result will be consistently seen some number of clock periods after the earlier-stage latches change, or else add logic to ensure that nothing will do anything with the output from a register which may have gone metastable. The former approach would be better if one wishes to handle one data item per clock cycle but can accept the pipeline delay. The latter approach may be better if there's lots of parallel data and it won't be necessary to have multiple calculations in the pipe simultaneously [the amount of logic required would be independent of the number of data paths]. The latter approach may be especially advantageous if the required number of delay cycles may be variable [e.g. if a circuit may operate at 100MHz, 50Mhz, or 32MHz and the logic's propagation time is 25ns, one may use a two-cycle delay at 100Mhz, a one cycle at 50MHz, and no delay at 32Mhz or below].


The FPGA tools know what the routing delays of the device are and compensate for this automatically. The only signals the tools don't know about are the signals entering the chip, or the required relationship of signals exiting the chip to external devices. That's exactly what timing constraints descriptions are for.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.