c1137390e2
The crate is wai-quantum-landscape-fpga, beside the fabric's simulated FPGA member, which has its own workflow. The README gives the board and part as data, what the design does and refuses, what it takes to build, the build and load steps, the checks and the power protocol. No bitstream is distributed: the vendor tool's licence limits a bitstream holding its components to that vendor's devices, which Apache-2.0 does not carry, so the README gives the build and the sha256 of the bitstream measured. measurements/2026-11-05 holds the first version's raw power logs and the predictions committed before them, unchanged. The workflow runs the unit tests and every check against the model of the logic on each change. Co-Authored-By: Claude Opus 5.5 <[email protected]>
54 lines
3.7 KiB
Text
54 lines
3.7 KiB
Text
PRE-REGISTERED, 2026-11-05, before the vQPU-EDGE bitstream had been loaded on the board, and before
|
|
any power was read from it. Written from the RTL, the software model's activity counts
|
|
(`vqpu-edge activity`) and the board's own earlier measurements. Not edited after the data.
|
|
|
|
WHAT IS MEASURED
|
|
Run minus halt on ONE bitstream (kv260/edge, 100 MHz pl_clk0), whole-board INA260, by the board's
|
|
written rules: no reload between states, randomised order each pass, sampling on the board in the
|
|
measuring process with nothing else running, reload detection per point (engine uptime counter must
|
|
keep counting; dmesg FPGA-write count must not move; ID must read back), pass dropped if flagged,
|
|
statistic = mean of per-pass differences of medians, error = SE across passes. Label of every
|
|
number: board-level, this KV260, this design. It is NOT the 0.1596 pJ/accumulate of the old
|
|
constant-folded vehicle and must not be quoted as that: this lowering keeps W in flops and adds a
|
|
product LUT, a compressor and a runtime-theta comparator to every cone, so it has its own rate.
|
|
|
|
THE INSTRUMENT CHECKS, which gate everything else
|
|
K1 known answer: the September vehicle ev_rdet.bit.bin, run/halt by its own script kv_runhalt.sh,
|
|
must reproduce 61.7 mW (its 2026-09-28 run/halt value, +/- 6.5). PASS if within 2 combined sigma.
|
|
If it fails, no number below is reported as measured.
|
|
K2 null: on the vQPU-EDGE bitstream, halt against halt (one slot labelled run): 0 mW.
|
|
PASS if |delta| < 2 SE.
|
|
|
|
PREDICTIONS (point value, and the range outside which I am wrong)
|
|
Reasoning: the old det vehicle drew 61.7 mW at 8.68 state flips per clock, i.e. ~71 pJ per flip with
|
|
its constant-folded cones. This lowering has ~3x the LUTs per cone (product + compressor + tree +
|
|
comparators), and a flip drives all 64 cones, so I take 2.5x per flip, uncertain by 2x either way.
|
|
|
|
class what repeats flips/clock predicted P_dyn range
|
|
t0-recall dense Hebbian n=64 (8 patterns), T=0 settle 6.88 122 mW 60..250
|
|
from a 30%-corrupted cue, 5 steps, reload
|
|
gibbs-recall same landscape, 8 sequential Gibbs sweeps at 0.028 5 mW 0..20
|
|
beta=4 + one T=0 step, reload (1539 clocks/job)
|
|
- cones barely move; what is left is PRNG, table
|
|
read, field mux and counters
|
|
solve-assign the 3x3 equality landscape (n=9), 39-sweep anneal ~0.1 3 mW 0..15
|
|
from T=1, final T=0 step; 55 of the 64 cones have
|
|
W=0 and cannot switch
|
|
t0-idle W=0, bound 0: the job FSM looping with a static 0 1 mW 0..10
|
|
datapath (control and counters only)
|
|
|
|
Derived, for t0-recall: 12.5 M settles/s at 8 clocks each => ~10 nJ per settle; with its accumulate
|
|
count (5 steps x nnz) that is about 0.5 pJ per accumulate, range 0.25..1.0. I expect it to be WORSE
|
|
than the old 0.16 pJ/accumulate, because the couplings are now data, not wiring.
|
|
|
|
WHAT WOULD REFUTE THE REASONING
|
|
- t0-recall outside 60..250 mW: the per-flip cost of this lowering is not 1-5x the old one.
|
|
- gibbs-recall above 20 mW: something other than state flips (the field mux, the table, the PRNG)
|
|
costs far more than the toggle study's numbers say.
|
|
- t0-idle above 10 mW: control is not negligible, and every per-job figure carries it.
|
|
|
|
WHAT THIS RUN CANNOT RESOLVE (said now, so a null is not read as a finding)
|
|
gibbs-recall, solve-assign and t0-idle are predicted at or below the protocol's floor (paired SE
|
|
~2-7 mW at 8-12 passes). A result consistent with 0 there means "below what one core on this
|
|
meter resolves", not "free". A second meter on the PL rail (or K replicated cores) is what would
|
|
resolve them.
|