Master Claude

# Timing path debug — chain of thought
I have a setup violation on path: FF_A/Q → combo_logic → FF_B/D
Slack = -0.34 ns at 1GHz. Think step by step:
1. Identify the likely root cause (long logic depth / high fanout / routing)
2. Calculate how much improvement each fix would give
3. Rank the fixes by effort vs. gain
4. Give me the exact Tcl command for the highest-ROI fix in DC

# FSM completeness check — chain of thought
Here is my Verilog FSM. Before telling me if it's correct:
Step 1: List all states and transitions you can see
Step 2: Check if every state has a transition for every input combination
Step 3: Check for any unreachable states
Step 4: Identify any latch inference risks
Then give me the final verdict with specific line numbers.

# Role stacking — get multiple expert perspectives in one shot
Review this AXI4 slave RTL from THREE perspectives:

1. As a senior RTL designer: check synthesizability and coding style
2. As a DV engineer: identify what test cases would break this
3. As an STA engineer: flag any timing concerns from the logic structure

Provide each perspective as a separate section.

[paste your RTL here]

# Tell Claude to format issues like your lint tool
When you find issues in my RTL, report them in this exact format:

[SEVERITY] FILE:LINE — RULE — Description of issue
  Suggested fix: <one line fix>

Example:
[ERROR] fifo.sv:47 — NB-ASSIGN — Blocking assignment in clocked always block
  Suggested fix: Change `=` to `<=`

[WARN] fifo.sv:112 — RESET-INCOMPLETE — Signal rd_ptr not reset
  Suggested fix: Add `rd_ptr <= '0;` in reset block

Now review this module and report all issues in the above format:
[paste RTL]

Prompt 1: Outline
"Outline the key design decisions for a 512-depth, 32-bit wide synchronous
FIFO with full/empty flags. List: (1) address tracking approach,
(2) full/empty generation logic, (3) any timing risks."

Prompt 2: Skeleton
"Good. Now write the module skeleton — just the port list, parameters,
and internal signal declarations. No logic yet."

Prompt 3: Core Logic
"Now fill in the write and read pointer logic with non-blocking assignments.
Full/empty generation only — no output assignments yet."

Prompt 4: Edge Cases
"Now add handling for: simultaneous read+write when nearly full,
and the condition where rd_ptr wraps around past wr_ptr."

Prompt 5: Assertions
"Add 3 SVA assertions checking: (1) no write when full,
(2) no read when empty, (3) pointer separation never exceeds DEPTH."

Prompt 6: Review
"Now act as an adversarial reviewer. What could go wrong with this FIFO
under corner-case inputs? Focus on metastability and overflow."

# After getting Claude to write/review code, follow with:

You just reviewed this RTL and said it looks correct. Now switch roles.
Act as an adversarial verification engineer whose job is to find a bug
that slips through the review.

Ask yourself:
- What happens at reset edge cases?
- What if two signals change simultaneously?
- What is the behavior at power-of-2 boundaries?
- What if the input violates the protocol spec by 1 cycle?

Report any vulnerabilities you find, even theoretical ones.

# Force JSON output for automated processing
Analyze this timing report and return ONLY a JSON array.
No prose, no explanation — just the JSON.

Format:
[
  {
    "path_id": "string",
    "startpoint": "string",
    "endpoint": "string",
    "slack_ns": float,
    "root_cause": "logic_depth|fanout|routing|sdc",
    "fix_priority": 1-5,
    "recommended_fix": "string"
  }
]

[paste timing report here]

# Force table output for review spreadsheet
Review this RTL and output a markdown table with columns:
| Line | Severity | Rule | Issue | Fix |

Severity levels: CRITICAL / WARNING / INFO
One row per issue found.

Act as a senior VLSI design and verification engineer with 15 years of ASIC experience.

CONTEXT: I am designing [MODULE NAME] for [PROJECT/CHIP] targeting [TECHNOLOGY NODE].
Tool flow: [list your tools]. Target clock: [frequency]. RTL standard: [Verilog 2001 / SystemVerilog 2012].

TASK: [Your specific ask]

CONSTRAINTS:
- Synthesizable only (no simulation-only constructs)
- Non-blocking assignments in all clocked always blocks
- Named begin/end blocks for readability
- [Any other style rules]

OUTPUT FORMAT:
1. Summary of what you found/did (3 sentences max)
2. Code/fixes (if applicable)
3. List of remaining concerns or edge cases I should verify

Think step by step before answering.

[PASTE YOUR CODE/REPORT HERE]

Act as a silicon-experienced debug engineer.

SYMPTOM: [Exact description of the failure — waveform behavior, assertion, sim error]
EXPECTED: [What should happen]
ACTUAL: [What is happening]

Step 1: Identify the top 3 most likely root causes ranked by probability
Step 2: For each cause, describe what signal/line in the RTL to check
Step 3: Suggest the minimum-diff fix that addresses the most likely cause
Step 4: List one test vector that would confirm your hypothesis

Here is the relevant RTL:
[paste RTL]