谷动谷力

 找回密码
 立即注册
查看: 138|回复: 0
打印 上一主题 下一主题
收起左侧

RISC-V如何解决硬件碎片化的问题?

[复制链接]
跳转到指定楼层
楼主
发表于 2024-1-30 17:51:24 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
RISC-V如何解决硬件碎片化的问题?



1导言

最近几年RISC-V的大火,让IC行业开始关注RISC-V这个迅猛发展的架构。但提到这个年轻的架构,大家最先想到的是,薄弱的生态,硬件的碎片化。RISC-V从发展之初就旨在提供高度模块化和可拓展的指令集,用户甚至可以自己拓展指令集,这种灵活性有利于特定方向的芯片优化。但随之而来的问题就是各个厂商对于拓展的支持各不相同,甚至有不少自己定义的指令集,让原本就生态脆弱的RISC-V竞争力更低,尤其是在软件生态依赖很强的高端应用场景。


2 介绍

目前国际比较领先的RISC-V厂商,sifive,推出的几款RISC-V的IP,例如P670,>12 SpecINT2k6/GHz,性能大致在A78水平。而P870,>18 SpecINT2k6/GHz,性能则更进一步,靠近ARM的先进Core水准。不知道大家有没有关注到P670官网描述P670支持RVA22 profile specification,而P870支持的是RV23A profile specification。这里的RVA是什么?实际RVA本身的提出就是为了解决硬件厂商对芯片实现“脆片化”的问题。这个标准目前有三个,RVA,RVB,RVM,本文仅介绍RVA。


本质上RVA是对拓展实现种类和数量的要求,简单说就是如果宣称符合RVA规范,那么有些Spec里面的可选拓展将不再是“可选的”而是“强制”需要实现的。例如对压缩指令C拓展不是标准必须要实现的,但在RVA里则是强制需要实现的,否则就不是RVA标准。RVA同样分版本,例如RVA22版本不强制实现Svnapot拓展,而到了RVA23,该拓展强制需要实现,否则Core不符合RVA23标准。这种规范的出现则在保留灵活性的基础上,规范了Core“实现”的种类。有利于统一硬件厂商的芯片实现,利好软件生态的发展。


3 RVA23介绍

RVA23包含user-mode(RVA23U64)和supervisor-mode (RVA23S64),每个都包含强制实现的Base,强制实现的Extensions,以及部分可选的Extensions。


下面摘自RVA部分规范:

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.

4结语

目前RISC-V架构的不完善正在慢慢补全,碎片化的问题正在规整,而RISC-V无法实现高性能的传言也被各个厂商打破,目前不少的软件大厂也关注RISC-V,也许RISC-V的光明未来正在到来。



+10
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|Archiver|手机版|深圳市光明谷科技有限公司|光明谷商城|Sunshine Silicon Corpporation ( 粤ICP备14060730号|Sitemap

GMT+8, 2024-4-28 23:14 , Processed in 0.082326 second(s), 39 queries .

Powered by Discuz! X3.2 Licensed

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表