关注RISC-V和Chisel以及开源IC和EDA在中国的发展
要点新闻:
由SiFive和CNRV一起举办的这场线下交流会,将会邀请SiFive和U.C. Berkeley的Krste教授和SiFive的CTO Yunsup Lee博士。同时也会有国内其他的一些Chisel爱好者分享他们的一些使用经验。
希望这次活动能做为一个良好的起点和开端,和大家一起探讨对于Chisel等一些相关技术在项目中如何实践和落地的问题
另外,首届Chisel Community Conference也将在11月在湾区举办,详见下面暴走事件一栏。
活动报名网站:https://www.bagevent.com/event/1770532
SiFive在今年的Hot Chips大会上展示了其U540通过Chiplink和在FPGA上的NVDLA连接的SoC平台。
The demo will be shown this week at the Hot Chips conference and consists of NVDLA running on an FPGA connected via ChipLink to SiFive’s HiFive Unleashed board powered by the Freedom U540, the world’s first Linux-capable RISC-V processor. The complete SiFive implementation is well suited for intelligence at the edge, where high-performance with improved power and area profiles are crucial. SiFive’s silicon design capabilities and innovative business model enables a simplified path to building custom silicon on the RISC-V architecture with NVDLA.
BlueSpec最近开源了其用其自家语言BSV实现的一个三级流水线CPU,名叫:Piccolo。当然,因为编译bsv的工具是商业工具,所以repo中也附带了已经生成好的Verilog HDL源文件。这个商业工具可以从BlueSpec购买,而且对于学术用户是免费的。
同时另一个五级流水线的名为Flute的CPU也准备开源。
BlueSpec声称自己的bsv是高度可配置的,可以针对不同的应用进行优化,而且复杂到足够可以boot起一个Linux(基于sv39 MMU)。
以下是这颗U的介绍。
Features
Benefits
Links:
Tommy Murphy
在RISC-V SW Dev
提问说,
从https://github.com/riscv/riscv-gnu-toolchain release里面下载的代码做常规的编译,但是编译失败.虽然发现原因是因为维护人员打包是没有执行git submodule update --init --recursive
导致没有把源码完整的打包进去引起的问题。但是从其他也遇到问题的人看,riscv-gnu-toolchain
的维护比较混乱,容易让刚上手RISC-V的人掉进坑里。
虽然有Andes
, SiFive
和其他公司以及社区爱好者都开发和维护,但是总的来说还是缺乏人员来做常规稳定的维护和测试。
在讨论中Jim Wilson
也详细的说明当前的情况和处境。
binutils, gcc, and newlib are fully upstream. Riscv-gcc, riscv-newlib, and the binutils support in riscv-binutils-gdb are occasionally updated to the latest release, and patches backported, but there isn’t anyone actively maintaining these trees.
gdb is partly upstream. The embedded support is there, though SiFive has had some trouble using it, and the problems are being worked out. The linux support is not there. I have a riscv-linux native port in progress, and hope to submit an initial patch set this week to appear in the gdb 8.3 release that should come out around the end of the year. The linux port needs a lot more work to be a fully functional gdb port though. The gdb support in riscv-binutils-gdb is not being updated, as that would break our existing working support.
glibc is partly upstream. The 64-bit support is upstream. The 32-bit support is not. Andes has started working on this, and posted a patch set. The hope is to get this resolved before the next glibc release that should come out around February of next year. riscv-glibc is not being updated, as that would break the working 32-bit support we have in our tree.
qemu is upstream, but has a large patch backlog, as the upstream maintainers are slow to accept patches from new contributors. I think WD has some qemu maintainers that are helping SiFive with the backlog though. riscv-qemu is up to date, and has the backlogged patches applied. Riscv-gnu-toolchain however is using an older version because the 32-bit glibc support does not work with the current qemu. There is a linux kernel/glibc ABI problem with the stat structure that needs to be worked out, and that requires some more linux kernel and glibc work to resolve. Meanwhile, I want riscv-gnu-toolchain to use the old qemu so I can continue to test 32-bit linux binutils and gcc support.
The linux kernel is partly upstream. The core port is there, but not the drivers. The upstream tree is not bootable. I don’t follow linux kernel development, but I think some people from WD are also helping with this, at least to get enough drivers to boot. riscv-linux is up to date, and has all of the drivers required.
I think if you give it another 6 months, we should be fully upstream, and then the best trees to use will all be the upstream ones.
If you want stable supported tools, then there needs to be a group of people responsible for this. Linaro has a small team of people that maintain stable supported tools for ARM EABI and ARM Linux, and another group that maintains a stable supported linux kernel, and another group working on qemu,
riscv-gnu-toolchain
现在还有很多不完善的地方,比如gdbserver
的支持,现在
形同虚设,虽然在嵌入式领域主要是主要是用openocd
, 但是随着RISC-V
对linux环境
的支持越来越好,基于linux产品越来越多时,gdbserver
也是一个非常需要的工具。
RISC-V需要更多热心的人参与,让RISC-V的生态更加完善。
link: sw-dev
最近Jim Wilson在邮件列表中给出了一个非常完整的介绍,讲解如何在GCC的相关工具中添加一条RISC-V指令。
更详细的讲解,请参看Jim Wilson的邮件原文: sw-dev
Roger Ferrer 在使用 riscv64-unknown-linux-gnu GCC 8.1 编译 atomic 相关的代码时发现行为跟他预期的不符。
#include <stdatomic.h>
atomic_int x;
void foo(void) { atomic_fetch_add_explicit(&x, 5, memory_order_acq_rel); }
对于 atomic fetch 和 add, GCC 生成下列指令:
fence iorw,ow; amoadd.w.aq zero,a4,0(a5)
而不是
amoadd.w.aq zero,a4,0(a5)
Roger Ferrer 查看了 RISCV 规范也没发现规定了 atomic 指令之前要加上 IO 的 fence 。
Jim Wilson 猜测是因为 memory model 还在制定中,没有确定下来,但对应到 C/C++ 的标准定义好了,GCC 超前做了多余的事情。
更详细的讲解,请参看邮件列表 sw-dev
有同学提问,如何区分以下的错误(Fault)类型?
Instruction access fault -> Instruction page fault
Load access fault -> Load page fault
Store/AMO access fault -> Store/AMO page fault
简言之,”page” fault只会发生在有虚拟内存机制的系统中,通常来说是指具有MMU的系统中。
而access fault可以理解为任何在“总线(Bus)”上发生的错误,包括但不限于ECC/校验错误、物理内存保护、访问超时等。
随后讨论更加深入到了一个良好的设计的系统需要考虑到的一些细节问题:
详细讨论细节见:isa-dev https://goo.gl/oZ6Zb3
Gnanasekar在SW-Dev邮件组问到了一个交叉编译的问题。他本来的计划是在Windows的机器上编译一套RISC-V的工具链(toolchain),但是这个项目在实际中碰到了很多问题,尤其是碰到了形形色色的编译错误。
Tommy Murphy提到了一个基于docker的工具能够用来编译GNU MCU Eclipse RISC-V tool sources 项目链接. 他认为这个项目可以更容易地给windows编译工具链。
Jim Wilson抛出了一个更有意思的解决方案:加拿大交叉编译(canadian cross)。这个高大上的名字源于当时加拿大有三个政党组织。具体的方法如下:假定机器A,B,C有不同的操作系统和处理器,在机器A上交叉编译一套能用在机器B上的gcc工具,把这套工具拷到机器B上,然后在上面交叉编译出能运行在机器C上的二进制代码。看起来很复杂,但是如果用户比较熟悉Linux,事实上这个比在Windows直接进行交叉编译要容易。小编举个例子:Gnanasekar可以在Linux上利用mingw64编译一套能够直接运行在Windows的gcc,然后把这套工具搬到Windows上运行去编译产生RISC-V的二进制代码。
讨论连接:sw-dev goo.gl/b5aepe
Neel Gala 在虚拟内存模式的”spike –isa=rv64imac”中运行 riscv-tests 套件的 rv64ui 测试时,vmboot 阶段修改了 mstatus 的 FS 域。他认为:在禁用了浮点功能时,FS 域应该硬连线到 0,但它的值似乎会被改写。最新的特权体系结构手册中的如下描述(位于riscv-privileged-v1.10.pdf 3.1.11 P23)无法解决他的困惑:
"In systems that do not implement S-mode and do not have a floating-point unit, the FS field is hardwired to zero."
“对于没有实现 S 模式且没有浮点单元的系统,FS 域是硬连线到 0。”
所以他提出以下疑问:
假设对于 RV64IMAC 的实现,是否需要实现 FCSR 寄存器,在状态寄存器 mstatus/sstatus 中的 FS 域是否应该硬连线到 0?
Neel 的理解是:如果要支持软浮点,由于库代码需要使用 FCSR 寄存器和 FS 域,所以需要实现它们。倘若无需任何浮点支持,是否还要实现 FCSR 寄存器和 FS 域?
Jim Wilson 做出了如下解释:软浮点库不需要使用 FCSR 寄存器。你可以在没有 FCSR 寄存器的情况下使用软浮点代码。特别是针对无 FPU 的目标主机编译软浮点库所得到的软浮点库。但有时出于对 ABI 兼容性的考虑,针对有 FPU 的目标主机编译出的软浮点库将使用 FCSR。这类软浮点库更全面地实现了 IEEE FP 标准,且它可以更好地同硬浮点代码互动,并运行于同一处理器上。
Andrew Waterman 做出了如下解释:倘若想要使用 M 模式代码透明地模拟 FPU,那就应该实现 FS 域。在实现了 S 模式的情况下, 基于 Rocket 的核心总是提供 FS 域,这样甚至可以在 S 模式都无法感知的情况下模拟 FPU。 对于那些没有实现 S 模式且没有 FPU 的核心,就只将 FS 域硬连线到 0。
详细讨论细节见:RISC-V ISA Dev
lowRISC即将发布其第6版SoC实现。 该版本使用了最新的Rocket-chip,在其基础上添加了多种外围设备。 该版本的主要更新包括:
代码分支: refresh-v0.6
CNRV社区维护的浮点数据通路库https://github.com/cnrv/CNRV-FPU 更新了,支持Verilator仿真,并且以Testfloat-3e为Golden Model验证通过。这套浮点库的特点是:
Link: CNRV-FPU https://git.io/fAICG
Tommy Murphy总结的关于编译QEMU RISC-V映像的网页
EETime最近的文章提到了Esperanto这家去年成立的初创公司的最新动向。
新创公司Esperanto Technologies Inc.最近聘请了两位来自特斯拉(Tesla)自动驾驶(Autopilot)部门的资深工程经理。David Glasco和Dan Bailey将加入Esperanto,带领高阶RISC-V核心和处理器工程团队,负责深度学习和通用处理器开发任务。
…
去年11月,Esperanto在RISC-V大会上首度亮相。当时,Esperanto首席执行官Dave表示,该公司正在开发两款RISC-V核心和两款SoC,其中至少有一款将采用7nm技术工艺。搭载Maxion核心的16核心芯片瞄准单线程性能,而使用Minion核心的4,096核心芯片则在每颗核心中加进了一个向量单元,旨在实现最佳的每瓦性能。
Link: D&R: AI is now the Show Time for new companies and new architectures
FADU和Mobiveil两家公司相继宣布采用SiFive的RISC-V CPU用于其SSD控制其解决方案。这也从侧面证明了一些细分垂直领域(垂直这里是指软件和芯片都由自己开发),RISC-V已经得到了客户的认可。
Links:
来自36kr最近的报道显示,一家新创企业“新帆”正在研发基于RISC-V的处理器,时间需要2-5年,并将启动首轮亿元级别融资。
36氪近日接触到的新帆就是基于RISC-V自主设计芯片内核。新帆联合创始人、清谷资本创始合伙人夏淳告诉36氪,虽然大家都是用的是RISC-V指令集架构,但由于团队的设计能力不同,会使得芯片的性能和用途也有较大差异。新帆一大优势在于团队核心技术人员均有“正规军实战”的高端内核设计经验,设计团队建制完整。据悉,新帆技术人员在MIPS、SGI、SUN、ARM等大型芯片企业有平均超过15年的工作经验,拥有服务器级别、高性能和低功耗CPU、GPU、以及SOC等超过40款,累计过亿出货量的成功芯片案例。
Link: 基于RISC-V开源指令集,「新帆」要自主研发高并发、多线程、低功耗芯片内核
来自广东的FPGA厂商高云发布了基于RISC-V的微处理器的早期使用者计划,目前看下来这个计划提供的bit文件中包含了RISC-V的软核。
Link: 高云半导体公司发布基于晨熙家族FPGA的RISC-V微处理器 早期使用者计划
CNRV提供为行业公司提供公益性质的一句话的招聘信息发布,若有任何体系结构、IC设计、软件开发的招聘信息,欢迎联系我们!
整理编集: 宋威、黄柏玮、汪平、林容威、傅炜、巍巍、郭雄飞、黄玮
特别感谢: 王逵
欢迎关注微信公众号CNRV,接收最新最时尚的RISC-V讯日, RISC-V Day Tokyo将在Keio University举办,演讲征集已经开始。注册网站 息!
本作品采用知识共享署名-非商业性使用-相同方式共享 3.0 中国大陆许可协议进行许可。