Your complete playbook for using Claude in Physical Design — from floorplanning strategy and power grid design to CTS constraints, routing DRC debug, IR drop analysis, and Innovus/ICC2 Tcl scripting.
| Task | Claude Quality | Notes |
|---|---|---|
| Floorplan strategy guidance | Excellent | Macro placement, aspect ratio, power domain partitioning |
| Innovus / ICC2 Tcl scripting | Excellent | Full flow scripts, CTS spec, placement constraints |
| Power grid design recommendations | Good | Strap width, pitch, layer assignment — confirm with EM/IR tools |
| DRC violation explanation | Good | Explains rule classes; needs your PDK rule name for specifics |
| IR drop analysis interpretation | Good | Explains hotspots, suggests grid improvements |
| Placement constraint generation | Good | Fence, region, soft guide constraints |
| Congestion analysis and fixing | Good | Routing hotspot strategies, cell spreading |
| Predict actual wire length/area | Poor | Cannot replace PnR tool — no access to layout geometry |
Act as a senior physical design engineer. Help me plan the floorplan for this design. Design specs: - Technology: 7nm FinFET, 12-track standard cell library - Die area: 4mm x 4mm (target utilization 70%) - Hard macros: 4x SRAM_256KB (each 800um x 600um), 2x USB_PHY (200um x 400um) - Power domains: VDD_CORE (1.0V), VDD_IO (1.8V), VDD_MEM (0.9V) - Top-level blocks: CPU_CORE, GPU_CORE, DDR_CTRL, USB_CTRL, PMIC_IF - I/O ring: full peripheral I/O, 180 pins Give me: 1. Recommended die aspect ratio and why 2. Macro placement strategy (which macros near which edges and why) 3. Power domain boundary recommendations (minimize level-shifter crossings) 4. I/O pad ring partitioning (which signals on which sides) 5. Abutment recommendations (which blocks should share boundaries) 6. Top 3 floorplan risks for this design
Write an Innovus Tcl script for floorplan initialization and macro placement. Design: soc_top Die area: 4000um x 4000um Core utilization: 70% Core margin: 20um all sides Macros to place: - u_sram_0 (SRAM_256KB): top-left corner, 50um from boundary - u_sram_1 (SRAM_256KB): top-right corner, 50um from boundary - u_sram_2 (SRAM_256KB): bottom-left corner, 50um from boundary - u_sram_3 (SRAM_256KB): bottom-right corner, 50um from boundary - u_usb_phy_0 (USB_PHY): left edge, center vertically - u_usb_phy_1 (USB_PHY): right edge, center vertically Generate Innovus Tcl commands for: 1. floorPlan initialization (initFloorplan) 2. Macro placement (placeInstance -fixed) 3. Macro halo creation (createHalo) — 5um halo around each macro 4. Row creation after macro placement 5. Verify placement (checkPlace)
Design the power grid for my chip. Design specs: - Technology: 12nm FinFET - Total power: 2.5W at 1.0V core - Die area: 3mm x 3mm - IR drop budget: 30mV max (3% of VDD) - Available metal layers for PG: M5–M9 (M10 = top-level chip grid) - Sheet resistance: M5=0.04 ohm/sq, M7=0.025 ohm/sq, M9=0.015 ohm/sq Recommend: 1. Strap width and pitch for each metal layer (M5, M7, M9) 2. Estimated IR drop contribution per layer 3. Via stack strategy between layers 4. Ring width at core boundary 5. Macro power ring dimensions 6. Innovus Tcl commands: addStripe, addRing for the top two layers 7. How to check EM (electromigration) constraint on power straps
Analyze this IR drop report and recommend power grid improvements. IR drop summary: - Average IR drop: 18mV (budget: 30mV) - Peak IR drop: 52mV — VIOLATION at block u_cpu_core/u_alu - Hotspot location: center of ALU block, 1.2mm from nearest strap - Metal layers with highest resistance: M5 horizontal straps Contributing factors reported by tool: - M5 strap pitch: 80um (current spec) - Via resistance: 2 ohms per via stack (M5-M7) - ALU switching current: 45mA peak Questions: 1. What is causing the hotspot specifically? 2. Should I add more M5 straps, increase M5 width, or add M7 straps? 3. What strap pitch would bring peak IR below 30mV? 4. Is a dedicated local power ring around the ALU block worth it? 5. What Innovus commands add targeted straps in the hotspot region?
Write Innovus placement constraint Tcl commands for these requirements. Constraints: 1. u_crypto_core must be placed in a hard fence: region (200um, 200um) to (800um, 600um) No other cells allowed inside this fence 2. u_dsp_array: soft region guide (1000um, 500um) to (2500um, 1500um) Cells prefer this region but can overflow 3. u_rf_analog: keep-out zone for digital cells 300um buffer around macro u_adc_0 4. u_scan_ctrl: placed near scan test pads (bottom-left corner) Distance from bottom edge: < 200um 5. All clock buffers in clock domain CLK_FAST: restrict to M3 layer only No routing above M3 for this clock tree Generate: createFence, createRegion, createGuide, createPlacementBlockage, setPlacementConstraint commands with correct syntax.
I have routing congestion overflow in one region. Help me debug and fix it. Congestion details: - Hotspot location: (1500um, 800um) to (1800um, 1100um) - Overflow: 18% on M4 horizontal, 12% on M3 vertical - Cell density in that region: 85% - Cause reported by tool: high fanout bus u_bus_ctrl/data_bus[63:0] passing through Steps I want you to walk me through: 1. Is this a placement-driven or routing-driven congestion? How to distinguish? 2. What are the top 3 methods to reduce this overflow? - Method A: cell spreading / density reduction - Method B: layer promotion (route on M5 instead of M4) - Method C: bus rerouting / detour 3. What Innovus commands reduce cell density in that region? 4. How do I set a maximum density constraint to prevent future congestion? 5. At what overflow percentage should I stop and replan vs continue routing?
Explain these DRC violations from my Calibre DRC report and suggest fixes. Violations (top 3 by count): 1. Rule M4.S.1 — Metal 4 minimum spacing: 280 violations Error: two M4 wires are 0.058um apart; minimum is 0.064um 2. Rule VIA3.ENC.1 — Via3 enclosure by M3: 45 violations Error: via not fully enclosed by M3 metal on one side 3. Rule M2.W.1 — Metal 2 minimum width: 12 violations Error: narrow M2 segment 0.028um wide; minimum is 0.032um For each violation: 1. What causes this type of DRC in PnR context? 2. Can the router auto-fix this, or does it need manual ECO? 3. What Innovus routing options reduce this DRC class? 4. Which violations risk silicon reliability (EM, reliability) vs just geometric? 5. What is the priority order for fixing these three? Also: What Innovus command re-runs detail routing only in the DRC hotspot area?
Help me debug this LVS mismatch from Calibre LVS. LVS error summary: - 3 unmatched nets in schematic vs layout - Net "u_pll/vco_bias" present in schematic, missing in layout extraction - Net "VDD_ANA" shorted to "VDD_DIG" in layout (not in schematic) - Instance "u_pll/M_BIAS1" (NMOS) — gate connection differs: schematic=NET_A, layout=NET_B For each error: 1. What is the most likely physical cause? - Missing net: open via, incomplete routing, wrong pin name in LEF? - Short: accidental metal overlap, missing cut layer? - Wrong connection: pin name mismatch in LEF vs CDL? 2. What Virtuoso/Innovus command helps locate the physical location of the error? 3. How do I fix without re-running full LVS? 4. Which error is most likely a real silicon bug vs a tool/database issue?
My setup WNS was -0.05ns after placement and degraded to -0.42ns after CTS. Help debug. Post-CTS observations: - Clock skew on CLK_CORE: 180ps (was 0 during pre-CTS ideal clocks) - Clock insertion delay: 850ps - 12 paths now failing that were clean before CTS - Failing paths all have capture FF in clock skew group CG_FAST (high skew) Analysis questions: 1. Is 180ps skew high for 1 GHz at 7nm? What is a typical target? 2. Why does real clock skew cause more failures than ideal clock (post-CTS regression)? 3. Which clock skew group (CG_FAST) is causing the most failures — what does that mean? 4. What CTS properties/constraints would reduce skew in CG_FAST? 5. Should I re-run placement after CTS (post-CTS optimization) or just tune CTS? 6. Innovus Tcl: how to re-run optDesign with -postCTS flag only on failing paths?
Write Innovus Tcl commands for filler cell and well-tap insertion. Library cells available: - Fillers: FILL1, FILL2, FILL4, FILL8, FILL16, FILL32, FILL64 - Well taps: WELLTAP_X2, WELLTAP_X4 - Decap fillers: DCAP4, DCAP8, DCAP16 (decoupling capacitance) Requirements: 1. Insert well taps every 25um (max distance per DRC rule) 2. Fill all gaps in standard cell rows with fillers 3. Prioritize DCAP cells in high-switching regions (provide list: u_alu, u_mac) 4. Verify no DRC after insertion 5. Report: total filler count, decap coverage percentage Generate: addWellTap, addFiller, verifyConnectivity Innovus commands. Also explain: why is well-tap maximum distance a DRC rule in FinFET nodes?
Walk me through the Physical Implementation ECO flow for a functional bug fix. Bug fix: An AND gate (AND2_X2) at u_ctrl/U_AND_47 needs to be changed to OR gate. This is a late-stage ECO — GDS is nearly complete. Steps: 1. What are the three ECO implementation approaches? A. ECO in PnR tool (Innovus ecoChange) B. Metal-only ECO (MOE) — only change upper metal layers C. Mask ECO via spare cells — use pre-inserted spare logic 2. For this specific change (AND→OR), which approach is fastest? Lowest DRC risk? 3. Write the Innovus Tcl commands for ecoChange approach: - ecoChangeCell to swap AND2_X2 → OR2_X2 - ecoRoute to fix affected nets - Verify timing impact 4. How does metal-only ECO work for an AND→OR swap? (Which metal layers need to change?) 5. What is the spare cell ECO approach? When is it used?
Write a complete Cadence Innovus Tcl flow script for a standard block. Design: alu_top (sub-block, not top-level chip) Technology: 7nm, 12-track library Clock: CLK_CORE at 1 GHz Target utilization: 75% Input files: alu_top.v (netlist), alu_top.sdc, tech.lef, cells.lef Script should include all these stages in order: 1. Read design (read_netlist, read_lef, read_sdc) 2. Floorplan (initFloorplan, addRing) 3. Power routing (addStripe, sroute) 4. Placement (place_design, addWellTap, addFiller -placeOnly) 5. Pre-CTS optimization (optDesign -preCTS) 6. CTS (ccopt_design) 7. Post-CTS optimization (optDesign -postCTS) 8. Routing (routeDesign) 9. Post-route optimization (optDesign -postRoute) 10. Filler insertion (addFiller) 11. Verify and write outputs (verify_drc, streamOut GDS) Add comments explaining each step. Flag any non-default settings that affect QoR.
Analyze these electromigration violations from my Voltus EM report. EM violations: 1. Net "u_pll/vco_out" — M4 segment, current density 2.1 mA/um, limit 1.8 mA/um 2. Net "VDD" power strap — M7, current density 0.95 mA/um, limit 1.0 mA/um (marginal) 3. Net "u_clk_div/clk_out" — clock net on M3, current density 1.6 mA/um, limit 1.2 mA/um For each: 1. Is this a functional EM (AC) or average EM (DC) violation? 2. What is the reliability impact? (Mean time to failure estimate) 3. How much do I need to widen the wire to fix the violation? Formula: new_width = current_width * (current_density / limit) 4. Can I fix violation #1 by widening, or does the wire need rerouting? 5. For the clock net (#3): special considerations for EM on clock routes? 6. Innovus Tcl: how to enforce minimum width on a specific net?
Review my physical design sign-off status and tell me if I am ready for GDS tape-out. Current status: - DRC: 0 violations (Calibre clean) - LVS: Clean (Calibre LVS) - STA: WNS = +0.02ns setup, +0.05ns hold (all corners) - IR drop: max 28mV (budget 30mV) - EM: 1 marginal violation on net "u_pll/vco_out" (at 98% of limit) - Fill coverage: 72% (minimum required: 70%) - Antenna: Calibre antenna clean - ESD: ESD verified by custom rule deck - Density DMP: all layers within spec - Clock skew: max 95ps (budget 100ps) Questions: 1. Is the marginal EM violation a blocker? At 98% of limit, should I fix it? 2. Is 72% fill coverage adequate or do I need more? 3. Any sign-off item I'm not covering above? 4. What are the top 3 GDS submission mistakes PD engineers make? Give me a GO / NO-GO recommendation with justification.
I'm moving from Cadence Innovus to Synopsys ICC2 on a new project. Give me a command mapping table for the most common PD operations. Map these operations: 1. Read design / initialize 2. Floorplan creation (die area, core margin) 3. Add power stripes 4. Place standard cells 5. Run CTS 6. Run routing 7. Post-route optimization 8. Insert filler cells 9. Run DRC verification 10. Write GDS (stream out) 11. Save / restore database 12. Report timing (in-tool) Format as a two-column table: Innovus command | ICC2 equivalent command. Note any major conceptual differences (e.g., where Innovus uses "routeDesign", ICC2 uses a different philosophy for global vs detail routing).
Before running Innovus, describe your design hierarchy and constraints to Claude. Get a second opinion on macro placement, power domain boundaries, and I/O assignment before committing to a floorplan that is hard to change.
Use Claude to write first-pass Tcl scripts for each PnR stage. This is where Claude adds the most value — correct Innovus/ICC2 Tcl syntax from natural language requirements saves 2–3 hours per script.
Describe your power budget and die size. Claude recommends strap widths and pitches. Use this as a starting point for your Voltus/RedHawk model — adjust based on actual IR results.
Paste specific DRC error descriptions. Claude explains what causes each rule violation and suggests the fastest routing option to fix it — often faster than reading the PDK DRM.
Describe the overflow region, block names, and layer data. Claude walks through root cause analysis and recommends whether to adjust placement density or reroute.
Run through the signoff checklist (Prompt #14) with Claude before GDS submission. Catches overlooked items like antenna rule, fill spec, and marginal EM — items that get missed under deadline pressure.
Claude has no access to LEF/DEF files, technology rule decks, or extracted parasitics. It cannot tell you actual wire lengths, congestion heatmaps, or DRC coordinates. Use Claude to understand and plan — always verify with Innovus, ICC2, Calibre, and Voltus for real numbers.
Yes. Claude is excellent at floorplan strategy: macro placement guidelines, aspect ratio selection, power domain partitioning, and I/O assignment. It cannot access your actual LEF geometry, so treat its output as a starting strategy to validate in Innovus/ICC2.
Yes — this is one of Claude's strongest PD use cases. It generates correct Tcl syntax for floorplan, power routing, placement, CTS, and routing stages. Always test scripts in a non-critical run first; some commands may need version-specific adjustments.
Paste the DRC rule name, description, and violation count. Claude explains the physical cause and suggests routing constraints or design changes. For technology-node-specific rules, include the PDK rule name (e.g., M4.S.1) for best accuracy.
Yes. Describe your hotspot location, power budget, and current strap configuration. Claude recommends strap widths, pitch adjustments, and local power rings. For actual IR numbers you need Voltus or RedHawk — Claude helps you interpret results and plan fixes.
Claude cannot predict actual cell placement quality, route congestion maps, or physical DRC coordinate locations — it has no access to your layout. Never skip running Calibre DRC/LVS or Voltus IR/EM analysis based on Claude's advice alone. Claude is a planning and scripting assistant, not a replacement for your EDA flow.