Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

rtl-lint-auditor

Review synthesizable SystemVerilog for static RTL issues such as inferred latches, reset mismatches, width hazards, and multi-driver structure. Use this skill whenever generated RTL needs a deterministic front-end lint audit before CDC, RDC, or timing review.

Ejecutar en Manus

Resumen

Comando de instalación

npx skills add https://github.com/asicdesign-ai/asic-ai-workflows --skill rtl-lint-auditor

Copia y pega este comando en Claude Code para instalar la habilidad

Fuente

asicdesign-ai/asic-ai-workflows

Estrellas3

Forks2

Actualizado26 de abril de 2026, 03:29

SKILL.md

readonly

name	rtl-lint-auditor
description	Review synthesizable SystemVerilog for static RTL issues such as inferred latches, reset mismatches, width hazards, and multi-driver structure. Use this skill whenever generated RTL needs a deterministic front-end lint audit before CDC, RDC, or timing review.

RTL Lint Auditor Skill

Audit block-level SystemVerilog for front-end lint issues and emit one deterministic finding report.

Scope: block or small IP. This is a static lint audit, not an EDA signoff run.

Rules

Apply these repo rules before analysis and output generation:

../../rules/common/evidence-grounding.md
../../rules/common/output-discipline.md
../../rules/common/tool-evidence-provenance.md
../../rules/rtl/synthesizable-systemverilog.md
../../rules/rtl/lint-severity.md

Analysis

Read the RTL and perform these steps:

If project_root, source files, or a filelist are provided and HDL/EDA MCP tools are available, collect read-only compiler or lint evidence before finalizing findings.
Identify structural lint issues that can be proven from the provided RTL text or tool evidence.
Classify each issue with the severity mapping in ../../rules/rtl/lint-severity.md.
Mark critical and high findings as blocking.
Suggest the smallest valid fix for blocking issues.
Emit an empty findings list when the RTL is clean under this rule set.

Optional MCP Evidence Intake

When MCP tools are available, use them as evidence sources before finalizing findings. Discover tools by schema and description, not by vendor name. Prefer read-only HDL/EDA tools that provide parse/elaboration diagnostics, design-unit inventory, hierarchy, symbol lookup, or lint-rule-deck reports.

pyslang-mcp can ground front-end diagnostics, module descriptions, hierarchy, and symbol references. Useful calls include pyslang_parse_filelist or pyslang_parse_files, pyslang_get_diagnostics, pyslang_list_design_units, pyslang_describe_design_unit, pyslang_get_hierarchy, and pyslang_find_symbol. Treat pyslang-mcp as compiler-backed context, not as a replacement for a full lint deck.

For vendor or internal EDA MCPs, use tools only when their schema clearly exposes read-only parse/elaboration diagnostics, lint report retrieval, design-unit or hierarchy queries, symbol lookup, or waiver/status lookup that is explicitly in scope. Do not assume public vendor MCP support or hard-code tool names.

Normalize every tool finding into this skill's deterministic YAML severity model. Do not blindly copy vendor severities when they conflict with ../../rules/rtl/lint-severity.md; preserve original tool rule IDs, severities, or diagnostics only as evidence metadata.

Do not claim lint cleanliness solely because pyslang-mcp returns zero diagnostics. That means the design parsed under that frontend; text-grounded lint hazards can still remain.

If MCP evidence is unavailable, incomplete, or returns a structured tool error, continue with text-grounded analysis and record the limitation in tool_evidence when a tool path was attempted. Emit tool_evidence: [] when no MCP evidence was used. When tool evidence is present, each entry must contain source, tools, purpose, status, and summary. Do not invoke destructive, synthesis, simulation, CDC, timing, or RTL-editing tools from this skill.

Output Format

Produce a single YAML document:

design:
  top_module: event_counter
  rtl_files:
    - rtl/event_counter.sv

findings:
  - id: LINT-001
    severity: high
    category: latch
    file: rtl/event_counter.sv
    line: 27
    message: "The combinational next-state block leaves irq_nxt unassigned on one branch."
    recommendation: "Assign irq_nxt on every path or provide a default assignment before the branch tree."
    blocking: true

tool_evidence: []

summary:
  total_findings: 1
  blocking_findings: 1
  by_severity:
    critical: 0
    high: 1
    medium: 0
    low: 0
    info: 0

Scope Limitations

Can do: flag code-local lint hazards grounded in the RTL text.
Cannot do: replace full lint tool rule decks, prove CDC safety, or prove implementation timing.

Más de este repositorio

mismo repositorio

hdl-design-view-extractor

asicdesign-ai/asic-ai-workflows

Extract a source-grounded, AI-readable textual design view from HDL source, parser output, MCP tool output, or model reasoning. Use this skill when the user needs Verilog, SystemVerilog, VHDL, or proprietary hardware description language normalized into a reusable design view for downstream analysis flows such as timing, lint, CDC, RDC, formal planning, or DV planning. Prefer UHDM text for SystemVerilog/Verilog when available, AST JSON when UHDM is not available, and explicit model-derived views only when no tool evidence exists.

2026-04-273

rtl-timing-analyzer

asicdesign-ai/asic-ai-workflows

Analyze an HDL design view or visible RTL for pre-synthesis timing risk by estimating combinational logic depth on register-to-register and boundary timing paths. Use this skill when the user already has a UHDM text dump, AST JSON, source-grounded textual design view, or small visible RTL block and asks for critical paths, deep combinational logic, reg-to-reg timing risk, or pre-synthesis timing feedback. This skill is analysis-only; use an HDL-design-view extraction skill or flow when parser/tool/MCP selection, source-language normalization, or design-view generation is required.

2026-04-273

rtl-designer

asicdesign-ai/asic-ai-workflows

Read an approved microarchitecture specification and emit synthesizable SystemVerilog with requirement traceability. Use this skill whenever the flow moves from block architecture into concrete RTL implementation.

2026-04-263

block-requirements-normalizer

asicdesign-ai/asic-ai-workflows

Normalize a block-level design brief into deterministic requirements, explicit PPA targets, and open intake questions. Use this skill whenever the user provides high-level microarchitectural intent and the workflow must capture power, performance, and area before specification or RTL work begins.

2026-04-083

block-rtl-package-assembler

asicdesign-ai/asic-ai-workflows

Assemble normalized requirements, the microarchitecture spec, generated RTL, and static audit summaries into one front-end handoff package. Use this skill whenever the block-level RTL planning flow needs one deterministic output that can feed downstream DV planning.

2026-04-083

microarchitecture-spec-author

asicdesign-ai/asic-ai-workflows

Turn normalized block requirements into a Markdown microarchitecture specification with requirement traceability and targeted diagrams. Use this skill whenever the workflow needs a deterministic architecture document before RTL generation.

2026-04-083

Fuente

asicdesign-ai

asicdesign-ai/asic-ai-workflows

Abrir repositorio de GitHub Ver repositorios del creador

Comando de instalación

Descarga

Ejecutar en Manus

Útil paraSOC

Analistas de garantía de calidad de software y probadoresOcupaciones informáticas y matemáticas15-1253L4

name	rtl-lint-auditor
description	Review synthesizable SystemVerilog for static RTL issues such as inferred latches, reset mismatches, width hazards, and multi-driver structure. Use this skill whenever generated RTL needs a deterministic front-end lint audit before CDC, RDC, or timing review.

RTL Lint Auditor Skill

Audit block-level SystemVerilog for front-end lint issues and emit one deterministic finding report.

Scope: block or small IP. This is a static lint audit, not an EDA signoff run.

Rules

Apply these repo rules before analysis and output generation:

../../rules/common/evidence-grounding.md
../../rules/common/output-discipline.md
../../rules/common/tool-evidence-provenance.md
../../rules/rtl/synthesizable-systemverilog.md
../../rules/rtl/lint-severity.md

Analysis

Read the RTL and perform these steps:

If project_root, source files, or a filelist are provided and HDL/EDA MCP tools are available, collect read-only compiler or lint evidence before finalizing findings.
Identify structural lint issues that can be proven from the provided RTL text or tool evidence.
Classify each issue with the severity mapping in ../../rules/rtl/lint-severity.md.
Mark critical and high findings as blocking.
Suggest the smallest valid fix for blocking issues.
Emit an empty findings list when the RTL is clean under this rule set.

Optional MCP Evidence Intake

Do not claim lint cleanliness solely because pyslang-mcp returns zero diagnostics. That means the design parsed under that frontend; text-grounded lint hazards can still remain.

Output Format

Produce a single YAML document:

design:
  top_module: event_counter
  rtl_files:
    - rtl/event_counter.sv

findings:
  - id: LINT-001
    severity: high
    category: latch
    file: rtl/event_counter.sv
    line: 27
    message: "The combinational next-state block leaves irq_nxt unassigned on one branch."
    recommendation: "Assign irq_nxt on every path or provide a default assignment before the branch tree."
    blocking: true

tool_evidence: []

summary:
  total_findings: 1
  blocking_findings: 1
  by_severity:
    critical: 0
    high: 1
    medium: 0
    low: 0
    info: 0

Scope Limitations

Can do: flag code-local lint hazards grounded in the RTL text.
Cannot do: replace full lint tool rule decks, prove CDC safety, or prove implementation timing.