Common Path Pessimism

Common Path Pessimism is a common source of some extra pessimism in timing analysis. Before we delve further into this, note that pessimism can be of two types: Intended and Unwanted. Intended pessimism could be like adding some extra uncertainty for clock skew before CTS stage, or some uncertainty for noise before SI (Signal Integrity) analysis. It is often prudent to have this pessimism taken upfront in your design because it will avoid any surprises when you move from one stage to another. 

Having said that, which category do you reckon should Common Path Pessimism fall? Let's define it first and then we'll take a look at it objectively.

When any pair of launching and capturing flop have a some portion of clock path as common, the difference between the max and min delay of that common clock segment is referred to as Common Path Pessimism. We discussed the rationale behind the use of timing derates briefly in the post: OCV vs PVT. Note that the entire timing analysis revolves around this intended pessimism where the basic aim is to make the timing paths more critical to avoid seeing any surprises in the silicon. EDA tools, however, themselves have quite a fair amount of pessimism, it is always prudent for the STA engineers to augment some uncertainty/pessimism in their timing analysis.

Convince yourself that:

• Setup check would be most critical when clock reaches the launching flop late and capturing flop early; and the data path takes more delay.
• Hold check would be most critical when clock reaches the launching flop early, capturing flop late and data path takes less delay.

Consider the following example with no common clock path and note that we have just applied the above principle to add pessimism in timing analysis.

So, while doing setup analysis, the clock tree buffers in the launching path would be derated by +5% and in the capturing path would be derated by -5&. The data path would be derated by +5%.
While doing hold analysis, it would be the opposite. The clock tree buffers in the launching path would be derated by -5% and in the capturing path would be derated by +5&. The data path would be derated by -5%.

How would the situation change when there's a common clock path? Let's take a look.

Ideally speaking, for setup analysis, we would like to take the +5% derated value of the delay of these buffers while considering launching path and -5% derated value while considering the capture path. However, here lies the catch! How can the same buffer or set of buffers be derated differently for launch and capture? Recall from the definition of OCV that it is the intra-chip variation in PVT that STA engineers consider them in the first place.

However, now these buffers, they are in the same location. So at a time they would behave in a similar manner. It does not make sense to consider different delays for same buffers. And this is the origin of common path pessimism and in usually unwanted. What we can do is (or rather what EDA tools tend to do is), do the calculation considering common path to be non-existent. And in the slack, add the double derated value of the common buffers, which would be 10% of the three common buffers in this case. This is referred to as Common Path Pessimism Removal.

Combinational Loops

You would often hear backend engineers remonstrating the frontend design folks on the presence of combinational loops in the design. But why do they create such a hue and cry? What possibly could one or maybe few combinational loops do? Well, potentially, they can render the entire functionality of the SoC haywire and not taken care off. And some combinational loops, on the other hand, are indispensable for the evolution of a particular technology. We'll see how and why.

A combo loop is structure which is formed by a signal starting from an input of a combinational gate, after passing through one or more combinational gate, reaches the same combo gate from which it started without encountering any sequential element in between.

Here's what a generalized combo loop looks like:

• Unstable Loops: Let's start with a basic combo loop that you must have studied in your academics or at least heard about it. The reverend Ring Oscillator. It is an inveterate fallacy that a ring oscillator can be used to make a clock generating circuit. Trust me, clock generating or even divider circuits, for that matter, are not as simple as the ring oscillator shown below. 

Of what use could this simple circuit be? Well, if we can control any one input of any of the three inverters shown here, we can know the delay of an inverter which is often the first cell to be characterized in any technology. Moreover, test structures like these also help the foundry guys in determining the manufacturing process of a particular chip whether it was WCS or BCS.

• Stable Loops: Here's an example of a stable loop consisting of an OR gate. Note that, as soon as the free input receives a logic 1, the output goes to 1. And same signal is conveyed back to the another input, and the loop is stable or rather stuck-at-1.

Note that stable loops would not pose problems of copious dynamic power consumption. But such a loops pose headaches to DFT teams. Recall from the post: Two Pillars of DFT: Controllability & Observability, we talked about how stuck-at faults are simulated and detected. If such a loop would be present in the design, any stuck-at faults in the vicinity of this gate cannot be observed, and hence DFT team would lose their stuck-at coverage by a considerable amount!!

STA Concerns: We started this post with a preamble talking about backend engineers repining the frontend engineers. How would a backend engineer be affected by a combo loop? Here's how.

Recall from the post: Factors Affecting Delays of Standard Cells that the delay and output slew of any standard cell depends on the input slew and output load. The below figure shows one such example, where slew can keep on degrading indefinitely, and would ultimately impact the timing and more importantly the power consumption of the SoC.

To sum up, combo loops must be avoided in all SoCs except for special circumstances like ring oscillator circuit can be employed for testing the characteristics of the SoC.

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.