Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

rtl-lint-auditor

Estrelas4

Forks3

Atualizado26 de abril de 2026 às 03:29

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.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

asicdesign-ai

asicdesign-ai/asic-ai-workflows

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Analistas de garantia de qualidade de software e testadoresInformática e Matemática·SOC 15-1253

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.

Mais deste repositório

mesmo repositório

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-274

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-274

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-264

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-084

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-084

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-084

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.