AI × VLSI Engineering

Claude AI for VLSI Engineers

From RTL to tapeout — how the world's most capable AI assistant supercharges chip design, verification, timing analysis, and physical design.

6+
Engineering Domains
30+
Ready-to-Use Prompts
RTL→GDS
Full Flow Coverage
9-Step Tutorial Series
Claude for VLSI Engineers — Complete Guide
Start Step 1
① HOW IT WORKS
LLM & Tokenization
✓ Available
② SETUP
Projects & API
✓ Available
③ MASTER CLAUDE
Advanced Prompting
✓ Available
④ RTL ENGINEER
FSM, FIFO, AXI
Coming Soon
⑤ DV ENGINEER
SVA, UVM, Coverage
Coming Soon
⑥ STA ENGINEER
Timing & SDC
Coming Soon
⑦ PHYS DESIGN
PnR, CTS, DRC
Coming Soon
⑧ CDC ENGINEER
Sync, MTBF, FIFO
Coming Soon
⑨ SYNTHESIS
DC, QoR, Retiming
Coming Soon
What is Claude?

Anthropic's AI built for deep reasoning

Claude is a large language model built by Anthropic — designed for nuanced, technical reasoning. Unlike general chatbots, Claude excels at understanding long technical context — entire RTL files, full timing reports, complex SDC constraint files — and reasoning about them coherently.

200K token context window — paste an entire design file, netlist excerpt, or STA report
Writes synthesizable Verilog & SystemVerilog — FSMs, interfaces, assertions, UVM components
Explains reasoning — not just code, but why — MTBF formulas, timing slack math, CDC principles
Safe for proprietary work — use claude.ai with Projects, or the API for internal tooling
Live conversation example
I have a 2-FF synchronizer in my CDC path but still see metastability failures in simulation. Why?
A 2-FF synchronizer reduces metastability probability but cannot eliminate it. The mean time between failures (MTBF) is:

MTBF = exp(Tw/τ) / (f_clk × f_data × C1)

If you're still seeing simulation failures, the likely causes are:
1. Resolution time τ is too short for your process corner
2. The data path violates the sampling window assumption
3. You're using $random stimulus that toggles faster than MTBF assumptions allow...
Can you generate a 3-stage synchronizer with async reset for my 28nm design?
Yes — for 28nm at frequencies above 600MHz, 3 stages is the correct choice. Here's a clean, synthesis-friendly version with async assert, sync deassert reset...
Claude Across the VLSI Flow

Every discipline in the RTL-to-GDS flow has specific, high-value use cases where Claude replaces hours of documentation searching, script writing, or junior engineer handholding.

RTL Design
RTL / Frontend Engineer
Generate modules from spec, debug synthesis warnings, write FSMs, review CDC issues, and get instant code review on any Verilog block.
Verilog generation FSM coding Lint fixes CDC review Reset strategy
DV / Verification
DV / Verification Engineer
Generate SVA assertions, UVM sequences and scoreboards, testbench infrastructure, functional coverage plans, and constrained-random stimulus.
SVA assertions UVM components Coverage plans Testbench gen Debug assist
STA
STA / Timing Engineer
Paste a Primetime or Tempus report — Claude explains violations, suggests fix strategies, writes SDC constraints, and debugs false/multicycle path exceptions.
Report analysis SDC generation OCV/CPPR ECO guidance MCP exceptions
Physical Design
Physical Design Engineer
Floorplan strategy, power domain setup, clock tree planning, Tcl script generation for Innovus/ICC2, DRC interpretation, and timing ECO suggestions.
Floorplan advice Tcl scripting DRC debug CTS planning PG mesh
CDC
CDC / Metastability Engineer
Explain CDC violations from Questa CDC / SpyGlass reports, suggest correct synchronization structures, calculate MTBF, and generate Gray-coded FIFO pointer logic.
Synchronizer design MTBF calc SpyGlass fixes Gray counter Handshake
Synthesis
Synthesis / Logic Engineer
Debug Synopsys DC or Yosys warnings, understand area/power/timing tradeoffs, write synthesis scripts, and get RTL coding guidelines for optimal QoR.
DC scripting QoR optimization Warning debug Retiming Area reduction
Prompt Library — Copy & Use

These are real, production-quality prompts you can paste directly into Claude. Each shows both the prompt and a representative response excerpt.

Prompt 1 — Generate a parameterized FIFO
You are an expert RTL design engineer. Write a parameterized synchronous FIFO in Verilog with the following spec:
• DATA_WIDTH and DEPTH parameters
• Synchronous reset (active high)
• Full and empty flags
• almost_full when depth − 2 entries are used
• Use non-blocking assignments (<=) in all sequential blocks
• Target: Xilinx UltraScale BRAM inference
Include a brief comment explaining the ptr gray coding approach for FIFO depth tracking.
Claude Response (excerpt)
Here's a synthesizable parameterized FIFO targeting Xilinx UltraScale BRAM:
module sync_fifo #(
  parameter DATA_WIDTH = 8,
  parameter DEPTH      = 16,
  parameter ADDR_W     = $clog2(DEPTH)
)(
  input  wire                  clk, rst,
  input  wire                  wr_en, rd_en,
  input  wire [DATA_WIDTH-1:0] din,
  output reg  [DATA_WIDTH-1:0] dout,
  output wire                  full, empty, almost_full
);
  (* ram_style = "block" *)
  reg [DATA_WIDTH-1:0] mem [0:DEPTH-1];
  reg [ADDR_W:0] wr_ptr, rd_ptr;  // extra bit for full/empty distinction

  always @(posedge clk) begin
    if (rst) begin
      wr_ptr <= 0;  rd_ptr <= 0;
    end else begin
      if (wr_en && !full)  begin mem[wr_ptr[ADDR_W-1:0]] <= din; wr_ptr <= wr_ptr + 1; end
      if (rd_en && !empty) begin dout <= mem[rd_ptr[ADDR_W-1:0]];  rd_ptr <= rd_ptr + 1; end
    end
  end

  assign empty       = (wr_ptr == rd_ptr);
  assign full        = (wr_ptr[ADDR_W] != rd_ptr[ADDR_W]) &&
                       (wr_ptr[ADDR_W-1:0] == rd_ptr[ADDR_W-1:0]);
  assign almost_full = (wr_ptr - rd_ptr) >= (DEPTH - 2);
endmodule
The extra pointer bit technique avoids the ambiguity between full (wr==rd) and empty — they differ only in the MSB.
Prompt 2 — Review RTL for issues
Review this Verilog RTL block for the following issues and explain each finding with severity (Critical/Warning/Info):
1. Unintended latches (incomplete case/if without default)
2. Clock domain crossing without synchronizers
3. Blocking assignments in sequential always blocks
4. Missing reset conditions on flip-flops
5. Combinational loops

[PASTE YOUR VERILOG MODULE HERE]
Prompt 3 — Mealy FSM from spec
Implement a Mealy FSM in SystemVerilog for an AXI-Lite write channel manager. States: IDLE → AW_WAIT → W_WAIT → B_SEND → IDLE. Outputs: awready, wready, bvalid, bresp. Use the 3-block coding style (state register, next-state logic, output logic). Non-blocking assignments in sequential blocks only. Include full parameter for DATA_WIDTH.
Prompt 4 — Generate SVA assertions
Write SystemVerilog concurrent assertions (SVA) for an AXI4-Lite slave interface. Cover these properties:
1. awvalid must not deassert before awready is seen
2. wvalid must not deassert before wready is seen
3. bvalid must be asserted exactly 1–4 cycles after the write handshake
4. araddr must be stable while arvalid is asserted and arready is low
5. No outstanding read request during a write (exclusive access)

Use clocking block @(posedge clk). Include assume properties for input stimulus and assert properties for DUT behavior. Add $error messages.
Claude Response (excerpt)
// AXI4-Lite SVA Assertions
module axi_lite_sva #(parameter DW=32)(
  input logic clk, rst_n,
  // Write address channel
  input logic awvalid, awready,
  input logic [31:0] awaddr,
  // Write data channel
  input logic wvalid, wready,
  // Write response
  input logic bvalid, bready,
  // Read address
  input logic arvalid, arready,
  input logic [31:0] araddr
);
  default clocking cb @(posedge clk); endclocking
  default disable iff (!rst_n);

  // P1: awvalid must not deassert before awready
  p_awvalid_stable: assert property (
    awvalid && !awready |=> awvalid
  ) else $error("AXI: awvalid dropped before awready");

  // P3: bvalid within 1–4 cycles of write handshake
  p_bvalid_latency: assert property (
    (awvalid && awready) ##0 (wvalid && wready)
    |-> ##[1:4] bvalid
  ) else $error("AXI: bvalid not seen within 4 cycles of write");

  // P4: araddr stable while arvalid high and arready low
  p_araddr_stable: assert property (
    arvalid && !arready |=> $stable(araddr)
  ) else $error("AXI: araddr changed while arvalid high");
Prompt 5 — UVM sequence + scoreboard
Write a UVM sequence and scoreboard for verifying a 32-bit ALU with operations: ADD, SUB, AND, OR, XOR, SHL, SHR. The sequence should:
• Use constrained-random with weighted distribution (ADD 30%, others equal)
• Include a directed test for overflow on ADD
The scoreboard should use an associative array transaction queue and check results against a reference model function. Include functional coverage for all op-code combinations.
Prompt 6 — Coverage closure strategy
My functional coverage report shows these uncovered bins after 500k simulation cycles:
• fsm_state::ERROR never reached
• fifo_depth::full_to_empty transition: 0 hits
• interrupt::simultaneous_4_sources: 0 hits

Suggest directed test cases and SystemVerilog constraint modifications to close each coverage hole. Explain why each bin is likely hard to reach with purely random stimulus.
Prompt 7 — Interpret timing report
You are a senior STA engineer. Analyze this Primetime timing report and explain:
1. The exact cause of the setup violation
2. Which cells are on the critical path
3. Three ranked fix strategies (logic restructuring, buffering, placement hint, frequency reduction)
4. What SDC change could relax this path if it's a false path

[PASTE YOUR TIMING REPORT HERE — the section from "Startpoint:" to "slack (VIOLATED)"]
Claude Response (excerpt)
Looking at your timing report, the setup violation (slack = −0.23ns) is caused by a long combinational path through 5 cascaded mux cells in the address decoder, combined with a high-fanout net on the select signal.

Critical path analysis:
• Launch FF → U_DEC/MUX_0 (0.18ns cell delay + 0.34ns wire)
• MUX chain: 5× 0.21ns = 1.05ns
• Capture FF setup: 0.08ns

Fix strategies (ranked):
1. Logic restructuring (best ROI): Replace the 5-deep mux chain with a priority encoder + one-hot decode — reduces to 2 logic levels
2. Placement hint: set_max_delay -datapath_only 2.8 [get_pins U_DEC/...] allows the placer to co-locate the cells
3. Buffer insertion: Add a repeater on the high-fanout select net — reduces skew from 0.21ns to ~0.08ns
Prompt 8 — Write SDC constraints
Write complete SDC constraints for a SoC with the following clocks:
• clk_sys: 500MHz, source: PLL output, duty cycle 50%
• clk_ddr: 800MHz, source: DDR PHY, 90° phase shift relative to clk_sys
• clk_audio: 24.576MHz, asynchronous to both above

Include: create_clock, create_generated_clock, set_clock_groups for async domains, input/output delays for the top-level I/O ports, set_false_path for test logic, and set_multicycle_path for the DDR capture path (2-cycle).
Prompt 9 — Explain OCV and CPPR
Explain On-Chip Variation (OCV) and Clock Pessimism Removal (CPPR) as if I'm an RTL engineer moving into STA for the first time. Use a concrete numeric example showing how CPPR recovers timing slack. Then explain the difference between AOCV and POCV and when each is appropriate.
Prompt 10 — Floorplan strategy
I'm floorplanning a 7nm mobile SoC with these blocks: CPU cluster (4× A78, 2mm²), GPU (1.5mm²), NPU (0.8mm²), DDR PHY, USB PHY, PCIe PHY, SRAM banks (32× 256KB). Die size is 8mm × 8mm, 4 metal power rails.

Suggest a floorplan strategy covering:
1. Block placement priority and adjacency reasoning
2. Power domain partitioning (always-on vs power-gated)
3. PHY placement near die edge rationale
4. SRAM placement for minimum latency to CPU
5. Clock tree root placement
Claude Response (excerpt)
Floorplan strategy for your 7nm SoC:

1. Block placement priority:
Start with I/O-constrained blocks. Place DDR PHY, USB PHY, PCIe PHY along die edges — they need direct pad connections and their bump patterns dictate adjacent placement. DDR PHY south edge (closest to board DDR routing), USB/PCIe west edge.

2. CPU–SRAM adjacency (highest priority):
The 32× SRAM banks should form an L-shape around the CPU cluster. Target ≤300µm wire length from CPU cache controller to SRAM array. This is your #1 timing-critical interface at 3GHz+.

3. Power domains:
• Always-on: PMU, boot ROM, always-on SRAM (retention)
• CPU_PD: switchable, level-shifters on all CPU→fabric interfaces
• GPU_PD, NPU_PD: independent gating, share the same isolation cell library
• Never put a power domain boundary across a timing-critical path
Prompt 11 — Write Innovus Tcl script
Write an Innovus Foundation Flow Tcl script for a 16nm design that:
• Reads LEF/DEF and Liberty files
• Sets up multi-corner multi-mode (MCMM) analysis: func_ss_0p72v_125c and func_ff_0p88v_m40c
• Runs floorplan initialization with utilization 0.75
• Inserts welltaps and endcaps
• Runs place_opt and route_opt
• Exports final DEF and GDSII
Add comments explaining each step.
Prompt 12 — Debug SpyGlass CDC report
Analyze this SpyGlass CDC report excerpt and for each violation:
1. Explain why it's a real risk vs. a false positive
2. Show the correct fix in Verilog (synchronizer insertion, handshake, or waiver justification)
3. Estimate the MTBF impact if left unfixed at 500MHz → 200MHz crossing

[PASTE SPYGLASS CDC VIOLATIONS HERE]
Prompt 13 — Async FIFO with Gray pointers
Write a complete asynchronous FIFO in Verilog with these requirements:
• Parameters: DATA_WIDTH, ADDR_WIDTH
• Dual-clock: wclk and rclk, completely asynchronous
• Gray-coded read/write pointers synchronized across domains
• Full and empty flags generated in the correct clock domain
• Non-blocking assignments throughout
• Explain in comments: why Gray code prevents multi-bit glitches, and the 2-FF synchronizer choice
• Include a simulation waveform description showing pointer crossing
Prompt 14 — Explain MTBF calculation
Walk me through the complete MTBF calculation for a 2-stage synchronizer in a 7nm process. Given: τ (resolution time constant) = 28ps, C1 = 1×10^-10 s/V, clk_dest = 1GHz, data toggle rate = 100MHz. Show the formula, plug in values, and explain whether 2 stages is sufficient or if 3 stages is recommended. Compare against a 28nm process where τ = 45ps.
How to Get the Best Results

Claude is most powerful when you treat it like a knowledgeable colleague — give it full context, specify the tool chain, and ask for explanations alongside code.

01

Set the role and context first

Open every technical session with a role primer — it shifts Claude into the right reasoning mode.

"You are a senior RTL design engineer with 10 years at a tier-1 semiconductor company. Target tool: Synopsys DC. Process: TSMC 7nm FF."
02

Paste the actual artifact — not a summary

Paste the full Verilog module, the exact timing report section, or the precise lint warning message. Claude analyzes what's there, not what you describe.

"Here is the full module — lines 1–240 — please review for unintended latches: [paste code]"
03

Specify constraints explicitly

Non-blocking assignments, target tool, technology node, clock frequency — state them in the prompt, not as assumptions.

"Use only non-blocking assignments in sequential blocks. Target Xilinx UltraScale+. Synthesize at 250MHz."
04

Ask for explanation alongside code

Claude generates better RTL when forced to explain its choices — the explanation reveals whether it understood the spec.

"Write the Verilog and then explain why you chose this synchronizer topology over a 2-phase handshake."
05

Always verify synthesized output

Run Claude's code through your linter and synthesizer before committing. Claude is a productivity multiplier, not a rubber stamp — your DV flow is the ground truth.

Lint with Spyglass → Simulate with VCS/Questa → Synthesize with DC → close with PT
Power-User Prompting for VLSI
T1

Use "Projects" for persistent context

In Claude.ai, create a Project and paste your design spec, naming conventions, and tool constraints into the System prompt — every conversation inherits it.

T2

Iterative refinement beats one-shot

Start with the module skeleton, then ask Claude to add reset logic, then add assertions, then write the testbench. Each step builds on verified output.

T3

Ask it to find its own bugs

After generating RTL, ask: "Review this code you just wrote for CDC issues, incomplete case statements, and blocking assignment misuse." Claude catches ~80% of its own errors.

T4

Paste error messages verbatim

Copy the exact Vivado, DC, or Questa error including the line number. Claude uses the error code and message together — paraphrasing loses critical detail.

T5

Use it as a code reviewer, not just generator

Paste your existing RTL and ask: "Review this for synthesis-unfriendly patterns, latch inference risk, and any protocol violations against AXI4 spec section 3.1."

T6

Request multiple alternatives

Ask: "Give me 3 implementations of this arbiter — round-robin, priority, and weighted — with a tradeoff table. I'll pick based on area budget." Claude is best when comparing options.

Start Using Claude for VLSI Today

Free tier available at claude.ai — no credit card required. For team use, Claude's API integrates directly into your EDA flow scripts, Confluence pages, and CI pipelines.

Open Claude.ai Back to RTL Design Guides
Common Questions
How can Claude help RTL design engineers?

Claude generates synthesizable Verilog/SystemVerilog from specs, writes FSMs, reviews CDC issues, explains synthesis warnings, and produces testbenches. It handles parameterized designs, AXI/APB interfaces, and standard cell-aware coding patterns.

Can Claude write SystemVerilog assertions?

Yes — Claude generates concurrent SVA properties, sequences, and cover points from plain English. Describe the protocol behavior and it produces the assertion. Always simulate to confirm the assertion fires correctly on both passing and failing cases.

Is Claude useful for STA?

Claude interprets Primetime and Tempus reports, explains setup/hold violations, writes SDC constraints, debugs false path exceptions, and explains OCV/CPPR concepts. Paste the exact timing path report for best results.

Is it safe to paste proprietary RTL into Claude?

Review your company's IP policy first. For proprietary designs, use Claude via API with data privacy agreements, or use anonymized/abstracted versions of the code for review. claude.ai Pro/Team plans have stronger data handling commitments — check Anthropic's terms for your organization.

What are the best prompting practices for VLSI?

Always specify the target tool (Vivado, DC, Innovus), technology node, clock frequency, and exact constraints. Use role-priming. Paste full artifacts — not summaries. Ask for explanations alongside code. Verify all generated RTL through your lint/simulation/synthesis flow.

Claude for VLSI — Step-by-Step Series

9 in-depth guides taking you from zero to expert. Start at Step 1 or jump to your engineering domain.

STEP 1 ✓ Available
How Claude Works
LLM basics, tokenization, context window, training data for VLSI
STEP 2 ✓ Available
Setup & Settings
Account, Projects, system prompts, file uploads, API
STEP 3 ✓ Available
Master Claude
Chain-of-thought, few-shot, iterative refinement, adversarial review
STEP 4 Coming Soon
RTL Engineer Guide
FSM, FIFO, AXI, code review, 10+ real prompts
STEP 5 Coming Soon
DV Engineer Guide
SVA, UVM, coverage, testbench, debug workflow
STEP 6 Coming Soon
STA Engineer Guide
Timing reports, SDC, OCV/CPPR, ECO, slack analysis
STEP 7 Coming Soon
Physical Design Guide
Floorplan, CTS, Tcl, DRC, ECO, Innovus/ICC2
STEP 8 Coming Soon
CDC Engineer Guide
Synchronizers, MTBF, SpyGlass, Gray FIFO, handshake
STEP 9 Coming Soon
Synthesis Engineer Guide
DC, Yosys, QoR, retiming, area/power optimization
RTL Design CDC Deep Dive STA Guide Memory Design