标签: asynchronous

3 Asynchronous reset problem In discussing this paper topic with a colleague, the engineer stated first that since all he was working on was FPGAs, they do not have the same reset problems that ASICs have (a misconception). He went on to say that he always had an asynchronous system reset that could override everything, to put the chip into a known state. The engineer was then asked what would happen to the FPGA or ASIC if the release of the reset occurred on or near a clock edge such that the flip-flops went metastable. Too many engineers just apply an asynchronous reset thinking that there are no problems. They test the reset in the controlled simulation environment and everything works fine, but then in the system, the design fails intermittently. The designers do not consider the idea that the release of the reset in the system (non-controlled environment) could cause the chip to go into a metastable unknown state, thus avoiding the reset all together. Attention must be paid to the release of the reset so as to prevent the chip from going into a metastable unknown state when reset is released. When a synchronous reset is being used, then both the leading and trailing edges of the reset must be away from the active edge of the clock. As shown in Figure 5, an asynchronous reset signal will be de-asserted asynchronous to the clock signal. There are two potential problems with this scenario: (1) violation of reset recovery time and, (2) reset removal happening in different clock cycles for different sequential elements.   Figure 5 - Asynchronous reset removal recovery time problem 3.1 Reset recovery time Reset recovery time refers to the time between when reset is de-asserted and the time that the clock signal goes high again. The Verilog-2001 Standard has three built-in commands to model and test recovery time and signal removal timing checks: $recovery, $removal and $recrem (the latter is a combination of recovery and removal timing checks). Recovery time is also referred to as a tsu setup time of the form, “ PRE or CLR inactive setup time before CLK ↑” . Missing a recovery time can cause signal integrity or meta-stability problems with the registered data outputs. 3.2 Reset removal traversing different clock cycles When reset removal is asynchronous to the rising clock edge, slight differences in propagation delays in either or both the reset signal and the clock signal can cause some registers or flip-flops to exit the reset state before others. 4.0 Reset synchronizer Guideline: EVERY ASIC USING AN ASYNCHRONOUS RESET SHOULD INCLUDE A RESET SYNCHRONIZER CIRCUIT!! Without a reset synchronizer, the usefulness of the asynchronous reset in the final system is void even if the reset works during simulation. The reset synchronizer logic of Figure 6 is designed to take advantage of the best of both asynchronous and synchronous reset styles.   Figure 6 - Reset Synchronizer block diagram An external reset signal asynchronously resets a pair of master reset flip-flops, which in turn drive the master reset signal asynchronously through the reset buffer tree to the rest of the flip-flops in the design. The entire design will be asynchronously reset. Reset removal is accomplished by de-asserting the reset signal, which then permits the d-input of the first master reset flip-flop (which is tied high) to be clocked through a reset synchronizer. It typically takes two rising clock edges after reset removal to synchronize removal of the master reset. Two flip-flops are required to synchronize the reset signal to the clock pulse where the second flip-flop is used to remove any meta-stability that might be caused by the reset signal being removed asynchronously and too close to the rising clock edge. As discussed in section before, these synchronization flip-flops must be kept off of the scan chain. Figure 7 - Predictable reset removal to satisfy reset recovery time   A closer examination of the timing now shows that reset distribution timing is the sum of the a clk-to-q propagation delay, total delay through the reset distribution tree and meeting the reset recovery time of the destination registers and flip-flops, as shown in Figure 7. The code for the reset synchronizer circuit is shown in Example 8. module async_resetFFstyle2 (rst_n, clk, asyncrst_n);   output rst_n;   input   clk, asyncrst_n;   reg     rst_n, rff1;   always @(posedge clk or negedge asyncrst_n)     if (!asyncrst_n) {rst_n,rff1} = 2'b0;     else              {rst_n,rff1} = {rff1,1'b1}; endmodule Example 8a - Properly coded reset synchronizer using Verilog 5 Multi-clock reset issues For a multi-clock design, a separate asynchronous reset synchronizer circuit and reset distribution tree should be used for each clock domain. This is done to insure that reset signals can indeed be guaranteed to meet the reset recovery time for each register in each clock domain. As discussed earlier, asynchronous reset assertion is not a problem. The problem is graceful removal of reset and synchronized startup of all logic after reset is removed. Depending on the constraints of the design, there are two techniques that could be employed: (1) non-coordinated reset removal, and (2) sequenced coordination of reset removal.   Figure 12 - Multi-clock reset removal 5.1 Non-coordinated reset removal For many multi-clock designs, exactly when reset is removed within one clock domain compared to when it is removed in another clock domain is not important. Typically in these designs, any control signals crossing clock boundaries are passed through some type of request-acknowledge handshaking sequence and the delayed acknowledge from one clock domain to another is not going to cause invalid execution of the hardware. For this type of design, creating separate asynchronous reset synchronizers as shown in Figure 12 is sufficient, and the fact that arst_n, brst_n and crst_n could be removed in any sequence is not important to the design. 5.2 Sequenced coordination of reset removal For some multi-clock designs, reset removal must be ordered and proper sequence. For this type of design, creating prioritized asynchronous reset synchronizers as shown in Figure 13 might be required to insure that all aclk domain logic is activated after reset is removed before the bclk logic, which must also be activated before the cclk logic becomes active. Figure 13 - Multi-clock ordered reset removal For this type of design, only the highest priority asynchronous reset synchronizer input is tied high. The other asynchronous reset synchronizer inputs are tied to the master resets from higher priority clock domains. This article abstracted from CummingsSNUG2002SJ_Resets , the original author is Clifford E. Cummings and Don Mills.