False Path v/s Case Analysis v/s Disable Timing

Often people have asked me the difference between set_false_path, set_case_analysis and set_disable_timing. While the difference between these three is quite easy, it's the implications that leave many designers stumped.

Let me take a shot at explaining the difference.

1. FALSE PATH: All the timing paths which designers know won't be exercised on the fly, and they don't really need to meet any timing constraints on that path can be marked as false paths.
Tools would compute delays on all arcs on the false-path, would try to meet slopes/max-fanout/max-capacitance targets for all nodes along the path, but these paths would never surface up as timing (setup and hold) violations. However, if designers are too concerned about meeting slope and max cap targets, they usually prefer to mark such paths as set_multicycle_path instead.

Some examples of false path:

Consider the circuit above. The select line of the two multiplexers is complement of each other. STA tool, however, doesn't understand this logic and would treat all nodes as X (either 0 or 1). In practice, there can never be a timing path between 

C -> E -> G
D -> F -> G

And these can be marked as false paths.

2. CASE ANALYSIS: Using set_case_analysis, any node can be constrained to a boolean logic value of 1 or 0. All case values are evaluated and propagated through the design. For example, if one input of an AND gate is 0, 0 being the controlling value, the output of AND gate would also be 0 and this 0 is propagated downstream. The timing arcs for set_case_analysis are not evaluated and they never show up in the timing reports. However, PnR tooks would still fix max transition, max capacitance and max-fanout violations on these nets/pins.

• Some latest tool versions also support a case value of static which means that the node will always be static (never toggle), and this is used to reduce the pessimism which doing noise analysis.

• Case analysis is also particularly useful for DFT modes where you would want to set a few configuration registers and drive the chip into a particular DFT mode: like atspeed, shift or stuck-at mode. This acts as an additional level of verification because you'd expect to see only scan chains in the shift mode with scan enable being 1. You'd expect to see functional paths in the atspeed mode with scan enable being X, and you'd expect to see only paths ending at functional register inputs in the stuck-at mode with scan enable being 0.

3. DISABLE TIMING: This disables a particular timing arc, and that timing arc or any timing path through the disabled timing arc is not computed. This tends to be a bit disruptive as compared to false paths or case analysis, but in some cases this is indispensable and the easiest way to achieve the intent. For example if you have a MUX based divider which receives the clock signal at the select line of the multiplexer, and two functional enables at the multiplexer inputs, STA tool would try to propagate the clock to the output of the MUX via the MUX select line to the output. But for a MUX, a select line only controls what gets propagated to the output. In practice, there's no arc between select and output and should be disabled.

Both case analysis and disable timing result in fewer timing paths to be analyzed. False path still tries to fix the design rule (max cap, max transition and max fanout) violations.

The Timing Optimization Problem

Puzzle:

Tomorrow is the scheduled tape-out of your SoC. The target clock frequency for this SoC is 100 MHz (Time Period of 10 ns). However, there's only one setup violating path and you need to fix the timing by doing ECOs. Area is not a constraint.

Here's the circuit:

Points to note:

• My tape-out is tomorrow, I don't have the liberty of asking the RTL design team to change the architecture of the design.
• I have used the highest possible drive strength cells, and perhaps the lowest Vt flavor cells available in my standard cell library.
• There's no redundant logic in the path, it's been optimized well.
• I cannot add delay to the clock path of FF2 because doing so, the hold time of the scan chain connecting flops FF1 and FF2 would fail.

Please suggest ways to solve this timing violation. A rough image would be really helpful. I shall post my solution in a couple of days time.

Mike posted the correct answer, and I'll just add a figure explaining the solution:

Timing Analysis: Graph Based v/s Path Based

Hello folks! In this post, I'm gonna talk about the difference between two commonly used Static Timing Analysis methodologies, namely- the Graph Based Analysis and the Path Based Analysis.

I shall explain the difference with help of an example, shown below:

Now, we have two slews- fast and slow. In Graph Based Analysis, the worst slew propagation is ON, and the timing engine computes the worst case delays of all standard cells assuming the worst case slew for all the inputs of a gate. For example, assuming we need to compute the gate delays while doing setup analysis in a graph-based methodology for the path from FF1 to FF2:

• The delay of the A-> Z (output) arc of the OR gate (in brown) would be computed assuming the real slew slew, i.e. slew at pin A. 
• However, the slew that will be propagated to the output pin of the OR gate would be the worst slew, which in this case would be computed taking into account the load at the output of the OR gate and slew at B.
• Similarly, the delay of NAND gate (in blue) would be computed using the propagated slew coming from the previous stage i.e. the slew at pin B, but the slew that is propagated to the output would be according to the worst input slew, in this case slew at A.
• And so on and so forth..

While performing hold analysis in a graph-based methodology, the situation reverses, the the delays of all cells would be computed assuming the best propagated slews (fast slews) for all nodes along the timing path!

This method of timing analysis is faster and uses lower memory footprint because the engine has to simple keep a tab of worst propagated slews for every pin in the design. This surely is pessimistic but again faster and therefore does not encumber the optimization tool by bounding the problem. For example, for the OR gate, the slew propagated to it's output is the worst slew, therefore the delays of subsequent gates after the OR gate could be pessimistic. The Path-based analysis comes to the rescue at some cost.

In Path-based analysis, the tools takes into account the actual slew for the arcs encountered while traversing any particular timing path. For example for the path shown above from FF1 to FF2, the arcs encountered are- A-> Z for OR gate; B-> Z for NAND gate; B-> Z for XOR gate and A-> Z for the inverted AND gate.

The tool would therefore consider the actual slews and this dispenses with the unnecessary pessimism!

Why not use PBA instead of GBA? Who's stopping us?

The answer is the run-time and memory foot-print. Since, PBA needs to compute the delays of standard cells in cognizance with the particular timing path, it incurs a penalty on the run-time to compute the delays, as opposed to GBA where the worse propagated slew was being used to compute the delays. In a nutshell, PBA is more accurate at the cost of run-time. 

Typically, design engineers tend to use GBA for majority of the analysis. However, for the paths with a small violation (maybe of the order of 10s of ps) may be waived off by running PBA for the top-critical paths when the tape-out of the design is impending. One might argue that the extra effort spent in optimizing many other paths might have been saved had we used PBA earlier. And it is true! But like any engineering problem, there exists a trade-off and one needs to take a call between fixing the timing and a potential risk of delaying the tape-out!