fpga internal metastability
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].