Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > Embedded
?
?
Embedded??

Structural, reset faults in SoC designs (Part 2)

Posted: 22 Oct 2013 ?? ?Print Version ?Bookmark and Share

Keywords:combinational logic? reset path? register transfer level? RTL? metastability?

Read Part 1 of this series here.

Employing combinational logic in the reset path may produce glitches if the inputs of the combinatorial logic change at about the same time, triggering a false reset in design. Below is the kind of register transfer level (RTL) code which will produce such an unintentional reset.

assign module_a_rstb = !( (slave_addr[7:0] == 8'h02 & write_enable & (wdata[7:0] == 00) )
always @(posedge clk or negedge module_rst_b)
?? if(!module_rst_b) data_q ??else data_q In the above example, slave_addr, write_enable and wdata change their w.r.t system clock value. Using static timing analysis, the designer can ensure the stability of these signal within one clock cycle before the setup time window of the destination flop.

However, in this example these signals are used as the asynchronous clear input of a flop. Logically at any particular time the slave_addr[7:0] is changing its value from 00000110 to 01100000. But due to propagation delay (net delay and cell delay) of the combinatorial logic, it can make a transition with a sequence of 00000110:> 00000010> 00000000> 01000000> 01100000.

Figure 6: Combo logic in reset path.

If the wdata[7:0] is already zero and "write_enable" is already asserted during the time the salve_addr was 00000010 then it will create a unwanted pulse at module_rst_b, causing a false reset (figure 6).

Solution: The solution to this problem is to register the combinatorial output before using it as a source of reset (figure 7).

Sometimes the solution shown in figure 7 is not enough, if the inputs of the combinatorial logic change around the same time, triggering a false reset in the design. Figure 8 illustrates how this kind a problem can arise in such a design.

However, if the changes in the input signals of the combinatorial logic are mutually exclusive, then it may not cause any problems. For example, test mode and functional mode are mutually exclusive. Hence the test mux in the reset path is a valid design practice. But in some cases static signals or signals whose changes are mutually exclusive can cause a false reset trigger in a design.

Figure 7: Combo logic in reset path solution.

Figure 8: Combo logic in reset path.

In the example in figure 8, a MUX structure is used in reset path while coding in RTL. Here 'mode' is a control signal that doesn't change frequently, and mode0_rst_b and mode_1_rst_b are two reset events. However, while the RTL was synthesised, at the gate level it is broken into different complex combinational and-or-invert [AOI] cells. Logically this is equivalent to a mux. But due to different cell and net delays, final_rst_b produces a glitch whenever there is a change of the signal mode from 1>0.

Solution: Because MUX structures are less prone to glitches than other combinatorial logic, the best way to solve this problem is to preserve the MUX structure in the reset path during synthesis. A MUX pragma (data embedded in the RTL code to indicate some intention to the compiler) can be used while coding RTL to help the synthesis tool preserve any MUXes in reset path.

Issues with synchronous reset in design
SoC designers often prefer to reset the design synchronously with respect to the global clock. One reason to do this is to save some die area (flops with asynchronous reset inputs are bigger than non resettable flops). Another is to keep the system completely synchronous with respect to clock.

1???2???3?Next Page?Last Page



Article Comments - Structural, reset faults in SoC desi...
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

?
?
Back to Top