verilog-asic-design

name

verilog-asic-design

description

Verilog/SystemVerilog RTL implementation, review, linting, synthesis-oriented debugging, testbench generation, and ASIC flow troubleshooting. Use when the user is working on concrete RTL or verification tasks: writing or modifying .v/.sv modules, reviewing synthesizable logic, generating directed/SystemVerilog/UVM testbenches, fixing lint/synthesis/timing/CDC/reset/DFT issues, or asking ASIC implementation-flow questions tied to RTL, constraints, or EDA reports. Do not use for general electronics, CPU architecture theory, non-RTL programming, vague chip-industry questions, or FPGA/EDA discussion without Verilog/SystemVerilog, synthesis, verification, timing, CDC, DFT, or ASIC-flow work.

Verilog/ASIC Design

Comprehensive digital design assistant for RTL coding, code quality assurance, verification, and ASIC physical design flow.

Use this skill only when the request has a concrete Verilog/SystemVerilog, RTL, verification, synthesis, timing, CDC, DFT, or ASIC-flow artifact to produce, review, or debug. If the user is only asking broad hardware, electronics, chip-industry, or computer-architecture theory questions, answer normally without loading these resources.

Core Capabilities

1. RTL Code Generation — Produce synthesizable Verilog-2001 / SystemVerilog from specifications, block diagrams, or pseudocode.
2. Code Review & Lint — Check for synthesis issues, style violations, and common pitfalls. See references/lint-checklist.md.
3. Testbench Generation — Build simple directed testbenches, self-checking environments, or UVM skeletons that can be extended with drivers, monitors, and scoreboards. See references/testbench-patterns.md.
4. ASIC Flow Guidance — Explain and guide synthesis, SDC constraints, CDC/RDC, DFT insertion, placement & routing, static timing analysis, and low-power intent. See references/asic-design-flow.md.
5. Style & Convention — Apply ASIC-oriented coding standards. See references/verilog-style-guide.md.

Workflow

1. Understand the Request

Identify which capability is needed. Common signals:

• "Write a module that..." → RTL generation
• "Review/lint/check this code" → Code review
• "Generate a testbench for..." → Verification
• "How do I synthesize / write SDC / review CDC / run STA / fix setup violation" → ASIC flow

2. Determine Language Variant

Ask or infer:

• Verilog-2001: Legacy designs, simple combinational/sequential logic, gate-level netlists.
• SystemVerilog: New designs, interfaces, assertions, UVM verification, always_comb/always_ff.

Default to SystemVerilog for new designs unless the user specifies otherwise.

3. Apply Coding Standards

Load references/verilog-style-guide.md when generating or reviewing RTL. Key principles:

• Synthesizable subset only (no delays, no initial blocks for ASIC)
• Explicit clock/reset handling (async reset sync deassert for ASIC)
• Non-blocking assignments (<=) in sequential blocks, blocking (=) in combinational
• Avoid latches; use always_comb / always_ff or always @(*) with complete case/default

4. RTL Code Generation

Given a specification:

1. Define module interface (ports, parameters, clock/reset polarity)
2. Identify datapath vs control logic
3. Write RTL with inline comments explaining intent
4. Add // synthesis translate_on/off pragmas for tool-specific sections if needed
5. Flag any ambiguous requirements and propose assumptions
6. After modifying RTL, re-run scripts/verilog_lint.py to confirm no errors

5. Code Review & Lint

When reviewing user-provided code:

1. Run scripts/verilog_lint.py against the file for automated checks
2. Cross-reference references/lint-checklist.md for manual review items
3. Categorize findings: Error (synthesis fail), Warning (synthesis issue), Style (maintainability)
4. Provide corrected code snippets for critical issues
5. After any RTL modification, re-run lint and confirm zero errors before proceeding
6. Use --mode tb when checking testbench files so initial blocks and delay statements are not treated as RTL errors
7. Use --external auto when available to complement this heuristic linter with an installed formal parser/linter (verilator, verible-verilog-lint, or slang)

6. Testbench Generation

When building verification:

1. Determine testbench style: simple directed, self-checking, or UVM skeleton/component-based
2. Load references/testbench-patterns.md for templates
3. Generate: clock/reset generator, DUT instantiation, stimulus hooks, checker/scoreboard placeholders, waveform dump commands
4. Include coverage collection hints (toggle, FSM, expression) for ASIC sign-off

7. ASIC Flow Guidance

When user asks about physical design:

1. Load references/asic-design-flow.md
2. Identify which step they are on and the specific tool context (Design Compiler, ICC/Innovus, PrimeTime, etc.)
3. Provide tool-agnostic concepts first, then tool-specific commands if requested
4. For timing issues: distinguish setup vs hold, explain data-path vs clock-path debugging
5. For CDC/RDC or reset questions: identify source/destination domains, synchronizer protocol, reconvergence risk, and reset deassertion strategy

Directory of Resources

File	When to Load
references/verilog-style-guide.md	RTL generation, code review, style fixes
references/lint-checklist.md	Code review, lint runs, synthesis debugging
references/testbench-patterns.md	Testbench creation, verification planning
references/asic-design-flow.md	Physical design, synthesis, STA, DFT questions
scripts/verilog_lint.py	Automated static analysis of .v/.sv files
scripts/tb_generator.py	Scaffold generation for directed or UVM skeleton testbench files

Important Notes

• Synthesis target: Default to ASIC-synthesizable subset. FPGA-specific constructs (DSP primitives, block RAM instantiations) only when user explicitly asks for FPGA.
• Clock domains: Flag CDC (clock domain crossing) issues when generating multi-clock designs; recommend synchronizers or handshake protocols.
• Reset strategy: Prefer asynchronous assert / synchronous de-assert for ASIC. Avoid global synchronous reset for large designs.
• Don't guess tool versions: If user mentions a specific tool (Genus, DC, Vivado, etc.), ask for version before giving version-specific TCL commands.