Building a Zero Trust Verilator CI Pipeline for AI Verilog

Engineering teams adopting large language models for RTL generation run into the same wall within weeks. Prompting an LLM for an AXI4-Lite slave or a parameterized FIFO yields twenty lines of clean-looking Verilog in three seconds. The engineer glances at the port list, spots no syntax red flags, pastes the module into a branch, and opens a pull request.

Then the synthesis run breaks. Or worse, synthesis succeeds by inferring three unintended transparent latches, quietly masking a missing assignment in a complex case statement. When the block lands in the top-level testbench, debugging the delta-cycle race condition consumes two days of senior engineering time.

Treating generated HDL like human-written code is an operational mistake. When humans write buggy RTL, their errors reflect understandable conceptual misses, such as miscalculating counter overflow bounds or swapping ready/valid handshakes. When neural networks write RTL, their errors often stem from statistical sequence matching. They generate constructs that look idiomatic in procedural C++ but violate basic hardware synthesis semantics.

If you allow AI-generated Verilog into your repository without an automated gatekeeper, you turn your senior verification engineers into manual syntax sanitizers. You need a zero-trust continuous integration pipeline. Every pull request containing generated code must run through pedantic static linting, cycle-accurate Python cosimulation, and bounded formal verification before any human spends thirty seconds reviewing the diff.

The Failure Modes of Plausible Verilog

Language models excel at producing syntactically correct code that passes basic parsers. However, Verilog parsers are notoriously permissive by default. An unassigned wire defaults to a single-bit logic net or produces high-impedance states. A missing default branch in a combinational always @(*) block silently generates a latch.

There are four distinct classes of defects that LLMs introduce into hardware modules with alarming frequency.

1. Inferred Latches from Incomplete Combinational Trees

When an LLM generates a state decoder or an arithmetic control path using always @(*), it frequently leaves output variables unassigned in secondary conditional branches. In pure software, an unassigned branch leaves a variable untouched or undefined. In digital logic, keeping the previous value inside a combinational block forces the synthesis tool to infer level-sensitive latches.

On FPGAs, latches consume precious slice resources and introduce severe static timing analysis (STA) hazards. In ASIC standard-cell flows, unintended latches create testability nightmares and destroy scan chains.

2. Blocking Versus Non-Blocking Mixing

Autoregressive models learn heavily from software repositories alongside open-source Verilog. Consequently, models frequently mix blocking assignments (=) inside sequential clock blocks (always @(posedge clk)) or use non-blocking assignments (<=) inside combinational evaluation blocks.

Mixing these styles creates simulation-synthesis mismatches. The event scheduler in an event-driven simulator updates variables in different delta cycles than the physical hardware registers will exhibit after synthesis.

3. Implicit Width Truncation and Sign Extension

LLMs are weak at arithmetic bit-width tracking across complex expressions. When adding two 8-bit vectors, the model will often assign the result directly back to an 8-bit register without an explicit carry bit, or it will compare signed and unsigned vectors without explicit type casting. The simulator silently truncates the MSB, producing silent data corruption under specific corner-case payloads.

4. Deadlock-Prone Bus Handshakes

In bus protocols like AXI or Wishbone, the valid signal must never depend combinatorially on the ready signal from the receiver. Models frequently write combinational loops where m_axi_wvalid waits for s_axi_wready, while the slave controller waits for m_axi_wvalid before asserting s_axi_wready. The code looks elegant on a pull request diff, but deadlocks the bus on cycle one.

+-------------------------------------------------------------------------+
|                   Zero-Trust Hardware CI Gating Flow                    |
+-------------------------------------------------------------------------+
                                     |
                                     v
                      +-----------------------------+
                      | Step 1: Pedantic Lint       |
                      | Verilator --lint-only -Wall |
                      +-----------------------------+
                                     |
                                     | [Pass: Zero Warnings]
                                     v
                      +-----------------------------+
                      | Step 2: Open-Source Formal  |
                      | SymbiYosys / BMC (20 cycles)|
                      +-----------------------------+
                                     |
                                     | [Pass: Assertions Proven]
                                     v
                      +-----------------------------+
                      | Step 3: Cocotb Cosimulation |
                      | Constrained Random Stimulus |
                      +-----------------------------+
                                     |
                                     | [Pass: 100% Code Coverage]
                                     v
                      +-----------------------------+
                      | Step 4: Human Review & Merge|
                      +-----------------------------+

Step 1: Pedantic Linting with Verilator

Verilator is not just a high-performance cycle-accurate compiler; it contains one of the strictest, most pedantic static analyzers in the semiconductor ecosystem. While commercial simulators often silence warnings to maintain backwards compatibility with legacy 1995-era Verilog, Verilator can be configured to fail immediately on any non-standard or dangerous pattern.

To construct a zero-trust gate, you must run Verilator with lint-only mode and promote critical structural warnings to fatal compilation errors.

Here is a hardened Verilator lint configuration file (rules.vlt) designed specifically to trap LLM hardware hallucinations:

// rules.vlt - Strict Verilator Lint Policies for Generated RTL
`verilator_config

// Turn on all standard lint warnings
lint_on -rule ALWCOMBORDER
lint_on -rule CASEINCOMPLETE
lint_on -rule CASEOVERLAP
lint_on -rule COMBDLY
lint_on -rule IMPLICIT
lint_on -rule LATCH
lint_on -rule MULTIDRIVEN
lint_on -rule UNDRIVEN
lint_on -rule UNUSED
lint_on -rule WIDTH
lint_on -rule WIDTHCONCAT

In your CI runner, invoke Verilator with the following flags. We turn warnings into fatal errors and strictly enforce SystemVerilog 2012 or 2017 syntax:

#!/usr/bin/env bash
set -euo pipefail

MODULE_DIR="./src"
TOP_MODULE="axi_stream_fifo"

verilator \
    --lint-only \
    -Wall \
    -Werror-LATCH \
    -Werror-COMBDLY \
    -Werror-CASEINCOMPLETE \
    -Werror-CASEOVERLAP \
    -Werror-WIDTH \
    -Werror-MULTIDRIVEN \
    -Werror-UNDRIVEN \
    -Werror-SELRANGE \
    -Werror-IMPLICIT \
    -sv \
    rules.vlt \
    -I"${MODULE_DIR}" \
    --top-module "${TOP_MODULE}" \
    "${MODULE_DIR}/${TOP_MODULE}.sv"

echo "[PASS] Static lint clean. No latches, width mismatches, or implicit nets."

Let us break down what these specific flags catch:

• -Werror-LATCH: Halts execution if any combinational path fails to assign an output, preventing inferred latches completely.
• -Werror-COMBDLY: Catches instances where non-blocking delays (<=) or assignment delays (#1) were placed inside combinational blocks.
• -Werror-WIDTH: Fails if an assignment vector width does not match the target register exactly, catching silent MSB drops.
• -Werror-IMPLICIT: Blocks undeclared wires from automatically instantiating single-bit nets, a frequent byproduct of LLM variable renaming.

If the generated code fails any single rule, the pipeline terminates immediately. The PR is blocked before a single clock cycle is simulated.

Step 2: Open-Source Formal Sanity Checks

Static linting checks code topology, but it cannot verify functional properties or state transition safety. Before spending minutes running long dynamic testbenches, the CI pipeline should execute a rapid Bounded Model Check (BMC) using open-source formal tools like SymbiYosys (sby).

A model checking run of twenty cycles can mathematically prove whether an AXI-Stream FIFO drops transactions, allows pointer overflow, or violates handshake contracts.

Consider this compact formal wrapper (fifo_formal.sv) placed alongside the generated FIFO:

`default_nettype none

module fifo_formal (
    input  wire        clk,
    input  wire        rst_n,
    input  wire        wr_en,
    input  wire [31:0] wr_data,
    input  wire        rd_en,
    output wire [31:0] rd_data,
    output wire        full,
    output wire        empty
);

    // Instantiate the generated Unit Under Test
    axi_stream_fifo #(
        .DEPTH(8),
        .DATA_WIDTH(32)
    ) uut (
        .clk(clk),
        .rst_n(rst_n),
        .wr_en(wr_en),
        .wr_data(wr_data),
        .rd_en(rd_en),
        .rd_data(rd_data),
        .full(full),
        .empty(empty)
    );

`ifdef FORMAL
    // Tracking internal transaction volume for mathematical verification
    reg [3:0] count;

    always @(posedge clk) begin
        if (!rst_n) begin
            count <= 4'd0;
        end else begin
            case ({wr_en && !full, rd_en && !empty})
                2'b10: count <= count + 1'b1;
                2'b01: count <= count - 1'b1;
                default: count <= count;
            endcase
        end
    end

    // Formal Assertions
    always @(posedge clk) begin
        if (rst_n) begin
            // Property 1: Cannot be full and empty simultaneously
            a_never_full_and_empty: assert(!(full && empty));

            // Property 2: Must signal full when count reaches max depth
            a_full_flag_exact: assert((count == 4'd8) == full);

            // Property 3: Must signal empty when count reaches zero
            a_empty_flag_exact: assert((count == 4'd0) == empty);

            // Property 4: Write when full must not corrupt count
            if ($past(full) && $past(wr_en) && !$past(rd_en)) begin
                a_overflow_prevented: assert(count == 4'd8);
            end
        end
    end
`endif

endmodule

The corresponding SymbiYosys configuration file (fifo.sby) executes an engine sweep to verify these assertions over twenty timesteps:

[options]
mode bmc
depth 20

[engines]
smtbmc z3

[script]
read -formal -sv rules.vlt
read -formal -sv axi_stream_fifo.sv
read -formal -sv fifo_formal.sv
prep -top fifo_formal

[files]
rules.vlt
./src/axi_stream_fifo.sv
./formal/fifo_formal.sv

In less than five seconds on an off-the-shelf continuous integration runner, the Z3 SMT solver either proves that no sequence of inputs can violate the FIFO's invariant states, or it generates an exact .vcd counterexample trace showing precisely which transaction sequence breaks the state machine.

Step 3: Cosimulation with Cocotb and Verilator

Once static linting passes and formal sanity checks prove boundary invariants, the pipeline must verify full throughput under high randomized load.

Historically, digital verification required cumbersome SystemVerilog UVM (Universal Verification Methodology) harnesses. While UVM remains the standard for top-level ASIC sign-off, setting up complex factory classes for small AI-generated submodules creates friction.

Cocotb (Coroutine Cosimulation Testbench) allows engineers to write verification environments in Python. It communicates directly with Verilator via the standard VPI (Verilog Procedural Interface). You can implement constrained random testing, reference models, and functional coverage monitors in concise Python scripts.

Here is a robust Cocotb test harness (test_fifo.py) that tests backpressure handling and verifies data integrity:

import random
import cocotb
from cocotb.clock import Clock
from cocotb.triggers import RisingEdge, FallingEdge, Timer

@cocotb.test()
async def run_stress_test(dut):
    """Stress-test AI-generated FIFO with random backpressure and concurrent I/O."""
    
    # Generate a 100MHz clock (10ns period)
    clock = Clock(dut.clk, 10, units="ns")
    cocotb.start_soon(clock.start())

    # Initialize inputs
    dut.rst_n.value = 0
    dut.wr_en.value = 0
    dut.rd_en.value = 0
    dut.wr_data.value = 0

    # Apply synchronous reset for 3 cycles
    for _ in range(3):
        await RisingEdge(dut.clk)
    dut.rst_n.value = 1
    await RisingEdge(dut.clk)

    # Software scoreboard reference
    expected_queue = []
    cycles_to_run = 1000

    for cycle in range(cycles_to_run):
        await FallingEdge(dut.clk)
        
        # Generate randomized driving decisions
        will_write = (random.random() > 0.4) and (dut.full.value == 0)
        will_read  = (random.random() > 0.3) and (dut.empty.value == 0)

        dut.wr_en.value = int(will_write)
        dut.rd_en.value = int(will_read)

        if will_write:
            val = random.randint(0, 0xFFFFFFFF)
            dut.wr_data.value = val
            expected_queue.append(val)

        await RisingEdge(dut.clk)
        
        # Sample read output on the following clock cycle
        if dut.rd_en.value == 1 and dut.empty.value == 0:
            await Timer(1, units="ps") # Allow delta cycle propagation
            if len(expected_queue) > 0:
                expected_val = expected_queue.pop(0)
                actual_val = int(dut.rd_data.value)
                assert actual_val == expected_val, (
                    f"Data mismatch at cycle {cycle}! "
                    f"Expected 0x{expected_val:08X}, Got 0x{actual_val:08X}"
                )

    dut._log.info(f"Passed {cycles_to_run} cycles of random backpressure without corruption.")

To execute this testbench inside Verilator, use a standard Makefile configuration:

SIM ?= verilator
TOPLEVEL_LANG ?= verilog

VERILOG_SOURCES += $(PWD)/src/axi_stream_fifo.sv
TOPLEVEL = axi_stream_fifo
MODULE = test_fifo

# Enable coverage collection and C++ compilation flags
EXTRA_ARGS += --coverage --trace-fst

include $(shell cocotb-config --makefiles)/Makefile.sim

Verilator compiles the Verilog module into native C++ code, links Cocotb's Python VPI wrapper, and runs thousands of simulated clock cycles in a fraction of a second. If an LLM miscalculated pointer increments or created an off-by-one index bug under backpressure, Cocotb fails the assertion and exports a .fst waveform for root-cause triage.

Automated CI Pipeline Implementation

You can bundle this entire multi-tier test environment into a GitHub Actions or GitLab CI workflow that runs on every pull request targeting your hardware repository.

Here is a complete, containerized GitHub Actions workflow (.github/workflows/rtl_gatekeeper.yml):

name: Zero-Trust RTL Verification

on:
  pull_request:
    branches: [ main, develop ]
    paths:
      - 'src/**'
      - 'formal/**'
      - 'tests/**'

jobs:
  verify-rtl:
    runs-on: ubuntu-latest
    container:
      image: hdlc/sim:latest

    steps:
      - name: Checkout Repository
        uses: actions/checkout@v4

      - name: Step 1 - Pedantic Verilator Lint
        run: |
          verilator --lint-only -Wall \
            -Werror-LATCH -Werror-COMBDLY -Werror-CASEINCOMPLETE \
            -Werror-CASEOVERLAP -Werror-WIDTH -Werror-MULTIDRIVEN \
            -Werror-UNDRIVEN -Werror-SELRANGE -Werror-IMPLICIT \
            -sv rules.vlt -I./src --top-module axi_stream_fifo ./src/axi_stream_fifo.sv

      - name: Step 2 - Bounded Model Checking (Formal)
        run: |
          sby -f ./formal/fifo.sby

      - name: Step 3 - Cocotb Dynamic Simulation
        run: |
          pip install --no-cache-dir cocotb pytest
          make -f tests/Makefile SIM=verilator

      - name: Step 4 - Line & Toggle Coverage Check
        run: |
          verilator_coverage --annotate ./coverage_report logs/coverage.dat
          # Enforce minimum 95% line coverage
          python3 scripts/verify_coverage.py --threshold 95.0 ./logs/coverage.dat

Pipeline Performance and Defect Isolation

To understand why this layered approach protects engineering time, consider how long each stage takes compared to manual code review.

The table below shows an illustrative composite breakdown of triage time and defect containment across 100 benchmark pull requests containing AI-generated control blocks and bus interfaces:

Data based on composite benchmarks of typical 32-bit FIFO, crossbar, and peripheral controller generation workflows on standard 4-core CI nodes.

Notice the efficiency gains. Over 80 percent of broken AI outputs fail during the first five seconds of linting or formal verification. A developer who receives an automated failure notice within ten seconds can re-prompt or fix the defect locally, without consuming a colleague's review time.

What This Means for Silicode

At Silicode (silicode.ai), we believe that generative AI belongs in chip design only when bounded by deterministic verification. Plausible Verilog without structural proof is a liability, not an asset.

By treating all generated HDL as unverified until proven clean through automated linting, formal contracts, and high-throughput cosimulation, teams can capture the development velocity of AI while preserving tape-out quality.

Practical Checklist for Engineering Leads

Before allowing automated HDL generation tools into your team's day-to-day workflow, implement these five non-negotiable repository guardrails:

1. Ban Direct Commits: Enforce strict branch protection rules on main and develop. No code merges without passing all automated status checks.
2. Promote Lint Warnings to Errors: In your CI scripts, configure -Werror flags for all latch inference, width mismatches, and combinational loop conditions in Verilator.
3. Require Property Assertions: Ensure that all generated state machines or bus interfaces include an accompanying formal property file testing basic protocol invariants.
4. Standardize on Portable Python Testbenches: Use Cocotb to quickly write randomized stimulus tests without requiring multi-thousand-dollar commercial simulator licenses on every build worker.
5. Block on Coverage Thresholds: Automatically fail any pull request that reduces module line or toggle coverage below your established verification floor.

Automating the verification boundary removes the fear of hallucinated hardware. When your pipeline is strict enough to reject subtle mistakes in milliseconds, your team can experiment with modern automation tools without risking a broken chip.

Direct Answer: How to Implement Zero-Trust CI for RTL

To build a zero-trust CI pipeline for AI-generated Verilog, construct a three-tiered automated gating action in your CI runner: first, run Verilator with strict warning-to-error flags (-Werror-LATCH -Werror-WIDTH -Wall) to eliminate structural syntax hazards; second, run SymbiYosys for bounded model checking to mathematically prove protocol assertions; third, execute a randomized Cocotb Python cosimulation suite to verify data integrity under continuous backpressure. Never allow human code review until all three automated stages pass with zero warnings.

Sources

• CHIPS Alliance Verilator Documentation
• Verilator User Guide and Installation Manual
• Cocotb Python Verification Framework Documentation
• Writing Testbenches in Cocotb
• Empowering Chip Designers through LLMs (arXiv)
• When AI Agents Cross Chip Design Silos (Semiconductor Engineering)