Ostrium Labs
Menu

Ferrite · compiler and hardware research

From source code to silicon.

A research stack for turning algorithms into architectures, architectures into circuits, and circuits into physical silicon.

Engineering maturity
Research roadmap
Research registry
Unregistered
Strata revision
e1da679
Lithic revision
b9c0986
Source inspected
  1. Sourceinput
  2. Graph · Strataimplemented
  3. Schedule · HLSresearch
  4. RTL · Lithicimplemented
  5. Gates · synthesisresearch
  6. Placementresearch
  7. Routingresearch
  8. Dieresearch

Two implemented foundations. Everything between them and silicon is research.

Unregistered long-horizon research

Strata and Lithic provide implemented foundations. HLS, Ferrite-owned synthesis, physical design, signoff, and foundry integration remain research targets.

Explore the architecture Strata on GitHub Lithic on GitHub

load(a, b) → multiply → accumulate → output

routed: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. a port b port mul cells add + ff output clk Schematic cell groups · not a process layout routed: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. a port b port mul cells add + ff output clk Schematic cell groups
Fig. 4 · Computation to geometry

One computation, schematic cell groups and routes. Automatic source lowering and physical implementation are research targets. This educational object is not Ferrite output, a process layout, or evidence of silicon.

01

Transformation study

Educational schematic · not tool output
Conceptual transformation studyOne computation, changing representation.Future stages are not tool output.
  1. Source
  2. Dataflow
  3. Schedule
  4. Architecture
  5. RTL
  6. Gates
  7. Placement
  8. Clock tree
  9. Routing
  10. Die

01 · Source

// Target syntax — no HLS front end today
#[ferrite::kernel]
fn dot(a: &[i16; 256], b: &[i16; 256]) -> i32 {
    let mut sum: i32 = 0;
    for i in 0..256 {
        sum = sum.wrapping_add(
            a[i] as i32 * b[i] as i32);
    }
    sum
}
Research roadmap

Source

A dot product is the logical computation. The kernel attribute is conceptual; no Ferrite HLS front end is available.

The accumulator wraps at 32 bits. A compiler must preserve this explicit arithmetic contract.

02 · Dataflow

graph: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. load a load b mul acc output Loop-carried state · fixed-width semantics graph: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. load a load b mul acc output Loop-carried state
Research roadmap

Dataflow

Expose loads, multiplication, the loop-carried accumulation, and the final output. Dependencies constrain the schedule.

03 · Schedule

schedule: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. cycle 0cycle 1cycle 2 load a load b mul acc output Loop-carried state · fixed-width semantics schedule: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. cycle 0cycle 1cycle 2 load a load b mul acc output Loop-carried state
Research roadmap

Schedule

Assign operations to cycles and resources. An accumulator recurrence can limit the initiation interval; II = 1 is not assumed for this dot product.

04 · Architecture

architecture: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. load a load b mul acc output Loop-carried state · fixed-width semantics architecture: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. load a load b mul acc output Loop-carried state
Research roadmap

Architecture

Make state and control explicit. Registers hold the accumulation and index; memory ports constrain throughput.

05 · RTL

rtl: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. load a load b mul acc output Loop-carried state · fixed-width semantics rtl: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. load a load b mul acc output Loop-carried state
Implemented core

RTL

A manually described circuit can reach signal IR, cycle simulation, and Verilog in Lithic today. Automatic lowering from this source remains future work.

06 · Gates

gates: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. a port b port mul cells add + ff output Schematic cell groups · not a process layout gates: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. a port b port mul cells add + ff output Schematic cell groups
Research roadmap

Gates

Technology mapping would expand arithmetic and state into library cells. Boxes represent cell groups, not individual physical gates.

07 · Placement

placed: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. a port b port mul cells add + ff output Schematic cell groups · not a process layout placed: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. a port b port mul cells add + ff output Schematic cell groups
Research roadmap

Placement

Cell groups acquire legal positions within rows. Actual placement needs density, timing, macro, and congestion constraints.

08 · Clock tree

clock: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. a port b port mul cells add + ff output clk Schematic cell groups · not a process layout clock: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. a port b port mul cells add + ff output clk Schematic cell groups
Research roadmap

Clock tree

Clock distribution connects sequential state while managing skew, latency, slew, fanout, and power. The branching tree is illustrative, not a synthesized clock network.

09 · Routing

routed: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. a port b port mul cells add + ff output clk Schematic cell groups · not a process layout routed: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. a port b port mul cells add + ff output clk Schematic cell groups
Research roadmap

Routing

Connections acquire metal paths and vias; clock distribution is shown separately. These routes are schematic, not DRC-clean geometry.

10 · Die

die: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. a port b port mul cells add + ff output clk Schematic cell groups · not a process layout die: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. a port b port mul cells add + ff output clk Schematic cell groups
Ultimate objective

Die

A routed design still needs electrical and physical signoff, foundry acceptance, fabrication, and test. A die outline proves none of those gates.

02

Read the research architecture

24 sections
03

Compiler architecture

Expand a layer · solid = implemented · dashed = research

One question. Many boundaries.

The path is a research architecture, not an implemented end-to-end flow. Strata can route computation to software backends; the custom-hardware branch would enter HLS.

Solid rules identify existing foundations. Dashed rules mark research and manufacturing gates.

  1. 01 Ferrite StrataModel graph → executable partitions Implemented core

    What should become hardware?

    • Query backend support before compilation
    • Partition graphs at the subgraph boundary
    • Run CPU reference kernels and unsupported nodes on the host
    • Future: select economically justified custom hardware
    Boundary

    Graph IR, partitioning, CPU reference, and host execution exist. GPU execution and automatic ASIC generation do not.

    Read the Ferrite Strata record
  2. 02 Ferrite HLSAlgorithm → microarchitecture Research roadmap

    What architecture should the algorithm become?

    • Dependence analysis and modulo scheduling
    • Resource allocation, sharing, and binding
    • Loop unrolling and pipeline construction
    • Memory banking, bit widths, and control synthesis
    Boundary

    No HLS implementation is present in the inspected repositories.

  3. 03 Ferrite LithicHardware description → signal graph → Verilog Implemented core

    What exact circuit implements the architecture?

    • Represent fixed-width signals and circuit dependencies
    • Simulate explicit cycle semantics
    • Emit deterministic Verilog
    • Compare software models, simulation, and emitted RTL
    Boundary

    Embedded DSL, simulator, emitter, waveforms, and cosimulation exist. An algorithm-to-circuit HLS front end is future work.

    Read the Ferrite Lithic record
  4. 04 Ferrite SynthesisRTL → standard-cell netlist Research roadmap

    Which gates implement the circuit?

    • Register-transfer and Boolean representations
    • Constant propagation and dead-logic elimination
    • Mux, FSM, arithmetic, and register optimization
    • Retiming, clock gating, and technology mapping
    Boundary

    Ferrite-owned Boolean optimization and technology mapping are proposed.

  5. 05 Ferrite PhysicalGates → placed and routed layout Research roadmap

    How does the circuit become geometry?

    • Floorplan and legalize standard cells and macros
    • Construct clocks and power distribution
    • Global routing, track assignment, detailed routing
    • Extract parasitics and return physical feedback
    Boundary

    The placement and routing demonstrations on this site are educational schematics, not Ferrite output.

  6. 06 Ferrite SignoffLayout → independently checked design database Research roadmap

    Does the implementation meet the process contract?

    • Static timing, power, IR drop, and electromigration
    • RC extraction, DRC, LVS, and antenna checking
    • Density, metal fill, and reliability checks
    • Correlation with independent and foundry-approved references
    Boundary

    No Ferrite foundry-qualified timing, physical verification, or signoff stack is demonstrated.

  7. 07 Foundry handoff → siliconAccepted database → manufactured and tested device Ultimate objective

    Will the physical result survive fabrication?

    • Authorized process and library data
    • Foundry acceptance and reference-flow correlation
    • Test vehicle, fabrication, and measured silicon
    • Long-term target: advanced-node FinFET manufacturing
    Boundary

    Authorized process access, tool qualification, fabrication, packaging, and test are separate gates. No N3 support or tapeout is claimed.

04

The research study

Conceptual transformation · one computation throughout
graph: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. load a load b mul acc output Loop-carried state
Source · graph

The same multiply–accumulate computation, viewed at this abstraction boundary. Educational schematic; no measured tool output or manufacturing claim.

Semiconductor design is fragmented by abstraction boundaries.

Software, HLS, RTL, logic synthesis, physical design, timing, verification, and manufacturing each operate on different representations. Their tools have different optimization objectives and different ways to decide whether a result is correct. Passing an artifact to the next stage can lose the reasoning behind a previous decision.

Ferrite asks: what happens if those layers share a coherent compiler architecture? The goal is an inspectable chain of transformations, with explicit contracts between representations and physical feedback travelling back upstream. A common architecture need not mean one universal IR or one representation forced on every problem.

Strata and Lithic are the existing foundations. Source-to-Silicon names their proposed long-term convergence with HLS, synthesis, physical implementation, verification, and process integration. The inspected repositories do not implement that complete chain.

Strata: what should become hardware?

Strata’s implemented boundary is the subgraph. A backend describes supported operations and patterns; a planner partitions the graph; a backend compiles a supported partition; and the runtime executes it. Decline is an explicit outcome, so unsupported work can remain on the host rather than making the entire graph unusable.

The current core contains graph IR, capability queries, partitioning, CPU reference kernels, and host execution. GPU execution, the C ABI loader, and torch.compile integration are future work in the inspected revision. A documented plugin design is not a working vendor plugin ABI.

The long-term question extends beyond execution on existing devices:

MODEL GRAPH
     ↓
   STRATA ───→ CPU
     ├───────→ GPU / accelerator (future backend)
     └───────→ custom hardware (research)
                       ↓
                  Ferrite HLS

Deciding that a graph region deserves custom silicon would require measured workload frequency, compilation cost, power, throughput, memory traffic, fabrication economics, and a software alternative. Automatic ASIC generation is not a current Strata capability.

HLS: what architecture should the algorithm become?

Research roadmap. High-level synthesis would turn a supported algorithm into a microarchitecture. Dependency analysis exposes what can overlap; scheduling assigns work to cycles; allocation and binding choose resources; memory architecture determines banks and ports; pipeline and control construction make execution explicit.

The proposed scope includes modulo scheduling, unrolling, sharing, memory banking, bit-width inference, and control synthesis. These decisions trade throughput against area, power, latency, and interconnect. A source loop is not automatically synthesizable, and a fast software implementation is not automatically a good circuit.

For independent multiply–add iterations, an illustrative schedule can overlap work:

y[i] = a[i] * b[i] + c[i]

LOAD → MUL → REG → ADD → REG → STORE

cycle     0    1    2    3    4
i = 0    MUL  ADD
i = 1         MUL  ADD
i = 2              MUL  ADD
i = 3                   MUL  ADD

Illustrative II = 1: one new iteration begins each cycle, assuming the resources, memory ports, and timing permit it. This is a teaching example, not a Ferrite measurement. A loop-carried accumulation has different dependence constraints and cannot inherit that interval without analysis.

Lithic: what exact circuit implements the architecture?

Lithic is an embedded Rust hardware DSL, signal IR, cycle simulator, and Verilog generator. The existing circuit path is:

manual hardware description → signal graph
                              ├→ cycle simulator
                              └→ RTL emitter → Verilog → Verilator

Port derivation, cycle-indexed waveforms, VCD output, step testbenches, and cosimulation are present. This is circuit tooling, not a compiler that accepts arbitrary Rust algorithms and produces an optimized architecture.

Correctness needs an independent witness. Software reference implementations check algorithm behavior; the step testbench checks cycle behavior; Verilator checks that emitted RTL agrees with simulation for the tested stimulus. Local tests may skip external tools when absent. The repository’s dedicated cosimulation CI installs Verilator and Icarus and rejects skipped checks.

Memory limitations matter: zero-filled memory primitives exist, but an initialized-memory IR node does not. Design::rom builds a mux/case tree rather than promising block RAM or SRAM inference. The simulator also refuses multiple clocks and unmodelled instances. These boundaries remain visible in the Lithic project record.

Logic synthesis: RTL becomes gates.

Research roadmap. Ferrite-owned synthesis would lower register-transfer behavior into Boolean and sequential networks, optimize those networks, and map them against a standard-cell library.

RTL → register-transfer network → Boolean network
    → optimization → technology mapping → cell netlist

Candidate passes include constant propagation, dead-logic elimination, Boolean rewriting, common subexpression elimination, mux and FSM optimization, arithmetic decomposition, retiming, clock gating, and logic sharing. Any transformation must preserve the relevant sequential behavior and explicitly account for clocks, resets, and timing assumptions.

Mapping is the transition from abstract logic to actual cells: drive strengths, pin capacitances, timing arcs, power, geometry, and legal orientations enter the decision. No Ferrite-owned synthesis implementation is evidenced in the inspected repositories.

Gates become geometry.

Cell groups acquire positions, clocks, and routes. The physical constraints become part of the compiler's problem.

Conceptual transformation studyGates become geometry.Future stages are not tool output.
  1. Gates
  2. Placement
  3. Clock tree
  4. Routing
  5. Die

01 · Gates

gates: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. a port b port mul cells add + ff output Schematic cell groups · not a process layout gates: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. a port b port mul cells add + ff output Schematic cell groups
Research roadmap

Gates

Technology mapping would expand arithmetic and state into library cells. Boxes represent cell groups, not individual physical gates.

02 · Placement

placed: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. a port b port mul cells add + ff output Schematic cell groups · not a process layout placed: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. a port b port mul cells add + ff output Schematic cell groups
Research roadmap

Placement

Cell groups acquire legal positions within rows. Actual placement needs density, timing, macro, and congestion constraints.

03 · Clock tree

clock: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. a port b port mul cells add + ff output clk Schematic cell groups · not a process layout clock: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. a port b port mul cells add + ff output clk Schematic cell groups
Research roadmap

Clock tree

Clock distribution connects sequential state while managing skew, latency, slew, fanout, and power. The branching tree is illustrative, not a synthesized clock network.

04 · Routing

routed: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. a port b port mul cells add + ff output clk Schematic cell groups · not a process layout routed: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. a port b port mul cells add + ff output clk Schematic cell groups
Research roadmap

Routing

Connections acquire metal paths and vias; clock distribution is shown separately. These routes are schematic, not DRC-clean geometry.

05 · Die

die: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. a port b port mul cells add + ff output clk Schematic cell groups · not a process layout die: the same multiply–accumulate computation Two input loads feed a multiplier. Its result updates an accumulator with a loop-carried feedback edge, then feeds the output. Later stages depict equivalent cell groups in rows, clocks, routing, and a die boundary. Educational schematic, not emitted RTL or physical layout. a port b port mul cells add + ff output clk Schematic cell groups
Ultimate objective

Die

A routed design still needs electrical and physical signoff, foundry acceptance, fabrication, and test. A die outline proves none of those gates.

Physically aware HLS: hardware compilation cannot stop at RTL.

Research direction. An architecture that looks efficient before placement can become expensive after routing. Wire delay, congestion, clock distribution, memory location, power delivery, and critical paths can change the best schedule and resource topology.

HLS → RTL → synthesis → physical implementation → measured PPA
 ↑                                                   │
 └──── revise architecture and compile again ────────┘

PPA means power, performance, and area. Ferrite would use physical observations to revise unroll factors, resource binding, pipeline depth, memory banks, scheduling, and placement affinity. The research problem is not merely predicting a scalar cost: it is deciding which physical facts justify changing an upstream architecture.

Processes contribute data. Ferrite provides algorithms.

The proposed Ferrite Process Contract, or Technology Capsule, would describe what a fabrication technology permits. A normalized contract would include device definitions, layers, vias, routing and design rules, parasitic models, process corners, cell libraries, memory macros, density, reliability, and signoff requirements.

authorized foundry / research PDK
                 ↓
              adapter
                 ↓
       Ferrite Process Compiler
                 ↓
        normalized Process IR
       ↙         ↓          ↘
devices/rules  cells/RC  corners/memories

Research roadmap. No Process Compiler or supported capsule is implemented in the inspected repositories. A common schema must preserve process-specific constraints rather than silently erase details it cannot express.

The foundry defines what can be manufactured. Ferrite’s objective is to own the algorithms that determine how to design it. Authorized process knowledge may remain confidential; an open implementation does not make a foundry’s process data public. Ferrite does not propose reconstructing a proprietary PDK from public information.

The technology ladder: evidence before smaller nodes.

SKY130: first prove the compiler on real silicon.

Proposed proving ground / research roadmap. SKY130 provides data derived from a real 130nm process and an opportunity to test an eventual complete flow. The public PDK is explicitly an experimental preview rather than a production-qualified release; its availability alone does not guarantee acceptance for fabrication. See the SKY130 status documentation.

A future test chip would need synthesis, placement, routing, extraction, verification, an authorized handoff route, fabrication, packaging, and measurement. Passing those gates would provide a physical correctness anchor, not proof that an advanced-node flow works.

ASAP7: challenge the architecture with FinFET scaling.

Predictive research candidate. ASAP7 is a 7nm FinFET research PDK. Its maintainers explicitly state that resulting designs are not manufacturable. It can support studies of architecture and physical costs without representing a fabrication opportunity. See Arizona State’s ASAP7 description.

The question is how architecture changes when cell and interconnect costs change: shared versus replicated multipliers, pipeline depth, clocks, congestion, memory, and power density. Ferrite should derive decisions from characterized models and post-route results, rather than multiplying a 130nm estimate by a scaling constant. No Ferrite ASAP7 integration is claimed.

Predictive 3nm environments: explore before a process becomes a product.

Research category / platform selection open. Candidate studies would examine cell characterization, parasitic sensitivity, routing congestion, power delivery, and resource binding across predictive environments. No specific predictive 3nm PDK is selected by this publication.

An important falsifiable question is whether the optimal HLS architecture remains stable when the predictive PDK changes. A result that is highly sensitive to the model may be a useful finding. A predictive PDK is neither equivalent to TSMC N3 nor permission to manufacture there.

TSMC N3: the manufacturing north star.

Ultimate objective. N3 is advanced-node FinFET manufacturing, not GAAFET. TSMC’s N2 uses nanosheet transistors; node-family labels should not be treated as interchangeable device architectures. See TSMC’s N3 technology description.

The target is a foundry-accepted database produced by Ferrite-owned implementation algorithms using authorized process data. There is no current Ferrite N3 support, process access, foundry relationship, tool certification, accepted GDS, or tapeout evidenced by the inspected repositories.

ULTIMATE OBJECTIVE / NOT AN AVAILABLE COMMAND

ferrite build accelerator.rs \
  --target tsmc-n3 \
  --objective performance-per-watt

This command describes a target experience. It is not an instruction that works today.

No proprietary implementation runtime.

Ferrite’s long-term architectural objective is a complete implementation path without required proprietary EDA executables. Foundry device models, rules, libraries, corners, and manufacturing constraints would still be necessary authorized inputs.

Process knowledge is distinct from an EDA implementation. Replacing algorithms does not replace physics, license conditions, process expertise, or foundry acceptance. Qualification may require independent or foundry-approved reference checks even if those tools are outside Ferrite’s intended production compilation path.

Standard cells: the technology mapper needs real costs.

Research roadmap. A normalized cell model would carry a logical function, pins, timing arcs, slew/load tables, leakage and switching power, physical dimensions, obstructions, drive strength, and legal orientation. A mapper would select cells against both logical requirements and physical constraints.

The same Boolean function can be implemented by cells with different delay, power, area, and routability. Abstract AND gates alone cannot answer an advanced-node implementation question. Memory macros also need latency, port, physical, and timing contracts; replacing a large SRAM with flip-flops is a materially different architecture.

Physical implementation research.

All items below are roadmap scope. The visual study illustrates their responsibilities; it is not a solved layout.

  • Floorplanning: establish die/core geometry, macro locations, channels, and blockages.
  • Global placement: optimize connectivity, density, timing, and congestion across the core.
  • Legalization and detailed placement: move instances to legal sites, orientations, and non-overlapping positions.
  • Clock-tree synthesis: distribute clocks while controlling skew, latency, slew, fanout, and power.
  • Global routing and track assignment: allocate connectivity to regions and layers while estimating congestion.
  • Detailed routing and repair: realize metal and vias under widths, spacing, enclosure, antenna, and other rules.
  • Power-grid synthesis: build delivery paths and evaluate current and voltage constraints.
  • Parasitic extraction: convert routed geometry into resistance and capacitance networks, including coupling.

A physical IR would retain instances, macros, nets, rows, tracks, blockages, clock networks, and power grids. All passes would consume the process contract instead of spreading hard-coded node cases throughout the compiler.

Signoff: layout is not enough.

Research roadmap. A manufacturable design must satisfy electrical and physical constraints. A file that can be parsed as GDS or OASIS is only a representation; it does not establish manufacturability.

  • Static timing analysis: arrival/required times, setup/hold, clocks, variation, corners, exceptions, and slack.
  • Power analysis: switching, leakage, clock, memory, and other relevant power components.
  • IR drop and electromigration: voltage loss and current-density reliability throughout power and signal networks.
  • DRC: geometry against process rules for spacing, widths, enclosures, area, and pattern interactions.
  • LVS: extracted layout connectivity and devices against the intended schematic/netlist.
  • Antenna checking: manufacturing-induced charge exposure against process limits.
  • Density and fill: satisfy manufacturing density while reassessing coupling, timing, power, and DRC.

Extraction, physical verification, testability, and reliability need independent correlation. DFT, scan/ATPG, memory BIST, and appropriate memory compiler or macro interfaces are additional future engineering gates.

The north star requires more than Ferrite declaring its own output valid: tool qualification and foundry acceptance are external decisions. TSMC’s EDA Alliance describes tool and methodology validation across implementation and signoff categories; this is context, not a claimed Ferrite partnership.

Never trust one compiler to verify itself.

Lithic’s existing corpus compares software references, cycle-indexed behavior, and emitted RTL through independent tools. Source-to-Silicon would extend that discipline across each boundary.

TRANSFORMATION             INDEPENDENT WITNESS
HLS                        software reference / interpreter (future)
Lithic RTL                 Verilator (present)
Synthesis                  reference synthesis / equivalence (future)
Physical implementation    independent physical flow (future)
Static timing              trusted timing implementation (future)
DRC                        independent rule checker (future)
LVS                        independent extraction / equivalence (future)
RC extraction              reference parasitic extraction (future)

Yosys, OpenROAD, OpenSTA, and KLayout are possible research oracles, not claimed Ferrite integrations or guaranteed replacements for foundry-qualified checks. Verilator is already part of Lithic’s cosimulation approach. Tools may serve as comparison witnesses before Ferrite earns an independent implementation. Agreement on shared assumptions is still weaker than independent physical evidence.

The validation ladder.

Each stage introduces a new failure surface. These are evidence gates, not a progress score:

  1. L0 / Software oracle: algorithm outputs against an independent implementation; used in Lithic’s corpus.
  2. L1 / HLS IR interpreter: preserve source semantics across scheduling and binding; future.
  3. L2 / Lithic cycle simulator: observe clocked behavior and state transitions; present.
  4. L3 / RTL and Verilator: compare emitted circuit behavior for controlled stimulus; present testing path.
  5. L4 / Gate-level equivalence: preserve sequential behavior after mapping; future.
  6. L5 / Post-route timing: evaluate extracted physical delay and timing constraints; future.
  7. L6 / Electrical and physical signoff: DRC, LVS, power, EM/IR, and the full process contract; future.
  8. L7 / Fabricated silicon: measure the manufactured and tested device; ultimate evidence gate.

Passing one gate does not imply the next. Simulation cannot certify process rules, and equivalence on finite stimulus is not proof for every input or environment.

Test the compiler with real architectures.

Existing Lithic corpus. The inspected repository reports 21 designs across seven tiers. Its source includes CRC, AES, ChaCha20, SHA-256, GHASH, bitpacking, encodings, RLE, sorting, bitmap operations, automata, packet parsing, sketches, and entropy coding. Each class stresses a different circuit shape rather than repeating one easy example. Aggregate test counts are deliberately omitted because repository summaries contain inconsistent breakdowns.

Future source-to-silicon corpus. GEMM/GEMV, convolution, normalization, softmax, RoPE, quantization, reductions, RISC-V, DMA, NoC, cache controllers, and memory subsystems are candidate integration tests. They are not all implemented Lithic designs. In particular, BLAKE3 and FFT files in the inspected corpus are unimplemented files, not shipped algorithms.

Corpus evidence should preserve source, circuit, constraints, configurations, reference outputs, failures, and the exact tool/process revisions. A design becoming an integration test is different from a design becoming a manufactured chip.

Attack the physical algorithms.

Proposed adversarial physical corpus. High fanout, narrow channels, macro congestion, long clock paths, deep arithmetic, via-heavy routes, density cliffs, antenna exposure, hold-critical paths, power hotspots, routing blockages, extreme aspect ratios, and cell-abutment edge cases should be capable of disproving an algorithm’s assumptions.

Each case needs an invariant and an independent witness. A placement that lowers wirelength while making routing impossible is a counterexample, not a successful optimization. An algorithm that cannot diagnose its own limit should refuse or report uncertainty rather than silently produce plausible geometry.

Technology-aware HLS: the same algorithm need not become the same hardware.

Research direction. Adders, multipliers, memories, muxes, registers, pipeline stages, clocks, and wires have technology-specific costs. One process may favor shared arithmetic; another may favor additional resources but deeper pipelines. A topology that gains parallelism can lose it again through routing and power limits.

algorithm + constraints
          ↓
         HLS ← characterized technology model
          ↓
architecture A / architecture B / architecture C
          ↓
independent post-route comparison

Those architectures are candidate outcomes, not measured Ferrite results. The compiler must learn whether a model remains useful after placement and whether its decisions survive a different PDK.

Ferrite Characterize: measure the cost model.

Research roadmap. A characterization engine would construct primitive architectures, synthesize/place/route them, measure delay, area, and power, and produce a technology cost model.

operation × bit width × pipeline depth × technology
                         ↓
            synthesis / place / route
                         ↓
                delay / area / power
                         ↓
               versioned cost model

An HLS query such as cost(MUL, width=32, pipeline=2) would then refer to identified evidence rather than an undocumented guess. Device-level cell characterization from authorized models is a separate longer-term direction. Models need process corners, uncertainty, provenance, and independent correlation; a table is not ground truth merely because it was generated automatically.

Compilation becomes design-space exploration.

Research direction. Given a target clock, area/power limit, throughput, and technology, Ferrite would explore unroll factors, pipeline depths, memory banks, resource counts, bit widths, and topology. Width changes must respect the arithmetic/accuracy contract rather than silently alter the task.

A Pareto frontier would retain candidates for which no other measured design is better on every chosen objective. It should expose trade-offs and constraint violations instead of announcing a universal optimum. Search time, characterization cost, and failed candidates contribute to the complete engineering loop.

What should remain software—and what deserves silicon?

Strata’s eventual connection to the physical stack would compare CPU, GPU, existing accelerators, and a custom-hardware branch. The latter would pass through HLS, Lithic, synthesis, physical implementation, and signoff before a fabricated device could be evaluated.

This is a research question about workload economics and physical constraints. Specialized hardware is not automatically the better answer: changed models, deployment volume, memory traffic, fabrication cost, and software flexibility can favor remaining in software.

Questions Ferrite is trying to answer.

  • Can coherent representation contracts span software scheduling and physical implementation without losing each domain’s essential semantics?
  • How much should physical placement influence HLS scheduling?
  • When does parallelism stop helping because interconnect dominates?
  • How should memory architecture change across process nodes?
  • Can measured PPA revise loop unrolling and resource binding reliably?
  • Can a technology-independent compiler preserve different process constraints without node-specific logic spreading through every pass?
  • How closely can an independent open flow correlate with foundry-qualified references?
  • When is a model region economically worth specialized hardware?

These questions are open. Their answers require protocols, counterfactuals, reproducible artifacts, and independent evidence.

Processes describe physics. Compilers should own the transformation.

A fabrication process defines what can be manufactured. Ferrite explores whether upstream scheduling, circuit construction, placement, routing, and verification can become an inspectable and testable compiler architecture that consumes authorized process information as data.

The ultimate objective is source-to-silicon compilation: a complete open Rust-native flow capable of reaching foundry-manufacturable silicon without requiring proprietary EDA implementation software. It remains a long-horizon research objective. The present contribution is the implemented Strata and Lithic foundation and the questions it makes concrete.

05

Maturity and research roadmap

Scope and evidence gates · not a schedule
Not a delivery schedule

Milestones describe scope and evidence gates, not a delivery schedule. Implemented foundations do not imply an end-to-end manufacturing capability.

  1. M0

    Lithic foundation

    Signal IR, cycle simulation, RTL emission, and equivalence corpus. This milestone covers circuit tooling, not a silicon flow.

    Implemented core
  2. B1

    Strata core

    Graph/runtime/CPU foundation exists; portable GPU, plugin loading, and PyTorch integration remain future work.

    In development
  3. M1

    HLS

    Dependence analysis, scheduling, binding, pipelining, and memory architecture; algorithm-to-RTL validation.

    Research roadmap
  4. M2

    SKY130 proving ground

    Synthesis, physical implementation, verification, and eventually a tested chip using an authorized fabrication route.

    Research roadmap
  5. M3

    7nm research

    Predictive ASAP7 studies of FinFET costs, post-route PPA, and technology-aware HLS. No fabrication path.

    Research roadmap
  6. M4

    Advanced-node research

    Selected predictive environments, parasitic sensitivity, routing, and cross-PDK architecture robustness; no environment selected here.

    Research roadmap
  7. M5

    Physically aware HLS

    Use placement, timing, and power observations to revise architectures and re-synthesize.

    Research roadmap
  8. M6

    Foundry integration

    Authorized technology capsule, reference-flow correlation, tool validation, and a silicon test vehicle.

    Research roadmap
  9. M7

    N3 tapeout

    Foundry-accepted advanced-node handoff from a complete Ferrite flow. No access, qualification, or manufacturing capability is asserted.

    Ultimate objective

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