Development with AI Agents

1. Flash — Introduction

What is Flash?

Flash is a Rust-based domain-specific compiler for the DPU's programmable flow processors (SGE, PTA) and FlexLSO. It compiles .flash programs into JSON artifacts that FunOS loads to program hardware TCAM/instruction memory at runtime.

Pipeline: Source → Scanner (47 tokens) → Parser (recursive descent) → Semantic Model → Encoder → JSON + C bindings

The Flash pipeline

The 📐 Interactive Flash Architecture Diagram provides a detailed clickable view of the compiler internals.

2. Flow Processor TCAM — Structured Match Syntax

The first project was improving how TCAM entries are expressed in Flash. The SGE flow processor has 128 TCAM entries with a 68-bit key — but the flow syntax treated it as opaque hex.

Asking the AI to analyze the problem

flow {
    mask  0xF0000
    match 0x200000
    action do_stuff
}

The transformation

flow {
    mask  0xf000_0000_0000_0000
    match 0x2000_0000_0000_0000
    action sq_db
}

key sge_keygen_key @ message {
    msg_type  : 4
    sid       : 1
    cid       : 1
    thd_id    : 2
    queue_type: 2
    ...
}

flow {
    match sge_keygen_key {
        msg_type == MSG_TYPE_SQ_DB
    }
    action sq_db
}

The compiler resolves field names to bit positions, computes mask/value automatically, and validates overlaps and exhaustiveness at compile time.

3. FlexLSO — From RTL Analysis to Real Programs

Inspired by the TCAM work, the next question was: can we extend Flash to handle FlexLSO — a major new S3 hardware block with no prior SW support? This section shows the deliberate approach used to develop it end-to-end.

Phase 1: Start with RTL analysis

Rather than jumping to implementation, the first step was having the AI read and understand the actual hardware — legacy LSO RTL and the new FlexLSO instruction set.

This produced a comprehensive 850-line specification extracted from RTL — covering command structures, header stack types, per-packet modification logic, and the 5-stage data pipeline.

Phase 2: Design through Q&A

Before writing any code, the approach was to have the AI propose and then ask clarifying questions. This back-and-forth — 12 clarifying questions across multiple rounds — iterated on key design decisions before a single line of code was written.

// Before (raw offsets):
compute fix.seq_num + flex.tcp_seq_num_inc
    -> swap header[16, 4]

// After (symbolic):
line inner_l4 -> stack(0) as tcp : tcp_hdr_t {
    compute fix.seq_num + flex.tcp_seq_num_inc
        -> swap tcp.seq_num
}

Phase 3: Implementation + Rapid iteration

With the design settled, the AI implemented the full compiler in one session, followed by iterative program development with constant human feedback.

Catching real errors

Design specs

📄 FlexLSO Compiler Proposal 📄 FlexLSO Programs Design

4. HRW — Closing the Loop with Real Traffic

FlexLSO was complete but couldn't be traffic-tested (S3 ETP refmodel not available). The next step was to apply the same approach to HRW (Header Rewrite) on S2, where existing ref model + tests could validate actual datapath behavior.

Design-first approach

Full pipeline: Compiler → Loader → Datapath

Unlike FlexLSO, HRW was carried all the way through to real traffic flowing through the HW reference model.

Design spec

📄 HRW Flash Compiler Spec (~1000 lines)

5. Lessons Learned — What Works and What Doesn't

The key insight

6. The Repeatable Workflow

The same pattern was used successfully across all three areas:

7. Session Logs & Resources

Full session histories

Code repositories

Interactive tools

📐 Flash Architecture Diagram — clickable, searchable view of the compiler internals