RESEARCH RTL
The RTL is supplied under a written evaluation agreement. The interface contract, cycle model and measured verification results are public on this page. CV-X1 Pro L8 remains the released, public IP.
Arithmetic contract
group[r,g] = Σ (signed4(w[r,k]) − signed4(zp[r,g])) × signed8(x[k]) # k in group g, 32 columns
row[r] = Σ int64(group[r,g]) × uint8(scale[r,g])
output[r] = clamp(row[r], −2147483648, 2147483647) # once, after the whole rowThe scale is an integer 0..255, not a floating-point exponent. Saturation happens once per row, after all groups. CV-X1 Pro saturates per tile instead, so the two are not numerically interchangeable. Group, product and accumulation ranges fit the RTL's 18-, 26- and 64-bit registers for every supported dimension.
Configuration
| Parameter | Legal range | Notes |
|---|---|---|
| ROWS | 1..4096, divisible by P | Primary size 256; other sizes in the verification report |
| COLS | 32..65536, multiple of 32 | Primary size 4096; other sizes in the verification report |
| P | 1..ROWS, divides ROWS | Row engines, eight multiplication lanes each |
Derived tile, group and address-width parameters are fixed by these three. A legal value is not thereby verified; the verified configurations are named in the verification report.
Interfaces
- Command: accepted on a rising edge when
start_valid && start_ready. One command at a time; a heldstart_validstarts the next command when the core returns to idle. There is no hidden command queue. - Memory: load every weight, metadata and activation location through the reference memory's write ports before start, and do not write them until
done. Reset does not clear or initialize storage. - Reads:
mem_renrequests one synchronous read; data returns after that edge and is consumed on the next. There is no wait input, so a memory with longer latency needs an adapter and revalidation. - Words: weights P × 32 bits (eight signed nibbles per row); activations eight signed bytes shared by all row engines; metadata P × 12 bits (scale
[7:0], signed zero point[11:8]). Row-major bank layout: weight address = row_block × (COLS/8) + tile; metadata address = row_block × (COLS/32) + group. - Output: P signed 32-bit rows at once with
out_rowandout_last, held stable whileout_readyis low.donepulses on acceptance of the final block. This is a wide ready/valid research interface, not an AXI-compliant bus. - Reset: active-low; aborts work and clears valid, controller and accumulator state. Deassert it synchronously in an integration.
- Resident device wrapper: connects the core, input memories and a ROWS × 32-bit result memory. Configuration writes are blocked while a command runs; results are read back synchronously after completion.
Cycle model
With out_ready held high, a dense command takes, from acceptance to the first valid presentation of the final output block:
cycles = (ROWS / P) × (COLS / 8 + 7) − 1
resident result (device wrapper) = cycles + 1cycle_count stops at that presentation and excludes loading. read_count counts issued memory reads; stall_count counts cycles with out_valid && !out_ready. Counters reset on each accepted command. A cycle count is not a nanosecond measurement: converting it needs a clock that closes timing with real memory.
Measured results
| Check | Result |
|---|---|
| Core against an independent Python integer model | 136 cases in Icarus Verilog 13.0 and Verilator 5.052; 120,700 output rows compared; 0 mismatches. Covers real memory writes, consecutive commands, reset, random output stalls, extreme signs, saturation and cancellation. |
| Resident device wrapper, both simulators | Memory loading, configuration/start arbitration, writes rejected while busy, two resident operations, readback and reset: pass. 128 × 512, P = 8: 1,136 resident cycles; 256 × 4096, P = 256: 519 resident cycles, equal to the cycle model. |
| Formal safety (Yosys BMC + induction) | ROWS = 2, COLS = 32, P = 1, arbitrary memory and receiver ready: output hold, row order, bounds and reset recovery pass. Not an arithmetic proof for every parameter, and not a liveness proof when ready stays low. |
At the primary size, 256 × 4096 with one row block (P = 256), the cycle model gives 518 core cycles and 519 resident cycles. These are simulated cycles of the RTL, not a timed silicon result.
Open-PDK layout results for a CV-GEMV core are on the physical implementation page.
Same-condition comparison
CV-GEMV is measured against the published open designs that can be rerun, in one fixed flow on the same processes and real model data, with pass lines fixed before any result and the verdict computed by code.
| Verdict | Revision | By code | Cross-review (round 8, 2026-11-08) |
|---|---|---|---|
| Nangate45 and ASAP7 | r14 | reached | confirm |
| Three manufacturable open PDKs | r14 | not reached (open gate: G3 gf180) | confirm |
Metrics, every row and raw files: same-condition comparison.
Revisions
The arithmetic contract and interface above are the same for every revision. The implementation revisions measured on the comparison page change only the circuit inside the core, and each is checked block by block to give results identical to the first revision. An evaluation agreement names the revision delivered.
Storage and implementation scope
At 256 × 4096 the useful storage is 577,536 bytes: 524,288 bytes of weights, 49,152 bytes of packed metadata and 4,096 bytes of activations. Each issued cycle the core reads P × 32 weight bits and 64 activation bits, plus P × 12 metadata bits at each group boundary; that bandwidth has to be built before physical performance can be claimed.
The supplied memory is synthesizable inferred-array RTL used in both simulators. Compute-only synthesis excludes it. No foundry SRAM macro, SRAM timing, area or power, clock tree, pad interface or silicon measurement is part of this release.
Not claimed
- Whole-model accuracy or throughput.
- Drop-in numerical compatibility with CV-X1 Pro's per-tile saturation.
- Physical memory timing, or any latency in nanoseconds.
- Production readiness: this is research RTL.
Evaluate CV-GEMV
Tell us your matrix sizes, memory budget and target process through the inquiry form. Evaluation starts with a written agreement and a verification plan for your configuration; see licensing.
