Your complete playbook for using Claude in Logic Synthesis — from Synopsys DC and Yosys scripts to QoR analysis, SDC for synthesis, area/power optimization, scan insertion, and netlist verification.
| Task | Claude Quality | Notes |
|---|---|---|
| Write Synopsys DC Tcl scripts | Excellent | Full flow: read, link, compile_ultra, reports |
| Write Yosys synthesis scripts | Excellent | Open-source flow, sky130 / generic stdcell |
| Explain synthesis warnings | Excellent | Latch, unconnected, multi-driven, unresolved |
| Write synthesis SDC constraints | Excellent | create_clock, dont_touch, dont_use, set_max_area |
| QoR improvement strategies | Good | compile directives, RTL restructuring suggestions |
| Interpret synthesis reports | Good | Reads timing, area, power reports accurately |
| Scan insertion guidance | Good | DFT compile flow, scan chain constraints |
| Predict post-synthesis netlist area | Poor | No access to PDK — requires actual DC run |
Write a complete Synopsys Design Compiler Tcl script for synthesizing my block. Design info: - Top module: alu_top - Technology library: slow.db (worst corner), fast.db (best corner) - Target frequency: 1 GHz (1ns period) - Target area: 50,000 um² (soft constraint) - Input files: alu_top.v, alu_sub.v, alu_top.sdc Script must cover all these stages with comments: 1. Setup: library paths, search_path, target_library, link_library 2. Read and elaborate: read_verilog, elaborate 3. Link design 4. Apply constraints: read_sdc 5. Set compile directives: - compile_ultra -no_seq_output_inversion -no_boundary_optimization - Enable retiming: set_optimize_registers 6. Report pre-compile quality: check_design 7. Run compile 8. Post-compile reports: - report_timing -max_paths 10 - report_area - report_power - report_qor 9. Write outputs: write_verilog, write_sdc, write_sdf Add error handling: check for zero violations before writing outputs.
Write a multi-corner Synopsys DC synthesis script. Corners to run: - SS/0.72V/125C (worst: setup critical) — library: slow_125.db - TT/0.8V/25C (nominal) — library: typical_25.db - FF/0.88V/-40C (best: hold critical) — library: fast_m40.db For each corner: 1. Set correct target_library and link_library 2. Apply temperature-scaled clock uncertainty 3. Run compile_ultra 4. Collect these QoR metrics into a Tcl array: - WNS (worst negative slack) - TNS (total negative slack) - Area (um²) - Leakage power (nW) After all corners complete: 5. Print a QoR comparison table to stdout 6. Identify the corner that limits timing (highest TNS) 7. Check if hold is positive at FF corner 8. Write netlists for all 3 corners with corner suffix in filename
Write an SDC constraints file optimized for synthesis (not signoff STA). Design: core_top Primary clock: CLK at 1 GHz Generated clocks: CLK_DIV2 (500 MHz), CLK_APB (100 MHz) Synthesis-specific requirements: 1. Add 10% margin to clock period for synthesis guard band (synthesis clock = 0.9ns for 1 GHz target) 2. Set clock uncertainty: 0.15ns for setup, 0.05ns for hold 3. Set input delays: 30% of clock period for all inputs 4. Set output delays: 30% of clock period for all outputs 5. dont_touch on: u_pll, u_io_ring (pre-implemented blocks) 6. dont_use on: cells with HIGH_DRIVE suffix (reserved for clock tree) 7. set_max_fanout 20 on all input ports 8. set_max_transition 0.2ns on all nets 9. set_max_area 0 (area optimization mode) Also add comments explaining why synthesis SDC differs from signoff SDC (guard band, simplified I/O constraints, no CPPR).
Generate dont_use and dont_touch constraints for my synthesis flow. Library cell categories to exclude (dont_use): - All cells with drive strength > X16 (too large for datapath, keep for clock tree) - All scan-specific cells (SE_*, SI_*, SO_* prefix) — inserted separately by DFT flow - All analog/mixed-signal cells (ANLG_* prefix) - Deprecated cells marked EOL in PDK v2.1 release notes - Filler cells (FILL*, WELLTAP*) Instances to protect (dont_touch): - u_pll_core — analog PLL, pre-characterized - u_sram_macro_* — memory compiler output, fixed - u_io_ring — pad ring, placed separately - All instances matching pattern u_analog_* Generate: 1. set_dont_use [get_lib_cells lib/*X16 lib/*X32 lib/*X64] in DC syntax 2. set_dont_touch [get_cells u_pll_core] in DC syntax 3. How to verify dont_use is respected: check_dont_use report 4. Risk: what happens if dont_use removes all cells for a function? How does DC handle it?
Analyze this Synopsys DC QoR report and tell me how to improve it. [PASTE YOUR report_qor OUTPUT HERE] I want to know: 1. What is WNS and TNS? Are they acceptable for my 1 GHz target? 2. How many paths are failing timing? Are they in the same clock domain? 3. What does the "Timing Path Group" distribution tell me? 4. What is the logic level count on the critical path? Is it too deep? 5. What is the overall cell area and how does it compare to a typical design of this complexity? 6. Power estimate: dynamic vs leakage breakdown 7. Top 3 specific compile directives to improve WNS: - Option A: compile_ultra -retime - Option B: set_compile_directives for the critical path hierarchy - Option C: RTL restructuring (if logic depth > 20) 8. Is my synthesis constrained too aggressively (over-constrained)? How do I detect over-constraint?
My post-synthesis area is 20% over budget. Help me reduce it. Current state: - Area: 120,000 um² (target: 100,000 um²) - WNS: +0.15ns (timing has margin) - Power: 85 mW (within budget) - Logic depth: average 14 levels (target was 12) Reduction strategies to try: 1. Compile with area optimization: what DC directives help? (set_max_area, compile_ultra -area_high_effort_script) 2. Hierarchy flattening: should I flatten? What are the risks? 3. RTL changes that typically reduce area most: - Replace priority encoder with round-robin - Share multiplier hardware across time-multiplexed paths - Reduce pipeline register count (trade latency for area) 4. Identify over-designed blocks: how do I find which sub-modules are largest? Generate the DC Tcl command to report area by hierarchy 5. Clock gating: will inserting clock gates help area? How? 6. After all optimizations: what is a realistic area reduction target?
Help me reduce post-synthesis power consumption. Current power breakdown (from report_power): - Dynamic switching: 62 mW (target: 50 mW) - Dynamic internal: 18 mW - Leakage: 5 mW - Total: 85 mW (target: 75 mW) Design context: - Clock: 1 GHz, 70% activity factor on datapath - Many idle states where datapath is not active Optimization levers: 1. Clock gating: - Is clock gating already applied? How to check in DC? - What is the minimum register count for DC to insert clock gate? - How to force more aggressive clock gating? - DC command: set_clock_gating_style options 2. Multi-Vt cell selection: - My library has HVT, SVT, LVT cells - Which paths should use HVT (low leakage) vs LVT (fast)? - DC command to prefer HVT: compile_ultra -gate_clock 3. Operand isolation: - For datapath blocks with enable signals - DC command: set_operand_isolation_style 4. Activity-based optimization: - How to provide switching activity (SAIF) to DC - Impact on power reduction quality Generate the DC Tcl commands for each strategy.
Explain these Synopsys DC synthesis warnings and tell me which to fix. Warning 1: WARNING: (UID-95) Net 'u_ctrl/next_state[2]' has no loads. (design: ctrl_fsm) Warning 2: WARNING: (LINT-1) Inferred memory for variable 'u_cache/data_ram' Warning 3: WARNING: (ELAB-302) Could not resolve hierarchical reference: u_pll/clk_out Warning 4: WARNING: (SYNTH-5) A latch was inferred for signal 'mode_reg' in always block Warning 5: WARNING: (LINT-28) In design 'alu_top': Net 'carry_internal' is multiply driven For each warning: 1. What is the root cause? 2. Is this CRITICAL (must fix before tapeout) or BENIGN (informational)? 3. What RTL or script change fixes it? 4. Which warnings should NEVER appear in a clean tapeout-ready design? Priority ranking: which of these 5 is the most dangerous for silicon?
Guide me through using retiming in Synopsys DC to fix a timing violation. Current situation: - Critical path: 8-stage multiplier pipeline, setup WNS = -0.22ns - Logic depth in stage 4: 24 levels (too deep) - Stage 5 is very short: only 6 logic levels Retiming should move registers from stage 5 backward into stage 4 to balance them. Steps: 1. What DC command enables retiming? (set_optimize_registers / compile_ultra -retime) 2. What RTL attributes might BLOCK retiming? (dont_touch, preserve) 3. How do I tell DC which register group to allow retiming on? 4. What are the risks of retiming? - Does it change RTL behavior? - Does it affect scan chain insertion? - Can it break CDC synchronizers? 5. How do I verify retiming was applied: what does the log/report show? 6. After retiming, does the SDF (delay file) need to be regenerated? 7. Generate the specific DC commands for my case.
Write a Synopsys DC DFT (Design for Test) flow script for scan insertion. Design requirements: - Number of scan chains: 8 - Target scan coverage: 95% - Scan-enable port: scan_en (already in RTL) - Scan input ports: si[7:0] - Scan output ports: so[7:0] - Clock for scan: use CLK_CORE (same as mission mode) - Exclude from scan: u_pll, u_sram_* (memory macros) DC DFT Tcl commands needed: 1. set_dft_signal for test clock, scan_en, scan_in, scan_out 2. create_test_protocol 3. dft_drc — check DFT design rules before insertion Fix any DFT DRC issues 4. insert_dft — insert scan chains 5. report_dft_insertion_configuration 6. report_scan_path — show chain connectivity 7. Write scan-inserted netlist and SPEF Also explain: - What cells CANNOT be scanned (why are memories excluded)? - How does DC handle clock gating cells in scan mode? - What is scan compression and when is it needed?
Write a complete Yosys synthesis script targeting the SkyWater sky130 PDK. Design: my_alu (Verilog RTL) Target: sky130_fd_sc_hd (high-density standard cell library) Optimization goal: timing + area balanced Yosys script must include: 1. Read RTL: read_verilog -sv my_alu.v my_alu_pkg.sv 2. Elaborate: hierarchy -check -top my_alu 3. Flatten (optional): flatten 4. Technology-independent optimization: - proc (convert procedural to netlist) - opt (constant propagation, dead code) - techmap (generic mapping) - opt -fast 5. ABC optimization: - dfflibmap -liberty sky130_fd_sc_hd.lib - abc -liberty sky130_fd_sc_hd.lib -constr timing.constr 6. Cleanup: setundef, hilomap 7. Write outputs: - write_verilog -noattr my_alu_synth.v - write_json my_alu.json (for nextpnr) 8. Stats: stat -liberty sky130_fd_sc_hd.lib Also: what ABC timing constraint file format does Yosys expect? Generate a sample timing.constr for 50 MHz target clock.
Explain how to run formal equivalence checking after synthesis. I need to verify that my synthesized netlist (my_alu_synth.v) is functionally equivalent to my RTL (my_alu.v). Options: A. Synopsys Formality (industry standard) B. Yosys + ABC equivalence check (open source) C. Cadence Conformal (alternative) For each option: 1. What are the basic Tcl/script commands to set up and run? 2. What does a PASS result mean? What does FAIL mean? 3. What are common causes of equivalence check failure after synthesis? (retiming, constant propagation, scan insertion changes) 4. How do I handle don't-care conditions in equivalence checking? 5. If the check FAILS, how do I locate the failing point in the netlist? Generate the complete Formality Tcl script for my alu_top design. Also generate the equivalent Yosys equivalence check as an alternative.
Help me plan the hierarchical synthesis strategy for a large SoC. Design hierarchy: - soc_top (10M gates estimated) - cpu_core (3M gates, 1 GHz) - gpu_core (4M gates, 800 MHz) - ddr_ctrl (1M gates, 400 MHz) - usb_ctrl (0.5M gates, 480 MHz) - apb_interconnect (0.3M gates, 100 MHz) - misc_ctrl (0.2M gates, 200 MHz) Questions: 1. Bottom-up vs top-down synthesis — which for this design? Why? 2. Which blocks should be synthesized independently with fixed interface timing? (set_boundary_optimization false strategy) 3. Which blocks benefit from cross-hierarchy optimization? 4. How do I set up interface timing models (ETM) for block-level synthesis? 5. What is the DC command to write an ETM for cpu_core? 6. How does this affect runtime? Estimate total synthesis time reduction. 7. What are the risks of hierarchical synthesis vs flat synthesis for QoR?
Review my synthesis output and tell me if it is ready for PnR handoff. Synthesis output summary: - WNS: +0.03ns (setup, SS corner) - TNS: 0.0ns (no failing paths) - Area: 98,500 um² (target 100,000 um²) - Power: 78 mW (target 80 mW) - Warnings: 3 (all LINT informational — unloaded output ports) - check_design: CLEAN - Scan chains: 8 chains, 95.2% coverage - Equivalence check: PASS - Dont_touch violations: 0 - Unresolved hierarchical references: 0 Checklist I need reviewed: □ Timing clean at worst corner with guard band? □ All synthesis warnings resolved or justified? □ DFT scan insertion complete and verified? □ Equivalence check passed? □ Netlist written with correct naming conventions? □ SDC written and matches netlist hierarchy? □ SDF generated for gate-level simulation? □ Power intent (UPF/CPF) applied and consistent? GO / NO-GO for PnR? Flag any item that needs action.
My synthesis WNS degraded from +0.05ns to -0.18ns between two runs. Help debug. Changes between Run A (clean) and Run B (failing): - Added 2 new RTL modules: u_new_filter.v, u_new_ctrl.v - Updated SDC: added 3 set_multicycle_path exceptions - Changed compile directive: removed -no_boundary_optimization - Updated to new library version: v2.3 (was v2.2) Debugging approach: 1. Which change is most likely the root cause of the -0.23ns degradation? 2. How do I isolate: run synthesis with each change reverted one at a time 3. What does removing -no_boundary_optimization do to QoR? (This is the most likely culprit — explain why) 4. Can a library version update cause timing degradation? How much is typical? 5. How do I diff two DC timing reports to see exactly which paths changed? Generate the DC Tcl commands to compare report_timing output files 6. Once I find the root cause, what is the fastest fix to get back to +0.05ns?
Use Claude to write your first-pass DC or Yosys script before running anything. Getting the script structure right (library setup, compile directives, report generation) from the start saves hours of "why isn't this running" debug time.
Use Prompt #3 to generate synthesis SDC with correct guard band and dont_use constraints. Many QoR problems trace back to missing SDC constraints — over-constrained paths waste compile time, under-constrained paths produce incorrect netlists.
After first synthesis run, paste all warnings into Prompt #8. Triage takes 5 minutes with Claude vs 30 minutes reading documentation. Fix all CRITICAL warnings before proceeding — especially multi-driven nets and inferred latches.
Paste the report_qor output into Prompt #5. Claude identifies the bottleneck (timing vs area vs power) and recommends the highest-leverage compile directive or RTL change to improve QoR in the next iteration.
Run scan insertion only after functional synthesis is clean. Use Prompt #10 for the DFT compile flow. DFT changes area by 5–15% — reserve area budget before DFT insertion.
Use the synthesis signoff checklist (Prompt #14) before handing off to PnR. Verify equivalence check (Prompt #12) and ensure the netlist, SDC, and SDF are all written and consistent.
Synthesis optimizations — especially retiming, boundary optimization, and constant propagation — can introduce functional changes that simulation does not catch. Always run formal equivalence checking (Formality or Yosys) between RTL and gate-level netlist before proceeding to PnR. A passing equivalence check is required for tapeout at most foundries.
Yes — this is one of the strongest use cases. Claude writes complete DC Tcl scripts covering read, elaborate, link, compile_ultra, and all reports. It knows compile directives, report commands, and write output commands. Test scripts on a small design block first before running on the full chip.
Yes. Paste your report_qor output and describe your target (timing, area, or power). Claude identifies the bottleneck and recommends specific compile directives, RTL restructuring, or SDC constraint adjustments for the next iteration. Most useful for diagnosing why WNS is stuck after compile_ultra.
Yes. Claude writes complete Yosys scripts for sky130 and other open PDKs, including the ABC optimization pass, dfflibmap, and write_verilog output. It also explains the Yosys command pipeline and how each step maps to what Synopsys DC does internally.
Paste the warning messages directly — no need to look them up in the DC manual. Claude explains each warning category (inferred latch, unconnected port, multi-driven net, unresolved reference) and provides the RTL or script fix. It also identifies which warnings are critical blockers vs benign informational messages.
Claude cannot predict actual post-synthesis area, timing, or power — it has no access to your PDK or netlist. Technology-specific cell selection and drive strength decisions require the actual DC tool and characterized library. Use Claude to write scripts, interpret reports, and plan strategy — verify all numbers with DC or Yosys.