IDO
Insight

silicode · 2026-10-30 · 11 min

Auditing AI Generated RTL for Side Channels and Latent Traps

AI generated Verilog often passes functional testbenches while hiding timing side channels and dead state traps. Here is how formal audits secure machine code.

Microchip floorplan showing logic paths and formal verification signal traces in a technical schematic layout.

The IEEE Heterogeneous Integration Roadmap team recently updated Chapter 19 on Cyber Security, focusing on a problem that digital teams have quietly pushed aside for two years: the vulnerability profile of untrusted, automated IP integration. As multi-die packaging mixes chiplets from varied origins and engineering teams use large language models to write bus arbiters, crypto wrappers, and register decoders, the primary failure mode is no longer just broken functional logic. It is non-functional leakage and latent hardware traps that slip through conventional coverage metrics.

When an engineer prompts an LLM to generate an AXI4-Lite crossbar, an AES round controller, or a high-throughput FIFO, the resulting SystemVerilog usually compiles. With minimal prompt engineering, it passes standard directed testbenches. It achieves 100 percent branch and toggle coverage in modern simulators. Yet underneath that clean lint report, machine-generated RTL frequently introduces data-dependent execution jitter, uninitialized register holding states, and state-machine dead zones. These flaws allow physical side-channel extraction or provide trigger payloads for hardware trojans.

For ASIC and FPGA leads carrying tape-out risk, this shifts the signoff problem. A functional bug costs schedule and respin budget. A hardware security escape in high-assurance silicon invalidates the entire silicon tape-out, destroys customer trust, and triggers severe commercial liability. Auditing machine-generated RTL requires moving beyond stimulus-response testbenches and adopting quantitative security metrology, information flow tracking, and unbounded formal property verification before freezing the RTL freeze milestone.

How Machine-Generated Code Introduces Non-Functional Flaws

Neural networks trained on public repositories ingest vast amounts of open-source Verilog. Much of that code was written by university students or hobbyists optimizing for quick functional validation rather than constant-time execution or defensive state-machine design. When an LLM synthesizes an RTL block based on a natural language specification, it prioritizes satisfying the immediate functional prompt over maintaining structural security invariants.

This training bias manifests in three critical design flaws:

1. Timing Jitter in Cryptographic Primitives

In security-critical blocks like modular exponentiation, elliptic curve scalar multiplication, or AES S-box lookups, execution time must remain strictly independent of secret keys or operand values. LLMs frequently insert early-exit optimizations or operand-dependent conditional branching to shorten average latency. While this looks like clever logic optimization on a simulation waveform, it creates variable latency that leaks private keys through simple timing analysis (STA-based execution profiling) or power analysis.

2. Incomplete State Space Coverage and Don't Care Traps

When building Finite State Machines (FSMs), AI models often write case statements without exhaustive state decoding, or they rely heavily on full_case parallel_case synthesis directives. In other instances, models use unspecified default branches that hold previous register states rather than forcing a deterministic reset to a safe state. An attacker who uses power glitching, clock glitching, or specific bus sequences can knock the FSM out of its standard trajectory and trap it in an undocumented privileged mode.

3. Latent Trigger Mechanisms

An LLM generating complex glue logic, such as an AMBA interconnect or DMA scatter-gather engine, sometimes emits complex logical conditions for corner-case handling that mirror the structure of a hardware trojan trigger. These conditions rely on rare combinations of internal counters, parity errors, and specific bus addresses. While rarely inserted with deliberate malice by the model itself, these hallucinated corner cases create reachable states where bus isolation breaks, privilege checks drop, or internal registers leak onto unmonitored debug buses.

+------------------------------------------------------------------------+
|                    Machine-Generated RTL Pipeline                      |
+------------------------------------------------------------------------+
                                    |
                                    v
       [ Prompt: Generate AXI4 Bus Crossbar with Secure Enclaves ]
                                    |
                                    v
       [ LLM Synthesizes Verilog Code: Incomplete Case Decoders ]
                                    |
                                    v
+------------------------------------------------------------------------+
| Traditional Verification (FAILS TO CATCH SECURITY ESCAPES)             |
| - Directed Testbenches: PASSED (Valid addresses route correctly)       |
| - 100% Branch & Toggle Coverage: PASSED (Known states fully covered)   |
| - Standard Linter: PASSED (Clean synthesis, no syntax errors)          |
+------------------------------------------------------------------------+
                                    |
                                    v
+------------------------------------------------------------------------+
| Required Security Auditing Flow (EXPOSES NON-FUNCTIONAL RISKS)         |
| 1. Information Flow Tracking (IFT): Flags data leakage across domains  |
| 2. Unbounded Formal Model Checking: Proves constant-time latency       |
| 3. Reachability & Dead-State Extraction: Flags undocumented transitions|
| 4. Early Power & Activity Metrology: Detects operand-dependent current |
+------------------------------------------------------------------------+

The Blind Spots of Standard Simulation and Coverage

Most front-end verification teams rely on a standard stack: commercial linters, SystemVerilog Assertions (SVA) for protocol compliance, and coverage-driven random testing using UVM (Universal Verification Methodology). These tools answer a specific question: Does the hardware perform the intended function under valid and semi-randomized inputs?

Security verification asks the exact opposite: Does the hardware perform any unintended function under adversarial inputs, fault injection, or side-channel observation?

Consider an AI-generated bus decoder intended to isolate a secure memory region from a non-secure processor core. The model generates the address decoding logic shown below:

module secure_axi_decoder (
    input  wire        clk,
    input  wire        rst_n,
    input  wire [31:0] addr_i,
    input  wire        secure_zone_en,
    input  wire        req_valid_i,
    output reg         access_grant_o,
    output reg         sec_error_o
);

    // Security policy: Address 0x8000_0000 to 0x8000_FFFF is privileged
    always @(*) begin
        sec_error_o    = 1'b0;
        access_grant_o = 1'b0;
        
        if (req_valid_i) begin
            if (addr_i[31:16] == 16'h8000) begin
                if (secure_zone_en) begin
                    access_grant_o = 1'b1;
                end else begin
                    sec_error_o    = 1'b1;
                    access_grant_o = 1'b0;
                end
            end else begin
                // Non-secure address space access
                access_grant_o = 1'b1;
            end
        end
    end

endmodule

In standard functional simulation, this block passes every test. Non-secure requests to 0x8000_XXXX are denied. Secure requests are granted. Requests to other spaces pass freely. The code gets 100 percent toggle and statement coverage immediately.

However, consider the physical and formal flaws:

  1. If addr_i experiences a transient glitch during an address transition while req_valid_i is floating or unlatched, combinational feedthrough immediately grants access to non-secure space for several picoseconds, bypassing the registered clock domain.
  2. The code fails to account for unmapped address spaces or address wrapping conditions where an upper-bit rollover triggers non-secure grants.
  3. The synthesis tool may optimize out portions of the comparison logic if default conditions are improperly constrained upstream, creating an unmonitored path that leaves internal multiplexer controls floating.

Standard functional tests cannot catch these conditions because testbenches rarely assert multi-cycle temporal properties against unintended non-functional pathways.

Formal Security Verification: Information Flow Tracking and Non-Interference

To audit machine-generated RTL before tape-out signoff, teams must deploy formal methods specifically tailored to security properties. The two most effective techniques are Register-Transfer Level Information Flow Tracking (RTL-IFT) and Formal Non-Interference Proofs.

Information Flow Tracking (RTL-IFT)

RTL-IFT tracks the movement of sensitive data (tainted bits) through the design at the register-transfer level. Every register, wire, and logic gate is assigned a shadow security label. If a bit is marked as Secret (such as an encryption key, an internal fuse value, or a secure enclave memory segment), that label propagates through logical operations.

In an RTL-IFT flow, the security rule asserts that no path shall exist where a signal marked Secret can influence the value, timing, or toggle activity of a signal marked Public (such as an external bus, a status register, or a debug port) unless an explicit, authenticated declassification operation occurs.

+---------------------------------------------------------------------+
|                   Illustrative Security Audit Setup                 |
| Setup: Formally verified AXI/Crypto blocks generated by LLM engines |
| Environment: Cadence JasperGold / Synopsys VC Formal Security Apps  |
| Target: Constant-time execution, IFT non-interference, FSM traps    |
+---------------------------------------------------------------------+
| Metric Checked                | Functional Sim | Formal Security    |
+-------------------------------+----------------+--------------------+
| Branch / Toggle Coverage      | 100%           | N/A (Exhaustive)   |
| Data-Dependent Latency Jitter | Undetected     | Flagged (3 cycles) |
| Latent Dead-State Transitions | Undetected     | Flagged (2 states) |
| Register Taint Leakage (IFT)  | Undetected     | Flagged at Port D  |
| Verification Wall-Clock Time  | 12 minutes     | 4.2 hours          |
+-------------------------------+----------------+--------------------+

Note: The table above represents an illustrative composite audit benchmark reflecting representative results across standard commercial formal property checkers applied to generative RTL modules.

Non-Interference Properties with SystemVerilog Assertions

Non-interference proofs verify that low-security observers cannot distinguish between two system executions that differ only in their high-security inputs. This is proven mathematically using miter circuits or dual-run formal models.

In a dual-run setup, two identical instances of the generated RTL module (inst_a and inst_b) are instantiated inside a formal harness. Both instances are driven with identical public inputs, identical initial reset states, and identical bus commands. However, their secret inputs (such as encryption keys or secure registers) are driven with completely different, unconstrained values (key_a versus key_b).

The formal solver is tasked with proving a strict equivalence assertion:

// SystemVerilog Dual-Run Security Assertion
assert_constant_time_and_data_independence:
    assert property (@(posedge clk) disable iff (!rst_n)
        (inst_a.public_output_data === inst_b.public_output_data) &&
        (inst_a.public_ready_signal === inst_b.public_ready_signal) &&
        (inst_a.execution_cycles   === inst_b.execution_cycles)
    )
    else $fatal(1, "Security Violation: Public observation diverges based on secret operand!");

If the formal engine discovers even a single edge-case input sequence where inst_a.public_ready_signal asserts one cycle earlier than inst_b.public_ready_signal, it returns a counterexample. That counterexample is the exact trace needed to identify a timing side channel. Human engineers can spend weeks writing UVM tests without ever stumbling across the precise corner case that an unbounded formal solver extracts in minutes.

Unreachable State Analysis and Trap Detection

Another failure mode in machine-generated code is the introduction of unreachable or orphaned state machine conditions. While human designers often write structured state machines using explicit enumerated types, LLMs frequently generate brittle one-hot or gray-coded state registers with incomplete transition tables.

When synthesis tools encounter these state machines, their standard optimization algorithms map undefined transitions into arbitrary don't-care spaces. In deep submicron nodes (12nm, 7nm, and below), physical phenomena such as single-event upsets (SEU) from radiation, supply voltage droop, or intentional clock glitch attacks can force a flip-flop into one of these undefined states.

If the machine-generated logic lacks a deterministic recovery path, the system either deadlocks (causing a denial-of-service condition) or drops into an unmonitored state where bus access privileges remain asserted from the prior operational cycle.

Extracting Trap States via Formal Model Checking

To detect these traps, the verification flow must mandate an exhaustive Reachability and Dead-State Analysis before logic synthesis. This involves:

  1. State Enumeration Verification: Extracting all $2^N$ possible states for an $N$-bit state register and proving that every state outside the legal operating set has a single-cycle, unconditional transition back to a designated safe-reset state.
  2. Path Invariance Checking: Ensuring that no input sequence exists that allows transition from an illegal state directly into a privileged execution state without asserting the system-wide hard reset line.
  3. Deadlock Detection: Proving that for every reachable state $S_n$, there exists at least one valid input trajectory that transitions the FSM back to the idle state $S_0$ in fewer than $K$ clock cycles, where $K$ is the design's maximum permissible latency bound.
// SVA Assertion for Safe State Machine Recovery
property p_fsm_safe_recovery;
    @(posedge clk) disable iff (!rst_n)
    !($onehot(fsm_state_reg)) |-> ##1 (fsm_state_reg == STATE_SAFE_ERROR);
endproperty

assert_fsm_never_trapped: assert property (p_fsm_safe_recovery)
    else $error("FSM Security Violation: Illegal state does not transition to SAFE_ERROR");

Metrology for Physical Side-Channel Susceptibility

Static and formal checks catch logical and architectural flaws at the RTL boundary, but physical side channels (power consumption and electromagnetic radiation) require dynamic switching metrology. Machine-generated Verilog often produces unbalanced logical trees where the Hamming distance of switching registers varies wildly depending on operand values.

To audit this before committing to physical layout and mask generation, engineering teams must incorporate power-profile metrology into their digital simulation loops:

1. SAIF and VCD Activity Extraction

Simulate the generated block under diverse operational vectors and export detailed Switching Activity Interchange Format (SAIF) or Value Change Dump (VCD) files with gate-level timing annotations.

2. Differential Power Analysis Emulation

Calculate the cycle-by-cycle Hamming Weight (total number of active high bits) and Hamming Distance (number of bit transitions per clock edge) across all data buses and intermediate pipeline registers. If a statistical correlation exists between the Hamming Distance of the internal pipeline and the bits of a private cryptographic key, the RTL contains an exploitable power side channel.

3. Logic Balancing Insertion

Where imbalance is detected, replace machine-generated single-ended arithmetic blocks with dual-rail pre-charge logic or insert cryptographically secure masking (Boolean or arithmetic secret sharing) directly into the RTL pipeline. Masking ensures that every sensitive operation is randomized with an internal entropy source, reducing the correlation coefficient below the noise floor of standard side-channel measurement equipment.

The Pre-Mask Security Signoff Checklist

Before freezing any machine-generated or third-party RTL module for physical synthesis and place-and-route, lead engineers should run the following signoff checklist:

  1. Exhaustive Dual-Run Non-Interference Proof: Formally prove that public outputs, status flags, and ready signals are mathematically independent of private data across all valid and invalid operational modes.
  2. Exhaustive State Machine Enumeration: Confirm that all $2^N$ states in every FSM contain explicit transitions to an error or reset state, verified with unbounded model checking.
  3. RTL-IFT Taint Analysis: Run information flow tracking across clock domain crossings (CDCs), debug registers, and scan chains to verify that tainted secrets cannot leak during test modes (DFT/JTAG).
  4. Constant-Time Execution Verification: Assert that cryptographic and security-critical algorithmic blocks execute in a constant number of clock cycles regardless of key values or plaintexts.
  5. Combinational Glitch Immunity: Verify that security-critical decoders and multiplexers are strictly registered at module boundaries to prevent transient glitch-based privilege bypasses.
  6. Hamming Distance Correlation Metrology: Ensure that gate-level power simulation demonstrates zero statistically significant correlation between operand values and switching activity.

A Pragmatic Role for Verified Code Generation

Generative AI has an undeniable role in accelerating front-end digital design, but treating LLM output as production-ready RTL without mathematical proof is a dangerous gamble. Plausible Verilog is not verified Verilog. The cost of running an automated formal security audit during front-end design is negligible compared to the millions of dollars required for an engineering change order (ECO) or mask respin after physical silicon evaluation.

Automated tools must incorporate closed-loop formal engines directly into their generation pipelines. Systems like Silicode (silicode.ai) reflect this shift by tying generation directly to formal test harnesses, assertion synthesis, and deterministic lint models rather than relying on raw text completion.

Hardware security in the modern chiplet and AI era cannot rely on trust or surface-level code reviews. As integration complexity rises, security must be treated as a first-class mathematical constraint enforced by formal solvers, information flow tracking, and strict physical metrology at every step of the design cycle.

Sources

More Silicode Insight

Hardware SecurityVerilog VerificationRTL GenerationASIC Signoff