RISC-V 雙週簡報 (2018-05-25)

要點新聞：

• RISC-V Day Shanghai開放註冊和邀請演講者
• FireSim宣佈開源

頭條新聞

RISC-V Day Shanghai開放註冊和邀請演講者

RISC-V基金會在2018年有五場全球範圍內的活動，而6月30日在上海復旦大學光華樓舉辦的RISC-V Day Shanghai你絕對不能錯過，這次研討會除了在全球領域對RISC-V有貢獻的公司外，還召集了幾乎所有國內在RISC-V領域有貢獻的公司和個人。

群頭非常希望和你們在研討會上聊聊如何RISC-V在中國的發展，不論是技術的還是商業的。以及國內中小企業如何通過RISC-V來提高自身優勢等話題。

同時仍然歡迎有興趣來做演講的公司、研究機構或者個人提交你的演講。演講時長可以為25分鐘、15分鐘或者3分鐘的poster preview。演講提交的截止日期是5月28日。 演講提交地址https://app.jiffyevents.com/s/fi1t292ro3或短網址 http://t.cn/R12lge0

對於活動有任何問題可以直接發郵件給Alex Guo [email protected]。

技術討論

關於快速核間通訊的討論(fast hart-to-hart)

先普及一個專用名詞，hart意思是硬體核心的意思。

在郵件組裡有人發起了關於快速的硬體核心間通訊的問題。

常見的核間通訊可以大致被分為幾種，傳統的多核處理器中核心之間的通訊和在NoC中不同Tile中Core的通訊。最開始的討論列舉了各種各樣的核間通訊的手段，不論是FIFO還是通過一致性快取，或者通過某些獨立的硬體，甚至在多個晶片之間的通訊也要被考慮進來。而收到訊息的時候是否觸發中斷，如何處理訊息佇列的空和滿也是要考慮的問題。

在一系列自由討論之後，RoaLogic的Richard Herveille提出了較為普適性的提案，即通過增加3條指令來實現這個功能，而這3條指令被設計成儘可能和具體的硬體實現無關。

If inter-processor communication is FIFO based and we use special instructions, would that solve most of the blocking objections?

A hart sends a message to another hart using a send-message instruction. This gets stored into a dedicated (hardware) FIFO belonging to that hart.

The receiving hart gets interrupted when there’s a message for it. These harts could be either in the same core, chip, or even off-chip.

The sending hart’s command fails (traps?) when the receiver’s message buffer (FIFO) is full, which (most likely) indicates that the receiver is stuck.

The actual communication channel can/should be implementation dependent; direct connections would be low-latency, whereas messages send via the NOC might have higher latency. Messages sent off chip would, obviously, have the highest latency.

Does that mean we’d need 3 instructions (assuming we’re using dedicated instructions)?

• MSTORE: message send; send message to a target hart) and store it in its message-buffer. Traps when target buffer is full.
• MLOAD: message load; load message from local message buffer. Traps when buffer is empty.
• MFLUSH(?): flush local buffer

後續的進一步討論請移步郵件列表~

為什麼RISC-V定義的PPN和VPN位數不一致

在RISC-V的特權指令級定義中，一個記憶體頁的大小為4KB，地址偏移量為12位元，但是在RV32系統中，一個頁表項（VPN和PPN）卻只有10位元。這是因為一個PTE（page table entry）的大小為32位元，其地址是4B對齊的，沒有必要記錄最低的2位元PTE地址。 同時，VPN[1]為10位元，但是PPN[1]卻為12位元。這是為了在32位系統中支援最高64GB（34位元實體地址）的記憶體。一個虛擬地址空間的最大大小為4GB，但是通過將10位的VPN[1]對映到12位的PPN[1]就可以實現多個虛擬地址空間合用64GB實際記憶體。

Link: sw-dev上的討論： 連結

自由的RISC-V (Libre RISC-V)？

Luke Kenneth Casson Leighton 和 Jacob Bachmeyer 想成立一個 Libre RISC-V 的組織來維護自由的RISC-V，以保證RISC-V的logo只被用於開放系統。

Jacob Bachmeyer： Also, some organization needs to be the “face” of the approach and protect the “open general-purpose RISC-V” logo to ensure that it is only used on systems that actually meet the purpose. I was hoping that the Libre RISC-V group might be interested in the idea, if the RISC-V Foundation does not itself take that role.

然而，這個假設和RISC-V的初衷是違背的。 RISC-V是RISC-V基金會的商標。只要符合RISC-V標準，即使不是會員的非商業使用也可以自由使用該商標。

Krste: RISC-V is a trademark of the Foundation. Non-commercial use is granted to non-members for systems that follow the RISC-V standards.

最初加州伯克利的RISC指令集現在已經算進入公有領域，可以被免費使用。但是使用這些指令集的系統不能直接被稱作為RISC-V系統，除非該系統符合RISC-V標準。如果Libre RISC-V不符合上面的原則，就不應該是被稱為RISC-V。

The RISC ISA that was originally designed at Berkeley is effectively public domain, and derivatives can be developed and used freely. But they cannot be called RISC-V, or use RISC-V in their name, except if they follow Foundation guidelines. If “Libre RISC-V” is not following the guidelines, then the project should change it’s name.

關於RISC-V名字的使用規則，是為了防止歧義、社群分散和商標劫持。

The policy around the name was set up to avoid confusion, fragmentation, and/or hijacking.

我(Krste)正式地說，RISC-V基金會致力於推廣最廣泛的軟體多樣性，並不限制RISC-V的使用。

For the record, the Foundation is interested in having the largest possible variety of software run on RISC-V, and not in restricting uses of RISC-V.

一個目的是使能徹底免費和開放的硬體設計，不隱藏任何軟體和韌體。另一個目的則是使能徹底封閉的硬體設計。這兩個目的並不矛盾。這兩個用途對在不同場景下維護安全和自由都至關重要。

One goal is to enable completely free and open hardware designs, with no hidden software or firmware. Another is to enable completely locked-down hardware designs. These goals are not contradictory. Both are valuable for preserving freedoms and security in different scenarios.

Link: isa-dev上的討論： 連結

用 LLVM 編譯 RISC-V 程式碼(Building RISC code with llvm)

Gnanasekar R 發現是使用自己編譯的釋出版模式的 LLVM 無法編譯出帶有壓縮指令集的程式碼，但他使用的 GCC 可以。

Bruce Hoult: LLVM 的優勢：易於修改，所以是人們在 RISC-V CPU 中實現自定義擴充套件指令的編譯器的較好選擇，並可能成為第一個支援新的標準擴充套件指令集的編譯器。最新的 Low RISC LLVM彙編器暫不支援壓縮指令集，可以通過使用 ‘-S’ 引數生成彙編程式碼的方式證明。

Alex Bradbury(lowRISC): 最新的 upstream LLVM 已經支援了壓縮指令集，並提供了多種驗證步驟。 但是同時需要一個補丁 被 upstream 接受以解決 LLVM 無法找到標頭檔案的問題。

Luke Kenneth Casson Leighton: 提醒編譯除錯模式 LLVM 的工程師: ld 需要將所有工作目標檔案放入記憶體，可能導致系統崩潰，即使是超出記憶體空間一點點也會讓編譯程序的執行變得極其緩慢。Bruce Hoult 給出了可完成除錯模式編譯所對應的系統配置建議。Jim Wilson 告知 ld 將需要的所有工作目標檔案放入記憶體的原因: 優化編譯效率，儘量避免頻繁使用系統IO讀取檔案。

Links:

• Upstream LLVM: LLVM and Clang repositories hosted by llvm.org
• sw-dev上的討論： 連結

Sv39系統中一個被選中（taken）分支上的非法目標地址的指令頁錯誤(Instruction page fault for an illegal target address of Sv39 from a taken branch)

chuanhua.chang 提出： 在最新的特權體系結構標準中提到： 指令取指地址和載入（Load）和儲存（Store）的有效地址是 64 位, 63-39 位必須與第 38 位相同, 否則將產生一個頁錯誤。在最新的 ISA 標準中： 當發生一個條件分支或者無條件跳轉，若目標地址不是4位元組對齊時, 將產生一個指令地址不對齊異常。

那麼，一個被選中（taken）分支上的非地址對齊的指令頁錯誤將在這個分支指令上產生一個指令地址不對齊異常，再者（在Sv39系統中）一個被選中（taken）分支上的非法地址，頁錯誤在取指階段將在目標地址上產生還是在分支指令上產生？

建議設定一個在源指令（而非目標指令）中檢測非法目標地址的基本原則，便於除錯。Krste（Asanovic）曾經提到過：可以在分支指令中檢測非對齊地址。但為何不是Sv39非法地址而是非對齊地址? 我們僅需要的是一個針對這兩個異常的優先順序。

Tommy Thorn: 應該是先被觸發的那個中斷，並最好去 riscv-test 查詢有沒有相應的測試用例，否則應該建立一個。

Andrew Waterman: 同意 Tommy Thorn 的觀點，並補充道：為儘可能簡單方便地探測異常，相對於探測虛擬地址是否合法有效，探測非對齊則較為容易。 雖然 ISA 設計選擇有點不一致，但也很務實。

Jacob Bachmeyer: 同時應該注意的是：指令非對齊、指令訪問錯誤和指令頁錯誤在 RISC-V 中都是不同的異常。 使得非法指令地址的取指異常是發生在取指階段而不是放入 PC 階段的決定也出於安全上的考慮（xRET）。可以參考"Intel SYSRET bug"： RedHat Bugzilla, Xen Blog, osdev Wiki

Link: isa-dev上的討論： 連結

構建RISC-V的llvm編譯器的時候崩潰(LLVM compiler crash while building for riscv)

Gnanasekar R 發現在構建RISC-V的llvm編譯器的手崩潰. 從報錯資訊來看來看，除了“collect2: fatal error: ld terminated with signal 9 [Killed]”沒有真正有用的出錯資訊。

因為是在ubuntu 16上編譯，而在linux系統 signal 9的定義是 SIGKILL (確認殺死) 當用戶通過kill -9命令向程序傳送訊號時，可靠的終止程序，從而可以判斷是系統主動發出了殺死程序的訊號，所以最有可能的是系統記憶體資源不夠，導致OOM(Out Of Memory Killer)。討論最後，Bruce Hoult 給出了記憶體和編譯引數的一些參看： LLVM debug builds currently need a minimum of about 10 GB of disk cache for reasonable performance, plus 6 GB per simultaneous program link (i.e. the number of (hyperthreading) cores in your machine, by default).

當前RISC-V的llvm編譯器debug版本，基礎需要10GB，每個連結程序需要6GB,連結程序數預設跟CPU核數一致。但是可以通過LLVM_PARALL_LINK_JOBS巨集來控制。

• 記憶體16G, -DLLVM_PARALL_LINK_JOBS=1
• 記憶體32G, -DLLVM_PARALL_LINK_JOBS=3
• 記憶體48G, -DLLVM_PARALL_LINK_JOBS=8
• 記憶體72G, -DLLVM_PARALL_LINK_JOBS=10
• 記憶體超過128+GB, -DLLVM_PARALL_LINK_JOBS=無限制

Link: RISC-V SW Dev討論 連結

程式碼更新

FireSim宣佈開源

FireSim能夠在亞馬遜F1雲上通過FPGA來加速週期精確的基於rocket-chip的始終速率從十幾MHz到數百MHz級別的模擬。（150MHz下的4核模擬，或者大約10MHz下的1024或4096個節點的使用資料中心的網路通訊和接近16TB記憶體進行的模擬）

在這一版的Release中其支援兩個Case:

1. 單節點並行模擬（不需要模擬網路）：跑一遍SPECInt 2017大約需要一天的時間，也可以boot Fedora。
2. 資料中心/叢集上的模擬：通過乙太網連線的、指令週期精確的超多核心的模擬。

有人問和gem5的關係:

The end goal is similar to gem5 - ultimately we want to collect performance results for some hardware design - but the approaches are different.

In FireSim, the simulator is automatically derived from the RTL that describes a hardware design, in this case Rocket Chip (although the methodology is not specific to Rocket Chip). So the simulator “implements” the RISC-V ISA as an artifact of the fact that it is modeling Rocket Cores (that implement RISC-V) on the FPGA. Similarly, we can plug-in “BOOM Chips” and model those without extra effort, since the simulation is derived from the RTL (this is a WIP, should show up on a branch soon).

With our automation, we’re aiming to achieve the ease-of-use of gem5, but with the performance of FPGA-accelerated simulation, all while being derived from real hardware implementations rather than handwritten abstract-models.

點評：群頭必須告訴你的是，未來半導體公司必須開始重視雲端計算能給我們的生產力所帶來的改進，從AWS F1到國內雲端計算廠商都開始部署FPGA雲，儘管這些雲99%都不是用來做IC模擬加速或者驗證的，但是正式因為有了其他99%的應用，才能有效的拉低雲上FPGA的價格，從而有效的降低研發成本和提高生產力，我認為這也是Agile Hardware Developtment中重要的一個環節。

rocket-chip更新詳細的gdb除錯指南

來自法國的 Noureddine Ait Said (@noureddine-as) 在 Rocket Chip 的 增加了關於使用 GDB 除錯 emulator 的文件。

該文件描述瞭如何以跟 Spike 一樣的方式使用 GDB 去除錯執行在 Rocket Chip （使用 verilator）的模擬器上。

Links:

實用資料

Chisel教程(Chisel tutorials)

Martin Schoeberl 在chisel-users討論組中提到要歐洲推廣Chisel， 並向兩個會議提交了兩個半天的教程提案，希望在教程中有一些動手實驗。 Edward Wang 和 Yaman Umuroglu 都推薦了generator-bootcamp，generator-bootcamp 是一個基於jupyter的互動式Chisel教程。

通過generator-bootcamp能夠在閱讀教程同時編寫scala並執行輸出，及時檢視輸出結果。同時generator-bootcamp的環境安裝簡單，能夠跨平臺執行。

安裝方法：

執行效果：

• generator-bootcamp教程目錄

• 進入generator-bootcamp教程詳情頁

• jupyter執行Chisel效果

• Chisel效果Verilog效果

Chisel是由伯克利大學釋出的一種開源硬體構建語言，建立在Scala語言之上，是Scala特定領域語言的一個應用，具有高度引數化的生成器(highly parameterized generators)，可以支援高階硬體設計。Chisel是是一個純scala語言的庫，而scala是一門多正規化（multi-paradigm）的程式語言，設計初衷是要整合面向物件程式設計和函數語言程式設計的各種特性，Scala執行在Java虛擬機器上，併兼容現有的Java程式。所以可以很好的執行在windows，linux和macos系統上。

對於英文最好的教程可能是官方wiki, CSDN有一個不錯偏實踐操作的中文教程

Links:

行業視角

John Hannessy和David Patterson接受Recode的採訪

兩點陣圖靈獎獲得者最近接受了Recode的創始人Kara Swisher的採訪。整篇訪談非常值得完整的聆聽，當然在這裡我們只摘取和RISC-V相關的部分。

DP: That’s the one that I’m particularly interested in, and this, I think I talked about earlier with RISC-V, this open-source instruction set.

In the past, you know, we’ve had to wait for Intel. We have to beg Intel to make a change before we can do anything. Now we don’t have to beg anybody. We can jump in there, come up, try ideas, put them online through these field programmable gate arrays, and see if they work. And not only that, you don’t have to work for Intel or ARM. Anybody in the world can do this. So we could see this potentially rapid acceleration of innovation around security with architecture and software systems. We need to get better at this, and I can imagine this path working. And so yeah, that’s what I think that’s a really exciting thing to work on.

Rupert Baines的巴塞羅那研討會觀後感

Rupert Baines是UltraSoC的CEO，一位業界老兵。他在Eembedded Computing上發表了自己最近參加完巴塞羅那會議之後的觀後感。

Between the 6th Workshop in Shanghai in May 2017 and the 8th Workshop in Barcelona, the industry has moved from discussing the fundamentals of the ecosystem, to making solid choices about implementation and security. We’re now starting to see and hear about products that are well down the road in development. Several groups brought RISC-V based systems to Barcelona, running various flavors of Linux—the RISC-V desktop PC is now a reality, including multi-core systems.

…

With all this positive news, why am I still uneasy? With any new technology, the question of “Are we there yet?” will always come up. Many technologies don’t fulfill their potential, so the question is valid. Where is RISC-V then, in terms of development and adoption? Is it living up to the hype? There’s a large gap between a great idea and commercial success.

I don’t think RISC-V has quite crossed the chasm yet. There’s still a feel of early adopters and evangelists, and people wanting to see it move to the next stage. They want to see commitment and designs from more companies, which is why people were clamoring to see working demos. We’re getting there, and things are moving quickly. But we do need the industry to work harder to make it all happen. We’re now seeing the early adopters.

Links:

zGlue的System-on-a-Chip

zGlue是一家初創公司，試圖通過封裝技術來將諸如CPU、感測器等不同的小晶片整合在一起來製造面向IoT的小晶片(chiplet)。

在TechCrunch的採訪中，zGlue的創始人Ming Zhang提到了他對RISC-V的看法。

Zhang, too, said RISC-V offers some potential, especially in its own scope. “RISC-V is a great tool to build small, fast, and low power IoT applications,” he said. “The nature of open source makes it more available to more people. We welcome and embrace RISC-V to join the family of ‘MCU’ chiplets supported by our technology.”

市場相關

IPnest的最新報告顯示去年ARM在CPU IP上的收入同比下滑

IPnest在SemiWiki上的最新調查顯示，2017年整個行業Desgin IP的收入增長了大約12.4%。ARM依然坐頭把交椅，但是其收入同比去年減少了6.8%。

另一方面，RISC-V開始展現其強勁的勢頭，預計2019年結果便得以揭曉。

ARM is obviously #1 in the CPU category, and will probably keep this position for a long time due to the royalty mechanism. Nevertheless, we can see that ARM CPU IP license revenue has declined by 6.8% YoY, more than compensated by the royalty revenue growing by 17.8%. The reasons may be multiple. After the ARM acquisition by SoftBank, the accounting policy was changed creating what Eric calls an “artifact”. However, in my opinion we are starting to see the impact of RISC-V becoming a credible alternative to the ARM CPU hegemony. The 2019 Design IP report should confirm this.

Links:

AndesTech和SiFive在上海同時推廣RISC-V

5月17日，在上海的同一家酒店，SiFive和AndesTech各自舉辦了其技術推廣研討會，吸引了不少國內的愛好者參加。

Links:

暴走事件

六月

• 2nd CARRV 第二次CARRV workshop(Computer Architecture Research with RISC-V ) 將在6月2日和ISCA 2018共同舉辦。
• 2018年7月1日，也就是RISC-V Day Shanghai的後一天會有HelloLLVM的線下聚會活動，具體地點和時間還未確定，何不一波流來上海玩一把？

七月

十月

• RISC-V Day Tokyo (mid-October TBD)

十二月

招聘簡訊

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

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

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