CNRV

(图片来源于Twitter等）

RISC-V软核大赛结果公布

RISC-V基金会官方举办的RISC-V软核大赛在RISC-V Summit上公布。

• 第一名: Charles Papond的VexRiscv: repo: SpinalHDL/VexRiscvSoftcoreContest2018
• 第二名: Antti Lukats的Engine-V: repo: micro-FPGA/engine-V
• 第三名: Changyi Gu的PulseRain Reindeer: repo: PulseRain/Reindeer
• 最佳创意: Olof Kindgren的SERV: repo: olofk/serv

Links:

• CNRV最近也报道了RISC-V软核大赛获奖者心得
• RISC-V SoftCPU Contest Winners Demonstrate Cutting-Edge RISC-V Implementations for FPGAs

Daniel Lustig获2018 RISC-V Foundation Board Of Directors’ Award

恭喜来自NVIDIA的Senior Research Scientist，同时也是RISC-V基金会存储模型工作组的主席和年轻帅小伙Daniel Lustig获得了基金会颁发的2018 RISC-V Foundation Board Of Directors’ Award！

Links

• Daniel Lustig, Chairman Of The RISC-V Memory Model Task Group, Receives Inaugural 2018 RISC-V Foundation Board Of Directors’ Award At The RISC-V Summit
• Daniel Lustig个人网站
• Daniel Lustig, Chairman of the RISC-V Memory Model Task Group, Receives Inaugural 2018 RISC-V Foundation Board of Directors’ Award at the RISC-V Summit

RV新闻

RISC-V基金会和Linux基金会达成合作关系

RISC-V基金会和Linux基金会最近宣布达成合作关系，RISC-V基金会将得到Linux基金会在工具基础架构、服务和培训等方面的支持。

Links

• The Linux Foundation And RISC-V Foundation Announce Joint Collaboration To Enable A New Era Of Open Architecture
• Linux lobby org joins with RISC-V bods to promote open chip spec

RISC-V 快速中断小组成立

Krste Asanovic 教授在 RISCV ISA Dev 邮件列表里宣布成立快速中断小组（Fast Interrupts Task Group），他本人是主要负责人，另一位是来自 Andes 的 Kevin Chen。为直接针对单个硬件线程 hart （hardware thread）的中断，开发一个低延迟，向量化，基于优先级，抢占式的中断策略，兼容现存的 RISC-V 标准并可以向多核扩展。提供硬件标准和软件 ABIs/APIs 。标准化编译器用来标注中断处理函数的规范。

邮件列表

SiFive Proposal for a RISC-V Core-Local Interrupt Controller

西部数据的的最新RISC-V相关进展

西部数据在RISC-V Summit上公布了其最新的RISC-V进展以及对社区的贡献。分别是：

1. SweRV处理器技术细节和开源计划
2. OmniXtend跨芯片缓存一致性协议
3. SweRV指令集模拟器 (ISS)

首先是SweRV处理器，这个处理器目前还没有开源，所以在Github上依然是empty的状态。但是对应的指令集仿真器已经开源（GPL-3.0），以方便用户在没有硬件的情况下完成一些开发工作。

如果开源，这颗开源CPU Core将是目前能找到的性能最高的RV Core。

接下来是OmniXtend，一个通讯协议，用于通过网络包(L1 Ethernet)来使得多个节点上的CPU能够有统一的共享存储(NUMA)。

从Github上的Repo来看，这个工作一定程度上基于TileLink，是类似ChipLink的一种序列化方案，当然OmniXtend和TileLink还是明显不同的。

This initial release of OmniXtend is based on a simple serialization of the TileLink coherence protocol created for the RISC-V ecosystem. Future evolution may diverge from the on-chip coherence protocol to tackle issues of scalability and heterogeneity. It is important to keep in mind that OmniXtend is not equivalent to TileLink, despite their similarity at the moment.

来自Github

群头必须提醒的是，一个明显的趋势是，所有商业RISC-V CPU Core IP Vendor都必须面临：

1. 来自ARM等其他ISA标准CPU Core Vendor的竞争
2. 来自其他RISC-V CPU Core Vendor的竞争
3. 来自开源RISC-V CPU Core Vendor的竞争

这当中很多商业模式可能需要被重新审视。

Links:

• Western Digital Announces Plans for Its Own RISC-V Processor
• Early to embed and early to rise? Western Digital drops veil on SweRVy RISC-V based designs
• Western Digital Reveals SweRV RISC-V Core, Cache Coherency over Ethernet Initiative
• Western Digital 計劃性開放全新 RISC-V SweRV Core 原始碼，藉以為內部架構開發與支持 RISC-V 架構生態系統
• Github Repo: swerv-ISS
• Github Repo: swerv
• Github Repo: OmniXtend

Microsemi/Microchip的包含RISC-V硬核的FPGA SoC

Microsemi在最近的Summit上发布了其最新的SoC FPGA将包含来自SiFive的U54-MC Compelx。U54-MC和我们能够看到的SiFive HiFive-Unleashed上搭载的Complex类似，是4个可以运行Linux的核心和一个E级核心用于实时应用。除此之外，更多的高级调试功能也被加入了进来。而且片上的2MB L2 Cache存储器，既可以用做Cache，也可以作为ScratchPad或是直接存取，以满足客户在实时控制方面的需求。Microsemi还和antmicro合作，在其IDE中集成了Renode开发环境。

Announced today at the RISC-V Summit in Santa Clara, California, Microchip’s new PolarFire SoC architecture brings real-time deterministic asymmetric multiprocessing (AMP) capability to Linux platforms in a multi-core coherent central processing unit (CPU) cluster. The PolarFire SoC architecture, developed in collaboration with SiFive, features a flexible 2 MB L2 memory subsystem that can be configured as a cache, scratchpad or a direct access memory. This allows designers to implement deterministic real-time embedded applications simultaneously with a rich operating system for a variety of thermal and space constrained applications in collaborative, networked IoT systems.

…

PolarFire SoC includes extensive debug capabilities including instruction trace, 50 breakpoints, passive run-time configurable Advanced eXtensible Interface (AXI) bus monitors and FPGA fabric monitors, and Microchip’s built-in two-channel logic analyzer SmartDebug. The PolarFire SoC architecture includes reliability and security features such as single error correction and double error detection (SEC-DED) on all memories, physical memory protection, a differential power analysis (DPA) safe crypto core, defense-grade secure boot and 128Kb flash boot memory.

Links:

• Hard-Core RISC-V Cores Mate with FPGA
• Microsemi adds to RISC-V based FPGAs

UltraSoC “Any processor” lockstep解决方案

UltraSoC最近发布了其“Any Processor”lockstep解决方案以满足不断增长的如汽车等关键应用领域的安全（Safty）方面的需求。这套解决方案当然也支持RISC-V，能够让不论是开源还是商业的RISC-V CPU，都能使其通过lockstep来满足诸如ISO 26262等一系列严格的车规要求。

The new Lockstep Monitor consists of a set of configurable semiconductor IP (SIP) blocks that are protocol aware and can be used to cross-check outputs, bus transactions, code execution and even register states, between two or more redundant systems. It can be used with any processor architecture, including those – such as the emerging RISC-V architecture – which lack native support for lockstep configurations. In addition to traditional processor cores, it can also check other subsystems or accelerators. Because it is implemented in hardware, it responds at wire speed and imposes no execution overhead on the host system.

…

RISC-V is gaining increasing traction in safety-critical applications, particularly in the automotive industry. However, the RISC-V ecosystem as a whole currently lacks support for the functional safety and security principles – such as lockstep operation – mandated by global standards such as ISO26262 for functional safety, J3061 for cybersecurity, IEC 61508, EN50126/8/9 and CE 402/2013. UltraSoC’s Lockstep Monitor allows any RISC-V system, whether using open source or commercial cores, to incorporate sophisticated safety capabilities. The company will be presenting on automotive safety and security – jointly with ResilTech, the specialists in resilient computing for critical systems –at the upcoming RISC-V Summit (Santa Clara, 3 – 6 Dec 2018).

Link: UltraSoC launches “any processor” lockstep solution for safety-critical systems

Andes Custom Extension

AndesTech宣布支持ACE（Andes Custom Extension）用于让客户在其处理器中增加自定义指令以满足高性能应用。

“Using ACE is easy for designers who already know Verilog and C languages. With the powerful ACE constructs, richer functions can be implemented with fewer lines of code. ACE instructions not only accelerate applications by replacing a sequence of baseline instructions, but also reduce power consumption and code size,” said Dr. Charlie Su, CTO and Senior VP of Andes Technology. “By utilizing Andes highly-optimized V5 processor cores incorporated with effective ACE custom instructions that closely address application bottlenecks, youcan greatly enhance their capabilities to reach high performance design goals”.

Link: Andes Custom Extension™ Further Accelerates Your High Performance RISC-V Processors

生态系统

IAR和SiFive达成合作关系

你们喜欢用的IDE厂商IAR系统最近和SiFive达成合作关系以满足客户在编译器和调试器等方面的需求。

Link: IAR Systems and SiFive partner to meet customers’ demands for professional solutions for RISC-V

技术讨论

让我们重新思考SBI的定义

随着RISC-V特权指令集的逐步完善，关于SBI的讨论逐步增多。 然而，RISC-V并没有一个关于SBI的定义文档，甚至将原有关于SBI的说明从特权指令集中移出（priv v1.10）。 现在最广泛存在的SBI实现就是BBL中的SBI定义。 由于BBL是伯克利大学早期为了将Rocket-Chip运行于FPGA之上的简单bootloader实现，其中的SBI定义其实只是所需功能的拼凑，远远不是仔细考量多种SoC平台的结果，不利于作为一个SBI通用定义的基础。 针对该问题，Alex Bradbury提出，让我们重新思考SBI的定义问题。

在详细介绍关于此问题的冗长讨论之前，让小编先来科普一下什么是SBI。 SBI，或者Supervisor Binary Interface，是操作系统向底层（虚拟层、中间件、固件等等）提出服务请求的接口。 从优先级来说，也就是S模式下的程序向M(H)模式的服务程序提出请求的API接口。 从软件体系来说，操作系统通过SBI向底层硬件提出服务请求，某种程度上SBI为操作系统提供了争对底层硬件的隔离。

Alex首先提出：

我们当前缺少一个关于SBI设计的指导理念。最接近的描述是特权指令集的描述“如果所有的系统执行环境SEE支持单一的SBI接口，同一个OS镜像则可以运行在所有的系统执行环境上”。 特权指令集提出使用SBI于如下的用途：

• 初始化、保存和恢复非标准的ABI上下文扩展。
• 进程间的信号通信。
• 清除计时中断。
• 屏蔽、开启和询问外部中断。
• 修改time/cycle/instret控制寄存器。
• 设置计时中断。
• 页表同步（TLB shootdown）。

和现在已有的SBI实现（BBL中的）相比，这显然需要更多的功能，而且看起来杂乱无章。 到现在为止，似乎所有的SBI改进方案都不能覆盖上面提出的所有功能。 这到底是因为我们还没关于SBI的使用达成共识？还是这个描述其实还不完整？

在讨论中，有人提问“我们为什么要定义SBI呢，让操作系统全权控制不就好了吗？”

针对该问题，Samuel Falvo II回答说：

这其实是一个系统和硬件的抽象问题。所有可以在普通电脑上启动的系统都需要：

• 键盘驱动：用户可以定制bootloader选项。
• 显示驱动：显示bootloader定制参数。
• 存储驱动：将系统从存储设备导入内存。

这些“驱动”是最简单的能够控制这些设备的代码。 一个好的BIOS能提供这些功能并充当一个比较好的硬件抽象层，刚好能启动bootloader。

其实现在关于SBI的设计有三组不同的阵营：

• 喜欢UEFI的人会希望把所有的东西都扔到SBI中，包括你的“垃圾桶”。
• 喜欢BIOS的人希望SBI简化到只支持那些必须支持的硬件抽象。
• 不喜欢固件的人希望操作系统在启动之后接管一切（便不需要SBI）。

Michael Clark似乎并不认为UEFI有那么糟糕，他认为UEFI其实在系统之后便将绝大部分的工作扔给了操作系统，并不再处理关于虚拟化和安全的功能，也不提供运行时服务。 （显然在这一点上coreboot有不同理解。）他认为SBI的设计有三点内容需要考虑：

• 启动支持，类似ARM的EBBR或一个最小化的UEFI。
• 运行时的虚拟化支持（中断虚拟化、电源管理等等）。
• 关于不支持特性的模拟和虚拟化支持，比如浮点指令模拟、非对齐内存访问等等。

关于计时中断和时间相关的控制寄存器访问，有人提出使用SBI会非常缓慢，将一个指令的操作变成了上百条指令的操作。 这其实回到了为什么曾经的mtime控制寄存器现在被定义为一个IO空间上的寄存器的问题，涉及到处理器睡眠、变频的等等问题。 不过，Bruce Hoult指出，这是个错觉，其实差不多10条指令就可以了。 当程序进入了ecall环境内，下面的5条指令就能立即跳到对应的SBI服务函数：

lui t0,#ecallTableBase #or auipc
slli t1,a6,2 #3 for 64 bit
add t0,t0,t1
jr,nnn(t0) #lo bits of ecallTableBase, if not 4k aligned
# called function does the mret

在整个讨论中，一向异常活跃的Luke Kenneth Casson Leighton童鞋这回又跳出来，指责RISC-V基金会成员闭门讨论。 针对此问题，基金会主席Krste教授解释说，基金会一部分的讨论是封闭在基金会内部的主要原因是为了团结商业公司。 团结商业公司的原因是为了防止专利战。 现在的模式，所有入会的公司都承诺不会就指令集本身而发起知识产权诉讼，同时所有对指令集的贡献都是无偿贡献。 这样能解决一部分的专利战问题，尽管只是很小一部分，但仍然是一个好的开始。 更多的公司参与，将能推动RISC-V得更快发展，同时避免关于专利的愚蠢诉讼。 我们已经走到了这一步，不可能再退回去，使用一个完全开放的方式建立基金会，然后看是哪一种方式发展更快。 基金会已经承诺，标准、标准模型（golden model）和一致性测试集将一直开放，所以所有人都可以根据他们调整自己的产品。 基金会内部闭门的讨论实际上也是对所有会员（同意基金会协定）敞开的。

Link: 具体讨论请见邮件列表sw-dev和最新的RISC-V SBI草案GitHub。

用GCC为哈佛架构编译ELF

应该如何用gcc为哈佛结构编译elf呢？sw-dev列表里最近讨论了这个问题。

活跃的Liviu给大家科普了一下哈佛和冯·诺伊曼结构：传统上，哈佛结构的指令和数据储存空间是分开的，并且分别有单独的总线连接。与此相对的冯·诺依曼结构则是指令和数据共用储存空间，因此取指和取数的总线一般也是共用的。哈佛结构的优势在于取指取数可以同时进行。（编者按：现实的情况是，在用缓存的情况下，大部分的商用架构其实是一种两者的混合，或者称为Modified Harvard Architecture：靠近核心的用的是哈佛结构，比方说指令缓存和数据缓存有单独的总线连接和地址空间；从缓存往下的是冯·诺伊曼结构，共用地址空间和总线）

Liviu继续说虽然这只是个硬件层面的区别，但是对于软件还是有很大的影响的：其实ISO/IEC 14882 C++和ISO/IEC 9899 C标准都是有个暗含的前提，那就是地址空间是唯一的，比如说指向一个存储在RAM数据或者指向一个程序，甚至是常数，所用的指针并没有什么不一样（除了指针本身的数值以外）。换句话说，如果仅仅通过指针的数值，架构可以区分数据指针和程序指针，那样就没有问题。否则的话会有大麻烦，比如说是AVR8和老的PIC（编者按：AVR8和PIC都是哈佛结构）。

Nelson Ribeiro等几个人说，其实只要修改Linker Script就可以达到（比如使得.text字段从.data，.bss和可写的分开），或者是用32位里的最高位作为区分程序空间和数据空间等等。不过Liviu总结说：Linker Script之类的改动，必须得需要指针有足够的位宽，比方是4 Byte，否则就会有类似AVR8和PIC一样的问题，两者都只有16 bit的指针，而且会有（数据和程序）地址重叠的情况。

另外，Jatin Bhateja指出其实gcc和LLVM都有方法规避地址重叠的情况。

• gcc有-fdata-sections会把每个变量都放到单独的.data字段，类似的-ffunction-sections会把每个函数放到单独的.text字段。参见(1)。
• llvm则有P<address space>可以指定对应的程序空间地址。缺省值是地址空间0，也就是冯·诺伊曼结构的数据和程序空间相同。参见(2)。

Links:

• (1) GCC Manual: Options That Control Optimization
• (2) LLVM Language Reference Manual
• 讨论原文

M模式虚拟化（M-mode virtualization）

Kelly Dean 在邮件列表里介绍了有关M-mode虚拟化的长文内容。他首先强调，M-mode虚拟化的技术不复杂，总的来说 类似于地址转化（address translation)。主要操作是手动meta-CSR的叠加，以及类CSR机制的叠加。

他介绍了M模式虚拟化手册的两个点：

• 与当前优先级架构手册的相关性。
• 与当前优先级架构手册的不同含义。

在邮件中他列出了M模式虚拟化手册的四个主要内容：

• 将M,HS,S和U合并成单模式，再将f*CSR已到M模式。
• 虚拟化合并的单模式为任意的嵌套级（nesting level）。虚拟化的过程中有目标性的，但是每一个隶属级都能看到自己处于 0 level，并且看到下一级为 1 level。
• 与M模式共存的同时，灵活的定义在优先级结构手册里面的标准的M/S/U结构仍旧是一个可编程的选择。
• 微架构上的一些改变。

他最后提到当前的RISC-V内核的设计只需要做一些稍微改动就能实现兼容M模式指令集。

Link: 具体操作细节可以详见sw-dev邮件列表[1]，[2]。

访问机器模式只读的 ID 寄存器（Use of MRO CSRs）

Mitchell Horne 提出： 在特权架构标准手册中定义了一些机器模式下的只读寄存器，用于唯一标识一个 RISC-V 核心。若可通过这些寄存器在监管者模式下获取 CPU 的信息，则可能有助于运行于该模式下的 OS。问题是：

1. 是否可在除机器模式以外的其他模式下读取这些寄存器的信息？
2. 如果无法在其他模式下访问这些寄存器，那这些寄存器的意义何在？为什么能通过影子寄存器让其他模式也访问这些寄存器？

Michael Clark 认为：当前无法在除机器模式以外的其他模式下读取这些寄存器。虽然在 CSR 命名规则上保留了其命令空间，暗示了在其他模式下被访问的可能性。但问题是，我们是否真的有必要导出这些信息。如果软件真的需要这些信息，则可通过修改 RISC-V 构架来实现。但正确设计应该是让针对这些寄存器的操作可以陷入 M-mode, 以便 Monitor 或者 Supervisor 可以干预返回给低特权级的值。所以比较理想的方式应该是：

1. 通过模拟的 CSR 指令来访问这些寄存器值
2. 通过 SBI 来控制指令是否可以被模拟

Richard W.M. Jones 认为：从虚拟化的角度考虑，需要保留最少一个掩码和陷入的办法来模拟这些调用是很重要的，否则无法在不同构架的机器间进行动态迁移。Michael Clark也同一此观点，并表示这就是他提出以上建议的原因。

Link: 具体讨论的细节可以详见sw-dev邮件列表

软件如何转换到用户模式下执行（Switch SW to execute User Mode）

Puneet Dhar 提出问题：RISC-V 核心(启动时)默认在机器模式(M-mode)下运行的。软件的执行具体是如何从 M-mode 转换到其他较低权限模式(S-mode 和 U-mode)的?

以下3位分别给出了他们的解决方案和参考代码：

Bruce Hoult： 设置 CSR(或者同处理器上的堆栈)，好像系统的上一个执行环境是较低特权级别，然后执行“Return-From-Exception”

Jimmy Li：

• 设置 mstatus.mpp 为 S-mode 或者 U-mode；
• 设置 mepc 地址；
• 调用 mret，则下一个指令将从 mepc 指向的地址以 S-mode 或者 U-mode 模式执行。

Tommy Murphy：可以参考以下代码(仅供参考)：

switch_to_u_mode:
    csrci   mstatus, MSTATUS_MIE      # 禁中断
    LA  t0, hart1_u_mode_test         # 设置 mepc 地址(U-mode代码)
    csrw    mepc, t0
    li      t0, MSTATUS_MPP
    csrc    mstatus, t0               # 设置“上一”模式为 U-mode
    li      t0, MSTATUS_MPIE
    csrs    mstatus, t0               # 保证中断在转换时被使能
    li      t0, MIP_MEIP
    mret                              # 跳转到设置好的用户代码

switch_to_s_mode:
    csrci   mstatus, MSTATUS_MIE      # 禁中断
    LA  t0, u54_2_s_mode_test         # 设置 mepc 地址(S-mode空间代码)
    csrw    mepc, t0
    li      t0, MSTATUS_MPP
    csrc    mstatus, t0               # 清 MSTATUS_MPP 位
    li      t0, 0x00000800            # MPP =1, supervisor 模式
    csrs    mstatus, t0               # 设置“上一”模式为 supervisor
    li      t0, MSTATUS_MPIE
    csrs    mstatus, t0               # 保证中断在转换时被使能
    li      t0, 0x01                  # 使能 U-mode 中断
    csrs    mie, t0
    li      t0, 0x08                  # 使能 M-mode 中断, 当中断来自 S-mode ML时，似乎需要这个设置
    csrs    mie, t0
    li      t0, 0x02                  # 使能 S-mode 中断
    csrs    mie, t0                   # <<<
    mret                              # 跳转到设置好的supervisor代码

Link: 具体讨论的细节可以详见sw-dev邮件列表

安全点评

继MIT的Sanctum之后，第二个基于RISC-V硬件架构的飞地可信计算开放解决方案Keystone Enclave终于发布了第一个版本，这个版本主要包含用于信任链条原型测试的bootrom，用于测试的busybear-linux，RISCV的GNU工具链，包含Keystone驱动的linux内核，基于riscv-pk实现的运行于机器模式的安全监控器，开发包和特权模式的运行时以及demo， 目前Keystone在QEMU，FireSim以及HiFive Unleashed平台上都可以完成基础测试。RISC-V处理器要完整应用Keystone需要做少量修改实现信任根，另外硬件生产过程中所面另的硬件熵相关的PUF方案以及key管理的挑战Sanctum已经有所考虑，Keystone社区未来会持续改进。Sanctum/Keystone作为开放的飞地可信计算方案是很好的开端，中长期可以在一些场景中替代连GCP都未启用的不可审计的Intel SGX，虽然L1TF的曝光让Intel SGX神话的破灭，但开放的飞地方案并不代表安全，开放方案仅仅是带来了可审计性，而RISC-V最大的优势在于可审计性，这也是HardenedLinux社区一直都在推动基于coreboot的RISC-V自由固件的原因。

行业视角

RISC-V各界评论

市场相关

Thales和SureCore加入RISC-V基金会

最近有两家公司加入了基金会。Thales是一家超大型的法国军工企业。而SureCore则是一家SRAM IP公司。

Links:

• Thales joins RISC-V Foundation to help secure open-source microprocessors
• SureCore Joins the RISC-V Foundation

Codasip融资1000万美金

提供可定制RISC-V处理器的厂商Codasip最近获得1000万美金融资，融资方之一还包括国内投资机构深创投以及西部数据等。

Link: Codasip Secures $10M in Series A Financing to Expand RISC-V Processor Technology Offerings

晶心CPU和Hex Five MultiZone获高云半导体FPGA采用

最近的报道显示，国内FPGA厂商高云半导体采用了来自晶心和Hex-Five的解决方案用于其Arora GW-2A FPGA家族，RISC-V处理器获得越来越多的FPGA厂商的采用。

Links:

• GOWIN Semiconductor Licenses Andes Technology RISC-V CPU Core For Its Arora® GW-2A FPGA Family Products
• Hex Five adds MultiZone Security to the Andes RISC-V Cores on GOWIN FPGAs

暴走事件

2018年12月

• 2018年12月11-12日，在上海举办的IC CHINA的同时首届全球企业家大会将包含RISC-V的议题。

2019年3月

• 2019年3月12-14日 RISC-V Taiwan Workshop将在新竹举办。

2019年6月

• 2019年6月10日 RISC-V Zurich Workshop将在瑞士苏黎世举办。

招聘简讯

CNRV提供为行业公司提供公益性质的一句话的招聘信息发布，若有任何体系结构、IC设计、软件开发的招聘信息，欢迎联系我们！

整理编集: 宋威、黄柏玮、汪平、林容威、傅炜、廖巍巍、郭雄飞、黄玮、李健

特别感谢: citypw

欢迎关注微信公众号CNRV，接收最新最时尚的RISC-V讯息！

本作品采用知识共享署名-非商业性使用-相同方式共享 3.0 中国大陆许可协议进行许可。