Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutRoadmapCareersInternshipsFAQContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • The NanoSoC Tour
  • Reading Path
  • SoC Glossary10
  • SoC Metrics Reference
  • SoC Cheatsheet
  • What SoC Integration Is12
  • Architecture and Budgets21
  • Memory Maps and Address Decode26
  • Interconnect and Bus Fabrics26
  • Clock and Reset Architecture24
  • Power Architecture21
  • Interrupts, DMA and Peripherals15
  • Memories, Boot and Security21
  • IP Integration and Handoff21
  • Top-Level Verification and Bring-up21
  • Package, Pads and I/O18
  • Chip Signoff and Tapeout18
    • The Signoff Manifest
    • Waiver Governance
    • Closure Dashboards
    • Tapeout Readiness Review
      • Evidence per Owner
      • Go and No-Go
      • Last-Week Surprises
    • ECO and Respin Risk
    • Errata and Post-Silicon
  • SoC Interview Prep16
  • Capstone: Integrate NanoSoC14
Loading lesson

←Tapeout Readiness Review
  1. Topics
  2. SoC Design
  3. Chip Signoff and Tapeout
  4. Tapeout Readiness Review
  5. Evidence per Owner
On this page

    Part 12 of 14, lesson 10 of 18Part 12 of 14/Chip Signoff and Tapeout/Lesson 10 of 18All levels

    Evidence per Owner

    What timing, power, physical, crossings, verification, software and package each must bring, as a template.

    Why it matters

    Every failed review fails the same way: an owner presents effort instead of evidence, the room debates the summary, and the decision rests on confidence rather than checks. The fix is a standing list of what each owner brings, in what form, against which baseline, published before the meeting so gaps are found by the checklist rather than by argument. This lesson is that list for NanoSoC. Its one job is the inputs; the rule applied to them is next.

    The core idea

    Each owner brings results on the signoff candidate, never summaries. A real chip's owners bring the artefacts below. NanoSoC as specified defines the budgets and the reset and power sequences but no corner set, no layout results and no package or ballout (the pads and the crystal sit outside the top), so the matrix is a template listing the artefact each owner would attach, with the NanoSoC figures to check wherever the course defines them.

    • Timing brings worst slack per corner and mode with the exception review signed; for NanoSoC that means the 192, 96 and 24 MHz domains and the asynchronous boundaries between them, with the corner list coming from the process (illustrative here).

    • Power brings intent-clean reports plus the power-aware simulation that switched the domain off and back, covering the 2.917 us power-down and the 14.073 us wake.

    • Physical brings the DRC and LVS counts with waived cells listed (a real chip's artefact; the course defines no layout results).

    • Crossings bring zero opens against the ten-group inventory, the reset order among them.

    • Verification brings the top-level coverage with the boot to 12.581 ms, the 64-word DMA self-test, the interrupt latency bounds of 135.4 to 182.3 ns, and the power-state walk all passing.

    • Software brings the driver rules the results depend on: start with 0x3, clear both DONE and ERR, wait while busy before touching length or key.

    • Package and board bring the ballout, the reset-state pin table and the power sequence the silicon will actually see (template row: for NanoSoC the attachable artefacts are the reset and power sequences).

    example.py
    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
    43
    44
    45
    46
    # The evidence matrix: every owner has a row, every row names the
    # candidate and the artefact. Missing, stale or summary-only rows are
    # refused. Candidate labels are illustrative.
    CAND = "214/n88/gds-31"          # rtl / netlist / layout of the signoff candidate
    OWNERS = ["timing", "power", "physical", "crossings", "verification",
              "software", "package-board"]
    
    def refused(evidence):
        out = []
        names = [row[0] for row in evidence]
        for owner in OWNERS:
            if owner not in names:
                out.append((owner, "no row"))
        for owner, artefact, cand, present in evidence:
            if not present:
                out.append((owner, "absent"))
            elif not artefact:
                out.append((owner, "summary without artefact"))
            elif cand != CAND:
                out.append((owner, "stale"))
        return out
    
    draft = [
        ("timing", "slack+exceptions", CAND, True),
        ("power", "intent+pa-sim", CAND, True),
        ("physical", "drc+lvs", "214/n87/gds-30", True),   # old candidate
        ("crossings", "cdc+rdc zero", CAND, True),
        ("verification", "coverage+must-pass", CAND, True),
        ("software", "driver rules signed", CAND, False),   # not delivered
    ]                                                       # package-board missing
    assert refused(draft) == [("package-board", "no row"),
                              ("physical", "stale"),
                              ("software", "absent")], refused(draft)
    fixed = [
        ("timing", "slack+exceptions", CAND, True),
        ("power", "intent+pa-sim", CAND, True),
        ("physical", "drc+lvs", CAND, True),
        ("crossings", "cdc+rdc zero", CAND, True),
        ("verification", "coverage+must-pass", CAND, True),
        ("software", "driver rules signed", CAND, True),
        ("package-board", "pin-states+power-sequence", CAND, True),
    ]
    assert refused(fixed) == []
    assert refused(fixed[:-1] + [("package-board", "", CAND, True)]) == [
        ("package-board", "summary without artefact")]
    print("PASS: draft refused on 3 rows; fixed matrix has 7 owners, 7 artefacts")

    What the review looks for

    • The matrix above, filled, published a day before the meeting, with every artefact retrievable from the manifest.

    • No row whose artefact is a slide: waveforms, logs, signed exception lists, or it does not count.

    • Software evidence present even though software is not taped: the results depend on driver rules, so the rules are evidence.

    Verify and debug

    Audit one artefact per owner before the meeting: open the timing exception list and read three entries against the RTL, replay the wake sequence from the power log, check the interrupt latency numbers against the 135.4 and 182.3 ns bounds. Audits done early turn the meeting into confirmation; audits skipped turn it into discovery, which is the most expensive place to discover anything.

    Trim and fuse data loaded late: analog trim not loaded before it is needed, so the start-up sequence the review approved never ran in the order silicon will run it. The package-board and power rows exist to catch exactly this: the sequence evidence must cover loading order, not just final values.

    If asked what you demand from each owner, recite the artefact, not the person: slack with exceptions, intent with switching sim, counts with waived cells, zero against inventory, coverage with must-pass tests, signed driver rules, ballout with pin states. Say which of those your chip really has.

    Check yourself Verification brings 100 percent block coverage but the top-level boot test ran on last month's RTL. Pass?

    No. Block coverage is the wrong artefact and the boot test is stale. The row needs top-level coverage with must-pass tests on the frozen baseline; anything else is effort, not evidence.

    Related topics

    • Next: Go and No-Go

    • Verification: The Tape-Out Review

    • Verification: Sign-Off Criteria

    Previous

    241 / 289

    Next: Go and No-Go

    Up next

    Up nextGo and No-Go

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • Last-Week Surprises