FPGA開発日記

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

AWS EC2 F1インスタンスを使ったハードウェア開発の勉強 (11. 割り込み信号によるFPGAからホストへの通知機能)

AWS_F1

AWS F1インスタンス HDK の勉強を続けている。 目標としては、以下の部分にAXIマスタを接続してDRAMにアクセスし、データをフェッチする。

  1. DMAでホストからデータをDDR4メモリに格納する。
  2. AXIマスタデータをフェッチする
  3. 演算し、結果を格納する。

として、例えば行列積のアクセラレータをF1インスタンス上で動作させてみたい。ここまでは上手くできたのだが、計算の完了をホストに通知する方法があまりよくない。

Configurationバスにアクセスして、計算完了フラグが立っていた場合に次の計算のためのデータを流し込む。 これでは時間がかかるので、割り込みのような機能を使用したい。

github.com

  • 今の方式では 1us に一度状態を読み込みに行く機構のため、あまり良くない。
  while (matrix_finished == 0) begin
    tb.peek(.addr(`HELLO_WORLD_REG_ADDR), .data(matrix_finished), .size(DataSize::UINT16), .intf(AxiPort::PORT_OCL));         // start read & write
    $display ("Reading 0x%x from address 0x%x", matrix_finished, `HELLO_WORLD_REG_ADDR);
    #1us;
  end

HDKの資料を見ていると、割り込み通知のための信号が用意されている。

github.com

f:id:msyksphinz:20180531000721p:plain

Interrupts

16 user interrupt source are supported. There is mapping logic that maps the user interrupts to MSI-X vectors. Mapping registers in the DMA controller map the 16 user interrupt sources to MSI-X vectors.

There are two sets of signals to generate interrupts:

  • cl_sh_apppf_irq_req[15:0] (from CL to SH)
  • sh_cl_apppf_irq_ack[15:0] (from SH to CL)

This interface uses single clock pulses for the req/ack. The CL asserts (active high) cl_sh_apppf_irq_req[x] for a single clock to assert the interrupt request to the SH. The SH will respond with a single clock pulse on sh_cl_apppf_irq_ack[x] to acknowledge the interrupt. Once the CL asserts a request on a particular bit[x], it should not assert a request for the same bit[x] until it has recieved the ack for bit[x] from the SH. The CL may assert requests on other bits[y] (y!=x).

というわけで、計算が完了すると、cl_sh_apppf_irq_req信号を使って割り込みをホストに対して通知してみる。

github.com

  • hdk/cl/examples/cl_dram_matrix/design/cl_int_matrix_calc.sv:embed:cite
...

logic [15: 0]           w_int_input;
assign w_int_input = {15'h000, matrix_calc_done};
...
lib_pipe #(.WIDTH(32), .STAGES(4)) PIPE_IN (.clk (clk),
                                            .rst_n (rst_n),
                                            .in_bus({int_trig, sh_cl_irq_ack}),
                                            .out_bus({cl_sh_irq_req, int_ack})
                                            );

計算が完了すると、matrix_calc_doneをアサートし、割り込みポートから通知する。

これにより、ホストのテストベンチに割り込みが通知されることが確認できる。

            50734000 : [cl_axi_mstr_bus  R] DATA=000001530000015200000151000001500000014f0000014e0000014d0000014c0000014b0000014a000001490000014800000147000001460000014500000144
            50738000 : [cl_axi_mstr_bus  R] DATA=000001630000016200000161000001600000015f0000015e0000015d0000015c0000015b0000015a000001590000015800000157000001560000015500000154
            50750000 : [matrix] result FIFO read     00000000000328b8
            50754000 : [cl_axi_mstr_bus AW] LEN=  0 SIZE=3 ADDR=0000000400020038
            50754000 : [cl_axi_mstr_bus  W] STB=0000000000000000 DATA=000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000328b8
Received interrupt  0
[            50772000] : Sending ack for interrupt  0
            51206000 : [axi_mstr_cfg_bus R] ADDR=00000500
            51210000 : [axi_mstr_cfg_bus R] ADDR=00000500
Reading 0x00000001 from address 0x00000500

おそらくこれは、sdk/userspace/utils/sh_dpi_tasks.c に通知が行われている。sv_int_ack() の部分に、さらに追加したい処理を記述する、ということかな。

void int_handler(uint32_t int_num)
{
// Vivado does not support svGetScopeFromName
#ifdef SV_TEST
  #ifndef VIVADO_SIM
    svScope scope;
    scope = svGetScopeFromName("tb");
    svSetScope(scope);
  #endif
#endif

  cosim_printf("Sample Received interrupt %2d", int_num);

#ifdef SV_TEST
  sv_int_ack(int_num);
#endif

}

Amazon EC2 F1インスタンスで動作するRISC-Vシミュレーション環境FireSimの論文を読む

RISC-V

ISCA 2018で発表される予定の論文、"FireSim: FPGA Accelerated Cycle Exact Scale-Out System Simulation in the Public Cloud" をざっと流し読みした。

EC2 F1インスタンスを勉強している身としては、把握しておきたい内容ということで、分かったことをまとめていくことにした。 まだ途中だし、2～3時間で読んだので全然理解としては足りないのだが、概要をまとめていく。

ちなみに、最後まで読んでわかったのだが、Rocket Chip @ 3.2GHz というのは「仮想の」動作周波数で、ネットワークの帯域がいくらであると仮定して、それに合わせてシミュレーションのタイミングも間引くことで「正確なサイクル」での、シミュレーションを可能としている、ということらしい。 最初読んだときに、「FPGAって3.2GHzで動くの！？」と思ってびっくりしてしまった。

ベンチマークを取るために、1024コアのRISC-V Rocket-Chipを32個のf1.16xlarge を動かしている。 これで1時間のシミュレーションで$400程度だったというのだから、研究室で自前でFPGAを持つよりもコスト的にはお得だなあ...という感じ。

ちなみにオリジナルの論文はこちら。図もすべてこちらから参照している。

  • FireSim: FPGA-Accelerated Cycle-Exact Scale-Out System Simulation in the Public Cloud

https://sagark.org/assets/pubs/firesim-isca2018.pdf

FireSim: クラウド上で構築するサイクルベースでスケールアウト可能な、FPGAでのシステムシミュレーション

概要

FireSimはサイクルベースなRTLシミュレーション環境である。 これまでのように単体のFPGAを使うわけではなく、Amazon EC2 F1インスタンスを使用するところが新規部分である。 1024個の3.2 GHz 4コアサーバと、16GBのメモリ、さらに200Gbit/sのインターコネクトネットワークを使って3.4MHzのシミュレーションを行っていたが、Amazon EC2 F1インスタンスを使うことにより、4096コアと16TBのメモリのシステムをシミュレーションし、1秒当たり140億命令を実行する環境を構築した。

イントロダクション

Warehouse Scale Computingにおいて、個々のサーバを密に結合させる方向にトレンドが進んでいる。

ソフトウェアシミュレータを使用した場合には、シミュレーション速度がボトルネックになる(5～100KIPS)。

そこで、FPGAベースのシミュレーションフレームワークであるFireSimを提案する。 ユーザはネットワークのトポロジと、ブレードサーバのタイプを選択する、FireSimは自動的に高性能シミュレーション環境をAmazon EC2 F1インスタンス上に構築する。 ユーザは、FPGA上にシミュレーション環境を構築するという煩雑な作業から解放されるという点が利点である。

  • 第2章 : 近年のハードウェアのトレンドを紹介する。高速かつコスト効率の高いシミュレーション環境の必要性を説明する。
  • 第3章 : FireSimのシミュレーション環境について説明する。
  • 第4章 : ソフトウェアを実行し、デザイン構成のシミュレーションを行う。
  • 第5章 : シミュレーションの性能とスケーリングの可能性について説明する。
  • 第6章 : 過去のWarehouseスケールのハードウェア・ソフトウェアの協調設計について説明する。
  • 第7章 : スケーリングアウトするシステムシミュレーションについて、過去の研究について説明する。
  • 第8章 : FireSim の性能と機能を向上させるための概要について説明する。

パブリッククラウド上のFPGA

FPGAの開発環境はとにかくひどい。ビルドに時間がかかり、並列化するにも、ライセンスの制限に引っかかる。大きなFPGAを導入しても、その管理コストは馬鹿にならず、研究用プロトタイプとして共有使用するのも非常に難しい。

しかし、最近はAmazonはじめとするクラウドサービスとして、FPGAを導入する企業が増えてきている。 Amazon, Microsoft, Huawei, Alibabaなどである。 FPGAを高性能計算リソースとして使用することを期待している。

FireSimはAmazon EC2 F1インスタンスを使用するプラットフォームである。 EC2のf1.2xlargeとf1.16xlarge を使用する。

各FPGAには、64GBのDRAMが接続されている。4-CH接続である。

FPGA Developr AMIというFPGA開発用のOSイメージを提供しており、FPGA合成用のツールとライセンスが提供されている。

さらに、F1インスタンスは m4.16xlarge インスタンスを備えており、これにより高性能ネットワーク(25Gbit/s) をサポートしている。 FireSimでは、このインスタンスを使用してルートスイッチモデルを実行している。

FireSim

FireSimのモデルは、複数のネットワークに接続されたサーバブレードモデルから構成されている。 これをFAME-1モデルと呼ぶ。 ターゲットのネットワークは、ホストサーバ上で動作するサイクルベースのC++スイッチモデルに接続されている。

図1と図2は、ターゲットのトポロジと、ターゲットとホストのマッピングの構成について説明している。 64ノードのシミュレーション環境は、8つのtop-of-rack(TOR)スイッチに接続されている。

f:id:msyksphinz:20180529021638p:plain
f:id:msyksphinz:20180529021649p:plain

サーバブレードのシミュレーション

ターゲットサーバのデザイン

FireSimの計算サーバは、Rocket Chip SoC Generator により構成されている。 このRocket ChipはChiselで記述されている。 Rocket ChipはVerilog RTLを生成することができる。これには、RISC-V Rocket CPU、L1, L2キャッシュ、カスタムアクセラレータ(表2)、そしてI/Oペリフェラルが含まれる。

表1. サーバブレードの構成
ブレードの構成 RTL or モデル
1から4 コアのRISC-V コア @ 3.2GHz RTL
RoCCアクセラレータ(表2) RTL
16KB L1I\$, 16KB L1D\$, 256KB L2$ RTL
16GB DDR3 FPGA Timing Model
200Gbit/s Ethernet NIC RTL
ディスク ソフトウェアモデル
表2. カスタムブレードのアクセラレータ(例. 本実験にて使用したもの)
アクセラレータ 目的
ページフォルトアクセラレータ メモリの高速アクセスパス
Hwacha[25] ベクトル計算
HLS-Generated カスタムデザインの早期スケールアウト

ターゲットサーバのネットワークインタフェースコントローラ

完全なサーバモデルを構築するために、我々は2つの新しいペリフェラルをRocket Chip SoCに挿入した。 一つ目はChiselで記述されたネットワークインタフェースコントローラ(NIC)であり、SoCのトップレベルのネットワークインタフェースである。 NICのデザインは図3に示されている。

f:id:msyksphinz:20180529021703p:plain

NICはネットワークスイッチからのEthernetパケットを送受信する。 近年の研究では、レイテンシを削減するためにCPUとNICを1つのチップ上に実装する試みがなされているが、私たちのNICも同様の手法を取っている。 NICはRocket Chipのネットワークに、TileLinkを通じて直接接続されている。 これにより、NICはサーバSoCの共有L2キャッシュを直接読み書きすることができる。

私たちの実装したNICは大きく3つの領域に分割されている。

  • コントローラ
  • 送信パス
  • 受信パス

この中で、送信パスと受信パスはCPUにメモリマップドI/Oで接続されている。 送信パスと受信パスは合計4つのキューを持っており、また割り込みにより受信したことを通知されることもできる。

送信パスは、まずReaderユニットがメモリからデータを読み込み、それをReservation Bufferに渡す。 送信パスはデータをネットワーク上に送信し、送信がすべて完了すると、完了バッファからその情報を受信する。 (※ ここから先はSend Pathの詳細な構成が語られているが省略)

受信パスは、まずはPacket Bufferがデータを受信するところから始める。 パケットは完全に受信できない場合(つまり十分な受信バッファの空き容量がない場合)、そのパケットは破棄される。 Writerは受信したデータをメモリに書き込み、すべてのデータを書き込んだらControllerに通知する。 Controllerは受信完了したことをCPUに通知し、ユーザレベルのLinuxドライバがその受信データを処理する。

Writerはすべてのデータを書き込むまでControllerに通知を送ることはないため、不完全なネットワークパケットをCPUに通知することはない。

ターゲットサーバのブロックデバイスコントローラ

Linuxのディストリビューションを実行するために、ブロックデバイスのコントローラを実装した。これはMemory Mapped I/O(MMIO)に接続される。 これにより、512-byte のセクタのデータ転送が可能となる。

RTLによるサイクル精度のサーバシミュレーション

MIDAS / Strober のシステムを利用して、Chiselで記述されたデザインを変換してRTLを生成しFPGAで動作させる。 FPGAでは、各インタフェースでは外部からそのサイクルのトークンが入力される。 もしトークンが入力されなければシミュレーションはトークンが到着するまで停止し、これによりサイクル精度のシミュレーションを実現している。

スケーラビリティと使用率の向上

複数のサーバブレードのモデルを1つのFPGAに挿入することで、FPGAの使用率を向上させる。 これにより、最大で1024コアを動作させるクラスタが構成できる。

B. ネットワークシミュレーション

1. ターゲットスイッチのモデリング

ネットワークスイッチはソフトウェアにてシミュレーションを行う。

2. ハイパフォーマンス・トークン転送

トークンの転送はソフトウェアで行われるが、サイクル数をを正確にシミュレーションするために、パケットを通過させるレイテンシを計算してソフトウェアでシミュレーションを行う。 トークンが通過するサイクル数を算出すると、それに合わせてハードウェアの動作が調整される。

200Gbit/sのリンクをシミュレーションするためには、シミュレーションするプロセッサの3.2GHzとしてシミュレーションが行われる。

まず、ホストCPUとFPGAのデータ転送にはPCIeを使用する。 次に、トークンの束を転送するためAmazon Elastic DMA(EDMA)を使用する。 ToRスイッチには、共有メモリポートを使用し、異なるノード間の転送にはTCPを使用する。

NIC転送におけるサイクル計算の考え方。

3. EC2 F1インスタンスへのデプロイとマッピング

FireSimの構成をFPGAにデプロイするために、手動で構成していると時間がかかって無駄である。 FireSimは実現したい構成をPythonで記述すると、自動的にシステムを構成してFPGAでデプロイを行う。

Pythonで記述されたブレードサーバの構成を図4. に示す。 必要な構成に応じて、スイッチングのためのサーバには自動的にMACとIPアドレスが割り当てられ、MACのスイッチングテーブルはシミュレーション用に自動的に構成される。

f:id:msyksphinz:20180529021803p:plain

4. 環境と性能測定

FireSimのシミュレーション環境の検証と性能測定を行う。

A. ネットワークレイテンシベンチマーク

8ノードクラスタでLinuxをブートし、100のpingを実行して結果を測定した。 リンクのレイテンシを調整していき、レイテンシが予測通り変化することを確認した。

f:id:msyksphinz:20180529021739p:plain

B. ネットワークバンド幅測定

次に、ネットワークのバンド幅を測定するために、2つのノード間でパケットを転送しバンド幅を測定した。 結果は1.4Gbps/s となり、ネットワーク帯域の200Gbit/sを大幅に下回ったが、これはターゲットプロセッサのRocket CPUの性能ボトルネックになっているものと思われる。

C. ベアメタルのネットワークバンド幅テスト

一方で、Linuxを使用しないベアメタルのネットワークバンド幅テストのソフトウェアを開発し動作させた。 このテストでは100Gbit/sを計測し、私たちのネットワークバンド幅テストが低速な理由が、Linuxのソフトウェアスタックであることが確認できた。

D. ネットワークバンド幅の飽和を確認する

単一ノードでのネットワーク転送では最大帯域まで到達することは出来なかったが、複数のノードを接続することでネットワーク帯域が飽和するかを確認した。 これにより、例えば100Gbit/sの帯域制限を持たせたネットワークテストでは、2つのノードが転送を始めるとネットワーク帯域が200Gbit/sとなりバンド幅が飽和することを確認した。

f:id:msyksphinz:20180529021813p:plain

E. FireSimクラスタでmemcachedのQoS現象を再現する

(※ 省略)

5. シミュレーションパフォーマンス

A. ノード数と性能の関係

ノード数を増やしていき、シミュレーション性能を測定した。 200Gbit/s のネットワークで、2usのレイテンシの構成を使い、Linuxのユーザスペース上でベンチマークプログラムを実行した。 結果は、ノードの数を増やすとシミュレーション速度の低下がみられる。 ネットワークのシミュレーション性能がボトルネックになっており、特にSuperNodeの状態では複数のコア同期をとる必要があるため性能が落ちやすい。 図8. では、ベンチマークプログラムを実行した際のシミュレーション性能(シミュレーション性能MHz)を示している。

f:id:msyksphinz:20180529021822p:plain

B. ネットワークのレイテンシと性能の関係

ネットワークのレイテンシを短くすると、シミュレーション性能が低下することが確認できた。 つまり、ネットワークのレイテンシは性能における重要なボトルネックになっていることが確認できた。

f:id:msyksphinz:20180529021831p:plain

C. 数千ノードのデータセンタシミュレーション

FireSimのスケーラビリティをデモンストレーションするため、1024×2.2GHzの4コアノードでのシミュレーションを行った。 これには、32個のTop-of-Rackスイッチと4つの中間スイッチ、1つのトップスイッチを使用する。 ネットワーク帯域は200Gbit/sでレイテンシは2usの構成を使用した。 この状態でシミュレーション速度は3.42MHzであった。

このシミュレーション環境を、32個のf1.16xlargeインスタンスにマッピングして実行した。 これにはホストのToRスイッチと、サーバブレードのシミュレーション環境が含まれている。 5つのm4.16xlargeインスタンスを立ち上げ、ルートスイッチモデルと中間スイッチをシミュレーションした。 これにより、全体でかかったコストは1時間のシミュレーションあたりおよそ～\$100であった。 オンデマンドインスタンス、固定されたインスタンスの料金を含めて、1時間当たりのシミュレーションにかかる料金は～\$440であった。 EC2のFPGAを購入して使用するとなると、1FPGAあたり\$50Kとして、\$12.8M 必要となるところである。

f:id:msyksphinz:20180529021839p:plain

「30日でできる！OS自作入門」を読了した (29日/30日 アプリケーション作成)

30日でできる! OS自作入門

30日でできる! OS自作入門

29日目と30日目はアプリケーションをたくさん作ってみる話。

アプリケーションのアルゴリズム自体にはあまり興味がなかったので写経して終了。

一応、いろんなアプリケーションが動くようになった。記念撮影。

f:id:msyksphinz:20180527230020p:plain
図. ハリボテOSでいろんなアプリケーションを立ち上げた図。
f:id:msyksphinz:20180527232024p:plain
図. ハリボテOSでいろんなアプリケーションを立ち上げた図2。

ただしグラフィックスに関してちょくちょく(私の)実装ミスみたいなものがある。。。たとえば、インベーダーが動くたびに少しずつ増殖してしまっている。 なんでだろう。。。？グラフィックスの部分をもう少し読み直すと分かるかもしれない。

ここから進めていきたいこと。

  1. 復習。自分の中で曖昧に理解しているところがある。自分の言葉で表現することでより理解を深める。
  2. 他の文献をあたる。xv6の復習を開始したい(勉強したのはずいぶん昔だ...)
  3. 他アーキテクチャへの移植。Raspberry-Pi ARMへの移植は @uzusayuu さんにより行われている。これはすごい。

uzusayuu.hatenadiary.jp

「30日でできる！OS自作入門」を読み始めた (28日目 ファイルの操作と日本語表示)

30日でできる! OS自作入門

30日でできる! OS自作入門

28日目はファイル操作と日本語のサポートを行う。

ファイル操作については、APIをいくつか追加した。

  • ファイルのオープン
    • EDX = 21
    • EBX = ファイル名
    • EAX(戻り値) = ファイルハンドル
  • ファイルのクローズ
  • ファイルのシーク
    • EDX = 23
    • EAX = ファイルハンドル
    • ECX = シークのモンド(0=シークの原点はファイルの先頭、1=シークの原点は現在のアクセス位置、2=シークの原点はファイルの終端)
    • EBX = シーク量
  • ファイルサイズの取得
    • EDX = 24
    • EAX = ファイルハンドル
    • ECX = ファイルサイズ取得モード (0=普通のファイルサイズ、1=現在の読み込み位置はファイルの先頭から何バイト目か、2=ファイルの終端から見た現在位置までのバイト数)
    • EAX = ファイルサイズ(OSから返される)
  • コマンドラインの取得
    • EDX = 26
    • EBX = コマンドラインを格納する番地
    • ECX = 何バイトまで格納できるか
    • EAX(戻り値) = 何バイト格納したか

というわけで、typeiplコマンドを実装して、ipl10.nasを表示するコマンドを作った。

f:id:msyksphinz:20180527030815g:plain
図. `typeipl` コマンドを作って、ファイルを表示する。

次に、日本語対応を行う。日本語フォントを格納したファイルは、edimgコマンドなどを作って加工するようなのだが、これはとりあえずそのまま使わせてもらうことにした。 nihongo.fnt ファイルはそのままディスクイメージに挿入する。

そしたら、日本語の表示を実装する。基本は日本語Shift JISだが、EUCも実装していく。

最初に勘違いしていたのだが、フォントのアドレスを計算するのに、文字コードをunsigned charではなくcharで計算していたため、符号付きとして計算されてしまっていた。 これで随分とはまってしまった。

void putfonts8_asc (unsigned char *vram, int xsize, int x, int y, char c, unsigned char *s)   // unsigned char *s を最初char *s としており、符号付として計算されてしまった。
f:id:msyksphinz:20180527031212g:plain
f:id:msyksphinz:20180527031239g:plain
f:id:msyksphinz:20180527031321g:plain

NHK技研公開2018に行ってきました

www.nhk.or.jp

NHK放送技術研究所に行ってみるのは初めてのことだった。成城学園前駅からバスで約10～15分。意外と遠いな！ 実際に通っている人はみんなバスで通っているのかな。

NHKの技研公開では、NHKが考える未来の技術、現在開発中の技術や、NHKが作ろうとしている未来の放送の形を見ることができる。

例えば、23時からのニュースチェック11の「ニュースのヨミ子」など、AIを使った技術なども積極的に開発している。

例えば、

  • ニュースの音声を自動的にテキストに変換する書き起こし制作システム
  • 映像自動要約
  • テキストビッグデータ解析技術

など、今年のオリンピックでも活用された技術がたくさんある。 私は実際に見たわけではないけど、例えばオリンピックの放送配信所から送られてくる情報をテキストや音声に変換して読み上げるのならば、比較的簡単に実現できそうな技術である。

f:id:msyksphinz:20180526201616p:plain

少し気になるのは、NHKがどんどん放送の形態を広げようとしていることだ。 例えば、デンソーとの共同研究？で、視聴者から集めた視聴履歴から周辺のおすすめのお店を割り出し、ドライブ中にスマホやタブレットに表示してナビをすることができる。 これって、ほかの動画配信メディアの広告収入？というスタイルに似ているのかな？と思った。

例えば視聴者の視聴履歴という個人情報を渡したり、企業やお店にお金を払ってもらって視聴者にお勧めとして表示する。 こうやってテレビというメディアと視聴者をつなげ、ビジネスを成立させることも可能だ。

そうすると、視聴者からの受信料に頼らなくても？放送事業を継続することが可能なのではないか。と、ここで図を作ってみて、こういうのってネットメディア企業がやっていることと大して変わらなない、と思うようになった。じゃあこのビジネスモデルで、我々がわざわざ受信料を払う価値とはいったい...？

f:id:msyksphinz:20180526203409p:plain

まあそれはさておき、NHKの8K技術も面白い。 8Kシアターは見に行かなかったけど、これでスポーツを見れたら本当にすごいと思う。

f:id:msyksphinz:20180526203708p:plain

ピョンチャンオリンピックのフィギアスケートでも出ていた、連続カメラで角度を変えながらアニメーションを作る技術とか。Sports 4D Motionっていうのね。 あれはスポーツ競技にはちょっと不要かもしれないけど...

f:id:msyksphinz:20180526204916p:plain
4D Motion技術 (https://www.nhk.or.jp/strl/open2018/tenji/18.html より抜粋)

あとは、連続ドラマ「半分、青い」の立て看板とか...

f:id:msyksphinz:20180526204749p:plain:w400

技研7階のご飯は、安いし美味しかった。

f:id:msyksphinz:20180526204847p:plain

RISC-Vの連載第5回がインターフェース誌に掲載されました

これまでの記事はこちら。

f:id:msyksphinz:20180526001755p:plain
図. 第5回ではRISC-VボードHiFive1を使います。

今回は実機を触るということでRISC-VのASICチップHiFive1を使います。

HiFive1を動かすためにはいろんな方法があって、連載の中でも解説してますが、Arduinoの環境を使っていたり、Freedom SDKキットを使ったりと様々な方法があります。

今回は、とりあえず基本的な環境のセットアップの方法と、あとはベンチマークプログラムとしてCoreMarkを動かします。 CoreMarkが動いてしまえばそのボードはもう動いたようなもの！という勝手な感触で進めております...

あとはサイクルカウンタの使い方。これはRISC-Vに特有の問題ではありませんが、サイクルカウンタが64ビットで32ビットずつ別々のレジスタに分かれている場合、ちょっと変わったサイクルの取り出し方をしますよね。

  1. 上位32ビット(1)を取り出す。
  2. 下位32ビットを取り出す。
  3. 上位32ビット(2)をもう一度取り出す。
  4. (1)と(2)が異なっていればもう一度やり直し

これは2つのレジスタでサイクルカウンタが桁上げをしてしまい値がおかしくなることを防ぐためで(まあ桁上げの瞬間をキャプチャすることってなかなか無いだろうけど)、こういうテクニックはマイコンではよく使いますよね。

次回はHiFive1をつかってもうちょっと複雑なプログラムを動かす...と思われます。

AWS EC2 F1インスタンスを使ったハードウェア開発の勉強 (10. 整数行列計算回路の実装)

AWS_F1

AWS F1インスタンス HDK の勉強を続けている。 目標としては、以下の部分にAXIマスタを接続してDRAMにアクセスし、データをフェッチする。

  1. DMAでホストからデータをDDR4メモリに格納する。
  2. AXIマスタデータをフェッチする
  3. 演算し、結果を格納する。

として、例えば行列積のアクセラレータをF1インスタンス上で動作させてみたい。

f:id:msyksphinz:20180516232156p:plain

というわけで、とりあえず簡易的な行列演算回路、というか Dot Product Accelerator を作ってみた。 これでシミュレーションを実行してみる。 まずは簡単に、16x16の行列積を計算するための、16要素同士の32bit整数のDot Productを計算する。これをホストから16×16回アドレスを変えながら実行し、行列積を実行する。

f:id:msyksphinz:20180524004101p:plain

とりあえず256要素分を全部計算すると時間がかかるので、以下の青色の部分だけを計算するようにプログラムを切り替えてシミュレーションを実行した。

f:id:msyksphinz:20180524004850p:plain

計算結果のログを抽出すると、以下のようになる。正しく計算できていることが確認できた。

今度は計算性能を上げる改造と、F1インスタンスを使ったFPGAでの動作を確認していく。

            35594000 : [matrix] result FIFO read     0000000000008a20
            38094000 : [matrix] result FIFO read     0000000000008aa8
            40878000 : [matrix] result FIFO read     0000000000008b30
            43270000 : [matrix] result FIFO read     0000000000008bb8
            45778000 : [matrix] result FIFO read     00000000000167a8
            48642000 : [matrix] result FIFO read     0000000000024730
            50750000 : [matrix] result FIFO read     00000000000328b8
            53262000 : [matrix] result FIFO read     0000000000040c40