Guides, API reference, and tutorials for AI-powered verification.
Get up and running in under 5 minutes.
ChipPilot requires Python 3.9+ and pip. Optional dependencies include Verilator, VCS, or Xcelium for simulation, and SymbiYosys or JasperGold for formal verification.
ChipPilot uses LLM providers to power its AI pipeline. Set your API key as an environment variable:
llm_provider: ollama in config)For server-side authentication, set CHIPPILOT_AUTH_TOKEN for Bearer token access. See the Authentication Guide for full details.
ChipPilot is configured via chippilot.yaml in your project root. Key configuration options:
Run chippilot config show to display current settings, or chippilot config set <key> <value> to modify individual options.
Follow these steps to go from zero to a verified design:
The pipeline will iteratively generate, compile, simulate, and refine your verification environment until coverage targets are met or max iterations are reached.
The ChipPilot VS Code extension is coming soon. It will provide inline lint annotations, one-click UVM generation, real-time coverage overlays, and evidence graph visualization directly in your editor. Stay tuned for updates.
ChipPilot uses a modular agent architecture with a central Orchestrator that coordinates specialized agents (UVM, Formal, Lint, Regression). Each agent operates in a closed-loop cycle: plan → generate → compile → simulate → refine → converge. The Orchestrator manages iteration counts, convergence criteria, and cross-agent dependencies.
Each agent exposes a set of skills — discrete verification tasks such as "generate UVM sequence", "create SVA assertion", or "run lint check". Skills are composable and can be chained by the Orchestrator to build complex verification workflows. The skill registry is extensible via plugins.
Evidence graphs provide full traceability from requirements to verification artifacts. Each node represents a verification artifact (assertion, coverage point, test) and edges show derivation relationships. Graphs are generated as interactive HTML reports that link assertions to RTL lines, coverage holes to test gaps, and failures to root causes.
ChipPilot abstracts LLM interactions behind a unified provider layer supporting OpenAI, Anthropic, and Ollama. Prompts are managed via Jinja2 templates in src/chippilot/templates/. The LLM layer handles retries, token budgeting, and structured output parsing. A policy engine sanitizes all prompts to prevent injection attacks.
ChipPilot supports custom plugins for extending tool runners, adding new lint rules, or integrating with proprietary EDA tools. Plugins are discovered via Python entry points and can register new skills, tool backends, or report formatters.
The Auto-UVM pipeline analyzes your RTL to extract port lists, clock/reset signals, and protocol interfaces. It then uses LLM-powered generation to produce a complete UVM environment including: top-level testbench, environment, agent(s), driver, monitor, sequencer, scoreboard, and coverage model. The pipeline compiles and simulates iteratively, refining generated code until compilation succeeds and coverage targets are met.
ChipPilot uses Jinja2 templates (.sv.j2 files) to generate SystemVerilog testbench components. Templates are located in src/chippilot/templates/ and can be customized per project. Template variables include module name, port lists, clock domains, and protocol-specific parameters. Override default templates by placing custom .sv.j2 files in your project's templates/ directory.
ChipPilot auto-generates UVM scoreboards that compare expected vs. actual outputs. The LLM analyzes your RTL's functional behavior to create a reference model inside the scoreboard. Scoreboards support in-order and out-of-order comparison, configurable tolerance for floating-point designs, and automatic error reporting.
Coverage models are synthesized by analyzing RTL control paths and generating covergroups that target branch coverage, toggle coverage, FSM state coverage, and cross-coverage of key signals. The pipeline tracks functional coverage during simulation and reports coverage metrics in the final evidence graph.
Define custom constraints in your chippilot.yaml or via inline directives in your RTL. Constraints guide the UVM sequence generator to focus on specific scenarios, boundary conditions, or protocol corner cases. ChipPilot merges user-defined constraints with auto-discovered ones from RTL analysis.
ChipPilot uses AI to automatically generate SystemVerilog Assertions from your RTL. The formal agent analyzes signal relationships, protocol specifications, and design intent to synthesize meaningful properties including safety checks (no-X propagation), liveness properties, and protocol compliance assertions. Generated SVA is placed in dedicated assertion files alongside your RTL.
Ensure your chippilot.yaml specifies the formal tool: formal_tool: sby (SymbiYosys) or formal_tool: jasper (JasperGold).
ChipPilot integrates with SymbiYosys (open-source) and JasperGold (commercial) for bounded model checking. Properties are proved or disproved up to a configurable depth. The tool automatically generates .sby task files, runs the solver, and parses results back into the evidence graph.
When assertions fail, ChipPilot's assumption mining discovers the minimal set of environmental assumptions needed to make properties hold. This helps identify missing constraints or incorrect interface assumptions, reducing false negatives in formal runs.
When a formal property fails, ChipPilot extracts the counter-example trace and uses LLM analysis to explain the failure in natural language. The analysis identifies which signals transitioned unexpectedly, maps them to RTL source lines, and suggests potential fixes — feeding directly into the next refinement iteration.
Lint rules are configured in your chippilot.yaml under the lint_rules key. Built-in rules include no-latches, no-x-assign, clk-edge-consistency, reset-polarity, and signal-naming conventions. Enable or disable individual rules, set severity levels (error, warning, info), and configure rule-specific parameters.
ChipPilot lint results can be integrated into your IDE workflow via standard output formats. JSON output (chippilot lint --format json) is compatible with popular editor plugins. A dedicated VS Code extension with inline annotations is planned for a future release.
Integrate ChipPilot linting into your CI/CD pipeline with a single command. Use chippilot lint --format json --exit-code to return non-zero on lint failures. Compatible with GitHub Actions, GitLab CI, Jenkins, and CircleCI. Example GitHub Actions step:
The regression runner orchestrates large-scale test suites across multiple simulators. It supports parallel execution, seed management, and automatic re-run of failed tests. Configure regression suites in chippilot.yaml and launch with chippilot run --regression.
When tests fail, ChipPilot automatically clusters failures by error signature, stack trace similarity, and signal patterns. The triage algorithm uses LLM analysis to group related failures and identify the most likely root cause for each cluster, reducing manual triage effort by up to 10×.
Failed tests are ranked by blast radius — the number of downstream tests affected by each root cause. The ranking algorithm considers failure frequency, signal correlation, and historical fix patterns to prioritize which issues to address first.
ChipPilot can automatically create Jira tickets or GitHub Issues for triaged failures. Each issue includes the failure cluster summary, affected tests, suggested root cause, and links to relevant RTL lines and waveform snapshots.
The RTLGenAgent generates SystemVerilog RTL from high-level descriptions. It supports module generation with configurable ports and parameters, FSM synthesis from state/transition definitions, and protocol adapter generation for industry-standard interfaces.
Generate complete SystemVerilog modules with generate_module(). Specify ports, parameters, and a natural-language description. The agent produces synthesizable RTL with proper clock/reset handling, parameterization, and coding style compliance.
Generate finite state machines with generate_fsm(). Define states and transitions as Python lists and dicts. The agent produces a well-structured FSM with proper encoding, reset handling, and state transition logic following best practices.
Generate protocol interface adapters with generate_interface_adapter(). Supports APB and AXI protocols with configurable data and address widths. Produces compliant bus interfaces ready for integration.
The TestPlanAgent generates structured verification test plans. It can work from design specifications (ports, FSM states, interfaces, requirements) or by directly analyzing RTL source code to extract testable features automatically.
Use generate_plan() with ports, FSM states, interfaces, and requirements to create a comprehensive test plan. Each test item includes priority, description, and coverage targets aligned with your design requirements.
Use generate_from_rtl() to automatically analyze RTL source code. The agent extracts ports, detects FSM states, identifies interfaces, and generates test items covering functional paths, boundary conditions, and corner cases.
The CDCAgent detects clock-domain crossing issues by analyzing RTL for multiple clock domains, identifying signals that cross boundaries, and checking for proper synchronization. It flags unsynchronized crossings and metastability risks.
The agent automatically identifies all clock domains in the design by analyzing always_ff blocks and their clock edge sensitivities. Each domain is tracked with its associated registers and combinational logic cones.
Use check_synchronizer() to verify that a specific signal has proper multi-flop synchronization when crossing clock domains. The agent checks for standard 2-FF synchronizer patterns and reports missing or insufficient synchronization.
Signals crossing clock domains without proper synchronization are flagged as metastability risks. The report includes the source and destination clock domains, the crossing signal, and recommended synchronization schemes (2-FF, handshake, FIFO-based).
The TimingAgent performs static timing analysis on RTL, identifying critical paths, estimating logic depth, and detecting setup/hold violations based on the configured clock period.
The agent traces combinational paths between registers to identify the longest (critical) paths in the design. Each path includes start/end points, estimated logic depth, and propagation delay relative to the clock period.
Paths with estimated delays exceeding the clock period are flagged as potential setup violations. The report includes violation severity, slack, and suggestions for pipelining or logic restructuring to meet timing constraints.
Use estimate_logic_depth() to get per-signal depth estimates. This helps identify complex combinational cones that may cause timing issues, enabling early architectural decisions about pipeline stages.
The PowerAgent analyzes RTL for power characteristics, estimates switching activity, and identifies clock-gating opportunities to reduce dynamic power consumption.
Use estimate_switching_activity() to get per-signal toggle rate estimates. High toggle-rate signals are candidates for optimization through gating, encoding changes, or architectural restructuring.
The agent identifies register banks that toggle unnecessarily when their outputs are unused. These are reported as clock-gating opportunities with estimated power savings and suggested gating conditions.
Based on the analysis, the agent provides actionable suggestions including clock gating, operand isolation, memory banking, and data encoding optimizations to reduce overall power consumption.
The DRCAgent checks RTL against design rules covering naming conventions, synthesis rules, structural rules, and coding guidelines. It supports custom rules and waiver management for known exceptions.
Enforces consistent naming for modules, signals, ports, and parameters. Default rules require lowercase with underscores for signals, uppercase for parameters, and module names matching file names.
Detects common synthesis issues including inferred latches, mixed blocking/non-blocking assignments, incomplete sensitivity lists, and multi-driven signals. Each violation includes the specific rule ID and remediation guidance.
Use add_waiver() to suppress known violations with documented reasons. Waivers can be scoped to specific modules or global. Waived violations are tracked separately in the report for audit compliance.
The DebugAgent automates root-cause analysis of simulation failures. It parses simulation logs, identifies failure patterns, analyzes assertion failures with trace context, and suggests which waveform signals to observe for debugging.
The agent parses simulation logs to extract failure events, assertion violations, and timeout errors. It uses LLM analysis to correlate failures with RTL source code and suggest root causes with confidence scores.
The WaveformAgent parses VCD (Value Change Dump) files to extract signal transitions. Use analyze_failure() to examine waveform data around a failure time point and identify the sequence of events leading to the failure.
The BugReporter generates structured bug reports from verification findings. It deduplicates similar findings, generates detailed reports with context, and formats output for Markdown documentation or JIRA issue tracking integration.
The DesignSpaceExplorer evaluates PPA (Power, Performance, Area) trade-offs across design configurations. It identifies Pareto-optimal design points and supports parameter sweeps for systematic exploration.
Evaluate design points across power, performance (frequency, latency), and area dimensions. Each point is characterized by its parameters and measured PPA metrics for comparison.
The explorer identifies Pareto-optimal designs — configurations where no single metric can be improved without degrading another. This helps designers make informed trade-off decisions.
Use sweep_parameter() to systematically vary a design parameter (e.g., data width, FIFO depth) across a range of values and collect PPA metrics for each configuration.
Enterprise RBAC provides three roles: Viewer (read-only), Operator (run pipelines), and Admin (full configuration access). Roles are enforced at the API layer with hierarchical permissions. Assign roles per project or organization.
Enterprise plans support SAML 2.0 SSO integration with identity providers including Okta, Azure AD, and OneLogin. Configure SSO in your organization settings to enable single sign-on for all team members.
Deploy ChipPilot entirely within your private infrastructure with no internet connectivity required. Air-gapped mode uses local Ollama models for LLM inference and includes all dependencies in a self-contained Docker image. See the Deployment Guide for details.
Every action in ChipPilot is logged with timestamp, user identity, action type, and affected resources. Audit logs are stored in structured JSON format and can be forwarded to your SIEM system for compliance and security monitoring.
Complete command-line reference for all ChipPilot commands: init, run, status, config, verify, lint, report, serve, and version. Each command supports --help for detailed usage. See the full CLI Reference documentation.
Use ChipPilot programmatically via the Python SDK. Import chippilot.core to access the Orchestrator, Config, and Agent APIs directly. The SDK supports async execution and integrates with Jupyter notebooks for interactive exploration.
ChipPilot exposes a FastAPI-based REST API with endpoints for project management, pipeline execution, configuration, and reporting. WebSocket support is available for real-time pipeline status updates. See the full API Reference.
Configure webhooks to receive notifications when pipeline runs complete, coverage targets are met, or critical failures are detected. Webhook payloads include run summary, coverage metrics, and links to generated reports.