RISC-V 雙週簡報 (2018-10-14)

要點新聞：

• 位元嘉楠雙雙使用RISC-V
• ARM承認RISC-V的發展使其改進授權模式

RV新聞

位元大陸的BM1880內建RISC-V CPU

位元大陸最近釋出了面向端測的AI晶片BM1880，除了集成了兩顆ARM Cortex A53之外，還集成了1顆1GHz的RISC-V處理器。

小編：有趣的是位元大陸和嘉楠耘智都紛紛在AI上發力，也都選擇了RISC-V。

Links:

RV應用

Hackday評搭載嘉楠K210的Sipeed M1開發板

Hackday最近報道了搭載嘉楠勘智K210端測AI晶片，Sipeed M1（荔枝丹）開發板。這塊板子支援機器視覺和機器聽覺，並且可以在

Links:

RV生態

riscvemu更名為TinyEMU

2018-09-23riscvemu正式更名為TinyEMU.

TinyEMU(原名riscvemu) 是一個x86平臺上的risc-v模擬器， 方便開發者進行risc-v方面的開發和測試，TinyEMU設計簡單，輕量，高效.

國產實時作業系統RT-Thread 4.0版本增強對RISC-V的支援

國產實時作業系統RT-Thread最近舉行了4.0版本釋出會，RTT 4.0增強了對RISC-V支援包括RV64以及RV32/64的SMP支援，以及針對嘉楠K210晶片的BSP。

技術討論

關於RISC-V硬體中斷源

在hw-dev郵件列表有提問關於RISC-V是如何定義硬體中斷介面，比方說中斷請求和中斷響應的管腳（編者按：提問者感興趣的彷彿是具體實現）。 Dr. Jonathan Kimmitt的回答是RISC-V的spec對於具體實現不做規定，RISC-V指令集裡面有關於PLIC的描述(Platform Level Interrupt Controller，平臺級中斷控制器)，具體實現可以參考Rocket的原始碼，以及SiFive的文件。

Gavin Stark則嘗試了總結他對PLIC的理解：

• PLIC會在PLIC關口（gateway）那裡把電平或者邊沿觸發的中斷轉化成為某種中斷請求，中斷請求可以是記憶體對映（memory-mapped）到處理器，處理器完成以後會以某種“中斷完成資訊”告知PLIC。雖然指令集沒有定義什麼樣的“中斷完成資訊”，或者什麼樣的記憶體對映，但是提到可以是通過寫到有記憶體對映的某種I/O暫存器，並且這些暫存器是可以改變當前系統狀態的（編者按：編者理解non-idempotent的意思是對其操作會改變系統狀態）。PLIC關口也可以用來處理類似PCIe的MSI/MSI-X（Message-Signalled Interrupt）那種基於message的interrupt，按照類似邊沿觸發來處理。（編者按：有興趣的讀者可以參考RISC-V指令集1.10，Chapter 7）

• PLIC對每個關口分配一個級別（Priorty），並且對於每個中斷目標（RISC-V的硬體程序，hart）會有相對應的使能訊號。每個關口也會有相對應的中斷閾值（Threshold）。當且僅當關口有中斷產生，並且對應的使能有效，而且級別高於閾值的時候，EIP（External Interrupt Pending）位才會有效。中斷級別從0開始遞增（級別=0代表“永不中斷”）。要是有兩個中斷關口具有相同的級別，那麼級別低者勝（編者按：這裡Gavin好像把Interrupt Identifier等同於Gateway，編者隱約覺得兩者還是不一樣的，比方說同一個Gateway難道只能有一個ID，或者同一個ID必然對應同一個Gateway嗎？歡迎討論。）

• Gavin認為spec沒有規定PLIC的暫存器定義，目前他的經驗是如果不和Rocket Chip一致，那就得自己弄了。如果是沒有中斷，或者是隻有一箇中斷的話完全不必用到PLIC，因為會增加複雜度和片上開銷。

• Gavin隨後補充道Supervisor和User模式也可以分別有自己的中斷輸入，和相對應的使能訊號，所以SEIP（Supervisor External Interrupt Pending）是可以中斷machine的，前提是mideleg.seip和mideleg.ueip都有相對應設定。

Krste教授另外提出mip和mie的bit16及以上都可以用作定製本地中斷的空間（編者按：關於本地中斷local interrupt和全域性中斷global interrupt，參見指令集7.2），另外SiFive也提出了本地核心中斷控制器（Core-Local Interrupt Controller，CLIC）的提案，會提供一個更加靈活的本地中斷控制器。（編者按：參考連結）

Samuel A. Falvo II補充對於UEIP，應該是當且僅當mideleg.ueip=1，存在S-Mode並且sideleg.ueip=1，存在U-Mode並且支援N-Extention的時候才可以是U-Mode的外部中斷。另外他認為外部中斷的管腳個數其實可以有XLEN那麼多個（XLEN表示架構的位寬），因為雖然計時器中斷和處理器間中斷等等只是遵循傳統命名，但是可以用作任何目的。（編者按：儘管會破壞相容性。）

在hw-dev郵件列表上相關討論：連結

多級bootloader的層次劃分、介面和安全性討論

SiFive開源其用於HiFive上的U-Boot原始碼引發了社群關於現在和將來用於RISC-V的bootloader的一系列討論。

其中，Anup Patel希望，將來用於啟動作業系統的最後一級bootloader，最後完全運行於S模式，不包含任何M模式的程式碼，使用SBI向M模式請求底層功能。 這樣的層次劃分主要處於兩個原因：

• 這樣將有利於S模式的虛擬化。當虛擬一個作業系統時，hypervisor可以直接複用最後一級bootloader。
• 和平臺相關的具體硬體服務（熱插拔、啟動重啟、可信啟動等等）都應當由平臺的底層映象完全提供。希望作業系統或最後一級bootloader提供對所有平臺的支援是不可行的。所以，Anup Patel建議RISC-V社群現在就制定關於RISC-V的標準啟動流程。

出於安全的考慮，Ron Minnich有著非常不同的看法。大多數人為，平臺廠商如果能開源其底層bootloader，那麼安全分析人員就可以評估其程式碼，檢驗其安全性，發現並修正錯誤。但這種想法在現實面前好像過於天真了。首先，安全分析人員可能沒有工具鏈來編譯開源的程式碼，即使能看見程式碼，不能執行也是非常難以發現執行時錯誤的，甚至說發現了錯誤也可能無法修正，因為bootloader已經被一次性固化到平臺中。所以，Ron提出應該讓核心提供它自己所需要的M模式實現。這樣，當一個安全漏洞被發現，核心可以通過打補丁和重啟的方式堵住漏洞，而不是更新固化的bootloader，往往更新bootloader是非常困難甚至不可完成的。

Karsten Merker針對他自己在Debian社群的工作，詳盡分析了Linux核心與各種啟動模式(u-boot+device-tree, UEFI+device-tree和UEFI+ACPI)合作時遇到的種種問題。總的來說，他希望板級設計能將底層的bootlaoder放到板上的非易失記憶體中而不是SD卡上，RISC-V能定義一個預設的bootloader載入地址表，以方便多種不同載入源的自動支援。 更具體的資訊，請閱讀他的郵件原文。

最後，Jonathan Neuschäfer對當前使用較多的幾種bootlaoder做了一個總結：

Bootloader分為三種：

1. 底層硬體初始化。
2. 執行時的可呼叫中介軟體，支援系統板級呼叫介面(SBI)
3. 一個完整的bootloader，用於從不同外設/網路讀取核心載荷，並啟動核心。

• SiFive的第一級Bootloader(FSBL)實現了(1)和(3)。
• coreboot主要實現(1)，針對RISC-V的版本為了能啟動Linux也實現了(2)，同時支援(3)，將將能啟動，功能不是非常完整。
• ARM的可信中介軟體(ATF)主要實現(2)，有的時候也實現(3)。
• 在Chrombook上，coreboot實現(1), Depthcharge實現(3)。在使用ARM的crhomebook上，ATF實現(2)。
• 在coreboot+TianoCore的系統上，coreboot實現(1)， TianoCore實現(2)和(3)。
• u-boot一般實現(1)和(3)，也可以用來實現(2)。
• LinuxBoot主要實現(3)。

主要討論郵件：sw-dev[1, 2, 3, 4, 5, 6]

移植Buildroot實現對risc-v的支援

Fabrice Bellard在RISC-V SW Dev說移植了Buildroot,實現對risc-v支援.

Buildroot是一個簡單高效且易於使用來生成嵌入式linux系統的跨平臺工具，整個Buildroot是由Makefile指令碼和Kconfig配置檔案構成的。你可以和編譯Linux核心一樣，通過buildroot配置，menuconfig修改，編譯出一個完整的可以直接燒寫到機器上執行的Linux系統軟體(包含boot、kernel、rootfs以及rootfs中的各種庫和應用程式)。

Fabrice Bellard目前為止，提供的補丁實現瞭如下功能：

• 提供了*musl libc*對32位和64位的risc-v支援
• 提供了Buildroot本身對32位和64位的risc-v的支援
• 內建了以下工具鏈
  • gcc 7.3.0
  • glibc 2.27 (riscv64), glibc 2.26 (riscv32) or musl
  • Linux 4.15 kernel headers

Buildroot support for risc-v的下載地址

假設你是Fedora 27 x86_64系統，你可以通過以下步驟進行安裝:

Untar the buildroot-riscv-xxxx-yy-zz.tar.gz archive. Copy the default RISC-V 64 or RISC-V 32 configuration:

  cp configs/riscv64_defconfig .config

or

  cp configs/riscv32_defconfig .config

(The X Window configurations used for JSLinux are available in riscv64_xwin_defconfig and riscv32_xwin_defconfig. More packages are enabled so the compilation is longer) Edit the configuration and save it (you can change nothing as a first try):

  make menuconfig

Generate the image (it takes a few minutes with the default configuration):

  make

If you want to run the generated image with TinyEMU: Download and compile TinyEMU. Download and untar the diskimage-linux-riscv archive to get the BIOS, Linux kernels and TinyEMU example configurations. In diskimage-linux-riscv, edit buildroot-riscv64.cfg (resp. buildroot-riscv32.cfg) to ensure that the generated Buildroot image path (rootfs.ext2) is correct. Run TinyEMU:

temu buildroot-riscv64.cfg

or

temu buildroot-riscv32.cfg

Log in as root with an empty password.

連結:

開放risc-v 1.0 Verilog原始碼

andrew在RISC-V HW Dev公開了risc-v 1.0的Verilog原始碼. 雖然應該沒有什麼軟體能在這個古董的指令集上執行。但滿足了很多人對risc-v早期實現的好奇心。

連結:

可重新進入的 向量取數/向量存數（VLD/VSD）？

有人提出，向量取數/向量存數（Vector Load/Store）存在這樣一個問題，當出現多個頁缺失（Page Fault）需要處理時，由於只知道是這一條指令導致的，沒有足夠的狀態資訊來確定確切的返回資訊。他想知道 RISCV Vector 工作組有沒有討論過這個問題。

Waterman 回覆說，這個問題在工作組裡和在最近這幾十年有價值的向量機設計中都被討論過了。沒有寫進向量規範手冊裡（V spec document）是因為沒有必要與無授權的軟體介面密切相關。目前流行的提案是，用一個處理向量元素（element-progress）的 CSR 暫存器來表明哪個元素導致了異常。該暫存器還是表明了應該從哪裡重新開始執行向量運算。這樣的話，當處理完頁缺失（Page Fault）之後，舊的元素就不會又再次計算一遍。（值得注意的是，這麼做並不是為了提高效能，這只是為了確保向前處理（forward-progress）。當執行完一條向量指令之後，該 CSR 暫存器會清零，這樣下一條向量指令從元素 0 開始執行。

這個提案跟軟體實現的 TLB 重填（refill）是完全相容的，但需要記住的是，用軟體 TLB 重填（refill）的方式去構建向量機是一個明顯要命的陷阱。想花更多的精力去處理 TLB 不命中（miss）的問題只會加劇 Amdahl 定律（Amdahl Law）的瓶頸（小編注：意思是花費精力這麼做不划算，得不償失），硬體實現能夠節省下來的十分有限。

Waterman 還回答了 Alex Solomatnikov 提出的鏈式（chaining）操作的問題，具體參見 isa-dev

實用資料

關於RISC-V的英文簡報 Last Week in RISC-V

SiFive的Palmer Dabbelt發起了Last Week in RISC-V的Github專案，和雙週簡報類似跟蹤和報道RISC-V的最新進展，歡迎關注。

小編：鑑於兩者都是基於CC-BY-NC-SA的License釋出，所以以後我們將互相補充和引用各自的內容，開源License的好處即在於此。

Links:

TileLink Spec中文版翻譯

在SiFive的授權下，一些國內志願者將SiFive TileLink 規格書1.7.1(草案)翻譯成了中文版。

對於中文版翻譯有任何問題、意見或者建議，可以在此新建Issue，或是直接寫郵件給[email protected]。

貢獻者：

• 翻譯：劉鵬、林容威、李沛南
• 校對：宋威
• 技術支援：郭雄飛

市場相關

Andes RISC-V Con

CRVIC成立大會在張江舉辦

2018年10月17日下午，中國RISC-V產業聯盟（China RISC-V Industry Consortium ）和上海市積體電路行業協會RISC-V專業委員會成立大會在上海張江召開，並同時舉辦了RISC-V產業化高峰論壇。

本次大會得到了上海市經信委，上海市科委、上海市積體電路行業協會、國家積體電路創新中心、芯原控股有限公司、中國RISC-V產業聯盟等多家機構的支援。

行業視角

Arm在其TechCon上對RISC-V的一些迴應

隨著RISC-V得到越來越多的關注，Arm在各種活動上也經常會被問到RISC-V相關的問題。這次Arm TechCon上，CEO Segars迴應中提到了RISC-V的興起一定程度上使得Arm對於CPU授權方式做出了調整。

On the subject of RISC-V, Segars acknowledged the rise of the free alternative has “sometimes” caused Arm to adjust its CPU core licensing. “There’s been open-source and free processors in the past, and none of them have the industry traction Arm has today,” he said.

“We’ve got to take disruption seriously, though, and make our products easy to design in, be the best possible available in terms of performance, and keep the community engrossed in Arm. RISC-V is keeping us on our toes from a technical and business point of view.”

小編認為Arm和RISC-V都會長期合理的各自存在，就像Windows和Linux，而且兩者的相互學習和競爭最終對於整個產業都是好事。

暴走事件

2018年11月

• 2018年11月8日 AndesTech將在在北京中關村舉辦 2018 Andes RISC-V CON
• 2018年11月13-14日 Chisel Community Conference將會在灣區舉辦，會議開放Call for Paper，地點還沒有完全確定

2018年12月

招聘簡訊

CNRV提供為行業公司提供公益性質的一句話的招聘資訊釋出，若有任何體系結構、IC設計、軟體開發的招聘資訊，歡迎聯絡我們！

• 中國科學院資訊工程研究所資訊保安國家重點實驗室處理器安全體系結構團隊招聘: (1) 晶片安全體系結構研究,副研究員/助理研究員； (2) 晶片設計與實現，高階工程師/工程師； (3) 作業系統與軟體開發，高階工程師/工程師。 詳情見招聘啟事。

整理編集: 宋威、黃柏瑋、汪平、林容威、傅煒、巍巍、郭雄飛、黃瑋、李健

感謝：黃銳、熊譜翔

歡迎關注微信公眾號CNRV，接收最新最時尚的RISC-V訊息！