Asynchronous & Synchronous Reset Design Techniques

Asynchronous & Synchronous Reset Design Techniques - Part Deux Clifford E. Cummings Don Mills Steve Golson Sunburst Design, Inc. LCDM Engineering Trilobyte Systems cliffc@sunburst-design.com mills@lcdm-eng.com sgolson@trilobyte.com ABSTRACT This paper will investigate the pros and cons of synchronous and asynchronous resets. It will then look at usage of each type of reset followed by recommendations for proper usage of each type. SNUG Boston 2003 Asynchronous & Synchronous Reset Rev 1.3 Design Techniques - Part Deux 2 1.0 Introduction The topic of reset design is surprisingly complex and poorly emphasized. Engineering schools generally do an inadequate job of detailing the pitfalls of improper reset design. Based on our industry and consulting experience, we have compiled our current understanding of issues related to reset-design and for this paper have added the expertise of our colleague Steve Golson, who has done some very innovative reset design work. We continually solicit and welcome any feedback from colleagues related to this important design issue. We presented our first paper on reset issues and techniques at the March 2002 SNUG conference[4] and have subsequently received numerous email responses and questions related to reset design issues. We obviously did not adequately explain all of the issues related to the asynchronous reset synchronizer circuit because many of the emails we have received have asked if there are metastability problems related to the described circuit. The answer to this question is, no, there are no metastability issues related to this circuit and the technical analysis and explanation are now detailed in section 7.1 of this paper. Whether to use synchronous or asynchronous resets in a design has almost become a religious issue with strong proponents claiming that their reset design technique is the only way to properly approach the subject. In our first paper, Don and Cliff favored and recommended the use of asynchronous resets in designs and outlined our reasons for choosing this technique. With the help of our colleague, Steve Golson, we have done additional analysis on the subject and are now more neutral on the proper choice of reset implementation. Clearly, there are distinct advantages and disadvantages to using either synchronous or asynchronous resets, and either method can be effectively used in actual designs. When choosing a reset style, it is very important to consider the issues related to the chosen style in order to make an informed design decision. This paper presents updated techniques and considerations related to both synchronous and asynchronous reset design. This version of the paper includes updated Verilog-2001 ANSI-style ports in all of the Verilog examples. The first version of this paper included an interesting technique for synchronizing the resetting of multiple ASICs of a high speed design application. That material has been deleted from this paper and readers are encouraged to read the first version of the paper if this subject is of interest. SNUG Boston 2003 Asynchronous & Synchronous Reset Rev 1.3 Design Techniques - Part Deux 3 2.0 Resets Purpose Why be concerned with these annoying little resets anyway? Why devote a whole paper to such a trivial subject? Anyone who has used a PC with a certain OS loaded knows that the hardware reset comes in quite handy. It will put the computer back to a known working state (at least temporarily) by applying a system reset to each of the chips in the system that have or require a reset. For individual ASICs, the primary purpose of a reset is to force the ASIC design (either behavioral, RTL, or structural) into a known state for simulation. Once the ASIC is built, the need for the ASIC to have reset applied is determined by the system, the application of the ASIC, and the design of the ASIC. For instance, many data path communication ASICs are designed to synchronize to an input data stream, process the data, and then output it. If sync is ever lost, the ASIC goes through a routine to re-acquire sync. If this type of ASIC is designed correctly, such that all unused states point to the “start acquiring sync” state, it can function properly in a system without ever being reset. A system reset would be required on power up for such an ASIC if the state machines in the ASIC took advantage of “don’t care” logic reduction during the synthesis phase. We believe that, in general, every flip-flop in an ASIC should be resetable whether or not it is required by the system. In some cases, when pipelined flip-flops (shift register flip-flops) are used in high speed applications, reset might be eliminated from some flip-flops to achieve higher performance designs. This type of environment requires a predetermined number of clocks during the reset active period to put the ASIC into a known state. Many design issues must be considered before choosing a reset strategy for an ASIC design, such as whether to use synchronous or asynchronous resets, will every flip-flop receive a reset, how will the reset tree be laid out and buffered, how to verify timing of the reset tree, how to functionally test the reset with test scan vectors, and how to apply the reset across multiple clocked logic partitions. 3.0 General flip-flop coding style notes 3.1 Synchronous reset flip-flops with non reset follower flip-flops Each Verilog procedural block or VHDL process should model only one type of flip-flop. In other words, a designer should not mix resetable flip-flops with follower flip-flops (flops with no resets) in the same procedural block or process[14]. Follower flip-flops are flip-flops that are simple data shift registers. In the Verilog code of Example 1a and the VHDL code of Example 1b, a flip-flop is used to capture data and then its output is passed through a follower flip-flop. The first stage of this design is reset with a synchronous reset. The second stage is a follower flip-flop and is not reset, but because the two flip-flops were inferred in the same procedural block/process, the reset signal rst_n will be used as a data enable for the second flop. This coding style will generate extraneous logic as shown in Figure 1. SNUG Boston 2003 Asynchronous & Synchronous Reset Rev 1.3 Design Techniques - Part Deux 4 module badFFstyle ( output reg q2, input d, clk, rst_n); reg q1; always @(posedge clk) if (!rst_n) q1 <= 1'b0; else begin q1 <= d; q2 <= q1; end endmodule Example 1a - Bad Verilog coding style to model dissimilar flip-flops library ieee; use ieee.std_logic_1164.all; entity badFFstyle is port ( clk : in std_logic; rst_n : in std_logic; d : in std_logic; q2 : out std_logic); end badFFstyle; architecture rtl of badFFstyle is signal q1 : std_logic; begin process (clk) begin if (clk'event and clk = '1') then if (rst_n = '0') then q1 <= '0'; else q1 <= d; q2 <= q1; end if; end if; end process; end rtl; Example 1b - Bad VHDL coding style to model dissimilar flip-flops SNUG Boston 2003 Asynchronous & Synchronous Reset Rev 1.3 Design Techniques - Part Deux 5 Figure 1 - Bad coding style yields a design with an unnecessary loadable flip-flop The correct way to model a follower flip-flop is with two Verilog procedural blocks as shown in Example 2a or two VHDL processes as shown in Example 2b. These coding styles will generate the logic shown in Figure 2. module goodFFstyle ( output reg q2, input d, clk, rst_n); reg q1; always @(posedge clk) if (!rst_n) q1 <= 1'b0; else q1 <= d; always @(posedge clk) q2 <= q1; endmodule Example 2a - Good Verilog-2001 coding style to model dissimilar flip-flops library ieee; use ieee.std_logic_1164.all; entity goodFFstyle is port ( clk : in std_logic; rst_n : in std_logic; d : in std_logic; q2 : out std_logic); end goodFFstyle; architecture rtl of goodFFstyle is signal q1 : std_logic; begin process (clk) begin SNUG Boston 2003 Asynchronous & Synchronous Reset Rev 1.3 Design Techniques - Part Deux 6 if (clk'event and clk = '1') then if (rst_n = '0') then q1 <= '0'; else q1 <= d; end if; end if; end process; process (clk) begin if (clk'event and clk = '1') then q2 <= q1; end if; end process; end rtl; Example 2b - Good VHDL coding style to model dissimilar flip-flops Figure 2 - Two different types of flip-flops, one with synchronous reset and one without It should be noted that the extraneous logic generated by the code in Example 1a and Example 1b is only a result of using a synchronous reset. If an asynchronous reset approach had be used, then both coding styles would synthesize to the same design without any extra combinational logic. The generation of different flip-flop styles is largely a function of the sensitivity lists and if-else statements that are used in the HDL code. More details about the sensitivity list and if-else coding styles are detailed in section 4.1. 3.2 Flip-flop inference style Each inferred flip-flop should not be independently modeled in its own procedural block/process. As a matter of style, all inferred flip-flops of a given function or even groups of functions should be described using a single procedural block/process. Multiple procedural blocks/processes should be used to model larger partitioned blocks within a given module/architecture. The exception to this guideline is that of follower flip-flops as discussed in section 3.1 where multiple procedural blocks/processes are required to efficiently model the function itself. SNUG Boston 2003 Asynchronous & Synchronous Reset Rev 1.3 Design Techniques - Part Deux 7 3.3 Assignment operator guideline In Verilog, all assignments made inside the always block modeling an inferred flip-flop (sequential logic) should be made with nonblocking assignment operators[3]. Likewise, for VHDL, inferred flip-flops should be made using signal assignments. 4.0 Synchronous resets As research was conducted for this paper, a collection of ESNUG and SOLV-IT articles was gathered and reviewed. Around 80+% of the gathered articles focused on synchronous reset issues. Many SNUG papers have been presented in which the presenter would claim something like, “we all know that the best way to do resets in an ASIC is to strictly use synchronous resets”, or maybe, “asynchronous resets are bad and should be avoided.” Yet, little evidence was offered to justify these statements. There are both advantages and disadvantages to using either synchronous or asynchronous resets. The designer must use an approach that is appropriate for the design. Synchronous resets are based on the premise that the reset signal will only affect or reset the state of the flip-flop on the active edge of a clock. The reset can be applied to the flip-flop as part of the combinational logic generating the d-input to the flip-flop. If this is the case, the coding style to model the reset should be an if/else priority style with the reset in the if condition and all other combinational logic in the else section. If this style is not strictly observed, two possible problems can occur. First, in some simulators, based on the logic equations, the logic can block the reset from reaching the flip-flop. This is only a simulation issue, not a hardware issue, but remember, one of the prime objectives of a reset is to put the ASIC into a known state for simulation. Second, the reset could be a “late arriving signal” relative to the clock period, due to the high fanout of the reset tree. Even though the reset will be buffered from a reset buffer tree, it is wise to limit the amount of logic the reset must traverse once it reaches the local logic. This style of synchronous reset can be used with any logic or library. Example 3 shows an implementation of this style of synchronous reset as part of a loadable counter with carry out. module ctr8sr ( output reg [7:0] q, output reg co, input [7:0] d, input ld, clk, rst_n); always @(posedge clk) if (!rst_n) {co,q} <= 9'b0; // sync reset else if (ld) {co,q} <= d; // sync load else {co,q} <= q + 1'b1; // sync increment endmodule Example 3a - Verilog-2001 code for a loadable counter with synchronous reset SNUG Boston 2003 Asynchronous & Synchronous Reset Rev 1.3 Design Techniques - Part Deux 8 library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; entity ctr8sr is port ( clk : in std_logic; rst_n : in std_logic; d : in std_logic; ld : in std_logic; q : out std_logic_vector(7 downto 0); co : out std_logic); end ctr8sr; architecture rtl of ctr8sr is signal count : std_logic_vector(8 downto 0); begin co <= count(8); q <= count(7 downto 0); process (clk) begin if (clk'event and clk = '1') then if (rst_n = '0') then count <= (others => '0'); -- sync reset elsif (ld = '1') then count <= '0' & d; -- sync load else count <= count + 1; -- sync increment end if; end if; end process; end rtl; Example 3b - VHDL code for a loadable counter with synchronous reset SNUG Boston 2003 Asynchronous & Synchronous Reset Rev 1.3 Design Techniques - Part Deux 9 Figure 3 - Loadable counter with synchronous reset 4.1 Coding style and example circuit The Verilog code of Example 4a and the VHDL code of 4b show the correct way to model synchronous reset flip-flops. Note that the reset is not part of the sensitivity list. For Verilog omitting the reset from the sensitivity list is what makes the reset synchronous. For VHDL omitting the reset from the sensitivity list and checking for the reset after the “if clk’event and clk = 1” statement makes the reset synchronous. Also note that the reset is given priority over any other assignment by using the if-else coding style. module sync_resetFFstyle ( output reg q, input d, clk, rst_n); always @(posedge clk) if (!rst_n) q <= 1'b0; else q <= d; endmodule Example 4a - Correct way to model a flip-flop with synchronous reset using Verilog-2001 library ieee; use ieee.std_logic_1164.all; entity syncresetFFstyle is port ( clk : in std_logic; rst_n : in std_logic; d : in std_logic; q : out std_logic); end syncresetFFstyle; architecture rtl of syncresetFFstyle is SNUG Boston 2003 Asynchronous & Synchronous Reset Rev 1.3 Design Techniques - Part Deux 10 begin process (clk) begin if (clk'event and clk = '1') then if (rst_n = '0') then q <= '0'; else q <= d; end if; end if; end process; end rtl; Example 4b - Correct way to model a flip-flop with synchronous reset using VHDL One problem with synchronous resets is that the synthesis tool cannot easily distinguish the reset signal from any other data signal. Consider the code from Example 3, which resulted in the circuit of Figure 3. The synthesis tool could alternatively have produced the circuit of Figure 4. Figure 4 - Alternative circuit for loadable counter with synchronous reset This is functionally identical to Figure 3. The only difference is that the reset and-gates are outside the MUX. Now, consider what happens at the start of a gate-level simulation. The inputs to both legs of the MUX can be forced to 0 by holding rst_n asserted low, however if ld is unknown (X) and the MUX model is pessimistic, then the flops will stay unknown (X) rather than being reset. Note this is only a problem during simulation! The actual circuit would work correctly and reset the flops to 0. Synopsys provides the compiler directive sync_set_reset which tells the synthesis tool that a given signal is a synchronous reset (or set). The synthesis tool will “pull” this signal as close to the flop as possible to prevent this initialization problem from occurring. In this example the directive would be used by adding the following line somewhere inside the module: SNUG Boston 2003 Asynchronous & Synchronous Reset Rev 1.3 Design Techniques - Part Deux 11 // synopsys sync_set_reset "rst_n" In general, we recommend only using Synopsys switches when they are required and make a difference; however the sync_set_reset directive does not affect the logical behavior of a design, instead it only impacts the functional implementation of a design. A wise engineer would prefer to avoid re-synthesizing the design late in the project schedule and would add the sync_set_reset directive to all RTL code from the start of the project. Since this directive is only required once per module, adding it to each module with synchronous resets is recommended. Alternatively the synthesis variable hdlin_ff_always_sync_set_reset can be set to true prior to reading in the RTL, which will give the same result without requiring any directives in the code itself. A few years back, another ESNUG contributor recommended adding the compile_preserve_sync_resets = "true" synthesis variable [15]. Although this variable might have been useful a few years ago, it was discontinued starting with Synopsys version 3.4b[38]. 4.2 Advantages of synchronous resets Synchronous reset logic will synthesize to smaller flip-flops, particularly if the reset is gated with the logic generating the d-input. But in such a case, the combinational logic gate count grows, so the overall gate count savings may not be that significant. If a design is tight, the area savings of one or two gates per flip-flop may ensure the ASIC fits into the die. However, in today’s technology of huge die sizes, the savings of a gate or two per flip-flop is generally irrelevant and will not be a significant factor of whether a design fits into a die. Synchronous resets generally insure that the circuit is 100% synchronous. Synchronous resets insure that reset can only occur at an active clock edge. The clock works as a filter for small reset glitches; however, if these glitches occur near the active clock edge, the flip-flop could go metastable. This is no different or worse than every other data input; any signal that violates setup requirements can cause metastability. In some designs, the reset must be generated by a set of internal conditions. A synchronous reset is recommended for these types of designs because it will filter the logic equation glitches between clocks. By using synchronous resets and a pre-determined number of clocks as part of the reset process, flip-flops can be used within the reset buffer tree to help the timing of the buffer tree keep within a clock period. According to the Reuse Methodology Manual (RMM)[32], synchronous resets might be easier to work with when using cycle based simulators. For this reason, synchronous resets are recommend in section 3.2.4(2nd edition, section 3.2.3 in the 1st edition) of the RMM. We believe using asynchronous resets with a good testbench coding style, where reset stimulus is only changed on clock edges, removes any simulation ease or speed advantages attributed to synchronous reset designs by the RMM. Translation: it is doubtful that reset style makes much difference in either ease or speed of simulation. SNUG Boston 2003 Asynchronous & Synchronous Reset Rev 1.3 Design Techniques - Part Deux 12 4.3 Disadvantages of synchronous resets Not all ASIC libraries have flip-flops with built-in synchronous resets. However since synchronous reset is just another data input, you don’t really need a special flop. The reset logic can easily be synthesized outside the flop itself. Synchronous resets may need a pulse stretcher to guarantee a reset pulse width wide enough to e