組み込み向けプロセッサの性能評価指標、ベンチマークを動作させる

この記事は ハードウェア開発、CPUアーキテクチャ Advent Calendar 2016 - Qiita の9日目の記事です。

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

前回のベンチマーク紹介に続き、無料で使うことのできるベンチマークプログラムをコンパイルして、ZedBoardで動作させてみようと思う。

また、Verilogの本格的なシミュレータ環境を持っていなくても、Verilatorを使ってRISC-VのRocketチップを動作させることが出来る。

これについても、やり方を少し触れておきたい。

1. ZedBoard上のCortex-A9上でベンチマークを動作させる

ZedBoard上のZynqに搭載されているCortex-A9で、Linuxを動作させる記事は、既にかなりの量で紹介されている。

• ZedBoard用のUbuntu Linuxをビルド１（PLをビルド）

FPGAの部屋 ZedBoard用のUbuntu Linuxをビルド１（PLをビルド）

では、今回は立ち上がったLinux上でベンチマークを動作させようと思う。

Dhrystone ZedBoardで動作させる

Dhrystone自体は、SDカードにアーカイブを保存しておき、ZedBoard上のLinuxで展開する。

さらにコンパイルするためには、Makefileの-DTIMEのコメントアウトを解除する。-DTIMESのコメントアウトする。

バイナリが完成すると、実行してみる。最初にベンチマークの実行回数を入力する必要がある。ここでは、10000000 を指定した。

root@linaro-ubuntu-desktop:~/work# ./gcc_dry2

Dhrystone Benchmark, Version 2.1 (Language: C)

Program compiled without 'register' attribute

Please give the number of runs through the benchmark: 10000000

Execution starts, 10000000 runs through Dhrystone
Execution ends

Final values of the variables used in the benchmark:

Int_Glob:            5
        should be:   5
Bool_Glob:           1
        should be:   1
Ch_1_Glob:           A
        should be:   A
Ch_2_Glob:           B
        should be:   B
Arr_1_Glob[8]:       7
        should be:   7
Arr_2_Glob[8][7]:    10000010
        should be:   Number_Of_Runs + 10
Ptr_Glob->
  Ptr_Comp:          86024
        should be:   (implementation-dependent)
  Discr:             0
        should be:   0
  Enum_Comp:         2
        should be:   2
  Int_Comp:          17
        should be:   17
  Str_Comp:          DHRYSTONE PROGRAM, SOME STRING
        should be:   DHRYSTONE PROGRAM, SOME STRING
Next_Ptr_Glob->
  Ptr_Comp:          86024
        should be:   (implementation-dependent), same as above
  Discr:             0
        should be:   0
  Enum_Comp:         1
        should be:   1
  Int_Comp:          18
        should be:   18
  Str_Comp:          DHRYSTONE PROGRAM, SOME STRING
        should be:   DHRYSTONE PROGRAM, SOME STRING
Int_1_Loc:           5
        should be:   5
Int_2_Loc:           13
        should be:   13
Int_3_Loc:           7
        should be:   7
Enum_Loc:            1
        should be:   1
Str_1_Loc:           DHRYSTONE PROGRAM, 1'ST STRING
        should be:   DHRYSTONE PROGRAM, 1'ST STRING
Str_2_Loc:           DHRYSTONE PROGRAM, 2'ND STRING
        should be:   DHRYSTONE PROGRAM, 2'ND STRING

Microseconds for one run through Dhrystone:    0.6
Dhrystones per Second:                      1666666.6

Coremarkを実行させる

Coremarkも同様に、Cortex-A9上のLinuxでコンパイルして実行できる。

make[1]: Leaving directory `/root/work/benchmarks/coremark_v./coremark.exe
2K performance run parameters for coremark.
CoreMark Size    : 666ktop:~/work/benchmarks/coremark_v1.0# make PORT_DIR=linux c
Total ticks      : 16252
Total time (secs): 16.252000
Iterations/Sec   : 1845.926655
Iterations       : 30000
Compiler version : GCC4.6.3
Compiler flags   : -O3 -DPERFORMANCE_RUN=1  -lrt
Memory location  : Please put data memory location here
                        (e.g. code in flash, data on heap etc)
seedcrc          : 0xe9f5
[0]crclist       : 0xe714
[0]crcmatrix     : 0x1fd7
[0]crcstate      : 0x8e3a
[0]crcfinal      : 0x5275
Correct operation validated. See readme.txt for run and reporting rules.
CoreMark 1.0 : 1845.926655 / GCC4.6.3 -O3 -DPERFORMANCE_RUN=1  -lrt / Heap

実際のところは性能はどうなのよ？

EEMBC - CoreMark - Processor Benchmark

Coremark Proを動作させる

こちらも同様に、Cortex-A9上のLinuxでコンパイルして実行できる。実行結果は以下のようになった。

UID     Suite   Name    Contexts        Workers Item Fails      Time(secs)      Iterations      It/s    Codesize        Datasize        Variance        Standard Deviation
#Results for run started at 70001:00:32:45 XCMD=
236760500       MLT     cjpeg-rose7-preset      1       default 0          0.074        1       13.5135135135135        66495   266828
490760323       MLT     core    1       default 0           9.37        1       0.106723585912487       42277   3688
1046644201      MLT     linear_alg-mid-100x100-sp       1       default 0          0.135        1       7.40740740740741        45423   3388
1814569103      MLT     loops-all-mid-10k-sp    1       default 0           3.04        1       0.328947368421053       54130   6912
549578576       MLT     nnet_test       1       default 0          2.473        1       0.404367165386171       45041   42844
780641437       MLT     parser-125k     1       default 0          0.351        1       2.84900284900285        52527   1468
1862946660      MLT     radix2-big-64k  1       default 0          0.119        1       8.40336134453782        1420169 1712
1050863061      MLT     sha-test        1       default 0          0.049        1       20.4081632653061        50823   1556
946108807       MLT     zip-test        1       default 0            0.1        1       10      87499   1660

2. Rocket-ChipのRTLをVerilatorで動作させ、ベンチマークを実行したい。

本当は自分でコンパイルしたCoremarkをRTLで動作させたかったのだが、時間切れ。。。あとで追記したい。

RocketChipをRTLシミュレーションするための環境は既に構築されており、RocketChipのリポジトリをダウンロードするだけで良い。

github.com

VCSとVerilatorの方法が紹介されている。私はVCSなどという高価なシミュレータは持っていないので、無料のVerilatorを使って動作させたい。

Verilatorで(既にリポジトリに登録されている)ベンチマークを動作させる方法

cd $ROCKETCHIP/emulator
make output/dhrystone.riscv

outputディレクトリには、dhrysoten.riscv(RISC-VでコンパイルされたDhrystone) バイナリが配置されており、このバイナリをロードして実行している。+verboseオプションが入っていると、output/dhrystone.riscv.outにパイプラインの動作結果が入っているはずだ。

using random seed 1481204383
C                   0:          0 [0] pc=[01b275ab7a] W[r 0=0000000000000000][0] R[r30=47ed8219deb18ce6] R[r12=eec807c6a88f1dbd] inst=[d4cf0a6f] jal     s4, pc - 0xfab4
C                   0:          1 [0] pc=[01b275ab7a] W[r 0=0000000000000000][0] R[r30=47ed8219deb18ce6] R[r12=eec807c6a88f1dbd] inst=[d4cf0a6f] jal     s4, pc - 0xfab4
C                   0:          2 [0] pc=[01b275ab7a] W[r 0=0000000000000000][0] R[r30=47ed8219deb18ce6] R[r12=eec807c6a88f1dbd] inst=[d4cf0a6f] jal     s4, pc - 0xfab4
C                   0:          3 [0] pc=[01b275ab7a] W[r 0=0000000000000000][0] R[r30=47ed8219deb18ce6] R[r12=eec807c6a88f1dbd] inst=[d4cf0a6f] jal     s4, pc - 0xfab4
C                   0:          4 [0] pc=[01b275ab7a] W[r 0=0000000000000000][0] R[r30=47ed8219deb18ce6] R[r12=eec807c6a88f1dbd] inst=[d4cf0a6f] jal     s4, pc - 0xfab4
C                   0:          5 [0] pc=[01b275ab7a] W[r 0=0000000000000000][0] R[r30=47ed8219deb18ce6] R[r12=eec807c6a88f1dbd] inst=[d4cf0a6f] jal     s4, pc - 0xfab4
C                   0:          6 [0] pc=[01b275ab7a] W[r 0=0000000000000000][0] R[r30=47ed8219deb18ce6] R[r12=eec807c6a88f1dbd] inst=[d4cf0a6f] jal     s4, pc - 0xfab4
C                   0:          7 [0] pc=[01b275ab7a] W[r 0=0000000000000000][0] R[r30=47ed8219deb18ce6] R[r12=eec807c6a88f1dbd] inst=[d4cf0a6f] jal     s4, pc - 0xfab4
C                   0:          8 [0] pc=[01b275ab7a] W[r 0=0000000000000000][0] R[r30=47ed8219deb18ce6] R[r12=eec807c6a88f1dbd] inst=[d4cf0a6f] jal     s4, pc - 0xfab4
C                   0:          9 [0] pc=[01b275ab7a] W[r 0=0000000000000000][0] R[r30=47ed8219deb18ce6] R[r12=eec807c6a88f1dbd] inst=[d4cf0a6f] jal     s4, pc - 0xfab4
C                   0:         10 [0] pc=[01b275ab7a] W[r 0=0000000000000000][0] R[r30=47ed8219deb18ce6] R[r12=eec807c6a88f1dbd] inst=[d4cf0a6f] jal     s4, pc - 0xfab4
C                   0:         11 [0] pc=[01b275ab7a] W[r 0=0000000000000000][0] R[r30=47ed8219deb18ce6] R[r12=eec807c6a88f1dbd] inst=[d4cf0a6f] jal     s4, pc - 0xfab4
C                   0:         12 [0] pc=[01b275ab7a] W[r 0=0000000000000000][0] R[r30=47ed8219deb18ce6] R[r12=eec807c6a88f1dbd] inst=[d4cf0a6f] jal     s4, pc - 0xfab4
C                   0:         13 [0] pc=[01b275ab7a] W[r 0=0000000000000000][0] R[r30=47ed8219deb18ce6] R[r12=eec807c6a88f1dbd] inst=[d4cf0a6f] jal     s4, pc - 0xfab4

訳わからないトレースログが出ているのだが、[1] pcでgrepすることで有効な命令を抽出することが出来る。

grep "\[1\] pc" dhrystone.riscv.out > dhrystone.riscv.inst

C                   0:     120610 [1] pc=[00800011e4] W[r 0=0000000080002f40][0] R[r14=00000000800031e0] R[r15=0000000000000042] inst=[d6f70023] sb      a5, -672(a4)
C                   0:     120611 [1] pc=[00800011e8] W[r 0=00000000800011ec][1] R[r 1=0000000080002130] R[r 0=0000000000000000] inst=[00008067] ret
C                   0:     120615 [1] pc=[0080002130] W[r15=4e4f545359524844][1] R[r 8=00000000800256b0] R[r 8=0000000000000003] inst=[f2843783] ld      a5, -216(s0)
C                   0:     120616 [1] pc=[0080002134] W[r 9=0000000000000002][1] R[r 0=0000000000000000] R[r 2=0000000000000003] inst=[00200493] li      s1, 2
C                   0:     120617 [1] pc=[0080002138] W[r11=0000000080025620][1] R[r 8=00000000800256b0] R[r16=0000000000000003] inst=[f7040593] addi    a1, s0, -144
C                   0:     120618 [1] pc=[008000213c] W[r 0=0000000080025620][0] R[r 8=00000000800256b0] R[r15=4e4f545359524844] inst=[f6f43823] sd      a5, -144(s0)
C                   0:     120650 [1] pc=[0080002140] W[r15=4152474f52502045][1] R[r 8=00000000800256b0] R[r 0=0000000000000000] inst=[f2043783] ld      a5, -224(s0)
C                   0:     120651 [1] pc=[0080002144] W[r10=0000000080025600][1] R[r 8=00000000800256b0] R[r16=4e4f545359524847] inst=[f5040513] addi    a0, s0, -176
C                   0:     120652 [1] pc=[0080002148] W[r 0=00000000800255f4][0] R[r 8=00000000800256b0] R[r 9=0000000000000002] inst=[f4942223] sw      s1, -188(s0)
C                   0:     120653 [1] pc=[008000214c] W[r 0=0000000080025628][0] R[r 8=00000000800256b0] R[r15=4152474f52502045] inst=[f6f43c23] sd      a5, -136(s0)
C                   0:     120654 [1] pc=[0080002150] W[r15=20444e2732202c4d][1] R[r 8=00000000800256b0] R[r24=4152474f52502047] inst=[f3843783] ld      a5, -200(s0)
C                   0:     120656 [1] pc=[0080002154] W[r 0=0000000080025630][0] R[r 8=00000000800256b0] R[r15=20444e2732202c4d] inst=[f8f43023] sd      a5, -128(s0)
C                   0:     120657 [1] pc=[0080002158] W[r15=0000000049525453][1] R[r 8=00000000800256b0] R[r20=4152474f52502047] inst=[f3442783] lw      a5, -204(s0)
C                   0:     120659 [1] pc=[008000215c] W[r 0=0000000080025638][0] R[r 8=00000000800256b0] R[r15=0000000049525453] inst=[f8f42423] sw      a5, -120(s0)
C                   0:     120660 [1] pc=[0080002160] W[r15=000000000000474e][1] R[r 8=00000000800256b0] R[r18=4152474f52502047] inst=[f3245783] lhu     a5, -206(s0)
C                   0:     120663 [1] pc=[0080002164] W[r 0=000000008002563c][0] R[r 8=00000000800256b0] R[r15=000000000000474e] inst=[f8f41623] sh      a5, -116(s0)
C                   0:     120664 [1] pc=[0080002168] W[r15=0000000000000000][1] R[r 8=00000000800256b0] R[r17=000000000000474f] inst=[f3144783] lbu     a5, -207(s0)
C                   0:     120667 [1] pc=[008000216c] W[r 0=000000008002563e][0] R[r 8=00000000800256b0] R[r15=0000000000000000] inst=[f8f40723] sb      a5, -114(s0)
C                   0:     120668 [1] pc=[0080002170] W[r15=0000000000000001][1] R[r 0=0000000000000000] R[r 1=0000000000000003] inst=[00100793] li      a5, 1
C                   0:     120669 [1] pc=[0080002174] W[r 0=00000000800255fc][0] R[r 8=00000000800256b0] R[r15=0000000000000001] inst=[f4f42623] sw      a5, -180(s0)
C                   0:     120670 [1] pc=[0080002178] W[r 1=000000008000217c][1] R[r31=00000000800256b3] R[r12=0000000000000003] inst=[92cff0ef] jal     pc - 0xed4
C                   0:     120732 [1] pc=[00800012a4] W[r 2=0000000080025510][1] R[r 2=0000000080025530] R[r 0=0000000000000000] inst=[fe010113] addi    sp, sp, -32
C                   0:     120733 [1] pc=[00800012a8] W[r 0=0000000080025520][0] R[r 2=0000000080025510] R[r 8=00000000800256b0] inst=[00813823] sd      s0, 16(sp)
C                   0:     120734 [1] pc=[00800012ac] W[r 0=0000000080025518][0] R[r 2=0000000080025510] R[r 9=0000000000000002] inst=[00913423] sd      s1, 8(sp)
C                   0:     120735 [1] pc=[00800012b0] W[r 0=0000000080025528][0] R[r 2=0000000080025510] R[r 1=000000008000217c] inst=[00113c23] sd      ra, 24(sp)
C                   0:     120736 [1] pc=[00800012b4] W[r 8=0000000080025600][1] R[r10=0000000080025600] R[r 0=0000000000000000] inst=[00050413] mv      s0, a0
C                   0:     120737 [1] pc=[00800012b8] W[r 9=0000000080025620][1] R[r11=0000000080025620] R[r 0=0000000000000000] inst=[00058493] mv      s1, a1
C                   0:     120738 [1] pc=[00800012bc] W[r11=0000000000000059][1] R[r 9=0000000080025620] R[r 3=000000008000217f] inst=[0034c583] lbu     a1, 3(s1)
C                   0:     120770 [1] pc=[00800012c0] W[r10=0000000000000052][1] R[r 8=0000000080025600] R[r 2=000000008000217f] inst=[00244503] lbu     a0, 2(s0)
C                   0:     120771 [1] pc=[00800012c4] W[r 1=00000000800012c8][1] R[r31=0000000080025603] R[r29=000000008000217f] inst=[fbdff0ef] jal     pc - 0x44

ちなみに、Dhrystoneは以下のディレクトリでコンパイルされており、これを真似るとCoremarkもコンパイル出来るはずなのだが。。。

cd rocket-chip/riscv-tools/riscv-tests/benchmarks/
make

CPUの性能を測る基準、ベンチマークについて

この記事は ハードウェア開発、CPUアーキテクチャ Advent Calendar 2016 - Qiita の8日目の記事です。

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

今日はRISC-Vから少し離れて、CPUの性能を測定するための一般的な性能指標、ベンチマークについていくつか紹介したいと思う。

1. そもそもマイクロプロセッサの性能を測定する基準とは

まず、単純なカタログスペックでCPUを比較することを考えると、例えば「動作周波数」「キャッシュサイズ」「メモリバンド幅」「命令リピートレート」などのパラメータがあるだろう。

しかしそれだけではCPUの性能を把握するには十分ではない。いくつかの「一般的な」ベンチマークプログラムを走らせ、実際のアプリケーションにてどの程度の性能が得られるか、測定してみる必要があるだろう。 プログラムを流して性能を測定する場合、プログラムの特徴が把握されてしまえば、そのプログラムに最適化することで「ベンチマークプログラムのみ高速」なCPUとなってしまう。 これを(ある程度)防ぐため、ベンチマークプログラムは通常いくつかの異なる種類の処理を行わせているか、「ベンチマークセット」として、異なるプラグラムセットを動作させ、各々の結果を見て複合的に判断することが多い。

2. 一般的に用いられているベンチマークプログラムとは何なのか

では、一般的に、どのようなベンチマークプログラムが用いられているのだろうか？こういうことを調べるためには、有名どころ書籍を読んでみるのが一番だ。

• Computer Architecture: Quantitative Approach

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

通称ヘネパタ本。コンピュータアーキテクチャを専攻する研究室ではまずこれを読まされることが多い。

• Superscalar Microprocessor Design

Superscalar Microprocessors Design (Prentice Hall Series in Innovative Technology)

通称は良く知らないが、スーパスカラプロセッサについて調査するときは大体この本を参照することが多い。

• Modern Processor Design: Fundamentals of Supersacalar Processor

Modern Processor Design: Fundamentals of Superscalar Processors

あまりモダンな内容では無いが基礎となる部分はしっかり解説してある。ただし内容が古い。

それぞれ、どのようなベンチマークプログラムが、性能測定に利用されているのだろうか？

SPEC Benchmarks

SPEC Benchmarks

おそらく、ベンチマークプログラムの最も有名なもの。ただし有料。SPEC 2006では以下のようなプログラムがベンチマークセットとして登録されている。整数系のベンチマークセットであるSPECINT, 浮動小数点系のベンチマークであるSPECFPが存在している。以下の画像はComputer Architecture: Quantitative Approach P.39より抜粋。

なお、同書には、サーバ向けベンチマークとしてSPECSFS、ウェブサーバ向けとしてSPECWeb、さらにトランザクションのベンチマーキングプログラムとしてTPC Benchmarksなども紹介されている。

Mike Johnson本で扱われているベンチマーク

次に、Superscalar Microprocessor Design で扱われているベンチマークは、SPECで扱われているベンチマークとセットが少し異なる。 しかしどちらにしても基本的な考え方は変わっておらず、様々な処理に対応したベンチマークを揃えることで、より公平なベンチマークを取ろうとしている。

Benchmark Name	Description
5diff	text file comparison
awk	pattern scanning and processing
ccom	optimizing C compiler
compress	file compressing
doduc	Monte-Carlo simulation,
espresso	logic minimization
gnuchess	computer chess program
grep	reports occurences of a string in one or more text files
irsim	delay simulator for VLIS layouts
latex	document preparation system
linpack	linear equation solver, double precision floating point
nroff	text formatter for a typewritter-like device
simple	hyrodynamics code
spice2g6	circuit simulator
troff	text formatter for typesetting device
wolf	standard-cell placement using simulated annealing
whetstone	standard floating point benchmark, double precision floating point
yacc	compiles a context-free grammar into LR 1 parser tables

Dhrystone

これも有名なベンチマークセットだ。

dhrystone 2.1 - Download, Browsing & More | Fossies Archive

しかし、dhrystoneは昔から存在したベンチマークで内容も比較的単純であり、各ベンタによりDhrystone対策が進んでしまい、ほぼベンチマークとしての意味を成さなくなってしまっている。 公平なベンチマークプログラムとして用いるのには、少し力不足だ。

EEMBC

もう一つ、上記の書籍ではあまり登場しないのだが、個人的に良くお世話になっているベンチマークセットについて紹介しようと思う。

組み込み向けのベンチマークプログラムの有名所として、EEMBCのベンチマークプログラムが存在する。組み込み向けのマイクロプロセッサについては、こちらのベンチマークセットを使うことが多い。

www.eembc.org

EEMBCは様々な用途のベンチマークセットを公開しており、主要なところで言うと(私が大好きな)Coremark, Coremark-Pro, Floating-Point Benchmark, Automotive Benchmarkなど、さらにはAndEBenchなどというAndroid向け？のベンチマークまで公開されている。

ちなみに、Coremark, Coremark-Proは無料だが、FPMarkやAutoBenchなどは有料だ。ただし、AndEBenchは無料のようなので、Androidのスマートフォンをお持ちの方は、試してみては如何だろうか？

www.eembc.org

Coremark

最後にEEMBCの中で最も有名なベンチマークプログラム、Coremarkについて紹介する。

www.eembc.org

その名の通り、CPUコアのベンチマーキングのために開発されたプログラムで、ベンチマークプログラムとしては1つのバイナリで提供されているが、実際には複数のプログラム(関数)によって構成されており、スタートポイントからストップポイントまでの性能を測定する。

ちなみに、殆ど多くの商用プロセッサでは、このCoremarkスコアが公開されており、CPUの性能を測定するための基準となっている。

このCoremarkを参照する場合、大きく分けて2つの基準がある。

• 周波数まで考慮した実時間性能を測定したもの "Coremarkスコア"
• 1サイクルあたりの命令実行性能を測定したもの "Coremark/MHzスコア"

つまりいくらパイプラインの効率が悪くても、動作周波数が高ければCoremarkスコアは伸びやすくなるし、一方で周波数を考慮しない、Coremark/MHzのスコアは悪くなる。

また、組み込み向けのCPUではあまり周波数が高くなくても、命令実行効率が良ければ良い場合もある。この場合、Coremark/MHzの指標の方が大事になる。

4. RISC-Vの各種ハードウェア実装では、Coremarkスコアはどのくらいだ？

既に前の日記でまとめている。

msyksphinz.hatenablog.com

	Rocket Chip	BOOM 2-wide	BOOM 4-wide	Z-scale
CoreMark[CMK/MHz]	2.32	3.91	4.7	-

ここでは、動作周波数を考えない、CMK/MHzで表示されている。Rocket Chipが一番CMK/MHz値は小さいが、BOOMの4-way版になると4.7程度のスコアとなる。4.7っていうと一般的なプロセッサで言うとどのあたりだろう？ 先程のCoremarkのスコア一覧で確かめてみよう。

一昔前のデスクトップPCのCPUコアの名前が並んでいる。また、マイコンで言うならば、ルネサス社のRXマイコンが同程度の効率を持っている。BOOMの最高性能のものと、RXマイコンが同程度の性能効率ということは、RXマイコンはかなり効率的であると考えることが出来るのだろうか？

こんな感じで、CPUコアの性能比較をするのも、なかなか楽しいので、自作CPUを作られる方は、是非自分のCPUのCoremarkスコアを公表して欲しい。

5. 終わりに

CPUコアを設計、評価するにあたり、一般的なベンチマークプログラムについて取り上げてみた。

また、これはあくまで筆者の個人的な経験とか、インターネット上での検索結果とか、さまざまな書籍を調査した結果ではあるが、誤りが含まれている可能性もあるので、「間違っている」とか「もっといろいろあるぞ！」という方のツッコミも大歓迎です。

RISC-V 5th Workshopの発表紹介 (Fast Instruction Set Simulator)

この記事は ハードウェア開発、CPUアーキテクチャ Advent Calendar 2016 - Qiita の7日目の記事です。

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

A FastInstruction Set Simulator for RISC-V (Esperanto)

https://riscv.org/wp-content/uploads/2016/11/Wed1330-Fast-ISA-Simulator-for-RISC-V-Maslov-Esperanto.pdf

Esperantoというスタートアップ企業で開発されている高速RISC-V命令セットシミュレータの紹介。

RISC-Vの命令セットシミュレータといえば、riscv-spikeが存在する。これは UC-Berkeleyで開発された本家のISSだ。また、RISC-V向けのQEMUも存在する。

github.com

github.com

これらのシミュレータは、例えばSPECINTを実行させた場合に、シミュレーションだけだと非常に遅いという欠点がある。例えば、実CPUでx64で動作させると一瞬なのだが、ISSで動作させると非常に時間がかかったり、そもそもQEMUで実行するとFailになったりする。

これを解決するために、EsperantoのFast Instruction Set Simulatorでは以下の部分に着目した。

• User Modeの実行のみに着目する
• RISC-Vの命令をx86の命令に変換する、また、システムコールの場合はx86のシステムコールに変換する。

シミュレーション時の、RISC-V命令の変換フローは以下のようになっている。

上記は https://riscv.org/wp-content/uploads/2016/11/Wed1330-Fast-ISA-Simulator-for-RISC-V-Maslov-Esperanto.pdf より抜粋。

これを見ると、もちろん命令の変換というのも実行されるのだが、一度変換した命令は、キャッシュに保存しておくことで冗長に変換処理を繰替えすことを防いでいる。

結果として、EsperantoのISSは、Nativeのx86でのベンチマーク実行と比較して、1/2.47倍の速度で実行できるようになった。 これは結構凄い結果だと思う。単純なISSでは決してここまで速くなることはないと思うのだが、Native命令に変換し、キャッシュを挿入することでNativeハードウェアと遜色無い性能にまで引き上げている。

ただし、手法自体はそこまで新しいものでは無いと思う。ターゲットの命令を、ホストPCの命令に変換し、これをキャッシュに格納して高速化することは、エミュレーションの本の最初の方にも説明があった気がする。 確か、以下の本だ。

• Virtual Machines: Versatile Platforms for Systems and Processes

Virtual Machines: Versatile Platforms for Systems and Processes (The Morgan Kaufmann Series in Computer Architecture and Design)

RISC-V 5th Workshopの発表紹介 (Time Traveling Coherence Algorithm)

この記事は ハードウェア開発、CPUアーキテクチャ Advent Calendar 2016 - Qiita の6日目の記事です。

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

Memory Model in RISC-V

ちょうど先月の終わり頃、5th RISC-V WorkshopがGoogle @ Mountain Viewで開催され、大盛況で終了したという記事が上がっていた。

そこで、本Advent Calendarのエントリでは、RISC-V Workshopのアップロードされた資料の中で、面白そうなものをピックアップしようと考えていたのだが、以外と資料のアップロードが遅い。。。 現時点で数本しか発表資料がアップロードされておらず、過去のWorkshopでYoutubeへ投稿されていた発表動画も未だに投稿されていない。

せっかくネタにしようとしていた情報源がこれでは少なすぎるのだが、これと言って他に情報源も無いので、とりあえず現状でアップロードされているものから、いろいろ調べてまとめてみる。

ちなみに当日の様子は、eetimesにて記事になっている。私は参加したかって？日本に住んでいるし、仕事もあるので不参加でした。

www.eetimes.com

発表資料の紹介

いくつかカテゴリがあるのだが、現時点でアップロードされている資料の中では、メモリモデルに関する発表が多いように感じている。

メモリモデル、特にマルチコア、メニーコアになった場合のコンシステンシの取り方の問題について、多くのアプローチが提案されている。 また、IoTのが普及し、非常に多くのデバイスが存在するようになると、それだけでメモリそのものの考え方や、セキュリティ、アドレッシングをどのようにすれば良いかということに繋がってくる。

Towards Thousand-Core RISC-V Shared Memory Systems

https://riscv.org/wp-content/uploads/2016/11/Wed1000-Thousand-core-RISC-V-Nguyen-MIT.pdf

"Tardis"という新しいコヒーレントプロトコルの紹介。これまでのコヒーレントプロトコルと違い、「タイムスタンプ」を導入し、データを「リース」することによりデータのコヒーレントを保とうとする方式。

ちなみに、このTardisについて検索すると以下の論文が見つかる。あとでしっかり読む必要があるかもしれない。

• Tardis: Time Traveling Coherence Algorithm for Distributed Shared Memory

https://people.csail.mit.edu/devadas/pubs/tardis.pdf

各コアには、データに対する現在の状態(MESIモデル)を保持しているのだが、それに加えて、集中管理(？)するためのManagerを用意する。こちらでは、データをリースしたタイムスタンプを保持している。これにはwts,rtsという値を利用し、wtsはリースの開始時間、rtsはリースの終了時間を記録する、としている。また、各プロセッサはptsというレジスタにタイムスタンプを保持している。

まず、コアが2つある状態で、Core-0がアドレスAに対してストアを実行すると、

• ManagerがアドレスAの所有者をCore-0に設定することでリース開始。
• Core-0はアドレスAを所持し、タイムスタンプを複写
• Core-0はアドレスAに書き込みを実施し、タイムスタンプwts=1, rts=1と設定する。またpts=1に更新する。

次に、Core-0がアドレスBをロードすると、

• Core-0はptsをManagerに送り、ManagerはアドレスBのタイムスタンプを設定する。wts=1,rts=1
• 現在のptsをベースに、タイムスタンプを設定する。wts=1, rts=11 とする。(注: ここでrts=11とするのは何故なのか良く分からない。長い時間保持しておく、ということだろうか？11にあまり意味はない？)

次に、Core-1がBをストアする。ここでは、まだCore-0との競合は発生しないが、タイムスタンプの更新が行われる。

• Managerは、現在のアドレスBのリース終了時間を+1する。これにより、アドレスBはShared状態からModified状態になり、wts=12,rts=12からは、Core-1が所有し、Modified状態になる、ということになる。

この状態で、Core-0とCore-1で異なる値がアドレスBに対して共存しているという状態が発生する。(Core-1がアドレスBに書き込みを行ったとしても、直ぐ様全体にInvalidateを出さないということか)

次にCore-1がアドレスAをロードしようとすると、

• ManagerはCore-0に対してアドレスAのライトバックを要求する。これは、ManagerのアドレスAの状態がModifiedで、所有者がCore-0であることから判明する。
• Core-1がアドレスAのロードを行い、タイムスタンプを設定する。wts=11, rts=22に設定する(つまりリース期間はこの場合は10ということか)

最後にCore-0がアドレスBのロードを行うと、Invalidateを行わないため、シンプルにCacheにヒットしてしまい、ここで最新のデータが取得できないという状態になっている(？)

これ、それを許容するというプロトコルなのかなあ？けど、リース期間は過ぎている訳だから、単純にもう一度取りに行けば良いのじゃないの？

そもそもこのプロトコルの目的は

という訳で、いまいちOrderの守られないプロトコルではあるが、どうやら本来のこのプロトコルの目的は、命令オーダー通りにデータをやりとりすることではなく、通信負荷を削減することらしい。

IoTのように大量のデータを結びつけることになると、そこまで厳密にプロトコルを守る必要は無い、という考えに基いているのかもしれない。

という訳で、少し難しいが RISC-V Workshopで発表されたコヒーレントプロトコルについての紹介をした。まあぶっちゃけRISC-Vには関係無いが、IoTの時代、このようなプロトコルをサポートする必要も生じてくるのかもね。

明日はもう一本、Fast Instruction Simulatorについて紹介しようかと思う。どちらかというと、こっちの方が内容としては簡単め。

個人が趣味で技術書を翻訳するという意義について

この記事は 技術翻訳 Advent Calendar 2016 - Qiita の4日目の記事です。

突然の参加ですが、趣味で技術翻訳を長年続けてきた立場から、思うことやこれから技術翻訳を行う人にアドバイスが出来たらなと思う。

1. これまで翻訳してきた技術書

突然だけど、私はこれまで趣味で結構な技術書を翻訳してきた。大学生の頃に趣味で始め、就職してからも毎日の朝と夜に時間を見付けて翻訳をしていた。これまでに翻訳した技術書をざっと振り替えってみようと思う。

2011年-2012年

• Computer Arithmetic: Algorithms and Hardware Designs (翻訳成果未公開)

Computer Arithmetic: Algorithms and Hardware Designs (The Oxford Series in Electrical and Computer Engineering)

始めて翻訳に挑戦した本。実に600ページ程度ある。とりあえず全体を翻訳するのに、おおよそ1年かかった。

2013年-2014年

• Principles and Practices of Interconnection Networks (翻訳成果未公開)

Principles and Practices of Interconnection Networks (The Morgan Kaufmann Series in Computer Architecture and Design)

• Handbook of Floating Point Arithmetic (翻訳成果未公開)

Handbook of Floating-Point Arithmetic

上記の2冊は途中まで翻訳したのだが、途中で面白くなくなって止めてしまった。

2014年-2015年

• Superscalar Microprocessor Design (翻訳成果未公開)

Superscalar Microprocessors Design (Prentice Hall Series in Innovative Technology)

既に日本語版が出ていのだが、入手困難になっていた。そこで自分で翻訳することにした。

2016年

• xv6. a simple, Unix-like teaching operating system (翻訳成果公開済)

https://pdos.csail.mit.edu/6.828/2012/xv6/book-rev7.pdf

有名なMITのオペレーティングシステムに関する教科書。オペレーティングシステムについての理解を深めるために翻訳した。翻訳成果公開済。ただしクオリティはヒドい。

GitHub - msyksphinz/xv6_translate: translation of XV6

• Understanding the detailed Architecture of AMD's 64 bit Core (翻訳成果公開済)

http://chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html

ハイパフォーマンス向けのCPUに関する技術書。現代のプロセッサの、高速化のための応用技術が紹介されている。翻訳成果公開済。ただしクオリティはヒドい。

2. 何故そんなにたくさん技術書の翻訳に取り組んだの？殆ど公開してないし、何のために翻訳したの？

本来そうあってはいけないのだけど、英語の翻訳というのは、ともすれば単純作業のように、英語を読んでそれを日本語に変える作業と考えることができる。

そうすると、翻訳作業というのはかなりの単純作業で、前後の文脈を考えずに実行することだって可能なのだ。普段エンジニアをしている私にとって、あまり頭脳労働でない翻訳作業は、ちょっとした休憩のようなものになってしまっていた。(本来はそうあるべきでは無いんです！翻訳のプロの皆さん、ゴメンなさい！！)

昔からの性格か、朝晩の単純作業というのは比較的得意で、いつの間にか長年続けることが出来るようになってしまっていた。これは良い点もあれば悪い点もあり、結果としていくつかの技術書については翻訳を完了できたし、 成果を公開することが出来た。ただし、プロでは無いし、プロ意識も無いまま翻訳してしまったので、クオリティはヒドいものになっているという弱点がある。

3. 長い量の翻訳を継続するために自分が工夫したこと

ここからは、600ページにも及ぶ技術書をひたすら翻訳するために自分が工夫した点を挙げてみる。継続するための工夫はもちろん行っており、いろんな方法を取った。

進捗管理をする。サブ目標を立てる

僕は翻訳の進捗管理を、プロジェクト管理ツールを使って実施していた。僕の場合はRedmineを使い、各章、各節毎にチケットを作成し、締切を決めて実施していた。

細かなマイルストーンを決めて、進捗管理することは、途中でダれてしまいがちな一人プロジェクトではとても重要なことだと思う。そこはいつも気を付けるようにしている。

なるべく成果を公開することを心掛けて(なので技術書ではなくOSSの資料を翻訳すべき)

人は成果が公開出来たほうがうれしいものです。なので、私のように全部翻訳が完了しても公開出来ない技術書を翻訳するよりも、成果が公開できるオープンソースの資料を狙って翻訳すべきですね！

自分の興味のあるものなら何でも！とにかく、自分の興味のある分野や、ある程度知識のある分野が重要。いきなり張り切って全くの門外漢の洋書を読んでも、途中で諦めてしまうのは目に見えている。

翻訳クオリティを上げるために、前後の文脈を考えて。作業になってしまわないように

翻訳クオリティを上げるために、というか、逆に何故個人が趣味で翻訳をするとクオリティが下がってしまうのだろう？ということを考えたときに、やはり前後の文脈を考えず、一文一文を独立に翻訳してしまいがちな傾向があるのでは無いだろうか？(少なくとも僕はそう)。

これを防ぐためには、

1. 一文単位で翻訳はしない。
2. 少なくとも段落は全部読んでから、翻訳する
3. (めっちゃ時間に余裕があれば)まず全体を読んでから翻訳、そうでなければ一章か一節読んでから翻訳が望ましい。そのためには、英文で2文になっているものを日本語で1文にしてしまっても構わない。

段落の内容をキチんと把握するために

では、段落の内容をキチんと把握し、綺麗な日本語に変換するためにはどうしたら良いのだろう？ 僕のおすすめの方法は、技術書の洋書に多い、端の余白に、まとめを記入していく事だ。

手書きで良いので、きちんと日本語に起こすこと。そして、はやまって急に翻訳文章にしてしまわないこと、これが大切だと思う。

4. 終わりに

• 翻訳は、一度起動にのれば、楽しい趣味にできる。
• 継続するためには、細かく進捗管理する。そして自分を律すること(ある程度ね)。
• 一文一文の直訳は禁物！せめて段落は読んで、分かりやすい日本語を心掛ける。

以上、エンジョイ翻訳ライフ！

さて、来年は何を翻訳しようかなー。

RISC-Vの特権命令まとめ

この記事は ハードウェア開発、CPUアーキテクチャ Advent Calendar 2016 - Qiita の5日目の記事です。

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

1. RISC-Vにはどのような特権命令があるのか

最初に、「特権命令」とは何かについて簡単にまとめておこう。

例えば、演算やメモリアクセスに使うような通常の命令と違って、CPUのステータスを変更したり、オペレーティングシステムを動作させるための命令などが含まれる。このような命令のことを特権命令と呼ぶ。 また、特権命令が操作する、CPUの各種情報を格納するためのシステムレジスタの仕様も含まれることが多い。これらをまとめて、「Privileged Architecture」などと言ったりするけど、日本語では何と言うのか良く分からない。

RISC-Vの特権命令の情報はどこにあるの

以下をサイトを参考にする。今ダウンロードすると、いつの間にか仕様書が1.9.1にアップデートされていることに気がついた。前まで1.9だったのに！

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

Changelogを見ていると、デバッグ命令あたりの情報も加わっているのか、、見逃していた。

2. RISC-Vのプロセッサ実行モード

RISC-Vには、仕様として以下の実行モードが存在する。上はユーザモードから、下はマシンモードまで。基本的にはユーザモードでは殆どのシステムレジスタにアクセス出来ないが、マシンモードでは全てのシステムレジスタへのアクセスが許される。

ちなみに、3. Hypervisor-Modeについては、仕様書にすらまだ詳細が書かれていない。まだ決まっていないらしい。。。そうすると、通常のRTL実装とか、チップとして上がってくるRISC-Vのプロセッサは、「Machine-Mode」「Supervisor-Mode」「User-Mode」から構成されるという訳だ。

なるほどなあ。

3. RISC-Vのシステムレジスタ(CSRレジスタ)と制御命令

システムレジスタを1つずつ解説していくのは無理なので、おおよそ重要なところをピックアップしていこう。

mstatus, hstatus, sstatus, ustatusレジスタ

レジスタ群の中でおそらく最も重要なのは、*statusレジスタとよばれる、現在のシステムの状態を格納しているレジスタだ。接頭語の「m,h,s,u」はそれぞれどの実行モード中に利用するかを指定する。

ここでは、mstatusレジスタのビットフィールドを見てみる。

0ビット目から3ビット目までは、Interrupt Enableビットで、各実行モードにおける例外許可を示すビットだ。使い方としては、基本的に現在の実行モードxの時には、xIE=1として利用する。下位の実行モードのIEビットはもちろんDisableだし、上位の実行モードのIEビットは1にすることができる。

次の4ビット目から7ビット目は、割り込みのネストを許可するために、一つ前の割り込み許可ビットを保持している。具体的には、Trapが発生する目のInterrupt Enableビットの状態を保持している。

また、VMビットはアドレス変換のモードを示すビットだ。RISC-Vにはいくつかのアドレス変換モードがある。詳細は、私の過去のブログも参考にして欲しい。

msyksphinz.hatenablog.com

msyksphinz.hatenablog.com

その他にも、メモリプロテクションのためのMPRVビット、FSビットは浮動小数点レジスタの状態を示し、XSビットはユーザモードの拡張のためのビットだ。

4. システムレジスタのアクセスに必要な特権命令

では、上記のシステムレジスタにどのようにしてアクセスするのだろうか？RISC-Vのシステムレジスタには、下記の表のように、一意のアドレスが付加されている。CSR Addressと書かれている12ビットの部分だ。このアドレスを利用してシステムレジスタにアクセスすることになる。

RISC-Vアーキテクチャではシステムレジスタは各実行モードによりまとめられており、もちろん各モードでアクセスできるシステムレジスタは異なっている。実際にアクセスするのは、"CSRxx"命令と呼ばれる命令だ。 概念としては、MIPSのmtc0命令や、mfc0命令に似ている。汎用レジスタとシステムレジスタの移動を行う命令なのだが、CSR命令はこのデータを「移動」ではなく「交換」するところがMIPS系の命令と異なる。

RISC-Vでは、以下のシツテムレジスタにアクセスする命令が用意されている。

• CSRRW命令 CSRRW rd,csr,rs1 で記述されるこの命令は、csrで表現される12ビットアドレスで示されるCSRレジスタと、汎用レジスタの交換を示す。本命令が実行されると、CSRレジスタの値がrdレジスタにロードされ、rs1の値がCSRレジスタに書き込まれる。この操作がアトミックに行われるというのが本命令の利点で、もしrd=x0(ゼロレジスタ)ならば、rdレジスタへのCSRの値読み込みは行われず、rs1の値がCSRレジスタに書き込まれるだけである。

• CSRRWI命令 CSRRWI rd,csr,imm は、rs1の変わりに5ビットの即値が指定できる命令だ。CSRRW命令ではrs1の値がCSRに書き込まれるが、本命令はimmの値がCSRに書き込まれる。下位5ビットしか効果が無いのでいまいち付きどころが分からないが、まあそういう命令だそうな。

• CSRRS命令、CSRRSI命令 CSRRS rd,csr,rs1, CSRRSI rd,csr,immで表現されるこの命令は、CSRの元の値がrdに読み込まれ、CSRレジスタのrs1レジスタの各ビットで1が立っている部分が強制的に1に設定される。rs1レジスタの各ビットで0であるビットに相当するCSRレジスタビットは影響を受けない。CSRRSIについても、rs1の値が即値になっているだけで同様である。

• CSRRC命令、CSRRCI命令 CSRRC rd,csr,rs1, CSRRCI rd,csr,immで表現されるこの命令は、CSRの元の値がrdに読み込まれ、CSRレジスタのRs1レジスタの各ビットで1が立っている部分が強制的にクリアされる。rs1レジスタの各ビットで0であるビットに相当するCSRレジスタビットは影響を受けない。CSRRCIについても、rs1の値が即値になっているだけで同様である。

余談。CSRRW命令はアウトオブオーダのプロセッサにおいてどうやって実装するのか？

各CSRアドレスが付加されているとは言え、12Bビット存在する。これをリネームマップを利用して変換するのは現実的に不可能だ。だとすると、CSRへの書き込みについて、リネームマップで変換してアウトオブオーダで処理するという機構は無いだろう。

とすると、CSR命令の場合のみアウトオブオーダ発行を止め、インオーダで一つずつ実行するという方式が現実的ではなかろうかと思う。例えば、同一CSRレジスタに連続して書き込む命令であれば、

CSRRW x1,mstatus,x3   // x1<--mstatus, mstatus<--x3
CSRRW x4,mstatus,x5   // x4<--mstatus, mstatus<--x5

mstatusにはレジスタ書き込みが発生するが、汎用レジスタであるならばリネーミングにより、1命令目と2命令目で別々の物理レジスタがマッピングされる。しかしCSRレジスタはリネーミングが出来ないので、この部分だけインオーダだ実装する必要があるだろう。 つまり、1命令目のmstatusの書き込みが完了するまで、2命令目のmstatusの更新命令はストールさせるという方法になる。

Rocketとか、BOOMとかはどのようにして実装しているんだろうな？

5. トラップリターン命令

v.1.7までの仕様

v.1.7までのPrivileged Instructions では、以下の命令が定義されていた。

mrts命令は、現在の実行モードから前の実行モードに遷移する命令だ。

• MRTS : マシンモードからスーパバイザモードへの帰還命令
• MRTH : マシンモードからハイパーバイザモードへの帰還命令

v.1.9からの仕様

MRET 命令は常に提供される、それ以外の命令はそのプロセッサがどのアーキテクチャまでをサポートしているかに依存する。

6. まとめ

これらのシステム特権命令は、上記にも伸べたように仕様のアップデートの度に命令が増えたり消えたりする。細かいチェックが必要だが、大体の命令は一般的な命令と同様なので、知っている人がすぐに理解出来ると思う。

ただし、まだ仕様として固まっていないので、例えばLinuxなどのシステムを動かすときは、RTLの実装とコンパイラがどのバージョンに対応しているかの確認をしっかりしておく必要がある。

RISC-Vアーキテクチャの実装についてまとめ

この記事は ハードウェア開発、CPUアーキテクチャ Advent Calendar 2016 - Qiita の2日目の記事です。

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

1. RISC-Vの実装について (Berkeley編)

UC Berkeleyが実装した、RISC-Vの実装は以下のようなものが挙げられる。

	Rocket Chip	BOOM 2-wide	BOOM 4-wide	Z-scale
	UCB	UCB	UCB	UCB
ISA	64-bit RISC-V v2	64-bit RISC-V	64-bit RISC-V	32-bit RISC-V RV32IM
Pipeline	Single-Issue In-Order 5-stage	2-wide, 3-Issue Out-of-Order 6-stage	4-wide, 4-issue Out-of-Order 6-stage	Single-Issue In-order 3-stage
L1 cache	Configurable	Configurable	Configurable	-
L2 cache	Configurable	Configurable	Configurable	-
Performance[DMIPS/MHz]	1.72	-	-	1.35
IPC	0.76	1.25	1.5	-
Max Frequency[MHz]	1500	1500	1500	500
CoreMark[CMK/MHz]	2.32	3.91	4.7	-
Area [mm2]	0.39 (with 16k cache)	1.1 (with 32k cache)	1.4 (with 32k cache)	0.0098
Area Efficiency[DMIPS/MHz/mm2]	4.41	-	-	138

Rocket Core

最も一般的なRISC-V実装。シングル命令発行で5パイプラインステージを持つ。またコアの実装自体はChiselというハードウェア記述言語で実装されている。

github.com

XilinxのFPGA向けに、Zybo, Zedboard, ZC706 向けの実装パッケージが提供されている。

github.com

BOOM

性能を重視したコア。2-wide版と4-wide版が存在する。またコアの実装自体はChiselというハードウェア記述言語で実装されている。

github.com

• The Berkeley Out-of-Order Machine (BOOM): An IndustryCompetitive, Synthesizable, Parameterized RISC-V Processor

http://digitalassets.lib.berkeley.edu/techreports/ucb/text/EECS-2015-167.pdf

• The Berkeley Out-of-Order Machine (BOOM!): An Open-source Industry-CompeEEve, Synthesizable, Parameterized RISC-V Processor

https://riscv.org/wp-content/uploads/2016/01/Wed1345-RISCV-Workshop-3-BOOM.pdf

Z-scale

32-bitのコア。パイプライン段数は短かく、最も面積性能を重視したコア。

github.com

github.com

• Z-scale: Tiny 32-bit RISC-V Systems With Updates to the Rocket Chip Generator

https://riscv.org/wp-content/uploads/2015/06/riscv-zscale-workshop-june2015.pdf

2. RISC-V実装 (UC Berkeley以外)

UC Berkeley以外の実装には、調査したところ以下のような実装が存在した。

本当はWorkshopの発表内容とか全部チェックしていくともっと沢山あるんだろうけど。。。そこまで気力が無かった（笑）

SHAKTI Processor (一部実装公開済)

Indian Institute of Technologyが開発しているプロセッサ。特徴としては「とにかく目標が壮大なこと」。

2016/12/02 追記。@ogawa_tter 様より指摘あり。

SHAKTIの特徴の一つに Interconnectとして RapidIO実装があります (ざっと見たところ 2014年頃から進んでないようですが)。さらに S classは HMC対応です。

申し訳ありません。あまりにも説明が雑過ぎましたね。。。

• SHAKTI Processor Project http://rise.cse.iitm.ac.in/shakti.html

シリーズとしては以下が計画されている。

• SHAKTI Processor C-Class : マイクロコントローラクラス
• SHAKTI Processor I-Class
• SHAKTI Processor M-Class
• SHAKTI Processor S-Class
• SHAKTI Processor H-Class : 3-5 + Tflopsクラス
• SHAKTI Processor T-Class : Experimental security oriented 64-bit variants with tagged ISA, single address space support, decoupling of protection from memory management.

ちなみに、実装は以下から確認できるようだ。

bitbucket.org

さっそく、cloneしてみた。結構サイズがある。C-Class, I-Class, E-Classの実装がある。E-Classは、Cクラスよりもより小さなコアとのこと。 I-Classはアウトオブオーダまで組んであるらしいので、高性能が好きな人は良いんじゃないかな。

PicoRV32 (実装公開済)

実装としてはかなり小さい方。RV32IMをサポートとしている。CPI=4.081と、パイプライン組んでいないんじゃないの？クラス。ただし取っ掛かりとしてはかなりお手頃かもしれない。

github.com

RIDECORE (実装公開済)

東京工業大学 吉瀬研究室が開発したプロセッサ。MIPSの実装とか昔は作っていたようだが、最近はRISC-Vに切り替えたのかな。

• Verilog HDLで記述するRISC-V命令セットの教育用アウトオブオーダ実行プロセッサ

github.com

検索してみると論文も出てくる。ただしDhrystone値もCoremark値も計測していないようなので、性能としては未知数。あんまり特定のアプリケーションでは、比較する気にならない。

http://www.arch.cs.titech.ac.jp/a/thesis/Bthesis-2016-02-fujinami.pdf

RI5CY (実装公開済)

2016/12/12追記。 @muo_jp 様より指摘頂きました。

github.com

PULPinoというプラットフォームは、オープンソースなRISC-V SoCプラットフォームのようだ。4ステージのシンプルなパイプラインに、様々な独自命令を拡張している。例えば、

• ハードウェアループ
• ポストインクリメント、デクリメントメモリアクセス命令
• MAC命令

など。ちなみに、この辺りのコンパイラ生成も独自に拡張を加えているようだ。やるなあ。

The ETH version supports all the ISA extensions that were incorporated into the RI5CY core.

Pulsar (実装非公開)

CeaTechという企業？が開発したプロセッサ。結構早い段階からRISC-V Workshopにて実装を発表している。ただし、こちらも性能面での言及があまり無く、概念の話が多い。

まあどちらかというと、FD-SOIプロセスを利用するということに焦点が当てられている気がするね。

• Heterogeneous Multicore Based on RISC-V Processors and FD-SOI Silicon Platform

https://riscv.org/wp-content/uploads/2016/07/Tue1000_Heterogeneous_multicore_based_on_RISC-V_processors_and_FD-SOI_silicon_platform.pdf

Hwacha Project

id:Worldforward 様より指摘頂きました。追記します。

RISC-VのRocket Chipを拡張して、ベクトル演算のアクセラレータを搭載したもの。ベースはUC BerkeleyのRocketだが、それを拡張する形でベクトル命令をオフロードできるようになっている。

そして、兎に角資料が詳細で凄い。これをきちんと読み進めるのは、相当な時間がかかりそうだ。

• The Hwacha Vector-Fetch Architecture Manual, Version 3.8.1 https://www2.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-262.pdf
• The Hwacha Microarchitecture Manual, Version 3.8.1 https://www2.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-263.pdf

3. 実機

ちょうど近ごろ、RISC-Vのチップのリリースがありましたね。

www.sifive.com

これによると動作周波数は320MHz、1.61 DMIPs/MHz, 2.73 Coremark/MHz、Arduinoのプラットフォームを採用している。

ソースコードはこちらで公開されている。

github.com

入手してみる価値は、あるかも？