Pith. sign in

REVIEW 2 major objections 4 minor 3 cited by

Instruction Scheduling in the Saturn Vector Unit

T0 review · 2 major / 4 minor · reviewed 2026-08-12 · deepseek-v4-flash

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

Pith's one-line read Saturn, a complete short-vector RVV microarchitecture, is claimed to match or beat long-vector designs using a low-cost scheduling mechanism.

desk verdict A real short-vector RVV unit with a clever element-group scoreboard chaining mechanism; the comparative edge over Spatz/Hwacha is not established because those baselines are self-modeled, and an internal inconsistency about Spatz's memory latency weakens the claim further. read the letter →

arxiv 2412.00997 v1 pith:OL4BGP2B submitted 2024-12-01 cs.AR

Jerry Zhao , Daniel Grubb , Miles Rusch , Tianrui Wei , Kevin Anderson , Borivoje Nikolic , Krste Asanovic This is my paper · ORCID
classification cs.AR
keywords Short-vectormicroarchitectureRISC-VvectorextensionInstructionschedulingChainingScoreboardingDecoupledaccess/executeOut-of-orderexecutionregisterfile
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 tries to establish that a short-vector implementation of a modern scalable vector ISA does not have to sacrifice performance to stay compact. It presents Saturn, an RTL implementation of the full RISC-V vector extension 1.0, whose instruction sequencing uses fine-granularity chaining, limited out-of-order issue, and run-ahead memory accesses without register renaming or deep issue queues. The authors argue that this combination keeps SIMD datapaths busy even with short application vectors, where long-vector units waste area and power. If true, it would mean mobile and embedded processors could adopt a portable, future-proof vector ISA instead of proprietary packed-SIMD extensions.

What carries the argument

The load-bearing mechanism is an augmented scoreboarding scheme that tracks pending-read and pending-write bit-vectors (PRSb/PWSb) at element-group granularity, where an element-group is a DLEN-wide segment of a vector register. Each sequencer in the vector backend maintains precise scoreboards for the instruction currently being sequenced, while instructions still in the issue queues contribute only coarse operand-specifier information, avoiding expensive per-element state. Sequencers crack vector instructions into single-cycle micro-ops behind the issue queues and validate each micro-op against older instructions' scoreboards, enabling cycle-granularity chaining across RAW, WAR, and WAW hazards. This mechanism, combined with a decoupled access/execute load-store unit and separate per-path sequencers, lets Saturn overlap memory latency, reorder work across load/store/arithmetic paths, and run ahead on memory addresses with minimal hardware overhead.

What would settle it

Run the same benchmark suite on the original Spatz RTL and an unmodified Hwacha implementation with matching datapath width, and compare utilization and physical efficiency; if either matches or exceeds SV-Full's near-peak utilization or SGFLOPS/W numbers, the paper's central comparison claim fails.

Watch

Extended reading notes

Core claim

The central claim is that Saturn, a complete RVV 1.0-compliant short-vector microarchitecture, achieves comparable or superior power, performance, and area characteristics to state-of-the-art long-vector and short-vector implementations by relying on a distributed, explicit-chaining instruction scheduling mechanism rather than on long architectural vector lengths, high instruction fetch throughput, general out-of-order execution, or register renaming. In evaluation, the SV-Full configuration with VLEN=512, DLEN=256 sustains above 90% functional-unit utilization across a range of kernels, outperforms the Ara long-vector baseline, and shows higher power efficiency (121 SGFLOPS/W) than Ara, Hwacha, and Vitruvius+. The paper also argues that short-vector designs are inherently better suited to domains with short application vector lengths, such as mobile and DSP workloads.

Load-bearing premise

The comparisons against Spatz and Hwacha assume that Saturn variants with features disabled or modified faithfully reproduce those microarchitectures; if these models misrepresent the real designs' scheduling behavior, the claimed superiority over state-of-the-art short-vector implementations is not established.

Editorial extensions

If this is right

  • Short-vector RVV implementations can sustain near-peak SIMD utilization across diverse kernels when instruction scheduling combines decoupled memory access with dynamic sequencing.
  • RVV register grouping lets a short-vector machine execute long application vectors without a large register file, matching long-vector performance with lower area and power.
  • A native chime length (VLEN:DLEN) of 2:1 is a practical design point that avoids the high instruction-throughput pressure of a 1:1 ratio while keeping register-file area low.
  • Issue queue depths of 2 to 4 entries capture most of the load-balancing benefit, so the scheduling hardware remains small.
  • The decoupled load-store unit and issue queues can tolerate up to 128 cycles of memory latency in a VLEN=512, DLEN=256 configuration, removing the need for a fixed low-latency memory system.
  • Long vector lengths cannot always compensate for scheduling inefficiency, as the modeled Hwacha configuration underperformed SV-Full in fft, spmv, and transpose.

Reading between the lines

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

  • The same element-group scoreboarding technique could plausibly be applied to other scalable vector ISAs such as SVE, potentially enabling compact SVE cores that avoid register renaming.
  • If the paper's model of Hwacha's central master sequencer is accurate, the results suggest that scheduling flexibility matters more in irregular kernels than in regular streaming loops, worth testing on other sparse or transpose-like workloads.
  • The power breakdown suggests that reducing spurious scalar instruction-fetch activity during low-IPC vector loops could further improve energy efficiency, a direction the paper mentions but does not quantify.
  • The shallow-queue, distributed-scoreboard design is likely sensitive to the number of concurrent vectors in flight; extending it to wider out-of-order windows would require evaluating whether the scoreboard broadcast overhead stays acceptable.
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.

Referee Report

2 major / 4 minor

Summary. The paper presents Saturn, a short-vector RISC-V vector (RVV 1.0) microarchitecture with an instruction-sequencing mechanism that supports fine-granularity chaining, limited multi-issue out-of-order execution, zero dead time, and decoupled run-ahead memory access. The authors describe the microarchitecture (frontend, load/store unit, backend sequencers, scoreboard-based hazard tracking at element-group granularity), provide an open-source RTL implementation, and evaluate it through simulation and VLSI synthesis in a 16nm process. The evaluation compares Saturn against Ara (via direct RTL simulation), Spatz and Hwacha (via self-modeled baselines constructed from Saturn's RTL), and prior published area/power numbers. The paper claims that Saturn achieves comparable or superior power, performance, and area characteristics relative to state-of-the-art long-vector and short-vector implementations.

Significance. The core contribution—a sequencing mechanism for short-vector units that supports explicit chaining, dynamic load balancing, and run-ahead memory without register renaming or deep issue queues—is well motivated and technically interesting. The authors ship a complete RVV 1.0 RTL implementation with precise traps and virtual memory support, which is a substantial engineering contribution, and they ground the evaluation with direct Ara RTL simulation, physical synthesis, and parameter sweeps. These are genuine strengths that go beyond a purely analytical study. However, the headline comparative claim against state-of-the-art short-vector designs currently rests on self-modeled Spatz and Hwacha baselines, and the Spatz model is undermined by an internal inconsistency in the paper's own characterization of Spatz's memory system. The comparative claims therefore need revision before the paper's central claim is fully established.

major comments (2)
  1. [Section VI-A, Table V, Section VIII] The identification of SV-Base with Spatz is internally inconsistent. Section VI-A states that SV-Base is 'comparable to the Spatz microarchitecture' and that Spatz 'supports variable memory latency,' but Table V marks Spatz's 'Var. Mem. Lat.' as unsupported, and Section VIII states that 'Spatz, Vicuna, and Torrent all assume a low-latency memory system.' SV-Base is constructed by disabling Saturn's load-store decoupling and out-of-order issue while retaining Saturn's cache-based, variable-latency memory path. If the real Spatz relies on a tightly coupled fixed-latency shared-L1 memory, then SV-Base is not a faithful Spatz model: the utilization gap between SV-Base and SV-Full in Figure 8 may be attributable to memory-system assumptions rather than to the proposed scheduling mechanism. Since the paper's claim of superiority over state-of-the-art short-vector implementations depends on this baseline, the authors should either run Spatz's actual RTL on the same workloads or explicitly reposition SV-Base as a Saturn-derived baseline and remove or qualify the Spatz comparison.
  2. [Section VI-A] The Hwacha comparison is obtained by 'modelling Hwacha's fundamental behavior with modifications to Saturn's RTL' with no validation against Hwacha's actual RTL or published performance numbers. The conclusions that SV-Full outperforms LV-Hwacha on fft2, spmv, and transpose, and that long vector lengths cannot always compensate for scheduling inefficiencies, rely on this unverified model. A concrete test would be to run Hwacha's open-source RTL (or its published benchmark results) in the same harness and compare against the modeled LV-Hwacha/SV-Hwacha points. If such validation is not feasible, the relative claims against Hwacha should be presented as a modeling study rather than as a direct comparison to the actual design.
minor comments (4)
  1. [Section VI-C] The text gives conflicting efficiency numbers for the same SV-Full design: '112 SGFLOPS/W' appears once and '121 SGFLOPS/W' appears in the immediately following sentence, while Table III reports 121 SGFLOPS/W. The duplicated sentence should be collapsed to a single value consistent with Table III, and the missing spaces ('theSV-Full', '256design') should be fixed.
  2. [Section VI-B, Table III] The area and power comparison to prior work mixes process nodes, datapath widths, and ISA capabilities (e.g., Spatz2 is 22nm with DLEN=64 and lacks floating-point/64-bit support, while Saturn is 16nm with DLEN=256). The text notes that numbers are extrapolated from published results, but the table caption or discussion should also explicitly list these mismatches so that the 'comparable area' claim is not over-interpreted.
  3. [Figure 8] The SV-Hwacha and LV-Hwacha points are model-based configurations, not direct measurements of Hwacha. The figure or its caption should clearly mark these as modeled to avoid misleading readers into treating them as direct comparison points.
  4. [Section VIII] The sentence 'Among comparable work, Saturn is the first to demonstrate efficient execution of short vector lengths without requiring register renaming or a constrained memory system' is contradicted by Table V, which lists the industrial NX27V as having No Renaming ✓, Var. Mem. Lat. ✓, and RVV 1.0 Full. If the claim is intended to be limited to academic designs, that limitation should be stated explicitly.

Circularity Check

2 steps flagged · score 4.0 of 10

Comparative short-vector claim rests on Saturn-derived proxies for Spatz and Hwacha; SV-Base is defined as Saturn minus the very features being evaluated, so part of the performance edge is built into the baseline.

  1. fitted input called prediction [Section VI-A, first paragraph of the performance evaluation (SV-Base / Spatz comparison)]
    "As a baseline, we configure a variant of Saturn without support for load-store decoupling and out-of-order issue. This SV-Base variant is comparable to the Spatz [12] microarchitecture, since Spatz serializes execution through its global controller. We could not compare directly against Spatz’s implementation due to its partial support for RVV . ... The SV-Base configuration, lacking the ability to exploit memory-level parallelism or to dynamically load-balance across issue paths, suffers in all evaluated workloads."

    SV-Base is not an independent Spatz baseline; it is Saturn with load-store decoupling and out-of-order issue disabled. The paper then reports that this variant 'suffers in all evaluated workloads' and concludes that combining DAE with dynamic scheduling is necessary for near-peak utilization. The baseline is therefore defined as lacking precisely the mechanisms whose benefit is being demonstrated, making the SV-Base-to-SV-Full gap a consequence of the model definition rather than a measurement of Spatz.

  2. other [Section VI-A, paragraph defining SV-Hwacha and LV-Hwacha]
    "We also attempt a comparison with Hwacha’s [20] scheduling mechanism by modelling Hwacha’s fundamental behavior with modifications to Saturn’s RTL. Hwacha uses a central 8-entry master sequencer where complex instructions occupy multiple entries. We evaluate this behavior for both short and long vector lengths, where SV-Hwacha uses VLEN = 512 and LV-Hwacha uses VLEN = 4096."

    The Hwacha comparison is produced by editing Saturn's own RTL to emulate a description of Hwacha rather than by running Hwacha's actual RTL or a validated independent simulator. The evaluation then reports that SV-Hwacha underperforms in convolution kernels and that LV-Hwacha underperforms compared to SV-Full in fft, spmv, and transpose. Because the model is built from Saturn's RTL and the Hwacha behavior is imported from a same-group technical report without external validation, the result is an evaluation of Saturn-derived variants, not of the real Hwacha implementation.

full rationale

The core scheduling mechanism itself is derived and described self-contained: the PRSb/PWSb scoreboarding, element-group hazard tracking, and sequencing algorithm are presented as a microarchitectural construction, not as a fit to the evaluation results. There is also independent evidence: Ara is simulated directly from its own RTL, and the physical power, frequency, and area numbers in Table III are compared against published external results. The circularity is therefore partial and concentrated in the comparative performance claim against other short-vector and Hwacha baselines. The paper explicitly states that Spatz was not run directly and that Hwacha was modeled with modifications to Saturn's RTL; these self-referential baselines are then used to conclude that Saturn achieves state-of-the-art short-vector performance. Because SV-Base is defined as Saturn minus the features whose benefit is being shown, the SV-Base-versus-SV-Full gap is partly a tautology, and the internal inconsistency about Spatz's memory-latency support further undermines the fidelity of that proxy. This warrants a moderate circularity score of 4 rather than a higher score, because the central scheduling contribution and the direct Ara comparison retain independent content, and the physical comparison is externally anchored.

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

No fitted numerical parameters are used in the mathematical sense; the central claim rests on architectural design choices and benchmark configurations. The most load-bearing assumptions are the representativeness of modeled baselines and the fairness of cross-process physical comparisons.

free parameters (2)
  • VLEN/DLEN ratio of the evaluated design = 512/256 (2:1)
    Selected as the target design point in Section VII-A based on a sensitivity sweep; the headline performance comparison uses this configuration, not the full design space.
  • Issue queue depth = 4 entries
    Chosen from the sensitivity analysis in Section VII-B; the central evaluation uses this depth, though the paper concludes depths of 2 to 4 are appropriate.
assumptions (4)
  • domain assumption Short application vector lengths dominate mobile, DSP, and embedded workloads, making large vector register files low-value.
    Introduced in Section II-D to justify the short-vector premise; supported by external studies [17], [18], [28], but the paper does not re-validate this on its own workloads.
  • domain assumption Utilization is a fair comparative performance metric when datapath width and memory bandwidth are matched.
    Section VI-A defines utilization as the main metric; this assumes frequency and memory-system effects are secondary, yet Table III reports different frequencies across compared units.
  • ad hoc to paper Modeling Spatz-like and Hwacha-like baselines by disabling or modifying Saturn's RTL faithfully captures their behavior.
    Section VI-A: SV-Base is said to be comparable to Spatz, and Hwacha is modeled via modifications to Saturn's RTL; no independent validation against the actual implementations is provided.
  • domain assumption Published area and power numbers from other vector units can be extrapolated across process nodes using kGE and reported figures.
    Section VI-B and Table III mix 16nm and 22nm results and extrapolate prior area from publications, which weakens physical comparisons.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Instruction Scheduling in the Saturn Vector Unit." pith.science (2026). https://pith.science/paper/OL4BGP2B

@misc{pith2026241200997,
  author       = {Pith},
  title        = {Pith review of: Instruction Scheduling in the Saturn Vector Unit},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/OL4BGP2B}},
  note         = {Machine review of arXiv:2412.00997}
}
read the original abstract

While the challenges and solutions for efficient execution of scalable vector ISAs on long-vector-length microarchitectures have been well established, not all of these solutions are suitable for short-vector-length implementations. This work proposes a novel microarchitecture for instruction sequencing in vector units with short architectural vector lengths. The proposed microarchitecture supports fine-granularity chaining, multi-issue out-of-order execution, zero dead-time, and run-ahead memory accesses with low area or complexity costs. We present the Saturn Vector Unit, a RTL implementation of a RVV vector unit. With our instruction scheduling mechanism, Saturn exhibits comparable or superior power, performance, and area characteristics compared to state-of-the-art long-vector and short-vector implementations.

Figures

Figures reproduced from arXiv: 2412.00997 by the authors.

Figure 1
Figure 1. Overview of the Saturn short-vector microarchitecture (gray) and [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Pipeline stages of Saturn when integrated into a host in-order RISC-V [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. The vector load and store paths handle variable-chime and long [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (9 more)
Figure 4
Figure 4. Figure 4: The backend organization for a configuration with two arithmetic [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 5
Figure 5. Figure 5: A comparison of instruction cracking vs sequencing for a block of [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 7
Figure 7. Figure 7: Diagram of a vector instruction sequencer. The sequencer tracks [PITH_FULL_IMAGE:figures/full_fig_p006_7.png]
Figure 6
Figure 6. Figure 6: A diagram depicting how Saturn implements the PRSb and PWSb [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]
Figure 8
Figure 8. Figure 8: Utilization across a variety of kernels. Comparison points include short-vector (SV) designs evaluated using Saturn, long-vector (LV) designs evaluated [PITH_FULL_IMAGE:figures/full_fig_p008_8.png]
Figure 11
Figure 11. Figure 11: Power consumption across three configurations of Saturn running a [PITH_FULL_IMAGE:figures/full_fig_p009_11.png]
Figure 10
Figure 10. Figure 10: Layout of the SV-Full V512D256 implementation of Saturn, at 60% density. We additionally break down the area of the various com￾ponents of Saturn across three machine configurations with varying VLEN and DLEN [PITH_FULL_IMAGE:figures/full_fig_p009_10.png]
Figure 12
Figure 12. Figure 12: Performance degradation with memory latency injection on top of [PITH_FULL_IMAGE:figures/full_fig_p010_12.png]
Figure 13
Figure 13. Figure 13: Utilization of SGEMM with varying problem sizes. [PITH_FULL_IMAGE:figures/full_fig_p011_13.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 3 Pith papers

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

  1. Tensor Program Optimization for the RISC-V Vector Extension Using Probabilistic Programs

    cs.LG 2025-07 conditional novelty 6.0 of 10

    Integrating RVV tensor intrinsics into TVM's MetaSchedule autotuner yields AI kernels that are 29-50% faster than hand-written muRISCV-NN and 35-46% faster than compiler autovectorization on tested RVV 1.0 hardware.

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

  3. SEAM-V: A Hybrid-Decoupled RISC-V Vector Processor with Backend-Visible Packet Semantics and Source-Lifetime-Aware Scheduling

    cs.AR 2026-07 conditional novelty 5.0 of 10

    A hybrid-decoupled RISC-V vector architecture that forms execute packets, propagates their context into the vector backend, and achieves 1.34x geometric-mean speedup over a tightly coupled baseline.

Reference graph

Works this paper leans on

31 extracted references · 29 canonical work pages · cited by 3 Pith papers

  1. [1]

    RISC-V:NX27V

    “RISC-V:NX27V.” Available: https://www.andestech.com/en/products- solutions/andescore-processors/riscv-nx27v/

    work page

  2. [2]

    Semidynamics Vector Unit - Only 100% customisable RISC-V Vector Unit

    “Semidynamics Vector Unit - Only 100% customisable RISC-V Vector Unit.” Available: https://semidynamics.com/en/technology/vector-unit

    work page

  3. [3]

    SiFive Intelligence X280

    “SiFive Intelligence X280.” Available: https://www.sifive.com/cores/ intelligence-x280

    work page

  4. [4]

    SX-Aurora TSUBASA Architecture

    “SX-Aurora TSUBASA Architecture.” Available: https://www.nec.com/ en/global/solutions/hpc/sx/architecture.html?

    work page

  5. [5]

    Armv8-M Architecture Reference Manual,

    “Armv8-M Architecture Reference Manual,” 2015. Available: https: //developer.arm.com/documentation/ddi0553/bx/?lang=en

    work page 2015

  6. [6]

    RISC-V ”V

    “RISC-V ”V” Vector Extension,” Sep. 2021. Available: https://github. com/riscv/riscv-v-spec/releases/download/v1.0/riscv-v-spec-1.0.pdf

    work page 2021

  7. [8]

    Veyron V1 Data Center-Class RISC-V Processor,

    “Veyron V1 Data Center-Class RISC-V Processor,” in 2023 IEEE Hot Chips 35 Symposium (HCS) , Aug. 2023, pp. 1–16. Available: https://ieeexplore.ieee.org/document/10254710

    work page arXiv 2023

  8. [9]

    EVE: Ephemeral Vector Engines,

    K. Al-Hawaj, T. Ta, N. Cebry, S. Agwa, O. Afuye, E. Hall, C. Golden, A. B. Apsel, and C. Batten, “EVE: Ephemeral Vector Engines,” in 2023 IEEE International Symposium on High-Performance Computer Architecture (HPCA) . Montreal, QC, Canada: IEEE, Feb. 2023, pp. 691–704. Available: https://ieeexplore.ieee.org/document/10071074/

    work page arXiv 2023

Show all 31 references
  1. [10]

    Vector microprocessors,

    K. Asanovi ´c, “Vector microprocessors,” Ph.D. dissertation, EECS Department, University of California, Berkeley, 1998. Available: http://www2.eecs.berkeley.edu/Pubs/TechRpts/1998/6404.html

    1998

  2. [11]

    Asanovic, Computer Architecture: A Quantitative Approach, Ap- pendix G , 2019

    K. Asanovic, Computer Architecture: A Quantitative Approach, Ap- pendix G , 2019

    2019

  3. [12]

    Spatz: A Compact Vector Processing Unit for High-Performance and Energy- Efficient Shared-L1 Clusters,

    M. Cavalcante, D. W ¨uthrich, M. Perotti, S. Riedel, and L. Benini, “Spatz: A Compact Vector Processing Unit for High-Performance and Energy- Efficient Shared-L1 Clusters,” in Proceedings of the 41st IEEE/ACM International Conference on Computer-Aided Design , ser. ICCAD ’22. ...

    2022

  4. [13]

    Xuantie-910: A Commercial Multi-Core 12-Stage Pipeline Out-of-Order 64-bit High Performance RISC-V Processor with Vector Extension : Industrial Product,

    C. Chen, X. Xiang, C. Liu, Y . Shang, R. Guo, D. Liu, Y . Lu, Z. Hao, J. Luo, Z. Chen, C. Li, Y . Pu, J. Meng, X. Yan, Y . Xie, and X. Qi, “Xuantie-910: A Commercial Multi-Core 12-Stage Pipeline Out-of-Order 64-bit High Performance RISC-V Processor with Vector Extension : Indu...

    2020

  5. [14]

    Architecture of the Hexagon™ 680 DSP for mobile imaging and computer vision,

    L. Codrescu, “Architecture of the Hexagon™ 680 DSP for mobile imaging and computer vision,” in 2015 IEEE Hot Chips 27 Symposium (HCS), Aug. 2015, pp. 1–26. Available: https://ieeexplore.ieee.org/ document/7477329

    2015

  6. [15]

    Hexagon DSP: An Architecture Optimized for Mobile Multimedia and Communications,

    L. Codrescu, W. Anderson, S. Venkumanhanti, M. Zeng, E. Plondke, C. Koob, A. Ingle, C. Tabony, and R. Maule, “Hexagon DSP: An Architecture Optimized for Mobile Multimedia and Communications,” IEEE Micro , vol. 34, no. 2, pp. 34–43, Mar. 2014. Available: https://ieeexplore-ieee...

    2014

  7. [16]

    Out-of-order vector architectures,

    R. Espasa, M. Valero, and J. Smith, “Out-of-order vector architectures,” in Proceedings of 30th Annual International Symposium on Microarchitecture . Research Triangle Park, NC, USA: IEEE Comput. Soc, 1997, pp. 160–170. Available: http://ieeexplore.ieee.org/document/645807/

    1997

  8. [17]

    BLASFEO: Basic Linear Algebra Subroutines for Embedded Optimization,

    G. Frison, D. Kouzoupis, T. Sartor, A. Zanelli, and M. Diehl, “BLASFEO: Basic Linear Algebra Subroutines for Embedded Optimization,” ACM Trans. Math. Softw. , vol. 44, no. 4, pp. 42:1–42:30, Jul. 2018. Available: https://doi.org/10.1145/3210754

    2018 doi

  9. [18]

    Vector- Processing for Mobile Devices: Benchmark and Analysis,

    A. Khadem, D. Fujiki, N. Talati, S. Mahlke, and R. Das, “Vector- Processing for Mobile Devices: Benchmark and Analysis,” Sep. 2023. Available: http://arxiv.org/abs/2309.02680

    2023 arXiv

  10. [19]

    Adaptable Register File Organization for Vector Processors,

    C. R. Lazo, E. Reggiani, C. R. Morales, R. F. Bagu ´e, L. A. V . Vargas, M. A. R. Salinas, M. V . Cort ´es, O. S. Unsal, and A. Cristal, “Adaptable Register File Organization for Vector Processors,” in 2022 IEEE International Symposium on High-Performance Computer Architecture...

    2022 arXiv

  11. [20]

    The hwacha vector-fetch architecture manual, version 3.8.1,

    Y . Lee, C. Schmidt, A. Ou, A. Waterman, and K. Asanovi ´c, “The hwacha vector-fetch architecture manual, version 3.8.1,” Tech. Rep. UCB/EECS-2015-262, Dec. 2015. Available: http://www2.eecs. berkeley.edu/Pubs/TechRpts/2015/EECS-2015-262.html

    2015

  12. [21]

    Vitruvius+: An Area-Efficient RISC-V Decoupled Vector Coprocessor for High Performance Computing Applications,

    F. Minervini, O. Palomar, O. Unsal, E. Reggiani, J. Quiroga, J. Marimon, C. Rojas, R. Figueras, A. Ruiz, A. Gonzalez, J. Mendoza, I. Vargas, C. Hernandez, J. Cabre, L. Khoirunisya, M. Bouhali, J. Pavon, F. Moll, M. Olivieri, M. Kovac, M. Kovac, L. Dragic, M. Valero, and A. Cri...

    2023

  13. [22]

    Preliminary Performance Evaluation of the Fujitsu A64FX Using HPC Applications,

    T. Odajima, Y . Kodama, M. Tsuji, M. Matsuda, Y . Maruyama, and M. Sato, “Preliminary Performance Evaluation of the Fujitsu A64FX Using HPC Applications,” in 2020 IEEE International Conference on Cluster Computing (CLUSTER) , Sep. 2020, pp. 523–530. Available: https://ieeexplo...

    2020

  14. [23]

    RISC-V2: A Scalable RISC-V Vector Processor,

    K. Patsidis, C. Nicopoulos, G. C. Sirakoulis, and G. Dimitrakopoulos, “RISC-V2: A Scalable RISC-V Vector Processor,” in 2020 IEEE International Symposium on Circuits and Systems (ISCAS) , Oct. 2020, pp. 1–5. Available: https://ieeexplore.ieee.org/document/9181071

    2020

  15. [24]

    Arm Neoverse N2: Arm’s 2nd generation high performance infrastructure CPUs and system IPs,

    A. Pellegrini, “Arm Neoverse N2: Arm’s 2nd generation high performance infrastructure CPUs and system IPs,” in 2021 IEEE Hot Chips 33 Symposium (HCS) , Aug. 2021, pp. 1–27. Available: https://ieeexplore.ieee.org/document/9567483

    2021

  16. [25]

    Ara2: Exploring Single- and Multi-Core Vector Processing with an Efficient RVV1.0 Compliant Open-Source Processor,

    M. Perotti, M. Cavalcante, R. Andri, L. Cavigelli, and L. Benini, “Ara2: Exploring Single- and Multi-Core Vector Processing with an Efficient RVV1.0 Compliant Open-Source Processor,” Nov. 2023. Available: http://arxiv.org/abs/2311.07493

    2023 arXiv

  17. [26]

    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,” pp. 18 pages, 831 915 bytes, 2021. Available: https://drops.dagstuhl.de/entities/ document/10.4230/LIPIcs.ECRTS.2021.1

    2021 doi

  18. [27]

    Fye24-q3 shareholder letter,

    A. H. plc, “Fye24-q3 shareholder letter,” December 2023. Available: https://investors.arm.com/static-files/4404a89a-d033-419e- aa0f-d7b15d40e11f

    2023

  19. [28]

    A risc-v simulator and benchmark suite for designing and evaluating vector architectures,

    C. Ram ´ırez, C. A. Hern ´andez, O. Palomar, O. Unsal, M. A. Ram ´ırez, and A. Cristal, “A risc-v simulator and benchmark suite for designing and evaluating vector architectures,” ACM Transactions on Architecture and Code Optimization (TACO) , vol. 17, no. 4, pp. 1–30, 2020

    2020

  20. [29]

    The CRAY-1 computer system,

    R. M. Russell, “The CRAY-1 computer system,” Communications of the ACM , vol. 21, no. 1, pp. 63–72, Jan. 1978. Available: https://dl.acm.org/doi/10.1145/359327.359336

    1978

  21. [30]

    Decoupled access/execute computer architectures,

    J. E. Smith, “Decoupled access/execute computer architectures,” ACM SIGARCH Computer Architecture News , vol. 10, no. 3, pp. 112–119, Apr. 1982. Available: https://dl.acm.org/doi/10.1145/1067649.801719

    1982

  22. [31]

    The ARM Scalable Vector Extension,

    N. Stephens, S. Biles, M. Boettcher, J. Eapen, M. Eyole, G. Gabrielli, M. Horsnell, G. Magklis, A. Martinez, N. Premillieu, A. Reid, A. Rico, and P. Walker, “The ARM Scalable Vector Extension,” IEEE Micro , vol. 37, no. 2, pp. 26–39, Mar. 2017. Available: http://ieeexplore.iee...

    2017

  23. [32]

    Parallel operation in the control data 6600,

    J. E. Thornton, “Parallel operation in the control data 6600,” in Proceedings of the October 27-29, 1964, Fall Joint Computer Conference, Part II: V ery High Speed Computer Systems , ser. AFIPS ’64 (Fall, Part II). New York, NY , USA: Association for Computing Machinery, Oct. ...

    1964

Pith tools

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