Claude for Physical Design Engineers: AI-Assisted ASIC Implementation from Floorplanning to Signoff

---
name: power-planning-review
description: Audits ASIC power distribution networks (PDN), power rings, stripes, rails, vias, and power domain meshes for static/dynamic IR drop and EM compliance.
---

# Power Planning Review Skill

## Purpose
Analyzes ASIC Power Distribution Networks (PDN), verifying metal layer stack allocation, ring/stripe pitch, standard cell power rail connections, via arrays, and voltage domain isolation to prevent static IR drop and electromigration (EM) failures.

## When to Activate
Activate after macro placement and initial floorplanning, before standard cell placement, or when debugging power grid synthesis scripts.

## Required Input Files
- Power planning Tcl script (Innovus `addRing`, `addStripe` / ICC2 `create_pg_mesh`, `create_pg_std_cell_conn`)
- Technology LEF / Tech file (Metal layer sheet resistance $R_s$, max current density $J_{\max}$)
- Power domain specifications and supply voltages ($V_{DD}$, $V_{SS}$, multi-voltage rails)
- Early power budget estimates (Worst-case dynamic and leakage power)

## Step-by-Step Analysis Workflow
1. **Metal Stack Layer Allocation:**
   - Ensure top thick metals (e.g., M8/M9 or AP) carry global power distribution stripes to minimize $I \cdot R$ loss ($R_{	ext{thick}} \ll R_{	ext{thin}}$).
   - Verify intermediate metals (M4–M7) carry regional distribution stripes orthogonal to top metals.
   - Ensure bottom thin metal (M1) is strictly reserved for standard cell followpins/rails.
2. **Power Stripe Pitch & Width Calculation:**
   - Calculate stripe resistance: $R = R_s 	imes (L / W)$.
   - Verify grid density: Target PG metal utilization between 15% and 25% per routing layer to leave adequate tracks for signal routing.
3. **Standard Cell Rail & Via Array Integrity:**
   - Verify M1 rail width matches standard cell height pitch.
   - Confirm dense via arrays (stacked vias from top metal down to M1) are inserted at every orthogonal strap intersection.
4. **Power Domain & Voltage Area Isolation:**
   - Ensure separate power domains have independent PG meshes with dedicated boundary spacing.
   - Audit power switch cell (headswitch/footswitch) daisy chain and control grid connections.

## Tool-Specific Considerations
- **Cadence Innovus:** Uses `addRing`, `addStripe`, `sroute -connect {corePin padPin blockPin}`, `verifyPowerVia`.
- **Synopsys ICC2:** Uses `create_pg_mesh_pattern`, `set_pg_strategy`, `compile_pg`.

## Technical Limitations
- Claude cannot solve finite-element linear resistor matrices; quantitative static/dynamic IR drop and EM signoff require **Cadence Voltus** or **Synopsys RedHawk-SC**.

## Output Format
- **PDN Topology Summary:** Metal Layer | Direction | Width | Pitch | Resistance/um
- **Congestion vs IR Drop Assessment:** Trade-off analysis of PG blockage on signal routing.
- **Optimized Power Script:** Hardened Tcl script for grid construction.
- **Signoff Prerequisite Checklist:** Verification directives for Voltus / RedHawk.

## Validation Checklist
- [ ] Top metals carry primary global power currents.
- [ ] Via arrays placed at all strap intersections without DRC errors.
- [ ] Standard cell followpins continuously connected across rows.
- [ ] Sufficient routing resources remain for signal routing.

## Example Invocation
```text
/power-planning-review
Technology: TSMC N7
Voltages: VDD = 0.75V, VSS = 0.0V
Review this Innovus power mesh script for static IR drop feasibility:
[paste power_plan.tcl]
```

---
name: placement-optimization-review
description: Evaluates global and detailed placement, density maps, cell spreading, timing-driven optimization, and high-fanout net buffering in Innovus/ICC2.
---

# Placement Optimization Review Skill

## Purpose
Inspects post-placement Quality of Results (QoR), evaluating cell density distributions, global routing congestion maps, setup timing WNS/TNS, high-fanout nets (HFN), and scan-chain ordering before clock tree synthesis.

## When to Activate
Activate immediately after global/detailed placement and pre-CTS timing optimization (`place_opt_design` / `place_opt`).

## Required Input Files
- Placement log file (Innovus `place_opt_design.log` / ICC2 `place_opt.log`)
- Pre-CTS timing summary report (`report_timing -max_paths 50`)
- Global routing congestion summary / GRC report
- High-fanout net report (`report_net -min_fanout 32`)

## Step-by-Step Analysis Workflow
1. **Placement Density & Spreading Audit:**
   - Check local density hotspots: Identify regions where standard cell density exceeds 85%, which triggers detailed routing DRC explosion.
   - Recommend density bounds (`set_placement_status`, `create_density_constraint`).
2. **Congestion-Driven Placement Check:**
   - Inspect overflow metrics: Total Overflow (TOF) and Max Overflow (MOF).
   - If GRC overflow > 1.5%, identify whether root cause is macro proximity, pin clustering, or wide bus crossings.
3. **Timing-Driven Placement & Critical Path Clustering:**
   - Review pre-CTS WNS and TNS: Verify that launch/capture flip-flops on critical timing paths are physically clustered close together.
   - Detect long flylines on unbuffered high-fanout control nets.
4. **Buffer Insertion & Cell Sizing Sanity:**
   - Audit buffer explosion: Ensure the placement tool hasn't inserted tens of thousands of tiny delay buffers to fix timing in heavily congested channels.

## Tool-Specific Considerations
- **Cadence Innovus:** Uses `place_opt_design`, `setPlaceMode -congEffort high -timingEffort high`, `reportCongestion`.
- **Synopsys ICC2:** Uses `place_opt`, `set_app_options -name place.coarse.congestion_driven_max_util`, `report_congestion`.

## Technical Limitations
- Pre-CTS timing reports use ideal clock trees (zero insertion delay and zero skew); final timing depends on post-CTS clock skew synthesis.

## Output Format
- **Placement QoR Scorecard:** Total Cell Count, Max Density %, GRC Overflow %, Pre-CTS WNS/TNS.
- **Congestion & Timing Bottleneck Diagnosis:** Root cause of localized placement clusters.
- **Tcl Tuning Directives:** Tool commands to adjust cell padding, density limits, or net weights.

## Validation Checklist
- [ ] No legalizer cell overlaps (`checkPlace` clean).
- [ ] GRC overflow below 1.0% in all directions (H and V).
- [ ] High-fanout reset and scan nets properly identified and deferred to CTS.
- [ ] Critical path logic depth aligned with physical placement distance.

## Example Invocation
```text
/placement-optimization-review
Tool: Synopsys ICC2
Log: [paste place_opt.log summary]
Timing: Pre-CTS WNS = -420ps on 1.0ns clock
```

---
name: cts-report-analysis
description: Analyzes Clock Tree Synthesis (CTS) reports, evaluating clock skew, insertion delay, buffer sizing, clock gating setup/hold, and multi-corner clock latency.
---

# Clock Tree Synthesis (CTS) Report Analysis Skill

## Purpose
Diagnoses Clock Tree Synthesis (CTS) execution logs and reports from Cadence Innovus (ccopt) and Synopsys ICC2 (clock_opt), identifying clock skew imbalances, excessive insertion delays, duty-cycle distortion, and clock-gating timing violations.

## When to Activate
Activate after CTS implementation (`ccopt_design` / `clock_opt`) to evaluate clock tree quality before detailed signal routing.

## Required Input Files
- CTS summary report (`report_clock_trees`, `report_ccopt_skew_groups`, `report_clock_tree_summary`)
- Clock specification file / SDC constraints (`create_clock`, `set_clock_uncertainty`, `set_clock_latency`)
- Post-CTS timing report (`report_timing -delay_type min_max`)

## Step-by-Step Analysis Workflow
1. **Clock Skew Decomposition:**
   - Distinguish **Global Skew** (difference between maximum and minimum latency across the entire design) from **Local Skew** (latency difference between communicating flip-flop pairs).
   - Verify local skew is within budget (typically < 5%–10% of clock period).
2. **Insertion Delay & Clock Depth:**
   - Audit maximum insertion delay: Abnormally large insertion delay (> 1.5–2.0 ns on high-speed clocks) exacerbates on-chip variation (OCV) and derate penalties.
   - Check clock tree logic levels (number of buffer stages from root to leaf pins).
3. **Clock Inverter/Buffer Cell Selection:**
   - Ensure CTS strictly uses balanced clock inverters/buffers (`CLKINV_X4`, `CLKBUF_X8`) with symmetrical rise/fall slew rates to prevent duty cycle collapse.
4. **Clock Gating Checks (Integrated Clock Gaters - ICG):**
   - Check enable setup and hold timing on ICG cells (`EN -> CP`).
   - Ensure clock gaters are positioned close to their target load register clusters.
5. **Multi-Corner Clock Latency:**
   - Verify clock skew does not diverge severely between Early (fast/min) and Late (slow/max) timing corners.

## Tool-Specific Considerations
- **Cadence Innovus (CCOpt):** Uses `create_ccopt_clock_tree_spec`, `ccopt_design`, `report_ccopt_clock_trees -summary`.
- **Synopsys ICC2:** Uses `clock_opt`, `report_clock_qor`, `synthesize_clock_trees`.

## Technical Limitations
- Post-CTS timing reports use estimated interconnect routing parasitics; post-route extraction (SPEF) will introduce cross-coupling capacitance.

## Output Format
- **CTS Quality Scorecard:** Clock Name | Target Skew | Actual Skew | Min Latency | Max Latency | ICG Count
- **Root-Cause Anomaly Detection:** Skew outliers, long clock branches, high transition nets.
- **Tcl Optimization Script:** CCOpt / clock_opt constraint refinements (target skew, routing rules NDR).

## Validation Checklist
- [ ] Clock routing assigned to shielded double-width/double-spacing Non-Default Routing (NDR) rules.
- [ ] Local skew between critical timing paths meets SDC uncertainty budget.
- [ ] No regular standard cells mixed into CTS buffer inverter chains.
- [ ] ICG enable setup and hold slacks are positive.

## Example Invocation
```text
/cts-report-analysis
Tool: Cadence Innovus 22.1 (CCOpt)
Target Clock: clk_core (Period = 1.0ns)
Report: [paste report_ccopt_clock_trees.rpt]
```

---
name: routing-congestion-analysis
description: Analyzes global routing congestion, detailed routing DRC violations, track utilization, antenna violations, and routing detours in Innovus/ICC2.
---

# Routing & Congestion Analysis Skill

## Purpose
Diagnoses post-route DRC reports and global routing congestion (GRC) maps, categorizing metal shorts, spacing violations, via enclosure failures, antenna effects, and routing detours.

## When to Activate
Activate during or after global and detailed routing (`routeDesign` / `route_auto`) when resolving routing DRC clean-up.

## Required Input Files
- Routing log and summary report (Innovus `routeDesign.log` / ICC2 `route_auto.log`)
- Detailed routing DRC violation report (`checkRoute` / `check_lvs -drc`)
- Metal layer congestion statistics (% track utilization per metal layer)
- Process design rule constraints (LEF minimum area, spacing, notch rules)

## Step-by-Step Analysis Workflow
1. **DRC Violation Categorization:**
   - Parse total violation count into distinct classes: Metal Shorts, Min Spacing, Min Area, Via Overlap, Enclosure, Antenna.
2. **Spatial Hotspot Identification:**
   - Identify whether violations are randomly distributed (easy to fix via search-and-repair) or concentrated in localized clusters (indicates physical unroutable bottleneck).
3. **Layer-by-Layer Track Exhaustion:**
   - Check horizontal vs vertical metal utilization: If M3/M4 track utilization exceeds 90%, signal lines are forced to detour to upper layers, blowing timing.
4. **Antenna Rule Violations:**
   - Identify long metal traces connected directly to gate oxide without diode protection or metal jumpers to upper layers.
5. **Pin Accessibility in Advanced Nodes:**
   - In sub-10nm FinFETs, pin access is heavily constrained by colored EUV grids; verify standard cell pin access issues.

## Tool-Specific Considerations
- **Cadence Innovus:** Uses `routeDesign`, `setNanoRouteMode -drouteFixAntenna true`, `verifyGeometry`, `verifyConnectivity`.
- **Synopsys ICC2:** Uses `route_auto`, `route_detail -incremental true`, `check_routes`.

## Technical Limitations
- Automated routing analysis cannot visually display GDS polygons; physical sign-off DRC requires **Siemens Calibre nmDRC** or **Synopsys IC Validator (ICV)**.

## Output Format
- **DRC Category Breakdown Table:** Rule Name | Layer | Count | Severity | Root Cause
- **Hotspot Remediation Strategy:** Cell spreading, placement blockage widening, layer promotion.
- **Tcl Repair Directives:** Search-and-repair script commands and antenna diode insertion.

## Validation Checklist
- [ ] Zero metal shorts and zero open nets in design.
- [ ] Antenna violations eliminated via layer jumpers or reverse-biased diodes.
- [ ] Critical timing nets have direct routes without excessive serpentine detours.

## Example Invocation
```text
/routing-congestion-analysis
Tool: Cadence Innovus NanoRoute
Report: [paste verifyGeometry.rpt summary]
Total DRCs: 2,410 violations (mostly M2 spacing and Via1 enclosure)
```

---
name: setup-timing-debug
description: Performs root-cause analysis on negative setup slack (WNS/TNS) timing paths in PrimeTime, Tempus, Innovus, and ICC2.
---

# Setup Timing Debug Skill

## Purpose
Performs deep-dive engineering investigation of setup timing violations (max_delay), systematically deconstructing data arrival and required paths, logic depth, cell drive strengths, interconnect parasitics, and clock skew.

## When to Activate
Activate when analyzing post-placement, post-CTS, or post-route setup timing violations with negative slack.

## Required Input Files
- Full timing path report (`report_timing -nosplit -transition_time -capacitance -nets -attributes`)
- Target clock period and SDC constraints (`create_clock`, `set_clock_uncertainty`)
- Library operating corner (e.g., SSG 0.75V 125C worst-case setup corner)

## Step-by-Step Analysis Workflow
1. **Timing Path Topology Identification:**
   - Startpoint: Launch flip-flop, input port, or macro output.
   - Endpoint: Capture flip-flop data pin (D), output port, or macro input.
   - Launch & Capture clock domains and edge relationships (same-edge vs opposite-edge).
2. **Slack Equation Decomposition:**
   - $	ext{Slack} = 	ext{Data Required Time} - 	ext{Data Arrival Time}$.
   - $	ext{Data Arrival} = T_{	ext{launch\_latency}} + T_{	ext{CK}	o	ext{Q}} + T_{	ext{cell\_delay}} + T_{	ext{net\_delay}}$.
   - $	ext{Data Required} = T_{	ext{period}} + T_{	ext{capture\_latency}} - T_{	ext{setup}} - T_{	ext{uncertainty}}$.
3. **Bottleneck Component Isolation:**
   - **Cell vs Net Ratio:** Is delay dominated by cell switching (logic depth) or RC interconnect (long routing net / high capacitance)?
   - **Transition Violations:** Are cell delays inflated due to slow input slew rates?
   - **Drive Strength Sanity:** Are cells undersized (e.g., `X1` or `X2` driving long nets)?
   - **Clock Skew Effect:** Is clock skew hurting or helping slack?
4. **Remediation Strategy Formulation:**
   - Cell Sizing (`size_cell` to `X4`/`X8`).
   - Buffer Insertion (`insert_buffer` to split long resistive nets).
   - Logic Restructuring / Swapping to faster pin paths.
   - Useful Skew: Pushing capture clock latency later (if hold budget permits).

## Tool-Specific Considerations
- **Synopsys PrimeTime:** Uses `report_timing -delay_type max -input_pins`, `get_timing_paths`.
- **Cadence Tempus:** Uses `report_timing -late -view worst_setup`, `report_property`.

## Technical Limitations
- Setup fixes must never be committed without verifying that the changes do not introduce hold timing violations on fast corners (FFG 0.88V -40C).

## Output Format
- **Path Delay Breakdown Table:** Stage | Instance | Cell Type | Slew (ps) | Cap (fF) | Cell Delay | Net Delay | Running Total
- **Root-Cause Diagnosis:** Explicit explanation of what caused the negative slack.
- **Actionable Fix Prescription:** Exact Tcl ECO commands (cell resize, buffer insert, useful skew).
- **Secondary Impact Assessment:** Hold risk, area impact, dynamic power penalty.

## Validation Checklist
- [ ] Transition times at all intermediate nodes comply with max_transition constraints.
- [ ] No unconstrained paths or generated clock definition errors.
- [ ] Suggested cell resizing exists in target technology library.

## Example Invocation
```text
/setup-timing-debug
Tool: Synopsys PrimeTime 2023.12
Corner: SSG 0.675V 125C
Slack: -312ps on 1.25GHz clock
Report: [paste report_timing.rpt]
```

---
name: hold-timing-debug
description: Diagnoses and remediates hold timing violations (min_delay) across fast PVT corners without degrading setup slack or inducing congestion.
---

# Hold Timing Debug Skill

## Purpose
Investigates hold timing violations (min_delay), ensuring fast data paths cannot overwrite sequential flip-flop states before the required hold window elapses, prioritizing fixes at fast PVT corners.

## When to Activate
Activate during post-CTS and post-route timing closure, specifically when running STA on fast/hold corners (e.g., FFG 0.88V -40C).

## Required Input Files
- Hold timing path report (`report_timing -delay_type min -nosplit -transition_time -nets`)
- Library operating corner (e.g., FFG / Cbest / -40C fast corner)
- SDC hold uncertainty constraints (`set_clock_uncertainty -hold`)

## Step-by-Step Analysis Workflow
1. **Hold Equation Decomposition:**
   - $	ext{Slack}_{	ext{hold}} = 	ext{Data Arrival Time} - 	ext{Data Required Time}$.
   - $	ext{Data Arrival} = T_{	ext{launch\_latency}} + T_{	ext{CK}	o	ext{Q}} + T_{	ext{combinational\_min}}$.
   - $	ext{Data Required} = T_{	ext{capture\_latency}} + T_{	ext{hold}} + T_{	ext{hold\_uncertainty}}$.
   - Hold violations occur when data arrives *too quickly* ($	ext{Slack} < 0$).
2. **Root-Cause Identification:**
   - Zero logic depth: Direct flip-flop to flip-flop connections (`Q -> D`).
   - Clock skew anomaly: Capture clock arriving much later than launch clock due to CTS branch imbalance or long ICG insertion delay.
   - Corner disparity: Cell switching ultra-fast at cold temperatures (-40C) and high voltage.
3. **Remediation Strategy:**
   - Delay Buffer Insertion: Insert standard hold-fixing delay cells (e.g., `DLY1_X1`, `DLY2_X1`).
   - Placement Proximity Check: Ensure hold delay buffers are placed physically close to the capture flip-flop.
   - Setup Cross-Check: Mandate that inserting hold buffers does not turn positive setup slack negative on the worst-case slow setup corner!

## Tool-Specific Considerations
- **Synopsys PrimeTime:** Uses `fix_eco_timing -type hold -methods {insert_buffer}`.
- **Cadence Innovus:** Uses `optDesign -postRoute -hold`.

## Technical Limitations
- Indiscriminate hold buffer insertion causes standard cell density inflation and routing congestion; always prioritize high-resistance delay buffers on non-critical setup nets.

## Output Format
- **Hold Path Deconstruction:** Launch Latency, Capture Latency, Min Data Delay, Slack.
- **Buffer Insertion Plan:** Target net, proposed delay cell type, estimated delay addition.
- **Setup Hazard Safeguard:** Verification that setup margin on slow corner absorbs the added delay.

## Validation Checklist
- [ ] Hold verified on fast corner (FFG / Cbest / -40C).
- [ ] No hold buffers inserted on nets that are setup critical on slow corner (SSG / Cworst / 125C).
- [ ] Delay cell leakage power conforms to total power budget.

## Example Invocation
```text
/hold-timing-debug
Corner: FFG 0.88V -40C
Slack: -85ps WNS
Path: Direct register-to-register shift register path
Report: [paste report_timing_min.rpt]
```

---
name: sta-report-analysis
description: Decodes multi-corner, multi-mode (MCMM) Static Timing Analysis reports from Synopsys PrimeTime and Cadence Tempus, extracting WNS, TNS, and FEP.
---

# Static Timing Analysis (STA) Report Analysis Skill

## Purpose
Interprets comprehensive Multi-Corner Multi-Mode (MCMM) Static Timing Analysis summaries, analyzing Worst Negative Slack (WNS), Total Negative Slack (TNS), Failing Endpoints (FEP), and Design Rule Constraints (DRC) across all operating modes and process corners.

## When to Activate
Activate during timing closure milestones, tapeout readiness reviews, or signoff analysis.

## Required Input Files
- Global timing summary report (PrimeTime `report_qor` / Tempus `report_summary`)
- Multi-corner slack matrix (SSG, TT, FFG across Functional, Scan, BIST modes)
- DRC violation summary (Max Transition, Max Capacitance, Max Fanout)

## Step-by-Step Analysis Workflow
1. **MCMM Scorecard Compilation:**
   - Extract WNS, TNS, FEP, and Violating Paths for each active scenario (`mode.corner`).
2. **Dominant Corner & Mode Isolation:**
   - Identify whether timing violations are concentrated in a specific scenario (e.g., Functional.SSG_0p675v_125c vs ScanShift.FFG_0p88v_m40c).
3. **Design Rule Constraint (DRC) Audit:**
   - Check Max Transition violations: Slow edge rates increase cell delay and degrade noise margins.
   - Check Max Capacitance violations: Overdriven nets cause excessive dynamic power and reliability risks.
4. **Endpoint Clustering Analysis:**
   - Group failing endpoints by hierarchy/module to detect systematic architectural timing bottlenecks.

## Tool-Specific Considerations
- **Synopsys PrimeTime:** Uses `report_qor`, `report_constraint -all_violators`, `report_analysis_coverage`.
- **Cadence Tempus:** Uses `report_timing_summary`, `report_analysis_views`.

## Technical Limitations
- STA reports reflect static mathematical calculations based on SDC constraints; unconstrained or incorrectly false-pathed nets will not appear as violations.

## Output Format
- **MCMM Scenario Summary Matrix:** Mode | Corner | Setup WNS | Setup TNS | Hold WNS | Hold TNS | Max Tran Violators
- **Top 5 Bottleneck Modules:** Ranked by failing endpoint density.
- **Prioritized Action Plan:** Recommended optimization passes for ECO closure.

## Validation Checklist
- [ ] All clock domains and cross-domain paths analyzed.
- [ ] 100% timing path coverage (no unconstrained registers).
- [ ] SDC constraints verified clean via `check_timing`.

## Example Invocation
```text
/sta-report-analysis
Tool: Synopsys PrimeTime 2023.12
Report: [paste report_qor across 8 active corners]
```

---
name: timing-constraint-review
description: Audits Synopsys Design Constraints (SDC) for missing clocks, generated clock definitions, false paths, multicycle paths, and case analysis.
---

# Timing Constraint (SDC) Review Skill

## Purpose
Audits Synopsys Design Constraints (SDC) files for completeness and physical accuracy, detecting dangerous over-constraining, missing generated clocks, unconstrained interfaces, and unsafe false-path exceptions.

## When to Activate
Activate before synthesis, during floorplanning, and before final STA signoff to validate timing constraints.

## Required Input Files
- SDC constraints file (`.sdc`)
- Top-level clock specification and PLL documentation
- Chip boundary interface timing agreements (input delays, output delays)

## Step-by-Step Analysis Workflow
1. **Clock Definition Audit:**
   - Verify all primary oscillator inputs have explicit `create_clock` definitions with correct periods and waveforms.
   - Audit `create_generated_clock`: Ensure clock dividers, PLL outputs, and clock multiplexers have explicit generated clock definitions with accurate source pins (`-source`) and division/multiplication factors (`-divide_by`, `-multiply_by`).
2. **Clock Uncertainty & Latency:**
   - Check that `set_clock_uncertainty` includes both PLL jitter and clock tree variation margin.
3. **I/O Delay Constraints:**
   - Audit `set_input_delay` and `set_output_delay`: Verify reference clock names and max/min values account for PCB trace flight times.
4. **Timing Exceptions Audit (Critical):**
   - **False Paths (`set_false_path`):** Ensure false paths are only applied to verified asynchronous CDC paths (e.g., static configuration registers).
   - **Multicycle Paths (`set_multicycle_path`):** Verify that multicycle paths have matching hold multipliers (`-hold N-1`).

## Tool-Specific Considerations
- **Synopsys PrimeTime:** Uses `check_timing -verbose`, `report_exceptions`.
- **Cadence Innovus / Tempus:** Uses `check_timing`, `report_timing_exceptions`.

## Technical Limitations
- Constraint review cannot confirm PCB board-level trace lengths; I/O delays must be verified against system-level board timing specs.

## Output Format
- **Constraint Health Scorecard:** Primary Clocks | Generated Clocks | Unconstrained Endpoints | Active Exceptions
- **Risk Assessment:** Flagged unsafe false paths or missing clock dividers.
- **Refined SDC Directives:** Corrected syntax conforming to IEEE 1800-2023 / SDC 2.1.

## Validation Checklist
- [ ] `check_timing` produces zero unconstrained endpoints.
- [ ] All multicycle setup paths have corresponding hold multipliers.
- [ ] No internal clocks defined as independent primary clocks unless physically asynchronous.

## Example Invocation
```text
/timing-constraint-review
Review this top-level SDC file for a dual-PLL PCIe/DDR controller SoC:
[paste chip_top.sdc]
```

---
name: tcl-script-debugger
description: Debugs, refactors, and automates Tcl scripts for Cadence Innovus, Synopsys ICC2, PrimeTime, Tempus, and Calibre with verified syntax.
---

# Tcl Script Debugger & Automation Skill

## Purpose
Specialized EDA automation skill that inspects, debugs, and optimizes Tool Command Language (Tcl) scripts for commercial physical implementation and timing tools, ensuring correct object collection handling, error trapping, and high-performance execution.

## When to Activate
Activate when writing, debugging, or optimizing physical design automation scripts, custom report parsers, or flow-control hooks.

## Required Input Files
- Defective or target Tcl script
- Target EDA tool and version (Innovus, ICC2, PrimeTime, Tempus, Calibre)
- Error log or failure message generated during tool execution

## Step-by-Step Analysis Workflow
1. **Tool-Specific Command Vocabulary Verification:**
   - Verify commands match the exact syntax of the target tool (e.g., distinguishing PrimeTime `get_pins -of_objects` from Innovus `dbGet`).
2. **Object Collection vs List Manipulation:**
   - Detect common Tcl crash: treating an EDA collection (Synopsys `get_cells`, Cadence `get_db`) as a standard Tcl string list instead of using `sizeof_collection` or `foreach_in_collection`.
3. **Variable Expansion & Substitution Scrutiny:**
   - Audit bracket substitutions `[ ]` and quote escaping inside loops.
4. **Performance & Memory Optimization:**
   - Replace slow iterative string parsing with native tool attribute queries (`get_attribute`).
5. **Error Handling & Return Codes:**
   - Add `catch { ... } error_msg` blocks around non-fatal commands to prevent automated flow termination.

## Tool-Specific Considerations
- **Cadence Innovus:** Uses legacy `dbGet` / modern Common UI `get_db`.
- **Synopsys ICC2 / PrimeTime:** Uses collections (`get_cells`, `get_pins`, `foreach_in_collection`).
- **Siemens Calibre:** Uses Calibre Interactive batch Tcl directives.

## Technical Limitations
- Never invent proprietary command options; if an internal tool variable is unconfirmed, flag it explicitly.

## Output Format
- **Bug Diagnosis:** Exact line and explanation of Tcl runtime or syntax failure.
- **Corrected Tcl Script:** Production-ready code block with robust collection handling.
- **Performance Optimization Notes:** Explanation of speedups achieved.

## Validation Checklist
- [ ] Collections properly iterated using tool-specific iteration primitives.
- [ ] No bare file paths without existence validation.
- [ ] Compatible with both interactive terminal and non-interactive batch mode execution.

## Example Invocation
```text
/tcl-script-debugger
Tool: Synopsys PrimeTime 2023.12
Error: "Can't read collection element as string in foreach loop"
Script: [paste parse_violators.tcl]
```

---
name: drc-violation-analysis
description: Analyzes physical verification DRC violation logs from Siemens Calibre nmDRC and Synopsys ICV, mapping polygon errors to layout causes.
---

# Design Rule Check (DRC) Violation Analysis Skill

## Purpose
Categorizes and investigates physical verification Design Rule Checking (DRC) violation summaries from foundry signoff engines (Siemens Calibre nmDRC, Synopsys ICV), determining root causes in placement, routing, or filler cell insertion.

## When to Activate
Activate during physical verification signoff runs on post-routing and metal-filled GDSII/OASIS databases.

## Required Input Files
- Calibre DRC summary report (`calibre.drc.summary` / `drc.log`)
- Foundry design rule deck name and technology node (e.g., TSMC N5, GF 12LP)
- Physical layer affected (Base layers, FinFET fins, Poly, Contact, Via1–ViaN, Metal1–MetalTop)

## Step-by-Step Analysis Workflow
1. **Rule Deck Classification:**
   - Base Layer DRC: Poly pitch, active diffusion spacing, well proximity (typically caused by standard cell abutment or tap-cell gaps).
   - Metal Layer DRC: Minimum spacing, minimum area, wide-metal spacing, jog rules.
   - Via DRC: Enclosure rules, cut spacing, redundant via requirements.
   - Density & DFM DRC: Minimum/maximum metal density across moving windows.
2. **Systematic vs Random Failure Diagnosis:**
   - Check if a specific cell master or SRAM boundary accounts for thousands of repeated violations.
3. **Remediation Prescription:**
   - Route-level violations: Recommend NanoRoute / route_detail search-and-repair parameters.
   - Base-layer violations: Check boundary end-cap cells, well-tap spacing, or macro halo keepouts.
   - Metal Density: Adjust automated dummy metal fill scripts (`insert_metal_fill`).

## Tool-Specific Considerations
- **Siemens Calibre nmDRC:** Standard foundry signoff engine.
- **Synopsys IC Validator (ICV):** Synopsys integrated in-design signoff DRC.

## Technical Limitations
- Calibre DRC requires loading the GDSII layout into Calibre RVE or layout viewer (KLayout / Virtuoso) to inspect polygon coordinate geometries; Claude provides analytical triage.

## Output Format
- **DRC Violation Triage Matrix:** Rule Name | Category | Violation Count | Root Cause Category
- **Top Root-Cause Suspects:** Master cell abutment, routing channel starvation, via enclosure defect.
- **Remediation Roadmap:** Step-by-step PnR tool commands to fix in layout before rerunning Calibre.

## Validation Checklist
- [ ] Signoff verified using golden foundry-provided Calibre runset.
- [ ] Base layer DRC verified clean before metal fill insertion.
- [ ] Zero net-shorts or open connections.

## Example Invocation
```text
/drc-violation-analysis
Tool: Siemens Calibre nmDRC
Foundry: TSMC 16FFC
Report: [paste calibre.drc.summary excerpt]
Top violation: M2.S.1 (Metal 2 spacing violation: 1,840 instances)
```

---
name: lvs-debug-assistant
description: Decodes Layout Versus Schematic (LVS) mismatch reports from Siemens Calibre nmLVS, diagnosing shorts, opens, and device property discrepancies.
---

# Layout Versus Schematic (LVS) Debug Assistant Skill

## Purpose
Diagnoses physical verification Layout Versus Schematic (LVS) failure reports from Siemens Calibre nmLVS, isolating discrepancy points between the extracted GDSII netlist and the synthesized gate-level SPICE netlist.

## When to Activate
Activate when Calibre nmLVS reports "COMPARE RESULTS: NOT COMPARED" or "DISCREPANCIES FOUND" during tapeout verification.

## Required Input Files
- Calibre LVS summary report (`lvs.rep` / `calibre.lvs.summary`)
- Source gate-level netlist (`.v` or `.spi`)
- Power/Ground supply net names ($V_{DD}, V_{SS}$) and text label definitions

## Step-by-Step Analysis Workflow
1. **Initial Discrepancy Classification:**
   - **Net Shorts:** Multiple electrical nets merged into a single physical polygon.
   - **Net Opens:** A single electrical net physically broken into two isolated pieces.
   - **Unbalanced Pin / Port Count:** Missing top-level I/O text labels or mismatched port names.
   - **Component Parameter Mismatches:** Transistor channel width/length ($W/L$) or resistor values differing between schematic and layout.
2. **Text Label & Pin Attachment Audit:**
   - Verify top-level supply ports have text labels on the correct metal layer matching Calibre text-layer directives.
3. **Power/Ground Short Isolation:**
   - If $V_{DD}$ and $V_{SS}$ are reported shorted, locate the first shorted coordinate in the log to inspect standard cell tap abutments or macro power ring crossings.
4. **Subcircuit Reduction & Unmatched Instance Trees:**
   - Trace discrepancy trees to locate the true root-cause instance rather than downstream propagated symptoms.

## Tool-Specific Considerations
- **Siemens Calibre nmLVS:** Golden foundry signoff engine.
- **Cadence Pegasus LVS:** Cadence signoff LVS solution.

## Technical Limitations
- Calibre LVS coordinates must be highlighted in layout tools (Calibre RVE / Virtuoso / Innovus); Claude provides logical path deconstruction.

## Output Format
- **LVS Discrepancy Breakdown:** Shorts | Opens | Unmatched Instances | Unmatched Nets
- **Root-Cause Analysis:** Pinpoints the initial mismatch event that caused downstream net collapse.
- **Remediation Checklist:** Actionable layout and netlist corrections.

## Validation Checklist
- [ ] Calibre report states: "COMPARE RESULTS: COMPARED - ZERO DISCREPANCIES".
- [ ] Power and ground supplies unambiguously verified.
- [ ] No soft-shorts or floating well body contacts.

## Example Invocation
```text
/lvs-debug-assistant
Tool: Siemens Calibre nmLVS
Summary: "Net VDD shorted to Net VSS at coordinate (1420.5, 890.2)"
Report: [paste lvs.rep discrepancy section]
```

---
name: ir-drop-em-analysis
description: Analyzes static and dynamic voltage drop (IR drop) and electromigration (EM) violation reports from Cadence Voltus and Synopsys RedHawk-SC.
---

# IR Drop & Electromigration (EM) Analysis Skill

## Purpose
Interprets static and dynamic IR drop distributions and signal/power electromigration (EM) reports from signoff power analysis tools (Cadence Voltus, Synopsys RedHawk-SC), identifying power grid starvation and high-current hotspots.

## When to Activate
Activate during post-CTS and post-route power integrity signoff, or when diagnosing voltage drop induced timing failures.

## Required Input Files
- IR drop summary report (Voltus `report_ir_drop` / RedHawk `static_ir_summary`)
- Vectorless or VCD-driven dynamic power analysis configuration
- Supply voltage specifications and allowable drop threshold (e.g., $V_{	ext{drop}} \le 5\% 	imes V_{DD}$)

## Step-by-Step Analysis Workflow
1. **Static vs Dynamic IR Drop Classification:**
   - Static IR Drop: Caused by average DC current flowing through power grid resistance ($V = I_{	ext{avg}} \cdot R_{	ext{grid}}$). Indicates inadequate power straps or missing vias.
   - Dynamic IR Drop: Caused by instantaneous simultaneous switching current ($L \cdot di/dt + I_{	ext{peak}} \cdot R$). Indicates simultaneous clock tree buffer switching or high-activity datapath clusters.
2. **Power Mesh Resistance Mapping:**
   - Trace IR drop contours back to power pad / bump locations. Identify regions far from power bumps with high effective resistance ($R_{	ext{eff}}$).
3. **Electromigration (EM) Violation Audit:**
   - Signal EM: High-frequency clock nets driving high capacitive loads exceeding metal current density limits ($J_{	ext{rms}}, J_{	ext{avg}}$).
   - Power EM: Power stripes feeding large standard cell blocks carrying current exceeding electromigration lifespan thresholds.
4. **Remediation Plan:**
   - Static Fix: Add intermediate power stripes or increase via array density.
   - Dynamic Fix: Insert Decoupling Capacitance (Decap) standard cells adjacent to switching hotspots; stagger clock tree buffer trigger edges.

## Tool-Specific Considerations
- **Cadence Voltus:** Native signoff power integrity solution.
- **Synopsys RedHawk-SC:** Industry standard grid and dynamic IR signoff engine.

## Technical Limitations
- IR drop is highly sensitive to switching activity vectors; vectorless analysis is conservative, while VCD analysis depends strictly on testbench stimulus realism.

## Output Format
- **Power Integrity Scorecard:** Worst Static Drop (mV), Worst Dynamic Drop (mV), EM Violating Nets Count.
- **Hotspot Location Diagnosis:** Correlation with standard cell density and clock buffer trees.
- **Actionable Remediation Prescription:** Decap cell insertion guidelines and power strap reinforcement.

## Validation Checklist
- [ ] Peak dynamic IR drop within foundry voltage margin (typically < 5%–7% of nominal $V_{DD}$).
- [ ] Decap cells placed without causing excessive leakage current penalty.
- [ ] All signal and power metal lines conform to foundry EM limits for 10-year lifetime.

## Example Invocation
```text
/ir-drop-em-analysis
Tool: Cadence Voltus
Nominal VDD: 0.80V (Threshold: 5% = 40mV)
Report: [paste voltus_ir_drop.rpt]
Max Drop: 74mV in logic cluster near SRAM macro
```

---
name: eco-review
description: Plans and verifies Engineering Change Orders (ECO) for timing closure, DRC repair, and functional logic modification using spare gates.
---

# Engineering Change Order (ECO) Review Skill

## Purpose
Guides the formulation, review, and verification of Engineering Change Orders (ECOs) in late-stage physical design, evaluating timing ECOs, design-rule ECOs, and freeze-silicon metal-only functional ECOs using pre-placed spare gates.

## When to Activate
Activate during late timing closure, post-mask functional bug fixes, or when generating incremental physical implementation scripts.

## Required Input Files
- ECO intent: Timing fix (setup/hold), DRC fix, or Functional logic patch
- Pre-ECO vs Post-ECO netlist diff or ECO change description
- Available spare cell inventory (for metal-only ECOs)
- ECO Tcl commands (Innovus `ecoChangeCell`, `ecoAddRepeater` / ICC2 `eco_netlist`)

## Step-by-Step Analysis Workflow
1. **ECO Classification & Scope:**
   - **Post-Route Base-and-Metal ECO:** All silicon mask layers can be modified. Suitable for automated buffer insertion and cell resizing during timing closure.
   - **Metal-Only Freeze-Silicon ECO:** Base layers (diffusion, poly, contact) are frozen in fab; modifications are strictly restricted to metal routing layers (M1–MTop) using pre-instantiated spare cell gates (`SPARE_AND`, `SPARE_FF`).
2. **Logical Equivalence Checking (LEC) Verification:**
   - For functional ECOs, verify that golden modified RTL matches the ECO-patched netlist using **Cadence Conformal** or **Synopsys Formality**.
3. **Physical Impact & Disturbance Minimization:**
   - Confirm that ECO routing does not rip up critical timing-closed nets.
   - Verify that newly inserted cells are placed into legal filler cell gaps without shifting adjacent standard cells.
4. **Timing Re-Convergence:**
   - Verify that the ECO fixes the intended violation without causing secondary setup or hold failures on adjacent nets.

## Tool-Specific Considerations
- **Cadence Innovus:** Uses `ecoChangeCell`, `ecoAddRepeater`, `ecoRoute`.
- **Synopsys ICC2:** Uses `eco_netlist`, `route_eco`.
- **Formality / Conformal:** Mandated for formal equivalence signoff.

## Technical Limitations
- Metal-only ECOs depend strictly on physical proximity of spare gates; if no unused spare flip-flop exists within routing distance, a metal-only fix is physically impossible.

## Output Format
- **ECO Implementation Strategy:** Base-and-Metal vs Metal-Only assessment.
- **Verified Tcl ECO Script:** Precise commands to insert buffers, resize cells, or rewire spare pins.
- **Verification Signoff Checklist:** Formality/Conformal and incremental STA prerequisites.

## Validation Checklist
- [ ] Formal equivalence verified (LEC clean).
- [ ] Incremental STA verifies violation closed without side-effect slack degradation.
- [ ] Incremental DRC and LVS verify layout remains 100% clean.

## Example Invocation
```text
/eco-review
Type: Metal-Only Functional ECO
Goal: Invert signal 'data_valid' before entering FIFO using spare inverter 'spare_inv_inst_42'
[paste eco_script.tcl]
```

---
name: physical-design-run-comparison
description: Compares multi-run physical design implementation logs and QoR metrics across floorplan, placement, CTS, and routing iterations.
---

# Physical Design Run Comparison Skill

## Purpose
Compares physical implementation metrics across multiple PnR runs, floorplan variants, or synthesis revisions, systematically identifying regressions and improvements in timing (WNS/TNS), area, leakage, wirelength, and congestion.

## When to Activate
Activate when evaluating new floorplan options, testing aggressive optimization flags, or performing regression triage between design revisions.

## Required Input Files
- Run A vs Run B Quality of Results summaries (QoR reports from Innovus or ICC2)
- Timing summaries (WNS, TNS, FEP for setup and hold)
- Physical metrics (Core utilization, total cell count, wirelength, DRC count)

## Step-by-Step Analysis Workflow
1. **Key Metric Extraction:**
   - Timing: Setup WNS/TNS, Hold WNS/TNS, FEP count.
   - Physical: Standard cell area, macro area, total wirelength, via count.
   - DRC & Congestion: Max GRC overflow %, total DRC count.
   - Power: Total dynamic power (switching + internal), leakage power.
2. **Delta Calculation & Trend Analysis:**
   - Calculate exact $\Delta$ values ($	ext{Run B} - 	ext{Run A}$) and percentage shifts.
3. **Regression Root-Cause Isolation:**
   - If timing improved but wirelength and routing DRCs exploded, identify whether over-buffering or cell clustering caused localized congestion.
   - If leakage jumped significantly, check high-drive cell or low-Vt cell substitution rates.
4. **Actionable Go/No-Go Decision:**
   - Synthesize a clear engineering verdict on whether Run B represents a net improvement for the project milestone.

## Tool-Specific Considerations
- Compatible with all major PnR platforms (Cadence Innovus, Synopsys ICC2).

## Technical Limitations
- Metric comparison identifies *what* changed; root-cause diagnosis requires drilling down into specific failing timing paths or congestion hotspot coordinates.

## Output Format
- **Executive Comparison Matrix:** Metric | Run A (Baseline) | Run B (Candidate) | Absolute Delta | % Change | Trend Icon
- **Regression Analysis:** Detailed narrative of trade-offs (e.g., timing gain vs area cost).
- **Go / No-Go Recommendation:** Clear guidance for flow integration.

## Validation Checklist
- [ ] Both runs evaluated under identical SDC constraints and operating corners.
- [ ] Extraction mode and tool versions aligned to prevent apples-to-oranges comparisons.

## Example Invocation
```text
/physical-design-run-comparison
Baseline: Run_42_Base_Floorplan
Candidate: Run_43_Widened_Channel_Floorplan
[paste summary reports for both runs]
```