One narrow problem. Every open design we could rerun. The same flow.

What this page claims, and what it does not

Under the conditions below, CV-GEMV r14 (PAIR_REG = 0 on Nangate45, PAIR_REG = 1 on ASAP7, by the timing rule) has the highest throughput per cell area, the lowest energy per useful multiply-accumulate and the fewest bits read per useful multiply-accumulate of the open designs in the table, VTA's tuned and carry-save rows included, in Nangate45 and ASAP7, with bit-exact results.

The verdict for the three manufacturable open PDKs is separate (see below). The CV-GEMV number format loses less model accuracy than INT4 with 128-column groups and than MXFP4, measured the same way.

Rule change, 2026-11-07: this verdict now takes the latest CV-GEMV revision instead of r7. (a) When the rule was written, the r8 and r9 results in these two processes were already published; (b) in return the comparator bar was raised with two tuned VTA rows; (c) the r7 verdict and its two review rounds stay on this page as history.

History: the earlier verdict (CV-GEMV r7, r7c on Nangate45 and r7r on ASAP7, against the comparators as published then) was reached and confirmed in round 2 after round 1's findings were fixed. Against the best VTA row now in the table, tuned and carry-save rows included, r7 is at Nangate45 M1 -3.3%, M2 -9.5%; ASAP7 M1 -6.9%, M2 -5.2%.

It does not claim anything about other problems (batched matrix multiplication, convolution, training), commercial IP we cannot rerun, GPUs, or fabricated silicon. Where CV-GEMV loses or wins only narrowly, the section Where the margin is small says so.

Status: reached (all gates and all metrics pass). An independent reviewer from a different model family has confirmed it.

The problem and the conditions

• Workload: Qwen2.5-0.5B layer 12 mlp.down_proj (896 × 4864) on WikiText-2 test tokens. 4,358,144 useful multiply-accumulates per token.
• Arithmetic: signed INT4 weights with a signed INT4 zero point and an unsigned 8-bit integer scale per 32 columns, signed INT8 activations, exact integer result per row. Every W4A8 engine computes the same integers (the W8A8 baseline uses its own per-row INT8 weights and is labelled as a baseline); where an engine cannot apply the group scale or row sum itself, the host does it and that work is not charged to the engine.
• Every engine is sized to the same peak, 64 multiply-accumulates per cycle.
• Flow: OpenROAD-flow-scripts in one pinned container image, the same constraint shape and utilisation target for every engine. ASAP7 (typical corner, RVT) at 1000 ps and Nangate45 (typical) at 4.0 ns.
• Power: every routed netlist replays real tokens of the same layer at gate level (every output checked), and OpenSTA applies that switching activity with extracted parasitics at the target clock. Most engines replay the first two tokens; the TPU and Gemmini, whose batch-1 replays are about eight times longer, replay the first token only; replaying the second token instead changes their energy by at most 0.04% (check). Energy is divided by the useful work in each engine's own window.
• Excluded for every engine: storage (SRAM), I/O pads, multi-corner sign-off and host work. These exclusions favour the comparators, several of which keep large accumulators or partial sums outside the engine.
• A design that misses the target clock is scored at its own minimum period for throughput.

The engines

• Apache TVM VTA matrix-vector core (Apache-2.0, d4a15f6). Its official module generated from the Chisel source, and a register-for-register hand port that matched it on 200,000 random cycles. Since 2026-11-07 both also appear tuned, with the three changes from r9 and r10 that VTA's structure has (accumulator pipe registers without load enables, exact widths at VTA's interface, Booth-recoded 5-bit MACs; pipeline stages, valid-result latency and results unchanged, checks and diffs), and, after review round 3 noted that CV-GEMV r10 and r11 had carry-save trees while VTA did not, tuned with carry-save trees as well (each MAC's Booth partial products, and each row's eight products plus its accumulator value, summed in carry-save with one add each; same checks, checks and diffs). VTA is scored with the best of the six rows for every metric. Not applied to VTA (rules, 2026-11-08 06:57): CV-GEMV r13 and r14 recode their scale into Booth digits before the register that feeds the multiplier, and VTA's weights also pass an input register before its MACs, but the worst setup path of every tuned and carry-save VTA row, in all five processes, starts after the MACs and ends at the accumulator output, so the same move cannot shorten VTA's clock and would add register bits to all 64 MACs. CV-GEMV's revisions r8 to r14 were chosen from its own GF180MCU timing.
• OpenGeMM BlockGemm (KU Leuven MICAS, Apache-2.0), 1 × 8 × 8, generated from the unchanged Chisel source.
• Gemmini spatial array (UC Berkeley, BSD-3-Clause), 8 × 8, weight-stationary, generated from the unchanged Chisel source outside the Chipyard SoC.
• LogikBench TPU matrix unit (Zero ASIC, MIT), 8 × 8, as shipped in OpenROAD-flow-scripts.
• Plain W8A8 GEMV, a textbook engine we wrote with the same peak and memory style, as a labelled baseline.
• CV-GEMV, this IP. Its RTL is supplied under an evaluation agreement; the routed reports, logs and power files are published here.

The two systolic arrays (TPU, Gemmini) are built for matrix-matrix work. At batch 1 they keep 1 of 8 columns busy, which is why their numbers are far apart from the others; they are included because they are the open references most often cited.

Results

★ marks the CV-GEMV setting that the rules fix for each process. Every number links back to the raw files in its row folder.

Nangate45, 4.0 ns

ASAP7, 1000 ps

M1 = useful multiply-accumulates per second per mm² of standard-cell area. M2 = workload power × replay window ÷ useful multiply-accumulates. M3 = bits the engine must read (weights, group data, activations) per useful multiply-accumulate; each row states its basis in the JSON.

Before and after design work

The first CV-GEMV version (r1) lost to VTA. It was then improved with ordinary engineering in steps r2 to r14 (retiming, one group-scale multiplier shared between rows, narrower counters, the zero point folded out of the lanes, registers without load enables, exact widths, Booth recoding, carry-save registers), each checked block by block to give results identical to r1. On Nangate45, throughput per area went from 262.6 to 627.7 GMAC/s per mm² and energy from 1.283 to 0.695 pJ. On ASAP7, r1 missed 1000 ps (scored at 840 MHz); r14 meets it. The comparators keep their published default structure; VTA, the strongest, also appears with the same kinds of ordinary change.

Where the margin is small, and what CV-GEMV loses

• Throughput per area against VTA's best row on Nangate45 (VTA hand port, tuned + carry-save): +32.1%; on ASAP7 (VTA hand port, tuned + carry-save): +17.9%. The pass line counts anything within ±1% as a tie.
• VTA needs fewer cycles per token (68,097 versus 69,104).
• Nangate45: CV-GEMV r14 does not have the shortest minimum period (1.980 ns); Plain W8A8 GEMV (baseline) closes at 1.300 ns.
• ASAP7: CV-GEMV r14 does not have the shortest minimum period (0.806 ns); Plain W8A8 GEMV (baseline) closes at 0.803 ns.
• The PAIR_REG setting is chosen by the timing rule (0 if it meets the target clock, otherwise 1), written before the r14 results; the other setting is in the table.
• Energy per useful multiply-accumulate against VTA's best row: -24.5% on Nangate45, -16.2% on ASAP7.
• Accuracy: the CV-GEMV format is about equal to the same format with floating-point scales (+14.1% versus +14.0%), not better.
• Under four shared flow-setting variants the smallest margins against VTA's best row are Nangate45 M1 +32.1%, M2 -24.2%; ASAP7 M1 +17.6%, M2 -15.4% (Flow settings).
• On 11 more projections (other layers and models) the smallest margins against the best comparator row are Nangate45 M1 +27.4%, M2 -22.9%; ASAP7 M1 +13.4%, M2 -14.3%; SKY130HD M1 +14.6%, M2 -20.5% (nine projections: its 2,432 × 896 CV-GEMV build did not route, so gate_proj and up_proj have no CV-GEMV row); GF180MCU M1 +46.4%, M2 -2.6%; IHP SG13G2 M1 +14.5%, M2 -26.2% (Other layers and models).
• At 256 MACs per cycle, against the best 256-MAC comparator row: Nangate45 M1 +12.3%, M2 +4.1%; ASAP7 M1 -7.9%, M2 +26.0%; SKY130HD M1 +0.9%, M2 +12.9%; GF180MCU M1 +32.2%, M2 +25.7%; IHP SG13G2 M1 +5.6%, M2 -1.8% (Four times the size).
• A later revision, r15, built as 16 rows of 16 columns at 256 MACs per cycle (not the verdict subject), against the same 256-MAC comparator rows: Nangate45 M1 +26.9%, M2 -4.2%; ASAP7 M1 +9.4%, M2 +4.3%; SKY130HD M1 +18.1%, M2 -2.6%; GF180MCU M1 +36.1%, M2 +21.3%; IHP SG13G2 M1 +15.4%, M2 -13.0% (Another shape at 256 MACs).

Manufacturable open PDKs: not reached

The same comparison, with its conditions fixed before the first open-PDK result and later changes dated in the rules, in three processes that can be fabricated through open shuttles: SKY130HD, GF180MCU and IHP SG13G2, one 8.0 ns target for all (the clock OpenROAD-flow-scripts ships for its ibex reference design on each). CV-GEMV's setting per process was fixed in advance (PAIR_REG = 0 if it meets 8.0 ns). Result by the same code: not reached.

• GF180MCU: no engine, CV-GEMV included, meets 8.0 ns (CV-GEMV misses by 0.016 ns), so the timing gate fails.
• IHP SG13G2: the pinned flow's IHP platform file removes every standard cell from the netlists it writes for its equivalence check, so that check compared empty netlists for every IHP row whose flow ran it (the TPU's flow left no final check log). By the rule of 2026-11-07 09:13, G2 here comes from the same checker run the flow's way on netlists written from the same databases with only the bond-pad pattern removed: identical (lec.txt; the flow's own record is lec-flow.txt).
• Second machine (G4): 33 of 33 rows reproduced, 0 differences (table).
• Bits read per useful MAC (M3), bit-exact results and model accuracy do not depend on the process and still pass.

History: with r7 these processes lost throughput per area to VTA by 5.6 % (SKY130HD) and 17.5 % (IHP). r8 folds the zero point out of the 64 lanes (the standard identity sum (w - zp) x = sum w x - zp sum x) and drops the performance counters; it is identical to r1 block for block and bit-exact on the real layer, and the rules made it the subject here before any r8 result. With r8, SKY130HD and IHP passed every metric; on GF180MCU r8 missed 8.0 ns (9.37 ns) and tied VTA on energy. r9 takes the load-enable multiplexers out of registers that are read only under a valid flag (the GF180MCU library has no enable flip-flop, so each enable is a multiplexer), shifts the waiting group results one row per phase instead of selecting them, and gives every register its exact width; results and cycle counts are r8's, and the rules made r9 the subject before any r9 result. With r9 every metric passed in all three processes and GF180MCU closed at 8.05 ns. r10 recoded the lane weights in radix-4 Booth digits, registered each pair sum in two parts with the carry between them kept as one bit, and held the activation sum in carry-save form; it shrank the PAIR_REG = 0 layouts (SKY130HD -7 %, IHP -11 %) but slowed the stage after the pair registers, and GF180MCU closed at 9.15 ns. r11 rebuilt that stage as one carry-save tree and took the plain scale product back; GF180MCU closed at 8.48 ns. r12 split the four pair sums at different bits so their carries enter the group tree without a counting adder, summed the scale product in an explicit carry-save tree and cleared the row accumulators from a register: 8.08 ns. r13 took the scale as radix-4 Booth digits recoded when it is copied (three carry-save levels instead of four) and moved the pair splits so that no upper add is wider than r11's: 8.01 ns. r14 holds those digits one-hot, so each partial-product bit is one AND-OR: 8.02 ns. By the rule the subject is the latest revision (r14), not the one that closed fastest. On 2026-11-07 VTA also got two tuned rows, which raised the bar in every process. The claim above stays limited to Nangate45 and ASAP7 until this verdict is reached.

Attempts: r2 to r14 were all made for this comparison (r1 is the first version measured); 8 of them were measured in GF180MCU (r7 to r14). Each revision's rule was committed before its result, but every extra attempt adds a chance of keeping one that met the target by luck, so all of them stay in summary.json (the tables on this page show r1 and r7 to r14). GF180MCU minimum period per revision (the shorter of its two settings; target 8.0 ns): r7 10.90 ns, r8 9.37 ns, r9 8.05 ns, r10 9.15 ns, r11 8.48 ns, r12 8.08 ns, r13 8.01 ns, r14 8.02 ns.

SKY130HD, 8.0 ns

GF180MCU (9-track, 5 V), 8.0 ns

IHP SG13G2, 8.0 ns

Flow settings

The flow gives the same result for the same inputs as far as it was checked: for every row a verdict uses, a second machine (one per row: the Mac or AWS) reproduced every number in the table (gate G4), with the same routed netlist for 22 of 22 main-verdict rows (second-machine.json), and here the 3 ASAP7 rows run again at the published setting on the AWS instance reproduced every number. So instead of a random seed the margins were tested against small changes of two settings every engine shares: core utilization and the placement density add-on. The rows and variants were fixed before any run (rules, 2026-11-07 14:34): in each process the CV-GEMV subject and every VTA row within 5 % of VTA's best M1 or M2 there (21 rows), every variant applied to all of them, flows, replay and power on the AWS instance. Each cell is CV-GEMV's margin over the best of those VTA rows under that setting (the row that is best can change; it is named in the JSON).

No variant reverses a metric: in every process and metric each margin stays outside the ±1 % band. The closest is GF180MCU M2, -2.9% (density add-on 0.15). None of the rule's four variants changed whether a row meets its clock, its routing DRC count or its replay result. On GF180MCU CV-GEMV misses its clock in every variant as in the published table, so its throughput there is scored at its own minimum period and the timing gate stays open. The verdicts are not changed by this study.

Correction (rules, 2026-11-07 18:00, after the results): the rule gave the base utilization as 45 %; in ASAP7 it is 50 %, so there the 50 % column is the published configuration itself (the AWS run reproduced every numeric field of the three published ASAP7 rows) and 40 % is ten points below it. Added after the results and outside the fixed rule, the three ASAP7 rows at 45 and 55 % (below; not part of the smallest value): no metric reverses.

ASAP7 at 55 %: VTA hand port, tuned + carry-save misses its 1000 ps target by 0.30 ps and is scored at its own minimum period.

All six VTA rows (rules, 2026-11-07 18:48, written after the round-5 cross-review and before these runs): the 14 VTA rows the rule left out were run under the same four settings, and ASAP7's four of them also at 45 and 55 %. Each cell below is CV-GEMV's margin over the best of all six VTA rows under that setting. This is reported apart from the rule's result above, which stays as published.

Against all six VTA rows no metric reverses or comes within ±1 % either. In no variant is a left-out row VTA's best, so the margins equal the rule's. ASAP7 at 45 and 55 % against all six: M1 +18.8%, +18.2%; M2 -16.4%, -15.9% (none reversed or within ±1 %). Under density add-on 0.25, ASAP7 vta8_official_tuned misses its 1000 ps target by 14.62 ps and is scored at its own minimum period (in the published table it meets it).

The current subject (r14)

The study above was fixed on 2026-11-07 for the subject of that day (r11). When both verdicts moved to r14 (rules of 2026-11-08, each revision's entry written before its results; these runs were fixed at 06:21), its subject row in each process was run under the same four settings, and ASAP7's also at 45 and 55 %, on the AWS instance. Each cell is r14's margin over the best of all six VTA rows under that setting (the VTA rows are the published variant rows above). Reported apart; no verdict depends on it.

No metric reverses or comes within ±1 %. ASAP7 at 45 and 55 %: M1 +18.2%, +17.7%; M2 -16.1%, -16.0% (none reversed or within ±1 %). Worst setup slack of each subject under each setting (gate G3 is decided by the published flow; this shows how far the other settings move it):

GF180MCU: r14 misses 8.0 ns under the published table, utilization 40 %, utilization 50 %, density add-on 0.15. Tables: utilization 40 %, utilization 50 %, density add-on 0.15, density add-on 0.25, ASAP7 at 45 %, ASAP7 at 55 %.

Sensitivity JSON ↓ · Each variant's table, with a raw-file folder per row: utilization 40 %, utilization 50 %, density add-on 0.15, density add-on 0.25, ASAP7 at 45 %, ASAP7 at 55 % · all VTA rows, utilization 40 % · all VTA rows, utilization 50 % · all VTA rows, density add-on 0.15 · all VTA rows, density add-on 0.25 · all VTA rows, ASAP7 at 45 % · all VTA rows, ASAP7 at 55 %

Other layers and models

Both verdicts use one projection. As written on 2026-11-08 08:40, before any of these files existed, the verdict subject (CV-GEMV r14, the setting the subject rule chose in each process) and every comparator row of the tables were measured in all five processes on 11 more projections (except CV-GEMV on SKY130HD gate_proj and up_proj, whose build did not route; see Gates): the other six of the base layer, down_proj of the first and the last layer, and down_proj of the middle layer of three recent models. Each projection's data comes from the base pipeline (the same calibration, the eight preregistered token positions, per-token INT8); the generator first reproduced the base table's 15 input files byte for byte (14 of them have published hashes). VTA, the TPU, OpenGeMM and Gemmini take any shape at run time and were replayed on their published routed netlists. CV-GEMV and the W8A8 baseline fix the shape when they are built, so each new shape is a new build of the same RTL with the same flow settings; CV-GEMV takes at most 4096 rows per command, so gate_proj and up_proj run as two commands on one 2,432 × 896 build; between them the testbench swaps the weight and group memories in zero time, as it swaps the query between tokens (storage is outside every engine), and both commands' cycles and reads are counted. As in the base table, the TPU and Gemmini replay one token and the others two. No verdict changes; this is reported apart.

Smallest margin over the base table and the eleven projections (SKY130HD: the base table and nine projections), and energy per MAC over the seven projections of layer 12 together:

Throughput per area (M1): CV-GEMV's margin over the best comparator row

No workload puts this margin inside ±1% or reverses it.

Energy per useful MAC (M2): CV-GEMV's margin over the best comparator row

No workload puts this margin inside ±1% or reverses it.

Bits read per useful MAC (M3): -10.4% in every process and projection; the count depends on the formats and the tiling, not on the data.

Written before the results: CV-GEMV r14 spends a fixed 9 or 10 cycles per block of eight rows, which VTA's mapping does not, so on the 896-column projections (7 to 8 % of its cycles instead of 1.5 %) its M1 margins were expected several points smaller, and the GF180MCU energy margin, the closest of the base table, might fall inside ±1 % or reverse. Margins in bold are inside ±1 % or reversed. The best comparator row of every cell is in the JSON.

Result: on the 896-column projections the M1 margins are Nangate45 +27.4 to +28.9% (base +32.1%); ASAP7 +13.4 to +14.6% (base +17.9%); SKY130HD +14.6 to +16.6% (base +21.2%); GF180MCU +46.4 to +48.4% (base +51.3%); IHP SG13G2 +14.5 to +18.5% (base +18.8%). GF180MCU M2 ranges from -4.9% to -2.6% over the base table and the eleven projections; it does not fall inside ±1 % or reverse.

Gates

• Nangate45: 121 replays, every output bit-exact. CV-GEMV: 6 of 6 new builds routed, 0 DRC violations, setup met at the target. W8A8: 6 of 6 new builds routed, 0 DRC violations, setup met at the target.
• ASAP7: 121 replays, every output bit-exact. CV-GEMV: 6 of 6 new builds routed, 0 DRC violations, setup met at the target. W8A8: 6 of 6 new builds routed, 0 DRC violations, setup met at the target.
• SKY130HD: 119 replays, every output bit-exact. CV-GEMV: 5 of 6 new builds routed, 0 DRC violations, setup met at the target; the 2432 × 896 build did not route (detailed routing ended with 1 violation and unrouted nets), so gate_proj and up_proj have no CV-GEMV row. W8A8: 6 of 6 new builds routed, 0 DRC violations, setup met at the target.
• GF180MCU: 121 replays, every output bit-exact. CV-GEMV: 6 of 6 new builds routed, 0 DRC violations, setup missed at the target by 0.008 ns (1536 × 12288), 0.009 ns (2048 × 6144), 0.028 ns (896 × 896), 0.068 ns (1024 × 3584) (scored at their own minimum period). W8A8: 6 of 6 new builds routed, 0 DRC violations, setup missed at the target by 0.188 ns (896 × 896), 0.478 ns (1024 × 3584), 0.501 ns (4864 × 896), 0.541 ns (1536 × 12288), 0.654 ns (2048 × 6144), 1.056 ns (128 × 896) (scored at their own minimum period).
• IHP SG13G2: 121 replays, every output bit-exact. CV-GEMV: 6 of 6 new builds routed, 0 DRC violations, setup met at the target. W8A8: 6 of 6 new builds routed, 0 DRC violations, setup met at the target.

Each replay row of the eleven projections (603; the 55 base rows are the base table's own) names the machine it ran on (AWS instance: 311, Azure build VM: 292) and the SHA-256 of the routed netlist it read. The replays of each published routed row all read one and the same netlist (55 of 55 rows); for the 22 rows whose netlist hash second-machine.json publishes, it is that netlist. The generator's check on the base projection compared 15 files, 0 different; the 14 whose hashes fixtures.json publishes are listed with those hashes (equal). The route log of the build that did not route: excerpt.

Workload breadth JSON ↓ · raw files per row under /evidence/compare/workloads/.

Four times the size: 256 MACs per cycle

Every engine above has a peak of 64 multiply-accumulates per cycle. As written on 2026-11-08 16:51, before any source, input file, flow or replay at the new size, the verdict subject (CV-GEMV r14 with the setting the subject rule chose in each process, now with 32 rows per cycle) and every comparator row were built at 256 MACs per cycle and measured on the base layer in all five processes: the W8A8 baseline with 32 rows; VTA at 16 × 16 (its default size) in its six rows; the TPU at 16 × 16; Gemmini as a 16 × 16 mesh (its default); OpenGeMM at 1 × 16 × 16. Each process's flow settings are those of the same 64-MAC row; only the size changed. VTA's square shape is its default and needs half the accumulators of a 32 × 8 shape, which favours VTA. No verdict changes; this is reported apart.

Checks before any flow, as the rule fixed them: at size 8 the generalised input generator reproduced the 15 base files byte for byte, and the generalised testbenches gave the published replay lines of 12 of 12 64-MAC rows exactly; at 256 MACs all 12 of 12 rows replay bit-exact at RTL. The VTA hand ports at 16 × 16 follow VTA's own source, which moves the pipeline register of the dot product from the first adder layer (8 × 8) to the third (16 × 16, after two adder layers); each hand port was checked cycle by cycle against the module generated from the unchanged Chisel, and the tuned and carry-save copies against their unchanged modules (25 runs of 200,000 cycles, 0 mismatches; a deliberately broken copy fails). The program that makes the tuned and carry-save copies of the generated module gives the published 8 × 8 copies byte for byte.

CV-GEMV's margin over the best 256-MAC comparator row

The 64-MAC columns are the same comparison on the published rows (higher M1 and lower M2 are better; bold: inside ±1 % or reversed). Bits read per useful MAC (M3): -15.9% in every process.

Written before the results: the cycles per token follow from the mappings (CV-GEMV about 17,275 or 17,303, VTA 17,025), so the cycle ratio to VTA stays the base table's; VTA's and OpenGeMM's accumulators only double while their multipliers quadruple, while CV-GEMV's per-row parts grow four times, so the margins over VTA might be smaller than at 64 MACs or reverse. Result: inside ±1 % or reversed: Nangate45 M2 +4.1% (VTA official generated module, 16 × 16); ASAP7 M1 -7.9% (VTA official generated module, 16 × 16); ASAP7 M2 +26.0% (VTA official generated module, 16 × 16); SKY130HD M1 +0.9% (VTA official module, tuned + carry-save, 16 × 16); SKY130HD M2 +12.9% (VTA official module, tuned + carry-save, 16 × 16); GF180MCU M2 +25.7% (VTA official generated module, 16 × 16)

Reported, not used (written before the results): the flow inserts timing-repair buffers, most of them hold buffers on the registers that take an engine's inputs directly (CV-GEMV / VTA's largest count: Nangate45 5546 / 15382; ASAP7 9600 / 9110; SKY130HD 10351 / 7488; GF180MCU 7618 / 13745; IHP SG13G2 10029 / 15146). With every row's timing-repair buffer area left out, M1 margins are Nangate45 +10.2% (64 MACs: +26.2%); ASAP7 -5.9% (64 MACs: +7.0%); SKY130HD +6.6% (64 MACs: +21.0%); GF180MCU +24.4% (64 MACs: +48.8%); IHP SG13G2 +0.3% (64 MACs: +17.3%).

Built with hold repair off after the flow stopped at the hold-repair buffer limit (second fallback, which favours the row): ASAP7 VTA hand port, 16 × 16, ASAP7 VTA hand port, tuned + carry-save, 16 × 16, ASAP7 VTA official generated module, 16 × 16, ASAP7 VTA official module, tuned + carry-save, 16 × 16, ASAP7 VTA official module, tuned, 16 × 16, ASAP7 VTA hand port, tuned, 16 × 16, Nangate45 VTA official generated module, 16 × 16.

Each engine at 256 MACs over itself at 64 MACs

Gates

• Nangate45: 11 rows replayed, every output bit-exact; every row meets the target clock; 0 route DRC violations.
• ASAP7: 11 rows replayed, every output bit-exact; setup missed at the target by VTA hand port, tuned + carry-save, 16 × 16 11.100 ps, VTA official module, tuned, 16 × 16 17.300 ps, VTA official module, tuned + carry-save, 16 × 16 18.600 ps, LogikBench TPU MXU 16 × 16 58.900 ps, VTA hand port, 16 × 16 111.600 ps, VTA hand port, tuned, 16 × 16 173.600 ps, OpenGeMM BlockGemm 1 × 16 × 16 1128.700 ps (scored at their own minimum period); 0 route DRC violations.
• SKY130HD: 11 rows replayed, every output bit-exact; setup missed at the target by VTA hand port, tuned + carry-save, 16 × 16 0.003 ns, VTA official generated module, 16 × 16 0.040 ns, VTA hand port, tuned, 16 × 16 0.126 ns, VTA official module, tuned, 16 × 16 0.138 ns, VTA hand port, 16 × 16 0.152 ns, OpenGeMM BlockGemm 1 × 16 × 16 6.538 ns (scored at their own minimum period); 0 route DRC violations.
• GF180MCU: 11 rows replayed, every output bit-exact; setup missed at the target by CV-GEMV r14, PAIR_REG = 1, P = 32 0.410 ns, Plain W8A8 GEMV (baseline), P = 32 0.943 ns, Gemmini mesh 16 × 16, weight-stationary 1.379 ns, VTA official generated module, 16 × 16 3.221 ns, VTA official module, tuned + carry-save, 16 × 16 3.310 ns, VTA official module, tuned, 16 × 16 3.326 ns, VTA hand port, tuned + carry-save, 16 × 16 3.331 ns, LogikBench TPU MXU 16 × 16 3.382 ns, VTA hand port, tuned, 16 × 16 4.446 ns, VTA hand port, 16 × 16 5.256 ns, OpenGeMM BlockGemm 1 × 16 × 16 17.732 ns (scored at their own minimum period); 0 route DRC violations.
• IHP SG13G2: 11 rows replayed, every output bit-exact; setup missed at the target by OpenGeMM BlockGemm 1 × 16 × 16 1.476 ns (scored at their own minimum period); 0 route DRC violations.

Machines: AWS instance: 23 rows, Azure build VM: 32 rows; each row names its machine and the SHA-256 of its routed netlist.

Reproduction

As written on 2026-11-08 17:49, every 256-MAC row was built and replayed once more from clean folders on the AWS instances, two of the same image and setup (the Azure rows on a second machine, the AWS rows as a clean rerun). Compared per row: the routed netlist's SHA-256, cell area, setup slack, route DRC, the replay's cycles and result lines, and the power. 55 of 55 rows are identical in every field. The margins above use the first run; each row's second-run values are in size256.json (reproduction, rows).

256-MAC JSON ↓ · raw files per row under /evidence/compare/size256/.

Other layers and models at 256 MACs

As written on 2026-11-08 17:49, the eleven projections of the workload-breadth section, with the same integers, on the 256-MAC subject and every 256-MAC comparator row: VTA, the TPU, OpenGeMM and Gemmini replay their 256-MAC routed netlists; CV-GEMV and the W8A8 baseline are built for each new shape, only the shape changed. Smallest margin over the base layer and the projections (the cell least favourable to CV-GEMV), next to the same at 64 MACs (higher M1 and lower M2 are better):

605 replays, every output bit-exact. Inside ±1 % or reversed: Nangate45 down_proj (base) M2 +4.1% (VTA official generated module, 16 × 16); Nangate45 q_proj M2 +7.8% (VTA official generated module, 16 × 16); Nangate45 k_proj M2 +7.9% (VTA official generated module, 16 × 16); Nangate45 v_proj M2 +8.3% (VTA official generated module, 16 × 16); Nangate45 o_proj M2 +1.6% (VTA official generated module, 16 × 16); Nangate45 gate_proj M2 +8.4% (VTA official generated module, 16 × 16); Nangate45 up_proj M2 +8.2% (VTA official generated module, 16 × 16); Nangate45 layer 0 down_proj M2 +10.5% (VTA official generated module, 16 × 16); Nangate45 layer 23 down_proj M2 +11.5% (VTA official generated module, 16 × 16); Nangate45 Qwen3.5-0.8B down_proj M2 +3.8% (VTA official generated module, 16 × 16); Nangate45 Qwen3.5-2B down_proj M2 +3.4% (VTA official generated module, 16 × 16); Nangate45 Gemma 4 E2B down_proj M2 +8.2% (VTA official generated module, 16 × 16); ASAP7 down_proj (base) M1 -7.9% (VTA official generated module, 16 × 16); ASAP7 down_proj (base) M2 +26.0% (VTA official generated module, 16 × 16); ASAP7 q_proj M1 -12.0% (VTA official generated module, 16 × 16); ASAP7 q_proj M2 +33.5% (VTA official generated module, 16 × 16); ASAP7 k_proj M1 -11.3% (VTA official generated module, 16 × 16); ASAP7 k_proj M2 +32.6% (VTA official generated module, 16 × 16); ASAP7 v_proj M1 -11.3% (VTA official generated module, 16 × 16); ASAP7 v_proj M2 +33.2% (VTA hand port, 16 × 16); ASAP7 o_proj M1 -12.0% (VTA official generated module, 16 × 16); ASAP7 o_proj M2 +26.9% (VTA official module, tuned + carry-save, 16 × 16); ASAP7 gate_proj M1 -11.9% (VTA official generated module, 16 × 16); ASAP7 gate_proj M2 +33.1% (VTA official generated module, 16 × 16); ASAP7 up_proj M1 -11.9% (VTA official generated module, 16 × 16); ASAP7 up_proj M2 +32.9% (VTA official generated module, 16 × 16); ASAP7 layer 0 down_proj M1 -7.9% (VTA official generated module, 16 × 16); ASAP7 layer 0 down_proj M2 +29.9% (VTA official generated module, 16 × 16); ASAP7 layer 23 down_proj M1 -7.9% (VTA official generated module, 16 × 16); ASAP7 layer 23 down_proj M2 +30.8% (VTA official generated module, 16 × 16); ASAP7 Qwen3.5-0.8B down_proj M1 -6.9% (VTA official generated module, 16 × 16); ASAP7 Qwen3.5-0.8B down_proj M2 +25.6% (VTA official generated module, 16 × 16); ASAP7 Qwen3.5-2B down_proj M1 -7.4% (VTA official generated module, 16 × 16); ASAP7 Qwen3.5-2B down_proj M2 +26.4% (VTA official generated module, 16 × 16); ASAP7 Gemma 4 E2B down_proj M1 -6.9% (VTA official generated module, 16 × 16); ASAP7 Gemma 4 E2B down_proj M2 +29.7% (VTA official generated module, 16 × 16); SKY130HD down_proj (base) M1 +0.9% (VTA official module, tuned + carry-save, 16 × 16); SKY130HD down_proj (base) M2 +12.9% (VTA official module, tuned + carry-save, 16 × 16); SKY130HD q_proj M1 -1.5% (VTA official module, tuned + carry-save, 16 × 16); SKY130HD q_proj M2 +10.1% (VTA official module, tuned + carry-save, 16 × 16); SKY130HD k_proj M2 +7.0% (VTA official module, tuned + carry-save, 16 × 16); SKY130HD v_proj M2 +7.5% (VTA official module, tuned + carry-save, 16 × 16); SKY130HD o_proj M1 -1.5% (VTA official module, tuned + carry-save, 16 × 16); SKY130HD o_proj M2 +12.5% (VTA official module, tuned + carry-save, 16 × 16); SKY130HD gate_proj M1 -1.1% (VTA official module, tuned + carry-save, 16 × 16); SKY130HD gate_proj M2 +10.2% (VTA official module, tuned + carry-save, 16 × 16); SKY130HD up_proj M1 -1.1% (VTA official module, tuned + carry-save, 16 × 16); SKY130HD up_proj M2 +10.1% (VTA official module, tuned + carry-save, 16 × 16); SKY130HD layer 0 down_proj M1 +0.9% (VTA official module, tuned + carry-save, 16 × 16); SKY130HD layer 0 down_proj M2 +12.7% (VTA official module, tuned + carry-save, 16 × 16); SKY130HD layer 23 down_proj M1 +0.9% (VTA official module, tuned + carry-save, 16 × 16); SKY130HD layer 23 down_proj M2 +13.1% (VTA official generated module, 16 × 16); SKY130HD Qwen3.5-0.8B down_proj M2 +9.7% (VTA official module, tuned + carry-save, 16 × 16); SKY130HD Qwen3.5-2B down_proj M2 +9.0% (VTA official module, tuned + carry-save, 16 × 16); SKY130HD Gemma 4 E2B down_proj M2 +12.7% (VTA official module, tuned + carry-save, 16 × 16); GF180MCU down_proj (base) M2 +25.7% (VTA official generated module, 16 × 16); GF180MCU q_proj M2 +33.9% (VTA official generated module, 16 × 16); GF180MCU k_proj M2 +33.4% (VTA official generated module, 16 × 16); GF180MCU v_proj M2 +34.1% (VTA official generated module, 16 × 16); GF180MCU o_proj M2 +26.1% (VTA official generated module, 16 × 16); GF180MCU gate_proj M2 +34.5% (VTA official generated module, 16 × 16); GF180MCU up_proj M2 +34.3% (VTA official generated module, 16 × 16); GF180MCU layer 0 down_proj M2 +30.5% (VTA official generated module, 16 × 16); GF180MCU layer 23 down_proj M2 +31.3% (VTA official generated module, 16 × 16); GF180MCU Qwen3.5-0.8B down_proj M2 +25.2% (VTA official generated module, 16 × 16); GF180MCU Qwen3.5-2B down_proj M2 +27.0% (VTA official generated module, 16 × 16); GF180MCU Gemma 4 E2B down_proj M2 +31.5% (VTA official generated module, 16 × 16); IHP SG13G2 gate_proj M2 -0.8% (VTA hand port, tuned + carry-save, 16 × 16); IHP SG13G2 up_proj M2 -1.0% (VTA hand port, tuned + carry-save, 16 × 16). New builds that miss the target clock, scored at their own minimum period: GF180MCU CV-GEMV r14, PAIR_REG = 1, P = 32 1,024 × 3,584 by 0.160 ns, GF180MCU CV-GEMV r14, PAIR_REG = 1, P = 32 128 × 896 by 0.166 ns, GF180MCU CV-GEMV r14, PAIR_REG = 1, P = 32 1,536 × 12,288 by 0.152 ns, GF180MCU CV-GEMV r14, PAIR_REG = 1, P = 32 2,048 × 6,144 by 0.339 ns, GF180MCU CV-GEMV r14, PAIR_REG = 1, P = 32 2,432 × 896 by 0.252 ns, GF180MCU CV-GEMV r14, PAIR_REG = 1, P = 32 896 × 896 by 0.115 ns, GF180MCU Plain W8A8 GEMV (baseline), P = 32 1,024 × 3,584 by 0.872 ns, GF180MCU Plain W8A8 GEMV (baseline), P = 32 128 × 896 by 0.966 ns, GF180MCU Plain W8A8 GEMV (baseline), P = 32 1,536 × 12,288 by 0.767 ns, GF180MCU Plain W8A8 GEMV (baseline), P = 32 2,048 × 6,144 by 0.631 ns, GF180MCU Plain W8A8 GEMV (baseline), P = 32 4,864 × 896 by 1.086 ns, GF180MCU Plain W8A8 GEMV (baseline), P = 32 896 × 896 by 0.806 ns, IHP SG13G2 Plain W8A8 GEMV (baseline), P = 32 1,536 × 12,288 by 0.007 ns, SKY130HD CV-GEMV r14, PAIR_REG = 0, P = 32 896 × 896 by 0.030 ns; route DRC 0 on every new build. Written before the results: CV-GEMV's fixed cycles per row block do not depend on P, so its M1 margins on the 896-column projections were expected several points smaller than on the base layer, as at 64 MACs. Result: the smallest M1 margin is 1.6 to 4.1 points below the base layer's in every process.

256-MAC workloads JSON ↓ · raw files under /evidence/compare/workloads256/.

Which size a memory keeps busy

Reported, not used (rule written 2026-11-08 18:18, before any 256-MAC metric). In single-token decoding every weight is read once per token, so a memory of peak bandwidth BW feeds at most 8 × BW / M3 useful MACs per second, M3 being CV-GEMV's measured bits per useful MAC on the base layer at 256 MACs (4.625). Divided by the 256-MAC row's clock and utilization this is the number of MACs per cycle that keeps up; the table gives the smallest power of two from 64 to 4,096 not below it. Peak bandwidths are from the JEDEC standards (transfer rate × bus width / 8); a real controller reaches less, so every size is an upper bound. * not a measured size (computed from the 256-MAC row's clock, utilization and M3, which another size would change).

The token rate counts the seven projections of each of the 24 layers and the 151,936 × 896 output projection (493,961,216 MACs per token), nothing else. Bandwidth the measured rows themselves read at their clocks (GB/s):

Written before the results: on LPDDR5X-8533 x64 the size was expected to be 128 or 256 in every process. Result: Nangate45 512, ASAP7 128, SKY130HD 1024, GF180MCU 1024, IHP SG13G2 1024 MACs, so the expectation did not hold in Nangate45, SKY130HD, GF180MCU, IHP SG13G2.

Sizing JSON ↓

Another shape at 256 MACs: 16 rows of 16 columns

The 256-MAC rows above build CV-GEMV r14 as 32 rows of 8 columns per cycle. As written on 2026-11-10 11:20, before any flow, replay or power of the rows below, a later revision, r15, was built as 16 rows of 16 columns per cycle: the same 256 MACs per cycle, the same integers, the same two tokens and the same outputs. Each process uses the flow settings and target clock of its 256-MAC r14 row; only the source file, its parameters and the names changed. Three builds per process differ in the pipeline registers of the dot product (PAIR_REG = 0, 2 and 1, fewest flip-flops first). The shape and the PAIR_REG = 2 setting were fixed after the 256-MAC results above, from RTL replays and synthesis areas, before any flow of an r15 row; a second shape (8 rows of 32 columns) was looked at by synthesis only and is not measured. The comparator rows are the published 256-MAC rows above, not rebuilt. No verdict changes: the verdicts' subject stays r14, and r15's RTL is not public, as r14's is not.

Checks before any flow: built at r14's shapes, the r15 source gives the published replay lines of 3 of 3 published rows exactly (64 MACs and 256 MACs); at 16 × 16 all 3 of 3 builds replay bit-exact at RTL, and the expected outputs are the published 256-MAC row's file, byte for byte.

The row reported for each process

Chosen by timing only, before any power or metric was read: the first of the three builds, in the order below, that meets the target clock with 0 route DRC violations; if none does, the one with the shortest minimum period. Setup slack at the target clock (bold: chosen):

Margin over the best 256-MAC comparator row

The r14 columns are the margins of the 256-MAC table above, against the same comparator rows (higher M1 and lower M2 are better; bold: inside ±1 % or reversed). Bits read per useful MAC (M3): 4.875, -11.4% in every process (r14: 4.625, -15.9%); with 16 rows per cycle in place of 32, each activation is read twice as often.

r15 at 16 × 16 over r14 at 32 × 8, same process

Written before the results: by synthesis areas and cycle counts, M1 was expected to rise by about 10 % where PAIR_REG = 0 is chosen and about 18 % where PAIR_REG = 2 is chosen in place of r14's PAIR_REG = 1, and energy per MAC to fall most where PAIR_REG = 2 is chosen; whether r14's reversed margins would turn was not known. Result: M1 over r14 Nangate45 +13.0%; ASAP7 +18.7%; SKY130HD +17.0%; GF180MCU +2.9%; IHP SG13G2 +9.3%; energy per MAC over r14 Nangate45 -8.0%; ASAP7 -17.2%; SKY130HD -13.7%; GF180MCU -3.4%; IHP SG13G2 -11.4%; inside ±1 % or reversed with r14 and no longer with r15: Nangate45 M2, ASAP7 M1, SKY130HD M1, SKY130HD M2; still inside ±1 % or reversed: ASAP7 M2 +4.3% (VTA official generated module, 16 × 16); GF180MCU M2 +21.3% (VTA official generated module, 16 × 16).

All three builds

Gates

• Nangate45: 3 builds replayed, every output bit-exact; every build meets the target clock; 0 route DRC violations.
• ASAP7: 3 builds replayed, every output bit-exact; setup missed at the target by PAIR_REG = 0 108 ps (scored at their own minimum period); 0 route DRC violations.
• SKY130HD: 3 builds replayed, every output bit-exact; setup missed at the target by PAIR_REG = 0 0.231 ns (scored at their own minimum period); 0 route DRC violations.
• GF180MCU: 3 builds replayed, every output bit-exact; setup missed at the target by PAIR_REG = 0 5.935 ns, PAIR_REG = 2 2.746 ns, PAIR_REG = 1 0.992 ns (scored at their own minimum period); 0 route DRC violations.
• IHP SG13G2: 3 builds replayed, every output bit-exact; every build meets the target clock; 0 route DRC violations.

Reproduction

Each reported row was built and replayed once more from a clean folder on the other AWS instance (two instances of the same image and setup). Compared per row: the routed netlist's SHA-256, cell area, setup slack, route DRC, the replay's cycles and result lines, and the power. 5 of 5 rows are identical in every field. The margins use the first run; the second run's values are in the JSON (reproduction, rows).

16 × 16 JSON ↓ · raw files per build under /evidence/compare/lanes256/.

r16 at 256 MACs: ASAP7 and GF180MCU

This two-process pilot evaluates CV-GEMV r16 at 16 rows × 16 columns per cycle, using the same integer workload and two tokens as the r15 study above. The target clocks and flow conditions are unchanged. Area, timing and energy are tool estimates from routed layouts and replay activity. The reference rows are the published r15 and 256-MAC comparator rows; they were not rebuilt for this pilot. The margins below use the first run.

The verdict above evaluates r14. The r16 results apply to ASAP7 and GF180MCU. The measurement and reproduction status is complete. Timing and performance criteria are shown separately below.

Measured results

Margins against the reference rows

Higher M1 and lower M2/M3 are better. The best comparator is chosen separately for each metric. Bold margins are within ±1% or worse; a margin within ±1% is not a win. ASAP7: M1 better, M2 worse, M3 better; GF180MCU: M1 better, M2 worse, M3 better.

Clocks and routing checks

M1 uses the target period when setup is met and otherwise the layout's minimum period. M2 remains the activity-based power estimate at the common target period. When setup is missed, that M2 value is not an energy measurement at a clock that the layout meets. Storage and host work are excluded from both designs, as in the published comparison.

Reproduction

Compared fields: routed-netlist SHA-256, cell area, setup slack, route DRC, cycles per token, replay-result SHA-256, workload power, replay result, flow-setting fingerprint. 2 of 2 reproduced rows are identical in all listed fields; 2 were reproduced on the other instance. The second-run values and differences are in the JSON. Equal replay results do not by themselves establish timing or energy superiority.

r16 JSON ↓ · public report summaries under /evidence/compare/r16/.

Model accuracy by weight format

Same model, same text, same harness; activations are per-token INT8 for every format; only the weight format changes. Perplexity increase over 8 pre-registered windows of 512 tokens. All formats use plain round-to-nearest encoding without calibration (GPTQ, AWQ or rotations could change the order).

The pass line asks that the CV-GEMV format (+14.1%) not be worse than INT4 with 128-column groups (+22.3%) and MXFP4 at its better encoder (+25.7%). NVFP4 (+16.3%) is reported, not part of the pass line.

Recent models

The same check on recent open models (weights rounded the same way, every linear layer of the language decoder quantized, the model's own tokenizer). Pinned revisions are in models.json.

NVFP4 loses less accuracy than the CV-GEMV format on Qwen3.5-2B, gemma-4-E2B. It is reported, not part of the pass line.

Gates

• G1 (nangate45), gate-level replay of the real tokens, 0 output mismatches: pass
• G2 (nangate45), final netlist formally equivalent to synthesis: pass
• G3 (nangate45), 0 routing DRC violations and the target clock met: pass
• G1 (asap7), gate-level replay of the real tokens, 0 output mismatches: pass
• G2 (asap7), final netlist formally equivalent to synthesis: pass
• G3 (asap7), 0 routing DRC violations and the target clock met: pass
• G4, a second, independent run reproduces the table: pass: on a second machine, 22 of 22 rows reproduced, 0 differences (table); from clean directories on the build machine, 22 of 22 rows reproduced, 0 differences (table)

Independent review

Round 1 (2026-11-06): OpenAI Codex CLI 0.166.0, model gpt-6-astra, reasoning effort low, read-only sandbox; public material only: reproduce.zip, public/evidence/compare/, the comparison pages. Conclusion: disagree. The reviewer recomputed M1–M3 for 10 rows from the raw files; findings are quoted as written.

Round 2 (2026-11-06): OpenAI Codex CLI 0.166.0, model gpt-6-astra, reasoning effort low, read-only sandbox; public material only: reproduce.zip, public/evidence/compare/, the comparison pages. Conclusion: confirm. The reviewer recomputed M1–M3 for 10 rows from the raw files; findings are quoted as written.

Round 3 (2026-11-07): OpenAI Codex CLI 0.166.0, model gpt-6-astra, reasoning effort low, read-only sandbox; public material only: reproduce.zip, public/evidence/compare/, before-13/summary.json, the comparison pages. Conclusion: confirm (main verdict, r11), confirm (open PDKs). The reviewer recomputed M1–M3 for 11 rows from the raw files; findings are quoted as written.

Round 4 (2026-11-07): OpenAI Codex CLI 0.166.0, model gpt-6-astra, reasoning effort low, read-only sandbox; public material only: reproduce.zip, public/evidence/compare/, before-csa/summary.json, the comparison pages. Conclusion: confirm (main verdict, r11), confirm (open PDKs). The reviewer recomputed M1–M3 for 15 rows from the raw files; findings are quoted as written.

Round 5 (2026-11-07): OpenAI Codex CLI 0.166.0, model gpt-6-astra, reasoning effort low, read-only sandbox; public material only: reproduce.zip, public/evidence/compare/ (sensitivity.json, sensitivity/), the comparison pages. Scope: the flow-setting study only, not the verdicts. Conclusion: disagree. The reviewer recomputed M1 and M2 for 30 rows from the raw files; findings are quoted as written.

Round 6 (2026-11-07): OpenAI Codex CLI 0.166.0, model gpt-6-astra, reasoning effort low, read-only sandbox; public material only: reproduce.zip, public/evidence/compare/ (sensitivity.json, sensitivity/, review.json round 5), the comparison pages. Scope: the flow-setting study only, not the verdicts. Conclusion: confirm. The reviewer recomputed M1 and M2 for 2 rows from the raw files; findings are quoted as written.

Round 7 (2026-11-08): OpenAI Codex CLI 0.166.0, model gpt-6-astra, reasoning effort low, read-only sandbox; public material only: reproduce.zip, public/evidence/compare/ (sensitivity.json, sensitivity/ incl. all-vta/, review.json rounds 5-6), the comparison pages and the CV-GEMV page. Scope: the flow-setting study only, not the verdicts. Conclusion: confirm. The reviewer recomputed M1 and M2 for 22 rows from the raw files; findings are quoted as written.

Round 8 (2026-11-08): OpenAI Codex CLI 0.166.0, model gpt-6-astra, reasoning effort low, read-only sandbox; public material only: reproduce.zip, public/evidence/compare/, the table before the r12 to r14 rows (before-r12/summary.json), the comparison pages and the CV-GEMV page. Conclusion: confirm (main verdict, r14), confirm (open PDKs). The reviewer recomputed M1–M3 for 17 rows from the raw files; findings are quoted as written.

Round 9 (2026-11-08): OpenAI Codex CLI 0.166.0, model gpt-6-astra, reasoning effort low, read-only sandbox; public material only: reproduce.zip, public/evidence/compare/ (workloads.json, workloads/, the base rows), the comparison pages. Scope: the study of other layers and models only, not the verdicts. Conclusion: confirm. The reviewer recomputed M1 and M2 for 20 rows from the raw files; findings are quoted as written.

Round 10 (2026-11-08): OpenAI Codex CLI 0.166.0, model gpt-6-astra, reasoning effort low, read-only sandbox; public material only: reproduce.zip, public/evidence/compare/ (workloads.json, workloads/, the base rows, review.json rounds 1 to 9), workloads.json as round 9 reviewed it, the comparison pages. Scope: the study of other layers and models only, not the verdicts. Conclusion: disagree. The reviewer checked the changes after the previous round against the files (no metric changed); findings are quoted as written.

Round 11 (2026-11-08): OpenAI Codex CLI 0.166.0, model gpt-6-astra, reasoning effort low, read-only sandbox; public material only: reproduce.zip, public/evidence/compare/ (workloads.json, review.json rounds 1 to 10), workloads.json and review.json as round 10 reviewed them, the comparison pages. Scope: the study of other layers and models only, not the verdicts. Conclusion: confirm. The reviewer checked the changes after the previous round against the files (no metric changed); findings are quoted as written.

Round 12 (2026-11-10): Antigravity CLI 1.5.3, model Gemini 4 Argon, effort low, terminal sandbox, run in a copy of the public files (OpenAI Codex, used in rounds 4 to 11, was at its usage limit); public material only: reproduce.zip, public/evidence/compare/ (size256.json, size256/, workloads256.json, workloads256/, bandwidth-sizing.json, the base rows), the comparison pages. Scope: the 256-MAC study only, not the verdicts. Conclusion: confirm. The reviewer recomputed M1 and M2 for 36 rows from the raw files; findings are quoted as written.

Round 13 (2026-11-10): Antigravity CLI 1.5.3, model Gemini 4 Argon, effort low, terminal sandbox, run in a copy of the public files (OpenAI Codex, used in rounds 4 to 11, was at its usage limit); public material only: reproduce.zip, public/evidence/compare/ (size256.json, size256/, workloads256.json, workloads256/, bandwidth-sizing.json, the base rows), the comparison pages. Scope: the 256-MAC study only, not the verdicts. Conclusion: confirm. The reviewer checked the changes after the previous round against the files (no metric changed); findings are quoted as written.

Round 14 (2026-11-10): Antigravity CLI 1.5.4, model Gemini 4 Argon, effort low, terminal sandbox, run in a copy of the public files (OpenAI Codex, used in rounds 4 to 11, was at its usage limit); public material only: reproduce.zip, public/evidence/compare/ (lanes256.json, lanes256/, size256.json, size256/, the base rows), the comparison pages. Scope: the 16 × 16 study at 256 MACs only, not the verdicts. Conclusion: confirm. The reviewer recomputed M1 and M2 for 15 rows from the raw files; findings are quoted as written.

Review record JSON ↓

Published designs we cannot rerun (context only)

These numbers come from papers, under the authors' own conditions, and never enter the verdict. To put them next to ours we scaled them to 7 nm in two ways that disagree: the Stillmaker–Baas scaling equations, and the energy ratio our own flow measures for the same RTL and setting (CV-GEMV r7, PAIR_REG = 1) between Nangate45 and ASAP7 (5.6×). For reference, CV-GEMV r7 on ASAP7: 0.170 pJ per useful MAC and 21,849 GMAC/s per mm².

• The W4A8 decode accelerator from ISLPED 2025 scales to between 0.14 and 0.23 pJ per MAC, which brackets CV-GEMV's figure. Its number is a peak at full array use; ours counts useful work at batch 1. We cannot say which is lower without rerunning it.
• The MXFP4 mode of the ASP-DAC 2026 datapath scales to 0.13–0.17 pJ per MAC with 4-bit activations, a different problem from W4A8.
• Throughput per area is not comparable on equal terms: most published areas include scratchpad memory and all figures are peaks.

Sources, quoted inputs and arithmetic ↓

How the verdict is made

The pass line was written before the verdict: every metric must beat every comparator in both processes, ties within ±1% count as not better, and changes made after results are recorded as dated additions. Most of them can only favour the comparators (VTA's tuned and carry-save rows among them); three concern CV-GEMV itself and are disclosed above: its design was improved in steps r2 to r14, its one build option (PAIR_REG) was first fixed per process after the first r7 results, and on 2026-11-07 the verdict moved from r7 to the latest revision with PAIR_REG chosen by a timing rule. A script applies it to the table; a reviewer from a different model family than the author then reads the raw files and either confirms or lists disagreements. Disagreements are settled by measuring again.

Raw files

Comparison table JSON ↓ · Verdict by code JSON ↓ · Number formats JSON ↓ · Workload hashes ↓

Reproduce: the comparison scripts, flow configurations of the public engines and testbenches are in the reproduction package. The flow runs in the pinned image openroad/orfs@sha256:9aeafa602de8317ea294ec24b95755437546111a08e4e1bce452339401da14b2.