Why it matters

A week before tapeout someone asks whether the power-aware simulation ran with isolation enabled, and nobody can answer without rerunning it, because the result was filed without the power-intent revision. The manifest exists so that question never needs asking: every result names the exact inputs it used. On NanoSoC the inputs are small enough to list in full, which makes this lesson concrete; on a large chip the same rows apply with longer version strings.

The core idea

A manifest has four kinds of row. Versions name every input that can change a result: the RTL revision, the map version from the address-map table, the constraint set, the power-intent revision, the firmware image used in co-simulation, and the collateral revisions for each third-party block. Derived databases name what the flow produced from those inputs and what signoff actually analysed: the synthesised netlist, the final layout database with its checksum, the extracted parasitics, the library and technology-file revisions and the tool versions. Checks name every signoff analysis in tool-independent words: static timing across the corner and mode matrix, physical verification, power and isolation checks, crossing checks, connectivity, equivalence after every netlist change, gate-level simulation. Results attach each check to the revisions it ran against, with pass or fail and the date. And waivers record every excused violation with its owner, expiry and evidence, so an excuse is never just a comment in a log.

The difference between the first two kinds matters. Results from the front half of the flow (coverage, connectivity, crossing checks) name the RTL revision. Results from signoff (timing, physical verification, power on the netlist) run on the netlist, the layout and the parasitics, so they must name those too: a result tied only to RTL 214 does not identify the chip that was checked, and a checker that compares only RTL would pass with a different netlist or layout underneath.

The NanoSoC manifest in miniature shows the shape. Fifteen RTL blocks and the PLL macro each carry a revision, from the interconnect decoder to the reset controller; the map version stamps the headers, the decoder and the verification model together; the constraint set covers the three domains at 192, 96 and 24 MHz plus the asynchronous boundaries between them. The check rows mirror the dashboard disciplines of the third topic: timing, power, physical verification, crossings, verification coverage, connectivity, equivalence and gate-level simulation. Nothing here is new analysis; it is the index over analyses owned elsewhere, which is why the integrator can own it without owning any tool. All revision labels in this section (rev 214, map 7, netlist n88, layout gds-31) are illustrative.

NanoSoC as specified has no test logic, so its manifest has no DFT rows. A real chip with SRAMs adds scan, pattern and memory-test rows, plus power-grid IR and EM, ESD and antenna rows, each with an owner.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

# Every manifest row names its owner and the revisions it ran on.
# Revision labels are illustrative. A result is only evidence if every
# revision it names equals the baseline entry.
BASE = {"rtl": "214", "map": "7", "sdc": "12", "upf": "5",
        "netlist": "n88", "layout": "gds-31"}
rows = [
    # name, owner, revisions the row names
    ("rtl-top", "integrator", {"rtl": "214"}),
    ("address-map", "integrator", {"map": "7"}),
    ("constraints", "timing owner", {"sdc": "12"}),
    ("power-intent", "power owner", {"upf": "5"}),
    ("netlist", "implementation owner", {"netlist": "n88"}),
    ("layout", "implementation owner", {"layout": "gds-31"}),
    ("timing-result", "timing owner",
     {"sdc": "12", "netlist": "n88", "layout": "gds-31"}),
    ("connectivity-result", "integration", {"rtl": "214", "map": "7"}),
    ("isolation-result", "power owner", {"upf": "5", "netlist": "n88"}),
    ("waiver-014", "cdc owner", {"rtl": "214"}),
]

def problems(rows):
    bad = []
    for name, owner, revs in rows:
        if not owner or not revs:
            bad.append((name, "ownerless or unversioned"))
        for key, rev in revs.items():
            if BASE[key] != rev:
                bad.append((name, key, rev))
    return bad

assert problems(rows) == []

# inject two violations: a result on last week's netlist, an ownerless row
broken = list(rows)
broken[6] = ("timing-result", "timing owner",
             {"sdc": "12", "netlist": "n87", "layout": "gds-31"})
broken.append(("pv-result", "", {"layout": "gds-31"}))
found = problems(broken)
assert ("timing-result", "netlist", "n87") in found
assert ("pv-result", "ownerless or unversioned") in found
assert len(found) == 2, found
print("PASS: 10 rows owned and on baseline; stale netlist and ownerless row both caught")

What the review looks for

• Every check the dashboard shows has a manifest row with a revision, a result and a date.

• Every signoff result names the netlist and layout it ran on, not only the RTL.

• Every consumer of the map, headers, decoder and verification model, carries the same map version stamp.

• Every third-party block names its collateral revision: what arrived, what was checked, what was waived.

Verify and debug

Diff the manifest against the repository tags: any revision the manifest names must exist as a tag, and any tag newer than the manifest on a taped path is either in the manifest or the baseline moved without a record. The checker in the third lesson automates exactly this; by hand, start from the map version, because headers and the decoder disagree first and loudest.

Related topics

• Next: Freezing a Baseline

• Physical Design: Tapeout Checklist

• Physical Design: Revision Tagging and Reproducibility