Approach

Honeycomb keeps the hardware surface small enough to reason about: one cell, one ISA, one mesh interface, and one way to move data.

One repeated cell

The basic hardware element is the Honeycomb cell. It contains local memory, scalar/control state, a MAC datapath for the kernel path, and nearest-neighbour network ports. The same cell is used throughout the compute fabric.

That uniformity is a verification choice. Each extra kind of core, tile, cache, memory tier, boot agent, or privileged controller would add another behavior to specify and another interface to prove. Honeycomb instead proves one cell and composes it uniformly. Distance still matters, but it is a cost in the mesh rather than a named hardware tier.

A cell has:

• local memory holding instructions, scalar data, resident weights, and streams;
• scalar/control instructions for ordinary control flow;
• a MAC datapath for the resident-weight kernel path;
• nearest-neighbour links for explicit movement;
• the same boot ROM as every other cell.

One ISA, two workloads

Honeycomb uses the same cell for two kinds of work.

The kernel path is static and dataflow-like: resident weights are read from local SRAM, operands move explicitly, and schedules can make exact timing claims. The control path is an ordinary small computer: it boots, loads programs, handles coordination, and runs data-dependent branches. Its timing claim is bounded worst case, not exact cycle equality.

Using one ISA avoids a separate conductor core. The price is a modest amount of scalar and branch logic in every cell; the benefit is a single semantic contract for both the fast path and the control path.

Memory as a cost-space

Honeycomb does not make software name a memory hierarchy. Every object is addressed through a flat namespace and differs by cost: local SRAM is cheap, a neighbour is a hop away, and an external memory node is slower and larger.

cost = < distance (hops), latency, access granularity, capacity class >

own cell memory   < 0,      1 cyc,   word,  small >
neighbour cell    < 1 hop,  few cyc, word,  small >
DRAM node         < far,    100s,    block, large >

Local SRAM is for bandwidth and deterministic access, not for storing every byte a system might need. A large DRAM pool is still necessary for cold data, model loading, datasets, checkpoints, and host interaction. Honeycomb treats that DRAM as a region of the same cost-space: a memory node presents the mesh interface, even though the controller behind it is different silicon.

The practical first form is DRAM attached at the array edge. That leaves some cells farther from bulk memory than others, so schedules must account for the distance. A later package could put memory under the array and make that cost more uniform. The programming model is the same in both cases: movement is explicit and schedulable.

Placement resolves names

Programs name values and tensors, not region+tile+cell+bank addresses. Placement resolves each name to a physical (node, offset), and routing turns movement into explicit copies. Locality is exposed as cost information; software does not depend on a fixed physical coordinate.

This matters for reliability too. If a physical cell is bad, placement can disable it and remap names elsewhere. A uniform array makes every healthy location a possible spare.

Boot without a master

The array should not need a privileged tile to start. Every cell has the same boot ROM. On reset, cells run identical code, discover their position from the mesh boundary, and organize distributed startup without a central sequencer. Edge devices such as storage, console, and DRAM are attached to ordinary edge cells and driven by programs.

The trust target is a measured boot path: replicated ROM verifies the first image before executing it, and later stages can be checked against the same architecture contract used by the Lean model.

Deterministic movement

There is no cache coherence protocol and no implicit remote load. Movement is expressed as operations such as copy, fill, launch, and barrier, with deterministic completion and failure states. Static-rate kernels can be scheduled ahead of time; control code can still branch, but within a bounded machine model.

The current book proves the first mesh layer: Manhattan-distance routing, faithful payload transport, and uniform composition over the proved cell. Larger meshes with contention are part of the remaining fabric work.

Self-hosting

Self-hosting is a trust goal, not a performance claim. The near-term target is narrow: prove and build the hardware rule that lets generated instruction memory become fetchable in a deterministic way.

The intended rule is restrictive: write an instruction region while the target is stopped, then perform an explicit visibility operation before it can be fetched. Once that is proved, the next milestones are an assembler that rebuilds itself bit-for-bit and a checker that validates generated artifacts on the machine.

Proof surface

The verification story is intentionally small:

• one proved cell — memory, MAC, control semantics, and execute-path refinement;
• one uniform composition — the mesh theorem over identical cells;
• one movement model — explicit packets with proved delivery properties;
• one visibility rule — fetch-after-write for generated instruction memory;
• one boot contract — replicated ROM and measured startup.

The design is not simpler for style. It is simpler because each omitted special case is a proof obligation that does not have to exist.

What cannot be flattened

Some non-uniformity remains and is part of the model:

1. Distance — a far node costs more than a near one.
2. The edge — external devices attach somewhere.
3. DRAM controllers — bulk memory is different silicon behind a uniform interface.
4. Capacity — local SRAM gives bandwidth, while large storage still lives outside the cell.