Visible to Intel only — GUID: mwh1409959563610
Ixiasoft
Visible to Intel only — GUID: mwh1409959563610
Ixiasoft
2.3.1.2. Using Asynchronous Resets
This method is only advantageous under certain circumstances—you do not need to always reset the register. Unlike the synchronous reset, the asynchronous reset is not inserted in the datapath, and does not negatively impact the data arrival times between registers. Reset takes effect immediately, and as soon as the registers receive the reset pulse, the registers are reset. The asynchronous reset is not dependent on the clock.
However, when the reset is deasserted and does not pass the recovery (µtSU) or removal (µtH) time check (the Timing Analyzer recovery and removal analysis checks both times), the edge is said to have fallen into the metastability zone. Additional time is required to determine the correct state, and the delay can cause the setup time to fail to register downstream, leading to system failure. To avoid this, add a few follower registers after the register with the asynchronous reset and use the output of these registers in the design. Use the follower registers to synchronize the data to the clock to remove the metastability issues. You should place these registers close to each other in the device to keep the routing delays to a minimum, which decreases data arrival times and increases MTBF. Ensure that these follower registers themselves are not reset, but are initialized over a period of several clock cycles by “flushing out” their current or initial state.
Verilog HDL Code of Asynchronous Reset with Follower Registers
module async_reset (
input clock,
input reset_n,
input data_a,
output out_a,
);
reg reg1, reg2, reg3;
assign out_a = reg3;
always @ (posedge clock, negedge reset_n)
begin
if (!reset_n)
reg1 <= 1’b0;
else
reg1 <= data_a;
end
always @ (posedge clock)
begin
reg2 <= reg1;
reg3 <= reg2;
end
endmodule // async_reset
You can easily constrain an asynchronous reset. By definition, asynchronous resets have a non-deterministic relationship to the clock domains of the registers they are resetting. Therefore, static timing analysis of these resets is not possible and you can use the set_false_path command to exclude the path from timing analysis. Because the relationship of the reset to the clock at the register is not known, you cannot run recovery and removal analysis in the Timing Analyzer for this path. Attempting to do so even without the false path statement results in no paths reported for recovery and removal.
SDC Constraints for Asynchronous Reset
# Input clock - 100 MHz
create_clock [get_ports {clock}] \
-name {clock} \
-period 10.0 \
-waveform {0.0 5.0}
# Input constraints on data
set_input_delay 7.0 \
-max \
-clock [get_clocks {clock}]\
[get_ports {data_a}]
set_input_delay 1.0 \
-min \
-clock [get_clocks {clock}] \
[get_ports {data_a}]
# Cut the asynchronous reset input
set_false_path \
-from [get_ports {reset_n}] \
-to [all_registers]
The asynchronous reset is susceptible to noise, and a noisy asynchronous reset can cause a spurious reset. You must ensure that the asynchronous reset is debounced and filtered. You can easily enter into a reset asynchronously, but releasing a reset asynchronously can lead to potential problems (also referred to as “reset removal”) with metastability, including the hazards of unwanted situations with synchronous circuits involving feedback.