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
      • The Metrics That Matter
      • Building the Dashboard
      • Reading the Trend
    • Tapeout Readiness Review
    • ECO and Respin Risk
    • Errata and Post-Silicon
  • SoC Interview Prep16
  • Capstone: Integrate NanoSoC14
Loading lesson

←Closure Dashboards
  1. Topics
  2. SoC Design
  3. Chip Signoff and Tapeout
  4. Closure Dashboards
  5. The Metrics That Matter
On this page

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

    The Metrics That Matter

    One honest metric per discipline across timing, power, physical, crossings, coverage and connectivity.

    Why it matters

    A dashboard with forty metrics is wallpaper: nobody reads it, so nobody notices when one turns. The integrator needs one headline metric per discipline that is hard to make green while the chip is broken, plus the rule that keeps each honest. On NanoSoC the numbers are small and checkable, which makes this lesson the reference for what each discipline owes the dashboard.

    The core idea

    Eight disciplines report. Timing reports worst slack across the corner and mode matrix with all exceptions reviewed: green means no negative slack and no unreviewed exception, because an unreviewed false path is a wrong timing exception waiting to happen. Power reports the intent checks clean: all 114 isolation cells present and enabled in the right order, retention lists complete, in a power-aware simulation that actually switched the domain off. Physical verification reports zero open DRC and LVS violations outside waived cells. Crossings report zero open CDC and RDC violations, structural, with the synchroniser inventory matching the ten crossing groups of NanoSoC. Verification reports functional coverage of the top-level plan with the boot, interrupt, DMA and power-state tests passing on the frozen baseline. Connectivity reports the master-slave reachability matrix and the tie-off audit clean, including the check that the deliberate DMA alias is documented and that no header addresses an alias image. Equivalence reports every netlist revision proven equivalent to the RTL, the last ECO included. Gate-level simulation reports the boot, the DMA self-test and the power-state walk passing on the current netlist.

    No metric here is ungameable: the last column of the table shows the usual way each is made to look green when it is not, and the rule in the third column is what keeps it honest.

    Discipline

    The metric

    Green means

    Dishonest green looks like

    Timing

    Worst slack, exceptions reviewed

    No negative slack, every exception evidenced

    A false path covering a real path

    Power

    Intent checks plus power-aware sim

    114 clamps present, order proven in sim

    Static checks only, domain never switched in sim

    Physical

    Open DRC and LVS count

    Zero outside waived cells

    Waived cells nobody re-checked

    Crossings

    Open CDC and RDC count

    Zero, inventory matches the ten groups

    Synchronisers the checker cannot see, unlisted

    Verification

    Top-level coverage plus must-pass tests

    Boot, IRQ, DMA, power walk green on baseline

    Coverage on last month's RTL

    Connectivity

    Reachability plus tie-offs

    Reachability matrix and tie-off audit clean; the 16-image DMA alias documented and no driver or header uses an image other than the first

    Tests that only touch the alias images, or a matrix that skips the DMA window

    Equivalence

    Netlist revisions proven against RTL

    Every netlist revision proven, last ECO included

    Equivalence run on the previous netlist

    Gate-level sim

    Boot, DMA self-test, power walk on the netlist

    All three pass on the current netlist

    Run on an older netlist, or with the power-down step skipped

    The budgets the dashboard is compared with

    A signoff dashboard compares measured results with budgets. The NanoSoC teaching budgets are 82.74 mW in RUN, a 0.655 mm2 core, interrupt latency of 135.4 to 182.3 ns for the irq_dma path, hardware reset in 53.948 us and a 12.581 ms boot with the SPI load owning 86.9 percent of it. These are teaching estimates, not measurements, and the area is a floorplan input rather than a signoff outcome. A signoff report that exceeds a budget goes red until a waiver or an approved budget change moves it.

    What the review looks for

    • Each discipline shows its one metric with the evidence link: the result row in the manifest, on the frozen baseline.

    • Every amber names its owner and its date to green; every green built on waivers names the waiver count.

    • No metric is green on a stale baseline: the dashboard carries the baseline tuple on its face.

    Verify and debug

    Pick one green per week and reproduce it from the baseline: rerun the fastest check in that discipline and compare. Reproduced greens build trust in the rest; a green that cannot be reproduced demotes the whole dashboard to amber until the process is fixed. Start with connectivity, because the map checker runs in milliseconds.

    Missing isolation is caught by power-aware simulation showing X on the always-on side. In NanoSoC the case is 112 of 114 clamps present, the two interrupt lines missed, so the interrupt output turns spurious on entering sleep. A power metric built on static checks alone stays green straight through this failure; that is why the metric demands the switching simulation.

    If asked which metric you watch most closely in the last month, answer crossings and exceptions: timing and physical close visibly, while a late false path or a re-timed synchroniser hides inside a green until silicon. Say what you do about it: the weekly reproduce-one-green habit.

    Check yourself Power is green but the power-aware simulation never switched the domain off. What colour is power really?

    Red, or amber at best. The metric requires the switching simulation; static intent checks without it are the dishonest green in the table.

    Related topics

    • Next: Building the Dashboard

    • Physical Design: Closure Metrics Dashboard

    • Physical Design: Timing Signoff Dashboard

    Previous

    238 / 289

    Next: Building the Dashboard

    Up next

    Up nextBuilding the Dashboard

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • Reading the Trend