Performance
Latency first, power 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 can keep weights resident near the datapath.
Honeycomb does not yet have measured silicon. The current performance evidence is a conservative physical anchor: generated RTL for a macro-backed cell routed in sky130, plus analytical models for how that cell should scale 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 current run is honeycomb_cell_mac, a generated cell with a pipelined multiplier and five bound sky130 SRAM macros. It routes cleanly with powered macros and meets setup and hold across nine corners at a 29 ns clock.
| Metric | Current sky130 estimate | Evidence | How to read it |
|---|---|---|---|
| Routed clock | 29 ns, 34.5 MHz | recorded | A conservative achieved floor, not the architecture target. |
| STA-implied limit | about 36.6 MHz | recorded | Derived from worst setup slack in the final run; needs reruns at tighter clocks. |
| Power | 11.36 mW nominal TT, 10.33-12.25 mW across reported corners | recorded | OpenROAD vectorless/default-activity estimate, not measured silicon power. |
| Energy per cycle | 329 pJ nominal TT, 300-355 pJ across reported corners | modeled | Computed from reported power at the routed clock. |
| Instance area | 1.168 mm^2 | recorded | 0.214 mm^2 standard cells plus 0.954 mm^2 SRAM macros. |
| Routed die box | 5.58 mm^2 | recorded | Intentionally roomy for routing; not a tile-area claim. |
The clock number is low. That is expected for this evidence point: it is sky130, uses the open high-density standard-cell library, closes through a general OpenLane flow, includes real SRAM macro timing, and was not pushed as a frequency-optimized design. Its job is to prove that the generated memory-rich cell can be physically routed and timed. The 22 nm test chip is the first place where frequency, voltage, power, and area become a credible product-facing PPA anchor.
Where the energy goes
The power number above is now workload-specific, not vectorless. We gate-level simulate the routed signoff netlist under real workloads, dump switching activity, and let OpenROAD annotate it onto the placed design (method and caveats in the repo’s test/power/README.md). At the 29 ns clock, a kmac workload draws 9.80 mW and an idle-but-resident cell draws 9.59 mW — a difference of about 2%. That gap is the whole story:
| Where the power goes (resident cell) | Share | recorded |
|---|---|---|
| SRAM macros (kept clocked) | ~70% | five bound sky130 SRAM macros |
| Clock tree | ~15% | clock distribution |
| Registers | ~15% | sequential state |
| MAC arithmetic (the actual compute) | ~2% | combinational datapath |
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 silicon estimates: in a memory-resident fabric, keeping weights near the datapath — not multiplying — is where the joules go. The near-term power lever is clock-gating idle SRAM and amortizing the standing cost across a faster clock, not a cheaper multiplier.
The per-operation energy has to be read in that light:
| Energy metric | Value | How to read it |
|---|---|---|
| Per cycle (kmac, activity-driven) | 284 pJ | recorded, vs 329 pJ vectorless |
| Marginal per MAC (compute only) | ~30 pJ | modeled, of which ~14 pJ is the multiply |
| Fully-loaded per MAC | ~1.42 nJ | modeled, residency-dominated standing cost |
The fully-loaded 1.42 nJ/MAC is large, and deliberately not the headline. It is inflated by two current-cell artifacts, neither architectural: the five-phase control retires only one MAC every five clocks (145 ns/MAC, ~6.9 M MAC/s per cell), and there is no clock gating, so the resident SRAM and clock tree are billed to every MAC. A throughput-pipelined datapath at one MAC per cycle divides it by about five, and clock-gating the SRAM removes most of the rest. It is the standing cost of an unoptimized sky130 cell, not a floor on Honeycomb’s arithmetic energy.
What Honeycomb should win
Honeycomb should not lead with peak TOPS. Its useful performance story is realized service behavior:
- Low inter-token latency: decode should stay close to the resident-weight datapath instead of rereading weights through a distant memory 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 should make p99 and max latency much closer to p50.
- Lower movement energy: fewer external bytes per token should translate into lower joules/token when the working set fits the resident placement.
- Repeatable output: bit-exact runs across schedule and batch conditions are part of the performance claim because they reduce operational variance.
The current home-page table shows same-node utilization for prefill and decode:
| Workload | GPU (measured) | Honeycomb (target) | Evidence |
|---|---|---|---|
| LLM prefill (compute-bound) | 76,206 tok/s (100.0% of peak) | about 0.9×, comparable; MAC utilization ~89–91% | modeled |
| Decode, batch-1 (latency-bound) | 430 tok/s (0.6% of peak) | about 200× faster; weights stay resident, no memory wall | measured / modeled |
| Decode, batch-32 (throughput) | 8,523 tok/s (11.2% of peak) | about 9× faster; batching recovers some GPU throughput | measured / modeled |
GPU: RTX 2000 Ada, GPT-2, same-node. Percentages are computed from the book’s recorded constants.
That table is intentionally narrow. The next version of the performance page should show latency distributions, energy per token, and scaling curves, not only throughput.
Projection ladder
The defensible path from today to production has three rungs:
| Rung | Source | Website label |
|---|---|---|
| sky130 physical anchor | OpenLane routed reports over open sky130 cells and SRAM macros | recorded estimate |
| 22 nm test chip | measured frequency, voltage, power, shmoo, and workload counters from fabricated silicon | measured silicon |
| production node | projection from measured 22 nm data using stated density, voltage, SRAM, and frequency assumptions | projected |
The 22 nm chip should replace sky130 as the public PPA anchor as soon as bring-up produces stable measurements. The production-node page should then scale from measured 22 nm behavior, not directly from sky130.
Comparison stance
The comparisons should be selected to answer different questions:
- GPU serving: compare against H100/H200/B200/GB-class systems on TTFT, TPOT, p99 latency, throughput under latency SLO, joules/token, and cost per million tokens.
- Low-latency inference ASICs: compare against Groq-style LPU systems on deterministic latency, jitter, batch sensitivity, SRAM residency, and compiler-visible scheduling.
- Architecture-normalized view: compare tokens/sec/W, tokens/sec/mm^2, pJ/MAC, bytes moved per token, and realized utilization instead of raw peak TOPS.
Raw throughput still matters, but it should sit below latency, energy, and determinism. Honeycomb is not trying to be a denser GPU. It is trying to make a smaller, checkable, memory-resident compute fabric win the serving cases where GPUs are underutilized.
Next measurements
The vectorless-to-activity-driven step above is now done for the compute cell: idle, control, and kmac traces run through the routed netlist, and OpenROAD reports pJ/cycle and the power decomposition by workload. What remains before the 22 nm chip becomes the measurement source:
- pJ/mesh-hop needs the router and mesh through place-and-route; only the compute cell is routed today, so per-hop energy is not yet measurable.
- Corner spread on activity power: only a TT SRAM library exists, so the activity numbers are nom-TT only.
- Clock-gated and pipelined variants, to show the residency and control overhead coming down rather than just noting that it dominates.
- Load/store and decode-shaped traces, extending the workload matrix beyond the datapath.
Those numbers will still be estimates, but they are workload-specific estimates. That is the right intermediate step before the 22 nm test chip becomes the measurement source.