PaperlayerView exact revision on arXiv

Source-linked AI summary

FABRICA: Agentic CUDA-to-CSL Translation and Optimization for Wafer-Scale Systems

Yuebo Luo, Eliu Huerta, Venkatram Vishwanath, Caiwen Ding, Rajeev Thakur, Le Chen

arXiv:2608.25124v1cs.CE

TL;DR

Porting CUDA kernels to CSL requires reconstructing computation and rebuilding placement, communication, storage, tasks, and interfaces for a wafer-scale machine. The paper introduces FABRICA-BENCH and FABRICA, an executable benchmark and agentic workflow using target knowledge, staged repair, execution feedback, and correctness-gated optimization. On the fixed 28-task core, the workflow raises success from 6/28 to 26/28, while broader evaluation and timing results show correct programs across 38/49 tasks and speedups over CSL references.

  • Problem

    CUDA and CSL encode decomposition, locality, synchronization, and observation through substantially different architectural models, while CSL programming resources and learned code are scarce.

  • Method

    FABRICA-BENCH provides 49 executable paired CUDA/CSL tasks, and FABRICA translates and repairs programs through staged agents before optimizing validated CSL against simulator and WSE execution.

  • Results

    26/28 core tasks succeed with the full workflow versus 6/28 from a single generation attempt; 38/49 tasks yield correct programs, and 27 timing-comparable pairs achieve 3.75× simulator and 3.47× WSE-3 geometric-mean speedups.

  • Takeaways & Limitations

    The evidence identifies base-model capability, retrieved target knowledge, execution feedback, failure-directed repair, and same-target measurement as central factors in cross-architecture kernel generation.

  • Takeaways & Limitations

    Coverage counts a task once if any scheduled workflow passes, while the SFT pilot reports structural metrics rather than executable correctness and generated programs still require compilation, numerical checks, and device timing.

Abstract

from arXiv · show

Porting GPU kernels across architectures requires architectural remapping, not syntax substitution. CUDA encodes decomposition, locality, and synchronization through threads, blocks, and memory accesses; the Cerebras Software Language (CSL) requires explicit placement, distributed SRAM, fabric communication, event-driven tasks, and host/device contracts. We present FABRICA-Bench, 49 paired CUDA-to-CSL tasks, and FABRICA, an agentic framework combining target knowledge, execution, failure-directed repair, and correctness-gated optimization. On a fixed 28-task Level~1--3 core comparison with Claude Opus 4.8, FABRICA raises success from 6/28 to 26/28; 22 successful programs match or beat their CSL references. Across the 49-task coverage evaluation, 38 tasks produce a correct program; the final three tasks are evaluated over three seeds and pass 8/9 runs. For 27 generated/reference pairs with device-internal timing, geometric-mean speedup is 3.75$\times$ on the SDK simulator and 3.47$\times$ on WSE-3 hardware. With the executable workflow fixed, Claude Opus~4.8 passes 26/28 core tasks while the best open-weight model passes 2/28; retrieved Cerebras knowledge separately raises success from 1/15 to 7/15 on a Level~1--3 panel. These results identify base-model capability, target knowledge, execution feedback, and same-target measurement as central to cross-architecture kernel generation.

I. INTRODUCTION

CUDA-to-CSL translation requires reconstructing program intent and rebuilding it for a spatial, distributed, event-driven architecture. FABRICA-BENCH and FABRICA address this gap with executable paired tasks and an agentic workflow combining target knowledge, staged repair, execution feedback, and gated optimization.

  • Motivation: CUDA exposes hierarchical threads, blocks, and memory spaces, whereas Cerebras requires explicit placement, distributed storage, communication, tasks, and host/device contracts.The architectural mismatch makes direct syntax substitution insufficient.
  • FABRICA-BENCH: 49 paired CUDA-to-CSL tasks provide validated implementations and execution-based scoring with compilation, numerical checks, held-out inputs, and anti-gaming safeguards.The benchmark joins workload semantics with wafer-scale target mechanisms.
  • FABRICA: FABRICA retrieves Cerebras knowledge and uses staged analysis, architecture design, implementation, failure-directed review, and cycle-gated optimization.A longer repair loop alone does not recover missing target idioms in the reported knowledge-panel comparison.
  • Results: 38/49 tasks produce correct programs in the coverage evaluation, and the final three tasks pass 8/9 seeded runs.For 27 timing-comparable pairs, geometric-mean speedup is 3.75× on the simulator and 3.47× on WSE-3 hardware.

II. BACKGROUND AND RELATED WORK

CUDA and WSE expose fundamentally different execution, memory, communication, and observation models. Effective translation must preserve computation while re-deriving decomposition and constructing spatial dataflow and communication for the wafer-scale target.

  • Architectural contrast: CUDA organizes work around a virtual grid–block–thread hierarchy, GPU memory spaces, warps, runtime block assignment, and synchronization.Its performance vocabulary includes occupancy, coalescing, cache reuse, divergence, and synchronization.
  • Architectural contrast: WSE-3 uses roughly 900,000 processing elements with local distributed SRAM, statically configured fabric routes, layout programs, descriptors, and event- or queue-bound tasks.Host-visible symbols and entry points complete the CSL program.
  • Architectural contrast: The translation changes per-thread execution into persistent PE-tile execution, GPU memory into PE-local SRAM and descriptor-addressed buffers, and dynamic scheduling into compile-time routing plus event-driven execution.Conditions and event triggers become target-specific constructs such as colors, queues, wavelets, and routes.
  • Observability: WSE profiling supplies compiler diagnostics, simulator cycles, timestamps, traces, and memory metadata rather than CUDA metrics such as occupancy and bandwidth.Because the optimization vocabularies barely overlap, target-specific insights must be collected directly.
  • Translation requirements: A translator preserves dependencies and I/O shape, discards GPU-only choices such as block size, and builds PE computation, fabric layout, communication, and host interfaces.Thread indices become PE coordinates plus local loops, while barriers become routing patterns and task activations.

C. Related Work

FABRICA differs from prior CUDA agents and compiler approaches by translating existing CUDA into wafer-scale CSL through controlled workflows and staged construction. Its evaluation separates translation, co-design, optimization, and correctness acceptance.

  • Related systems: Prior CUDA agents combine staged reasoning, profiling, and repeated execution within the familiar GPU model, while KernelCraft targets emerging accelerators without starting from CUDA or targeting a wafer-scale mesh.These differences motivate a distinct cross-architecture setting.
  • Compiler approaches: Compiler-guided repair and hand-built MLIR lowering can provide stronger construction guarantees, but require extensions for each supported representation and domain.Prior WSE work includes stencils, collectives, stencil lowering, and hand-built inference systems.
  • Controlled workflows: W1 fixes the layout and edits only compute CSL, W1-C permits compute/layout co-design, and W2 starts from correct CSL to reduce device cycles.These scopes distinguish synthesis failures from optimization failures and test whether layout causes apparent algorithmic failures.
  • Acceptance: Candidates are staged in fresh reference-bundle clones and evaluated under fixed host interfaces, visible and held-out inputs, compilation, execution, numerical agreement, and valid timing paths.The workflow prevents agents from changing how candidates are tested.
  • Acceptance: Optimization replaces the current best only when the proposed edit satisfies the same validity gate and improves the measured device-cycle objective.A fast but invalid path cannot become optimizer state because winning edits must pass held-out validation.

III. FABRICA-BENCH AND THE FABRICA AGENT

FABRICA-BENCH is an executable paired CUDA/CSL benchmark organized into controlled construction levels and evaluation sets. Its scoring requires executable correctness and uses device-internal cycles for performance assessment.

  • Benchmark construction: 49 executable CUDA/CSL pairs span four levels, with 28 tasks forming the fixed Level 1–3 core for paired workflow and model comparisons.The benchmark includes validated CSL bundles, task descriptions, metadata, and operation families including machine-learning operators and collectives.
  • Benchmark construction: The 31 original pairs draw mainly from SDK examples and scientific kernels, while 18 additions cover machine-learning operators and collectives.The additions were manually integrated and validated end to end rather than treated as independent expert references.
  • Evaluation sets: The frozen core enables identical paired comparisons, the diagnostic set uses five repeats across eight tasks, and the knowledge set contains 12/15 Level 2–3 tasks.Only the full set covers all 49 executable tasks and all four levels.
  • Scoring: The base score requires compilation, execution, and numerical agreement with the reference, while performance uses in-kernel device cycles and requires reference parity or speedup.Simulator wall time is not the performance metric.
  • Scoring: Six integrity checks detect leakage, protect held-out inputs, freeze timing and interfaces, verify numerical outputs, and reject unverified success reports.These checks help ensure that executable scores reflect genuine correctness and performance.

B. System Overview

FABRICA processes CUDA inputs through specialized analysis, architecture, implementation, execution, repair, and optimization stages while isolating references and enforcing valid cycle reductions. Its GEMV trace illustrates recovery of a row-wise reduction, 8 × 8 placement, compiler-guided repair, correctness verification, and optimization.

  • Pipeline: Six role-specific stages convert CUDA source, task specifications, and host–device constraints into a CSL kernel while withholding validated CSL references and held-out inputs.The stages recover per-PE computation and communication, design placement and layout, implement the kernel, and use execution feedback for repair and optimization.
  • Pipeline: Reference isolation, routed execution failures, and median-cycle validation constrain the workflow’s optimization decisions.An optimization is accepted only when it remains valid and reduces median cycles.
  • GEMV trace: 58,610 cycles at first correctness fell to 7,861 after three correctness-checked edits, versus a 10,309-cycle expert reference for the large GEMV.The trace first recovers row-wise reduction, constructs an 8 × 8 collective decomposition, and repairs a compiler-reported API error.
  • Workflow state: The workflow separates transient run state, reusable target knowledge, and verification history to support unfamiliar CSL generation.Retrieved material is filtered by role, and prior code returns only as screened aggregate lessons rather than complete reference bundles.

D. Constrained Generation and Execution Feedback

FABRICA constrains generation with stable starting structures, deterministic extraction, executable checking, routed repair, and bounded profiling. Correctness gates precede optimization, while the protocol keeps task sets, denominators, and attempt budgets explicit.

  • Constrained generation: Starter templates provide common imports, timing hooks, task declarations, and host-interface structure, but 47 of 49 tasks use the generic single-PE template.The evaluation therefore treats templates as stable starting structure followed by repair, not as evidence for specialized-template effects.
  • Constrained generation: Deterministic extraction supplies compile-time parameters, launch order, symbols, layout identifiers, queues, and best-effort resource checks as prompt guidance rather than compiler IR.The checks include mesh agreement, a 48-KB per-PE SRAM budget, and resource collisions.
  • Execution feedback: Every candidate passes through original build, runner, and numerical tests, with malformed CSL stopped by a compile-only gate before reviewer-routed repair.Failures are routed to architectural redesign, code repair, or interface repair.
  • Execution feedback: Profiling uses bounded heuristic signals rather than calibrated occupancy or congestion counters, while interactive debugging remains a human aid.Signals include event mixes, dispatch-span proxies, wavelet or backpressure indicators, and SRAM estimates.
  • Optimization: Each permitted optimization proposal is tested after restoring frozen timing and interface state, and only a valid lower-median candidate is retained.The protocol explicitly orders architecture mapping before implementation and correctness before optimization.

E. From Run Logs to Post-Training Data

FABRICA converts execution traces into deterministic supervision and preference data while preserving run provenance and filtering unreliable records. Its experimental protocol keeps study rows separate and evaluates timing with device-internal measurements on both simulator and hardware.

  • Run-log labeling: Each code-producing turn receives a deterministic label indicating immediate correctness, eventual repair success, or failure without later success.The label is derived from aligned run logs and is explicitly not a learned reward model.
  • Post-training data: Of 1,741 run directories, 1,673 align and yield 7,619 supervised candidates; after filtering, 6,066 remain, including 2,440 verified passes and 3,626 intermediate repairs.All-failure runs contribute no turns, while duplicates, over-cap records, suspected leakage, and unsuitable repair sequences are filtered.
  • Experimental protocol: Table III keeps task sets, repetitions, attempt budgets, and denominators separate across controlled, coverage, and optimization studies.The primary studies use Claude Opus 4.8, SDK 1.4.0 simulation, fresh bundles, numerical checks, and disjoint train/test splits.
  • Experimental protocol: The full workflow generates three candidates before bounded repair, and retained passes require both status=pass and success_marker=true.Profiling uses ten paired runs per original task and five per later-added task.
  • Timing evaluation: All 27 timing-comparable generated/reference pairs achieve geometric-mean speedups of 3.75x on the simulator and 3.47x on WSE-3.Figure 5 groups pairs by construction level and compares simulator and hardware speedups on a shared logarithmic axis against reference parity.
  • Timing evaluation: Timing uses plausible device-internal measurements, excludes host-bracketed RPC timing, and retains prompts, candidates, checks, and measurements in the artifact.Hardware rows use the same SDK bundle and kernel-owned run path on both targets.

V. EVALUATION AND RESULTS

The evaluation shows large gains from the complete executable workflow, strong performance for Claude models relative to open-weight models, and a distinct contribution from retrieved Cerebras knowledge. Coverage and cross-model comparisons are reported on fixed task sets with explicit denominators.

  • End-to-end results: The full workflow passes 26/28 core tasks versus 6/28 for a single attempt, a 72 percentage-point correctness difference.Among the 26 successful programs, 22 match or beat their references and 16 are strictly faster.
  • Cross-model comparison: Opus 4.8 passes 26 core tasks, compared with 25 for Sonnet 4.6, 24 for Opus 4.6, and 2 for the best open-weight model.Under the same workflow, the best commercial-to-open comparison differs by 24 tasks, or 86 percentage points.
  • Knowledge ablation: Retrieved Cerebras knowledge raises Sonnet 4.6 success from 1/15 to 7/15 on the Level 1–3 panel, while removing the CSL primer does not reduce the knowledge-free result.The six additional successes require collective operations, halo exchange, or DSD/queue setup.

C. Feedback Changes Where Search Effort Goes

Execution feedback concentrates search on repair types revealed by staged evidence, while coverage results show that most successful workflows need only short repair paths.

  • Repair classification: 130 of 189 repair requests (68.8%) are local implementation repairs, compared with 37 (19.6%) crossing bundle boundaries and 22 (11.6%) requesting new decompositions.The compile-only gate filters 140/224 malformed candidates before simulation.
  • Adaptive search: Retained passing workflows converge in a median of two evaluations, while 11 workflows consume the full ten-evaluation budget.This supports a short initial path followed by additional repair when staged evidence requests it.
  • Coverage: 38 of 49 swept tasks produce at least one correct program, including 18/18 later-added tasks and 20/31 tasks in the original set.The coverage metric counts each task once if any scheduled workflow passes.
  • Seeded follow-up: The final three tasks pass 8/9 seeded runs, with every passing run beating its reference; among 32 passing held-out tasks, 28 use fewer cycles.The three tasks are GEMM-1PE, Laplacian2D-Reduce, and LorenzoPredictor-Tile.
  • Repair example: RowParallel-Softmax reaches a passing distributed program after compiler, numerical, and cycle evidence expose successive interface, reduction, and scope faults.Two accepted edits reduce runtime to 13,688 cycles, 1.29× faster than the 17,714-cycle reference.
  • Correctness versus speed: GEMM-Collectives-2D reaches 1.07× while GEMV-Collectives-2D reaches 0.92×, separating correctness from speed; Game-of-Life adds 2/5 passing runs in follow-up evaluation.The complementary evaluation reports both task correctness and paired same-target speedups.

E. Correctness-Gated Optimization

Optimization is applied only to validated CSL programs and yields substantial gains on many PE-local kernels, while simulator-to-hardware comparisons reveal target-dependent variation.

  • Optimization results: All 14 measured references improve when optimization starts from correct CSL, with a 1.44× geometric-mean speedup and seven programs improving by at least 25%.Accepted transformations include descriptor-offset chaining, task simplification, buffer cleanup, bulk DSD operations, fused arithmetic, and loop simplification.
  • Same-target measurement: 27 timing-comparable generated/reference pairs show geometric-mean speedups of 3.75× on the SDK simulator and 3.47× on WSE-3 hardware.23/27 generated programs are faster on hardware, and 26/27 match or beat their references.
  • Cross-target variation: The simulator-to-hardware shift reflects relative movement between generated and reference implementations, with generated and reference geometric means of 1.030 and 0.953.Together they yield an aggregate 7.5% reduction.
  • Per-kernel variation: DFT improves from 10.21× to 10.92×, while Prefix-Sum falls from 2.11× to 1.54× and ReLU from 86.6× to 46.2× on WSE-3.Per-kernel movement can be larger than the aggregate shift because generated and reference paths change differently.
  • Task levels: WSE-3 speedups span 0.97× to 46.2× for Level 1, while Level 2 and Level 3 have geometric means of 2.56× and 2.71×.The Level 4 RowParallel-Softmax task remains near its expert reference at 1.24×.

G. Architecture Mapping Exposes System Boundaries

The paper frames CUDA-to-CSL translation as distributed program construction across explicit placement, communication, and interface boundaries, then evaluates training and workflow choices with executable validation.

  • Co-design boundaries: Execution-guided repair lets Laplacian2D pass 5/5 runs versus 0/5 unguided, while Cholesky layout editing removes at least five early interface stops.A train-derived collectives_2d example produces a running 383-line co-design, with 5/9 attempts reaching numerical checking.
  • Training signal: Offline SFT on benchmark-disjoint data improves all four 14B proxy metrics, while the 8B scores do not uniformly improve.The 14B usable/contract/chrF/vocabulary scores rise from 0.29/0.39/0.39/0.49 to 0.71/0.78/0.55/0.60.
  • Workflow implication: The results support retrieving target knowledge, using short initial paths for PE-local tasks, invoking classified repair after observed failures, and optimizing only validated programs.A proposed next step is lowering typed mappings into CSL rather than adding more prompt facts.
  • Scope boundary: The 49-task coverage metric counts a task once if any scheduled workflow passes, while the SFT pilot reports SDK-free structural metrics rather than executable correctness.Generated programs still require compilation, numerical checks, and device timing.
  • Architecture mapping: FABRICA recovers source invariants, builds WSE placement and communication, rebuilds candidates in a sandboxed reference bundle, and optimizes only after validation.The framework treats translation as distributed program construction rather than syntax substitution.
Loading 2608.25124v1…