QoR Dashboard & Trend Triage: Theory Deep Dive

Foundational theory

QoR Dashboard & Trend Triage is a core part of Constraints & QoR. QoR closure is a trend-management problem: dashboard baselines catch regressions early and keep optimization decisions tied to measurable outcomes. Senior synthesis engineers connect every QoR claim to constraint context, compile setup, and reproducible artifacts.

Core concepts explained

• QoR closure is a trend-management problem: dashboard baselines catch regressions early and keep optimization decisions tied to measurable outcomes.

• Primary metric: WNS/TNS trend, area delta, dynamic/leakage trend, compile runtime

• Primary artifact: QoR dashboard snapshot, baseline diff, closure memo

• Owners: synthesis lead, program owner, STA owner

• Compare timing, area, and power together

• Preserve run manifest for every regression jump

Why this matters at closure

At tapeout pace, QoR Dashboard & Trend Triage decisions can either shorten closure loops or create hidden debt. QoR quality starts with clean synthesis constraints and policy hygiene.

Mental model

QOR DASHBOARD
timing lane : WNS / TNS / endpoint count
area lane   : cell area / buffer %
power lane  : dynamic / leakage / clock %
runtime lane: compile time / memory

Worked intuition

1. Freeze RTL tag, constraint tag, and compile switches.

2. Open WNS/TNS trend, area delta, dynamic/leakage trend, compile runtime and isolate the first meaningful regression.

3. Classify whether issue is constraints, mapping transform, or physical estimate.

4. Collect QoR dashboard snapshot, baseline diff, closure memo and owner signoff evidence.

5. Pick minimal reversible fix and define rollback criteria.

6. Run timing + power + area regression matrix before merge.

Common misconceptions

• Better WNS always means better overall QoR.

• dont_touch is harmless if timing still passes.

• Retiming gain is free and always safe for formal.

• Topographical estimates are equivalent to signoff route outcomes.

Visual reinforcement

QoR dashboard lanes

QOR DASHBOARD
timing lane : WNS / TNS / endpoint count
area lane   : cell area / buffer %
power lane  : dynamic / leakage / clock %
runtime lane: compile time / memory

Layer responsibilities

SYNTHESIS OWNERSHIP LAYERS — QoR Dashboard & Trend Triage

layer               owns                          failure mode
----------------    ---------------------------   -------------------------
constraints         clocks/exceptions/policy      fake QoR optimism
mapping             cell choices/structure        depth/fanout regressions
optimization        timing/power tradeoffs        one-metric overfitting
physical-aware      topo/congestion estimates     handoff delta surprises
closure             ECO order/regression          fixes break other corners

Synthesis deep dive

Constraint hygiene determines whether synthesis QoR is trustworthy.

Concept diagram

CONSTRAINT FLOW

RTL intent -> synthesis SDC -> compile checks -> QoR dashboard -> review gate

Metric graph

QOR HEALTH

constraint lint pass   ███████████████
unconstrained count    ███
policy violations      ██

Reports and artifacts

• compile QoR

• unconstrained endpoints

• constraint lint

• policy audit log

Mini case study

Nightly WNS improved but unconstrained paths jumped; strict SDC lint restored true QoR picture.

Debug branches

• Diff SDC first

• Audit dont_touch scope

• Track unconstrained trend weekly

Senior review question

Ask: what evidence proves this QoR move is real and stable?

Key takeaways

• State exact run context (RTL, SDC, libs, switches) with every QoR claim.

• Re-run timing, area, and power regressions after each synthesis ECO.

Common pitfalls

• Comparing runs with mismatched constraints or library views.

• Timing-only fixes that violate power or area budgets.

• Skipping equivalence checks after structural changes.

Theory reinforcement

QoR quality starts with clean synthesis constraints and policy hygiene.