Puzzle: DFT Shift Frequency

It is a well known fact that DFT Shifting is done at a slower frequency. Well, I'm gonna list down some cons against this. You'll have to tell the pros!

• Lower is the frequency, greater is the test time. In modern SoCs, tester cost  (which is directly proportional to the tester time) accounts for roughly 40% of the selling price of a single chip. It would be pragmatic to decrease the test time by increasing the frequency. No?
  
• Increasing the frequency would not pose any timing issue. Because, hold would anyway be met (Hold check is independent of frequency). And setup would never be in the critical path considering the fact that scan chains only involve direct path from output of a flop to scan input pin of the next flop, devoid of any logic.
  

Then why not test at a higher frequency, which is at least closer to the functional frequency? What could possibly be the reason for testing at slower frequency?

Puzzle: Stuck-At Fault

A brief introduction to Stuck-At Faults was given in the post: Design for Testability: Need for Modern VLSI Design. You might want to go through it first. Anyway, as the name suggests, stuck-at faults manifest themselves if any particular node  in the design is "stuck" at either 0 or 1. A plausible explanation for stuck-at-0 (SA0) might be that the particuular node on question has somehow been shorted to Ground (GND at 0V) . Similarly, a node might be Stuck-At-1 (SA1) if let's say it is somehow shorted to the VDD (at logic 1).

In order to detect a stuck-at-0 fault, we would try to excite that node to the opposite value, i.e. 1 and try and see if we are able to achieve that. If we are able to do so, we can safely say that the node in question in NOT stuck-at-0. And vice-versa.

In the below question, we intend to check the node X for a stuck-at-0 fault. Can you tell what input vector (A,B,C) would be need to give to do so?

Two Pillars of DFT: Controllability & Observability

I haven't given an equitable share of attention to DFT, and now, it's time to make some amends! Just like Timing is built on two pillars: Setup & Hold, entire DFT is built on two pillars: Controllability & Observablity.  Very often you would find DFT folks cribbing that they can't control a particular node, or don't have any mechanism to observe a particular node in question. You may like to review the previous post: DFT Modes: Perspective before proceeding further.

Shifting our attention to the pillars of DFT, let's define the two.

• Controllability: It is the ability to have a desired value (which would be one out of 0 or 1) at any particular node of the design. If the DFT folks have that ability, they say that that particular node is 'controllable'. Which in turn means that they can force a value of either 0 or 1, on that node!
• Observability: It is the ability to actually observe the value at a particular node whether it is 0 or 1 by forcing some pre-defined inputs. Note that, unlike the circuit that we make on paper, the SoC is a colossal design and one can observe a node only via the output ports. So, DFT folks actually need a mechanism to excite a node and then fish that value out of the SoC via some output port and then 'observe' it!

Ideally, it is desired to have each and every node of the design controllable and observable. But reality continues to ruin the life of DFT folks! (Source: Calvin & Hobbes). It is not always possible or rather practical to have all the nodes in a design under your control, because of the sheer complexity that modern SoCs possess. And therefore, it is the reason you would hear them talk about 'Coverage'. Let's say coverage is 99%, this means that we have the ability to control and observe 99% of the nodes in the design (A pretty big number, indeed!).

Now let's take some simple examples.

In the above example, if we have control the flops such that the combo cloud results in 1 at both the inputs of AND gate, we say that the node X is controllable for 1. Similarly, if we can control any input of AND gate for 0, we say that node X is controllable for 0. Similarly, let's say we wish to observe the output of FF1. If we can somehow replicate the value of FF1 by making the combo clouds and AND gate transparent to the value at FF1, we say that output of FF1 is observable. Intuition tells us that for AND gate to be transparent, we should have the controllability of other node for 1. Because when one input of AND gate is 1, whatever is the value at the other input, it is simply passed on!!

Low Power Synthesis: Insertion of Clock Gating Cells

Power consumption is a growing concern for modern SoCs and design engineers today face an arduous task of limiting the power dissipation of their SoCs. It would be unfair to think the backend design cycle as a magical solution to all the power solutions. However, modern synthesis EDA tools are smart enough in identifying some key RTL constructs and synthesizing a low power equivalent of the structure. We will take a look at one such RTL Construct and it's equivalent implementation for low power design.

Consider the following behavioral description:

always @ ( posedge clk )
begin
   if (enable == 1'b1) then
   q [15:0] <= d [15:0]
end

One logical implementation and the corresponding low power implementation of the above description would be:

The synthesis tools find such RTL constructs and try and convert it into the low power implementation shown above. Please note that, the clock gating integrated cell (CGIC) also consumes power and the above implementation might not be an expedient solution if the above enable is mostly high, or even if the number of registers in the register set is small. Therefore, one needs to exercise caution while using or implementing such a structure!

Clock Jargon: Important Terms

Clock to an SoC is like blood to a human body. Just the way blood flows to each and every part of the body and regulates metabolism, clock reaches each and every sequential device and controls the digital events inside the SoC. There are many terms which modern designers use in relation to the clock and while building the Clock Tree, the backend team carefully monitors these. Let's have a look at them.

• Clock Latency: Clock Latency is the general term for the delay that the clock signal takes between any two points. It can be from source (PLL) to the sink pin (Clock Pin) of registers or between any two intermediate points. Note that it is a general term and you need to know the context before making any guess about what is exactly meant when someone mentions clock latency.
• Source Insertion Delay: This refers to the clock delay from the clock origin point, which could be the PLL or maybe the IRC (Internal Reference Clock) to the clock definition point.
• Network Insertion Delay: This refers to the clock delay from the clock definition point to the sink pin of the registers.

Consider a hierarchical design where we have multiple people working on multiple partitions or the sub-modules. So, the tool would be oblivious about the "top" or any logic outside the block. The block owner would define a clock at the port of the block (as shown below). And carry out the physical design activities. He would only see the Network Insertion Delay and can only model the Source Insertion Delay for the block.

Having discusses the latency, we have now focus our attention to another important clock parameter: The Skew.

We discusses the concept of skew and it's implication on timing in the post: Clock Skew: Implication on Timing. It would be prudent to go through that post before proceeding further. We shall now take the meaning of terms: Global Skew and Local Skew.

• Local Skew is the skew between any two related flops. By related we mean that the flops exist in the fan-in or fan-out cone of each other.
• Global Skew is the skew between any two non-related flops in the design. By non-related we mean that the two flops do not exist in the fan-out or fan-in cone of each other and hence are in a way mutually exclusive.

In the next post we would discuss the implications of big clock latency on the timing. Please feel free to post your thoughts at my<dot>personal<dot>log<at>gmail<dot>com.