Ostrium Labs
Menu

Ferrite · compiler and hardware research

What should become hardware?

A vendor-neutral accelerator runtime. The subgraph is the boundary between a model and a backend's private implementation.

Engineering maturity
B1 core implemented; development continues
Research registry
Unregistered
Strata revision
e1da679
Source inspected
  1. Sourceinput
  2. Graph · Strataimplemented
  3. Schedule · HLSresearch
  4. RTL · Lithicimplemented
  5. Gates · synthesisresearch
  6. Placementresearch
  7. Routingresearch
  8. Dieresearch

The first layer of Ferrite decides where computation runs.

Not implemented

B1 core implemented; development continues. No portable GPU backend, dynamic plugin loader, PyTorch entry point, or automatic ASIC generation is implemented in the inspected revision.

Strata on GitHub Design and maturity record
Strata partitions supported computation and retains host fallbackA model graph enters backend support queries. Supported subgraphs form executable partitions; declined nodes retain CPU host fallback. The CPU reference and host runtime exist. Vendor GPU execution and a dynamic plugin ABI loader are future integration, not shipped capabilities. Model graph0102030405 supports(operations, patterns) AcceptDeclinecompile partitionhost fallback CPU / host runtimeImplemented core Vendor GPU / plugin loader: future
Fig. 2 · Partition and decline

Capability first. Partition when supported. Decline explicitly. The core runs CPU and host work. Vendor integration and a shipped plugin ABI loader remain future scope; no automatic ASIC generation is shown.

01

Implemented and future scope

Revision e1da679

Implemented core Available

  • Graph IR and backend/executable traits
  • Backend capability queries and graph partitioning
  • CPU reference kernels
  • Session, compile, run, and host fallback

Future integration Planned / research

  • CubeCL GPU backend — not started
  • Versioned C ABI and plugin loader — not started
  • PyTorch torch.compile entry point — not started
  • Automatic custom-silicon selection and HLS bridge — research
02

Runtime design

From repository source and design notes

Query support before committing work.

A backend declares operations and fused patterns it supports. Strata partitions the graph, compiles accepted subgraphs into executables, and runs them. Backend decline is handled separately from an error; unsupported nodes can execute on the CPU in the shared arena.

graph → support queries → partition plan
                              ↓
                        compile partitions
                              ↓
backend execution ← session → CPU / host fallback

Three crates exist today.

  • ferrite-strata
  • ferrite-strata-cpu
  • ferrite-strata-runtime

The README also names intended CubeCL, plugin-api, and PyTorch crates. Those names describe planned work; they are not a current crate inventory.

The plugin ABI is a design contract, not a shipped loader.

Design notes propose a versioned C-compatible vtable and safe Rust wrapper because Rust trait objects are not a stable cross-library ABI. Capability negotiation, refusal, executable compatibility, and opaque backend compilation are distinct contracts to implement and validate.

GPU and vendor integration must earn support through source and tests. The inspected core does not establish CUDA, ROCm, Metal, FPGA, or custom-silicon execution.

Software first. Silicon when justified.

The long-term branch from Strata into HLS would ask whether repeated model regions justify specialized hardware. It needs performance, power, memory, flexibility, and economic evidence. HLS and the physical flow remain research scope.

Follow the proposed Source-to-Silicon architecture Next implemented layer: Lithic

Implementation record

Inspected 2026-10-06

Current capabilities describe repository source inspected on 2026-10-06. Repository test reports are attributed to their authors; this publication does not independently certify a hardware flow.

Strata at e1da679 Lithic at b9c0986 Ostrium evidence record