Guest
On Jan 11, 4:29 pm, Dave Pollum <vze24...@verizon.net> wrote:
a clock-accurate reset with well-defined behaviour in the immediate
next cycle (say a reset of a functional unit before the next work item
is to be precessed) then you should go fully synchronous, both with
the reset generator and with the logic that uses the reset.
If, on the other hand, the reset has to just get your logic into some
known state after a brownout or PLL unlock or power-up, then you can
often get away with sloppier async resets. However, this is easier
said than done. There are two common mistakes that people make when
doing this.
Mistake 1 is to forget that when the reset drives clocked logic, that
you have to guarantee that the reset *de-asserts* synchronously to
clock edge to prevent different flops from seeing the reset complete
on different clock edges due to skew, etc. This is what Dave Pollum's
solution helps you achieve. Having an async reset is often an
invitation for race conditions coming out of reset; many people will
ignore FPGA PAR timing errors around the reset line. thinking "it's
OK, it's supposed to be asynchronous" :-(
Mistake 2 is to assume that clocks are stable during reset; in
brownout or PLL unlock conditions, this may not always be true. This
would prevent the simple synchronizer from working properly, you might
actually delay your reset assertion unwantedly until clocks recover.
For example, some PLL gating logic may hold the clock solid low until
the PLL is locked.
A more robust solution is to use an multi-flop synchronizer chain
where all flops get asynchronously reset by the global reset (ensuring
immediate response), then starts clocking through a "valid" (reset
done, clock valid, or conjunction of both). The "valid" (ie reset de-
assert) will come out 2 or 3 clocks after the initial condition
clears. This will ensure that when the reset condition eventually
clears, then your output reset line gets de-asserted on a known good
clock edge (required to avoid race conditions), and that some small
number of known good clocks have elapsed before reset de-asserts
(required when the reset is used to do a synchronous reset of block
that are not implemented with async resets).
There are, as always, many more options. But these two mistakes are
aspects that I've seen hurt designs in the past; you should consider
these when you think about modifying your reset tree.
Cheers,
- Kenn
It also depends what you need the reset to do. If the reset has to be
a clock-accurate reset with well-defined behaviour in the immediate
next cycle (say a reset of a functional unit before the next work item
is to be precessed) then you should go fully synchronous, both with
the reset generator and with the logic that uses the reset.
If, on the other hand, the reset has to just get your logic into some
known state after a brownout or PLL unlock or power-up, then you can
often get away with sloppier async resets. However, this is easier
said than done. There are two common mistakes that people make when
doing this.
Mistake 1 is to forget that when the reset drives clocked logic, that
you have to guarantee that the reset *de-asserts* synchronously to
clock edge to prevent different flops from seeing the reset complete
on different clock edges due to skew, etc. This is what Dave Pollum's
solution helps you achieve. Having an async reset is often an
invitation for race conditions coming out of reset; many people will
ignore FPGA PAR timing errors around the reset line. thinking "it's
OK, it's supposed to be asynchronous" :-(
Mistake 2 is to assume that clocks are stable during reset; in
brownout or PLL unlock conditions, this may not always be true. This
would prevent the simple synchronizer from working properly, you might
actually delay your reset assertion unwantedly until clocks recover.
For example, some PLL gating logic may hold the clock solid low until
the PLL is locked.
A more robust solution is to use an multi-flop synchronizer chain
where all flops get asynchronously reset by the global reset (ensuring
immediate response), then starts clocking through a "valid" (reset
done, clock valid, or conjunction of both). The "valid" (ie reset de-
assert) will come out 2 or 3 clocks after the initial condition
clears. This will ensure that when the reset condition eventually
clears, then your output reset line gets de-asserted on a known good
clock edge (required to avoid race conditions), and that some small
number of known good clocks have elapsed before reset de-asserts
(required when the reset is used to do a synchronous reset of block
that are not implemented with async resets).
There are, as always, many more options. But these two mistakes are
aspects that I've seen hurt designs in the past; you should consider
these when you think about modifying your reset tree.
Cheers,
- Kenn