RISC-V 双周简报 (2017-09-28)

RV新闻

Simens(包含Mentor Graphics), Aselsan, Ashling 加入基金会。

RISC-V 基金会今天在Twitter上宣布了Simens, Aselsan, Ashling 这三家公司加入基金会的消息。Aselsan是一家土耳其公司，跟国防工业有关。Ashling则是一家嵌入式系统解决方案公司。欢迎他们加入 : )

Twitter上的推文：http://bit.ly/2k73qEj

Linux port 第九版

Palmer 在第九版中将driver和core arch的部分分开，希望能先把core arch送进linux-next。因此，提交的这版本可以boot，但不能print或中断。Palmer正在整理driver的部分，期待下个版本能一起进linux-next。

LKML的连结：http://bit.ly/2xMFxHC

技术讨论

mtval 控制寄存器的取值和意图

mtval是RISC-V priv. spec定义的一个CSR，旨在发生异常时，提供造成异常的错误地址和错误指令。不过最近关于mtval在发生指令未对齐异常时的取址产生了疑问。现在Spike (RISC-V的标准实现)将mtval设定为对齐后的错误地址，而Rocket-Chip则直接置零。 Andrew关于这个不一致的解释给出了该控制寄存器的设计图： mtval其实是为了加快处理能够重新执行类型的异常，比如ecall，ebreak，illegal instruction (software trap)等等。对于不能重新执行类型的异常（严重错误需要退出进程），异常处理应该自己去发觉异常原因，mtval可以被置零。所以，mtval置零可以被作为一个提示信号告诉异常处理去自己发掘错误信息。

In general, zero is used as a sentinel value for mtval, indicating that software should manually derive the value. Similarly, on illegal-instruction traps, mtval can either be written with the instruction word, or 0, indicating that software should load the instruction from memory. (Rocket does actually write the instruction word in this case.)

mtval is provided to simplify and accelerate the handling of restartable exceptions. Misaligned instruction fetches are essentially never restartable, so providing the trap value isn’t useful, except for debugging. Debuggers can derive the target address by reading mepc and emulating the instruction.

详细讨论：https://goo.gl/FWRwNh

发生缺页中断时的 stval 值

考虑下面这个代码：

lui a0, 0x81
lw a0, -1(a0)

并假设页0x80被分配而页0x81还未被分配，从0x80fff地址地址都取4个字节会导致在读取0x81000字节时发生缺页中断。那么，stval应该被置为0x80fff的出错读取首地址还是0x81000的具体缺页地址呢？

按照spec最新的修改，stval在缺页中断时应指向发生缺页的地址，即0x81000。

初始问题: https://git.io/vdk8M
Spec 更新: https://git.io/vdk81

在RV32系统中，如何设定64位的时间比较寄存器timecmp

无论是在32位还是64位系统中，时间比较寄存器timecmp都是64位的，以保证其不会溢出。

出于对多核多电压以及电源关断的支持，时间比较寄存器不再是一个CSR，而是一个映射到IO地址空间上的系统寄存器。

当IO总线宽度小于64比特，比如32比特时，如何正确设定时间比较寄存器呢？

RISC-V priv spec如是说：

“In RV32, memory-mapped writes to mtimecmp modify only one 32-bit part of the register.”

Figure 3.15 below shows a ‘Sample code for setting the 64-bit time comparand in RV32 assuming the registers live in a strongly ordered I/O region.’
# New comparand is in a1:a0.

li t0, -1
sw t0, mtimecmp   # No smaller than old value.
sw a1, mtimecmp+4 # No smaller than new value.
sw a0, mtimecmp   # New value.

ecall和ebreak的返回地址

RISC-V在中断和异常时的返回地址定义是不同的。出现中断时，中断返回地址epc被指向下一跳指令，因为中断时的指令被正确执行。出现异常时，epc则指向当前指令，因为当前指令触发了异常。然而，如果异常由ecall或ebreak产生，直接跳回返回地址则会造成死循环（执行ecall导致重新进入异常）。正确的做法是时在异常处理中手动改变epc指向下一条指令。现在ecall/ebreak都是4字节指令，因此简单设定epc=epc+4即可。该问题很早以前就被提出过，最近又被重新提及。

突破 VIPT 缓存的容量限制

这里VIPT是指virtually indexed and physically tagged。一个VIPT缓存通过同时使用虚拟地址的低位寻找对应的cache set和虚拟地址的高位做TLB获得cache tag的方式，解决了支持虚拟地址的缓存中TLB关键路径问题。然而，VIPT正常工作有一个前提，即用于寻址cache set的地址低位和用于TLB的地址高位没有重叠。这便限制了VIPT缓存的大小一般为page-size * number-of-ways，因为number-of-sets * cache-block-size <= page-size。这个前提条件在经典计算机体系结构的教科书里都会提及。

如果忽视这个前提条件会发生什么？同一个物理地址可能被映射到多个不同的cache set，产生副本问题。虚拟地址用于物理页表寻址的低位被用于寻找cache set，而这个低位在TLB之后可能和tag不匹配。假设虚拟地址用于寻址cache set和用于物理页表寻址有N比特的重叠，那么同一个物理地址可能被映射到2^N个不同的cache set。

最近Rocket-Chip的一个问题就问到，有没有办法突破这个限制呢？Rocket-Chip的L1现在就是VIPT，暂时没有。但是很多处理器其实已经突破了这个容量限制，比如Alpha 21264，MIPS R10K，很多SPARC处理器和ARM Cortex-A73。具体方法有两种：

虽然PA->cache set产生了多重映射，VA->cache set仍然是单映射。所有的cache读操作正常执行，写操操作时则检查所有的可能副本，将其去除(invalidate)。
在页表分配时强制虚拟页表地址和物理页表地址的重叠部分相同，避免TLB结果和cache set不匹配问题。这种方法被称为page coloring。

参考：

Rocket-Chip的问题：https://git.io/v5jjF
突破限制的方法：CMU ECE-447 课件 Link:http://bit.ly/2wlPrw8

代码更新

Rocket-Chip 的 Diplomacy 调整

Diplomacy 是 Rocket-Chip 用于编译時模块自动类型推断和链接的重量级程序包。最近该包经历了一次较大调整（小编：需要学习Rocket-Chip内部实现机制的同学又要头疼一阵了）：

在使用diplomacy node链接两个模块时，链接的参数将随链接一起被推断（add parameters to diplomacy edges），这样能更好地支持个链接的参数配置。
不再使用bundleIn和bundleOut推断模块端口，而改用in()和out()方法，在推断端口的同时推断连接参数(edge parameter)
所有的lazyModule都将默认定义为MultiIOModule，从而强迫所有的端口定义都使用IO()宏。
添加:=?的新模块连接符，该连接符将利用新定义的CardinalityInferenceDirection参数自动选择:=, :*=和:=*连接类型。

具体的修改内容较多，请参看相应PR，特别是端口推断的PR，Wesley给出了示例程序。

为模块链接添加参数控制：https://git.io/vdYbw

修改端口推断方式：https://git.io/vdYbP

MUSL的动态链接库后缀定义

MUSL是一个轻量级的libc库。MUSL关于RISC-V的动态链接库后缀即将被定义如下：

Define MUSL_DYNAMIC_LINKER for riscv

Use no suffix at all in the musl dynamic linker name for hard float ABI. Use -sf and -sp suffixes in musl dynamic linker name for soft float and single precision ABIs. The following table outlines the musl interpreter names for the RISC-V ABI names.

musl interpreter RISC-V ABI

ld-musl-riscv32.so.1 riscv32-ilp32d

ld-musl-riscv64.so.1 riscv64-lp64d

ld-musl-riscv32-sf.so.1 riscv32-ilp32

ld-musl-riscv64-sf.so.1 riscv64-lp64

ld-musl-riscv32-sp.so.1 riscv32-ilp32f

ld-musl-riscv64-sp.so.1 riscv64-lp64f

musl interpreter	RISC-V ABI
ld-musl-riscv32.so.1	riscv32-ilp32d
ld-musl-riscv64.so.1	riscv64-lp64d
ld-musl-riscv32-sf.so.1	riscv32-ilp32
ld-musl-riscv64-sf.so.1	riscv64-lp64
ld-musl-riscv32-sp.so.1	riscv32-ilp32f
ld-musl-riscv64-sp.so.1	riscv64-lp64f

Rocket-chip 原有的 L2 真的有死锁问题

这里的二级缓存是指的还在lowRISC和BOOM中使用的二级缓存实现。最新的Rocket-chip并不提供二级缓存。

还记得4周前有过讨论，sxu55认为lowRISC所使用的L2存在死锁条件，但是那时候并没能找出死锁的具体原因。经过近一个月的讨论和盘查，最终[sxu55]提供了一段简单代码复制死锁条件。经过确认的确死锁了。 lowRISC通过修改二级缓存中关于一级缓存写回缓存块部分的控制逻辑，解决了该死锁问题。整个死锁的发生涉及接近6个相关报文按一个特殊的顺序发生，导致了二级缓存中的共享写回单元和处理一级缓存的回写模块发生互相等待。解决办法是在死锁可能发生的状态调整报文优先级，让一级缓存的回写先完成。

这里还只是涉及两个处理器没有第三级缓存的缓存一致性实现，如果有了三级缓存，估计问题的复杂度还得高个数量级。也许真的应该在设计缓存一致性控制模块之前，先建立行为模型，用形式验证的方法先证明没有死锁状况。

具体讨论：https://git.io/v5YAb
问题修复：https://git.io/v5pNi

微群热点

最近NVIDIA开源了其AI加速器DLA，在群内引起了不少关注，更有不少同学开始通宵狂肯DLA代码，短短几天时间GitHub上就有16个Issues；NV的员工也是辛苦，三更半夜不睡觉连夜回答。DLA的开源事件最终的影响恐怕要数年之后才能看到，但是硬件/Silicon开源这股风已经停不下来了！

据说未来NV自家的RISC-V核计划开源，同志们拭目以待吧！

实用资料

All Aboard blog part1 整理

Palmer 的 All aboard blog 已经连载到part5，介绍了code model, linker relaxation, 以及abi 等跟 risc-v toolchain 有关的知识。小编会逐渐带来每一篇的整理，本次先介绍第一篇。这篇介绍了riscv gcc的三个参数(-march, -mabi, -mtune)。

march比较好理解，由於risc-v是模组化的设计，可以产生很多种指令集的组合。例如要不要有F和D指令，或是要不要有C。每一种组合，gcc就会用对应的指令来编译。如果没有对应的指令，就会用emulation，跟soft float和hard float的概念一样。比如，要产生float，但没有F时，就会用emulation来产生float。比较特别的是，因为一些原因，现在的risc-v gcc并不会针对 A 做emulation。

mtune也蛮好理解的，这个在x86中很常出现。针对每种微架构，譬如pentium, atom，编译器可以产生不同的优化，为了速度或功耗。

加入 mabi後就比较复杂一点。mabi定义了函数传参时，值要放哪。比如，floating point 在传参时可以被放在fa0，也可以被放在 a0,a1。不同的ABI会决定要放在哪。有时，为了跟其他library接口，即使有F指令，也会放在a0 和 a1。如同这段所叙述的：

-march=rv32imafdc -mabi=ilp32d: Hardware floating-point instructions can be generated and floating-point arguments are passed in registers. This is like the -mfloat-abi=hard argument to ARM’s GCC.

-march=rv32imac -mabi=ilp32: No floating-point instructions can be generated and no floating-point arguments are passed in registers. This is like the -mfloat-abi=soft argument to ARM’s GCC.

-march=rv32imafdc -mabi=ilp32: Hardware floating-point instructions can be generated, but no floating-point arguments will be passed in registers. This is like the -mfloat-abi=softfp argument to ARM’s GCC, and is usually used when interfacing with soft-float binaries on a hard-float system.

看到这里，其实 march 和 mabi 就是把 ARM gcc中的 -mfloat-abi 拆成两半。原因是 RISC-V 未来可能有更多指令和ABI的组合。当然，更多的ABI可能会带来软件上的复杂性。因此，也是每个客制指令集设计者要思考的问题。

Palmer 的 all aboard blog part1原文 Link: http://bit.ly/2wmRct8

市场相关

SiFive 即将发布 RISC-V U54 Coreplex CPU

即将在10月4-5日举行的11th Annual Linley Processor Conference上，SiFive即将发布最新的U54 Coreplex CPU，我们将持续跟踪。

链接：11th Annual Linley Processor Conference Focuses on Deep Learning, Embedded, Communications, Automotive, IoT, and Server Designs http://t.cn/R0W0KIB

SEGGER 在 J-Link 中加入了对 SiFive Coreplex IP的支援

老牌厂商SEGGER最近宣布在其所有产品中增加对SiFive RISC-V Coreplex IP的支持，向SEGGER这样的商业版本的JTAG调试器支持很多开源产品不支持的高级特性。

All current J-Link models now support debugging of RV32 RISC-V cores. This includes support from SEGGER’s GDB Server, which is part of the J-Link software package that supports SiFive’s free Eclipse-based Freedom Studio. J-Link’s high performance and functionality allows it to be easily used and it provides reliable, professional support to RISC-V cores. Features also include a direct Flash memory download via an open flash loader interface giving SiFive and the RISC-V ecosystem access to SEGGER’s vast catalog of supported flash devices. For systems running code from flash memory instead of RAM, there is an unlimited number of breakpoints not only in RAM, but also in Flash (with higher end J-Link PLUS, J-Link Ultra + and J-Link PRO models).

Link: http://t.cn/R0W0RHl

Sifive的Coreplex IP 加入了 TSMC IP Alliance program

“Acceptance into the TSMC IP Alliance is an honor and a significant validation not only of SiFive, but of the RISC-V architecture as a whole,” said Jack Kang, vice president of Product and Business Development, SiFive. “Having the SiFive Coreplex IP platform available through the program makes designing a chip based on the latest in open source hardware even easier. We look forward to continued collaboration with TSMC and the other members of the IP Alliance ecosystem.”

Link: http://t.cn/R0WOzlM

CNRV社区活动

暴走事件

十月

OSDT开源开发工具大会2017（也就是原HelloGCC会议）将在10月下旬在北京举办，时间暂定10月21日，话题和赞助征集已经开始。话题内容包括“面向RISCV等新硬件的基础软件支持”，各位不要错过。
开源经济学研究-2017年年会邀请函
RISC-V at the Linley Processor Conference, 4-5 October 2017 at Santa Clara, California.
First Workshop on Computer Architecture Research with RISC-V (CARRV 2017), 14 October at Boston, Massachusetts, co-located with MICRO 2017.
LLVM US dev meeting将在十月18-19日于加州San Jose举行。其中有一场跟risc-v有关的演讲。Alex Bradbury演讲的主题会是 “Co-ordinating RISC-V development in LLVM”。有兴趣的可以参考。

十一月

The 7th RISC-V workshop 2017年11月28-30日，第7届RISC-V研讨会将在美国加州Milpitas由西部数据承办。
BSDTW17 2017年11月11-12日，BSDTW17会有两场关于RISC-V的演讲，地点在台北。

招聘简讯

lowRISC招聘硬件工程师

lowRISC是于2014年在剑桥成立的一家非盈利公司，致力于向中小企业和研究机构提供基于RISC-V和Rocket-Chip的开源多核片上系统。现在lowRISC希望聘请一位硬件工程师。主要的研究方向是多核片上系统和硬件安全。具体的招聘广告请查看https://lowrisc.workable.com/j/DBAC61322F

整理编集: 宋威，郭雄飞，黄柏玮

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

CNRV微信公众号

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