关注RISC-V和Chisel以及开源IC和EDA在中国的发展
要点
过去的一年发生了很多有趣的事情,相比去年,我能够看到越来越多的人开始对RISC-V持有乐观的态度。今年5月在上海举办的RISC-V Workshop在中国的影响是深远的,很多国内的半导体厂商开始意识到RISC-V或许是除了AI之外最不能错过的趋势。当然,这当中有些厂商有心参与却无处发力,有能力的一些厂商开始积极布局,更多的厂商打着自己的算盘闷声发大财。不论怎样,如果RISC-V不能给大家带来切切实实的利益,要他又有何用?
但不论在是国内还是国外,在RISC-V的普遍好评中我都能感受到一种气氛,那就是他们仍然在用过去20-30年的发展思路去看待RISC-V。很多人会想去做第二个Arm或是第二个Intel,我不能反驳这个思路,但我认为在技术创新的同时不能没有有商业模式的创新,而这或许是你没法做第二个Arm的主要原因之一。其实很难说最后会不会出现一家通过RISC-V发家的巨头,但是RISC-V要想跨越鸿沟,被普罗大众所接受,或许要是无数个小的力量聚合在一起所推动的。
RISC-V代表了一种“去中心化”的趋势,这意味着每个有能力的人都可以开始使用和改进RISC-V,而且门槛会越来越低,少数有能力的人会开发出稳定可靠的开源CPU,而你或许只要掌握少量的知识和技能就可以加入自己的东西并且为我所用。这就像是在Web开发领域,大量的高性能库、框架和可伸缩的云计算服务能够显著的降低开发人员的技能门槛。
所以,在新的一年里,让我们学着“解放思想”,想想怎么能把RISC-V和你们自己的优势结合起来,来巩固和加强你们的优势。黑猫白猫,捉住老鼠就是好猫。
最后,CNRV会在新的一年里继续努力,建立更大、更健康、更活跃的社群,我们也在准备会举办一场大规模的线下活动,到时候可别忘了来捧场,老铁!
最近一则关于“英特尔CPU爆惊天漏洞”的新闻传遍网络。 其实在小编看来,这则新闻并没有那么新,英特尔修复漏洞是必然,只是个时间问题。 反观RISC-V,其实RISC-V已经规避了Intel的问题,在这方面,是一个更加安全的指令集。 下面就让我来稍微仔细一点的说一说。
有人猜测说这个漏洞和乱序流水线的分支预测(branch speculation)有关,导致了低优先级的用户程序能够访问内核空间。 小编个人对此解释持保留态度。 使用分支预测已是乱序流处理器的基本配置,Intel存在漏洞而AMD幸免有些说不过去。 后来看更多的英文文档 [Lipp2017],其实英文里面说的是预测执行(speculative execution),这个就比分支预测的范围大得多了。 其原理简单说就是处理器允许预测执行的用户态代码访问内核数据并将内核数据真的读取并置入缓存。 从2016年CCS安全会议的一篇文章来看,使用Intel处理器的Linux系统早就被攻破,其关键也是对用户程序的内存读写监管不严。
先简单介绍一下基本的内核空间保护:基于种种原因,至少在Linux系统中,内核空间是被完整添加到用户进程的虚拟空间中的。 这就导致用户程序能很容易的访问内核空间,造成了安全隐患。 为了缓解该问题,现代内核往往使用内核空间地址随机化(KASLR),随机化之后,用户程序需要猜出内核空间分布才能窥视内核。 绕过内核地址随机化变成了攻击内核的重要一步。
在Sandy Bridge之后的Intel处理器允许用户程序的prefetch指令预取任意地址,包括内核空间的地址。 这边提供了攻击者创造特殊缓存时间侧信道来探测内核空间 [Gruss2016]。 更糟糕的是,Linux内核将所有用户空间都映射到了内核空间以方便内存管理(physmap)。 攻击者通过寻找自己的数据空间在内核空间的对应映射,便能够做到内核态代码注入,用以劫持内核 [Gruss2014, Kemerlis2014]。
这里暴露了很多问题:
那么我们再来看看RISC-V。 RISC-V指令集在SSTATUS控制寄存中定义了SUM标志位。 一般情况下,SUM=0,即内核态代码不能读写用户态数据,只有当必要时,内核才临时开启SUM直接操纵用户数据。 但是,内核无论如何都不能执行用户页的指令。 这样,即使physmap将用户页映射到了内核空间,其页表仍然标注该页属于用户态,则彻底堵上了利用physmap对内核的代码注入。
另外,RISC-V讨论组内部也早已开始讨论比Intel更加彻底的用户和内核页表分离方案 [isa-dev-2017-11-30]。 当前Intel的页表分离方案的明显性能下降主要来源于内核和用户切换时需要刷新TLB,产生了大量缺页中断 [Gruss2017]。 如果用户和内核使用不同的页表基地址和ASID,则不要频繁刷新TLB,大大降低性能损失。 由于用户和内核的彻底页表分离,prefetch指令将彻底失去预取内核数据的能力,去除其造成的侧信道。
(宋威:以上为个人基于有限文献的见解,受知识面和能力限制,如有错误,还望不吝指正。同时感谢Shawn的审校。)
最近 Palmer 在 glibc-alpha 上提交了 glibc port v2 和 v3。由於Debian, Fedora, OpenEmbedded 等上层软件都仰赖 glibc 和ABI 的稳定,glibc的upstream便显得急迫且重要。glibc的RISC-V port 将包含六个configuration。详请可见Palmer在port v2中的介绍:
Our QEMU port is not yet upstream (we’re preparing it for submission now), and general availiability of the first commercial, Linux-capable RISC-V chips is scheduled for Q1 2018.
We’ve had preliminary ports of Debian, Fedora, and OpenEmbedded to RISC-V, all of which are currently waiting on glibc so we can declare the ABI stable.
Michael Clark 最近提交了QEMU port v1,期望能在QEMU 2.12 合并主线。这次的提交主要是针对base ISA的部分。未来,可能会再加上hypervisor extension, vector extension 和device emulation 等功能。
详情请见:QEMU port v1
很多指令集都支持使用调试器来实现一些简单的I/O功能以方便系统的早期调试。 这时候,调试器便起到了一部分主机的功能,即称作semi-host。 由于调试器的可见中断只有EBREAK指令,所以实现semi-host必须在这条指令上想办法。 在RISC-V指令集定义的时候,EBREAK指令被定义为不带任何操作数的指令,其基本考虑如下:
From Krste:
- A debugger knows the addresses at which it has inserted breakpoints. (调试器应该知道源代码中的断点位置)
- When the debugger is notified that a hart has stopped at a breakpoint, it needs to read the pc at least. (当调试器被断点唤醒,调试器至少会读取当前PC指针)
- A debugger-side hashtable indexed by the pc can uncover all the necessary information about that breakpoint without having to go back and read the EBREAK instruction bits from target memory, and without being constrained by the size of the EBREAK immediate field. (使用一个简单的哈希表应该就能很快分析出断点的功能,而不需要去分析断点指令的参数)
- A compressed EBREAK should work the same as an uncompressed EBREAK, and encoding space is more critical in compressed code. (压缩和非压缩断点指令的行为应当一致)
- More generally, we viewed EBREAKs as instructions that are poked into compiled code from outside, not instructions that are compiled in to a binary, though it’s clear software breakpoints are being used in this way for other architectures. (从根本上说,断点指令应当被看作被外部添加的指令,而不是原有执行程序的固有指令。尽管软中断被其他的体系结构大量使用为软件基本功能)
上面的软件中断即暗指ARM系列的软终端,想起来了ARM 7中SWI #imm的用法吗?
不过这些基本假设现在似乎出现了问题。 比如,Liviu就指出,调试器并不是任何时候都能拿到被调试代码的执行副本的(思考直接将调试器接到一个嵌入式系统盲调)。 这这种时候,就不能假设调试器能独立理解断点所需要的功能。
为了解决这个问题,Liviu提议改变EBREAK的格式,添加一个立即数参数。但是这样便破坏了已经被定义的用户态RISC-V指令级标准。 作为折衷方案,Krste提出:
- Use EBREAK + 16-bit zero + 16-bit tag as current workaround to lack of EBREAK immediate (effectively making a new 64-bit EBREAK encoding). (仍然使用现在的EBRAK指令,不过在指令后添加一个16比特0的非法指令做标识符,然后使用一个16比特作为断点参数)
- Add “undelegate” feature to debug spec so ECALL (and other exceptions/interrupts) can trap to debugger. (为系统调用ECALL提供调试器的接口,让部分系统调用由调试器完成)
- Move eventually to using ECALL for semihosting-like applications where debug hardware supports “undelegate”. (逐步推进使用系统调用实现semi-host的大部分功能)
- Use labeled ELF for EBREAK “assert failure” use cases. (使用断点和执行文件副本实现assert)
但是即使这样也不能满足所有需求。 其中反映最激烈的问题是使用系统调用的方式实现semi-host导致每次host调用都必须陷入异常处理, 这对于使用semi-host来实现轻量级打印输出来说代价过大。 用semi-host的方式实现轻量级打印输出是trace调试的基本操作之一, 在系统早期调试硬件和基础软件,trace调试是非常有用的。 所以支持这种轻量级的semi-host也是很有必要。
现在这个讨论还在继续中,决定之后,RISC-V的调试标准将会做相应修改。 现在看来,对于I/O的semi-host应用会使用系统调用方式,而对于打印调试信息则可能使用断点叫附加断点参数的方式。
相关讨论:https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/1Su9Z7L18qM/QCDxYoCCBwAJ
这个技巧还真是令人大开眼界。假设下面的程序:
if(a>0) b=b+1;
else b=b-1;
这段小程序的else
分支只有一条指令。一般编译器会在if
分支的最后加一条跳转指令跳到else
分支之后的代码。
但是由于else
分支只有一条指令,与其使用跳转指令,可以使用一条类似LUI x0, #imm20
的NOP指令(x0
寄存器永远为0,所以赋值没有意义),
然后将else
分支的指令用一条RVC指令代替,然后将其藏在20比特的立即数里。很有点脑洞大开。
这么做的主要意义是节省指令空间,据说在以前的ROM大小受限的Z80系统经常会使用这种技巧。 在现代处理器中,这种使用方式基本不会带来任何速度优势(分支预测能很准确地预测跳转),但可能造成取指(Fetch)部分的错误。 不过对于系统初始环节,在初始内存受限情况下,也许有其用途。
这次的更新算是修正一些小错误。包括:
修正 sys_riscv_flush_icache()裡的一个typo。这是RISC-V linux裡专门处理 I$ flush的 syscall。由于RISC-V 裡没有跟cache 直接相关的指令,这个syscall 底层是使用fence.i 指令实作的。详情可见:fence.i 的 实作 和 syscall的实作
加回来了不小心被删掉的 smp_mb__after_spinlock()。
移除了关于旧版HVC_driver的code。这原本是为了early printk而做的。后来有比较好的方法了。详情可参考连结。
更多细节可参考 GIT pull 的连结:link
Palmer在这篇中记录了 4.15中 Upstream的内容,同时也讲了哪些还需要加强。还需要加强的部分包括memory model、PLIC、DMA、timer、device tree文档、以及SBI console driver。想了解Linux kernel整体的情况的话,可以参考。想了解更多更新,也可以追踪 patches@groups.riscv.org。
前半段Palmer先介绍了 RISC-V 系统中的 AEE (Application Execution Environment)和 SEE (Supervisor Execution Environment)。在RISC-V中,AEE的部分基本要求包括(小编:scall在2.1中其实已经被更名为ecall):
- The ISA string, which determines what the vast majority of instructions do as well as which registers constitute the machine’s current state.
- The supervisor’s user-visible ABI, which determines what the scall instruction does. This is different than the C compiler’s ABI, which defines the interface between different components of the application.
- The contents of the entire memory address space.
当然,实际上AEE还是要看各操作系统决定的,譬如FreeBSD 和 Linux的AEE就不同。至于Unix-class 的 SEE,则是会由Platform spec 小组订出一些基本要求,Palmer所猜测的定义如下(除了PMA和SBI以外,这跟workshop时小编记录的类似):
- Either the RV32I or RV64I base ISAs, along with the M, A, and C extensions. The F and D extensions are optional but paired together, leaving the possible standard ISAs for application-class SEEs as RV32IMAC, RV32IMAFDC (RV32GC), RV64IMAC, and RV64IMAFDC (RV64GC).
- On RV32I-based systems, support for Sv32 page-based virtual memory.
- On RV64I-based systems, support for at least Sv48 page-based virtual memory.
- Upon entering the SEE, the PMAs are set such that memory accesses are point-to-point strongly ordered between harts and devices.
- An SBI that implements various fences, timers, and a console.
在介绍完AEE和SEE这些系统基本的要求后,Palmer整理了一些RISC-V中 page table的特点:
- Pages are 4KiB at the leaf node, and it’s possible to map large contiguous regions with every level of the page table.
- RV32I-based systems can have up to 34-bit physical addresses with a three level page table.
- RV64I-based systems can have multiple virtual address widths, starting with 39-bit and extending up to 64-bit in increments of 9 bits.
- Mappings must be synchronized via the sfence.vma instruction.
- There are bits for global mappings, supervisor-only, read/write/execute, and accessed/dirty.
- There is a single valid bit, which allows storing XLEN-1 bits of flags in an otherwise unused page tables. Additionally, there are two bits of software flags in mapped pages.
- Address space identifiers are 9 bits or RV32I and 16 bits on RV64I, and they’re a hint so a valid implementation is to ignore them.
- The accessed and dirty bits are strongly ordered with respect to accesses from the same hart, but are optional (with a trap-based mechanism when unsupported)
值得注意的是,像ASID这种额外功能在RISC-V的 Linux kernel中其实还没实作。有兴趣的同学可以把握机会。最后,Palmer介绍了跟device 和DMA有关的部分。因为RISC-V 没有定义IOMMU,目前RISC-V linux kernel 使用 bounce buffer 及 32bit ZOME_DMA 来处理 device addressing的问题。
更多细节可以参考: Palmer 的 All aboard part 9
Shimomura Shigeki 整理了一份约20页的Sodor design doc,详细整理了code structure和每一个档的作用。有在用sodor研究RISC-V,或想学chisel的可以参考。
想透过学chisel学习rocket和BOOM的同学可以参考这个新的repo。这个 repo 用 Jupyter Notebook 来教怎么用chisel写generator。另外,chisel learning journey 的文档也在不断更新,也可以参考或加入chisel learning journey的hangout。
Links:
你恐怕要先问什么是34C3,34C3代表第34届混沌通讯会议(Chaos Communication Congress),是一个常年在德国举办的黑客聚会。
在本届34C3大会上,活跃在开源EDA领域的Clifford Wolf发表了演讲。当中提到了,在开源硬件领域,以RISC-V为代表,今年可以称之为开源硅(Open Silicon)之年了。
演讲中提到了Clifford在RISC-V形式验证当中的一些工作。
If we were to pick one of the largest developments in the open-source hardware industry this year, we’d call 2017 the year of open silicon. In particular the open RISC-V processor came out in hardware that you can play around with now. In ten years, when we’re all running open-silicon “Arduinos”, remember this time. And if you haven’t been watching [Clifford Wolf], you might have missed that he wrote a 3D modelling software called openSCAD or a free FPGA toolchain, project Icestorm.
Link: 34C3: THE FIRST DAY IS A DOOZY
Semiconductor Engineering的Brian Bailey发表了他对于2017年整个行业的思考,每一年他都会咨询他的业界朋友们对新一年的预测,而在第二年的时候他又会让他们去年的预测,看看哪些应验了,而哪些又会让人大吃一惊。
Schirrmeister预测2017对于微处理器行业来说会是很有趣的一年。这一年,MIPS在Imagination的交易中得以继续,而RISC-V则吸引了大量的关注。越来越多的公司认可RISC-V并且有公司表明他们在做相关的开发工作。这一趋势将会在2018年持续下去,这也让一些传统的厂商必须快速作出反应,就像Arm的非常的积极用DsignStart来对RISC-V作出反应一样。
Schirrmeister also predicted that 2017 would be an interesting year for processor architectures. At that point he had said that “even Open Source hardware architectures are looking like they will be very relevant. It’s definitely one of the most entertaining spaces to watch in 2017 and for years to come.” He now responds. “The battle is raging and has resulted in some interesting new business models. MIPS has been spun out as part of the overall Imagination transition, and RISC-V certainly enjoys A LOT of attention with more companies endorsing it and announcing serious product developments for it. This trend will only accelerate in 2018 and has forced some of the traditional players to react fast—like Arm did with its Design Start initiative.
“The semiconductor industry witnessed a consolidation slowdown with new startups offering free, open solutions for today’s design challenges – not to mention established companies moving away from closed architectures,” adds Rick O’Connor, executive director of the RISC-V Foundation. “There is a growing interest in open-source instruction set architectures (ISAs), such as RISC-V. The portability and flexibility of the RISC-V architecture has driven innovation in a number of applications, addressing the increasing demands of our connected world from big data to the IoT. This newfound freedom in silicon design has also encouraged collaboration across the ecosystem by fostering a system-level approach to SoC design.
…
In fact, the RISC-V appears to be creating a lot of excitement. Rick O’Connor, executive director of the RISC-V Foundation, notes that “in 2017, the semiconductor industry witnessed a consolidation slowdown with new startups offering free, open solutions for today’s design challenges – not to mention established companies moving away from closed architectures. There is a growing interest in open-source instruction set architectures (ISAs), such as RISC-V. The portability and flexibility of the RISC-V architecture has driven innovation in a number of applications, addressing the increasing demands of our connected world from big data to the IoT. This newfound freedom in silicon design also has encouraged collaboration across the ecosystem by fostering a system-level approach to SoC design.”
Links:
FOSDEM’18 2018年2月3-4日,FOSDEM (Free and Open Source Developers’ European Meeting)将在比利时的布鲁塞尔举行。
PULP WORKSHOP AT HPCA2018 2018年2月25日,在维也纳的HPCA中,会有一场跟Pulp 有关的workshop。PULP小组会介绍PULP最新的发展,和他们未来的走向,包括PULP-CAPI (Coherent Accelerator Processor Interface) 和 Ariane (Next generation of 64-bit RISC-V implementations)等。详情可参考 pulpino mailing list 中的 < PULP newsletter - 4Q2017 >。
CNRV提供为行业公司提供公益性质的一句话的招聘信息发布,若有任何体系结构、IC设计、软件开发的招聘信息,欢迎联系我们!
整理编集: 宋威、黄柏玮、郭雄飞
欢迎关注微信公众号CNRV,接收最新最时尚的RISC-V讯息!
本作品采用知识共享署名-非商业性使用-相同方式共享 3.0 中国大陆许可协议进行许可。