Tcl · Module 26

Modes

Functional and test operation constrain the same silicon differently. A mode is the name for that difference, and it belongs in a data structure rather than in somebody's memory.

Advanced20 min readtcledapart-iimcmmmodesdft

Part II · Module 26 · Chapter 26.2 · Modes

A mode is one way the chip can be operating. The silicon is identical in every mode; what differs is the constraint under which it must work.

Chapter 26.1 showed the scan-capture column failing everywhere while functional mode passed at two corners out of three. Same gates, same wires, same corner data — a different question asked of them.

1. The modes a design actually has

The common set, and what each is for:

Mode	What the chip is doing	Why it needs its own constraint
Functional	normal operation	the real clocks, the real frequency, the real I/O timing
Scan shift	loading and unloading the scan chain	one slow scan clock; functional paths are irrelevant
Scan capture	one functional cycle between shifts	the real clock, but the scan chain is now a timed path
Low power	a reduced-voltage or gated state	some clocks stopped, some domains off
Bring-up	first silicon, deliberately slow	a relaxed period to get anything working

The first three are the ones the registry's brief names, and they are enough to carry the chapter — the differences between them are the differences that matter.

2. A mode as data

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

define_mode functional   -period 5.0  -uncertainty 0.15 -hold 0.10 -scan 0 \
    -clocks {core_clk io_clk} -exceptions {async_io}
define_mode scan_shift   -period 20.0 -uncertainty 0.30 -hold 0.10 -scan 1 \
    -clocks {scan_clk}         -exceptions {functional_paths}
define_mode scan_capture -period 5.0  -uncertainty 0.15 -hold 0.10 -scan 1 \
    -clocks {core_clk}         -exceptions {}

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

=== the three modes, as declared ===
    MODE           PERIOD  UNCERT   HOLD  SCAN CLOCKS             EXCEPTIONS
    functional       5.00    0.15   0.10     0 core_clk io_clk    async_io
    scan_shift      20.00    0.30   0.10     1 scan_clk           functional_paths
    scan_capture     5.00    0.15   0.10     1 core_clk           (none)

Read down the columns, because the differences are the content:

period — 20 ns in shift against 5 ns elsewhere. Shift runs slowly on purpose: it is thousands of cycles of pure data movement and has no reason to be fast.
uncertainty — 0.30 in shift against 0.15. The scan clock is usually distributed less carefully than the functional clock, so more margin is reserved for it.
hold — identical at 0.10 everywhere. Hold requirement is a property of the capturing flip-flop, not of the clock period, so it is genuinely mode-independent in this design. §3 of Chapter 26.4 measures what that costs the cross-product.
clocks — which clocks are even running. Functional has two; shift has only the scan clock.
exceptions — functional declares async_io as not to be timed; shift declares all the functional paths so. Each of those is a claim needing a recorded reason, exactly as in Chapter 20.5.

3. What a mode changes, part one: which paths are timed

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

=== which paths each mode actually times ===
    functional    3 path(s): core_to_mem, io_to_core, short_hold
    scan_shift    4 path(s): core_to_mem, io_to_core, short_hold, scan_chain
    scan_capture  4 path(s): core_to_mem, io_to_core, short_hold, scan_chain

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

=== a mode changes WHAT IS TIMED: functional vs scan_capture ===
    functional    period  5.00  times 3 path(s)  scan_chain included: no
    scan_capture  period  5.00  times 4 path(s)  scan_chain included: yes
    identical period, identical requirement — only the PATH SET differs

Identical period, identical uncertainty, identical requirement — and a different number of paths. The scan chain exists physically in functional mode; it is simply not a path that has to work, because the scan enable is deasserted and nothing is clocked through it.

So a mode is not only a number. It selects what the analysis is even looking at, and a path that is unconstrained in one mode is a timed path in another.

This is the mechanism behind Chapter 26.1's scan-capture failures: the path that fails there does not exist as a timing problem in functional mode at all, which is precisely why a functional-only flow never sees it.

4. What a mode changes, part two: the requirement

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

=== and a mode changes THE REQUIREMENT: functional vs scan_shift ===
    functional    arrival 3.4500  required  4.8500  slack   1.4000
    scan_shift    arrival 3.4500  required 19.7000  slack  16.2500
    same path, same corner, identical arrival — the mode changed the REQUIREMENT

arrival 3.4500 in both. Same path, same corner, same derate — the data takes exactly as long to arrive, because the silicon has not changed.

What changed is required: 4.8500 against 19.7000, from the 5 ns and 20 ns periods less their uncertainties. The slack goes from +1.4000 to +16.2500 without a single gate moving.

Those are two different mechanisms and it is worth not conflating them.

I first wrote this chapter with a single section claiming "the mode changed the requirement", comparing functional against scan capture. Running it showed required 4.8500 in both, because those two modes share a period and an uncertainty. The claim was false for that pair.

The two mechanisms separate cleanly once each is demonstrated with the pair that actually shows it:

Pair	What is identical	What differs
functional vs scan capture	period, uncertainty, requirement	the path set — 3 against 4
functional vs scan shift	the path's arrival, 3.4500	the requirement — 4.85 against 19.70

A mode can change either, both, or neither. Which one a given pair of modes differs in is a question about the declarations, not something to be reasoned out — and getting it wrong produces a plausible sentence that the output contradicts.

5. What a mode dict is, and what it is not

Being honest about the model, because this is where a teaching mock is furthest from a tool.

A mode in the mock above is a handful of scalars. A mode in a real flow is a constraint file — or a set of them — containing create_clock for every clock in that mode, set_input_delay and set_output_delay for every port, set_false_path and set_multicycle_path for every exception, set_case_analysis for the mode-select pins that put the chip into this mode at all, and set_clock_groups for whatever is asynchronous in it. All of Module 20, once per mode.

So the data structure's job is not to replace those files. It is to name them, locate them, and record what else the scenario needs:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

define_mode functional \
    -sdc        constraints/functional.sdc \
    -case       constraints/functional_case.tcl \
    -period     5.0 \
    -clocks     {core_clk io_clk} \
    -scan       0 \
    -owner      "timing team" \
    -reason     "normal operation at 200 MHz"

Three things that buys, and all three are familiar arguments:

The file is named once. Every scenario that uses this mode sources the same file, so two scenarios cannot silently disagree about what "functional" means — which is the one-source-of-truth argument from Chapter 23.6 applied to constraints.

The non-file data travels with it. -scan, -clocks and -period are what the driver needs in order to decide and report, and reading them out of a dict is cheap where re-parsing an SDC file is not.

-owner and -reason make the mode accountable. A mode nobody can justify is a mode that keeps being analysed long after the feature it tested was removed — the same review obligation as Chapter 23.2 §7's declared net list and Chapter 19.3's allowlist.

6. Reporting which mode produced a number

Every number that leaves an MCMM run must carry its mode, for the reason Chapter 26.1 established: a slack of +0.7500 means nothing without knowing what was being asked of the design.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

proc mode_header {name} {
    set m [dict get $::mcmm::modes $name]
    return [format "mode %s  period %.2f  clocks {%s}  scan %d" \
                $name [dict get $m period] [dict get $m clocks] [dict get $m scan]]
}

One line at the top of every report, generated from the same dict the analysis was configured from — so the header cannot disagree with what actually ran. That matters more than it sounds: a header written as a literal string in a template is a header that goes stale the first time the period changes, and then every report in the directory is confidently mislabelled.

Chapter 26.6 makes this the basis of traceability.

7. Exercises

Exercise 1. What is a mode, and what is identical across every mode of a design?

Exercise 2. Why does scan shift run at a longer period than functional?

Exercise 3. Why is scan shift's clock uncertainty larger?

Exercise 4. Why is the hold requirement the same in all three modes here?

Exercise 5. Why does the table print (none) rather than leaving the exceptions cell blank?

Exercise 6. Functional and scan capture have identical periods. What differs, and why does the scan chain not need timing in functional mode?

Exercise 7. Functional and scan shift time the same path with identical arrival. What differs?

Exercise 8. What is a mode in a real flow, and what is the data structure's job?

Exercise 9. Why is set_case_analysis the entry that makes a mode real?

Exercise 10. Why generate the report header from the mode dict rather than writing it into a template?

Answers.

1. One way the chip can be operating. The silicon is identical in every mode; what differs is the constraint under which it must work.

2. Because shift is thousands of cycles of pure data movement with no functional work to do, so there is no reason to run it fast.

3. Because the scan clock is usually distributed less carefully than the functional clock, so more margin is reserved for its uncertainty.

4. Because a hold requirement is a property of the capturing flip-flop rather than of the clock period. That is true in this design; a mode that changed the capture flop family or gated a clock could change it.

5. Because a blank cell is ambiguous between "none" and "nobody has considered it", and in a sign-off table that ambiguity is the problem being solved.

6. The path set — 3 paths against 4. The scan chain exists physically in functional mode but is not a path that has to work, because scan enable is deasserted and nothing is clocked through it.

7. The requirement: 4.8500 against 19.7000, from the two periods. Arrival is identical at 3.4500 because the silicon has not changed.

8. A constraint file or set of them — clock definitions, I/O delays, exceptions, case analysis, clock groups — effectively all of Module 20 once per mode. The data structure's job is to name and locate those files and carry the extra data the driver needs, not to replace them.

9. Because the chip enters a mode by a pin being held, not by a tool being asked. Without case analysis the tool times paths that cannot be active and misses the scan muxing — and the analysis completes with plausible numbers describing a state the chip is never in.

10. Because a literal header goes stale the first time the period changes, and then every report in the directory is confidently mislabelled. Generating it from the dict the analysis used means the header cannot disagree with what ran.

Remember.

A mode is one way the chip operates. The silicon is the same; the constraint differs.
Functional, scan shift and scan capture differ in period, clock uncertainty, which clocks run, and which exceptions apply.
A mode changes two separate things — which paths are timed and what the requirement is — and a given pair of modes may differ in either, both or neither.
Demonstrate which, don't reason it out. Functional vs scan capture: same requirement, 3 paths against 4. Functional vs scan shift: same arrival, 4.85 against 19.70.
An empty exception list is a statement; a missing key is not. Print (none).
A real mode is a constraint file, all of Module 20 once per mode. The dict names and locates it.
Carry -owner and -reason, so a mode that outlived its feature is visible.
set_case_analysis is what makes a mode real — without it the analysis describes a state the chip is never in, and nothing reports that.
Generate the report header from the mode dict, so it cannot go stale.

Where this fits

Part of the Tcl curriculum.