How RISC-V Addresses Hardware Fragmentation Issues

1Introduction

In recent years, the rise of RISC-V has drawn attention from the IC industry towards this rapidly developing architecture. However, when it comes to this young architecture, the first things that come to mind are its weak ecosystem and hardware fragmentation. From the very beginning, RISC-V aimed to provide a highly modular and extensible instruction set, allowing users to even extend the instruction set themselves. This flexibility is beneficial for chip optimization in specific directions. However, the downside is that different manufacturers support extensions differently, and many have their own defined instruction sets, which further lowers the competitiveness of RISC-V, especially in high-end application scenarios that rely heavily on software ecosystems.

2Overview

Currently, leading international RISC-V manufacturers like SiFive have launched several RISC-V IPs, such as the P670, which achieves >12 SpecINT2k6/GHz, with performance roughly at the level of A78. The P870, on the other hand, achieves >18 SpecINT2k6/GHz, pushing performance closer to advanced ARM core standards. Have you noticed that the P670’s official website describes it as supporting the RVA22 profile specification, while the P870 supports the RV23A profile specification? What is RVA? The introduction of RVA was actually meant to address the issue of hardware manufacturers’ chip implementations being fragmented. Currently, there are three standards: RVA, RVB, and RVM, and this article will only introduce RVA.

Essentially, RVA sets requirements on the types and numbers of extensions that must be implemented. In simple terms, if a chip claims to comply with the RVA specification, certain optional extensions within some specs will no longer be “optional” but rather “mandatory” to implement. For example, the compressed instruction C extension is not a standard requirement, but in RVA, it is mandatory; otherwise, it would not meet the RVA standard. RVA also has different versions; for instance, the RVA22 version does not require the Svnapot extension to be implemented, while the RVA23 version mandates its implementation, or else the core does not comply with the RVA23 standard. The emergence of such standards helps standardize the types of core implementations while retaining flexibility, benefiting the unification of chip implementations among hardware manufacturers and fostering the development of the software ecosystem.

3Introduction to RVA23

RVA23 includes user-mode (RVA23U64) and supervisor-mode (RVA23S64), each containing mandatory Base, mandatory Extensions, and some optional Extensions.

Below are excerpts from the RVA specifications:

RVA23U64 Mandatory Base
RV64I is the mandatory base ISA for RVA23U64 and is little-endian. As per the unprivileged architecture specification, the ecall instruction causes a requested trap to the execution environment.

RVA23U64 Mandatory Extensions
The following mandatory extensions were present in RVA22U64.

M Integer multiplication and division.

A Atomic instructions.

F Single-precision floating-point instructions.

D Double-precision floating-point instructions.

C Compressed Instructions.

Zicsr CSR instructions. These are implied by presence of F.

Zicntr Base counters and timers.

Zihpm Hardware performance counters.

Ziccif Main memory regions with both the cacheability and coherence PMAs must support instruction fetch, and any instruction fetches of naturally aligned power-of-2 sizes up to min(ILEN,XLEN) (i.e., 32 bits for RVA23) are atomic.

Ziccrse Main memory regions with both the cacheability and coherence PMAs must support RsrvEventual.

Ziccamoa Main memory regions with both the cacheability and coherence PMAs must support AMOArithmetic.

Zicclsm Misaligned loads and stores to main memory regions with both the cacheability and coherence PMAs must be supported.

Za64rs Reservation sets are contiguous, naturally aligned, and a maximum of 64 bytes.

Zihintpause Pause instruction.

Zba Address computation.

Zbb Basic bit manipulation.

Zbs Single-bit instructions.

Zic64b Cache blocks must be 64 bytes in size, naturally aligned in the address space.

Zicbom Cache-Block Management Operations.

Zicbop Cache-Block Prefetch Operations.

Zicboz Cache-Block Zero Operations.

Zfhmin Half-Precision Floating-point transfer and convert.

Zkt Data-independent execution time.

The following mandatory extensions are new in RVA23U64:

V Vector Extension.

Note
V was optional in RVA22U64.
Zvfhmin Vector FP16 conversion instructions.

Zvbb Vector bit-manipulation instructions.

Zvkt Vector data-independent execution time.

Zihintntl Non-temporal locality hints.

Zicond Conditional Zeroing instructions.

Zimop Maybe Operations.

Zcmop Compressed Maybe Operations.

Zcb Additional 16b compressed instructions.

Zfa Additional scalar FP instructions.

Zawrs Wait on reservation set.

RVA23U64 Optional Extensions
RVA23U64 has ten profile options (Zvkng, Zvksg, Zacas, Zvbc, Zfh, Zbc, Zvfh, Zfbfmin, Zvfbfmin, Zvfbfwma).

Localized Options
The following localized options are new in RVA23U64:

Zvkng Vector Crypto NIST Algorithms including GHASH.

Zvksg Vector Crypto ShangMi Algorithms including GHASH.

Note
The scalar crypto extensions Zkn and Zks that were options in RVA22 are not options in RVA23. The goal is for both hardware and software vendors to move to use vector crypto, as vectors are now mandatory and vector crypto is substantially faster than scalar crypto.
Note
We have included only the Zvkng/Zvksg options with GHASH to standardize on a higher performance crypto alternative. Zvbc is listed as a development option for use in other algorithms, and will become mandatory. Scalar Zbc is now listed as an expansion option, i.e., it will probably not become mandatory.
Development Options
The following are new development options intended to become mandatory in RVA24U64:

Zacas Compare-and-swap

Zvbc Vector carryless multiply.

Expansion Options
The following expansion options were also present in RVA22U64:

Zfh Scalar Half-Precision Floating-Point (FP16).

The following are new expansion options in RVA23U64:

Zbc Scalar carryless multiply.

Zvfh Vector half-precision floating-point (FP16).

Zfbfmin Scalar BF16 FP conversions.

Zvfbfmin Vector BF16 FP conversions.

Zvfbfwma Vector BF16 widening mul-add.

Transitory Options
There are no transitory options in RVA23U64.

Note
Scalar crypto is no longer an option in RVA23U64, though the Zbc extension has now been exposed as an expansion option.
RVA23U64 Recommendations
Implementations are strongly recommended to raise illegal-instruction exceptions on attempts to execute unimplemented opcodes.

RVA23S64 Profile
The RVA23S64 profile specifies the ISA features available to a supervisor-mode execution environment in 64-bit applications processors. RVA23S64 is based on privileged architecture version 1.13.

Note
Priv 1.13 is still being defined.
RVA23S64 Mandatory Base
RV64I is the mandatory base ISA for RVA23S64 and is little-endian. The ecall instruction operates as per the unprivileged architecture specification. An ecall in user mode causes a contained trap to supervisor mode. An ecall in supervisor mode causes a requested trap to the execution environment.

RVA23S64 Mandatory Extensions
The following unprivileged extensions are mandatory:

The RVA23S64 mandatory unprivileged extensions include all the mandatory unprivileged extensions in RVA23U64.

Zifencei Instruction-Fetch Fence.

Note
Zifencei is mandated as it is the only standard way to support instruction-cache coherence in RVA23 application processors. A new instruction-cache coherence mechanism is under development (tentatively named Zjid) which might be added as an option in the future.
The following privileged extensions are mandatory:

Ss1p13 Privileged Architecture version 1.13.

Note
Ss1p13 supersedes Ss1p12 but is not yet ratified.
The following privileged extensions were also mandatory in RVA22S64:

Svbare The satp mode Bare must be supported.

Sv39 Page-Based 39-bit Virtual-Memory System.

Svade Page-fault exceptions are raised when a page is accessed when A bit is clear, or written when D bit is clear.

Ssccptr Main memory regions with both the cacheability and coherence PMAs must support hardware page-table reads.

Sstvecd stvec.MODE must be capable of holding the value 0 (Direct). When stvec.MODE=Direct, stvec.BASE must be capable of holding any valid four-byte-aligned address.

Sstvala stval must be written with the faulting virtual address for load, store, and instruction page-fault, access-fault, and misaligned exceptions, and for breakpoint exceptions other than those caused by execution of the EBREAK or C.EBREAK instructions. For illegal-instruction exceptions, stval must be written with the faulting instruction.

Sscounterenw For any hpmcounter that is not read-only zero, the corresponding bit in scounteren must be writable.

Svpbmt Page-Based Memory Types

Svinval Fine-Grained Address-Translation Cache Invalidation
The following are new mandatory extensions:

Svnapot NAPOT Translation Contiguity

Note
Svnapot was optional in RVA22.
Sstc supervisor-mode timer interrupts.

Note
Sstc was optional in RVA22.
Sscofpmf Count Overflow and Mode-Based Filtering.

Ssnpm Pointer masking, with senvcfg.PME and henvcfg.PME supporting, at minimum, settings PMLEN=0 and PMLEN=7.

Ssu64xl sstatus.UXL must be capable of holding the value 2 (i.e., UXLEN=64 must be supported).

Note
Ssu64xl was optional in RVA22.
H The hypervisor extension.

Note
The hypervisor was optional in RVA22.
Note
The following extensions were required when the hypervisor was implemented in RVA22.

Ssstateen Supervisor-mode view of the state-enable extension. The supervisor-mode (sstateen0-3) and hypervisor-mode (hstateen0-3) state-enable registers must be provided.

Shcounterenw For any hpmcounter that is not read-only zero, the corresponding bit in hcounteren must be writable.

Shvstvala vstval must be written in all cases described above for stval.

Shtvala htval must be written with the faulting guest physical address in all circumstances permitted by the ISA.

Shvstvecd vstvec.MODE must be capable of holding the value 0 (Direct). When vstvec.MODE=Direct, vstvec.BASE must be capable of holding any valid four-byte-aligned address.

Shvsatpa All translation modes supported in satp must be supported in vsatp.

Shgatpa For each supported virtual memory scheme SvNN supported in satp, the corresponding hgatp SvNNx4 mode must be supported. The hgatp mode Bare must also be supported.
RVA23S64 Optional Extensions
RVA23S64 has ten unprivileged options (Zvkng, Zvksg, Zacas, Zvbc, Zfh, Zbc, Zvfh, Zfbfmin, Zvfbfmin, Zvfbfwma) from RVA23U64, and six privileged options (Sv48, Sv57, Svadu, Zkr, Sdext, Ssstrict).

Localized Options
There are no privileged localized options in RVA23S64

Development Options
There are no privileged development options in RVA23S64.

Expansion Options
The following privileged expansion options were present in RVA22S64:

Sv48 Page-Based 48-bit Virtual-Memory System.

Sv57 Page-Based 57-bit Virtual-Memory System.

Zkr Entropy CSR.
The following are new privileged expansion options in RVA23S64

Svadu Hardware A/D bit updates.

Sdext Debug triggers

Ssstrict No non-conforming extensions are present. Attempts to execute unimplemented opcodes or access unimplemented CSRs in the standard or reserved encoding spaces raises an illegal instruction exception that results in a contained trap to the supervisor-mode trap handler.

Note
Ssstrict does not prescribe behavior for the custom encoding spaces or CSRs.
Transitory Options
There are no privileged transitory options in RVA23S64.

RVA23S64 Recommendations
Implementations are strongly recommended to raise illegal-instruction exceptions when attempting to execute unimplemented opcodes or access unimplemented CSRs.

4Conclusion

Currently, the imperfections of the RISC-V architecture are gradually being addressed, and the fragmentation issue is being organized. The rumors that RISC-V cannot achieve high performance have also been dispelled by various manufacturers. Many major software companies are now paying attention to RISC-V; perhaps a bright future for RISC-V is on the horizon.

Thank you for today’s sharing. If you have any original technical articles related to electronic design or others, feel free to submit them to us. We will select the best ones for publication, and you will receive a reward for published articles!How RISC-V Addresses Hardware Fragmentation IssuesFriendly Reminder:

Due to recent changes in the WeChat public platform’s push rules, many readers have reported not seeing updated articles in a timely manner. According to the latest rules, we recommend frequently clicking “Recommended Reading, Sharing, and Collecting” to become a regular reader.

Recommended Reading:

  • Zhihui Jun is up to something big again!

  • “The third largest wafer factory in mainland China” is reported for procurement bribery.

  • “A shocking inside story exposed: using pirated EDA, chip coverage over 20% dared to tape out”!

Please click 【Looking】 to give the editor a thumbs up!

How RISC-V Addresses Hardware Fragmentation Issues

Leave a Comment