A method, system and chip for implementing a RISC-V vector extension supporting hardware configurable vector register length

Abstract

The application discloses a RISC-V vector extension implementation method, system and chip supporting hardware configurable vector register length, the application stores a current vector register length configuration value in a self-defined control state register; monitors whether the value of the self-defined control state register changes; when the value changes, the legality of a target vector register length configuration value is checked; after the check, the target vector register length configuration value is distributed to each hardware module to update the behavior of each hardware module; wherein, each hardware module comprises a vector register group, vector register byte width return logic and vector instruction splitting logic. The application also provides corresponding systems and chips. The application enables the same chip to dynamically balance performance and power consumption in different scenarios through hardware configurable vector register length, while ensuring the cross-platform portability of binary code and reducing software development and maintenance costs.

Description

Technical Field

[0001] This invention belongs to the field of high-performance chip design technology, specifically relating to fifth-generation Reduced Instruction Set Computing V (RISC-V) vector extension technology, particularly a RISC-V vector extension implementation method, system, and chip that supports hardware-configurable vector register lengths. This invention is applicable to various scenarios such as embedded devices, edge computing nodes, server chips, and multi-core SMP (Symmetric Multiprocessing) architecture systems. It aims to solve the compatibility, scenario adaptability, and resource utilization problems caused by fixed VLEN designs through a flexible hardware-level VLEN configuration mechanism, while ensuring cross-platform portability of binary code, reducing software development and maintenance costs, and providing a unified vector extension hardware architecture support for chip products with different performance and power consumption requirements. Background Technology

[0002] RISC-V vector extension, a core technology for enhancing parallel data processing capabilities, significantly improves the execution efficiency of data-intensive tasks such as matrix operations, signal processing, and AI inference by performing parallel operations on batches of data through vector registers. It has become a standard extension solution for high-performance chips in embedded systems, servers, and edge computing. The vector register length (VLEN), a core parameter of vector extension, directly defines the bit width of a single vector register. Its value determines the amount of data that can be processed in a single vector operation (i.e., the degree of parallelism), and directly affects the chip's hardware resource usage (such as register area and computational unit complexity) and power consumption.

[0003] In the RISC-V Vector Extension specification, VLEN is an implementation-defined constant parameter, required to be a power of 2 and not less than ELEN (maximum element width). In existing RISC-V Vector Extension implementations, VLEN generally adopts a fixed design, meaning that VLEN is fixed in hardware circuitry at the chip's manufacturing stage and cannot be dynamically adjusted through software or hardware configuration. Specifically, embedded devices typically use smaller VLENs (e.g., 32-bit, 64-bit) to save chip area and power consumption; while application processors use larger VLENs (e.g., 256-bit, 512-bit) to improve parallel processing capabilities.

[0004] In the prior art, the fixed VLEN design leads to the following problems:

[0005] 1. Poor binary code compatibility: Fixed VLEN results in strong binding between software code and hardware. For example, binary code developed for 64-bit VLEN chips cannot run directly on 256-bit VLEN chips, leading to high costs for cross-platform porting and significant difficulties in software development and maintenance.

[0006] 2. Weak multi-core collaboration capability: In mainstream multi-core SMP architectures, processor cores with different VLEN configurations cannot share the same software code. Software needs to be developed separately for each VLEN version, resulting in complex system deployment and low resource utilization.

[0007] 3. Insufficient scenario adaptability: Fixed VLEN cannot dynamically match the differentiated needs of different scenarios. In low-power scenarios, large VLENs cause resource waste and power redundancy, while in high-performance scenarios, small VLENs cannot meet the needs of parallel processing, making it difficult to achieve the optimal balance between resource utilization and performance.

[0008] 4. Lack of scalability: The requirements for vector parallelism in future chip applications (such as new AI tasks and edge-cloud collaboration) will continue to change. Fixed VLEN designs cannot adapt to future needs, resulting in short chip product lifecycles and high redesign costs. Summary of the Invention

[0009] This invention aims to provide a RISC-V vector extension implementation method, system, and chip that supports hardware-configurable vector register length, ensuring cross-platform portability of different VLEN binary codes and reducing software development costs; solving the coordination problem of different VLEN processor cores in multi-core SMP architecture, enabling each core to execute the same set of software code through a unified VLEN configuration, improving system flexibility; and adapting to the resource and performance requirements of different scenarios.

[0010] To solve the above-mentioned technical problems, the present invention adopts the following technical solution:

[0011] A RISC-V vector extension implementation method supporting hardware-configurable vector register length includes the following steps:

[0012] A custom control status register is provided, which is used to store the current vector register length configuration value;

[0013] Monitor whether the value of the custom control status register changes, i.e., the custom control status register is written to the target vector register length configuration value;

[0014] When a change in the value of the custom control status register is detected, the validity of the target vector register length configuration value is first checked.

[0015] After the verification is successful, the target vector register length configuration value is distributed to each hardware module to update the behavior of each hardware module;

[0016] Each hardware module includes a vector register group, vector register byte width return logic, and vector instruction splitting logic.

[0017] This invention also provides a RISC-V vector extension implementation system that supports hardware-configurable vector register lengths, comprising:

[0018] A custom control status register is used to store the current vector register length configuration value;

[0019] The vector register set includes multiple configurable bit-width vector registers, which selectively enable a portion of the storage bit width based on the current vector register length configuration value;

[0020] The vector register byte width return logic is used to output the byte width value of the current vector register length;

[0021] Vector instruction splitting logic is used to split vector instructions into multiple sub-instructions based on the current vector register length configuration value;

[0022] The configuration control module is used to detect changes in the value of the custom control status register, perform a validity check, and distribute the configuration value that passes the check to the vector register group, the vector register byte width return logic, and the vector instruction splitting logic.

[0023] The present invention also provides a chip including the above-described RISC-V vector extension implementation system that supports hardware-configurable vector register length.

[0024] The overall architecture of this invention comprises five core components: a custom control status register, a configuration control module, a vector register group, vector register byte width return logic, and vector instruction splitting logic. These components interact via signals to configure the vector register length and adapt to hardware behavior. Specifically:

[0025] The custom control status register, vlencfg, follows the RISC-V architecture specification. It is 11 bits wide, with bits [10:0] storing the VLEN configuration value, supporting custom selectable values ​​(e.g., binary values ​​corresponding to 32 / 64 / 128 / 256 / 512 / 1024 bits). The VLEN value in the vlencfg register is modified using CSR instructions (such as csrrw, csrrs, etc.), thus configuring the current hardware VLEN size. The custom control status register consists of an 11-bit vlencfg register, read / write control logic, and address decoding logic. The address decoding logic identifies the vlencfg address and responds to CSR instructions for that address. The read / write control logic supports CSR instruction read and write operations; during write operations, only the bit [10:0] fields are modified, and during read operations, the bit [10:0] register values ​​are output.

[0026] The configuration control module detects whether the current VLEN has changed. When a change in the VLEN in the vlencfg register is detected, it immediately initiates the configuration activation process, generates control signals to the hardware modules to synchronize their behavior, and generates a VLEN configuration completion signal. Specifically, the configuration control module includes: a configuration start control unit, which receives the configuration signal from the vlencfg register and generates control signals to drive validity verification and configuration signal distribution; a validity verification circuit, which compares the vlencfg register with a preset set of valid VLEN values ​​(such as the binary values ​​corresponding to 32 / 64 / 128 / 256 / 512 / 1024 bits) using a comparator and outputs the verification result (valid / invalid); and a configuration signal distribution unit, which, after successful verification, generates a VLEN value signal, synchronously outputs the signal to each module, generates a VLEN configuration completion signal, and the hardware can then execute subsequent instructions.

[0027] Handling of invalid VLEN configuration values: When the target VLEN written to the vlencfg register does not belong to the hardware-supported set of valid values, or exceeds the chip's maximum VLEN_max, the validity check circuit outputs an invalid result, the write enable of the vlencfg main register is masked, the register content is not updated during this write, and the current VLEN configuration remains at its original value before the write. Illegal writes will not enter the VLEN configuration activation process and will not update the vector register byte width return logic, the bit width configuration of the vector register group, or the instruction splitting configuration. The configuration control module can set the vlencfg_illegal status bit to indicate that this write is ignored.

[0028] Vector Register Bank: Employs a configurable bit-width register array design. The register width is configured based on the bit-width signal output by the current configuration control module. The register width includes the memory cells containing the writable bit width of the vlencfg register. The vector register bank conforms to the RVV specification and contains 32 vector registers. The maximum bit width of each register is the chip-implemented maximum VLEN_max (e.g., 1024 bits). The vector register bank uses the chip-implemented maximum bit width VLEN_max as the physical upper limit and configures the visible bit width by bank / slice grouping. Each vector register is divided into multiple memory banks. Memory banks are selectively enabled or disabled based on the current vector register length configuration value; the local clock of disabled memory banks is turned off.

[0029] The local clock of the masked memory packet is turned off through the clock gating unit. The enable terminal of the clock gating unit is connected to the enable signal of the memory packet, which is generated by decoding the current vector register length configuration value. Specifically, the VLEN selection decoding module generates bank_mask[i] according to the current vector register length configuration value. The bank covered by the current VLEN corresponds to bank_mask[i]=1, and the higher-order banks outside the current VLEN correspond to bank_mask[i]=0.

[0030] `bank_clk_en[i] = vector_reg_write_en & config_valid & bank_mask[i]`, where `vector_reg_write_en` enables vector register writes, and `config_valid` indicates that the current VLEN configuration is valid and effective. `bank_clk_en[i]` is connected to the enable pin of the integrated clock gating unit (ICG) before the i-th bank. The ICG outputs `bank_clk[i]` as the local clock for that bank. When `bank_mask[i] = 0`, the local clock of the ICG for that bank is turned off, and the write mask for that bank is set to 0. The read selection / concatenation MUX does not select the output of that bank. When `bank_mask[i] = 1`, the local clock of that bank is turned on, and it operates according to the normal vector register read / write path.

[0031] In an exemplary implementation, when VLEN_max = 1024 bits, each vector register is divided into eight 128-bit banks. When VLEN = 128 bits, only bank0 is visible to software; when VLEN = 256 bits, banks0-bank1 are visible; when VLEN = 512 bits, banks0-bank3 are visible; and when VLEN = 1024 bits, all banks are visible. For 32 / 64-bit configurations, write masks and read selections can be performed using 32 / 64-bit slices within bank0. The above bank / slice grouping method is an exemplary implementation; in specific implementations, grouping can be done at granularities of 64 / 128 / 256 bits, and is not limited to a 128-bit bank or a maximum width of 1024 bits.

[0032] The vector register byte width return logic is used to return the result of dividing the current VLEN by 8 (i.e., the byte width of the vector register), conforming to the definition of the vlenb register in the RISC-V Vector Extension Specification. This logic employs a combinational logic circuit design, receiving the current VLEN value output by the configuration control module in real time. It calculates and outputs the VLENB value through a division by 8 operation (right shift by 3 bits, equivalent to division by 8), ensuring the correct result is returned after configuration changes.

[0033] Vector instruction splitting logic: Receive the current VLEN value output by the configuration control module, calculate the number of sub-instructions that the current vector instruction needs to be split into based on the current VLEN configuration, the execution width of the vector execution unit, the number of vector register groups (LMUL) of the vector instruction, and the element width (SEW) of the vector instruction, and record the splitting status (such as the current processing progress and the number of remaining elements) to ensure that the sub-instructions are executed in order and the results are correctly merged.

[0034] The vector instruction splitting logic does not use VL (vector length) as the criterion for determining the number of split instructions. Let the current visible bit width be VLEN_cur, the register set multiple be LMUL, the single processing width of the vector execution unit be EXEC_WIDTH, and the element width be SEW. Then, the split bit width that the register set needs to cover is group_bits = VLEN_cur × LMUL. The number of subinstructions is calculated by rounding up the product of the current vector register length and the number of vector register sets, divided by the execution width of the vector execution unit. Each subinstruction carries the register set bit offset, subinstruction processing bit width, element slot range, destination register offset, and mask information. VL is only used during the execution / commit phase to determine the validity of elements and process the tail element; it does not participate in the split instruction count calculation.

[0035] For example: VLEN_cur=256, LMUL=1, SEW=32, EXEC_WIDTH=128, then group_bits=256, which is split into two sub-instructions, each covering 128 bits, corresponding to four 32-bit element slots. As another example: VLEN_cur=512, LMUL=2, SEW=64, EXEC_WIDTH=256, then group_bits=1024, which is split into four sub-instructions, each covering 256 bits, corresponding to four 64-bit element slots.

[0036] The vector instruction splitting logic specifically includes: a decoding unit, which extracts the register group number (LMUL), element width (SEW), and vector instruction type from the vector instruction information; an instruction splitting unit, which receives the current VLEN value output by the configuration control module and splits different vector instructions into correct sub-instructions based on the information from the decoding unit; and a status recording unit, which records the current splitting progress through a counter to ensure that sub-instructions are executed in sequence and records the splitting information required by the vector execution unit to support correct execution by the execution unit.

[0037] The splitting progress is recorded using a splitting count counter. After a vector instruction is issued to the splitting logic, the splitting calculation logic calculates the number of sub-instructions required for this instruction based on the splitting bit width (group_bits) that the register group needs to cover and the number of sub-instructions (subop_num), and writes the number of sub-instructions into the splitting count counter (split_cnt). During the splitting process, for each sub-instruction issued, split_cnt is decremented by 1, and the progress recording information such as the current sub-instruction number (current_subop), bit offset (bit_offset), and destination register offset (dest_offset) is updated. If split_cnt is not 0, the next sub-instruction is generated and issued; when split_cnt decrements to 0, the split_done signal is set, indicating that all sub-instructions of the current vector instruction have been issued.

[0038] The above splitting is a sub-instruction or micro-operation splitting within the microarchitecture, used only to adapt to the current VLEN configuration and vector execution unit width, and does not change the RVV instruction encoding, software-visible semantics, or program execution results.

[0039] VLEN configuration activation process:

[0040] The software writes the target VLEN value (e.g., 256 bits) to the vlencfg register via the CSR instruction. The configuration control module receives the signal to configure the vlencfg register and verifies the validity of the value through a validity check circuit. If the value is invalid, the current vlencfg register value is not modified, and the configuration is completed directly. If the value is valid, the configuration control module sends configuration signals to each module: a target bit width selection signal to the vector register group, switching to the corresponding bit width storage unit; the target VLEN value to the vector register byte width return logic, outputting the corresponding byte width value through shift operations (e.g., outputting 32 when VLEN=256); and the target VLEN signal to the vector instruction splitting logic, calculating the splitting result based on the current VLEN. After configuration, the VLEN configuration completion signal is set, indicating that the configuration is effective and subsequent instructions can be executed. The software can confirm the configuration status by reading the VLENB register. After configuration, the hardware begins to execute vector instructions according to the target VLEN, supporting direct execution of the binary code corresponding to that VLEN.

[0041] Safety point control:

[0042] VLEN switching must be performed at a safe point. A VLEN switching safe point is defined as follows: when a CSR instruction modifies `vlencfg`, the CSR instruction must wait for all its preceding instructions to retire and confirm that the vector pipeline is empty before executing the VLEN configuration update. Hardware criteria include: all instructions preceding the CSR instruction have retired or committed; all issued vector instructions have been written back; all valid signals at each stage of the vector execution pipeline are 0; and the vector memory access queue and vector write-back queue are empty.

[0043] The control flow is as follows: When a CSR instruction to write to the vlencfg register is detected during the decoding, transmit, or commit phase, the configuration control logic sets vlen_cfg_pending and stalls subsequent instructions, preventing instructions after the CSR from continuing to enter the execution pipeline; after all preceding instructions have retired and the vector pipeline is empty, the CSR instruction is allowed to execute and update vlencfg, the vector register byte width return logic, the bit width configuration of the vector register group, and the vector instruction splitting configuration.

[0044] When a CSR instruction that modifies the vlencfg register retires, the hardware generates a flush signal to flush subsequent instructions that have been fetched, decoded, issued, or speculated into the pipeline after that CSR. This allows subsequent instructions to be fetched, decoded, and executed again under the new VLEN semantics, thus ensuring that the instruction execution semantics are consistent before and after the VLEN switch.

[0045] Multi-core synchronization:

[0046] In a multi-core system, inter-core synchronization enables the master core and at least one slave core to switch to a consistent target vector register length configuration value in the same synchronization round. Specifically, the master core initiates a vector register length switch request and notifies the slave cores to prepare for the switch via an inter-core interrupt (IPI). The master and slave cores each enter their local safepoints, waiting for all preceding instructions of their respective cores to retire, for all valid signals at each stage of the vector execution pipeline to be 0, and for the vector memory access queue and vector write-back queue to be empty. After each core reaches its safepoint, it reports its ready status to the master core. Once the master core confirms that all online cores are ready, it triggers a synchronization commit, enabling all cores to update their custom control status registers and related hardware configurations in the same synchronization round.

[0047] To achieve multi-core synchronous switching, the system sets up global synchronization registers, including: the target VLEN register (vlen_sync_target), which stores the target VLEN value for this switch; the switch request register (vlen_sync_req), which is set by the master core to initiate the switch; the ready mask register (vlen_ready_mask), which records the online cores that have completed safety point preparation; the commit epoch register (vlen_commit_epoch), which is written by the master core to trigger synchronous commits by all cores; and the completion mask register (vlen_done_mask), which records the cores that have completed VLEN configuration updates.

[0048] The above simultaneous effect means that the software presents a consistent VLEN view under the same synchronization round, and does not require all cores to complete the update at the absolutely same physical clock edge.

[0049] The present invention, by adopting the above-described technical solution, has the following beneficial effects:

[0050] (1) Compatible with fixed register width software and unified ISA view

[0051] When the RVV programming model is followed, it can run the same source code or binary on different hardware VLENs. However, many existing software / libraries are often implemented based on the assumption of fixed vector register widths (e.g., ARM NEON = 128-bit, x86 AVX = 256 / 512-bit, or implementations on RVV that are manually expanded and tuned according to a specific VLEN). This invention enables processors to configure visible VLENs to the target width without changing the chip, thus directly supporting the aforementioned fixed-width software implementations and existing binary distributions. Simultaneously, in multi-core systems, each core can be configured with a consistent VLEN, presenting a symmetrical and consistent ISA view to the software. This allows multi-core systems with potentially asymmetric VLENs to be configured as SMP systems when needed, reducing software fragmentation and improving system deployment flexibility.

[0052] (2) Improved scene adaptability and power consumption optimization

[0053] Configuring VLEN via the vlencfg register during startup or runtime allows the same chip to dynamically balance performance and power consumption across different workloads. Specifically:

[0054] In standby, light load, or low real-time requirements phases, VLEN is configured to a smaller value. In conjunction with the clock gating mechanism of the vector register group, VLEN selects the bank_mask generated by decoding to close the high-order banks. The clock gating of the integrated clock gating unit (ICG) of the corresponding high-order register banks is closed, the write mask is set to 0, and the read selection path does not select the high-order banks, thereby reducing the power consumption of unused register bit width and related paths, and reducing the dynamic power consumption of registers and execution paths.

[0055] In throughput-sensitive stages such as matrix multiplication, convolution, and signal processing, configuring VLEN to a larger value opens more banks, allowing the hardware to provide a larger software-visible vector register width and higher parallel processing capabilities, thereby improving parallelism and bandwidth utilization.

[0056] This mechanism can be combined with DVFS, task scheduling, thermal management, or workload profiling to achieve optimal resource utilization by opening bandwidth on demand, enabling the same chip to operate with the best energy efficiency ratio in different business scenarios.

[0057] (3) Hardware compatibility and scalability optimization

[0058] This invention does not change the RVV instruction encoding and semantics. The vlencfg register, as the control status register of the implementation layer, only affects the hardware implementation behavior of VLEN, VLENB and the visible bit width of the register, ensuring compatibility with the existing RISC-V vector software ecosystem.

[0059] In implementation, the hardware can pre-configure a set of discrete selectable VLENs, such as 128, 256, 512, or 1024 bits, and stipulate that the target VLEN must not exceed the maximum VLEN_max implemented by the chip. If larger VLENs are needed in the future, only the vector register array and related execution paths need to be expanded within the same architecture, while updating the valid value table and control logic; there is no need to redesign the entire vector expansion architecture. This feature enables chip products to cover continuously evolving parallel computing needs, effectively extending product lifecycles and reducing future upgrade R&D costs and design cycles.

[0060] (4) Enhanced multi-core collaboration capabilities and system deployment flexibility

[0061] This invention enables all processor cores in a multi-core system to switch to a consistent VLEN configuration within the same synchronization round through an inter-core synchronization mechanism. The system sets up a global synchronization register, including a target VLEN register, a switch request register, a ready mask register, a commit round register, and a completion mask register. The master core initiates a switch request and notifies slave cores of the readiness to switch via an inter-core interrupt (IPI). Each core, after entering its local safe point, reports its readiness status to the master core. Once the master core confirms that all online cores are ready, it triggers a synchronization commit, ensuring that each core presents a consistent VLEN view to the software within the same synchronization round.

[0062] This mechanism solves the problem that processor cores with different VLEN configurations cannot share the same set of software code: In a multi-core SMP architecture, each core can execute the same set of binary code by configuring a unified VLEN, eliminating the need to develop separate software for each VLEN version. This simplifies the software deployment of multi-core systems, reduces system integration and maintenance costs, and improves system resource utilization and deployment flexibility.

[0063] (5) Ensuring security and semantic consistency during switching

[0064] This invention ensures that the configuration switching process does not affect the correctness of instruction execution through a robust VLEN switching safety point control mechanism. Specifically:

[0065] Hardware safety criteria include several objective conditions: all instructions prior to the CSR instruction have been retired or committed, all issued vector instructions have been written back, all valid signals at each stage of the vector execution pipeline are 0, and the vector memory access queue and vector write-back queue are empty. These criteria are all objectively detectable hardware states, avoiding implementation ambiguities that might result from vague descriptions.

[0066] Upon detecting a CSR instruction to write to the vlencfg register, the configuration control logic sets vlen_cfg_pending and pauses the issuance of subsequent instructions, preventing instructions following this CSR from continuing to enter the execution pipeline;

[0067] Once all preceding instructions have retired and the vector pipeline is empty, the CSR instruction can be executed to update the configuration.

[0068] When a CSR instruction that modifies the vlencfg register retires, the hardware generates a flush signal that flushes the CSR. This flushes subsequent instructions that have been fetched, decoded, issued, or speculated into the pipeline, causing those instructions to be fetched, decoded, and executed again under the new VLEN semantics.

[0069] The above mechanism ensures that the instruction execution semantics are consistent before and after VLEN switching, enabling the hardware-configurable VLEN mechanism to switch flexibly while ensuring security, thus providing a strong guarantee for the reliable operation of the chip.

[0070] (6) Efficiency of vector instruction splitting

[0071] This invention utilizes vector instruction splitting logic to dynamically calculate the number of sub-instructions required to split each vector instruction within the current vector register length configuration, and employs a splitting count counter to precisely control the splitting progress. Specifically, the splitting logic calculates the number of sub-instructions based on the current visible bit width, register set multiple, and single-processing width of the vector execution unit. Each sub-instruction carries complete register set bit offsets, sub-instruction processing bit widths, element slot ranges, destination register offsets, and mask information, ensuring that sub-instructions are executed sequentially and results are correctly merged. This splitting mechanism does not use vector length as a condition for determining the number of splits; vector length is only used to determine element validity and process tail elements during the execution or commit phase. The splitting logic is separated from the execution or commit logic, resulting in a clear and efficient design that reduces the complexity of microarchitecture design. Attached Figure Description

[0072] The present invention will be further described below with reference to the accompanying drawings:

[0073] Figure 1 A schematic diagram of the overall architecture of the VLEN configuration hardware implementation provided in this embodiment of the invention;

[0074] Figure 2 This is a schematic diagram of the VLEN configuration activation process provided in an embodiment of the present invention;

[0075] Figure 3 A schematic diagram of a configurable bit-width vector register group circuit provided in an embodiment of the present invention. Detailed Implementation

[0076] To make the objectives, technical solutions, and advantages of this invention clearer, the embodiments of this invention will be described in further detail below with reference to the accompanying drawings. It should be noted that the following embodiments are only for a better understanding of this invention and do not constitute a limitation on the scope of protection of this invention.

[0077] Example 1: Single-core VLEN configuration switching

[0078] This embodiment uses a single-core processor as an example to describe the complete process of switching VLEN from 512 bits to 128 bits. It is assumed that the maximum VLEN_max implemented by the chip is 512 bits, and the system defaults to VLEN=512 bits after power-on.

[0079] When the program reaches a power-sensitive phase or the scheduler determines that the parallelism requirement of the current task is reduced, the software rewrites the vlencfg register to 128 bits at a safe point (when there are no in-transit vector instructions) using the CSR instruction. For example... Figure 2 As shown, the configuration activation process is as follows:

[0080] The software executes the csrrw or csrrs instruction to write the target value 128 to the vlencfg register. The configuration control module detects the change in the vlencfg register value and initiates the configuration activation process. The validity verification circuit compares the vlencfg register with the preset set of valid VLEN values ​​(32, 64, 128, 256, 512, 1024 bits) to confirm that the 128 bits belong to the set of valid values ​​and do not exceed VLEN_max = 512 bits.

[0081] After successful verification, the configuration control module sends an update signal to each module:

[0082] Vector register group: VLEN selects the decoding module to generate bank_mask, retains only the lower 128 bits of valid storage (bank0), shuts off the local clock for the integrated clock gating unit (ICG) of the higher banks, sets the write mask to 0, and does not select the higher banks in the read selection path;

[0083] Vector register byte width return logic: Receive the current VLEN=128 bits, and output VLENB=16 in real time through a right shift operation of 3 bits;

[0084] Vector instruction splitting logic: Receive the current VLEN=128 bits, and recalculate the splitting granularity and progress count based on the new VLEN.

[0085] Once the configuration is complete, the VLEN configuration complete signal is set, indicating that the configuration has taken effect. The software can confirm the configuration status by reading the VLENB register (the reading result is 16, i.e., 128 divided by 8), and continue executing subsequent vector code after confirming that the configuration has taken effect.

[0086] If a high-throughput phase is subsequently entered (such as matrix multiplication, convolution operations, or signal processing tasks), the VLEN can be switched back from 128 bits to 256 bits or 512 bits using the same process, enabling programmable switching between performance and power consumption.

[0087] Example 2: Specific circuit implementation of configurable bit width for vector register set

[0088] like Figure 3 As shown, the vector register group uses the chip's maximum bit width VLEN_max as the physical upper limit, and implements the visible bit width configuration by grouping by bank or slice.

[0089] In this embodiment, VLEN_max = 1024 bits, and each vector register is divided into eight 128-bit banks (bank0 to bank7). After the vlencfg register is decoded with a valid value, it outputs the current vector register length configuration value (current_vlen) and the configuration valid signal (config_valid). The VLEN selection decoding module generates a bank_mask[i] signal based on the current vector register length configuration value. The bank covered by the current VLEN corresponds to bank_mask[i] = 1, and the higher-order banks beyond the current VLEN correspond to bank_mask[i] = 0.

[0090] bank_clk_en[i] = vector_reg_write_en & config_valid & bank_mask[i]. bank_clk_en[i] is connected to the enable terminal of the integrated clock gating unit (ICG) before the i-th bank. The ICG outputs bank_clk[i] as the local clock of that bank.

[0091] The valid groups corresponding to each VLEN configuration are shown in Table 1:

[0092] Table 1

[0093] Configure VLEN Effective grouping Blocked or closed parts 32 or 64-bit low-position slice within bank0 bank0 high-level slice and other banks 128-bit bank0 bank1 to bank7 256-bit bank0 to bank1 bank2 to bank7 512 bits bank0 to bank3 bank4 to bank7 1024-bit bank0 to bank7 none

[0094] Clock gating can reduce the power consumption of dynamic flipping without using the high-order bank, without changing the physical structure of the register or the way the state is maintained.

[0095] Example 3: Specific Implementation of Vector Instruction Decomposition

[0096] This embodiment uses a vector addition instruction vadd.vv as an example to illustrate the working process of vector instruction decomposition logic.

[0097] Assume the current vector register length VLEN_cur=256, register set multiple LMUL=1, element width SEW=32, and vector execution unit single processing width EXEC_WIDTH=128.

[0098] After the vector instruction is issued to the vector instruction splitting logic, the decoding unit extracts LMUL=1, SEW=32 and instruction type from the vector instruction information; the instruction splitting unit calculates based on the current VLEN=256: the splitting bit width group_bits that the register group needs to cover = VLEN_cur × LMUL = 256 × 1 = 256, and the number of sub-instructions = the result of dividing the splitting bit width that the register group needs to cover by the single processing width of the vector execution unit by rounding up, that is, the rounding up operation (256 divided by 128) = 2.

[0099] After the split count counter (split_cnt) is written to 2, the split module generates the first sub-instruction, covering bit offsets 0 to 127 (corresponding to element slots 0 to 3), and sends it to the vector execution unit, decrementing split_cnt to 1. Subsequently, the second sub-instruction is generated, covering bit offsets 128 to 255 (corresponding to element slots 4 to 7), and sent to the vector execution unit, decrementing split_cnt to 0. Once split_cnt is zeroed, the split completion signal split_done is set, indicating that all sub-instructions of the current vector instruction have been sent.

[0100] During the above splitting process, each subinstruction carries register set bit offset, subinstruction processing bit width, element slot range, destination register offset, and mask information to ensure that subinstructions are executed sequentially and results are correctly merged. This splitting belongs to the subinstruction or micro-operation splitting within the microarchitecture and is only used to adapt to the current VLEN configuration and vector execution unit width. It does not change the RVV instruction encoding, software-visible semantics, or program execution results.

[0101] Example 4: Multi-core SMP Synchronous Switching

[0102] This embodiment uses a quad-core SMP system as an example to describe the complete process of multi-core VLEN synchronous switching. The system sets up global synchronization registers: the target VLEN register (vlen_sync_target), used to store the target VLEN value for this switch; the switch request register (vlen_sync_req), set by the master core to initiate the switch; the ready mask register (vlen_ready_mask), used to record online cores that have completed safety point preparation; the commit epoch register (vlen_commit_epoch), written by the master core to trigger synchronous commits from all cores; and the completion mask register (vlen_done_mask), used to record cores that have completed VLEN configuration updates.

[0103] The multi-core VLEN synchronous switching process is as follows:

[0104] 1. The main core initiates a switchover.

[0105] The master core acquires the lock (vlen_switch_lock), writes the target VLEN value 256 into the target VLEN register (vlen_sync_target), sets the switch request register (vlen_sync_req), and sends a VLEN_PREPARE request to all slave cores via inter-core interrupt (IPI).

[0106] 2. Each core enters its local safe point.

[0107] The main core enters the VLEN switchover preparation process locally, waiting for all preceding instructions of the main core to retire and for all valid signals at each stage of the vector execution pipeline to be 0, and for both the vector memory access queue and the vector write-back queue to be empty.

[0108] After receiving an inter-core interrupt from the core, the target VLEN register (vlen_sync_target) is read, subsequent vector instruction issuance is stopped, and the core waits for the core to reach a safe point, i.e., all preceding instructions have retired, all valid signals at each stage of the vector execution pipeline are 0, and the vector memory access queue and vector write-back queue are empty.

[0109] 3. Feedback readiness status of each core

[0110] Once each core reaches a safe point, the corresponding bit in the ready mask register (vlen_ready_mask) for that core is set, and the bits corresponding to all online cores in the master core's waiting ready mask register are also set.

[0111] 4. The main core triggers synchronous commit.

[0112] Once the master core confirms that all online cores are ready, it writes to the commit round register (vlen_commit_epoch) to trigger a synchronous commit.

[0113] 5. Update configurations synchronously on all cores.

[0114] After each core detects an update to the commit epoch register (vlen_commit_epoch), it samples the target VLEN register (vlen_sync_target) in the same commit epoch and updates its own vlencfg register. When the corresponding CSR instruction in each core's vlencfg register is updated and retires, a flush signal is generated, flushing the subsequently fetched instructions.

[0115] 6. Completion status of feedback from each core

[0116] After each core completes the return logic of the vector register byte width, the bit width configuration of the vector register group, and the vector instruction splitting configuration update, it sets the corresponding bit in the completion mask register (vlen_done_mask) for its own core. The bits corresponding to all online cores in the main core's waiting completion mask register are all set.

[0117] 7. Switching complete

[0118] The master core clears the switch request register (vlen_sync_req) and releases the lock (vlen_switch_lock). At this point, all cores have completed the VLEN synchronization switch and present a consistent VLEN view to the software.

[0119] The above-mentioned synchronization switching means that the software presents a consistent VLEN view under the same synchronization cycle, and does not require all cores to complete the update at the exact same physical clock edge.

[0120] Example 5: System Implementation

[0121] like Figure 1 As shown, the RISC-V vector extension implementation system supporting hardware-configurable vector register length provided by this invention includes:

[0122] A custom control status register is used to store the current vector register length configuration value; specifically, the vlencfg register has a bit width of 11 bits, and bits [10:0] are used to store the VLEN configuration value.

[0123] The vector register group includes multiple configurable bit-width vector registers, which selectively enable a portion of the storage bit width according to the current vector register length configuration value. Specifically, each vector register is divided into multiple storage groups, and each storage group corresponds to a clock gating unit. The clock gating unit turns the local clock of the corresponding storage group on or off according to the bit width selection signal output by the configuration control module.

[0124] The vector register byte width return logic is used to output the byte width value of the current vector register length. It uses combinational logic circuitry to receive the current vector register length configuration value in real time and output the byte width value of the current vector register length by dividing by 8.

[0125] The vector instruction splitting logic is used to split a vector instruction into multiple sub-instructions based on the current vector register length configuration value.

[0126] The configuration control module is used to detect changes in the value of the custom control status register, perform validity checks, and distribute the validated configuration value to the vector register group, vector register byte width return logic, and vector instruction splitting logic. The configuration control module includes:

[0127] The validity verification circuit is used to compare the target vector register length configuration value with the preset set of valid values ​​and output the verification result;

[0128] Configure a signal distribution unit to synchronously output the current vector register length value to each module after the verification is passed;

[0129] The configuration completion indicator unit is used to set the configuration completion signal after all hardware modules have completed the configuration update.

[0130] Design Requirements and Limitations

[0131] Based on the above embodiments, the present invention should meet the following design requirements and limitations in specific implementations:

[0132] (1) The configurable VLEN must belong to the set of legal values ​​supported by the hardware and must not exceed the maximum VLEN_max implemented by the chip;

[0133] (2) VLEN switching should be performed when the vector pipeline is idle or at a safe point where writeback has been completed. If necessary, the microarchitecture should provide a vector unit pause or flush mechanism.

[0134] (3) In a multi-core system, if the software requires SMP symmetry, inter-core synchronization or barrier mechanisms should be used to ensure that all cores continue to execute in parallel after the switch is completed.

[0135] (4) Write permissions to the vlencfg register can be limited to privileged mode (M mode or S mode) to avoid context inconsistency caused by misconfiguration of user mode.

[0136] This invention can be implemented in RISC-V processor chips and is applicable to various scenarios such as embedded devices, edge computing nodes, server chips, and multi-core SMP architecture systems. Those skilled in the art should understand that the specific embodiments described above are for illustrative purposes only and not for limiting the invention. Without departing from the concept of this invention, those skilled in the art can make various modifications, equivalent substitutions, or improvements to the technical solutions of this invention, all of which fall within the protection scope of this invention.

[0137] The above are merely specific embodiments of the present invention, but the technical features of the present invention are not limited thereto. Any simple changes, equivalent substitutions, or modifications made based on the present invention to solve essentially the same technical problems and achieve essentially the same technical effects are all covered within the protection scope of the present invention.

Claims

1. A RISC-V vector extension implementation method supporting hardware-configurable vector register length, characterized in that, Includes the following steps: A custom control status register is provided, which is used to store the current vector register length configuration value; Monitor whether the value of the custom control status register changes, and the change is when the custom control status register is written with the target vector register length configuration value; When a change in the value of the custom control status register is detected, the validity of the target vector register length configuration value is first checked. After the verification is successful, the target vector register length configuration value is distributed to each hardware module to update the behavior of each hardware module; Each hardware module includes a vector register group, vector register byte width return logic, and vector instruction splitting logic.

2. The RISC-V vector extension implementation method supporting hardware-configurable vector register length according to claim 1, characterized in that, The custom control status register is the vlencfg register, which has a bit width of 11 bits, where bits [10:0] are used to store the vector register length configuration value.

3. The RISC-V vector extension implementation method supporting hardware-configurable vector register length according to claim 1, characterized in that, The validity check includes: determining whether the target vector register length configuration value belongs to the set of valid values ​​supported by the hardware and does not exceed the maximum vector register length implemented by the chip; if the check fails, the write operation is ignored and the current vector register length configuration value remains unchanged.

4. The RISC-V vector extension implementation method supporting hardware-configurable vector register length according to claim 1, characterized in that, After successful verification, a configuration completion handshake signal is sent to indicate that the configuration has taken effect.

5. The RISC-V vector extension implementation method supporting hardware-configurable vector register length according to claim 1, characterized in that, The behavior of updating each hardware module includes configuring the register width of the vector register group according to the current vector register length configuration value. Specifically, each vector register is divided into multiple storage groups, and the storage groups are selectively enabled or disabled based on the current vector register length configuration value; wherein, the local clock of the disabled storage group is turned off.

6. A RISC-V vector extension implementation method supporting hardware-configurable vector register length according to claim 5, characterized in that, The local clock of the masked memory packet is turned off by a clock gating unit, the enable terminal of which is connected to the enable signal of the memory packet, which is generated by decoding the current vector register length configuration value.

7. A RISC-V vector extension implementation method supporting hardware-configurable vector register length according to claim 1, characterized in that, The vector register byte width return logic outputs the byte width value of the current vector register length based on the current vector register length configuration value.

8. A RISC-V vector extension implementation method supporting hardware-configurable vector register length according to claim 7, characterized in that, The vector register byte width return logic uses combinational logic circuits to receive the current vector register length configuration value in real time and output the current vector register length byte width value by dividing by 8.

9. A RISC-V vector extension implementation method supporting hardware-configurable vector register length according to claim 1, characterized in that, The vector instruction splitting logic splits the vector instruction into multiple sub-instructions based on the current vector register length configuration value.

10. A RISC-V vector extension implementation method supporting hardware-configurable vector register length according to claim 9, characterized in that, The vector instruction splitting logic calculates the number of sub-instructions that the current vector instruction needs to be split into based on the current vector register length configuration value, the vector execution unit execution width, the number of vector register groups, and the element width, and records the splitting progress; the number of sub-instructions is: the result obtained by dividing the product of the current vector register length and the number of vector register groups by the vector execution unit execution width and rounding it up.

11. A RISC-V vector extension implementation method supporting hardware-configurable vector register length according to claim 10, characterized in that, The splitting progress is recorded by a splitting quantity counter. Each time a sub-instruction is issued, the splitting quantity counter is decremented by 1 until it reaches zero, indicating that the splitting is complete.

12. The RISC-V vector extension implementation method supporting hardware-configurable vector register length according to claim 1, characterized in that, The vector register length configuration switch is performed at a safe point, which includes: all instructions prior to the custom control status register write operation have retired, and all valid signals at each stage of the vector execution pipeline are 0, and the vector memory access queue and vector write-back queue are empty; after detecting an instruction to write to the custom control status register, subsequent instruction issuance is stopped, and the configuration update is performed after the safe point is reached, and subsequent fetched instructions are flushed when the custom control status register write operation retires.

13. A RISC-V vector extension implementation method supporting hardware-configurable vector register length according to claim 1, characterized in that, In a multi-core system, inter-core synchronization enables the master core and at least one slave core to switch to a consistent target vector register length configuration value in the same synchronization round.

14. A RISC-V vector extension implementation method supporting hardware-configurable vector register length according to claim 13, characterized in that, The inter-core synchronization includes: The master core initiates a vector register length switching request and notifies the slave core to prepare for the switch via an inter-core interrupt. The master core and the slave core respectively enter the local safe point, waiting for all preceding instructions of the local core to retire and for all valid signals of each stage of the vector execution pipeline to be 0, and for the vector memory access queue and the vector write-back queue to be empty. Once each core reaches the safety point, it reports its readiness status to the main core. After the master core confirms that all online cores are ready, it triggers a synchronous commit, enabling all cores to update their custom control status registers and related hardware configurations in the same synchronization round.

15. A RISC-V vector extension implementation system supporting hardware-configurable vector register length, characterized in that, include: A custom control status register is used to store the current vector register length configuration value; The vector register set includes multiple configurable bit-width vector registers, which selectively enable a portion of the storage bit width based on the current vector register length configuration value; The vector register byte width return logic is used to output the byte width value of the current vector register length; Vector instruction splitting logic is used to split vector instructions into multiple sub-instructions based on the current vector register length configuration value; The configuration control module is used to detect changes in the value of the custom control status register, perform a validity check, and distribute the configuration value that passes the check to the vector register group, the vector register byte width return logic, and the vector instruction splitting logic.

16. A RISC-V vector extension implementation system supporting hardware-configurable vector register length according to claim 15, characterized in that, Each vector register in the vector register group is divided into multiple storage groups, and each storage group corresponds to a clock gating unit. The clock gating unit turns the local clock of the corresponding storage group on or off according to the bit width selection signal output by the configuration control module.

17. A RISC-V vector extension implementation system supporting hardware-configurable vector register length according to claim 15, characterized in that, The configuration control module includes: A validity verification circuit is used to compare the target vector register length configuration value with a preset set of valid values ​​and output the verification result. Configure a signal distribution unit to synchronously output the current vector register length value to the vector register group, the vector register byte width return logic, and the vector instruction splitting logic after the verification is passed; The configuration completion indicator unit is used to set the configuration completion signal after all hardware modules have completed the configuration update.

18. A chip, characterized in that, Including a RISC-V vector extension implementation system that supports hardware-configurable vector register length as described in any one of claims 15-17.

Images