FPGA開発日記

カテゴリ別記事インデックス https://msyksphinz.github.io/github_pages , English Version https://fpgadevdiary.hatenadiary.com/

RISC-VのPLIC(Platform-Level Interrupt Controller)について

RISC-VのPLIC(Platform-Level Interrupt Controller)について調査している。 以下はRISC-V Privileged Architecture Manualからの抜粋。

Draft Privileged ISA Specification v1.10 - RISC-V Foundation

プラットフォームレベル割り込みコントローラ (PLIC)

7.1 PLIC概要

図7.1に、PLICの簡単な構造を示す。 PLICの主な役割は、I/Oデバイスとして接続されている「グローバル割り込みソース」から、「割り込みターゲット(通常はHARTコンテキスト)」に接続する役割を担う。

複数の割り込みソースからの割り込み通知を、「割り込みゲートウェイ」により制御して単一の「割り込みリクエスト」として出力する。 PLICコアには、各ターゲットに対して選択する割り込みを制御するためのIE(割り込みイネーブル)の組み合わせ表が存在している。 もしターゲットが割り込みイネーブルペンディングしているならば、「割り込み通知」をターゲットに対して送信する。 ターゲットが外部割り込みを受領すると、「割り込みの獲得(interrupt claim)」信号が通知され、該当する割り込みのペンディングbitが解除される。 ターゲットが割り込み処理を完了すると、関連する割り込みゲートウェイに「割り込み処理完了(interrupt completion)」メッセージが送信され、次に別の割り込みリクエストが受信できるようになる。

f:id:msyksphinz:20171209191655p:plain

7.2 割り込みソース

RISC-VのHARTはローカル割り込みとグローバル割り込みを持っている。 このうち、グローバル割り込みだけがPLICで処理される。

ローカル割り込みソース

ローカル割り込みはPLICで処理されず、標準的なソフトウェア割り込みやタイマ割り込みなどが実行される。 ローカル割り込みはグローバル割り込みに比べて応答速度が速く、割り込み要因もmcauseレジスタを通じてすぐに参照することが出来る。

ローカル割り込みはレベルベースであり、対応する割り込み要因のmipビットが設定されると、ペンディングされる。 割り込みハンドラから戻ってきたときに、もう一度同じ割り込みを受け付けないようにするために、割り込みハンドラがハードウェアの通知条件ビットをクリアする必要がある。

標準搭載していないローカル割り込みソースは、マシンモードにてmip/mieレジスタを参照することで確認できる。

グローバル割り込みソース

グローバル割り込みソースはPLICにて処理される。 プラットフォーム独自のPLICの実装に依存するが、どのようなグローバル割り込みソースも、どのようなHARTのコンテキストにも転送される必要がある。

グローバル割り込みソースは様々な形で受け付けることが出来る。 例えば、レベルトリガ方式やエッジトリガ方式、メッセージシグナル方式で受け取ることが出来る。 いくつかのソースはキューを設置し、複数の割り込みリクエストを受理することが出来る。 全てのグローバル割り込みソースは、PLIC内部で処理するために、共通の割り込みリクエストフォーマットに変換される。

7.3 割り込みターゲットとHARTコンテキスト

割り込みターゲットは、通常はHARTコンテキストであり、HARTは権限モードを持っている。 全てのコンテキストが割り込みを受け取る必要はなく、もしプロセッサが割り込みを譲渡する機能を持っていなければ、低い権限のコンテキストは割り込みを受け付ける機能を持つ必要はない。 PLICによる割り込みの発生はmip/sip/uieレジスタmeip/seip/ueipビットに通知される。

各プロセッサコアは割り込みの受付に関するポリシを決定する必要がある。 簡単な例では、ひとつのHARTコンテキストしか動いていない場合は、もっとも高い優先度の高いコンテキストが割り込みハンドラを実行する。 マルチスレッドのようなプロセッサでは複数のスレッドが独立に動いているため、ぷろえっさはHARTコンテキストのうちどれが割り込みの処理に使用されるかを示さなければならない。

PLICはそれぞれの割り込みターゲットを独立に扱い、複数の割り込みターゲットに対する優先度のスキームを考慮しない。 PLICは割り込みのプリエンプションもしくは割り込みのネストのような仕組みについて、考慮することはない。

7.5 割り込みID

グローバル割り込みのソースには、符号無し整数の値が割り当てられる。初期値は1であり、0は割り込みが存在しないことを示す。

割り込みIDは、複数の割り込みが通知され、その優先度が同一だったときに使用される。 この場合、小さい数字の割り込みIDが通知される。

7.6 割り込みの優先度

割り込みの優先度は符号なしの整数で管理されており、0が割り込みが発生していない状況、そして数字が大きくなるとより高い割り込み優先度であることを示す。

各グローバル割り込みソースは、関連する割り込み優先度が割り当てられている。 異なる割り込みソースは同一の優先度セットをサポートする必要はない。 割り込みソースの優先度レジスタはWARLフィールドであり、ソフトウェアが読み書きできるビットを指定できる。 サポートしている優先度の値を見つけるのを簡単にするために、レジスタ内の2bitが有効優先度として有効であるならば、その組み合わせである4つの値はすべて有効な優先度レベルとして取り扱われなければならない。

7.12 割り込みフロー

図7.2に、PLICを通じて割り込み制御を行う場合のメッセージフローを示す。

ゲートウェイは一度に一つの割り込みリクエストしか通知せず、割り込み完了の信号がくるまでは後続の割り込みをフォワードしない。 PLICはゲートウェイから割り込みリクエストを受け取るとIPビットを設定し、ターゲットへの割り込み通知を遅らせる。 ターゲットは新しい割り込みが通知されてから応答するまでに時間がかかるが、割り込みIDを確保するために割り込み獲得リクエストをPLICに対して通知する。 PLICコアはIDをアトミックに通知し、該当するIPビットを開放する。 ハンドラが割り込みを処理すると、割り込み完了通知がゲートウェイに対して送信され、新しい割り込みのリクエストを許可する。

f:id:msyksphinz:20171209191651p:plain

7.13 PLICコア仕様

PLICの操作は非決定性有限オートマトンとして制御されており、入出力のメッセージキューにおいてステートマシンが動作する。

  • レジスタ書き込み : レジスタ書き込みリクエストがキューから取り出されると、内部レジスタに優先度の高い、IEビットのレジスタ書き込みが発生する。
  • リクエスト受領 : 該当する割り込みソースのIPビットがクリアされると、メッセージを含んだ割り込みリクエストがゲートウェイから取り出され、IPビットがセットされる。
  • プロセス獲得 : 割り込み獲得のメッセージがキューから取り出される。ターゲットに対して有効な割り込みリクエストの中で最も優先度の高いものが、IDとともに割り込みキューに設定される。割り込みソースのIPビットがクリアされる。

RISC-V向けRust-Toolchain の仕組み(HiFiveクレート)

RISC-V向け Rustのリポジトリは結構な量のライブラリとツール群が入っているが、HiFive1のサポートパッケージはどのように構成されているのか調査してみた。

riscv-rust-quickstartCargo.tomlにはhttps://github.com/dvc94ch/hifiveを指定する記述があり、ここからクレート(ライブラリのようなもの?)を取得する仕組みになっている。

  • riscv-rust-quickstart/Cargo.toml
[package]
name = "riscv-rust-quickstart"
version = "0.1.0"
authors = ["David Craven <david@craven.ch>"]

[dependencies.hifive]
git = "https://github.com/dvc94ch/hifive"

このHiFive1クレートにはHiFive1制御するためのライブラリ群が含まれている。

github.com

Clock, LED, PLICなどの制御モジュールが入っている。これにより、HiFive1のボードを制御する仕組みになっている。

RISC-V向けRust-Toolchain試行(4. リポジトリの修正試行 → ビルド成功 → HiFive1動作)

f:id:msyksphinz:20171129020950p:plain

前回のRust on RISC-Vのツールチェインのビルドの続き。

msyksphinz.hatenablog.com

riscv-rust-toolchainをビルドするためのソースコード修正

結局なんでうまくいかないのか、GitHubで聞きました。

ヘッダファイルの修正とかは私の方針で合っていて、あとはMakefileの中で環境変数をいくつか修正することで対応ができるようになっている。

github.com

以下の修正を加えることで、make toolchainはうまくビルドできるようになったようだ。ただし相変わらず全体を終わらせるのに2時間程度かかってしまう。

diff --git a/Makefile b/Makefile
index 1846cac..c3043a0 100644
--- a/Makefile
+++ b/Makefile
@@ -59,6 +59,7 @@ $(sysroot_dir)/bin/cc:
 
 rust-build: $(sysroot_dir)/bin/cc
   # --disable-manage-submodules
+       LD_LIBRARY_PATH=$(sysroot_dir)/lib \
        cd $(rust_src) && \
        ./configure --enable-debug \
               --enable-extended \

riscv-rust-quickstartを実行してサンプルプログラムをビルドする

次に、riscv-rust-quickstartを実行する。riscv-rust-quickstartディレクトリ内で、make buildを実行するとどうやら1つサンプルプログラムがビルドされるようだ。

これも一応うまくビルドができた。ビルドにすごく時間がかかったけど(20~30分くらい?)

  • src/main.rs
fn main() {
    init();
    loop {}
}
#[no_mangle]
pub fn mtimer_trap_handler(p: &Peripherals) {
    Clint(p.CLINT).restart();
    Blue::toggle(p.GPIO0);
}
#[no_mangle]
pub fn plic_trap_handler(p: &Peripherals, intr: &Interrupt) {
    let serial = Serial(p.UART0);
    let mut stdout = Port(&serial);

    match *intr {
        Interrupt::GPIO18 => {
...

このプログラムは1秒間に1回割り込みを発生させ、LEDポートの値を反転させる(LED点滅)ものらしい。 あとはGPIOから入力を受け付けて、標準出力にメッセージを出すことが出来るようだ。

VirtualBoxでビルドしているので、HiFive1をVirtualBoxに接続してダウンロードさせる必要がある。 この辺は、Qiitaの記事が詳しいので、こちらの通りに設定してHiFive1にプログラムを書き込めるようにする。

riscv-rust-quickstartをHiFive1に書き込む

ビルドしたriscv-rust-quickstartのプログラムをHiFive1に書き込む。 riscv-rust-quickstartリポジトリにはOpenOCDも含まれており、ツールを使えば書き込むことが出来ると思われる。

cd riscv-rust-quickstart
make openocd

$ make openocd
openocd -f /home/msyksphinz/work/riscv-rust-toolchain/openocd.cfg
Open On-Chip Debugger 0.10.0+dev-00103-g9b4628c9 (2017-12-03-11:03)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
adapter speed: 10000 kHz
Error: The specified debug interface was not found (ftdi)
The following debug interfaces are available:
1: remote_bitbang

Makefile:14: recipe for target 'openocd' failed
make: *** [openocd] Error 1

うーん、上手く行かない。もともとfreemo-e-sdkリポジトリでは上手く書き込みが出来るようなので、こちらに移行するとどうだろう。

$ cd freedom-e-sdk
$ ln -s ~/work/riscv-rust-quickstart/target/riscv32-unknown-none/debug/ software/riscv-rust-quickstart # Freedom-E-SDKのsoftwareディレクトリにリンクを張る。
$ make upload PROGRAM=riscv-rust-quickstart

work/build/openocd/prefix/bin/openocd -f bsp/env/freedom-e300-hifive1/openocd.cfg & \
/home/msyksphinz/work/freedom-e-sdk/work/build/riscv-gnu-toolchain/riscv64-unknown-elf/prefix/bin/riscv64-unknown-elf-gdb software/riscv-rust-quickstart/riscv-rust-quickstart --batch -ex "set remotetimeout 240" -ex "target extended-remot
e localhost:3333" -ex "monitor reset halt" -ex "monitor flash protect 0 64 last off" -ex "load" -ex "monitor resume" -ex "monitor shutdown" -ex "quit" && \
echo "Successfully uploaded 'riscv-rust-quickstart' to freedom-e300-hifive1."
Open On-Chip Debugger 0.10.0-dev (2017-12-03-13:32)
Licensed under GNU GPL v2
For bug reports, read
...
halted at 0x80000004 due to software breakpoint
Info : JTAG tap: riscv.cpu tap/device found: 0x10e31913 (mfg: 0x489 (<unknown>), part: 0x0e31, ver: 0x1)
riscv.cpu: target state: halted
halted at 0x80000004 due to software breakpoint
Start address 0x20400000, load size 124056
Transfer rate: 7 KB/sec, 11277 bytes/write.
halted at 0x20400004 due to step
halted at 0x20400004 due to step
shutdown command invoked
shutdown command invoked
A debugging session is active.

        Inferior 1 [Remote target] will be detached.

Quit anyway? (y or n) [answered Y; input not from terminal]
Remote communication error.  Target disconnected.: Connection reset by peer.
Successfully uploaded 'riscv-rust-quickstart' to freedom-e300-hifive1.

お、書き込めた。Screenで確認すると、1秒間に1回の”MachineTimer"の文字の出力と、HiFive1ボードのLEDの点滅が確認できた!

"MachineTimer"の文字列は riscv-rust-quickstart/src/main.rsには入っていないから、ライブラリ内に記述されているのかなあ。

$ sudo screen /dev/ttyUSB1 115200
Initialized hifive board
MachineTimer
MachineTimer
MachineTimer
MachineTimer
MachineTimer
...

Rustで書いたプログラムがRISC-Vで動く、ちょっと未来を感じるなあ。

f:id:msyksphinz:20171208000014p:plain

Computer Architecture: A Quantitative Approach 第6版を入手しました

この記事は 半導体・ハードウェア開発 Advent Calendar 2017 - Qiita の7日目の記事です。

Advent-Calendarを埋めてくれるかた、今からでも募集中です!是非参加してください! 私一人では、クオリティのある記事を続けられそうにありません。。。(弱音)


前々から話題になっていた、Computer Architecture: A Quantitative Approach Six Editionを手に入れた。 Amazonからの発送が早まっており、本日我が家に届けられた。9月に予約したので、9000円未満で購入したのだが今見ると14,000に跳ね上がっている。。。

f:id:msyksphinz:20171206234233p:plain

Computer Architecture, Sixth Edition: A Quantitative Approach (The Morgan Kaufmann Series in Computer Architecture and Design)

Computer Architecture, Sixth Edition: A Quantitative Approach (The Morgan Kaufmann Series in Computer Architecture and Design)

今回の大きなアップデートとしては、

中身を少し読んでみたが、なるほど、MIPSの部分がすべてRISC-Vに置き換わっている。

Domain Specific Architectureの項目も、Google Pixel Core, Tensor Processing Unitについてかなり深く言及されている(著者の一人のDavid Patterson先生はGoogleに所属しているので、ある程度やりやすいのだろうか)。

f:id:msyksphinz:20171206234627p:plain:w400

RISC-Vに差し替わっているとはいえ、本質的なところは変わっていない。新設されたWSCとDSAのところについて、しっかり読み込んでいこうかな。

RISC-Vの縁もあり、日本語訳についての計画があればご協力できますよ!ぜひ連絡を(笑)

ハードウェア開発・オープンソースの検証プラットフォームを調べてみた

この記事は 半導体・ハードウェア開発 Advent Calendar 2017 - Qiita の6日目の記事です。

Advent-Calendarを埋めてくれるかた、今からでも募集中です!是非参加してください! 私一人では、クオリティのある記事を続けられそうにありません。。。(弱音)


ソフトウェア分野でのテストフレームワークって、非常に多くあるように思う。

ただし、ハードウェア業界におけるテストフレームワークってあまり無いように思う。

主な理由として、 - シミュレーションツールが有料のものしかない。このEDAベンダが非常に古臭くてロクなテストフレームワークを提供しない。 - そもそも絶対人数が少ない - ハードウェアの開発はオープンに行われることが少なく、独自の文化がそれぞれの開発グループの中で作られている。

というわけで、数が少ないながら、オープンソースで公開されているハードウェア検証プラットふぉーおむについて調べてた。

基本的に「デジタル回路」「RTLシミュレーション」に焦点を絞っているのでご了承ください。

VUnit (https://github.com/VUnit/vunit)

個人的に大本命ではないかと思っている。

あまり癖が無く、VerilogPythonで記述してあり使いやすい。 中身を解析しやすく、カスタマイズも行いやすい。

筆者のVUnitを使ってみた記事はこちら。

msyksphinz.hatenablog.com

msyksphinz.hatenablog.com

Pythonで以下のようにテスト環境を記述する。

from os.path import join, dirname
from vunit.verilog import VUnit

ui = VUnit.from_argv()

src_path = join(dirname(__file__), "src")    # ソースファイルの場所を指定できるようにする。

uart_lib = ui.add_library("uart_lib")              # UART本体を格納するためのライブラリを定義する
uart_lib.add_source_files(join(src_path, "*.sv"))  # ライブラリにソースコードを挿入する

tb_uart_lib = ui.add_library("tb_uart_lib")                   # UARTのテストパタンを格納するためのライブラリを定義する
tb_uart_lib.add_source_files(join(src_path, "test", "*.sv"))  # UARTのライブラリにソースコードを挿入する。

ui.main()  # テスト実行

テストケースとテストスイート

TEST_SUITEはテストスイートを定義する。TEST_SUITEの中には、テストケースを定義している。テストケースは、テストスイート内に複数定義することが出来る。

テストケースはそのままテストを記述している。

   `TEST_SUITE begin
      `TEST_CASE("test_send_one_byte") begin
         send();
         check_all_was_received();
      end
      `TEST_CASE("test_send_many_bytes") begin
         for (int i=0; i<7; i++) begin
            send();
         end
         check_all_was_received();
      end
   end

テストケースでは、いくつかのdefineが使用できる。

  • TEST_SUITE_SETUP : 全てのテストスイート共通のセットアップを行う。
  • TEST_CASE_SETUP : 全てのテストケースの共通のセットアップを行う。
  • CHECK_EQUAL : アサーションを記述する。
  • TEST_CASE_CLEANUP : 全てのテストケース共通で、テスト終了後の処理を行う。
  • TEST_SUITE_CLEANUP : 全てのテストスイート共通で、テスト終了後の処理を行う。
  • WATCHDOG : タイムアウト設定

cocotb (https://github.com/potentialventures/cocotb)

こちらもPythonで記述されたプラットフォーム。 Verilogを記述してテストを実行する。 デフォルトのVerilogシミュレータはiverilogらしい。

例えば、以下のような加算器を検証したいとする。 - hdl/adder.v

// Adder DUT
module adder (input [3:0] A,
              input [3:0] B,
              output reg [4:0] X);
  always @(A or B) begin
    X = A + B;
  end

  // Dump waves
  initial begin
    $dumpfile("dump.vcd");
    $dumpvars(1, adder);
  end

endmodule

非常に単純だ。次はPythonで記述されたゴールデンモデル。 - model/adder_model.py

def adder_model(a, b):
    """ model of adder """
    return a + b

単純だ。次に、テストパタンだ。 - cat tests/test_adder.py

# Simple tests for an adder module
import cocotb
from cocotb.triggers import Timer
from cocotb.result import TestFailure
from adder_model import adder_model
import random


@cocotb.test()
def adder_basic_test(dut):
    """Test for 5 + 10"""
    yield Timer(2)
    A = 5
    B = 10

    dut.A = A
    dut.B = B

    yield Timer(2)

    if int(dut.X) != adder_model(A, B):
        raise TestFailure(
            "Adder result is incorrect: %s != 15" % str(dut.X))
    else:  # these last two lines are not strictly necessary
        dut.log.info("Ok!")


@cocotb.test()
def adder_randomised_test(dut):
    """Test for adding 2 random numbers multiple times"""
    yield Timer(2)

    for i in range(10):
        A = random.randint(0, 15)
        B = random.randint(0, 15)

        dut.A = A
        dut.B = B

        yield Timer(2)

        if int(dut.X) != adder_model(A, B):
            raise TestFailure(
                "Randomised test failed with: %s + %s = %s" %
                (int(dut.A), int(dut.B), int(dut.X)))
        else:  # these last two lines are not strictly necessary
            dut.log.info("Ok!")

この例では、通常のテストと、ランダムテストを実施しているみたいだ。 見て分かるとおり、デザインの生成した答えと、ゴールデンモデルが生成した答えが一致しているかを確認している。

        if int(dut.X) != adder_model(A, B):
            raise TestFailure(
                "Randomised test failed with: %s + %s = %s" %
                (int(dut.A), int(dut.B), int(dut.X)))

オープンソースGPGPU "NyuziProcessor" について調査

この記事は 半導体・ハードウェア開発 Advent Calendar 2017 - Qiita の5日目の記事です。

Advent-Calendarを埋めてくれるかた、今からでも募集中です!是非参加してください! 私一人では、クオリティのある記事を続けられそうにありません。。。(弱音)


(この記事は以前にオープンソースGPGPUを調査したときの記事の焼き直しです )

RISC-Vをはじめとする、オープンソースCPUが躍進している。 もともとオープンソースのCPUというのはOpenRISCをはじめとしていろいろ存在したが、オープンソースGPUというのはほとんど存在していなかった。 (もともとGPGPU自体が歴史が浅いしね)。

オープンソースGPGPUの種類

私が見つけたのは以下の2種類だ。

  • NyuziProcessor

https://github.com/jbush001/NyuziProcessor

命令セットも公開されており、テストプログラムも結構充実している。個人で開発しているようだが、完成度はかなり高いように感じる。 今でも積極的に開発が進んでいるようだ。

github.com

  • MIAOW

こちらは大学発のオープンソースGPGPUのようだ。日本国内の国際学会COOLChipsでも発表がされている。

[https://github.com/VerticalResearchGroup/miaow:embed:cite]

[https://www.hotchips.org/wp-content/uploads/hc_archives/hc27/HC27.25-Tuesday-Epub/HC27.25.50-GPU-Epub/HC27.25.512-MIAOW-Balasubramaniam-UWisc-v1.2.pdf]

今回は、NyuziProcessorについて調査した。

NyuziProcessorの構成

NyuziProcessorは以下のような構成を取っており、メインメモリにアクセスするためのAXIバスと、I/Oを制御するためのPeripheral Busから構成されている。

図. NyuziProcessorの構成

NyuziProcessorのダウンロードとビルド

Ubuntuの場合、まずはパッケージをダウンロードする。

sudo apt-get -y install autoconf cmake make gcc g++ bison flex python \
    python3 perl emacs openjdk-8-jdk swig zlib1g-dev python-dev \
    libxml2-dev libedit-dev libncurses5-dev libsdl2-dev gtkwave imagemagick

パッケージのダウンロードとビルドを行う。

git clone https://github.com/jbush001/NyuziProcessor.git
./build/setup_tools.sh

テストを実行するためにはmake testをタイプする。

make[1]: ディレクトリ '/home/msyksphinz/work/NyuziProcessor/tests' に入ります
cd remote-gdb && python3 ./runtest.py
gdb_breakpoint                          [PASS]
gdb_remove_breakpoint                   [PASS]
gdb_breakpoint_errors                   [PASS]
gdb_single_step                         [PASS]
gdb_single_step_breakpoint              [PASS]
gdb_read_write_memory                   [PASS]
gdb_read_write_register                 [PASS]
gdb_register_info                       [PASS]
gdb_select_thread                       [PASS]
gdb_thread_info                         [PASS]
gdb_invalid_command                     [PASS]
gdb_big_command                         [PASS]
gdb_queries                             [PASS]

VivadoでNyuziProcessorを論理合成してみる

NyuziProcessorはALTERAのFPGAでインプリメントするようにできているが、論理合成までならXilinxのツールでも試行できる。

NyuziProcessorのリポジトリをForkして、Vivadoで論理合成する環境を構築する。

github.com

基本的には、Vivadoのスクリプトをそのまま流せばよい。hardware/fpga/de2-115/de2_115.qsfを参考にして、ファイルリストを作成しておこう。 ちなみに、xdcのクロック定義は変えておかないとまずかったがそのままにしていたので、あまり厳密な結果ではない。。。

  • hardware/fpga/de2-115/de2_115.qsf
...
set_global_assignment -name PARTITION_COLOR 16764057 -section_id Top
set_global_assignment -name VERILOG_FILE de2_115_top.sv
set_global_assignment -name VERILOG_FILE ../common/vga_sequencer.sv
set_global_assignment -name VERILOG_FILE ../common/vga_controller.sv
set_global_assignment -name VERILOG_FILE ../common/sdram_controller.sv
set_global_assignment -name VERILOG_FILE ../common/spi_controller.sv
...
  • hardware/fpga/vivado/filelist.tcl
../de2-115/de2_115_top.sv
../common/vga_sequencer.sv
../common/vga_controller.sv
...
cd hardware/fpga/vivado
make

合成結果は以下のようになった。合成ターゲットは 7z020clg484-1 (Xilinx ZYNQ)としている。

ZYNQでは入りきらないらしい。。。

+----------------------------+-------+-------+-----------+--------+
|          Site Type         |  Used | Fixed | Available |  Util% |
+----------------------------+-------+-------+-----------+--------+
| Slice LUTs*                | 84315 |     0 |     53200 | 158.49 |
|   LUT as Logic             | 53182 |     0 |     53200 |  99.97 |
|   LUT as Memory            | 31133 |     0 |     17400 | 178.93 |
|     LUT as Distributed RAM | 28892 |     0 |           |        |
|     LUT as Shift Register  |  2241 |     0 |           |        |
| Slice Registers            | 43411 |     0 |    106400 |  40.80 |
|   Register as Flip Flop    | 43411 |     0 |    106400 |  40.80 |
|   Register as Latch        |     0 |     0 |    106400 |   0.00 |
| F7 Muxes                   |  4058 |     0 |     26600 |  15.26 |
| F8 Muxes                   |  1224 |     0 |     13300 |   9.20 |
+----------------------------+-------+-------+-----------+--------+

f:id:msyksphinz:20171205002730p:plain

NyuziProcessorのコア数はdefines.svで定義されている。

//
// Configurable parameters
// - Number of cache ways must be 1, 2, 4, or 8 (TLB_WAYS does not have
//   this constraint). This is a limitation in the cache_lru module.
// - If you change the number of L2 ways, you must also modify the
//   flush_l2_cache function in testbench/verilator_tb.sv. Comments above
//   that function describe how and why.
// - NUM_CORES must be 1-16. To synthesize more cores, increase the
//   width of core_id_t in defines.sv (as above, comments there describe why).
// - The size of a cache is sets * ways * cache line size (64 bytes)
// - L1D_SETS sets must be 64 or fewer (page size / cache line size) if
//   virtual address translation is enabled. This avoids aliasing in the
//   virtually indexed/physically tagged L1 cache by preventing the
//   same physical address from appearing in different cache sets
//   (see dcache_tag_stage)
//

`define NUM_CORES 1
`define THREADS_PER_CORE 4
`define L1D_WAYS 4
`define L1D_SETS 64        // 16k
`define L1I_WAYS 4
`define L1I_SETS 64        // 16k
`define L2_WAYS 8
`define L2_SETS 256        // 128k
`define AXI_DATA_WIDTH 32
`define HAS_MMU 1
`define ITLB_ENTRIES 64
`define DTLB_ENTRIES 64
`define TLB_WAYS 4

NUM_CORESを4に設定して再合成してみた。

f:id:msyksphinz:20171205004646p:plain

まあ、こんな感じ。あまり詳細な解析までは進まなかった。。。


焼き直し前記事。

msyksphinz.hatenablog.com

msyksphinz.hatenablog.com

msyksphinz.hatenablog.com

msyksphinz.hatenablog.com

2017年のRISC-V界隈振り返り

この記事は 半導体・ハードウェア開発 Advent Calendar 2017 - Qiita の2日目の記事です。

Advent-Calendarを埋めてくれるかた、今からでも募集中です!是非参加してください! 私一人では、クオリティのある記事を続けられそうにありません。。。(弱音)


2017年は、特にRISC-Vにとって重要な年になった。

商用IPを販売するSiFive社が本格的なSoCを投入し、RISC-V Foundationの加盟グループも100を超えてきた。 RISC-V FoundationのPlatinum Membersにも、巨大企業が名を連ねており威厳が増してきている。

RISC-V Foundationの加入メンバーは2017 Q3で100を突破した。

また、多くの半導体ベンダがRISC-Vに対応したハードウェアIP、ソフトウェアツールなどをリリースし始めている。

プロセッサをたしなむ人たちにとってのバイブル、「ヘネパタ」こと「コンピュータアーキテクチャ定量的アプローチ」の第6版も年内に出版される予定であり、こちらもRISC-Vに題材を移行して全体的に刷新される予定である。 少しずつではあるがRISC-Vは軌道に乗り始めた。

Computer Architecture, Sixth Edition: A Quantitative Approach (The Morgan Kaufmann Series in Computer Architecture and Design)

Computer Architecture, Sixth Edition: A Quantitative Approach (The Morgan Kaufmann Series in Computer Architecture and Design)

f:id:msyksphinz:20171128011033p:plain

研究向けのチップ開発から、ソフトウェアエコシステムの構築、プロダクションへの浸透が進む

初期のRISC-V Workshopの頃に比べて、研究向けの発表というよりもプロダクトの発表が多くなってきた。 Crusoeを開発したDavid Ditzel氏が立ち上げたEsperantoが開発している、4KコアのRISC-Vプロセッサが大きくニュースに取り上げられている。

一方で、より学術研究向けのイベントとしてCARRV(Computer Architecture Research with RISC-V)が立ち上げられた。 こちらはプロダクト関連ではなく、IEEE MICROと連携した研究者向けのイベントとなる。 論文も公開されており非常にありがたい。

  • CARRV (Computer Architecture Research with RISC-V )

CARRVのウェブサイト

2011年から2016年のRISC-Vの発展の歴史

下記の画像は私が作った、2011年から2016年、2017年にかけてのRISC-Vの発展を示した資料だ。 最初は研究用として作られたRISC-Vも、仕様が公開されてその性能と使いやすさが認められてから、徐々に発展していることが分かる。

f:id:msyksphinz:20171202155728p:plain

非常に強力なバックアップ

RISC-Vが発展するにあたり非常に重要なキーパーソンとなっているのが、MIPS、というかCPUの発展において非常に重要な役割を果たしている David Patterson氏のバックアップがあることだ。

David Patterson氏自身がRISC-Vを推しているということ、そしてRISC-V FoundationのChirmainであるKrste Asanović氏がPatterson氏の教え子であると言うところが大きい。

f:id:msyksphinz:20171202155724p:plain
David Patterson氏とKrste Asanovic氏

これにより、学術界にもRISC-Vは非常に大きな影響を与える。 「パタヘネ」と呼ばれるコンピュータアーキテクチャの入門書 "Computer Organization and Design" は RISC-V Editionが登場し、「パタヘネ」と呼ばれるより高度な内容を取り扱った書籍 "Computer Architecuter: A Quantitative Approach" は 12月に第6版が出版される予定で、これまでにMIPSで説明されていた内容がRISC-Vに全面的にアップデートされる予定となっている。

f:id:msyksphinz:20171202155720p:plain
"Computer Organization and Design: RISC-V Edition" と "Computer Architecture: A Quantitative Approach 6th Edition"

2017年に発表されたRISC-V実装

普段こういう情報をきちんとまとめていないので抜けがあるかもしないがご愛嬌。 プロダクトとして発表されたものを中心にまとめている。 学術研究としては非常に多くの実装がなされているが、数が多すぎるので省略。CARRVのウェブサイトを参照されたい。

SiFive U64-MC-Coreplex

RISC-Vと言えばSiFive。SiFiveのリリースした64ビットのマルチコアプロセッサがU54-MC-Coreplex IPだ。 RV64GC をサポートしたRISC-Vコアを4つ搭載しており、L1-ICache, L1-Dcacheをそれぞれ最大で32KB持つことが出来る。 また、モニタコアとして載っているRV64IMACをサポートしたシングルコアのRISC-Vプロセッサもあり、かなり本格的な利用を想定している。 また、Linuxもインポートさせ、動作させることが可能だ。

Andes Technology N25, NX25

Andes Technologyが発表したRISC-Vプロセッサ。 N25が32ビットコア、NX25が64ビットコアである。

N25のサポートする命令セットはRV32IMAC, NX25はRV64IMACとなっている。 どちらも基本的な⑤ステージパイプラインで、I-Cache、D-Cacheの構成は8KBから64KBまで変更が可能。 ILM, DLMを持っている。 5ステージのパイプラインだが、分岐予測機構を備えており、BTB(Branch Target Buffer), BHT(Branch History Table), RAS(Return Address Stack)を持っている。

性能的には - N25 2.86 DMIPS/MHz 3.46 CoreMark/MHz - NX25 3.20 DMIPS/MHz 3.45 CoreMark/MHz

Microsemi MI-V

https://www.microsemi.com/products/fpga-soc/mi-v-ecosystemwww.microsemi.com RV32IM RISC-Vを、MicrosemiのFPGAである PolarFire, RTG4, IGLOO2 で動かすことが出来る。

Esperanto Technologies ET-Maxion, ET-Minion

あまり細かい情報は載っていないが、ET-MaxionはRV64GC, ET-Minion はRV64G。 2018/01/26 ET-MinionをRV32と記載していました。ご指摘ありがとうございます。訂正しました。

Codasip Bk5-64

www.codasip.com

Codasip初の64ビットRISC-Vプロセッサは、命令セットとしてRV64I。ただしそれ以外の領域はかなり非サポート。 64ビットコアを作りたかったと言うだけで、それ以外は何も載っていない。

2017/12/18 "RISC-V Day Tokyo" 開催

日本で最初のRISC-V専門のイベントとして、"RISC-V Day Tokyo"が開催される。 - 2017年12月18日 9:30 - 18:30 - 東京大学 伊藤国際謝恩ホール

以下 https://riscv.tokyoから抜粋。

今回のカンファレンスは - ①IoT、AIシステム用ソリューションをFPGAとSoC+ソフトで高い自由度で経済的に商品化したい人 - ②既存マイコンシステムに飽きたら図応用アルゴリズムをハードでアクセラレーションをしたい人 - ③日本だけでなくグローバルに展開できるマイコンシステムを設計したい人 - ④32ビットに加え、64,128ビット数値処理、アドレッシング機能を使用したい人 - ⑤基板ソフト、開発ハード、量産ハード、開発ツールを経済的に調達したい人

に役に立ちます。とのこと。

riscv.org にもアナウンスが出てますね!

私も発表します。

@msyksphinz (FPGA日記著者) : "RISC-Vオープンソース ハードウェア 概説"

https://riscvjp.files.wordpress.com/2017/11/agenda-preliminary-1.jpg?w=840