1. Status and Evidence🔗

Honeycomb now has a first generated RTL cell tied to the book's documented boundary. The book proves the executable semantics, kernel arithmetic, block-float identity, small analytical design rules, the RTL DSL execute path against step, the encoded-word fetch bridge feeding that execute path, the abstract lifecycle protocol around reset, host writes, start, and execute gating, and the mesh transport-and-composition model that lifts the single cell to the flat fabric. The first-cell 256-entry physical memory index is explicit in those contracts. A first sky130/OpenLane run was recorded for the earlier inferred-memory cell; that run exposed the expected standard-cell memory expansion and did not reach pre-PNR timing. The hot memories now sit behind honeycomb_sram macro-adapter submodules, and a second sky130 synthesis run is recorded against that boundary: the memories bind as SRAM macros and the mapped flip-flop count collapses by roughly fifty times. The macro-backed honeycomb_cell_mac now routes to a clean powered close, meeting setup and hold across all nine corners. The book does not yet prove parser-level SystemVerilog refinement, does not reach a signoff-clean GDS, and does not claim fabricated silicon or measured Honeycomb hardware.

The status vocabulary is intentionally conservative:

• proved means the claim is a Lean theorem in this book.

• modeled means the claim follows from a checked analytical model and its stated constants.

• recorded means a measured or externally observed constant is copied into the book as evidence, but the book does not reproduce the measurement.

• target means design intent, not completed implementation.

This distinction matters because Honeycomb is meant to become hardware. The book can be exact about a processor contract today while still being explicit that parser-level RTL refinement, timing closure, physical area, and power are future work.

The recorded OpenLane run is deliberately conservative evidence, not a usable tile-area claim. It used the generated honeycomb_cell as-is, with inferred 256-entry program, scalar-data, resident-weight, and stream memories. Yosys reported zero pre-synthesis check problems and no inferred latches, but replaced all memories with registers. After DFF legalization the design contained 318547 cells and 40994 mapped sky130 flip-flops; the reported 875972.627200 square microns covers the mapped sequential cells, while the remaining combinational primitives were still before the final technology-mapped netlist. Final ABC mapping did not complete within the bounded run, so no pre-PNR timing number is recorded.

The important warning is architectural rather than cosmetic: the bare inferred-memory cell is a simulator and proof boundary, but standard-cell synthesis turns the hot storage into a very large flop-and-mux fabric. A credible physical area and timing number needs a macro-backed memory boundary.

The second run answers that warning. With the four hot memories behind honeycomb_sram adapters, the same sky130 standard-cell library, and the sky130_sram_1kbyte_1rw1r_32x256_8 macro bound as a blackbox, synthesis reaches a complete technology-mapped netlist. The program, resident-weight, and stream memories become one 32-bit SRAM macro each, and the 64-bit scalar-data memory becomes a dual-read 64-bit adapter that maps to two of the same 32×256 macros, for five physical SRAM macros in all. The mapped design keeps just 802 sky130 flip-flops for the register file and control state, down from 40994, and 16511 total mapped cells, down from 318547, with zero synthesis check problems and no inferred memories left in the logic. The standard-cell logic occupies about 125809 square microns, dominated by the 64-bit MAC datapath; each SRAM macro is about 190712 square microns, so a macro-backed tile is roughly nine-tenths SRAM by area.

This is deliberately recorded as a synthesis-shape experiment, not a cycle-faithful implementation. The proved honeycomb_sram adapter reads combinationally, while the sky130 macro is a synchronous-read SRAM. Binding the macro therefore demonstrates area and mappability at the documented boundary; a cycle-accurate macro cell needs a registered-read pipeline stage and its own refinement obligation.

That registered-read cell is the fully synchronous honeycomb_cell_sync, and a first placed-macro OpenLane run was made against it. The four adapters bound to five sky130_sram_1kbyte_1rw1r_32x256_8 macros — 5 KiB of SRAM in all: 256 words of 32 bits per macro, with the 64-bit data memory using two. The run reached synthesis, floorplan, macro placement, clock-tree synthesis, and post-CTS static timing. At a 30 ns clock the nominal corner met both setup and hold, but the slow corner left the 64-bit multiply-accumulate path several nanoseconds short even after post-CTS resizing, so routing was not attempted. The critical path is the arithmetic, not the SRAM: closing it needs a slower clock or a pipelined multiplier.

The area of that run is not a tile-area claim. The die was set to 2720 by 1300 microns, about 3.54 square millimeters, chosen loosely so the five macros and their routing had room; it is only about a third utilized. The real content is roughly one square millimeter — about 0.95 for the five SRAM macros and 0.13 for the standard-cell logic — so a tightened floorplan would be far smaller. What the run establishes is a real placed-and-clocked macro cell with an honest timing bottleneck, not a finished tile.

That bottleneck was then attacked directly. The critical path is the 32-bit signed multiply, not the accumulate: a combinational multiply-accumulate and one with the product merely registered route to essentially the same worst path, so the multiplier itself must be pipelined. Splitting the multiply into a half-width partial-product stage and a combine-and-accumulate stage — a two-cycle latency that the scheduling chapter's conservation law already proves leaves the accumulator unchanged — was placed and routed against the combinational baseline. Both were checked to retire the identical signed dot product first. At a 25 ns clock the combinational multiply-accumulate misses timing with a routed worst path of 26.3 ns (−0.78 ns slack), while the pipelined multiplier meets it with a 20.8 ns worst path (+4.87 ns slack): a roughly one-fifth shorter critical path, from a timing violation to comfortable margin, for the same arithmetic. A deeper split would shorten it further. This is the route by which the macro cell reaches timing closure — pipelining the multiply, with the kernel result already proved invariant to the added latency.

That multiplier was then folded into the cell. honeycomb_cell_mac is the fully synchronous cell with the combinational multiply replaced by the two-stage honeycomb_mul2, running each instruction over five phases — fetch, read, mul1, mul2, wb — with the accumulate in the write-back phase taking the pipelined product. It is generated from the same DSL, CI-checked, and passes the full golden program suite with identical architectural results, so the integration is correct. Placed and routed with the SRAM macros, it confirms the multiply is now off the critical path: the worst path no longer starts in the multiplier but at the instruction SRAM macro, whose clock-to-output access alone is about eleven nanoseconds, followed by the decode logic it feeds. At a 20 ns clock the cell improves on the combinational-multiply cell — from a −3.15 ns to a −2.23 ns nominal-corner worst path — but does not close, and the slow corner behaves as before, now on the SRAM path rather than the multiply. The honest lesson is that pipelining the multiply was necessary but not sufficient: the next bottleneck is the SRAM read itself, which closing requires registering the fetched instruction into its own pipeline stage so the macro's access latency stops sharing a cycle with the logic downstream of it.

That step was taken. The cell now re-registers its instruction, resident-weight, and streamed-operand SRAM outputs into standard-cell flip-flops each cycle, so the macro's roughly eleven-nanosecond clock-to-output is isolated on its own SRAM-to-register path, and decode and the multiplier both start from fast registers. This fits the same five-phase schedule -- the register consumes the slack of the read phase -- and the full golden suite still passes with identical results.

Placed and routed on five powered sky130_sram_1kbyte_1rw1r_32x256_8 macros (scripts/pnr-mac.sh), with the macros' vccd1/vssd1 pins tied to VPWR/VGND through PDN_MACRO_CONNECTIONS, detailed routing finishes 100% with zero DRC violations, and post-route static timing closes setup and hold across all nine corners at a 29 ns clock -- worst setup +1.66 ns, worst hold +0.15 ns at the slow ss100C1v60 corner, after post-GRT design repair. This is the first Honeycomb cell to reach a clean, powered physical close; earlier cells stalled in synthesis or in the post-CTS timing resizer before ever routing.

Two earlier numbers were corrected along the way. A previously-recorded "22 ns closes all corners, 15 ns nominal" timing and "twenty-three residual DRC violations" shared one root cause: the SRAM macro power pins were left unconnected, so the router drove signal wires into the untied power shapes -- the DRC shorts -- and the timing was read off an unpowered netlist, which is not a physical result. Tying the macro power pins removed the shorts and moved the honest close to 29 ns. The residual max-slew and max-capacitance violations that remain (~937 at the slow corner) are structural, on the SRAM macro pins and the clock tree, and are left for a signoff waiver or a targeted driver pass.

The 3100 by 1800 micron (5.58 mm^2) die is deliberately loose, about 21 percent utilized -- content is roughly 2.1 mm^2, about 0.95 for the five SRAM macros and 1.17 for the standard-cell logic -- and is not a tile-area claim. So the honest state is a placed, clock-tree-synthesized, and cleanly routed macro cell that closes timing at every corner on powered macros, generated from the same proved DSL and passing the same golden programs -- not yet a signoff-clean GDS. Full signoff DRC (via KLayout, since Magic's GDS reader chokes on the vendor SRAM) and a tightened floorplan are the physical steps that remain.