Electronic – Moving brute-force search to FPGA

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].

Since you didn't identify any specific difficulties, here's a quick run-through. If there are points you still don't understand, ask followup questions in the comments below.

flipflops is used to create an edge detector; counter_set pulses high every time there's an input transition. (Note that this is poor design — since button is an asynchronous input, there should be at least one more flipflop to reduce the chance of metastability.)

Every time counter_set pulses high, counter_out is cleared; otherwise it counts up until the MSB gets set, at which time result is set to the same state as button.

As a demo, the code increments counter_10 on every debounced transition (both low-to-high and high-to-low), which then gets decoded for a 7-segment display. In place of this, you could toggle your LED. If you want the LED to only toggle on one edge and not the other, make it conditional on result.