SRB-ELL: A Vector-Friendly Sparse Matrix Format for SpMV on Scratchpad-Augmented Architectures

Abstract

Sparse Matrix–Vector Multiplication (SpMV) is a critical computational kernel in high-performance computing (HPC) and artificial intelligence (AI). However, its irregular memory access patterns lead to frequent cache misses on multi-level cache hierarchies, significantly degrading performance. Scratchpad memory (SPM), a software-managed, low-latency on-chip memory, offers improved data locality and control, making it a promising alternative for irregular workloads. To enhance SpMV performance, we propose a vectorized execution framework targeting SPM-augmented processors. Recognizing the limitations of traditional formats for vectorization, we introduce Sorted-Row-Block ELL (SRB-ELL), a new matrix storage format derived from ELLPACK (ELL). SRB-ELL stores only non-zero elements, partitions the matrix into row blocks, and sorts them by block size to improve load balance and SIMD efficiency. We implement and evaluate SRB-ELL on a custom processor architecture with integrated SPM using the gem5 simulator. Experimental results show that, compared to vectorized CSR-based SpMV, the SRB-ELL design achieves up to 1.48× speedup and an average of 1.19×.

1. Introduction

Since the end of Dennard scaling and the subsequent stagnation in CPU clock frequency, computer architecture has undergone a paradigm shift. To sustain performance growth, both hardware architects and software developers have increasingly relied on exploiting parallelism. While instruction-level parallelism and thread-level parallelism have been extensively studied and deployed, data-level parallelism (DLP) remains a largely untapped opportunity. DLP can be efficiently exposed to hardware through vectorized execution, such as Single Instruction Multiple Data (SIMD) architectures [1,2], which operate on multiple data elements simultaneously. Many modern applications stand to benefit from vectorization, yielding improved performance, enhanced energy efficiency, and better utilization of computational resources [3,4,5,6].

Among the various computational workloads, sparse matrix operations—and in particular, Sparse Matrix–Vector Multiplication (SpMV)—pose significant challenges for efficient vectorization due to their inherently irregular memory access patterns and low computational intensity [7,8]. Despite these difficulties, SpMV remains a foundational kernel in a wide range of domains, including linear solvers, high-performance computing (HPC), artificial intelligence (AI), graph computing, and supercomputing [9,10,11,12,13,14]. For instance, SpMV is the core operation in Conjugate Gradient methods, which serve as a central component in the High-Performance Conjugate Gradient (HPCG) benchmark—an emerging alternative to the traditional LINPACK benchmark for evaluating supercomputer capabilities [15,16]. In AI workloads, SpMV is frequently used in optimization routines such as gradient descent in Support Vector Machine (SVM) training [17]. Additionally, in the realm of big data and graph analytics, SpMV forms the computational backbone of many graph algorithms and is the most critical kernel in the GraphBLAS specification [18]. Therefore, achieving high-performance vectorized implementations of SpMV is of paramount importance, with the potential to deliver transformative improvements across HPC, AI, and data-intensive applications.

In these domains, many real-world applications involve sparse matrices with less than 1% of non-zero elements [19]. To minimize memory usage and improve computational efficiency, a variety of compressed sparse matrix formats have been proposed [20,21,22,23,24]. However, most of these formats are poorly aligned with the requirements of modern vector architectures. Two primary challenges emerge: (1) sparse matrix formats often involve irregular memory access and indirection, which inhibit effective SIMD utilization, and (2) existing vector hardware lacks native support for the structural irregularity of sparse computations.

Among these formats, Compressed Sparse Row (CSR) remains the most commonly used due to its generality and compact representation [25,26]. However, its pointer-based row indexing and variable row lengths introduce irregular control flow and memory access, resulting in low vector lane utilization and poor cache performance.

To address these challenges, scratchpad memory (SPM) [27] has been proposed as an effective alternative to traditional cache hierarchies for irregular workloads. SPM offers low-latency, software-controlled access, allowing fine-grained management of frequently accessed data such as input vectors in SpMV, thereby reducing main memory traffic and improving data locality.

In this work, we propose Sorted-Row-Block ELL (SRB-ELL), a new sparse matrix format optimized for vectorization and SPM-based architectures. SRB-ELL stores only non-zero elements, partitions the matrix into row blocks, and sorts them by size to improve regularity and SIMD efficiency. We implement the SRB-ELL-based SpMV kernel on a custom processor architecture with integrated scratchpad memory using the gem5 simulator [28]. Experimental results demonstrate that SRB-ELL significantly improves vector efficiency and overall performance compared to vectorized CSR implementations.

The structure of this paper is as follows. Section 2 introduces related work. Section 3 details the design of the SRB-ELL format and its integration with scratchpad memory. Section 4 presents experimental evaluations of the proposed method. Finally, Section 5 concludes the paper.

2. Related Works

This section surveys existing sparse matrix formats, analyzes the limitations of current vectorization techniques for sparse computations, and highlights the motivation for hardware–software co-design to improve vectorization efficiency.

2.1. Sparse Matrix Compressed Formats

Efficient memory storage is a fundamental challenge in sparse matrix computation, motivating the development of numerous compressed formats that aim to minimize storage cost and improve access efficiency. CSR is one of the most widely used representations for sparse matrices, particularly in libraries that support sparse matrix operations. For the sparse matrix Ain Figure 1a, CSR encodes the matrix using three arrays, shown in Figure 1b: data stores all non-zero values in row-major order, col_idx holds the corresponding column indices, and row_ptr indicates the starting position of each row in the data and col_idx arrays. This compact structure eliminates the need to store zero elements explicitly, significantly reducing memory usage.

Algorithm 1 presents a typical CSR-based implementation of SpMV. The algorithm traverses only the non-zero elements of matrix A, thus avoiding unnecessary computation and memory access. However, CSR’s performance can be limited by pointer-chasing overhead, since the value in col_idx must first be loaded and then used to access the corresponding entry in the dense input vector x, leading to irregular memory access and reduced vectorized efficiency.

Algorithm 1 CSR-Based SpMV Implementation.

1: for  $i=0$  to  $rows-1$  do 2:     for $j=row\_ptr\left[i\right]$ to $row\_ptr[i+1]-1$ do 3:         $y\left[i\right]\leftarrow y\left[i\right]+data\left[j\right]\times x[col\_idx[j\left]\right]$ 4:     end for 5: end for

The ELLPACK (ELL) format is a structured sparse matrix representation optimized for vector and GPU architectures. It stores each row using a fixed number of entries equal to the maximum number of non-zero elements per row (K), padding with zeros when necessary. Two dense arrays of size $M\times K$ are used: data stores non-zero values and padded zeros, while indices holds the corresponding column indices, as illustrated in Figure 1c. This regular layout enables aligned memory accesses and efficient SIMD vectorization.

Algorithm 2 shows the ELL-based implementation of SpMV. Each row performs K fixed-length operations using the corresponding entries in the data and indices arrays, enabling regular and aligned memory accesses that benefit vector execution. However, when the matrix has a highly irregular distribution of non-zero elements across rows, the padding introduces redundant computations and memory overhead. This inefficiency is further amplified on CPUs, where vector units are narrower and memory bandwidth is more constrained. As a result, despite its structural regularity, the ELL format cannot be efficiently vectorized for general sparse matrices on modern CPUs.

Algorithm 2 ELL-Based SpMV Implementation.

1: for $i=0$ to $M-1$ do 2:     for $j=0$ to $K-1$ do 3:         $y\left[i\right]\leftarrow y\left[i\right]+\mathit{data}\left[i\right]\left[j\right]\times x\left[\mathit{indices}\right[i\left]\right[j\left]\right]$ 4:     end for 5: end for

2.2. SpMV Vectorization Bottlenecks

Vectorization, or SIMD, is a fundamental optimization technique in modern processors that allows performing the same operation on multiple data elements simultaneously. By operating on vectors of data instead of scalars, SIMD improves instruction throughput and DLP, which is especially critical given the stagnation of processor clock speeds.

To address vectorization challenges in irregular applications such as sparse matrix computations, the ARM Scalable Vector Extension (SVE) provides flexible hardware features including scalable vector lengths, predicate execution, and efficient gather/scatter instructions [29,30,31,32]. These features allow computation on irregular or partial vectors, reducing control divergence and improving SIMD utilization.

As shown in Figure 2, unlike fixed-length SIMD units such as SSE, SVE uses predicate vectors (e.g., svbool_t) to enable conditional execution on vector lanes. This fine-grained control is particularly effective for sparse computations.

However, applying vectorization effectively to SpMV is notoriously difficult. The primary challenge arises from the irregular distribution of non-zero elements, which leads to indirect memory accesses and irregular memory access patterns. Traditional formats such as CSR suffer from pointer chasing and poor data locality, while ELL introduces padding overhead to maintain regular structure, which can result in redundant computations and increased memory bandwidth usage, particularly for highly irregular matrices.

Prior efforts have explored various strategies to enhance memory access patterns and vectorization efficiency in sparse matrix computations. VHCC [33] employs a two-dimensional jagged partitioning scheme combined with segmented summation to improve data locality and SIMD utilization. ESB [34] reduces padding overhead in ELL by sorting and blocking rows, making it more suitable for engineering applications. SELL-C [35] reduces zero padding by slicing the matrix into C-row blocks, sorting rows within each block by non-zero count, and padding only to the block’s maximum row length. Hartwig et al. [36] further aligns row lengths within each block to the SIMD width or GPU warp size, improving parallel efficiency on architectures with strict alignment requirements. CSR5 [20] is designed for cross-platform compatibility and delivers moderate performance on x86 architectures. Chen et al. [37] propose a fine-grained comparison of non-zero elements to boost vectorization in irregular workloads. Ashari et al. introduce the BRC format, which applies two-dimensional blocking to better exploit cache and parallelism. CVR [38] introduces a vectorization-oriented sparse matrix format that enables simultaneous multi-row processing and efficient SIMD lane utilization, thereby improving cache locality while minimizing preprocessing overhead.

Block-based formats like BCSR and UBCSR improve vector utilization by grouping non-zeros into blocks [39,40]. However, these formats often suffer from zero padding overhead and alignment constraints, which may degrade performance. Graph-based reordering techniques such as Cuthill–McKee [41] can enhance data locality, but they also require complex preprocessing steps and are not always portable across different matrix structures.

3. Design and Implementation

We propose Sorted-Row-Block ELLPACK (SRB-ELL), a vector-friendly sparse matrix format based on ELL, designed to reduce padding and improve SIMD efficiency. To further optimize SpMV performance, we integrate scratchpad memory into armv8 processor in gem5.

3.1. SRB-ELL Design and Vectorized Algorithm

The ELL format is well-suited for vectorized execution due to its regular memory layout, but its performance degrades significantly when matrices have irregular row lengths. This is because ELL requires zero padding to align row lengths, which leads to additional memory usage and unnecessary computations, reducing overall SpMV efficiency. In contrast, formats like CSR are more compact but suffer from irregular access patterns and indirect memory accesses, making them less amenable to SIMD vectorization.

To address these limitations, we propose SRB-ELL, a vector-friendly sparse matrix format based on ELL, designed to improve vectorization utilization while minimizing zero padding overhead. SRB-ELL organizes the sparse matrix into blocks of rows, sorts them by row length, and removes fully empty rows, thereby preserving data regularity and reducing redundant storage and computation.

The SRB-ELL format employs four arrays: data stores all non-zero values, index stores their corresponding column indices, row_pos records the row position of each block, and row_len stores the length of each row. The storage process consists of the following:

• dividing the matrix into row blocks;
• storing each block independently;
• sorting blocks by increasing row length;
• removing blocks with zero-length rows.

As illustrated in Figure 3, the matrix A is first divided into five row blocks. The position and length of each row are recorded in row_pos and row_len, respectively. The row blocks are then sorted by ascending row length to minimize padding overhead. Fully empty rows are discarded during this process. This layout enhances memory access regularity while eliminating the performance penalties of padding, making it suitable for efficient vectorized SpMV computation.

To maximize the performance of SpMV based on the SRB-ELL, we implement a vectorized SpMV algorithm using SVE. Algorithm 3 outlines the computation process, First, row_pos and row_len are initialized to the current row index and its non-zero value count; svcntd() returns the system’s vector length; and svsum is zeroed to accumulate partial dot-products. Then, for each chunk of non-zero, count sets the active lane count in the predicate register pg; vector instructions (svld1_f64, svld1sw_u64 and svld1_gather_u64) load the non-zero value, column indices and the corresponding x elements; a vector multiply–accumulate updates the svsum. Once all non-zero values in the row have been processed, vector instruction svaddv reduces svsum to produce the y entry for row_pos.

Algorithm 3 SVE Vectorized SRB-ELL SpMV Implementation.

1: for $i=0$ to $N-1$ do   2:     $row\_pos\leftarrow \mathit{row}\_\mathit{pos}\left[i\right]$, $row\_len\leftarrow \mathit{row}\_\mathit{len}\left[i\right]$   3:     $vec\_size\leftarrow \mathtt{svcntd}\left(\right)$, $svsum\leftarrow \mathtt{svdup}\_\mathtt{f}\mathtt{64}\left(0.0\right)$   4:     for $j=0$ to $row\_len$ step $vec\_size$ do   5:         $count\leftarrow min(row\_len-j,vec\_size)$   6:         $pg\leftarrow \mathtt{svwhilelt}\_\mathtt{b}\mathtt{64}(0,count)$   7:         $svval\leftarrow \mathtt{svld}\mathtt{1}\_\mathtt{f}\mathtt{64}(pg,\mathit{data}[i\left]\right[j\left]\right)$   8:         $idx\leftarrow \mathtt{svld}\mathtt{1}\mathtt{sw}\_\mathtt{u}\mathtt{64}(pg,\mathit{index}[i\left]\right[j\left]\right)$   9:         $svxv\leftarrow \mathtt{svld}\mathtt{1}\_\mathtt{gather}\_\mathtt{u}\mathtt{64}\mathtt{index}\_\mathtt{f}\mathtt{64}(pg,x,idx)$ 10:         $svsum\leftarrow \mathtt{svmla}\_\mathtt{f}\mathtt{64}\_\mathtt{m}(pg,svsum,svval,svxv)$ 11:     end for 12:     $y[row\_pos]\leftarrow \mathtt{svaddv}(\mathtt{svptrue}\_\mathtt{b}\mathtt{64}(),svsum)$ 13: end for

3.2. Scratchpad Memory Implementation in gem5

In SpMV operations, the irregular distribution of non-zero elements in sparse matrices often leads to non-contiguous and unpredictable memory accesses to the dense input vector x. This irregularity severely limits data reuse and results in frequent cache misses, making SpMV a memory-bound computation. SPM is high-speed internal storage structure with simpler allocation and control mechanisms compared to general cache memories. To alleviate the inefficiency of caches under irregular access patterns in SpMV operations, we integrate a SPM into the processor. In our design, the SPM is exclusively allocated for storing the dense input vector x, which is repeatedly accessed during computation. This explicit management of x within the SPM reduces memory hierarchy traffic and access latency. The sparse matrix—including its non-zero values and associated index metadata—remains in off-chip memory and is streamed during execution. This design choice simplifies the memory allocation strategy.

To evaluate the effectiveness of our proposed architecture and storage format, we rely on the gem5 simulator. It is a widely used, modular, and extensible simulator for computer-system architecture research. It supports detailed microarchitectural modeling and provides a flexible environment for integrating and analyzing hardware modifications. Compared to real hardware prototyping, gem5 offers faster iteration, lower cost, and fine-grained observability of internal behaviors. These features make gem5 an ideal platform for implementing and evaluating customized memory hierarchies.

In gem5, processor cores, caches, and main memory communicate through a port-based architecture that mimics real-world bus connections. Each module consists of a C++ class that defines behavior and a Python configuration script for system instantiation. To maintain modularity while expanding the memory hierarchy, we introduce a custom interconnect component, Xbar, which abstracts communication between components at different levels of the memory system.

To integrate a SPM module into the memory system, we design a new interconnect class SPM_Xbar, derived from our custom Xbar. This component adds additional slave ports for connecting the CPU and SPM, while preserving existing connections to the instruction and data caches. On the CPU side, a new master port is added to interface with SPM_Xbar without interfering with the original cache and memory pathways.

The SPM is implemented as an extension of the base memory class in gem5. We augment it with configurable parameters such as latency, bandwidth, and capacity. Figure 4 illustrates the architectural integration of the SPM into the processor’s memory hierarchy. The CPU is connected to both the traditional cache subsystem and the newly introduced SPM via a custom interconnect module, SPM_Xbar. This interconnect module enables parallel access paths: one for regular memory operations through caches and DRAM, and another dedicated path for accessing the SPM.

And, we implement SPM as a configurable memory block with dedicated read/write ports that bypasses the cache hierarchy entirely. It is mapped to a fixed physical address range. During SpMV execution, the dense input vector x is stored in the SPM, allowing low latency and avoiding cache competition with matrix metadata. Meanwhile, the sparse matrix data is streamed from off-chip memory through the cache subsystem.

To enable software-level control of the SPM, we implement a user–space interface: spm_mem_alloc(uint64_t mem_size, uint64_t mem_address), where mem_size specifies the size of the memory region to be allocated, while mem_address defines the starting physical address of the SPM where the allocation should begin. The function internally invokes the mmap system call to map the specified physical memory region into the process’s virtual address space. It returns a generic pointer to the mapped region, which enables user–space programs to explicitly access and manage data within the SPM. Through this interface, fine-grained software-level control over the SPM is achieved, facilitating customized memory management strategies for performance-critical workloads.

In our prototype, the SPM is configured with 128 KB of capacity. The overall memory space is partitioned into 4 GB for main memory and 2 GB for I/O space, with the SPM address region isolated for conflict-free access.

By executing index-dependent operations on the input vector entirely within the SPM, the design minimizes memory hierarchy traffic and enhances effective bandwidth for streaming the sparse matrix. This hardware–software co-optimization enables higher throughput and improves the efficiency of vectorized SpMV kernels.

4. Results

This section presents the experimental evaluation of the proposed approach. We first describe the simulation environment and dataset configurations. Then, we compare the storage overhead of SRB-ELL with CSR and ELL format, followed by the performance analysis of vectorized SRB-ELL on an SPM-based processor architecture.

4.1. Full-System Simulation Infrastructure

We conduct full-system simulations using the gem5 with a single-core ARMv8 in-order CPU model. The simulated processor integrates a software-managed scratchpad memory and its user-level interface. The system runs Ubuntu 16.04 with Linux kernel 4.18, and employs a stride prefetcher to enhance cache ability. Key simulation parameters are summarized in

Table 1. Simulated processor system configuration.

Component	Configuration
CPU	1 GHz; ARMv8; in-order core
L1 Data Cache	32 KB; 2-way assoc; 2 cycles; 64B line; 4 MSHRs;
L1 Instruction Cache	32 KB; 2-way assoc; 2 cycles; 64B line; 4 MSHRs;
L2 Cache	1 MB; 8-way assoc; 20 cycles; 64B line; 20 MSHRs;
DRAM	4 GB DDR4
Scratchpad Memory	128 KB; 2 cycles; 512 GB/s

.

4.2. Real-World Data Sets

We use 2562 sparse matrices from the publicly available SuiteSparse Matrix Collection [42,43], covering a wide range of realistic application domains, including graph analytics, geometry processing, computational fluid dynamics, optimization, chemical simulation, circuit modeling, networks, and machine learning. The matrix characteristics are summarized in

Table 2. Structural characteristics of the sparse matrix datasets.

Matrix Feature	Max	Min	Avg
Num_Of_Rows	16,384	18	5320
Sparsity (%)	100.00	0.00017	1.17
NNZ (Non-Zeros)	18,068,388	24	58,990
NNZ_Per_Row	14,231	0	11

, including the number of non-zero elements (NNZ), average non-zeros per row (NNZ_Per_Row), and sparsity, defined as $\mathrm{NNZ}/(M\times N)$. The maximum row length is limited to 16,384 ($2^{14}$) due to the 128 KB capacity of the SPM, which can hold up to 16,384 double-precision values.

4.3. Experimental Results

4.3.1. Storage Overhead

CSR stores the non-zero elements of a sparse matrix and their row and column information using three one-dimensional arrays: data, row_ptr, and col_idx, with sizes NNZ, $N+1$, and NNZ, respectively, where NNZ denotes the number of non-zero elements and N denotes the number of rows. Taking double-precision floating-point values as an example, the storage cost of a CSR matrix is Equation (1), which indicates that the storage cost depends on both the number of non-zero elements and the number of rows.

$${\mathrm{Cos}\mathrm{t}}_{\mathrm{CSR}}=8\times \mathrm{NNZ}+4\times \mathrm{NNZ}+4\times (N+1)$$

(1)

ELL employs two two-dimensional arrays to store non-zero values and column indices, with the first dimension representing rows. Both arrays have size $N\times k$, where k denotes the maximum row length of the sparse matrix. The storage cost for ELL is given by Equation (2), showing that the cost depends on the matrix size and is closely related to the data distribution. Since sparse matrices often have irregular distributions, the ELL format is typically suitable for matrices with relatively regular data patterns.

$${\mathrm{Cos}\mathrm{t}}_{\mathrm{ELL}}=8\times N\times k+4\times N\times k$$

(2)

The SRB-ELL is similar to ELL but only stores non-zero values and their column indices, while additionally using two one-dimensional arrays, row_pos and row_len, to record row positions and lengths. The storage cost of SRB-ELL is Equation (3), which is similar to CSR, mainly depending on matrix size. Compared to CSR, SRB-ELL only introduces extra storage for row length arrays.

$${\mathrm{Cos}\mathrm{t}}_{\mathrm{SRB}-\mathrm{ELL}}=8\times \mathrm{NNZ}+4\times \mathrm{NNZ}+4\times N+4\times N$$

(3)

Figure 5 shows the storage costs of different formats across our datasets, where the differently colored points indicate the actual storage overhead of each matrix under the corresponding format. CSR and SRB-ELL exhibit similar storage trends, as both store only non-zero elements. Compared to CSR, SRB-ELL introduces an additional overhead of approximately $4N$ bytes to record row positions and lengths, but it avoids dependence on data distribution, making it more broadly applicable and general-purpose.

In contrast, ELL’s storage cost is highly sensitive to the distribution of non-zero elements. Although it compresses the matrix, it requires zero padding to maintain uniform row lengths. When rows have similar lengths, ELL performs comparably to CSR; however, for irregular matrices, its storage cost grows significantly due to fixed row block sizes.

4.3.2. SpMV Performance Analysis

To evaluate the performance of the proposed SRB-ELL format, we conduct full-system simulations in gem5, comparing it with traditional ELL and CSR formats under both memory and SPM environments. The system configuration is shown in Table 1.

Figure 6 illustrates the speedup of SRB-ELL over the ELL format. Across all tested matrices, SRB-ELL achieves a maximum speedup of 914.1× under standard memory, primarily due to its avoidance of excessive zero padding and redundant computations. ELL’s strict layout requires padding to the maximum row length, leading to unnecessary operations and increased memory access. In contrast, SRB-ELL stores only non-zero elements and reorganizes rows into sorted blocks, significantly reducing both computation and memory traffic.

When SPM is used to store the frequently accessed vector x, the performance of SRB-ELL improves further. As shown in Figure 6a,b, the maximum speedup reaches 927.4×, and the average speedup improves from 9.02× (in memory) to 9.05× (with SPM). This demonstrates the advantage of combining optimized data layout with conflict-free local memory.

We also compare SRB-ELL with the CSR format, which is efficient in storage but difficult to vectorize due to indirect memory accesses. As shown in Figure 7, SRB-ELL achieves an average speedup of 1.19× and a maximum of 1.48× compared to CSR under memory. The improved performance stems from SRB-ELL’s regular memory access pattern, which better exploits vector units and improves cache utilization.

In some cases, the performance gap is narrow or slightly negative (minimum speedup 0.95×), particularly for small and uniformly structured matrices. Here, the benefits of vectorization are offset by SRB-ELL’s additional metadata overhead (e.g., row_pos, row_len arrays).

Under SPM conditions (Figure 7a,b), the performance advantage of SRB-ELL remains, with an average speedup of 1.05×. Although SPM mitigates memory contention for both formats, SRB-ELL continues to benefit from its vector-friendly layout and reduced cache miss rate.

Furthermore, cache miss statistics that show in Figure 8, on average, the number of cache misses for ELL is 31.76× (memory) and 42.73× (SPM) higher than SRB-ELL. This confirms that SRB-ELL’s compact and regular layout significantly improves memory locality and reduces contention, especially in memory-bound computations. Figure 8c,d shows that CSR experiences 3.77× (memory) and 8.26× (SPM) more cache misses than SRB-ELL.

5. Conclusions

SpMV suffers from irregular memory accesses that cause severe cache conflicts and limit vectorization efficiency on modern architectures. To address this, we propose SRB-ELL, a new sparse matrix format derived from ELL, specifically designed for efficient vectorization. SRB-ELL organizes non-zero elements into row blocks sorted by block size, reducing load imbalance and eliminating unnecessary zero padding, which improves SIMD utilization. To further mitigate the cache conflicts caused by irregular access to the input vector x, we leverage scratchpad memory (SPM)—a low-latency, software-managed memory that offers precise control over data placement and avoids cache contention. In our design, vector x is allocated in SPM to reduce access conflicts during computation. We integrate SPM into a custom processor architecture in the gem5 simulator and evaluate the SVE-vectorized SpMV algorithm using 2562 sparse matrices from real-world applications. Experimental results demonstrate that our approach significantly improves performance over conventional formats, achieving up to 1.48× speedup and an average of 1.19× compared to a vectorized CSR SpMV.