Performance

Latency first, joules per token second, raw peak last.

Honeycomb is built for regimes where movement dominates arithmetic: batch-1 decode, long-context inference, deterministic serving, and workloads that keep weights resident near the datapath. Every number on this page carries its evidence tag, and none of it is measured silicon.

The current performance evidence is a conservative physical anchor: generated RTL for a macro-backed cell routed in sky130, with activity-driven power measured on the routed netlist, plus analytical models for how that cell scales into a mesh. Those numbers are useful because they come from a real standard-cell library, real SRAM macros, routed wires, parasitic extraction, and static timing. They are not production-node claims.

Current physical anchor

The strongest routed run is honeycomb_cell_mac, a generated cell with a pipelined multiplier and five bound sky130 SRAM macros, all of them behind access-driven clock gates. It routes with zero DRC violations, passes KLayout signoff DRC and LVS cleanly, and meets setup and hold at all nine STA corners at a 29 ns clock — with the reset fully timed (recovery, removal, and its functional fan-in meet at every corner; the earlier blanket exception is gone) and the only remaining timing exception the combinational debug taps. The routed netlist itself passes the complete golden program suite at gate level, plus a randomized lock-step co-simulation checked against the proved ISA semantics at every retire. Scope, stated plainly: the SRAM macros’ timing library exists only at the typical corner, and residual max-slew/max-cap violations on structural nets (antenna diodes, the clock input, vendor macro pins) are waived and enumerated in the evidence record — a diode-insertion pass was evaluated and rejected on a worse overall ledger, so the antenna nets stand as a documented tapeout-time item.

The clock number is low, and that is expected for this evidence point: it is sky130, the open high-density library, a general OpenLane flow, real SRAM macro timing, and no frequency-driven optimization. Its job is to prove that the generated memory-rich cell can be physically routed and timed. The 16 nm test chip is where frequency, voltage, power, and area become a product-facing PPA anchor.

Where the energy goes

Power here is workload-specific, not vectorless: the routed netlist is gate-level simulated under real workloads, the switching activity is annotated back onto the placed design, and OpenROAD reports the decomposition. The numbers that follow are the ungated baseline — the first measurement, before any clock discipline — because it is the decomposition that states the architecture’s thesis most clearly. At the 29 ns clock, that baseline cell draws 9.80 mW running a kmac workload and 9.59 mW idle-but-resident — a difference of about 2%. That gap is the whole story:

About 99% of the cell’s power is residency and clocking; the arithmetic is 1–2%. That is the architecture’s own thesis showing up in physical estimates: in a memory-resident fabric, keeping weights near the datapath — not multiplying — is where the joules go. It also means the energy lever is scheduling and clock discipline, not a cheaper multiplier.

Driving the standing cost down

Three levers have been built and measured, each taken back through place-and-route rather than estimated:

Gate the idle data memory. A resident kmac loop never touches the scalar data memory, yet the ungated cell clocks its macros every cycle. Access-driven clock gating drops kmac power from 9.80 to 7.13 mW (−27%), and the gated cell still closes setup and hold at all nine corners with zero DRC and clean LVS — the saving is real, not bought with timing.

Gate every memory. The instruction, weight, and stream memories are re-read every cycle even though their addresses are stable across an instruction. Gating all five macros drops kmac power to 3.72 mW (−62%) and idle to 3.10 mW; SRAM falls from ~70% of cell power to 16%. This point was first recorded on an eight-of-nine-corner close (one decode setup path missed by 0.27 ns at the slowest corner); the record tile since closes all nine corners with every memory gated — delay-mapped synthesis buys the margin at +38% standard-cell area, a cost stated rather than hidden.

Pipeline the datapath. The five-phase cell retires one MAC every five clocks (145 ns/MAC). A dedicated streaming kmac datapath — the RTL image of the scheduling chapter’s shift-register pipeline, proved to retire the identical accumulator at any latency — issues one MAC per cycle: 34.5 MMAC/s at ~59 pJ/MAC (2.02 mW activity-driven), routed clean at all nine corners with +10.28 ns of setup slack in 0.47 mm². That is 5× the five-phase throughput and roughly 9× better energy than the all-gated general cell — two effects compounding: one MAC per cycle amortizes the standing power over five times the work, and the dot-product datapath keeps only two macros resident instead of five.

The general control cell converges on the same lesson. Pipelining its fetch and splitting its multiply (the proved control-hazard and operand-interlock pipeline, emitted as honeycomb_cell_fpipe) takes its critical path from ~49 ns to ~29 ns; the one residual at signoff is a tool-structural gated-clock transition check, the same waiver class the mac cell carries. The durable takeaway: arithmetic throughput belongs in the dedicated streaming datapath, and the general cell’s job is control — both meet the same clock.

Together the levers move the fully-loaded energy from 1.42 nJ/MAC (ungated, five-phase) to 0.54 nJ/MAC (all-gated) to ~59 pJ/MAC (streaming) — a ~24× range that confirms the residency cost is reducible engineering overhead, not a floor.

The record tile, as routed today, carries the all-gated memories through a full nine-corner signoff and re-measures the ladder on its own netlist: 3.43 mW parked, 4.02 mW running kmac (117 pJ/cycle, 0.58 nJ/MAC at five clocks per MAC), with the SRAM share of a running cell holding near 15% — down from ~70% ungated. The lever narrative above keeps its original measurements deliberately: each step was taken back through place-and-route when it landed, and the record tile is the sum, measured again.

What Honeycomb should win

Honeycomb does not lead with peak TOPS. Its useful performance story is realized service behavior:

• Low inter-token latency: decode stays on the resident-weight datapath instead of rereading weights through a distant hierarchy.
• Flat latency under small batches: batch-1 and low-concurrency requests are the point, not an inconvenience hidden by batching.
• Tight jitter: deterministic schedules make p99 and max latency sit close to p50.
• Lower movement energy: fewer external bytes per token translate into lower joules/token when the working set fits the resident placement.
• Repeatable output: bit-exact runs across schedule and batch conditions reduce operational variance — and make results auditable.

The recorded same-node comparison — GPU figures measured, Honeycomb figures model targets generated from the book’s recorded constants:

GPU: RTX 2000 Ada, GPT-2, same-node. Percentages are computed from the book’s recorded constants.

That table is intentionally narrow — same node, one model family, throughput-shaped. The measurement plan below is how it grows into latency distributions, energy per token, and scaling curves.

Projection ladder

The defensible path from today to production has three rungs:

The 16 nm chip replaces sky130 as the public PPA anchor as soon as bring-up produces stable measurements; production-node numbers then scale from measured 16 nm behavior, never directly from sky130.

Comparison stance

The Landscape page places Honeycomb against the major accelerator architectures — GPUs, wafer-scale, SRAM-resident deterministic ASICs, reconfigurable dataflow, and tiled meshes — at the architectural level. The benchmark comparisons planned here are selected to answer different questions:

• GPU serving: H100/H200/B200-class systems on TTFT, TPOT, p99 latency, throughput under a latency SLO, joules/token, and cost per million tokens.
• Low-latency inference ASICs: Groq-style deterministic systems on latency, jitter, batch sensitivity, SRAM residency, and compiler-visible scheduling.
• Architecture-normalized view: tokens/sec/W, tokens/sec/mm^2, pJ/MAC, bytes moved per token, and realized utilization instead of raw peak TOPS.

Raw throughput matters, but it sits below latency, energy, and determinism. Honeycomb is not trying to be a denser GPU; it is trying to make a smaller, checkable, memory-resident fabric win the serving cases where GPUs are underutilized.

The measurement plan

Honeycomb is before silicon, so this section is a contract, not a results page: the axes that become results as the implementation matures, each labeled with its source until the 16 nm chip replaces estimates with measurements.

Latency suite — serving behavior, not just maximum throughput: time to first token, time per output token, p50/p90/p99/max, latency versus batch and concurrency, long-context decode at several context lengths, and maximum throughput while p99 TPOT stays under a stated service target. This is the suite where the architecture should be strongest: a flatter low-batch curve with less jitter, because schedules and movement are explicit.

Energy suite — split by operation and workload: pJ/MAC, pJ/SRAM access, pJ/mesh hop, pJ/cycle idle versus resident-kernel versus moving-packets, joules/token for prefill and decode, and tokens/sec/W at a fixed latency SLO. The first two passes exist for the compute cell (the decomposition above); pJ/mesh-hop waits on routing the mesh, and corner spread waits on a characterized SRAM library beyond TT.

Accuracy suite — performance is not credible without the numeric path: perplexity and downstream-task deltas against FP16/BF16, sensitivity to block size and accumulator width, overflow-bound coverage for the kernels used in public results, and bit-exact reproducibility across runs. The proofs give a stronger story than empirical quantization alone; the site will still show empirical deltas next to the theorems.

Scaling suite — measured at each boundary: single cell, tile, line and grid mesh, larger simulated meshes, and multi-chip projection once 16 nm measurements exist. Metrics include hop latency, bisection bandwidth, route contention, weak and strong scaling, and placement failure rate with cells disabled as spares.

Methodology rules — every published number carries: its source rung (sky130 estimate, 16 nm measured, production projection); model and parameter count; quantization and accumulator format; context length; batch and concurrency; clock, voltage, and corner where applicable; and whether power is vectorless, activity-driven, or measured at the board. One uncaveated number would make the careful numbers harder to trust.