{"id":"386cdc7c-56a9-4855-90b6-836889342db0","arxiv_id":"2501.10301","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"AraXL scales a RISC-V vector processor to 64 lanes and 64 Kibit vector registers by replacing all-to-all interconnects with pipelined hierarchical and ring links, reaching 146 GFLOPs and 40.1 GFLOPs/W in 22nm simulation.","lead":"Researchers at ETH Zurich present AraXL, a RISC-V vector processor design that scales to 64 parallel lanes with the maximum vector register length allowed by the RISC-V V specification. It matters because it shows how hierarchical, latency-tolerant interconnects can bypass the wiring bottleneck that kept wide vector processors at 8 to 16 lanes.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The claim of linear scaling is contradicted by the paper's own reduction-kernel results: fdotproduct and softmax reach only 6.1x and 7.3x on 64 lanes, so the load-bearing latency-tolerance assumption is not established for reduction-heavy HPC/ML workloads.","rationale":"The reader's weakest assumption concerned latency tolerance for irregular or short-vector workloads not covered by the six kernels. My concern is sharper and internal: even among the kernels tested, the reduction-heavy ones deviate from linear scaling at the exact long-vector regime used for the headline PPA claims. The paper acknowledges the 6.1x and 7.3x numbers but still concludes linear scaling for 'all benchmarks,' which is an overstatement. This does not invalidate the core architectural contribution, but it does mean the central performance claim should be qualified to FMA-bound, non-reduction kernels unless the 16384 B/lane result is actually demonstrated. The reader's conditional verdict already captures the need for such qualification, so I do not propose changing the verdict; I agree with the conditional posture and would only sharpen the requested revision to address the reduction-kernel evidence directly.","tokens_in":11572,"tokens_out":9957,"duration_ms":102730,"concrete_test":"Run fdotproduct and softmax at 512, 2048, and 16384 B/lane on 8-lane and 64-lane AraXL, normalizing to the 8-lane AraXL configuration rather than Ara2, and report the per-doubling speedup from 8 to 64 lanes. If the 64-lane vs 8-lane speedup at 16384 B/lane is below 7x, the ring-reduction latency remains material and the linear-scaling claim should be restricted to FMA-dominated kernels.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's headline scalability claim is internally undermined in Section IV-B. For the two reduction-heavy benchmarks, fdotproduct and softmax, Figure 6 shows only 6.1x and 7.3x speedup on 64 lanes relative to 8-lane Ara2, against the ideal 8x; the text nevertheless states 'linear performance scaling from 8 to 64 lanes' for all benchmarks. The explanation that the non-ideal inter-lane/inter-cluster reduction steps are configuration-dependent and amortized at 16384 B/lane is not backed by a figure or a reported measurement. Since reductions are central to softmax and dot-product workloads in the paper's target HPC/ML domain, the load-bearing assumption that long vectors hide the hierarchical interconnect latency is not established even in the paper's own data. The 146 GFLOPs and 40.1 GFLOPs/W headline numbers are computed on fmatmul, which avoids the reduction bottleneck and therefore does not support the general 'fast and efficient computation on long vectors' claim.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents AraXL, a RISC-V V vector processor architecture that scales to 64 vector lanes and a VLEN of 64 Kibit per vector register, which is the maximum permitted by the RVV 1.0 specification. The key microarchitectural contribution is a hierarchical, pipelined interconnect (REQI, GLSU, RINGI) that replaces the all-to-all links that limited Ara2's scalability. The authors evaluate AraXL with cycle-accurate simulations on six HPC/ML kernels and post-layout PPA for 16-, 32-, and 64-lane instances in 22nm, reporting linear area scaling, up to 146 GFLOPs and 40.1 GFLOPs/W on fmatmul, and a 3.8x area increase from 16 to 64 lanes.","tokens_in":11760,"tokens_out":4462,"duration_ms":42872,"significance":"If the claims hold, AraXL is a significant step in vector processor design: it demonstrates that a hierarchical interconnect can enable physical scalability to 64 lanes, it reaches the maximum VLEN allowed by the RISC-V V ISA, and it provides post-layout PPA evidence in a realistic 22nm technology. The design builds on the open-source Ara2, and the use of cycle-accurate simulation plus place-and-route gives the results a concrete, reproducible basis. The energy-efficiency and area-efficiency improvements over Ara2 and Vitruvius+ are valuable data points. However, the paper's universal linear-scaling claim is weakened by its own reduction-kernel measurements, and the latency-tolerance study covers only regular, dense kernels.","major_comments":[{"comment":"The statement that AraXL achieves 'linear performance scaling from 8 to 64 lanes' for all benchmarks is contradicted by the paper's own data: fdotproduct and softmax reach speedups of 6.1x and 7.3x on the 64-lane configuration relative to 8-lane Ara2, while ideal linear scaling would be 8x. The text attributes this to non-ideal inter-lane and inter-cluster log-tree reductions and cites a 7.6x speedup at 16384 B/lane for a strip-mined dot product, but that measurement is not shown in any figure or table. Because reductions are central to softmax and dot-product in the target HPC/ML workloads, the universal linear-scaling claim is not established. Please either report the 16384 B/lane experiment in Figure 6 or in a table, or explicitly scope the scaling claim to compute-bound kernels without inter-cluster reductions.","section":"Section IV-B, Figure 6"},{"comment":"The latency-tolerance evaluation covers only the six kernels listed in Table I, all of which have regular, unit-stride or slide-by-1 access patterns. The design decision to replace all-to-all interconnects with a pipelined hierarchical interconnect (8 additional cycles on the GLSU path, 2 on REQI, and 1 per ring hop) is justified by the assumption that long-vector applications hide this latency. The paper does not test gather/scatter, data-dependent control flow, or short-vector regimes where the pipeline cannot fill, so the claim that the architecture exhibits high latency tolerance in general is not yet supported. Please add a stress test with irregular memory access or clearly scope the latency-tolerance claim to regular dense kernels.","section":"Section IV-C, Figure 7"}],"minor_comments":[{"comment":"The legend lists '8L Ara2' twice and omits a distinct entry for the 16-lane AraXL lines; please correct the legend to match the plotted series.","section":"Figure 6 caption"},{"comment":"The header 'Scaling factor normalized to half the number of lanes' is confusing; it should be reworded to 'normalized to the 16-lane instance' to make the baseline explicit.","section":"Table II"},{"comment":"The text contains a formatting typo 'Q UESTASIM' that should read 'QuestaSim'.","section":"Section IV-A"},{"comment":"The headline 146 GFLOPs and 40.1 GFLOPs/W numbers are computed on fmatmul only; please state this explicitly in the abstract and conclusion so that readers do not infer a kernel-independent peak efficiency.","section":"Abstract and Section IV-D"},{"comment":"The phrase 'linear performance scaling' is used both for the fmatmul/fconv2d results and for the full set of benchmarks; please align the wording with the actual measured scaling factors of 6.1x and 7.3x for reduction-heavy kernels.","section":"Section IV-B"}],"recommendation":"major_revision","confidential_remarks":"The paper is a solid engineering contribution with valuable post-layout PPA data. The main issue is the overstatement of linear scaling for reduction-heavy workloads, which is directly contradicted by the paper's own Figure 6. I believe this can be fixed by adding the missing 16384 B/lane experiment or by scoping the claims, so I recommend major revision rather than rejection."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The real news here is the scale: 64 lanes and 64 Kibit VLEN, both records for a RISC-V V design, with a clean physical implementation story. The hierarchical interconnect replacing Ara2's all-to-all links is a legitimate engineering contribution—the pipelined GLSU and ring are described in enough detail to be reproduced, and the post-layout PPA shows good area scaling (3.8x area for 4x lanes) with only modest frequency degradation. The mask byte-encoding workaround is also sensible. Credit where due: this is a solid scaling demonstration, not a paper full of hand-waving.\n\nThe soft spots are real but not fatal. The paper claims \"linear performance scaling from 8 to 64 lanes\" for all benchmarks, yet its own Figure 6 shows fdotproduct at 6.1x and softmax at 7.3x against the ideal 8x. The explanation—that inter-cluster reduction latency is configuration-dependent and amortized at very long vectors—is plausible but not backed by a figure for the tested regime. That is an overclaim in the text, not a flaw in the architecture. The latency-tolerance study covers only six regular kernels; irregular or short-vector workloads could expose the added interconnect latency, so the general claim that long vectors hide it is only partially established. No RTL or scripts are released, and PPA comes from a single-corner, post-layout simulation without silicon. Those are minor for an architecture paper at this stage, but they should be stated as limitations.\n\nThe citation pattern is fine: Ara2 is the real published baseline, and the self-comparison is appropriate. No circularity, no invented entities. The free parameters are all real design choices, not fitted numbers.\n\nBottom line: this is a useful paper for anyone working on wide vector processors or long-vector accelerators. It deserves a serious referee, but the authors should be pushed to qualify the scaling claim to match their own reduction-kernel numbers and to say explicitly that the latency tolerance is demonstrated only for regular, long-vector workloads. I would engage with it.","headline":"A credible record-scale RISC-V vector processor with a genuinely new hierarchical interconnect, but the linear-scaling headline is too strong for its own reduction data.","tokens_in":12366,"tokens_out":1143,"would_cite":true,"duration_ms":13136,"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":"A 64-lane RISC-V V vector processor reaches the ISA's maximum 64-Kibit registers with near-linear area scaling.","keywords":["RISC-V vector extension","vector processor","long vectors","hierarchical interconnect","physical scalability","64-Kibit vector register","energy efficiency","HPC/ML workloads"],"falsifier":"Run the 64-lane AraXL on an irregular kernel, such as a gather/scatter or variable-slide workload, at the same 512 B/lane working set and compare FPU utilization with a 16-lane instance; if utilization drops by more than the single-digit percentages reported for regular kernels, or performance scaling falls below near-linear, the latency-tolerance premise fails.","tokens_in":11330,"feed_emoji":"⚡","tokens_out":7918,"duration_ms":70738,"temperature":0.7,"pith_summary":"The paper aims to show that a lane-based RISC-V V vector processor can be physically scaled to 64 double-precision lanes and to the ISA's maximum vector-register size of 64 Kibits per register, a regime no RISC-V design has reached. Its central wager is that long-vector HPC and machine-learning workloads tolerate added memory and interconnect latency, so a pipelined hierarchical interconnect can replace the wide all-to-all links that cap existing designs near 8 to 16 lanes. In 22-nm post-layout simulation the 64-lane configuration reaches 146 GFLOPs, 40.1 GFLOPs/W, and 3.8 times the area of the 16-lane version at 1.15 GHz. If the claim holds, vector processors can offer far longer registers and more lanes without the area and frequency penalties previously assumed inevitable.","feed_headline":"First 64-lane RISC-V vector core reaches 146 GFLOPs","feed_subtitle":"Hierarchical ring and load-store links trade latency for scale to reach the ISA's maximum 64-Kibit vector registers.","key_machinery":"The load-bearing mechanism is the hierarchical, pipelined interconnect that replaces the all-to-all links of the predecessor Ara2. A three-stage Global Load-Store Unit (GLSU) aligns and shuffles memory bytes to the correct clusters, the Request Interface (REQI) broadcasts vector instructions to all clusters and returns a single acknowledgement, and a Ring Interface (RINGI) carries 64-bit chunks between adjacent clusters for slides and log-tree reductions. Each interface accepts a parametric number of register cuts, trading 8 cycles on the GLSU path, 2 cycles on the REQI, and 1 cycle per ring hop for the ability to close timing at 64 lanes.","core_discovery":"AraXL is claimed to be the first RISC-V V vector processor to support 64 parallel lanes and the maximum V 1.0 vector length of 64 Kibits per register, with 8192 double-precision elements per vector. The architecture splits the machine into 4-lane clusters derived from the Ara2 design and connects them through three scalable interfaces: the REQI for synchronized instruction broadcast, the GLSU for multi-stage memory-to-VRF alignment and byte shuffling, and the RINGI for inter-cluster slide and reduction data movement. Because every interface is cut with a parametric number of registers, the critical timing paths that made Ara2's all-to-all units quadratic in complexity are broken; the added 8-cycle GLSU, 2-cycle REQI, and 1-cycle-per-hop ring latencies are meant to be hidden by long vectors. The claimed result is near-linear performance and area scaling from 8 to 64 lanes, with 99% FPU utilization on large matrix multiplication and better frequency and efficiency than the 16-lane Ara2 baseline.","pith_inferences":["This suggests the same latency-for-scalability trade could be applied to other wide data-parallel designs, but only for workloads whose vector lengths are long enough to hide the extra pipeline stages.","A direct extension would be to benchmark AraXL on irregular kernels such as gather/scatter, sparse matrix-vector products, or variable-length slides, which the paper does not evaluate and which would stress the latency-tolerance premise.","The reduction bottleneck visible in softmax and fdotproduct implies that a second interconnect or tree for cross-cluster reduction could close the remaining scaling gap, at some area cost not quantified in the paper."],"forward_implications":["At 64 lanes, AraXL sustains 146 GFLOPs with more than 99% FPU utilization on a sufficiently large matrix multiplication, at 40.1 GFLOPs/W and 1.15 GHz in 22nm.","Area scales almost perfectly with lane count: 32- and 64-lane instances are about 1.9 and 2.0 times the cell area of the 16-lane instance, with the three top-level interfaces contributing only about 3% of total area.","The added interconnect latency is mostly hidden in the long-vector regime, costing less than 2% FPU utilization for GLSU and ring cuts and up to 5% for the REQI at medium vector lengths.","Reduction-heavy kernels such as softmax and fdotproduct scale less than ideally (7.3x and 6.1x on 64 lanes) because inter-cluster reduction runs through the ring, but longer vectors amortize this overhead."],"supporting_citations":[{"why":"Supplies the 4-lane Ara2 cluster and the all-to-all VLSU, MASKU, and SLDU that AraXL reworks to remove the scalability bottleneck.","marker":"[13]"},{"why":"Provides Vitruvius+, the prior largest RISC-V long-vector design with 8 lanes and 16-Kibit VLEN, used as the state-of-the-art comparison.","marker":"[12]"},{"why":"Documents the 32-lane TSUBASA Aurora vector engine, the largest non-RISC-V comparison point for wide vector architectures.","marker":"[23]"},{"why":"Describes the A64FX CPU and its 2048-bit SVE registers, used to contrast Arm SVE's shorter vector length.","marker":"[10]"},{"why":"Supplies long-vector HPCG evaluation results used to justify the latency-tolerance and performance benefits of very long vectors.","marker":"[8]"},{"why":"Is the CVA6 scalar core that broadcasts instructions over the REQI and receives the acknowledgement in the AraXL system.","marker":"[25]"}],"fun_headline_variants":["64-lane RISC-V V: 146 GFLOPs, 40 GFLOPs/W","First RISC-V V to hit 64 lanes and 64-Kibit vectors","AraXL: ultra-wide RISC-V V scales to 64 lanes","RISC-V V reaches ISA max: 64 lanes, 64 Kibit per register","Long-vector RISC-V V: 64 lanes, 99% FPU utilization"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"AraXL's scalability rests on the assumption that long-vector HPC and ML workloads tolerate the extra latency of the pipelined GLSU, REQI, and ring, yet that tolerance is demonstrated only on six kernels with mostly regular, unit-stride access patterns.","fun_headline_variants_meta":{"raw":{"variants":["64-lane RISC-V V: 146 GFLOPs, 40 GFLOPs/W","First RISC-V V to hit 64 lanes and 64-Kibit vectors","AraXL: ultra-wide RISC-V V scales to 64 lanes","RISC-V V reaches ISA max: 64 lanes, 64 Kibit per register","Long-vector RISC-V V: 64 lanes, 99% FPU utilization"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000363,"raw_usage":{"total_tokens":2020,"prompt_tokens":1069,"completion_tokens":951,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":685,"completion_tokens_details":{"reasoning_tokens":836}},"tokens_in":685,"tokens_out":951,"duration_ms":8347,"temperature":1.0,"reasoning_tokens":836,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T19:15:12.430363+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the 64-lane AraXL on an irregular kernel, such as a gather/scatter or variable-slide workload, at the same 512 B/lane working set and compare FPU utilization with a 16-lane instance; if utilization drops by more than the single-digit percentages reported for regular kernels, or performance scaling falls below near-linear, the latency-tolerance premise fails.","supporting_citations":[{"cited_title":"Ara2: Exploring single- and multi-core vector process- ing with an efficient RVV 1.0 compliant open-source processor,","cited_arxiv_id":null,"evidence_quote":"Supplies the 4-lane Ara2 cluster and the all-to-all VLSU, MASKU, and SLDU that AraXL reworks to remove the scalability bottleneck."},{"cited_title":"Vitruvius+: An area-efficient RISC-V decoupled vector coprocessor for high performance computing applications,","cited_arxiv_id":null,"evidence_quote":"Provides Vitruvius+, the prior largest RISC-V long-vector design with 8 lanes and 16-Kibit VLEN, used as the state-of-the-art comparison."},{"cited_title":"NEC SX-Aurora TSUBASA architecture,","cited_arxiv_id":null,"evidence_quote":"Documents the 32-lane TSUBASA Aurora vector engine, the largest non-RISC-V comparison point for wide vector architectures."},{"cited_title":"Supercomputer Fugaku CPU A64FX realizing high performance, high-density packaging, and low power consumption,","cited_arxiv_id":null,"evidence_quote":"Describes the A64FX CPU and its 2048-bit SVE registers, used to contrast Arm SVE's shorter vector length."},{"cited_title":"HPCG on long-vector architectures: Evaluation and optimiza- tion on NEC SX-Aurora and RISC-V,","cited_arxiv_id":null,"evidence_quote":"Supplies long-vector HPCG evaluation results used to justify the latency-tolerance and performance benefits of very long vectors."},{"cited_title":"The cost of application-class processing: Energy and performance analysis of a Linux-ready 1.7-GHz 64-Bit RISC-V core in 22-nm FDSOI technology,","cited_arxiv_id":null,"evidence_quote":"Is the CVA6 scalar core that broadcasts instructions over the REQI and receives the acknowledgement in the AraXL system."}],"review_version":1}