In large SoCs (system-on-a-chip) or relatively slow FPGAs properly distributing the asynchronous reset lines to all the flops is a relatively important and big problem that should be architectured and planned before design even starts.
During my career, I personally inherited some legacy chips or designs in which this problem wasn’t thought through from the beginning, leaving the designers fighting place and route, layout and timing closure issues, costing months in schedule, damaging the morale of the team and damaging the entire company which is trying to tape-out its product. This is a hellish scenario since many of these problems, without proper re-design and planning, are just unsolvable in recent low geometry processes, where the OCV (on-chip-variation) that is factored into the timing calculation becomes more dominant.
In order to understand the problem better, we first need to understand what kind of timing checks, PrimeTime, or any other STA (static timing analysis) tools will make in order to determine whether the asynchronous reset into the flop, is meeting timing.
In a normal flip-flop, the activation or assertion of the reset line will make the flop output go to its reset/default value (most often ‘0). While the reset line is asserted the flop will keep this value on the output and ignore the clock and data-input lines. Once the reset line is deasserted the flop should resume normal behavior in which the data-input line will propagate to the data-output line on the clock-edge (rising edge for positive-edge triggered flip-flops). Herein lies the problem! In essence, when reset is being deasserted, a race between the clock and the reset signal is taking place. This is true for all the flops that are tied to the same reset and the same clock. The designer's intention is that all the flops have the intended default value when coming out of reset (reset deassertion), for at least one clock cycle. If a state machine should be initialized (reset state) to all zeros and one flop in this state machine comes out of reset with the value of ‘1, a serious silicon bug can occur.
This is why timing tools will check recovery and removal for the reset line.
Recovery check: This checks that the reset de-assertion signal arrives and gets stable at least a recovery-time (recovery-time is the Flip-Flop’s recovery time and is defined in the timing library of the flop) before the active clock edge. This check is equivalent to a normal setup check between the data and the clock, only the check here is between the reset and the clock.
the active clock edge. This check is equivalent to a normal check between the data clock, only the check here is between the reset and the clock.set synchronizer circuit usually). The timing check is checking that the reset signal is stable at least removal-time after the active clock edge. This check is equivalent to a normal hold check between data clock, only the check here is between the reset and the clock.
the active clock edge. This check is equivalent to a normal check between the data and the clock, only the check here is between the reset and the clock.
Since the de-assertion of the reset signal is being timed against the clock signal of the flops, it needs to be synchronized to it. There are a few common reset synchronizers designs, below is one example, but their idea is always the same:
Transfer the assertion of the reset asynchronously to all the flops in the reset network.
Synchronize the deassertion reset edge to the common clock so all flops leave the reset state and resume normal functionality at the same time.
One can immediately notice that if the domain that this reset-synchronizer is driving is large (i.e. a lot of flops occupying large area), one would have a problem with getting timing closed for this reset network. This kind of design, unless very localized, will not work well in deep-submicron technologies where the OCV between the reset and the clock would penalize timing for both recovery and removal (setup and hold) checks.
In part 2 I will outline an architecture that solves this problem, and basically completely removes the need to close timing on the reset lines.
Stay tuned!
Comentários