System-on-chip, data processing method, system-on-chip initialization method and computing device

Abstract

The invention provides a system-on-chip, a data processing method, a system-on-chip initialization method and computing equipment. Wherein the system on chip comprises a vector processing unit and an on-chip storage unit, the vector processing unit and the on-chip storage unit are connected through an on-chip interconnection network, and the vector processing unit comprises a scalar unit and a vector unit; the scalar unit and the vector unit are connected with the on-chip interconnection network through a first path; the vector unit and the on-chip interconnection network are connected through a second path; wherein the path bandwidth of the second path is higher than that of the first path. According to the method, the processing bottleneck caused by insufficient data access bandwidth in vector calculation is solved in a targeted manner, and the data throughput capacity and calculation efficiency of the vector unit are remarkably improved on the basis of not changing the original communication path of the scalar unit, so that the overall performance of the system on chip is optimized.

Description

Technical Field

[0001] This specification relates to the technical field of computer architecture, and in particular to a system-on-a-chip, data processing, system-on-a-chip initialization method, and computing device. Background Technology

[0002] With the development of heterogeneous computing and customized processor technologies, in order to meet the urgent demand for parallel processing capabilities in data-intensive applications represented by artificial intelligence (AI), vector processing units (VPUs) using the RISC-V Vector Extension (RVV) instruction set have become key components for achieving high-performance computing.

[0003] Currently, vector processing units use a set of fixed vector registers as their core cache, temporarily storing intermediate results during task execution. When the amount of data temporarily stored in the vector registers exceeds the register capacity, a register overflow mechanism is triggered, shifting some data out. Existing general architectures typically place the overflow region of vector data and scalar data together in a unified on-chip storage unit, managed by a shared cache mechanism.

[0004] However, the on-chip storage and cache management are primarily designed for scalar access, and its storage structure and access bandwidth are insufficient to effectively meet the high-bandwidth, contiguous block data exchange requirements generated by frequent overflows in vector data scenarios. This makes the data path between the vector processing unit and the on-chip storage unit a significant performance bottleneck, specifically manifested as insufficient available bandwidth and excessively high data access latency. Therefore, the existing architecture suffers from inefficient data exchange between the vector unit and on-chip storage when dealing with register overflows, severely limiting vector computation efficiency. Summary of the Invention

[0005] In view of the above, embodiments of this specification provide a system-on-a-chip. One or more embodiments of this specification also relate to a data processing method, a system-on-a-chip initialization method, a computing device, a computer-readable storage medium, and a computer program product, to address the technical deficiencies existing in the prior art.

[0006] According to a first aspect of the embodiments of this specification, an on-chip system is provided, including a vector processing unit and an on-chip storage unit, wherein the vector processing unit and the on-chip storage unit are connected through an on-chip interconnection network, and the vector processing unit includes a scalar unit and a vector unit. Scalar units and vector units are connected to the on-chip interconnect network via a first path; The vector unit and the on-chip interconnect network are connected via a second path; The bandwidth of the second path is higher than that of the first path.

[0007] According to a second aspect of the embodiments of this specification, a data processing method is provided, applied to a compiler of the above-described on-chip system, comprising: Determine if the current function is at risk of vector register overflow; If so, execute the dual-stack management mode, including: Divide the on-chip storage unit into a scalar stack space for storing scalar overflow data and a vector stack space for storing vector overflow data; When a scalar unit's register overflows, the overflowing scalar data is written to the scalar stack space via a shared buffer. When the vector register of a vector unit overflows, the overflowed data is written to the vector stack space.

[0008] According to a third aspect of the embodiments of this specification, an on-chip system initialization method is provided, applied to the firmware unit of the aforementioned on-chip system, comprising: A non-cacheable region is partitioned on the on-chip storage unit as a vector stack space; Assign the base address of the vector stack space to the vector stack pointer register; A cacheable region is allocated on the on-chip storage unit as a scalar stack space; Assign the base address of the scalar stack space to the scalar stack pointer register.

[0009] According to a fourth aspect of the embodiments of this specification, a computing device is provided, comprising: Memory and system-on-a-chip; The system-on-a-chip is as described above.

[0010] According to a fifth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores a computer program / instructions that, when executed by a processor, implement the steps of the above-described data transmission method.

[0011] According to a sixth aspect of the embodiments of this specification, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described data transmission method.

[0012] In one embodiment of this specification, a system-on-a-chip (SoC) is provided, including a vector processing unit and an on-chip storage unit. The vector processing unit and the on-chip storage unit are connected via an on-chip interconnect network. The vector processing unit includes scalar units and vector units. The scalar units and vector units are connected to the on-chip interconnect network via a first path. The vector units are connected to the on-chip interconnect network via a second path. The bandwidth of the second path is higher than that of the first path.

[0013] By configuring a second path with higher bandwidth for the vector unit, while maintaining regular communication between the scalar unit and the on-chip interconnect network via the first path, the vector unit can directly exchange data at high speed with the on-chip memory unit during large-scale data-parallel computations. This design specifically addresses the processing bottleneck caused by insufficient data access bandwidth in vector computation. Without altering the original communication path of the scalar unit, it significantly improves the data throughput and computational efficiency of the vector unit, thereby optimizing the overall performance of the system-on-chip. Attached Figure Description

[0014] Figure 1 This is one of the schematic diagrams of a system-on-a-chip provided in one embodiment of this specification; Figure 2 This is a second schematic diagram of the structure of a system-on-a-chip provided in one embodiment of this specification; Figure 3 This is a flowchart illustrating a firmware element in an on-chip system according to one embodiment of this specification; Figure 4 This is a flowchart illustrating a data processing method provided in one embodiment of this specification; Figure 5 This is a stack frame structure diagram of a single-stack and dual-stack system provided in one embodiment of this specification; Figure 6 This is a schematic diagram of the execution flow of a single-stack and dual-stack system in an embodiment of this specification; Figure 7 This is a flowchart of an on-chip system initialization method provided in one embodiment of this specification; Figure 8 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0015] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0016] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0017] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0018] Furthermore, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0019] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0020] RISC-V (Reduced Instruction Set Computing - V): An open and free instruction set architecture (ISA) based on the principles of Reduced Instruction Set Computing (RISC). Its design features modularity and scalability, allowing users to select or customize basic instruction subsets and extended instruction sets according to specific application scenarios, providing extremely high flexibility for processor design.

[0021] RISC-V Vector Extension (RVV): A vector processing extension defined in the RISC-V instruction set standard. It specifies a set of vector instructions with flexibly configurable vector register lengths and numbers, designed to efficiently support data-level parallel computing. It executes Single Instruction Multiple Data (SIMD) operations by configuring a set of scalable vector registers.

[0022] Static Random-Access Memory (SRAM): A type of random access memory that stores data without needing to be refreshed as long as it is powered on. It is implemented based on flip-flop circuits and has the advantage of fast access speed, but its memory cell structure is more complex and its chip area density is relatively low.

[0023] Dynamic Random-Access Memory (DRAM): A type of random access memory that requires periodic refresh to maintain stored data. It uses capacitors to store charge to represent data, has a simple structure, high storage density, and low cost, but its access speed is usually slower than SRAM.

[0024] With the rapid development of data-intensive applications, particularly artificial intelligence, and especially with the ever-expanding scale of deep learning models and the increasing complexity of computational graphs, extremely high demands are being placed on the parallel computing and data throughput capabilities of processors. Modern reduced instruction set architectures, such as RISC-V Vector Extension (RVV), with their flexible configurable vector lengths and register sets, have spurred the design of high-performance, scalable vector processing units (VPUs), demonstrating enormous application potential in fields such as AI acceleration and scientific computing, and have become one of the important technological paths to achieving high-performance computing.

[0025] In a typical vector processor architecture, a fixed set of vector registers constitutes the core data cache of the VPU. For example, processors conforming to the RVV standard are typically configured with 32 vector registers of expandable length (e.g., 512 bits). When performing typical AI computation tasks (such as large-scale matrix multiplication or convolution operations), the compiler maps the computation task to a series of vector loading, operation, and storage instructions, and temporarily stores the intermediate results of the computation in these vector registers to minimize the latency and energy consumption of accessing off-chip memory. However, when the complexity of the computation task exceeds the hardware resource capacity, especially when the amount of data to be temporarily stored exceeds the physical capacity of the vector registers, a register overflow mechanism is triggered. At this time, the active data in some registers must be moved out and stored in the next level of memory with larger capacity but slower access speed to free up register resources for subsequent computation. At the same time, artificial intelligence requires greater vector computation power, which greatly increases the length requirements of vector computation. However, the cache line size of a typical CPU is 64 bytes. If the length of a single vector register is greater than 64 bytes, then using a buffer overflow vector register will result in poor performance.

[0026] In existing general or scalar optimized architectures, to simplify the design, the overflow areas of scalar data and vector data are usually placed together in on-chip storage units managed by a unified cache hierarchy, and overflow management is usually carried out through a shared cache.

[0027] However, the on-chip storage and cache management are primarily designed for scalar access, and its storage structure and access bandwidth are insufficient to effectively meet the high-bandwidth, contiguous block data exchange requirements generated by frequent overflows in vector data scenarios. This makes the data path between the vector processing unit and the on-chip storage unit a significant performance bottleneck, specifically manifested as insufficient available bandwidth and excessively high data access latency. Therefore, the existing architecture suffers from inefficient data exchange between the vector unit and on-chip storage when dealing with register overflows, severely limiting vector computation efficiency.

[0028] Therefore, under existing technical solutions, the data path between the vector processing unit and the on-chip storage unit often becomes a serious system performance bottleneck when dealing with frequent register overflow scenarios. Insufficient available bandwidth and excessively high data access latency cause the vector computing unit to frequently be in a "data starvation" waiting state, preventing it from fully utilizing its powerful parallel computing capabilities. This bottleneck effect is particularly amplified in computationally intensive workloads such as AI training and inference, severely restricting the overall system's energy efficiency and throughput.

[0029] In summary, how to effectively overcome the problem of low data exchange efficiency between vector processing units and on-chip storage units caused by register overflow, thereby alleviating the bandwidth bottleneck and access latency caused by overflow data transfer, has become a key technical challenge that needs to be addressed to improve the execution efficiency of vector processors, especially for data-intensive applications for AI computing.

[0030] To address the aforementioned issues, this specification provides a system-on-a-chip (SoC) that resolves the processing bottleneck caused by insufficient data access bandwidth in vector computation. Without altering the original communication path of the scalar unit, it significantly improves the data throughput and computational efficiency of the vector unit, thereby optimizing the overall performance of the SoC.

[0031] This specification also relates to a data processing method, an on-chip system initialization method, a computing device, a computer-readable storage medium, and a computer program product, which are described in detail in the following embodiments.

[0032] See Figure 1 , Figure 1 This specification shows one of the structural schematic diagrams of a system-on-a-chip provided in an embodiment of the present specification. The system-on-a-chip 10 includes a vector processing unit 110 and an on-chip storage unit 120. The vector processing unit 110 and the on-chip storage unit 120 are connected through an on-chip interconnect network 130. The vector processing unit 110 includes a scalar unit 1110 and a vector unit 1120. Scalar unit 1110 and vector unit 1120 are connected to on-chip interconnect network 130 via a first path; The vector unit 1120 and the on-chip interconnect network 130 are connected via a second path; The bandwidth of the second path is higher than that of the first path.

[0033] The System-on-Chip (SoC) 10 is a computing system integrated on a chip, including processing units, storage units, and interconnect structures. Through on-chip integration, the SoC 10 achieves high-efficiency, low-latency data processing and transmission. For example, an AI chip for vision processing can perform image recognition tasks within the chip itself.

[0034] The vector processing unit 110 is a processing unit that supports vector instruction execution, comprising a scalar unit 1110 and a vector unit 1120. The vector processing unit 110 is specifically designed for data-parallel computing and can process multiple data elements simultaneously. For example, in neural network inference, the vector processing unit 110 simultaneously calculates the weighted sum of multiple locations in the feature map.

[0035] On-chip memory unit 120 is a storage medium located inside the chip, used for caching or temporarily storing data. On-chip memory unit 120 provides faster access speeds than off-chip memory, reducing data transfer latency. For example, a shared static random access memory unit is used to store the input feature maps and weight parameters for convolution operations.

[0036] The on-chip interconnect network 130 serves as the communication infrastructure connecting various functional modules within the chip. The on-chip interconnect network 130 is typically used for data exchange and coordination between modules, supporting concurrent transmission. For example, an interconnect network 130 based on the AXI (Advanced Dextensible Interface) bus protocol connects the vector processing unit 110 and the on-chip memory unit 120.

[0037] Scalar unit 1110 is the execution unit within vector processing unit 110 that processes scalar instructions, operating on a single data element at a time. Scalar unit 1110 is typically used for scalar tasks such as program flow control and address calculation. For example, in matrix multiplication, scalar unit 1110 calculates the loop index and determines the loop termination condition.

[0038] Vector unit 1120 is the execution unit in vector processing unit 110 that processes vector instructions and can operate on multiple data elements in parallel. Vector unit 1120 contains multiple parallel computing channels, making it suitable for large-scale data parallel operations. For example, in vector addition, vector unit 1120 simultaneously calculates the sum of all corresponding elements in two 512-bit vectors.

[0039] The first path is a communication path connecting scalar unit 1110, vector unit 1120, and on-chip interconnect network 130, and has a low path bandwidth. The first path is typically used to transmit instructions, scalar data, and control information. For example, scalar unit 1110 loads program instructions from on-chip memory unit 120 through the first path, and vector unit 1120 accesses scalar operands through the first path.

[0040] The second path is a dedicated communication path connecting the vector unit 1120 and the on-chip interconnect network 130, and has a high bandwidth. The second path is dedicated to the transmission of large data blocks by the vector unit 1120, such as overflow data from the vector register. For example, when the vector register capacity is insufficient, the vector unit 1120 writes a continuous 512-bit data block to the on-chip memory unit 120 at high speed through the second path.

[0041] The vector processing unit 110 and the on-chip storage unit 120 are connected via an on-chip interconnect network 130. One optional implementation is that the on-chip interconnect network 130 adopts a shared bus structure, with the vector processing unit 110 and the on-chip storage unit 120 connected to the bus as master and slave devices. Another optional implementation is that the on-chip interconnect network 130 adopts a crossbar to provide multiple parallel data channels for the vector processing unit 110 and the on-chip storage unit 120. Yet another optional implementation is that the on-chip interconnect network 130 adopts a packet-switched Networks on Chip (NoC) topology, such as a 2D mesh structure, to achieve scalable high-bandwidth interconnect.

[0042] Scalar unit 1110 and vector unit 1120 are connected to on-chip interconnect network 130 via a first path. One optional implementation is that the first path is a low-bandwidth shared bus, and scalar unit 1110 and vector unit 1120 access it in a time-sharing manner through a bus arbiter. Another optional implementation is that the first path includes independent instruction path and data path, used to transmit instructions, scalar data and vector data respectively. Yet another optional implementation is that the first path is connected to on-chip interconnect network 130 through a unified interface controller, which handles AXI protocol conversion and request scheduling.

[0043] The vector unit 1120 and the on-chip interconnect network 130 are connected via a second path. One possible implementation is that the second path is a dedicated data bus dedicated to the transmission of large data blocks by the vector unit 1120. Another possible implementation is that the second path includes multiple parallel read and write channels, supporting the vector unit 1120 to perform read and write operations simultaneously. Yet another possible implementation is that the second path is connected through a high-bandwidth Direct Memory Access (DMA) engine, which can perform data transfer tasks independently of the vector unit 1120.

[0044] For example, the vector processing unit includes a scalar unit and a vector unit. The scalar unit executes scalar instructions, and the vector unit has 32 512-bit vector registers for executing SIMD instructions. The on-chip memory is a large block of high-bandwidth, low-latency static random access memory. The on-chip interconnect network uses a crossbar matrix to provide multiple parallel data paths for the vector processing unit and the on-chip memory. The scalar unit is connected to the on-chip interconnect network via a first path of a lower-bandwidth, 64-bit bus. The vector unit is directly connected to the on-chip interconnect network via a second path of a high-bandwidth, 512-bit bus, enabling high-speed access to the static random access memory.

[0045] In a deep learning convolution operation example, vector unit 1120 needs to compute the convolution of a large feature map with a weight kernel. Due to the limited capacity of the vector registers, some intermediate results need to overflow into on-chip memory unit 120 during the computation. At this time, vector unit 1120 writes a set of consecutive data blocks from the vector registers into the reserved buffer of on-chip memory unit 120 in a single clock cycle through a high-bandwidth second path. Simultaneously, scalar unit 1110 reads the loop control variable from on-chip memory unit 120 through a first path, and the two operations are performed in parallel without conflict. When subsequent computations require this overflowed data, vector unit 1120 reads the data back through the second path, thereby significantly reducing the data starvation cycle of the vector unit and improving the overall throughput of the convolution operation.

[0046] In this embodiment, by additionally configuring a second path with higher bandwidth for the vector unit 1120, while maintaining regular communication between the scalar unit 1110 and the on-chip interconnect network 130 via the first path, the vector unit 1120 can directly exchange data at high speed with the on-chip storage unit 120 using the high-bandwidth path when performing large-scale data parallel operations. This design specifically addresses the processing bottleneck caused by insufficient data access bandwidth in vector computation, significantly improving the data throughput and computational efficiency of the vector unit 1120 without changing the original communication path of the scalar unit, thereby optimizing the overall performance of the system-on-chip 10.

[0047] In one optional embodiment of this specification, the vector processing unit 110 further includes a shared cache 1130; Scalar unit 1110 and vector unit 1120 are connected to shared cache 1130 via a first path, and shared cache 1130 is connected to on-chip interconnect network 130 via the first path.

[0048] The shared cache 1130 is used to store frequently accessed scalar instructions, scalar data, and small-granularity vector data from scalar units 1110 and vector units 1120. It aims to reduce access latency to on-chip memory units 120 by leveraging the principle of cache locality. For example, in an AI chip performing image recognition, this shared cache can be used to cache scalar control variables, loop counts, and small lookup tables required for the current computation layer in a convolutional neural network, rather than storing the complete weight matrix that needs to be continuously moved.

[0049] Scalar unit 1110 and vector unit 1120 are connected to shared cache 1130 via a first path. One optional implementation is that scalar unit 1110 and vector unit 1120 access shared cache 1130 through a shared low-latency bus, with the access order determined by arbitration logic. Another optional implementation is that scalar unit 1110 and vector unit 1120 are connected to shared cache 1130 through independent ports with the same bandwidth, supporting concurrent access. Yet another optional implementation is that scalar unit 1110 and vector unit 1120 access shared cache 1130 through a unified load / store unit, merging and scheduling access requests.

[0050] The shared cache 1130 and the on-chip interconnect network 130 are connected through a first path. One optional implementation is that the shared cache 1130 is connected to the on-chip interconnect network 130 through a unified system bus interface; another optional implementation is that the shared cache 1130 is directly connected as a master / slave device node of the on-chip interconnect network 130; yet another optional implementation is that the shared cache 1130 is connected to the on-chip interconnect network 130 through a dedicated cache proxy controller, which manages cache coherency protocols and external communication.

[0051] For example, the vector processing unit 110 includes a scalar unit 1110, a vector unit 1120, and a shared cache 1130. The scalar unit 1110 and the vector unit 1120 are connected to the shared cache 1130 via a 64-bit wide first path. The shared cache 1130 is used to cache scalar instructions and frequently accessed scalar data. The shared cache 1130 itself is connected to the on-chip interconnect network 130 via a 64-bit wide bus belonging to the same first path, for handling access to the on-chip memory unit 120 when a cache miss occurs. Meanwhile, the vector unit 1120 additionally has a separate 512-bit high-bandwidth second path, directly connected to the on-chip interconnect network 130, dedicated to large data block overflow operations of the vector register.

[0052] In an example of matrix multiplication, scalar unit 1110 reads loop control variables (such as matrix dimensions) from shared cache 1130, while vector unit 1120, during computation, needs to overflow some intermediate results in its vector register (such as a 512-bit vector). For overflow operations, vector unit 1120 writes the entire 512-bit data block directly to a specific area of ​​on-chip memory unit 120 in one cycle via a high-bandwidth second path. For a scalar operand that scalar unit 1110 needs to read but is not in shared cache 1130, the request is forwarded through shared cache 1130 to on-chip interconnect network 130 and retrieved from on-chip memory unit 120, but this process uses the lower-bandwidth first path.

[0053] In the embodiments described in this specification, a shared cache is introduced as a unified front-end interface for scalar and vector units to access on-chip storage. This shared cache, connected via a first path, effectively manages cache access to scalar data, instructions, and small-granularity vector data, simplifying system design. Simultaneously, the vector unit retains an independent high-bandwidth second path directly connected to the on-chip interconnect network. This allows vector data blocks to bypass the access bottleneck and protocol overhead of the shared cache and directly perform high-speed, block-level data transfer with the on-chip storage unit when register overflows occur during large-scale vector computations. This avoids the impact and contention of high-bandwidth vector data on shared cache resources and ensures low-latency response for scalar data, thereby synergistically improving the overall data supply efficiency and computational resource utilization of the vector processing unit when performing complex computational tasks.

[0054] In one optional embodiment of this specification, the shared cache 1130 is a second-level cache.

[0055] The Level 2 cache (L2 cache) is a cache level in the processor's memory hierarchy, situated between the processor core's private Level 1 cache (L1 cache) and on-chip memory unit 120. The L2 cache typically has a larger capacity than the Level 1 cache, and its access speed is slower than the Level 1 cache but faster than main memory, aiming to reduce the frequency and average latency of main memory accesses. For example, in System-on-Chip 10, this L2 cache can be shared by scalar unit 1110 and vector unit 1120 to cache instructions, scalar data, and frequently accessed small data blocks, such as frequently used bias parameters or scaling factors in a neural network.

[0056] In this embodiment, the shared cache 1130 is specifically implemented as a secondary cache, establishing a clear and efficient multi-level storage hierarchy within the system-on-chip 10. The scalar unit 1110 and the vector unit 1120 are connected to the secondary cache via a first path. This allows frequently accessed instructions with good locality and small-granularity data (such as scalar control variables and small constant tables) to be effectively captured by the secondary cache, resulting in low-latency access. Simultaneously, the vector unit 1120 bypasses this secondary cache hierarchy via an independent high-bandwidth second path, directly interacting with the on-chip storage unit 120 for large data blocks. This avoids competition and interference between different types of data streams on a single path and cache hierarchy, thereby achieving better utilization of computing resources and storage bandwidth at the system level.

[0057] In one optional embodiment of this specification, the on-chip storage unit 120 includes at least one of a static random access memory unit and a dynamic random access memory unit.

[0058] For example, an SRAM region in the on-chip memory unit 120 can be configured as a dedicated buffer for overflow data of the vector register, allowing the vector unit 1120 to access the data at high speed through a high-bandwidth second path.

[0059] For example, in System-on-Chip 10, a large-capacity on-chip storage cell 120 can be implemented using embedded DRAM (eDRAM) to store the weight parameters and intermediate activation values ​​of the entire neural network model.

[0060] For example, a low-latency, high-bandwidth dedicated storage area for vector overflow can be constructed using SRAM, which is directly connected to the vector unit 1120 through a second path to meet its burst bandwidth requirements; at the same time, a large-capacity general-purpose data pool can be constructed using eDRAM, which serves the scalar unit 1110 and the vector unit 1120 through the on-chip interconnect network 130, providing sufficient on-chip storage space in a flexible manner.

[0061] In the embodiments of this specification, when the on-chip storage unit 120 includes a static random access memory unit, its high-speed access characteristics can be utilized to configure a specific area as a dedicated buffer for vector register overflow. The vector unit 1120 directly accesses the buffer through a high-bandwidth second path, achieving low-latency, high-throughput transfer of large-scale, continuous vector data blocks, thereby effectively solving the data supply bottleneck in register overflow scenarios. When the on-chip storage unit 120 includes a dynamic random access memory unit, its high-density characteristics can be utilized to construct a large-capacity on-chip data pool within a limited chip area for storing massive amounts of program data, model parameters, and intermediate results, reducing the need to access slow off-chip storage and improving the efficiency of the on-chip system 10.

[0062] Corresponding to the above embodiments of multiple system-on-a-chip, Figure 2 This specification shows a second schematic diagram of the structure of a system-on-a-chip provided in one embodiment, as follows: Figure 2 As shown: The system-on-chip 10 includes a vector processing unit 110, a static random access memory unit, and a shared cache 1130. The vector processing unit 110 and the static random access memory unit are connected through a cross switch matrix. The vector processing unit 110 includes a scalar unit 1110 and a vector unit 1120. Scalar unit 1110 and vector unit 1120 are connected to shared buffer 1130 via a first path, and shared buffer 1130 is connected to crossbar switch matrix via a first path. Vector unit 1120 and crossbar switch matrix are connected via a second path.

[0063] Adapting to the differences in bandwidth and whether access is via cache between the first and second paths, the storage location and access path of different types of data are optimized by correspondingly dividing the address space of the on-chip storage unit 120 into cacheable and non-cacheable areas.

[0064] In one optional embodiment of this specification, the on-chip storage unit 120 is divided into a scalar stack space for storing scalar overflow data and a vector stack space for storing vector overflow data. The scalar stack space is located in the cacheable area of ​​the on-chip storage unit 120, while the vector stack space is located in the non-cacheable area of ​​the on-chip storage unit 120.

[0065] Scalar overflow data refers to scalar data that needs to be temporarily shifted out and stored in on-chip memory unit 120 when the scalar register capacity of scalar unit 1110 is insufficient. Scalar overflow data typically has random, non-contiguous, and fine-grained access characteristics, such as local variables, function call contexts, and address pointers in a program. For example, when executing a nested loop, the loop counter value of the inner loop may need to temporarily overflow to free up the scalar register for other computations.

[0066] Vector overflow data refers to vector data that needs to be temporarily shifted out and stored in on-chip memory unit 120 when the vector register capacity of vector unit 1120 is insufficient. Vector overflow data typically manifests as a large, contiguous set of data with high spatial locality, such as a submatrix in matrix operations or a large intermediate result vector in vector operations. For example, when performing a large matrix multiplication, a 512-bit wide intermediate result vector (containing 16 single-precision floating-point numbers) may need to overflow from the vector register.

[0067] The scalar stack space is a logical storage area allocated within on-chip storage unit 120 for storing scalar overflow data. The scalar stack space typically follows a last-in-first-out (LIFO) stack memory management method, and its physical address resides within the cacheable area of ​​the on-chip storage unit. For example, the compiler can allocate a private scalar stack space for each thread within on-chip storage unit 120 to manage register saving and restoring during function calls.

[0068] The vector stack space is a logical storage area allocated within on-chip memory cell 120 for storing vector overflow data. The vector stack space typically employs stack-based management, but its physical address is mapped to a non-cacheable region of the on-chip memory cell to support deterministic, high-bandwidth direct access. For example, in System-on-Chip 10, a contiguous address space in SRAM can be allocated as the vector stack space, dedicated to register overflow operations of vector cell 1120.

[0069] A cacheable region is an address space range within on-chip storage unit 120 that is accessible or requires access via a shared cache 1130 (such as a L2 cache). Read and write requests to the cacheable region are first sent to the shared cache 1130, leveraging the locality advantage of the shared cache 1130 to reduce access latency. For example, if the address range containing the scalar stack space is marked as cacheable, access to it by scalar unit 1110 will be routed through the L2 cache.

[0070] The non-cacheable region is the address space range in on-chip memory unit 120 that bypasses all cache levels and is directly accessed by the requester. Read and write requests to the non-cacheable region do not go through the cache and interact directly with the storage medium, thereby avoiding the overhead of cache lookup, replacement, and consistency, providing deterministic access latency, and is suitable for large-scale continuous data block transfers. For example, the SRAM address range where the vector stack space is located is marked as non-cacheable, and read and write operations on it by vector unit 1120 through the high-bandwidth second path are direct.

[0071] For example, in an AI acceleration chip instance supporting RVV extensions, the on-chip memory unit 120 of the system-on-chip 10 includes SRAM. This SRAM is divided into different regions in its address space. One portion of the address space is marked as a cacheable region by the operating system or compiler, and a scalar stack space is allocated within this region for each running thread to store scalar overflow data such as function call context and local variables. Access requests to this region from the scalar unit 1110 are sent to the shared L2 cache via a first path. Another contiguous portion of the SRAM address space is marked as a non-cacheable region and specifically designated as a vector stack space.

[0072] In this embodiment, a collaborative optimization architecture for register overflow problems in scalar and vector hybrid computation is constructed by physically and logically separating the scalar stack space storing scalar overflow data and the vector stack space storing vector overflow data, and configuring them respectively in the cacheable and non-cacheable regions of the on-chip storage unit 120. This architecture utilizes the matching relationship between hardware paths and storage attributes: the scalar stack space accesses the cacheable region of the on-chip storage unit 120 through the first path of the shared cache 1130, continuing the traditional advantage of reducing access latency by utilizing cache locality and maintaining compatibility with existing scalar processing. The vector stack space directly accesses the non-cacheable region of the on-chip storage unit 120 through the high-bandwidth second path, providing deterministic, cache-free, ultra-high bandwidth transport capability for vector data blocks, solving the data supply bottleneck in vector register overflow scenarios. The overflow / recovery operation of vector data is greatly accelerated due to its exclusive high-bandwidth direct connection path, while the low-latency response of scalar data is guaranteed. The two operate independently and in parallel, jointly improving the utilization rate of the computing unit. Secondly, in terms of storage management, the complete decoupling of the scalar stack and the vector stack allows the compiler or runtime system to allocate and manage stack space for the two independently and on demand, avoiding memory fragmentation caused by mixing scalar and vector objects of different sizes and alignment requirements in the traditional unified stack, thus optimizing the utilization of on-chip storage resources.

[0073] In one optional embodiment of this specification, the scalar stack space is provided with a scalar stack pointer, and the vector stack space is provided with a vector stack pointer. The scalar stack pointer and the vector stack pointer are independent of each other.

[0074] A scalar stack pointer (SP) is a specific memory location within a dedicated hardware register or memory unit that points to the current top address of the scalar stack space. When a scalar register overflows, the scalar unit (or the memory management unit serving it) uses the scalar stack pointer as the target address to save the data and updates the scalar stack pointer after the operation. When data needs to be restored, it is also accessed using the scalar stack pointer. For example, in a triple nested loop of matrix multiplication, the scalar unit uses the scalar stack pointer to manage the overflow and reclamation of the inner loop counter k, ensuring correct context when exiting and re-entering the inner loop.

[0075] The Vector Stack Pointer (VSP) is a specific storage location within a dedicated hardware register or memory unit that points to the current top address of the vector stack space. The vector stack pointer is independent of the scalar stack pointer and is specifically used to manage the storage location of vector overflow data within the vector stack space. When a vector unit executes an overflow / reclaim instruction, it uses and automatically updates this pointer. For example, in the matrix multiplication calculation mentioned above, when the vector register needs to store an intermediate result vector, the vector unit uses the vector stack pointer to push the data onto the vector stack space and uses the same pointer to pop it when needed later.

[0076] For example, consider an instance performing a large matrix multiplication (C=A*B). Scalar unit 1110 controls a triple loop (i, j, k), and its scalar stack pointer SP manages the loop variables i, j, k, and the scalar context, including the base address register. Vector unit 1120 performs the core vector multiplication-addition operation. During computation, after the vector unit processes a row of matrix A and a partial sum of a column of matrix B, the resulting 512-bit intermediate result vector needs to temporarily overflow to free up registers for new data. At this time, vector unit 1120 uses the address pointed to by its own vector stack pointer VSP (located in the non-cacheable area of ​​SRAM) as the target and writes the entire 512-bit vector through a high-bandwidth second path. After writing, the vector stack pointer VSP is automatically incremented. Simultaneously, scalar unit 1110 may need to overflow the current loop variable k due to function calls or insufficient registers. It writes the value of k to the address pointed to by SP (located in the cacheable area of ​​SRAM) through the scalar stack pointer SP. This access is via the first path and shared cache 1130. The scalar stack pointer SP is then updated. Throughout the computation, the scalar stack pointer SP and the vector stack pointer VSP are maintained and updated independently, managing the growth and rollback of different stack spaces in the cacheable and uncacheable regions, respectively, enabling the overflow and reclamation operations of the scalar control flow and the vector data flow to be performed independently and in parallel.

[0077] In the embodiments described in this specification, by configuring independent scalar stack pointers and vector stack pointers for the scalar stack space and vector stack space respectively, complete decoupling and independent management of the two overflow data stacks are achieved. The independence of these two pointers ensures that operations on their respective stack spaces do not require synchronization or coordination overhead, eliminating potential pointer race conditions. Since the access and management of the two stacks are independent in terms of data flow and control flow, deep interleaving and rearrangement of operation instructions for the scalar stack, operation instructions for the vector stack, and other dependent computation instructions can be performed, improving instruction-level parallelism. This allows the saving / reclaiming of the scalar context and the overflow / filling of the vector registers to be executed concurrently, thereby further amplifying the advantages of the heterogeneous path architecture. The data path separation is guaranteed from the control mechanism perspective, significantly improving the overall efficiency and performance of the system in handling register overflows in complex computational tasks.

[0078] In one optional embodiment of this specification, the scalar unit 1110 includes a scalar stack pointer register for storing a scalar stack pointer and a vector stack pointer register for storing a vector stack pointer, wherein the vector stack pointer register is a save register for the called function. The system-on-chip 10 also includes a firmware unit, which initializes the vector stack space in the non-cacheable region and configures the base address to the vector stack pointer register before the vector processing unit 110 executes the function, and initializes the scalar stack space in the cacheable region and configures the base address to the scalar stack pointer register.

[0079] The scalar stack pointer register is a hardware register integrated within scalar unit 1110, used to store and dynamically update the scalar stack pointer (SP). During scalar context switching, function calls / returns, or scalar register overflows / reclaims, its value is used to generate the target address and is automatically incremented / decremented. For example, when executing a nested function call, each time a function call occurs, scalar unit 1110 automatically saves the return address, saved registers, and other context information to the scalar stack space address pointed to by the scalar stack pointer register, and restores it from the same address upon return.

[0080] The vector stack register is a hardware register integrated within scalar unit 1110, used to store and dynamically update the vector stack pointer (VSP). When a vector register overflows or is restored, the value of the vector stack pointer register is used as the target address pointer for the vector stack space and is automatically updated. For example, when vector unit 1120 executes a vector register overflow instruction, it uses the value in the vector stack pointer register as the target address to write data to the vector stack space, and then automatically increments the register's value.

[0081] The Callee Saved Register is a type of register that, in a function calling convention, is saved by the called function (Callee) before modifying its value and restored before returning to the calling function (Caller). The Callee Saved Register is used to save the caller's context during a function call, ensuring that the caller's program state is not corrupted after the function returns. The Vector Stack Pointer Register is designed as a Callee Saved Register, needing to be saved and restored at the function call boundary. For example, in a scenario of calling an RVV vector function, the called vector function needs to save the current value of the Vector Stack Pointer Register (VSP) before execution and restore this value before returning to ensure that the caller's vector stack state is not corrupted.

[0082] The firmware unit is a read-only or updatable piece of software code and its execution environment located in the system-on-a-chip 10, running in privileged mode, and used for low-level system initialization and hardware configuration. The firmware unit runs before the operating system or application starts and is used for basic configuration of hardware resources, such as address mapping, peripheral initialization, and settings for specific functional units. For example, after the system-on-a-chip 10 is powered on or reset, the firmware unit executes first to initialize the memory controller, configure the interrupt vector table, and prepare the operating environment for the vector processing unit 110.

[0083] The base address is the starting address allocated to the stack space in the memory address space. It serves as the reference point for accessing this memory region, and subsequent access addresses are typically calculated by adding an offset to the base address. For example, if the firmware unit allocates a contiguous region in SRAM as a vector stack space, the starting address of this region is the base address of the vector stack space, and the initial value of the vector stack pointer register (VSP) is set to this base address. Similarly, if the firmware unit allocates a contiguous region in SRAM as a scalar stack space, the starting address of this region is the base address of the scalar stack space, and the initial value of the scalar stack pointer register (SP) is set to this base address.

[0084] Figure 3 This specification illustrates a flowchart of a firmware element in an on-chip system according to one embodiment, as shown below. Figure 3 As shown: During compilation: A fixed-size region is partitioned into static random access memory units to serve as a vector stack space.

[0085] During runtime (vector processing unit side): Assign the base address of the vector stack to the vector stack pointer register; The vector processing unit receives information about the function to be executed; Determine if there is a risk of vector register overflow in the current function; if so, execute dual-stack management mode.

[0086] For example, before the vector processing unit 110 executes a function containing RVV vector operations, the firmware element is executed first. The firmware element locates and allocates a contiguous, sufficiently large memory region in the address space of the on-chip memory unit 120 (such as SRAM), and configures the region's attributes as non-cacheable. Subsequently, the firmware element writes the starting address of this region, i.e., the base address of the vector stack space, into the vector stack pointer register (VSP) inside the vector unit 1120, completing the initialization of the vector stack. Simultaneously, the scalar stack pointer register (SP) inside the scalar unit 1110 is also initialized by the firmware element in the cacheable region. When a vector function is called, since the vector stack pointer register (VSP) belongs to the called function's callee saved register, the caller first saves the current VSP value to its scalar stack. Then, the callee uses the newly initialized VSP value (which points to the newly allocated vector stack space) to manage vector register overflow within this function. During function execution, vector unit 1120 performs vector calculations. When a register overflow occurs, it uses its internal VSP register value as an address and writes the data directly into the vector stack space in SRAM via a high-bandwidth second path. Before the function returns, the called party restores the VSP value saved by the caller. Throughout the entire process, the allocation and management of the scalar context and vector stack space are completely independent, accomplished collaboratively by hardware registers and firmware components.

[0087] In the embodiments described in this specification, a complete and efficient hardware-firmware collaborative vector stack management mechanism is constructed by setting dedicated scalar stack pointer registers and vector stack pointer registers in scalar unit 1110 and vector unit 1120, respectively, and introducing firmware units at the system level for vector stack space initialization and base address configuration. Dedicated pointer registers and fast address generation logic are provided for vector stack operations at the hardware level, ensuring the hardware execution efficiency of vector overflow / recovery operations. Defining the vector stack pointer register as a save register for called functions follows standard function calling conventions, ensuring the correct saving and restoration of the vector stack state during function calls, making the vector stack safe and reliable for function calls.

[0088] Corresponding to the above-described system-on-a-chip embodiments, this specification also provides embodiments of data processing methods. Figure 4 A flowchart illustrating a data processing method provided in one embodiment of this specification is shown. Figure 4 As shown, this method is applied to the compiler of the above-mentioned on-chip system and includes: Step 402: Determine if there is a risk of vector register overflow in the current function.

[0089] A compiler is a program on a system-on-a-chip (SoC) that translates a high-level programming language or intermediate representation into the instruction set of the target machine. Compilers analyze source code, optimize it, and generate low-level code that can be executed on the SoC. For example, a compiler optimized for the RISC-V RVV extension can compile source code containing vector inline functions into machine code that can be executed on vector processing units.

[0090] The current function is the unit of target code that the compiler is currently compiling, typically representing a callable subroutine or procedure. During compilation, the compiler performs control flow analysis, register allocation, and stack frame layout at the function level. For example, in a deep learning inference library, a function conv2d_kernel() that performs convolution calculations is the "current function".

[0091] The risk of vector register overflow refers to the possibility, determined during compile-time analysis of the current function, that the total amount of temporary vector data required during execution may exceed the physical capacity of the vector registers. This risk is the basis for the compiler's decision to adopt a dual-stack management mode and allocate vector stack space. For example, static analysis might reveal that the `conv2d_kernel().` function contains multiple nested loops, each potentially generating a large number of intermediate vector results. These results may not all be able to be stored in the 32 vector registers, thus indicating a high risk of overflow.

[0092] To determine if a function is at risk of vector register overflow, one possible approach is to parse the function to obtain intermediate results and then determine if it is at risk. Another possible approach is to obtain historical parsing information of the function and then determine if it is at risk based on this information (such as the number of vector register overflows, the amount of overflowed data, and the depth of the critical loop that triggered the overflow). Yet another possible approach is to parse the function to obtain its control access mode and then determine if it is at risk. No further limitations are specified here.

[0093] For example, when compiling the matrix block multiplication function of matmul_block, the compiler performs the following analysis: The function contains three nested loops that compute sub-blocks of two input matrices. The compiler analyzes the generated instruction sequences for vector loading, multiplication-addition, and reduction, and simulates the register allocation process. It determines that in one iteration of the innermost loop, the number of active intermediate vector results (such as accumulator vectors, input vectors loaded from memory, etc.) that need to be maintained simultaneously reaches 40, while the total number of vector registers is only 32. Therefore, the compiler determines that the matmul_block function will experience vector register overflow during execution, posing a risk of vector register overflow.

[0094] In step 402, by determining whether the current function is at risk of vector register overflow, a decision is made on whether to enable dual-stack management mode.

[0095] Step 404: If yes, execute the dual-stack management mode, including: dividing the on-chip storage unit into a scalar stack space for storing scalar overflow data and a vector stack space for storing vector overflow data; when the register of a scalar unit overflows, write the scalar overflow data into the scalar stack space through a shared cache; when the vector register of a vector unit overflows, write the vector overflow data into the vector stack space.

[0096] Dual-stack management is a stack management strategy employed by the compiler during code generation. This strategy creates and manages separate stack spaces (scalar stack space and vector stack space) for scalar overflow data and vector overflow data. In dual-stack management, compiler-generated stack manipulation instructions (such as adjusting the stack pointer and saving / restoring registers) are processed separately for each stack space. For example, in a function prologue, the compiler generates instructions to adjust both the scalar stack pointer (SP) and the vector stack pointer (VSP) to allocate two stack spaces.

[0097] Scalar overflow data refers to scalar data that needs to be moved from the scalar register of the scalar unit to the scalar stack space.

[0098] Vector overflow data refers to vector data that needs to be moved from the vector register of the vector unit to the vector stack space.

[0099] The registers of a scalar unit are hardware storage units within the scalar unit used to temporarily store scalar operands and intermediate results. The number of registers in a scalar unit is limited; when active data exceeds its capacity, some data overflows into the scalar stack space. For example, the general-purpose integer registers x1-x31 in RISC-VIS.

[0100] The vector registers of a vector unit are hardware storage units within the vector unit that support SIMD operations and are used to temporarily store vector operands and intermediate results. The number and length of the vector registers in a vector unit are configurable. When the active vector data exceeds its capacity, some data overflows into the vector stack space. For example, the v0-v31 vector registers defined in the RVV extension.

[0101] For example, for the matmul_block function that is determined to have an overflow risk, the compiler proceeds to step 404 and executes the dual-stack management mode: Stack space allocation: In the generated assembly code, the compiler reserves scalar stack space in the cacheable area of ​​on-chip memory and vector stack space in the non-cacheable area. The specific size is calculated by the compiler.

[0102] Stack frame adjustment: In the function prologue, the compiler generates instructions to reduce the scalar stack pointer register (SP) by the size of the scalar stack space and the vector stack pointer register (VSP) by the size of the vector stack space. These two adjustment operations are independent instruction sequences.

[0103] Overflow / fill code generation: Within a function body, when the compiler decides to overflow a scalar temporary variable (such as the loop index k), it generates a store instruction that stores the data into the scalar stack space pointed to by the scalar stack pointer via the first path, through the shared cache. When it decides to overflow a vector temporary variable (such as the accumulator vector v8), it generates a vector store instruction that stores the data into the vector stack space pointed to by the vector stack pointer via the second path (high-bandwidth direct connection). When it is necessary to restore this data, the corresponding load instruction is generated.

[0104] Stack object offset calculation: When allocating stack space, the compiler independently calculates the offset of scalar stack objects relative to the SP and the offset of vector stack objects relative to the VSP. Because the stack space is separated, the offset calculation of vector objects no longer needs to consider the alignment padding required by the scalar objects preceding them, eliminating the computational requirements of the scalable portion and simplifying address calculation.

[0105] In step 404, a dual-stack management mode is executed, including: dividing the on-chip storage unit into a scalar stack space for storing scalar overflow data and a vector stack space for storing vector overflow data; when the register of a scalar unit overflows, the scalar overflow data is written to the scalar stack space through a shared cache; when the vector register of a vector unit overflows, the vector overflow data is written to the vector stack space. Due to the physical separation of the stack space, the multiple memory alignment operations caused by the different sizes and alignment requirements of scalar and vector objects in the traditional unified stack are eliminated, significantly reducing memory fragmentation inside the stack and improving the utilization of valuable on-chip storage units.

[0106] In the embodiments described in this specification, through deep collaboration with the hardware characteristics of the system-on-chip, data-intensive applications facing register overflow bottlenecks can generate highly optimized code through the compiler, transparently and efficiently utilizing the dedicated acceleration facilities provided by the hardware, thereby achieving a significant improvement in vector computing performance and optimization of overall execution energy efficiency at the system level.

[0107] In one optional embodiment of this specification, step 404, which involves allocating scalar stack space from the on-chip storage unit for storing scalar overflow data, includes: At the start of a function call, the parsing function determines the scalar overflow data, allocates scalar stack space from the cacheable area of ​​the on-chip memory, allocates scalar stack frames from the scalar stack space, and adjusts the scalar stack pointer. When a scalar unit's register overflows, the overflowing scalar data is written to the scalar stack space via a shared buffer, including: When a scalar unit's register overflows, the overflowed scalar data is written to the scalar stack frame in the scalar stack space via a shared buffer. When a scalar unit's register overflows, after writing the overflowed scalar data to the scalar stack space via a shared cache based on the adjusted scalar stack pointer, the process also includes: When the function call ends, the scalar stack frame is reclaimed from the scalar stack space and the scalar stack pointer is restored.

[0108] A scalar stack frame is a contiguous storage area dynamically allocated for a specific function instance within the scalar stack space during a function call. It is dedicated to storing scalar overflow data and a portion of the call context generated during the function call. Each active function call has its own independent scalar stack frame within the scalar stack space. The size of the scalar stack frame is determined at compile time or during the function call, and its lifecycle is bound to the function call.

[0109] One possible implementation of dividing scalar stack frames from the scalar stack space and adjusting the scalar stack pointer is as follows: determine the scalar offset, divide the scalar stack frames from the scalar stack space based on the scalar offset, and adjust the scalar stack pointer.

[0110] One possible implementation of reclaiming scalar stack frames from the scalar stack space and restoring the scalar stack pointer is as follows: determine a scalar offset, and based on the scalar offset, reclaim the scalar stack frames from the scalar stack space and restore the scalar stack pointer.

[0111] For example, for the matmul_block function, when the compiler executes the dual-stack management mode in step 404, the scalar stack space is managed as follows: Stack Frame Allocation: In the function preamble, the compiler calculates that the scalar stack frame size required by the function is 128 bytes. The compiler generates instructions to subtract 128 from the value of the scalar stack pointer register (SP), thereby allocating a 128-byte scalar stack frame for the current matmul_block function call in the cacheable area of ​​the on-chip memory unit. The code generated by the compiler will use the current value of the scalar stack pointer register (SP) as the base address, add the pre-calculated scalar offset, and calculate the specific address of the scalar overflow data in the scalar stack frame.

[0112] Overflow data writing: During the execution of a function, when a scalar register of a scalar unit, such as the register storing the loop variable j, needs to overflow, the data is written to that address through the first path via the shared cache.

[0113] Reclaiming stack frames: At the end of the function, after all the necessary scalar data recovery is completed, the compiler generates instructions to add 128 bytes of scalar stack frame to the value of the scalar stack pointer register (SP), thereby reclaiming the scalar stack frame allocated for this call and restoring SP to its state before the call.

[0114] In the embodiments described in this specification, independent scalar stack frames are allocated at the beginning of a function call to ensure the isolation and security of different calling instance contexts. The stack frames are precisely reclaimed and the stack pointer is restored at the end of the function call, guaranteeing the correctness and efficiency of stack space management.

[0115] The specific implementation modifications on the compiler side to support dual-stack management mode require underlying code modifications to the compiler, mainly involving the following key methods in the LLVM framework: Modified emitPrologue: In the function prologue, the compiler calculates the scalar stack size (ScalarStackSize) and the vector stack size (RVVStackSize) separately. Instructions are generated using the adjustReg method, first adjusting the scalar stack pointer (SP) downwards by ScalarStackSize, and then adjusting the vector stack pointer (VSP) downwards by RVVStackSize. This ensures that the scalar stack and vector stack are allocated independently, avoiding alignment padding overhead.

[0116] Modified emitEpilogue: At the end of the function, the mirror performs the emitPrologue operation, restoring SP and VSP to their states before the function call, ensuring that the stack space is correctly reclaimed.

[0117] The `eliminateFrameIndex` modification: During the frame index elimination phase, the compiler calculates the offset based on the stack object type (scalar or vector). For scalar stack objects, the offset is based only on the SP and a fixed offset; for vector stack objects, the offset is calculated based on the VSP, without considering the scalar stack region, simplifying address calculation and eliminating dependence on high-latency CSR instructions.

[0118] Modifications related to FP: In scenarios with frame pointers (FP), the scalar stack is based on FP, while the vector stack remains based on VSP, ensuring consistency and efficiency in offset calculations in dual-stack mode.

[0119] These modifications enable the compiler to generate highly optimized dual-stack management code, making full use of the independent paths and storage areas provided by the hardware, and significantly improving the execution efficiency of vector-intensive functions.

[0120] Among them, emitPrologue was modified as follows: In the function prologue, the compiler needs to calculate the scalar stack size and the vector stack size (RVVStackSize) separately. The scalar stack size is statically calculated based on the total amount of scalar overflow data in the current function (e.g., by analyzing local variables and register context); the vector stack size is dynamically calculated based on the number of vector registers to overflow, the vector data type, and the hardware-defined length of the vector registers (such as VLEN). Specifically, the vector stack size = number of registers to overflow × vlenb (where vlenb = VLEN / 8, representing the byte length of a single vector register).

[0121] After modification, the compiler generates an instruction sequence using the `adjustReg` method: first, it adjusts the scalar stack pointer (SP) downwards by `ScalarStackSize`, allocating scalar stack frames in the cacheable area of ​​on-chip memory; then, it adjusts the vector stack pointer (VSP) downwards by `RVVStackSize`, allocating vector stack frames in the non-cacheable area. This modification ensures that the scalar stack and vector stack are allocated independently, avoiding multiple memory alignment operations caused by mixed layouts in traditional single-stack architectures and reducing memory fragmentation. A concrete example: Taking the matrix multiplication function `matmul_block` as an example, the compiler parses the function and finds that it needs to overflow four vector registers (each register is 512 bits long, `vlenb` = 64 bytes). Therefore, the vector stack size is calculated to be 4 × 64 = 256 bytes. In the `RISCVFrameLowering::emitPrologue` method of LLVM, the compiler generates the following instruction sequence: ADDI sp, sp, -ScalarStackSize / / Adjust SP to allocate a scalar stack frame (e.g., ScalarStackSize=128 bytes). ADDI vsp, vsp, -RVVStackSize / / Adjust the VSP and allocate vector stack frames (e.g., RVVStackSize=256 bytes).

[0122] This not only optimizes stack space utilization but also allows scalar stack and vector stack adjustment operations to be executed in parallel with hardware support, improving instruction-level parallelism.

[0123] Among them, emitEpilogue was modified as follows: At the end of the function, the compiler mirrors the `emitPrologue` operation, but restores the stack pointers in reverse order. Specifically, the compiler first moves the vector stack pointer (VSP) up by `RVVStackSize`, reclaiming vector stack frames; then it moves the scalar stack pointer (SP) up by `ScalarStackSize`, reclaiming scalar stack frames. This modification ensures that stack space is correctly reclaimed when the function returns, avoiding memory leaks.

[0124] Modify the RISCVFrameLowering::emitEpilogue method involving LLVM, where instructions are generated to restore the SP and VSP to their state before the function call. Since the vector stack pointer register (VSP) is defined as the save register for the called function, the compiler also needs to insert instructions before the function returns to restore the value of VSP from the scalar stack to ensure the correctness of the call chain context.

[0125] Specific example: Before the matmul_block function returns, the compiler generates the following instruction sequence: ADDI vsp, vsp, RVVStackSize / / Reclaim vector stack frames (VSP recovery); ADDI sp, sp, ScalarStackSize / / Reclaim scalar stack frames (SP recovery); LOAD vsp, [sp] / / Restore the caller's VSP value from the scalar stack (because VSP is the Callee Saved register).

[0126] This refined management improves system reliability and performance, and is especially suitable for nested function call scenarios.

[0127] Specifically, the `eliminateFrameIndex` parameter was modified as follows: During the frame index elimination phase, the compiler needs to calculate the offset based on the stack object type (scalar or vector). For scalar stack objects (such as local variables and call parameters), the offset is calculated only based on the scalar stack pointer (SP) and a fixed offset determined at compile time, without considering the vector stack region; for vector stack objects, the offset is calculated based on the vector stack pointer (VSP) and a fixed offset, without involving the scalar stack region.

[0128] This modification is implemented in LLVM's `RISCVRegisterInfo::eliminateFrameIndex` method, which simplifies offset address calculation by distinguishing stack object types. In traditional single-stack mode, the offset needs to be decomposed into a fixed part and a scalable part (dependent on the hardware vector length), resulting in the need for high-latency CSR read instructions; while in dual-stack mode, the offsets are all compile-time constants, eliminating runtime overhead. Specific example: Suppose a scalar local variable is located at offset 16 bytes from SP, and a vector object is located at offset 32 ​​bytes from VSP. During the `eliminateFrameIndex` stage: Scalar object offset calculation: Directly generate LW a0,16(sp) instruction, with offset 16 being a fixed value.

[0129] Vector object offset calculation: Generates VLW v8,32 (vsp) instructions, with offset 32 ​​based on VSP and pre-calculated values, without needing to read the VLEN register. Compared to single-stack mode, dual-stack avoids extra instructions such as CSRREAD t0, vlenb and ADD t0, sp, t0, reducing the number of instructions and latency.

[0130] Among them, the modifications related to FP (frame pointer) are: In scenarios with frame pointers (FP), the compiler needs to further optimize offset calculations. The scalar stack uses FP as its base address, ensuring that the offset calculation of scalar objects is based only on FP and fixed offsets, thus improving access speed; the vector stack still uses VSP as its base address, maintaining independence.

[0131] Modify several methods involving LLVM, such as in emitPrologue, where FP is initialized based on SP (e.g., MV fp, sp), but only for scalar stacks; in eliminateFrameIndex, for scalar stack objects, offsets are calculated based on FP (e.g., local variable address = FP + fixed offset), while for vector stack objects, offsets are calculated based on VSP.

[0132] For example, in a function with functional programming (FP), the access instruction for a scalar local variable might be LW a0, -16 (fp), while the access instruction for a vector object is VLW v8, 32 (vsp). This design ensures that the dual-stack model remains efficient and consistent in scenarios with FP, avoiding the computational complexity caused by the coupling between FP and VSP in traditional methods.

[0133] These modifications enable the compiler to generate highly optimized dual-stack management code, significantly improving the execution efficiency of vector-intensive functions. Through concrete examples and hardware co-design, low latency and high throughput are achieved in scenarios such as intensive computing.

[0134] After allocating stack space, the final access address of all stack objects (including scalar stack objects and vector stack objects) needs to be obtained by adding a pre-calculated offset to their respective adjusted stack frame base address (i.e., the adjusted stack pointer). In the traditional unified single-stack architecture, because scalar stack objects and vector stack objects are stored together in the same address space, and the size of the vector stack is related to the runtime hardware vector length (VLEN), the calculation of the offset of any stack object becomes complex. Specifically, the offset address of each stack object is decomposed into a fixed part and a scalable part related to the hardware vector length. The fixed part is the fixed offset of the stack object relative to the stack pointer, while the scalable part depends on the overall size of the vector stack, which depends on the VLEN value that can only be read from the control and status registers at program runtime. This coupling means that when calculating the offset, both scalar stack objects and vector stack objects need to process both the fixed and scalable parts simultaneously, increasing the complexity of compiler analysis and code generation. More importantly, computing the scalable part requires executing instructions for access control and status registers, which have a much higher latency than ordinary arithmetic instructions, becoming a performance bottleneck.

[0135] In one optional embodiment of this specification, adjusting the scalar stack pointer includes: Calculate the scalar offset based on the total amount of scalar overflow data in the current function; The scalar stack pointer is adjusted based on the current base address and scalar offset of the scalar stack space.

[0136] The total amount of scalar overflow data is the sum of the storage space occupied by all scalar data that needs to overflow from scalar registers to the scalar stack space in the current function. This total amount of data is statically calculated by the compiler at compile time by analyzing information such as scalar variables, local data, and saved register context within the function, and it is the basis for determining the required scalar stack frame size.

[0137] The scalar offset is the value that needs to be subtracted from the current scalar stack pointer (SP) when adjusting the scalar stack pointer. Its size is equal to the total size of the scalar stack frames allocated for the current function. This offset is a compile-time constant used to adjust the scalar stack pointer (SP) downwards in the function preamble to allocate stack frames, or to adjust the SP upwards at the end of the function to reclaim stack frames.

[0138] Based on the current base address and scalar offset of the scalar stack space, the scalar stack pointer is adjusted. One possible implementation is to divide the scalar stack space in the cacheable area of ​​the on-chip memory unit into scalar stack frames by subtracting the scalar offset from the value of the scalar stack pointer register, thereby completing the downward adjustment of the scalar stack pointer.

[0139] It's important to note that by employing a separate scalar stack and vector stack architecture, and equipping them with independent scalar stack pointers (SP) and vector stack pointers (VSP), the calculation process for stack object offsets is fundamentally simplified, and the dependency on high-latency CSR instructions is eliminated. In this dual-stack mode, stack space management is completely decoupled: the offset address of a scalar stack object (such as parameters passed through the stack, local scalar variables, etc.) is calculated only relative to the scalar stack pointer (SP), and its offset is statically determined by the compiler at compile time, representing a purely fixed portion without considering any scalable portion related to the vector length. Similarly, the offset address of a vector stack object is calculated only relative to the vector stack pointer (VSP), and its offset is also statically calculated by the compiler, similarly without a scalable portion. This separation design offers two technical benefits: firstly, it greatly simplifies the compiler's stack layout and address calculation logic, eliminating the need for the compiler to generate additional instruction sequences for calculating or retrieving the scalable portion, thus reducing code complexity and size. Secondly, and more importantly, it completely avoids executing high-latency CSR read instructions (such as reading VLEN) at runtime to determine the vector stack size, thus eliminating the performance overhead. This allows stack pointer adjustments, stack address calculations, and subsequent memory accesses to be performed more efficiently and deterministically, which is especially beneficial for complex calculation functions that involve a large number of stack operations and vector register overflow / recovery, significantly improving the overall program execution efficiency.

[0140] For example, during the function preamble phase, the compiler calculates that the required scalar stack frame size for the `matmul_block` function is 128 bytes, with a scalar offset of 128. The compiler generates instructions to subtract 128 from the current value of the scalar stack pointer register (SP). This operation allocates a 128-byte scalar stack frame for this function call within the cacheable area of ​​on-chip memory. At this point, the new value of the scalar stack pointer register (SP) points to the top of the stack frame. Using the current value of the scalar stack pointer register (SP) as the base address, plus a pre-calculated fixed offset relative to the top of the stack, the storage address of the variable in the stack frame can be accurately calculated.

[0141] In the embodiments described in this specification, the scalar offset is determined by explicitly using the total amount of scalar overflow data calculated at compile time. This offset is then used to directly and atomically adjust the scalar stack pointer, achieving precise and efficient management of scalar stack frame allocation and deallocation. Since the scalar stack and vector stack are separated, the calculation of this offset only needs to consider the scalar data itself, completely avoiding the complexity introduced by traditional hybrid stacks that require consideration of vector data regions.

[0142] In one optional embodiment of this specification, step 404, which involves allocating a vector stack space from the on-chip storage unit for storing vector overflow data, includes: At the start of a function call, the parsing function determines the vector overflow data, allocates vector stack space from the non-cacheable region of the on-chip memory, allocates vector stack frames from the vector stack space, and adjusts the vector stack pointer. When a vector register of a vector unit overflows, the overflowed data is written to the vector stack space, including: When the vector register of a vector unit overflows, the overflowed vector data is written into the vector stack frame in the vector stack space based on the adjusted vector stack pointer. After writing the overflowed data to the vector stack space when the vector register of a vector unit overflows, the process also includes: When the function call ends, the vector stack frame is reclaimed from the vector stack space and the vector stack pointer is restored.

[0143] A vector stack frame is a contiguous block of memory dynamically allocated within the vector stack space for a specific function instance during a function call. It is specifically used to store vector data that overflows from the vector registers during the function call. Each active function call requiring vector overflow operations has its own independent vector stack frame in the vector stack space. Its size is determined at compile time or during the function call, typically matching the function's vector register overflow requirements, and its lifecycle is tied to the function call.

[0144] One possible implementation of dividing vector stack frames from the vector stack space and adjusting the vector stack pointer is as follows: determine the vector offset, divide vector stack frames from the vector stack space based on the vector offset, and adjust the vector stack pointer.

[0145] One possible implementation of reclaiming vector stack frames from the vector stack space and restoring the vector stack pointer is as follows: determine the vector offset, and based on the vector offset, reclaim the vector stack frames from the vector stack space and restore the vector stack pointer.

[0146] For example, for the matmul_block function that is determined to have an overflow risk, the compiler manages the vector stack space as follows when executing the dual-stack management mode in step 404: Stack Frame Partitioning: In the function preamble, the compiler calculates the vector stack frame size based on the number of vector registers to be overflowed (e.g., 4) and the value of the vlenb register (vlenb = VLEN / 8), for example, a size of 4 vlenb bytes. The compiler generates instructions to subtract the calculated stack size from the value of the vector stack pointer register (VSP), thereby allocating a vector stack frame for the current matmul_block function call within the vector stack space of the unbuffered area of ​​on-chip memory. The base address of the vector stack frame is the value of the vector stack pointer register (VSP) before adjustment. The compiler-generated code uses the current value of the vector stack pointer register (VSP) as the base address, plus a fixed offset calculated by the compiler at compile time, to calculate the specific address of the overflowing vector data within the vector stack frame.

[0147] Overflow data writing: When the core vector multiplication and addition calculation is performed in the function body, if the vector register v8 of vector unit 1120 needs to overflow, the vector unit directly writes the entire 512-bit vector data in the v8 register to the vector stack frame at that address through the high-bandwidth second path. After writing, the VSP register value will automatically increment according to the data size, pointing to the next available location in the stack frame.

[0148] Stack frame reclamation: At the end of the function call, after all vector data has been restored from the vector stack frame (or is no longer needed), the compiler generates instructions to add 2048 bytes of the vector stack frame size to the value of the vector stack pointer register (VSP), reclaiming the vector stack frame allocated for this call and restoring the VSP to its state before the call. Since the vector stack pointer register (VSP) is a callee-saved register, before the function returns, the called function also needs to restore the original value of the vector stack pointer register (VSP) saved by the caller from the scalar stack to ensure the correctness of the call chain context.

[0149] In the embodiments described in this specification, independent vector stack frames are allocated at the beginning of a function call to ensure the isolation and security of different calling instance contexts. The stack frames are precisely reclaimed and the stack pointer is restored at the end of the function call, ensuring the correctness and efficiency of stack space management.

[0150] After allocating stack space, the final access address of all stack objects (including scalar stack objects and vector stack objects) needs to be obtained by adding a pre-calculated offset to their respective adjusted stack frame base address (i.e., the adjusted stack pointer). In the traditional unified single-stack architecture, because scalar stack objects and vector stack objects are stored together in the same address space, and the size of the vector stack is related to the runtime hardware vector length (VLEN), the calculation of the offset of any stack object becomes complex. Specifically, the offset address of each stack object is decomposed into a fixed part and a scalable part related to the hardware vector length. The fixed part is the fixed offset of the stack object relative to the stack pointer, while the scalable part depends on the overall size of the vector stack, which depends on the VLEN value that can only be read from the control and status registers at program runtime. This coupling means that when calculating the offset, both scalar stack objects and vector stack objects need to process both the fixed and scalable parts simultaneously, increasing the complexity of compiler analysis and code generation. More importantly, computing the scalable part requires executing instructions for access control and status registers, which have a much higher latency than ordinary arithmetic instructions, becoming a performance bottleneck.

[0151] In one optional embodiment of this specification, adjusting the vector stack pointer includes: Calculate the vector offset based on the number of vector registers to be overflowed, the data type of the vector registers, and the length of the vector registers defined by the hardware. The vector stack pointer is adjusted based on the base address and vector offset of the vector stack space configured for the function.

[0152] The number of vector registers to overflow is the maximum number of vector registers that are estimated to need to overflow from the vector registers into the vector stack space during the current function execution. This number is estimated by the compiler through static analysis or profiling feedback and is one of the important factors in calculating the required vector stack space.

[0153] The vector data type is the data format of each data element in a vector register. Common vector data types include single-precision floating-point numbers, half-precision floating-point numbers, and integers, and their size directly affects the storage space occupied by a single vector element.

[0154] The length of a hardware-defined vector register is the data bit width that a single vector register can hold, usually measured in bits. In RISC-V RVV, it can be specified or configured by a CSR such as VLEN. This length determines the number of vector elements that a single vector register can hold at one time (number of elements = vector register length / element size).

[0155] The vector offset is the value that needs to be subtracted from the current vector stack pointer (VSP) value when adjusting the vector stack pointer. Its size is equal to the total size of the vector stack frames allocated for the current function. This offset is calculated based on the number of vector registers to be overflowed, the vector data type, and the length of the hardware vector registers. It is a compile-time constant used to adjust the VSP downwards in the function prologue to allocate vector stack frames.

[0156] Based on the current base address and vector offset of the vector stack space, the vector stack pointer is adjusted. One possible implementation is to divide the vector stack space in the cacheable area of ​​the on-chip memory unit by subtracting the vector offset from the value of the vector stack pointer register, thereby completing the downward adjustment of the vector stack pointer.

[0157] It's important to note that by employing a separate scalar stack and vector stack architecture, and equipping them with independent scalar stack pointers (SP) and vector stack pointers (VSP), the calculation process for stack object offsets is fundamentally simplified, and the dependency on high-latency CSR instructions is eliminated. In this dual-stack mode, stack space management is completely decoupled: the offset address of a scalar stack object (such as parameters passed through the stack, local scalar variables, etc.) is calculated only relative to the scalar stack pointer (SP), and its offset is statically determined by the compiler at compile time, representing a purely fixed portion without considering any scalable portion related to the vector length. Similarly, the offset address of a vector stack object is calculated only relative to the vector stack pointer (VSP), and its offset is also statically calculated by the compiler, similarly without a scalable portion. This separation design offers two technical benefits: firstly, it greatly simplifies the compiler's stack layout and address calculation logic, eliminating the need for the compiler to generate additional instruction sequences for calculating or retrieving the scalable portion, thus reducing code complexity and size. Secondly, and more importantly, it completely avoids executing high-latency CSR read instructions (such as reading VLEN) at runtime to determine the vector stack size, thus eliminating the performance overhead. This allows stack pointer adjustments, stack address calculations, and subsequent memory accesses to be performed more efficiently and deterministically, which is especially beneficial for complex calculation functions that involve a large number of stack operations and vector register overflow / recovery, significantly improving the overall program execution efficiency.

[0158] For example, the estimated number of overflow vector registers is 8, the vector data type is FP32 (4 bytes / element), and the hardware vector register length is 512 bits (64 bytes / register). The data type mainly affects the number of elements that each vector register can store. FP32 can store 16 elements in a 512-bit register (512 bits / 32 bits = 16), but the stack size calculation needs to be based on the byte size of the registers. Therefore, each overflow vector register needs to occupy 64 bytes. Thus, the required vector stack frame size (vector offset) is calculated as: 8 registers * 64 bytes / register = 512 bytes. The compiler generates instructions to subtract 512 from the current value of the vector stack pointer register (VSP). This operation allocates a 512-byte vector stack frame for this function call in the vector stack space of the non-cacheable area of ​​the on-chip memory unit. The overflow address of the vector data can then be calculated based on this adjusted value of the vector stack pointer register (VSP) plus a fixed offset.

[0159] In the embodiments described in this specification, the decoupling and simplification of stack object offset calculation are achieved by physically separating the vector stack space and scalar stack space at the hardware level and configuring independent vector stack pointers (VSP) and scalar stack pointers (SP). Under this architecture, the address calculation of vector stack objects is completely independent of the scalar stack layout. When the compiler generates object code, the offset address of the vector stack object is calculated based solely on the vector stack pointer (VSP) and a fixed offset related to the vector data layout that can be determined at compile time. Since the scalar stack and vector stack are separated, the calculation of this offset only needs to consider the vector data itself, completely avoiding the complexity introduced by traditional hybrid stacks due to the need to consider scalar data regions.

[0160] In one optional embodiment of this specification, after step 402, the method further includes: If not, execute single-stack management mode, including: allocating stack space from on-chip memory units for storing overflow data; when a scalar unit's register overflows, writing the overflow data into the stack space through a shared cache.

[0161] Single-stack management is a traditional stack management strategy employed by the compiler when it determines that the current function does not pose a risk of vector register overflow. In this mode, the compiler allocates a single, unified stack space for the current function to store overflow data. This mode uses a single stack pointer (usually a scalar stack pointer SP) to manage the entire stack space, and overflow operations are performed through this unified stack space via a cache.

[0162] Overflow data refers to temporary data that needs to be temporarily moved out and stored in a designated stack space within on-chip memory when register capacity is insufficient. In single-stack management mode, overflow data includes scalar overflow data and vector overflow data, which share the same logical stack space.

[0163] In single-stack management mode, stack space refers to a logical storage area within on-chip memory used to uniformly store all overflow data of the current function. This stack space is typically located in a cacheable area, managed by a single stack pointer (SP), and follows a last-in-first-out (LIFO) stack access method.

[0164] It's important to note that single-stack and dual-stack management modes can be dynamically selected through compiler configuration options. For example, in the LLVM compiler, single-stack mode is enabled by default (--riscv-enable-two-stack=false). In this mode, both scalar registers and RVV vector registers may overflow, and both are managed by a single stack. However, when --riscv-enable-two-stack=true is set, the compiler selects the mode as needed: if the current function has a risk of vector register overflow, dual-stack mode is used; otherwise, single-stack mode is used. In this case, single-stack mode only handles scalar overflow data and does not need to consider vector register overflow, thus simplifying stack management and reducing overhead.

[0165] For example, when the compiler processes a simple scalar-intensive function (such as a loop counter or conditional statement), if the function does not use vector instructions or the vector register usage does not exceed the hardware capacity, the compiler will choose single-stack mode after enabling the dual-stack option. In this mode, the compiler allocates a unified stack space from the cacheable area of ​​on-chip memory and manages all overflow data through a scalar stack pointer (SP). For example, when the loop index register of a scalar unit overflows, the data is written to this stack space through a shared cache, while the vector registers, since they are not at risk of overflow, do not involve any additional operations, thus improving execution efficiency.

[0166] In the embodiments described in this specification, by introducing a configurable stack management mode, the compiler can intelligently select a single-stack or dual-stack strategy based on function characteristics, achieving dynamic resource optimization management. The single-stack mode reduces the complexity of stack management in scenarios without vector overflow, avoiding unnecessary vector stack overhead; while the dual-stack mode ensures the high bandwidth requirements of vector-intensive computations. This flexible mechanism, in conjunction with hardware characteristics, improves the overall performance and energy efficiency of the on-chip system.

[0167] Corresponding to the above-mentioned embodiments in the specification, Figure 5 This specification illustrates a stack frame structure diagram of a single-stack and dual-stack system-on-a-chip according to an embodiment of the present specification, as shown below. Figure 5 As shown: The stack frame structure in single-stack management mode is as follows: The passed-in stack parameter area; - The starting address of the scalar stack frame; The called function saves the register; Secondary alignment; Vector stack object; - (stack size of vector extended instruction set / 8) * vector register length; The padding area before the vector stack object; Scalar local variables, overflowing stack objects (overflow slots); The outgoing stack parameter area; - The termination address of the scalar stack frame.

[0168] The stack frame structure in dual-stack management mode is as follows: Scalar stack frame: The passed-in stack parameter area; - The starting address of the scalar stack frame; The called function saves the register; Alignment; Scalar local variables, overflowing stack objects (overflow slots); The outgoing stack parameter area; - The termination address of the scalar stack frame.

[0169] Vector stack frame: - Vector stack pointer.

[0170] In order to achieve Figure 5 To achieve the dual-stack management effect shown and realize its performance advantages during compilation and runtime, the compiler and hardware need to work together to complete the following key operations: Key tasks on the compiler side include: Define and conditionally reserve a vector stack pointer register: The compiler must select a callee save register that conforms to the calling convention as a dedicated vector stack pointer register. Crucially, the reservation and use of this register are conditional: this register will only be allocated and dual-stack management mode enabled if the compiler determines, through static analysis or historical analysis, that the current function indeed has a risk of vector register overflow; for functions without this risk or with only scalar overflow, the traditional single-stack management mode will be used to avoid unnecessary register resource overhead.

[0171] Independent adjustment and management of dual-stack frames: In functions that enable dual-stack management, the compiler needs to independently calculate the space required for the scalar stack and the vector stack, and generate independent instruction sequences to adjust the scalar stack pointer and the vector stack pointer respectively in the function preamble and post-function. The core improvement of this process lies in simplifying the multiple memory alignment operations required in traditional single-stack systems due to mixed layouts (which typically involve scalar stack internal alignment, scalar and vector stack object alignment, and re-alignment after secondary adjustments) into a one-time alignment within each stack space. This significantly reduces internal memory fragmentation caused by forced alignment and optimizes the utilization of on-chip storage resources.

[0172] Stack object offsets are calculated using independent stack frames: In dual-stack management mode, the compiler uses separate base addresses when calculating the specific storage addresses of stack objects (variables, parameters, overflow slots, etc.). Scalar stack objects are calculated using the adjusted scalar stack pointer as the base address, while vector stack objects are calculated using the adjusted vector stack pointer as the base address. The fundamental simplification brought by this separation is that the offset calculation of scalar stack objects does not need to consider the variable size of the vector data area, and the offset calculation of vector stack objects is completely unaffected by the layout of the preceding scalar data area. Both offsets are determined as fixed values ​​at compile time, completely eliminating the need for traditional solutions that rely on runtime reading of hardware vector lengths and calculation of complex variable offsets.

[0173] Correspondingly, Figure 6 This specification illustrates a schematic diagram of the execution flow of a single-stack and dual-stack system in an embodiment of this specification; In single-stack management mode, because all stack operations share a single stack pointer, the execution flow inherently suffers from a serialization bottleneck. Specifically, in the function preface, a first stack pointer adjustment is required to reserve space, followed by the overflow operation to save the callee's register, then a second stack pointer adjustment to accommodate the vector object, before other scalar and vector stack operations can be executed; the same applies to the garbage collection process at the end of the function. Throughout the entire process, the stack pointer adjustment operations forcibly separate different stack access operation sequences, and their execution order is fixed, making parallelization difficult.

[0174] In dual-stack management mode, the adjustment and use of scalar stack pointers and vector stack pointers are independent, resulting in a significant improvement in execution parallelism. In the function preamble, the operations of adjusting the SP and VSP can be issued as independent instructions. More importantly, there is no data path or pointer management dependency between subsequent memory access operations on the scalar stack and those on the vector stack. Therefore, with processor support, these operations can be dynamically executed in parallel or deeply interleaved by the hardware scheduler, effectively hiding memory access latency and improving instruction-level parallelism. This decoupling and parallelization potential in the execution flow is one of the key mechanisms by which the dual-stack architecture improves the overall function execution efficiency at runtime.

[0175] The above is an illustrative scheme of a data processing method according to this embodiment. It should be noted that the technical solution of this data processing method belongs to the same concept as the technical solution of the above-mentioned system-on-a-chip. For details not described in detail in the technical solution of the data processing method, please refer to the description of the technical solution of the above-mentioned system-on-a-chip.

[0176] Corresponding to the above-described system-on-chip embodiments, this specification also provides embodiments of system-on-chip initialization methods. Figure 7A flowchart illustrating an on-chip system initialization method according to one embodiment of this specification is shown. Figure 7 As shown, this method is applied to the firmware unit of the above-mentioned on-chip system and includes: Step 702: Allocate non-cacheable regions on the on-chip storage unit as vector stack space.

[0177] Step 704: Assign the base address of the vector stack space to the vector stack pointer register.

[0178] Step 706: Allocate cacheable areas on the on-chip storage unit as scalar stack space.

[0179] Step 708: Assign the base address of the scalar stack space to the scalar stack pointer register.

[0180] For example, after the on-chip system is powered on or reset, the firmware unit executes the initialization process: The firmware unit first traverses the physical address space of the on-chip memory unit and allocates a continuous and sufficiently large storage area.

[0181] The firmware unit configures the memory management unit or storage controller to set the memory attribute of the region to non-cacheable and maps its logical address to the system address space. After this operation is completed, the starting address of the region is established as the base address of the vector stack space.

[0182] The firmware unit executes privileged instructions (such as the CSR write instruction) to assign the base address of the vector stack space to the vector stack pointer register (VSP), thereby initializing the vector stack pointer to point to the bottom of the stack space.

[0183] While configuring the vector stack, the firmware unit divides the scalar stack space in the cacheable area in parallel and assigns its base address to the scalar stack pointer register (SP).

[0184] When the vector processing unit begins executing a function containing RVV vector operations, the hardware environment required for its vector stack management is ready.

[0185] In the embodiments described in this specification, the firmware unit pre-allocates a non-cacheable region on the on-chip storage unit as a vector stack space during the system initialization phase, assigning the base address of the vector stack space to the vector stack pointer register. Conversely, a cacheable region on the on-chip storage unit is allocated as a scalar stack space, with its base address assigned to the scalar stack pointer register. This is ready before the vector processing unit executes any computational tasks, supporting direct access via a high-bandwidth second path and avoiding latency caused by caching overhead. The physical separation and independent pointer management of the vector stack and scalar stack eliminate access conflicts of mixed data types found in traditional unified stacks, improving parallelism and resource utilization. The collaborative design of the firmware unit and hardware registers provides a low-latency, high-throughput data exchange foundation for vector-intensive computation, optimizing overall system performance.

[0186] The above is an illustrative scheme of an on-chip system initialization method according to this embodiment. It should be noted that the technical solution of this on-chip system initialization method belongs to the same concept as the technical solution of the on-chip system described above. For details not described in detail in the technical solution of the on-chip system initialization method, please refer to the description of the technical solution of the on-chip system described above.

[0187] Figure 8 A structural block diagram of a computing device according to one embodiment of this specification is shown. The components of the computing device 800 include, but are not limited to, a memory 810 and a system-on-a-chip 10; the system-on-a-chip 10 is as described above.

[0188] The system-on-chip 10 is connected to the memory 810 via a bus 830, and the database 850 is used to store data.

[0189] The computing device 800 also includes an access device 840, which enables the computing device 800 to communicate via one or more networks 860. Examples of these networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. The access device 840 may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Controller (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0190] In one embodiment of this specification, the above-described components of the computing device 800 and Figure 8 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 8 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0191] The computing device 800 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 800 can also be a mobile or stationary server.

[0192] The system-on-chip 10 is used to execute the following computer program / instruction, which, when executed by the processor, implements the steps of the above-described data processing method or system-on-chip initialization method.

[0193] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device belongs to the same concept as the technical solutions of the data processing method and the on-chip system initialization method described above. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solutions of the data processing method or the on-chip system initialization method described above.

[0194] An embodiment of this specification also provides a computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the above-described data processing method or system-on-chip initialization method.

[0195] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium belongs to the same concept as the technical solutions of the data processing method and the on-chip system initialization method described above. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solutions of the data processing method or the on-chip system initialization method described above.

[0196] An embodiment of this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described data processing method or on-chip system initialization method.

[0197] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product belongs to the same concept as the technical solutions of the data processing method and the on-chip system initialization method described above. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solutions of the data processing method or the on-chip system initialization method described above.

[0198] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0199] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0200] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0201] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0202] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A system-on-a-chip (SoC) includes a vector processing unit and an on-chip storage unit, wherein the vector processing unit and the on-chip storage unit are connected via an on-chip interconnect network, and the vector processing unit includes a scalar unit and the vector unit; The scalar unit and the vector unit are connected to the on-chip interconnect network via a first path; The vector unit and the on-chip interconnect network are connected via a second path; in, The bandwidth of the second path is higher than that of the first path.

2. The system-on-a-chip according to claim 1, wherein the vector processing unit further comprises a shared cache; The scalar unit and the vector unit are connected to the shared cache via the first path, and the shared cache and the on-chip interconnect network are connected via the first path.

3. The system-on-a-chip according to claim 2, wherein the shared cache is a level 2 cache.

4. The system-on-a-chip according to claim 1, wherein the on-chip storage unit includes at least one of a static random access storage unit and a dynamic random access storage unit.

5. The system-on-a-chip according to any one of claims 1-4, wherein the on-chip storage unit is divided into a scalar stack space for storing scalar overflow data and a vector stack space for storing vector overflow data; in, The scalar stack space is located in the cacheable area of ​​the on-chip storage unit, and the vector stack space is located in the non-cacheable area of ​​the on-chip storage unit.

6. The system-on-a-chip according to claim 5, wherein the scalar stack space is provided with a scalar stack pointer, and the vector stack space is provided with a vector stack pointer; in, The scalar stack pointer and the vector stack pointer are independent of each other.

7. The system-on-a-chip according to claim 6, wherein the scalar unit includes a scalar stack pointer register for storing a scalar stack pointer and a vector stack pointer register for storing a vector stack pointer, wherein the vector stack pointer register is a call function save register; The system-on-a-chip further includes a firmware unit, which is used to initialize a vector stack space in the non-cacheable region and configure the base address to the vector stack pointer register before the vector processing unit executes the function, and initialize a scalar stack space in the cacheable region and configure the base address to the scalar stack pointer register.

8. A data processing method applied to a compiler for the on-chip system according to any one of claims 1-7, comprising: Determine if the current function is at risk of vector register overflow; If so, execute the dual-stack management mode, including: Divide the on-chip storage unit into a scalar stack space for storing scalar overflow data and a vector stack space for storing vector overflow data; When the register of the scalar unit overflows, the scalar overflow data is written to the scalar stack space through the shared buffer; When the vector register of the vector unit overflows, the overflowed vector data is written to the vector stack space.

9. The method according to claim 8, wherein the step of allocating scalar stack space from the on-chip storage unit for storing scalar overflow data comprises: At the start of a function call, the function is parsed to determine scalar overflow data, scalar stack space is allocated from the cacheable area of ​​the on-chip storage unit, scalar stack frames are allocated from the scalar stack space, and the scalar stack pointer is adjusted. When the register of the scalar unit overflows, writing the overflowed scalar data into the scalar stack space through a shared cache includes: When the register of the scalar unit overflows, the scalar overflow data is written into the scalar stack frame in the scalar stack space through the shared buffer; After writing the scalar overflow data into the scalar stack space via a shared buffer based on the adjusted scalar stack pointer when the scalar unit's register overflows, the method further includes: When the function call ends, the scalar stack frame is reclaimed from the scalar stack space, and the scalar stack pointer is restored.

10. The method according to claim 9, wherein adjusting the scalar stack pointer comprises: Calculate the scalar offset based on the total amount of scalar overflow data in the current function; The scalar stack pointer is adjusted based on the current base address of the scalar stack space and the scalar offset.

11. The method according to claim 8, wherein the step of allocating a vector stack space from the on-chip storage unit for storing vector overflow data comprises: At the start of a function call, the function is parsed to determine the vector overflow data, vector stack space is allocated from the non-cacheable area of ​​the on-chip storage unit, vector stack frames are allocated from the vector stack space, and the vector stack pointer is adjusted. When the vector register of the vector unit overflows, writing the overflowed vector data into the vector stack space includes: When the vector register of the vector unit overflows, the overflowed vector data is written into the vector stack frame in the vector stack space based on the adjusted vector stack pointer. After writing the overflowed vector data to the vector stack space when the vector register of the vector unit overflows, the method further includes: When the function call ends, the vector stack frame is reclaimed from the vector stack space, and the vector stack pointer is restored.

12. The method according to claim 11, wherein adjusting the vector stack pointer comprises: Calculate the vector offset based on the number of vector registers to be overflowed, the data type of the vector registers, and the length of the vector registers defined by the hardware. The vector stack pointer is adjusted based on the base address of the vector stack space configured for the function and the vector offset.

13. The method according to claim 8, after determining whether there is a risk of vector register overflow in the current function, further comprising: If not, execute the single-stack management mode, including: Allocate stack space from on-chip storage units to store overflow data; When the register of the scalar unit overflows, the overflow data is written to the stack space through a shared cache.

14. A system-on-chip initialization method, applied to the firmware unit of the system-on-chip according to claim 7, comprising: A non-cacheable region is partitioned on the on-chip storage unit as a vector stack space; Assign the base address of the vector stack space to the vector stack pointer register; A cacheable region is partitioned on the on-chip storage unit as a scalar stack space; Assign the base address of the scalar stack space to the scalar stack pointer register.

15. A computing device, comprising: Memory and system-on-a-chip; The system-on-a-chip is as described in any one of claims 1-7.

16. A computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the method according to any one of claims 8-14.

17. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the method according to any one of claims 8-14.

Images