{"id":"ece83418-71bd-43d1-83b9-42603c52258f","arxiv_id":"2607.21130","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"Float16 full training on a single RISC-V core reaches near-float32 accuracy on tested MLPs with ~50% memory savings, plus a +1.15% LUT cost for scalar Zfh support.","lead":"This paper combines an open-source embedded AI framework with float16 kernels so a neural network can be fully trained on a single RISC-V core using about half the memory of float32. It also reports a low FPGA area cost for adding scalar float16 to a RISC-V core, while the vector-float16 part remains at the architecture stage.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"On-device claim rests on an unvalidated simulator for FP16 numerics; Zvfh speedup discussion is dated and possibly overstated in the conclusion.","rationale":"The paper's main technical result is an integration with clear contributions: FP16 on-device training on a RISC-V single-core with ~50% memory reduction, layer freezing, and a Zfh FPGA area study. The reader's identity is CONDITIONAL with moderate confidence. My stress test agrees with the reader's weakest assumption: validation on a simulator rather than the actual NaxRiscv target is the key gap. However, I note that this is an external-validation issue—the paper does not claim measured performance on the VPU, and the conclusion might overstate the Zvfh contribution since the VPU is design-only and no timing results are given. Still, this does not change the verdict because the numerical/memory claims are well supported and the hardware cost claims are explicitly labeled as future work. The paper has concrete limitations that it discloses; the concern is peripheral to the core integration. I would not move the verdict.","tokens_in":6311,"tokens_out":1291,"duration_ms":11853,"concrete_test":"Run the same MNIST/FashionMNIST training (Table 2, §2.2) on a NaxRiscv FPGA implementation with Zfh enabled (or an FPGA-emulated Zvfh once implemented), using the same code and hyperparameters; compare final accuracy and loss curves against the simulator numbers. If accuracy differs by more than 0.3 absolute percentage points or memory accounting differs, the on-device claim needs qualification.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The conclusion states \"full float16 ODT is possible on resource-constrained RISC-V single-core... requiring about 50% less memory than float32.\" The central claim splits into numerical feasibility (FP16 training converges with ~50% memory saving) and the \"on-device RISC-V\" delivery. The numerical part is supported: AIfES FP16 kernels ran on RISC-V ISA simulator and match FP32 accuracy on the reported benchmarks. However, the \"on-device\" part is only as credible as the simulator's FP16 behavior and the unbuilt Zvfh vector unit. A RISC-V ISA simulator is not NaxRiscv real silicon/FPGA; it does not verify microarchitectural effects (pipeline, caches, OoO, FPU edge cases). If the real NaxRiscv Zfh FPU has subtle non-IEEE NaN-boxing behavior, or if the simulator's Zvfh kernel path does not match actual Zvfh timing/functional behavior, the conclusion overstates. The Zvfh hardware is design-only (Fig. 4, §3.3) with no timing or area results, so \"Zvfh\" in Table 1 and the conclusion is premature. This is an external-validation gap, not an internal inconsistency, but it is the load-bearing weak point.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents a hardware–software co-design flow for float16 on-device training (ODT) on RISC-V single-core processors. The software contribution extends the open-source AIfES framework with RISC-V Zfh/Zvfh float16 kernels, a converter from PyTorch/TensorFlow models, and layer-freezing support for transfer learning. Training experiments on an MLP (512-256-128-64-10) on MNIST and FashionMNIST, run on a RISC-V ISA simulator, show F16 accuracy within about 0.7 percentage points of F32, and memory measurements report an approximately 50% reduction in model and work memory when using float16. The hardware contribution is an implementation of the scalar Zfh extension in the NaxRiscv out-of-order FPGA softcore, with a reported +1.15% LUT6 and +0.05% FF area overhead at 175 MHz, plus a design discussion of a Zvfh vector processing unit with four lanes and VLEN=64. The conclusion claims that full float16 ODT is possible on resource-constrained RISC-V single-cores with Zfh and/or Zvfh, with about 50% memory savings and minimal accuracy loss.","tokens_in":6603,"tokens_out":4515,"duration_ms":78025,"significance":"If the claims hold, this is a useful practical contribution: it would make full float16 training, not just inference or quantized fine-tuning, accessible on small RISC-V cores, with a solid arithmetic memory reduction and a measured low area cost for Zfh. The open-source release of the framework and the clean synthesis measurement for Zfh are strengths. The paper honestly states in the final paragraph that training was validated on an ISA simulator and that Zvfh performance evaluation is future work; however, the abstract and conclusion do not carry this caveat, and the central 'on-device' claim is therefore stronger than the evidence. The accuracy comparison is based on four single runs without seeds or error bars, so the 'minimal degradation' part of the claim is not yet statistically demonstrated. The Zvfh part is an architecture proposal, not an implemented and measured design. These are external-validation gaps rather than internal inconsistencies, and they are fixable, but they currently prevent the strongest form of the conclusion.","major_comments":[{"comment":"The claim of 'minimal model performance degradation' rests on four single training runs with no seeds, no error bars, and no repetition. The reported F16-vs-F32 differences are at most 0.68 percentage points (FashionMNIST SGD) and can readily be within run-to-run variation for MLPs at this scale. Please provide mean±standard deviation over at least 5 seeds (or otherwise quantify variance) and report the same hyperparameters for all datasets. Without this, the accuracy comparison is not load-bearing evidence for the conclusion.","section":"§2.2, Table 2"},{"comment":"All training experiments are performed on a RISC-V ISA simulator, not on the NaxRiscv FPGA target or any real Zfh/Zvfh core. The conclusion 'full float16 ODT is possible on resource-constrained RISC-V single-core' therefore assumes that the simulator faithfully reproduces Zfh/Zvfh functional behavior and, where performance is implied, timing. The paper's own final paragraph acknowledges this ('validating the ODT pipeline through the RISC-V ISA Simulator'), but the abstract and conclusion do not. Please either validate at least the scalar Zfh path on the implemented NaxRiscv (e.g., on FPGA) and report measured runtime, or explicitly qualify the on-device claim as 'functionally validated on an ISA simulator; hardware validation pending.'","section":"§2.2, Conclusion"},{"comment":"The Zvfh support is at the design-discussion stage: no RTL implementation, synthesis, area, timing, or measured speedup is reported. The 'raw 4× speed-up over scalar execution' is a theoretical peak based on four lanes and VLEN=64. Consequently, the conclusion's phrase 'supporting standard extensions (i.e. Zfh and/or Zvfh)' overreaches for Zvfh, and the inclusion of Zvfh in the central claim is premature. The memory reduction and Zfh area results are unaffected, but Section 3.3 should be clearly labeled as an architecture proposal and the conclusion should state that Zvfh results are projected, not measured.","section":"§3.3, Fig. 4–5, Conclusion"}],"minor_comments":[{"comment":"Typo: 'Multipliy-and-Accumulate' should be 'Multiply-and-Accumulate'.","section":"Introduction"},{"comment":"Typo: 'seemlessly' should be 'seamlessly'.","section":"§3.1"},{"comment":"Fig. 2 caption says 'our RISC-V Zvfh optimized kernels', but the text only says experiments were run on a RISC-V ISA simulator. Please specify which simulator was used, whether Zvfh vector instructions were functionally simulated, and the NMSIS-DSP version, so that readers can reproduce the experiments.","section":"§2.2, Fig. 2"},{"comment":"The table lists dataset, learning rate, and optimizer but not the number of epochs, batch size, or dataset split for FashionMNIST. The MNIST experiments use 20 epochs and batch size 128; please state whether the same settings were used for all rows.","section":"Table 2"},{"comment":"The notation 'Frozen layer id 1-2' is not defined; clarify that it means the first two layers are frozen. Also, the caption says the 'Gradients' column includes gradients, optimizer, and activation memory; please make explicit how activation memory scales with batch size for the reported numbers.","section":"Table 3"},{"comment":"The phrase 'in a ad-hoc fashion' should be 'in an ad hoc manner'.","section":"§3.3"}],"recommendation":"major_revision","confidential_remarks":"The paper is accepted at a conference (IEEE PRIME 2026), and the work is useful for the embedded/edge AI community. The main concern is scope: the abstract and conclusion claim 'on-device' and 'Zvfh' support, while the evidence is simulator-based for training and design-only for Zvfh. This is fixable by rephrasing claims and adding either a small FPGA validation or a clearly separated 'projected' section. I do not see a fundamental flaw in the memory arithmetic or the Zfh area measurement."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Read it. The core result is a working open-source integration: AIfES extended with Zfh/Zvfh kernels, plus a measured Zfh implementation in NaxRiscv. The memory reduction is arithmetic — float16 halves model and gradient storage — and the Zfh area numbers (+1.15% LUT, +0.05% FF, no frequency drop) are clean synthesis results. That part deserves credit. The comparison against float32 on four dataset/optimizer combos is also good, not just a single demo.\n\nThe soft spots are about the gap between what they demonstrate and what the conclusion claims. Training is done on a RISC-V ISA simulator, not on the NaxRiscv core or real silicon. That doesn't invalidate the numerical feasibility — FP16 training converges within a point of FP32 — but it does mean 'on-device' is an extrapolation, especially because a simulator doesn't model microarchitectural FPU behavior or NaN-boxing edge cases. The accuracy results are single runs with no seeds or error bars; the differences (97.29 vs 96.88, etc.) are within run-to-run noise, so 'minimal degradation' is weaker than it looks. And Zvfh is design-only: no timing, no area, no measured speedup. The paper says as much in the future work, but the abstract and conclusion still put Zvfh alongside Zfh as if both are demonstrated. The vrgather micro-op discussion is thoughtful, but it's an architecture proposal, not a result.\n\nOne pushback: the reader's weakest assumption about simulator fidelity is real, but it's not load-bearing for the central claim. The Zfh area measurement and the memory arithmetic are the solid contributions; the training results are supporting evidence, not the main proof. The paper would be stronger if they ran Zfh training on the actual FPGA softcore and repeated benchmarks a few times.\n\nWho is this for? Embedded ML engineers wanting fine-tuning on single-core RISC-V, and people designing cheap FP16-capable cores. It's an incremental but useful data point. Serious referee: yes — a real implementation with reproducible numbers. Ask for seeds/repeats, run on real hardware, and temper the Zvfh language. I'd bring it to a reading group as an example of honest co-design reporting, despite the overstated edges.","headline":"Useful incremental result: float16 on-device training on single-core RISC-V works in simulation and Zfh area cost is cleanly measured; the Zvfh and 'on-device' claims outrun the evidence.","tokens_in":7095,"tokens_out":2657,"would_cite":true,"duration_ms":21867,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Full float16 on-device training of small neural networks is achievable on a resource-constrained RISC-V single-core using the standard Zfh and Zvfh extensions, cutting memory use by about half versus float32 with minimal accuracy loss.","keywords":["on-device training","float16","RISC-V","Zfh","Zvfh","AIfES","FPGA","memory footprint"],"falsifier":"Train the same 5-layer MLP on MNIST in float16 on a physical Zfh-enabled RISC-V core (or the implemented NaxRiscv FPGA target) and compare validation accuracy, memory footprint, and runtime with the simulator results; divergence in accuracy beyond the reported roughly one point, memory above about 50% savings, or significantly different speed would falsify the central claim. For the Zvfh part, implement the four-lane VLEN=64 VPU and check that the float16 vector kernels produce correct results and the predicted 4x raw speed-up.","tokens_in":6228,"feed_emoji":"🧠","tokens_out":7509,"duration_ms":66513,"temperature":0.7,"pith_summary":"The paper tries to establish that complete on-device training of deep neural networks—not just inference or fine-tuning—can run on a resource-constrained RISC-V single-core when all training state is kept in float16. It does this by extending the AIfES DNN framework with hand-optimized kernels for the standard RISC-V extensions Zfh (scalar float16) and Zvfh (vector float16), reporting about 50% lower memory use than float32 and validation accuracies within roughly one point on MNIST, FashionMNIST, and an EMNIST fine-tuning task. The paper also quantifies the hardware cost: enabling Zfh in the NaxRiscv FPGA core costs about +1.15% LUTs and +0.05% flip-flops at 175 MHz, and it sketches a four-lane vector unit that would implement Zvfh. A sympathetic reader would care because this suggests standard RISC-V extensions alone could make full training practical on tiny edge devices that currently only support inference.","feed_headline":"Float16 training on a RISC-V single core halves memory use","feed_subtitle":"Complete DNN training, not just inference, runs in half precision on standard Zfh/Zvfh extensions with little accuracy loss.","key_machinery":"The load-bearing mechanism is the pairing of the standard RISC-V Zfh/Zvfh extensions with a modular DNN training framework that can swap in hand-vectorized float16 kernels. Zfh and Zvfh are the RISC-V standard extensions for scalar and vector half-precision floating-point arithmetic; they matter because they let all training state live in float16 without custom accelerators or non-standard instruction sets. Zfh's implementation trick is nan-boxing: narrow float16 values are padded with ones and carried through the 64-bit FPU datapath, which is why adding support to the NaxRiscv FPU costs little. Zvfh's proposed vector unit uses four 64-bit lanes fed by crossbars, a vector register file merge","core_discovery":"On its own terms, the paper's central claim is that full float16 on-device training is possible on resource-constrained RISC-V single-core processors supporting the standard Zfh and/or Zvfh extensions, while requiring about 50% less memory than float32 training. The evidence consists of an extended AIfES framework with float16 math primitives, a model converter that can freeze layers for transfer learning, and training experiments run on a RISC-V ISA simulator: a 5-layer MLP trained from scratch on MNIST and FashionMNIST reaches validation accuracies within about one point of float32 (e.g., 97.29% vs 96.88% on MNIST/SGD), and fine-tuning a pretrained MLP on EMNIST shows a flat 50% reduction","pith_inferences":["The paper leaves implicit that the same framework should port to any Zvfh-capable RISC-V core, not just NaxRiscv, because Zvfh is a standard extension; that portability is testable once real Zvfh silicon exists.","A logical next experiment is to measure actual training energy and throughput on the FPGA target; if the simulator's cycle counts are close to silicon, float16 ODT could become viable for battery-powered sensors.","Because Adam stores two optimizer states per parameter, the 50% memory reduction is much smaller when Adam is used; with SGD and frozen early layers, working memory approaches the model size, making optimizer choice—not precision—the main memory lever.","The vrgather handling points to a boundary for the design: gather-like vector instructions need special treatment when register groups are split into micro-ops, so the proposed Zvfh support is best seen as a deliberate architectural approach rather than a proof that every RVV instruction maps cleanly onto lanes."],"forward_implications":["A single-core RISC-V MCU with Zfh support can run end-to-end float16 training, cutting parameter memory to about half of float32 while keeping validation accuracy within about a point.","Because Zfh costs only about 1.15% extra LUTs and 0.05% extra flip-flops with no clock drop on the NaxRiscv FPGA core, adding half-precision training capability to existing RISC-V designs is cheap.","A Zvfh vector unit with four 64-bit lanes would give a raw 4x SIMD speed-up for float16 kernels while keeping standard vector code portable across RISC-V implementations.","Layer freezing in the converter enables on-device fine-tuning and transfer learning, with additional working-memory savings when only the last layer is trained.","The approach supports batch sizes greater than 1 in full float16 training, unlike some prior RISC-V training frameworks that are limited to batch size 1."],"fun_headline_variants":["Float16 training on RISC-V single core halves memory","50% memory cut with float16 DNN training on RISC-V","On-device float16 training on RISC-V saves half memory","RISC-V core: full float16 training, half memory footprint","Single-core RISC-V: float16 training cuts memory by half"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The weakest load-bearing premise is that the RISC-V ISA simulator used for all training results (Section 2.2) faithfully reproduces the numerical behavior and performance of the real NaxRiscv core, and, for the Zvfh part, that the vector unit described in Section 3.3 works as designed; the authors themselves state that measuring on the FPGA target is future work.","fun_headline_variants_meta":{"raw":{"variants":["Float16 training on RISC-V single core halves memory","50% memory cut with float16 DNN training on RISC-V","On-device float16 training on RISC-V saves half memory","RISC-V core: full float16 training, half memory footprint","Single-core RISC-V: float16 training cuts memory by half"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000153,"raw_usage":{"total_tokens":1038,"prompt_tokens":731,"completion_tokens":307,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":475,"completion_tokens_details":{"reasoning_tokens":217}},"tokens_in":475,"tokens_out":307,"duration_ms":3554,"temperature":1.0,"reasoning_tokens":217,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-01T08:21:10.340661+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Train the same 5-layer MLP on MNIST in float16 on a physical Zfh-enabled RISC-V core (or the implemented NaxRiscv FPGA target) and compare validation accuracy, memory footprint, and runtime with the simulator results; divergence in accuracy beyond the reported roughly one point, memory above about 50% savings, or significantly different speed would falsify the central claim. For the Zvfh part, implement the four-lane VLEN=64 VPU and check that the float16 vector kernels produce correct results and the predicted 4x raw speed-up.","supporting_citations":[],"review_version":1}