Tcl · Module 26

Why MCMM Exists

A single timing report is not wrong. It is narrow — true of exactly one combination of mode, corner and check, and silent about the seventeen others.

Advanced21 min readtcledapart-iimcmmsignofftiming

Part II · Module 26 · Chapter 26.1 · Why MCMM Exists

Chapter 22.8 ran the same analysis over several corners and found that the per-corner results could not be summarised by their worst number. This module is that observation turned into a flow.

The starting point is a report that looks like success.

1. One clean report

The timing model used throughout this module is a small teaching mock — no EDA tool exists on the machine these chapters were verified on (Chapter 25.1 §1). It computes arrival as (cell_delay + net_delay) × corner_derate and slack against the mode's period, so every number in Module 26 can be recomputed by hand, which is the point of using one.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

apply_mode functional
apply_corner tt_0p80v_25c

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

=== one scenario, analysed ===
    PATH             ARRIVAL  REQUIRED     SLACK
    core_to_mem       3.4500    4.8500    1.4000
    io_to_core        4.1000    4.8500    0.7500
    short_hold        0.1100    4.8500    4.7400
    worst setup slack : 0.7500

Worst setup slack +0.75 ns, positive, with margin. Three paths, all passing. If this is the report somebody pastes into a review, the design looks closed.

Check the arithmetic: core_to_mem has 2.90 of cell delay and 0.55 of net delay, the typical corner derates by 1.00, so arrival is 3.4500. The mode's period is 5.0 with 0.15 of uncertainty, so required is 4.8500. Slack is 1.4000. Nothing is hidden.

2. What that report is a report of

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

=== and that single clean report is what sign-off is NOT ===
    mode   : functional
    corner : tt_0p80v_25c
    checks : setup
    this is 1 of 18 mode x corner x check combinations

Figure 1 — the gap between one analysis and sign-off. Above: a single run fixes one mode, one corner and one check, so it is true of exactly one cell of the grid and says nothing about any other. Below: sign-off walks every combination the project has declared required, which is what lets a result stand for the design rather than for one operating point.

Three axes multiply:

Mode — what the chip is doing. Functional operation, scan shift, scan capture, a low-power mode, a bring-up mode. Each has its own clocks, periods and exceptions (Chapter 26.2).
Corner — the physical conditions and the library data that models them. Process, voltage, temperature (Chapter 26.3).
Check — setup and hold, which as Chapter 23.4 §5 established move in opposite directions.

Three modes, three corners, two checks is eighteen. A real design has more of all three, and the product is the number of analyses sign-off actually requires.

3. The same design, everywhere

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

=== the same design across every mode x corner x check ===
    MODE          CORNER         CHECK      WORST
    functional    ss_0p72v_125c  setup    -0.4800  <- VIOLATED
    functional    ss_0p72v_125c  hold      0.0430
    functional    tt_0p80v_25c   setup     0.7500
    functional    tt_0p80v_25c   hold      0.0100
    functional    ff_0p88v_m40c  setup     1.8980
    functional    ff_0p88v_m40c  hold     -0.0208  <- VIOLATED
    scan_shift    ss_0p72v_125c  setup     8.0000
    scan_shift    ss_0p72v_125c  hold      0.0430
    scan_shift    tt_0p80v_25c   setup    10.7000
    scan_shift    tt_0p80v_25c   hold      0.0100
    scan_shift    ff_0p88v_m40c  setup    13.2200
    scan_shift    ff_0p88v_m40c  hold     -0.0208  <- VIOLATED
    scan_capture  ss_0p72v_125c  setup    -6.8500  <- VIOLATED
    scan_capture  ss_0p72v_125c  hold      0.0430
    scan_capture  tt_0p80v_25c   setup    -4.1500  <- VIOLATED
    scan_capture  tt_0p80v_25c   hold      0.0100
    scan_capture  ff_0p88v_m40c  setup    -1.6300  <- VIOLATED
    scan_capture  ff_0p88v_m40c  hold     -0.0208  <- VIOLATED

    3 modes x 3 corners x 2 checks = 18 scenarios
    7 of 18 violate

Find §1's clean report in that table. It is row three: functional / tt_0p80v_25c / setup, at +0.7500.

Now read what sits either side of it in the same mode:

functional / ss_0p72v_125c / setup is −0.4800. One corner slower, same mode, same check: a violation.
functional / ff_0p88v_m40c / hold is −0.0208. One corner faster, same mode, and the other check: a different violation.

So the clean report is bracketed by failures in two different directions, and neither is reachable by looking harder at the report you have. That is the chapter's whole claim: a clean report is not wrong, it is narrow. It is a true statement about one cell of an eighteen-cell grid.

And this is the familiar Part II shape one more time — Chapter 23.3 §5's two placements with the same worst congestion, Chapter 24.3 §2's inverted leakage share, Chapter 25.4 §3's failing test exiting 0. In every case a confident number was produced by a correct process answering a narrower question than the one being asked.

4. Why the failures sit where they do

The table is not arbitrary, and the pattern in it is worth reading because it is the physics MCMM exists to cover.

Setup gets worse as the corner slows. functional / setup runs +1.8980 at the fast corner, +0.7500 at typical, −0.4800 at slow. The derates are 0.72, 1.00 and 1.30, and arrival scales with them directly — so the slow corner is where setup is decided.

Hold gets worse as the corner speeds up. functional / hold runs +0.0430 slow, +0.0100 typical, −0.0208 fast. A hold check asks whether data arrives too early, so a faster corner makes it harder. The slow corner, which is the dangerous one for setup, is the comfortable one for hold.

That is why there is no single worst corner, and why "just analyse the slow corner" does not work.

Setup is decided at the slow corner and hold at the fast one, so any flow that analyses one corner has, by construction, left one check unexamined. It is the two-sided structure of Chapter 23.4 §5 — where clock skew hurt setup and hold in opposite directions — reappearing as a property of the corner axis rather than of the clock tree.

A useful consequence: the corner list and the check list are not independent. A project that runs setup at three corners and hold at three corners is often doing twice the work it needs, because setup at the fast corner and hold at the slow corner are the comfortable combinations. That pruning is Chapter 26.4's subject, and the table above is the data it is decided from.

scan_capture / setup fails at every corner, including the fast one, at −1.6300. That is not a corner problem at all — the scan chain path has 9.0 ns of base delay and the capture mode's period is 5.0 ns, so no corner can rescue it. A scenario that fails everywhere is usually a sign that the scenario itself is wrong: real DFT captures at a slower clock precisely because the shift path cannot meet functional speed. The table does not tell you that; it tells you to go and ask.

scan_shift / setup passes with 8 to 13 ns of slack, because that mode's period is 20 ns. Analysis there is nearly free of information — the other half of the pruning argument.

5. What "a single clean report" costs

Being concrete about the failure mode, because this is the one that reaches silicon.

The report in §1 is the one that gets run most often, because typical-corner functional-mode setup is fast to analyse, easy to explain, and improves steadily as the design converges. It is a good tracking number. It is not a sign-off number, and the gap between those two uses is where the risk lives:

A design closed on typical ships a part that fails at temperature, which is the ss / setup violation.
A design closed on setup alone ships a part that fails at cold, which is the ff / hold violation — and hold failures are not recoverable by slowing the clock (Chapter 24.4 §5), so that part is scrap.
A design closed in functional mode alone ships a part that cannot be tested, which is the scan_capture column.

Each of those is a real, distinct, unrelated failure, and all three are invisible in the report that said +0.7500.

6. What this module builds

The rest of Module 26 is the flow that closes the gap:

26.2 Modes — what a mode is and what changes with it, stated as data rather than remembered.
26.3 Corners — a corner and the library and parasitic data it selects, in one structure rather than in file names.
26.4 Scenarios — the cross-product, and the deliberate decision about which combinations are required.
26.5 The driver loop — walking the required set with each iteration isolated.
26.6 Reporting per scenario — keeping the results separable so a number can be traced to the run that produced it.

Every one of those is ordinary Part I Tcl — dictionaries, nested foreach, catch, file mkdir. The difficulty of MCMM is not the Tcl. It is deciding what to run and keeping the answers apart afterwards.

7. Exercises

Exercise 1. What three axes multiply to give the scenario count?

Exercise 2. The §1 report says +0.7500 and nothing in it is wrong. What is the problem with it?

Exercise 3. Recompute core_to_mem's arrival and slack at the typical corner from the raw numbers.

Exercise 4. Which corner decides setup, which decides hold, and why?

Exercise 5. Why does "just analyse the slow corner" leave a gap?

Exercise 6. scan_capture / setup fails at all three corners. What does that suggest, and why is it not a corner problem?

Exercise 7. Why is scan_shift / setup nearly information-free?

Exercise 8. Name the three distinct silicon failures the §1 report cannot see.

Exercise 9. Why is a hold failure worse to discover in silicon than a setup failure?

Answers.

1. Mode (what the chip is doing), corner (process, voltage, temperature and the library data that models them), and check (setup and hold). Three of each, with two checks, gives eighteen.

2. It is narrow, not wrong. It is a true statement about one cell of an eighteen-cell grid, and the design violates in seven of those cells — including two reachable from the same mode by changing only the corner or the check.

3. Cell 2.90 plus net 0.55 is 3.45, times the typical derate of 1.00 is an arrival of 3.4500. Period 5.0 less uncertainty 0.15 is a required time of 4.8500. Slack is 4.8500 − 3.4500 = 1.4000.

4. The slow corner decides setup, because arrival scales with the derate and a bigger derate means later data. The fast corner decides hold, because a hold check asks whether data arrives too early and a smaller derate makes it earlier.

5. Because the slow corner is the comfortable one for hold. Analysing it alone leaves hold unexamined by construction.

6. That the scenario itself is probably wrong. The scan chain path has 9.0 ns of base delay against a 5.0 ns period, so no derate can close it — real DFT captures at a slower clock for exactly this reason.

7. Because that mode's period is 20 ns, so setup passes with 8 to 13 ns of margin. The analysis is correct and tells you almost nothing.

8. A part that fails at temperature (slow-corner setup), a part that fails at cold (fast-corner hold), and a part that cannot be tested (the scan-capture column).

9. Because slowing the clock does not fix it — both the data path and the clock path slow together — so the part does not work at any frequency and is scrap rather than a downgraded bin.

Remember.

Mode × corner × check is the scenario count. Three, three and two is eighteen; a real design is larger.
A single clean report is narrow, not wrong — true of one cell, silent on the rest. Here: +0.7500 at typical, with 7 of 18 scenarios violating.
The clean report is bracketed by failures in two directions — one corner slower on the same check, one corner faster on the other check.
Setup is decided at the slow corner; hold at the fast one. Any single-corner flow leaves one check unexamined.
So the corner and check axes are not independent, which is what makes deliberate pruning possible.
A scenario that fails at every corner is usually the wrong scenario, not a corner problem.
A scenario with enormous margin carries almost no information — scan shift setup at a 20 ns period.
Typical-corner functional setup is a tracking number, not a sign-off number, and confusing the two is how parts fail at temperature.
The difficulty of MCMM is not the Tcl. It is deciding what to run and keeping the answers apart.

Where this fits

Part of the Tcl curriculum.