AraXL: A Physically Scalable, Ultra-Wide RISC-V Vector Processor Design for Fast and Efficient Computation on Long Vectors

Luca Benini; Matteo Perotti; Navaneeth Kunhi Purayil; Tim Fischer

REVIEW 2 major objections 5 minor 2 cited by

AraXL: A Physically Scalable, Ultra-Wide RISC-V Vector Processor Design for Fast and Efficient Computation on Long Vectors

T0 review · 2 major / 5 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A 64-lane RISC-V V vector processor reaches the ISA's maximum 64-Kibit registers with near-linear area scaling.

desk verdict 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. read the letter →

arxiv 2501.10301 v1 pith:X722SUGF submitted 2025-01-17 cs.AR

Navaneeth Kunhi Purayil , Matteo Perotti , Tim Fischer , Luca Benini This is my paper · ORCID

classification cs.AR

keywords RISC-Vvectorextensionprocessorlongvectorshierarchicalinterconnectphysicalscalability64-KibitregisterenergyefficiencyHPC/MLworkloads

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

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.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the 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.

The 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.

The 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.

Bottom 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.

Referee Report

2 major / 5 minor

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.

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 (2)

[Section IV-B, Figure 6] 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 IV-C, Figure 7] 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.

minor comments (5)

[Figure 6 caption] 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.
[Table II] 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 IV-A] The text contains a formatting typo 'Q UESTASIM' that should read 'QuestaSim'.
[Abstract and Section IV-D] 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 IV-B] 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.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: AraXL's claims are supported by measured simulations and physical implementation, not by fitting or self-referential derivation.

full rationale

AraXL's central claims 鈥?64-lane scalability, 64 Kibit VLEN, 146 GFLOPs, 40.1 GFLOPs/W, and 3.8x area scaling 鈥?are presented as post-layout simulation and PPA measurements, not as derived consequences of an equation or fitted model. The architecture reuses Ara2 as a real, published, open-source baseline; citations to Ara2 and other prior work by overlapping authors are used for context and as a starting point, not as an unverified premise that forces AraXL's results. The latency-tolerance argument is evaluated empirically in Section IV-C with measured FPU-utilization drops. The performance-scaling data in Figure 6 indeed show sub-ideal speedups for reduction-heavy kernels (fdotproduct 6.1x, softmax 7.3x), but this is a correctness or robustness concern about the strength of the 'linear scaling' claim, not a circularity: the numbers are measured against an external baseline, not constructed from the claim. No equation in the paper is shown to equal its own input, no fitted parameter is renamed as a prediction, and no load-bearing uniqueness theorem is imported from the authors' prior work. The paper is self-contained with respect to its empirical evaluations, so the circularity score is 0.

Assumptions & free parameters 4 free parameters · 4 assumptions · 0 invented entities

AraXL is an engineering result, so the ledger records hand-chosen design parameters (interconnect pipeline depths, cluster size) and workload assumptions rather than fitted constants or speculation. No new physical entities are introduced; the new GLSU, RINGI, and REQI are ordinary hardware blocks whose behavior is described in the paper and could be independently tested.

free parameters (4)

GLSU register cuts = 4
Hand-chosen pipeline registers on the global load-store unit to close timing; adds 8 cycles of request-response latency (Section IV-C). This is a design parameter, not a fitted constant, but it shapes the claimed scalability.
REQI register cut = 1
One register cut on the request interface, adding 2 cycles to instruction acknowledgment; hand-chosen for timing.
RINGI register cut = 1
One register cut per ring hop, adding 1 cycle latency for slides and reductions; hand-chosen for timing.
Cluster size = 4 lanes
The 4-lane Ara2 configuration was chosen as the building block because it has the highest energy efficiency in prior work; all AraXL instances are multi-cluster versions of this block.

assumptions (4)

domain assumption Long-vector HPC/ML workloads tolerate the added interconnect and request latency (8+2+1 cycles) so pipeline registers can be inserted without meaningful performance loss.
This is the central design bet of Section III and is tested only on the six benchmarks in Section IV-C; if real workloads have shorter effective vectors, the scalability argument weakens.
domain assumption The six benchmark kernels and weak-scaling setup (Table I) are representative of target long-vector workloads.
The conclusion of linear scaling relies on this representativeness; strided, indexed, and variable-slide operations are not part of the scaling evaluation.
domain assumption The RISC-V V 1.0 ISA allows VLEN=65536 bits and the described memory-to-VRF byte mapping is compliant.
The claim of maximum vector register file size permitted by the ISA depends on this interpretation of the specification.
domain assumption The Ara2 4-lane cluster remains functionally correct and efficient when integrated into a multi-cluster system with modified interconnects.
AraXL inherits Ara2's internals without re-verifying them; the paper relies on Ara2 as a trusted building block.

how reviews work

0 comments

Cite this review

Pith. "Pith review of AraXL: A Physically Scalable, Ultra-Wide RISC-V Vector Processor Design for Fast and Efficient Computation on Long Vectors." pith.science (2026). https://pith.science/paper/X722SUGF

@misc{pith2026250110301,
  author       = {Pith},
  title        = {Pith review of: AraXL: A Physically Scalable, Ultra-Wide RISC-V Vector Processor Design for Fast and Efficient Computation on Long Vectors},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/X722SUGF}},
  note         = {Machine review of arXiv:2501.10301}
}

read the original abstract

The ever-growing scale of data parallelism in today's HPC and ML applications presents a big challenge for computing architectures' energy efficiency and performance. Vector processors address the scale-up challenge by decoupling Vector Register File (VRF) and datapath widths, allowing the VRF to host long vectors and increase register-stored data reuse while reducing the relative cost of instruction fetch and decode. However, even the largest vector processor designs today struggle to scale to more than 8 vector lanes with double-precision Floating Point Units (FPUs) and 256 64-bit elements per vector register. This limitation is induced by difficulties in the physical implementation, which becomes wire-dominated and inefficient. In this work, we present AraXL, a modular and scalable 64-bit RISC-V V vector architecture targeting long-vector applications for HPC and ML. AraXL addresses the physical scalability challenges of state-of-the-art vector processors with a distributed and hierarchical interconnect, supporting up to 64 parallel vector lanes and reaching the maximum Vector Register File size of 64 Kibit/vreg permitted by the RISC-V V 1.0 ISA specification. Implemented in a 22-nm technology node, our 64-lane AraXL achieves a performance peak of 146 GFLOPs on computation-intensive HPC/ML kernels (>99% FPU utilization) and energy efficiency of 40.1 GFLOPs/W (1.15 GHz, TT, 0.8V), with only 3.8x the area of a 16-lane instance.

Figures

Figures reproduced from arXiv: 2501.10301 by the authors.

**Figure 2.** Schematic of the cluster-based AraXL architecture and its interfaces. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

**Figure 3.** Schematic of the Global Load-Store Unit (GLSU). [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗

Figures from the paper (4 more)

**Figure 4.** Figure 4: Schematic of the Ring Interface (RINGI). [PITH_FULL_IMAGE:figures/full_fig_p004_4.png]

**Figure 7.** Figure 7: Performance impact of additional latency on the (a) Memory, (b) [PITH_FULL_IMAGE:figures/full_fig_p005_7.png]

**Figure 8.** Figure 8: 16-lane AraXL floorplan. Focus on the modified 4-lane Ara2 used as [PITH_FULL_IMAGE:figures/full_fig_p006_8.png]

**Figure 9.** Figure 9: Area breakdown of 16-lane AraXL and Ara2. For a fair comparison, [PITH_FULL_IMAGE:figures/full_fig_p006_9.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

Efficient Implementation of RISC-V Vector Permutation Instructions
cs.AR 2025-05 conditional novelty 6.0 of 10

A unified crossbar-based microarchitecture executes all RISC-V vector permutation instructions with fixed single-cycle latency at only 1.5% area overhead in a 7 nm processor.
Physical Design Exploration of a Wire-Friendly Domain-Specific Processor for Angstrom-Era Nodes
cs.AR 2025-08 unverdicted novelty 4.0 of 10

This design study claims its machine-learning processor cuts normalized wire length by over 2x and raises density by over 3x versus the VWR2A baseline on the IMEC A10 node.

Reference graph

Works this paper leans on

26 extracted references · 25 canonical work pages · cited by 2 Pith papers

[1]

Scaling the power wall: A path to exascale,

O. Villa et al. , “Scaling the power wall: A path to exascale,” in SC ’14: Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis . IEEE, 2014

work page 2014
[2]

The environmental cost of high performance computing system simulation,

E. Masciari and E. V . Napolitano, “The environmental cost of high performance computing system simulation,” in 32nd Euromicro In- ternational Conference on Parallel, Distributed and Network-Based Processing (PDP). IEEE, 2024

work page 2024
[3]

The CRAY-1 computer system,

R. Russell, “The CRAY-1 computer system,” Communications of ACM , vol. 21, no. 1, pp. 63–72, Jan. 1978

work page 1978
[4]

A RISC-V Simulator and Benchmark Suite for Designing and Evaluating Vector Architectures,

C. Ram ´ırez et al. , “A RISC-V Simulator and Benchmark Suite for Designing and Evaluating Vector Architectures,” ACM Transactions on Architecture and Code Optimization, vol. 17, no. 4, pp. 38:1–38:30, Nov. 2020

work page 2020
[5]

Challenges and oppor- tunities in the co-design of convolutions and RISC-V vector processors,

S. R. Gupta, N. Papadopoulou, and M. Peric `as, “Challenges and oppor- tunities in the co-design of convolutions and RISC-V vector processors,” in Proceedings of the SC ’23 Workshops of The International Conference on High Performance Computing, Network, Storage, and Analysis . ACM, 2023

work page 2023
[6]

Short Reasons for Long Vectors in HPC CPUs: A Study Based on RISC-V,

P. Vizcaino et al. , “Short Reasons for Long Vectors in HPC CPUs: A Study Based on RISC-V,” in Proceedings of the SC ’23 Workshops of The International Conference on High Performance Computing, Network, Storage, and Analysis . ACM, 2023

work page 2023
[7]

Efficiently running SpMV on long vector architectures,

C. G ´omez, F. Mantovani, E. Focht, and M. Casas, “Efficiently running SpMV on long vector architectures,” in Proceedings of the 26th ACM SIGPLAN Symposium on Principles and Practice of Parallel Program- ming. ACM, 2021

work page 2021
[8]

HPCG on long-vector architectures: Evaluation and optimiza- tion on NEC SX-Aurora and RISC-V,

——, “HPCG on long-vector architectures: Evaluation and optimiza- tion on NEC SX-Aurora and RISC-V,” Future Generation Computer Systems, vol. 143, pp. 152–162, Jun. 2023

work page 2023

Show all 26 references

[9]

AWS Graviton - Getting started,

A. W. Services, “AWS Graviton - Getting started,” accessed April 28, 2024. [Online]. Available: https://github.com/aws/ aws-graviton-getting-started

2024
[10]

Supercomputer Fugaku CPU A64FX realizing high performance, high-density packaging, and low power consumption,

R. Okazaki et al. , “Supercomputer Fugaku CPU A64FX realizing high performance, high-density packaging, and low power consumption,” Fujitsu Technical Review , 2020. [Online]. Available: https://www.fujitsu.com/global/documents/about/resources/ publications/technicalreview/2020...

2020
[11]

Vicuna: A timing-predictable RISC-V vector coprocessor for scalable parallel computation,

M. Platzer and P. Puschner, “Vicuna: A timing-predictable RISC-V vector coprocessor for scalable parallel computation,” in 33rd Euromicro Conference on Real-Time Systems (ECRTS 2021) . Schloss Dagstuhl, 2021

2021
[12]

Vitruvius+: An area-efficient RISC-V decoupled vector coprocessor for high performance computing applications,

F. Minervini et al. , “Vitruvius+: An area-efficient RISC-V decoupled vector coprocessor for high performance computing applications,” ACM Trans. Archit. Code Optim. , vol. 20, no. 2, pp. 1–25, 2023

2023
[13]

Ara2: Exploring single- and multi-core vector process- ing with an efficient RVV 1.0 compliant open-source processor,

M. Perotti et al., “Ara2: Exploring single- and multi-core vector process- ing with an efficient RVV 1.0 compliant open-source processor,” IEEE Transactions on Computers, vol. 73, no. 7, pp. 1822–1836, 2024

2024
[14]

[Online]

SiFive Intelligence X280 , SiFive Corp., 2022, accessed on January 13, 2025. [Online]. Available: https://www.sifive.com/document-file/ x280-datasheet

2022
[15]

P870 high-performance RISC-V processor,

SiFive, “P870 high-performance RISC-V processor,” in Hot Chips: A Symposium on High-Perf. Chips . IEEE, 2023

2023
[16]

AndesCore™ NX27V Processor,

“AndesCore™ NX27V Processor,” Andes Technology, accessed March 31, 2024. [Online]. Available: http://www.andestech.com/en/ products-solutions/andescore-processors/riscv-nx27v

2024
[17]

SiFive announces differentiated solutions for gen- erative AI and ML applications leading RISC-V into a new era of high-performance innovation,

SiFive, “SiFive announces differentiated solutions for gen- erative AI and ML applications leading RISC-V into a new era of high-performance innovation,” accessed March 31, 2024. [Online]. Available: https://www.sifive.com/press/ sifive-announces-differentiated-solutions-for-g...

2024
[18]

[Online]

SiFive Performance P270 , SiFive Corp., 2022, accessed January 10, 2025. [Online]. Available: https://www.sifive.com/document-file/ p270-and-p270-mc-data-sheet

2022
[19]

Spatz: Clustering compact RISC-V-based vector units to maximize computing efficiency,

M. Perotti, S. Riedel, M. Cavalcante, and L. Benini, “Spatz: Clustering compact RISC-V-based vector units to maximize computing efficiency,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 2025, Early Access, DOI: 10.1109/TCAD.2025.3528349

2025
[20]

Arrow: A RISC-V vector accelerator for machine learning inference,

I. A. Assir, M. E. Iskandarani, H. R. A. Sandid, and M. A. R. Saghir, “Arrow: A RISC-V vector accelerator for machine learning inference,” in Fifth Workshop on Computer Architecture Research with RISC-V (CARRV 2021) , 2021. [Online]. Available: https: //carrv.github.io/2021/pa...

2021
[21]

AndesCore™ AX45MPV,

“AndesCore™ AX45MPV,” Andes Technology, accessed March 31, 2024. [Online]. Available: https://www.andestech.com/en/ products-solutions/andescore-processors/riscv-ax45mpv

2024
[22]

Semidynamics vector unit,

“Semidynamics vector unit,” Semidynamics., accessed March 31,
[23]

NEC SX-Aurora TSUBASA architecture,

“NEC SX-Aurora TSUBASA architecture,” NEC Corporation, accessed March 31, 2024. [Online]. Available: https://www.nec.com/en/global/ solutions/hpc/sx/architecture.html

2024
[24]

The Llama 3 herd of models,

“The Llama 3 herd of models,” Meta Platforms Inc., accessed January 10, 2025. [Online]. Available: https://ai.meta.com/research/publications/ the-llama-3-herd-of-models/

2025
[25]

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,

F. Zaruba and L. Benini, “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,” IEEE Transactions on Very Large Scale Integration (VLSI) Systems, vol. 27, no. 11, pp. 2629–2640, 2019

2019
[2024]

Available: https://semidynamics.com/en/technology/ vector-unit

[Online]. Available: https://semidynamics.com/en/technology/ vector-unit

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.

[1] [1]

Scaling the power wall: A path to exascale,

O. Villa et al. , “Scaling the power wall: A path to exascale,” in SC ’14: Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis . IEEE, 2014

work page 2014

[2] [2]

The environmental cost of high performance computing system simulation,

E. Masciari and E. V . Napolitano, “The environmental cost of high performance computing system simulation,” in 32nd Euromicro In- ternational Conference on Parallel, Distributed and Network-Based Processing (PDP). IEEE, 2024

work page 2024

[3] [3]

The CRAY-1 computer system,

R. Russell, “The CRAY-1 computer system,” Communications of ACM , vol. 21, no. 1, pp. 63–72, Jan. 1978

work page 1978

[4] [4]

A RISC-V Simulator and Benchmark Suite for Designing and Evaluating Vector Architectures,

C. Ram ´ırez et al. , “A RISC-V Simulator and Benchmark Suite for Designing and Evaluating Vector Architectures,” ACM Transactions on Architecture and Code Optimization, vol. 17, no. 4, pp. 38:1–38:30, Nov. 2020

work page 2020

[5] [5]

Challenges and oppor- tunities in the co-design of convolutions and RISC-V vector processors,

S. R. Gupta, N. Papadopoulou, and M. Peric `as, “Challenges and oppor- tunities in the co-design of convolutions and RISC-V vector processors,” in Proceedings of the SC ’23 Workshops of The International Conference on High Performance Computing, Network, Storage, and Analysis . ACM, 2023

work page 2023

[6] [6]

Short Reasons for Long Vectors in HPC CPUs: A Study Based on RISC-V,

P. Vizcaino et al. , “Short Reasons for Long Vectors in HPC CPUs: A Study Based on RISC-V,” in Proceedings of the SC ’23 Workshops of The International Conference on High Performance Computing, Network, Storage, and Analysis . ACM, 2023

work page 2023

[7] [7]

Efficiently running SpMV on long vector architectures,

C. G ´omez, F. Mantovani, E. Focht, and M. Casas, “Efficiently running SpMV on long vector architectures,” in Proceedings of the 26th ACM SIGPLAN Symposium on Principles and Practice of Parallel Program- ming. ACM, 2021

work page 2021

[8] [8]

HPCG on long-vector architectures: Evaluation and optimiza- tion on NEC SX-Aurora and RISC-V,

——, “HPCG on long-vector architectures: Evaluation and optimiza- tion on NEC SX-Aurora and RISC-V,” Future Generation Computer Systems, vol. 143, pp. 152–162, Jun. 2023

work page 2023