Loom-ROM: Direct-to-Silicon Inference
A per-model derivative of Loom that commits frozen weights into an on-die ROM through the metal masks. When weights are static, the fastest possible memory is no memory at all. It is wiring. Loom-ROM shifts the cost of weight movement from runtime bandwidth to manufacturing-time metal.
Loom-ROM is a standard Loom base die customized with a two-metal-layer overlay that programs the die's built-in ROM grid with a specific model and optional fixed dataflow paths. Standard Loom host software runs unchanged and simply feature-detects Loom-ROM via a capability register.
Direct-to-silicon inference
Every inference pass on a standard accelerator begins by fetching model weights from external memory. For a 7B parameter model at INT4, that is roughly 3.5 GB of data streamed through the memory bus on every forward pass. Memory bandwidth is the bottleneck. HBM exists to address this, but at enormous cost and power.
Loom-ROM eliminates the fetch. Every Loom base die includes a non-configured, ultra-dense base-transistor ROM grid, with its sense amplifiers, word-line selectors, and bit-line read paths already fabricated in the lower layers. Programming a model drops vias from the top two metal layers into that grid, hardcoding the bits without touching the power grid or clock trees. The MXU then reads weights from on-die ModelROM at silicon speed, and the external memory interface is freed for what actually changes at runtime: KV caches, activations, I/O buffers, and agent state.
Loom-ROM places the entire model graph, pre-compiled, into on-die ROM. The host writes a single pointer to an argument descriptor and a single doorbell register. The ACP reads the descriptor, launches the ROM-resident command graph, and runs the full model end-to-end without host involvement. No kernel launch overhead. No driver round-trips. No scheduling jitter. Write one register, get one inference.
The programming model, command format, and numerical results do not change. What Loom-ROM adds is ModelROM, an on-die read-only store for weights, along with a manifest and, in some cases, preloaded command graphs, plus a built-in path that lets matrix multiply and matrix-vector operations read those stored weights directly, without changing how software schedules work.
On-die ROM is dense relative to the bandwidth and power cost of DRAM, but not dense relative to logic. Loom-ROM targets compact, edge-native models whose parameter count fits within the base die's ROM-grid area budget: vision classifiers, acoustic and keyword models, RF basebands, sensor triage nets, control policies, cognitive radio pipelines, and localized expert routers. Large frontier models stay on programmable Loom with commodity DRAM. The two product lines are designed to coexist.
Fixed topology, parameterized runs
Some Loom-ROM SKUs include an optional ROM-resident command graph that the on-die ACP can launch with a single doorbell write. This delivers hardware-appliance integration with minimal host orchestration, but it comes with an important rule: the graph topology is fixed in silicon. The command sequence and model architecture do not change at runtime. Each run is parameterized via a small run descriptor containing pointers and scalars.
| Frozen in Silicon | Parameterizable per Run |
|---|---|
| Layer count, head count, hidden size | Prompt pointer + length |
| Quantization / packing choices | KV base pointer and strides |
| Expert layout / pruning choices | Token position counters |
| The cmd64 operator sequence | Output buffer addresses |
| Sampling algorithm choice (greedy vs top-k vs etc.) | Sampling knobs (temperature, top-k, top-p), RNG seed |
One base die, three specialization tiers
| SKU | External DRAM | Weights | Compute Fabric | Use Case |
|---|---|---|---|---|
| LR-M2 | External DRAM present | ModelROM (metal-programmable) | Standard MXU/SCE | Drop-in speedup from eliminating weight bandwidth |
| LR-CW (custom) | External DRAM optional | ModelROM + wired into MXU sub-arrays | Constant-weight MAC arrays | Extreme perf/watt for a fixed model graph |
| LR-EDGE (custom) | None | ModelROM only | CW-MAC + on-chip SRAM only | Ultra-high-volume fixed embedded endpoints |
The most straightforward variant. The standard Loom base die with model weights burned into metal-programmable ROM. External commodity DRAM remains present for KV caches, activations, and I/O buffers. The MXU's Structured Weight Feeder sources directly from ModelROM instead of DRAM, eliminating the weight bandwidth bottleneck while keeping the compute fabric fully general-purpose. Drop this into any existing Loom deployment for an immediate throughput boost on a frozen model.
Goes further for extreme-volume, hyper-constrained deployments. The structured overlay permanently configures local multiplexers inside the MXU sub-arrays, locking weight paths directly into the array's execution buffers and eliminating register-file reads for those weights. The base transistors and gates are unchanged; only the metal-configured routing differs. Supported weight dtypes include binary, ternary, INT4, and INT8. External DRAM is optional, present for large KV caches, absent for pure fixed-function deployments.
Because LR-CW requires careful physical-design optimization of that routing against the target model, it is a custom engineering engagement reserved for ultra-high-volume, long-lifecycle endpoints rather than a self-service compiler output.
The ultimate embedded endpoint. No external memory interface at all. Weights live in ModelROM, activations live in on-chip SRAM, and the entire inference path runs within the die boundary. Target: ultra-high-volume fixed models deployed at the sensor edge. Vision classifiers, keyword spotters, anomaly detectors, always-on wake processors.
Like LR-CW, LR-EDGE is a custom engagement: physical design, pruning, and compute-fabric customization are co-optimized against the specific target model.
Metal-layer programming
LR-M2 starts from the standard Loom base die (L-Base). All transistors, local interconnect, and lower metal layers are identical to the programmable part, including the pre-fabricated structured ROM grid and its read circuitry, which sits unconfigured until a top-metal overlay is applied. Below the overlay this is a single mask set manufactured at volume, amortizing NRE across the programmable and LR-M2 family.
Per-model customization is applied using only the top two metal layers and their associated vias. This is the S-Overlay. It programs the base-die ROM grid by dropping vias to set each cell, optionally configures local routing inside MXU sub-arrays into constant-weight paths, and optionally removes pruned routes from the die. Changing the model means changing two masks.
The existing Loom compiler (loomc) is extended to emit a Structured Overlay Package (SOP) alongside the standard Loom compilation object files. The SOP contains the ModelROM image, optional prune maps, optional constant-weight mappings, and a mask routing map suitable for physical implementation. A bit-exact functional equivalence check verifies that the structured variant produces identical results to the general-purpose Loom compilation for a directed test suite and randomized vectors.
If a model has been pruned (neurons, attention heads, or entire MoE experts) permanently removed, the structured overlay physically omits those routes from the die. Not gated off. Not masked to zero. Absent. The silicon area and power consumed by dead weights drops to zero. Architecturally, pruned weights behave exactly as if they were zero, maintaining bit-exact compatibility with the general-purpose Loom execution.
ROM weights, DRAM state
Loom-ROM enables a clean separation: base weights live in on-die ModelROM at silicon speed, consuming zero external bandwidth. External commodity DRAM, when present, is dedicated to runtime state: KV caches for long-context inference, agent scratch memory, DMA I/O buffers for RF samples or video frames, and streaming network data. The memory bus serves only what actually changes at inference time.
The model is in silicon. Loom-ROM includes an optional ROM read-lock that enforces a hard architectural boundary: host reads from ModelROM return bus faults or poisoned data, and the data plane simply does not route ModelROM outputs back to the host PCIe interface. Only on-die engines (ACP, MXU, SCE) reach the weight data. The model manifest (hashes, dimensions, ABI version) stays host-readable for identity verification.
This will not stop a state actor with a decapsulation lab and an electron microscope; weights committed to metal are static and visible to physical analysis. What it does is make the weights impossible to extract via compromised host software, hypervisor escapes, or remote zero-days. The security boundary is architectural isolation against remote exfiltration, not physical anti-tamper.
How a model becomes silicon
The customer provides an architecture and checkpoint intended to be stable for a multi-year deployment lifecycle. Telecom basebands, embedded vision pipelines, robotics controllers, fixed inference endpoints.
Select supported weight dtypes: INT4, ternary, binary, FP8, or INT8. The quantization format is locked at overlay time. Loom-ROM supports the same packed weight formats as Loom.
The Loom compiler (loomc) emits a Structured Overlay Package containing the ModelROM image (weights plus manifest), optional ROM-resident command graph, optional prune map and constant-weight MAC mappings, and a mask routing map suitable for physical implementation. A bit-exact functional equivalence check verifies the structured variant produces identical results to the general-purpose Loom compilation.
Only the top two metal layers are customized. The base die remains standard. This is a two-mask change, designed for turnaround measured in weeks.
The host driver queries capabilities, validates the model UUID and weight hash against the manifest, and starts inference. Standard Loom software with feature detection. No new platform tax.
Where frozen models justify specialized silicon
Cameras, drones, industrial inspection systems. The model is trained once, validated, and deployed for years. LR-EDGE runs a frozen vision classifier or object detector on-die with no external memory, no host CPU, and single-digit watt power budgets. The ACP handles the full sensor-to-action loop autonomously.
5G neural receivers, beamforming engines, spectrum sensing. The baseband processing model is standardized and stable across deployment cycles. LR-CW hardens the beamforming weights into constant-weight MAC arrays while the Sparse Compute Engine handles mixed-radix FFTs. External DRAM buffers live RF samples. The entire physical layer runs at silicon speed with software-defined flexibility for the control plane.
Fixed assistants, translation engines, routing models, content classifiers. Workloads where a single frozen model serves millions of requests per day and the economics justify per-model silicon. LR-M2 provides an immediate throughput multiplier by eliminating weight bandwidth from the critical path. At sufficient volume, LR-CW pushes performance per watt to levels that general-purpose accelerators cannot approach.
Environments where model weights are classified or export-controlled. Loom-ROM's ROM read-lock ensures the model cannot be extracted by software on the host: the weights are not streamed from DRAM, not cached in host-visible SRAM, and not reachable through debug ports or the PCIe interface. Combined with the ACP's autonomous execution, the entire inference path can run without the host ever touching the model data. Physical anti-tamper against decapsulation remains a board- and enclosure-level responsibility.
Two lines, one base die
Loom is the programmable Autonomous Inference Engine. Loom-ROM is the direct-to-silicon line for customers turning a stable model into a hardware appliance. They share a base die; the overlay is what differs.
| Loom (Programmable) | Loom-ROM | |
|---|---|---|
| Model flexibility | Any model, any time | Frozen model per metal spin |
| Weight bandwidth | External DRAM limited | On-die (silicon-speed) |
| Perf/Watt | High | Extreme (ModelROM eliminates external DRAM interface power) |
| NRE per model | Zero (software only) | Two-mask overlay cost |
| Model security | Software-dependent | Weights in metal, optionally read-locked |
| Best for | Research, prototyping, dynamic workloads | Production, high-volume, frozen models |
If your model is frozen, talk to us about Loom-ROM.
