MENU

Structural faults leading to glitches

Structural faults leading to glitches

Feature articles |
By eeNews Europe



Also to save power, clock gating cells are inserted in the path of these clocks. While implementing these muxing and gating cells, designer tends to make some mistakes that can lead to glitches.

A glitch on a clock signal essentially renders a chip (or a section of a chip) to asynchronous behaviour. A glitch-prone clock signal driving a flip-flop, memory or a latch may store incorrect and unstable D (or data) input of a flip-flop, memory or a latch. This paper discusses structural faults that can lead to glitches in clocks. Also some bad design practices that lead to glitches in data are discussed briefly.

Converging outputs of flops as clock

In the design of figure 1, the outputs of two flops converge through combinational logic to make the clock of the third flop. Here again we may have a glitch at the output of combinational logic leading to a glitch prone clock operating the third flop. Now the designer needs to carefully review such structures. We can give waiver to such a structure if we are sure that the toggling of both paths is mutually exclusive. A typical case could be where one of the paths is through static IOMUX registers. In that case we may waive the path.

Fig. 1: Converging outputs of flops as clock

 

Incorrect latching of enable signal

Clock gating is an age old and important technique to reduce the overall dynamic power of design. There could be multiple approaches to implement clock gating. In the clock gating cell of figure 2, the enable signal is generated as output of “and” gate. This may lead to glitch in the enable signal which may lead to erroneous (glitch prone) clock as input to the flop.

One must always ensure that the enable signal of any clock gating cell is output of a flop else we may see glitch in the enable. If such structures cannot be avoided it must be ensured that at least one input to the “and” gate is static when used (say driven out of some configuration register). This ensures that there is no glitch in the enable signal when it is used. Such structures can be caught with any structural verification tool or in gls.

Fig. 2: Incorrect latching of enable signal.

 


Clock signals re-converging on a mux

In figure 3, the output of the mux after passing through the clock-pin of the flip- flop/latches re-converges back on the same mux. This results in creation of a glitch. We must ensure that we don’t have such structures in our design.

 

Fig 3: Clock signals re-converging on a mux.

 

Glitch due to reset crossing

Referring to the design of figure 4, the enable of a clock gating cell is coming from a flop which clears the enable signal asynchronously due to assertion of asynchronous reset ( Func_rst) while the input clock is still active, this can produce glitch at the output of the cell. A design solution for this is to synchronize the enable using 2-DFF structures which are either non – resettable flops or having POR as reset. This ensures that there is no asynchronous path from flop generating enable and clock gating cell.

 

Fig. 4: Glitch due to reset crossing.

 

Other Scenarios

There are other scenarios that can lead to glitches in clock. One of them being the use of combinational gates (and, nor, xor etc ) and instead of cg cells for gating of clocks – see figure 5.

While using a cg cell, there might be a case where the enable is launched from a clock domain that is different from that of the clock to be gated. This may also lead to glitches in the clock. Such cases need to be carefully reviewed and fixed in design after being caught by a tool or gls.

 

Fig. 5: Using combinational gates for clock gating.

 


Sources of data glitches

Any combinational logic used in a data path is glitch prone. But since the timing parameters are met for each and every synchronous path, the glitch will not be sampled in the destination domain. But there are cases (described below) where such timing parameters are not met and glitches may get sampled in the design.

Use of combinational logic at CDC Path

In an ideal situation, there should be no combinational logic present at the CDC Interface. If such logic is present it may lead to a glitch. Also the glitch may get sampled in the destination domain and may lead to erroneous behaviour. Here again designer needs to review all the paths at the interface. We may waive the structure shown in figure 6 if all the other inputs to this combo logic are static when used. Such structures can easily be caught with any CDC tool or in gls.

 

Fig. 6: Combinational logic at CDC Path.

 

Glitch at converging paths through an analogue block

Referring to figure 7, we have two inputs A and B which are combined through an “and” gate and fed to analogue IP. There is also another “and” gate which has B and the output of an analogue IP as inputs. The output of the second “and” gate is fed back to the analogue IP. Consider a case where B toggles and A = 1 we may observe glitches at the output of the second “and” gate. This kind of design which is purely combinational (with some hard macros) is always glitch prone. The glitch may get sampled in the design and may lead to unexpected behaviour. Such cases need the attention of designer and needs to be fixed in design.

 

Fig. 7: Glitch at converging paths through Analog block.

 

It is very important to make our design free of any clock or data glitches to ensure correct functioning of the design. There are cases where such issues have not only caused functional failure but increased execution cycle time by adding some extra debug time and effort. Hence it is very important for a designer to take care of such issues at very early stage of design once flagged by tool or gls.

About the author:

Ankush Sethi is design engineer at Freescale Semiconductor India Pvt Ltd – He can be reached at ankush.sethi@freescale.com

If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :    eeNews on Google News

Share:

Linked Articles
10s