Reconf 201901

Company Proprietary Confidential Toyota InfoTechnology Center Co., Ltd. All Rights Reserved.
非整列ストリームデータ処理向け
マルチコアプロセッサシステムの検討と評価
株式会社トヨタIT開発センター
三好健文
1

背景
2
https://iotnews.jp/archives/12873

背景
3
http://www.ntt.co.jp/ir/library/nttis/201712/feature1.html?link_id=ir-b0004

背景
4
組み込み機器
利用可能メモリの制約
記憶領域の制約
通信容量の制約
サーバー
多様なアプリケーション
WiFi, 5G, LoRa, ...
なるだけデータを圧縮したい
=> ビット・バイトレベルでのデータ表現
ビットアサイン表の共有
簡単にデータを扱いたい
(数値, 文字列)

背景
5
1.ISO 11783-3:2014, “Tractors and machinery for agricul- ture and forestry – serial control and communications data network – part 3: Data link layer,”
May 2014. https: //www.iso.org/standard/57554.html

背景
6
https://medium.com/@zengcode/messagepack-for-java-bdde520ee574
https://github.com/msgpack/msgpack-c/wiki/v2_0_cpp_unpacker

背景
7
組み込み機器
利用可能メモリの制約
記憶領域の制約
通信容量の制約
サーバー
多様なアプリケーション
なるだけデータを圧縮したい
=> ビット・バイトレベルでのデータ表現
ビットアサイン表の共有
簡単にデータを扱いたい
(数値, 文字列)
WiFi, 5G, LoRa, ...
解析・復号
SW
大変!!
a
b
c
d
e
fg
….
ID

背景
8
◆組み込みではビット・バイトレベルのデータ解析が必須
◆多種多様なデータを扱うのは，結構大変
=> あれ？FPGAでやってみると，いいのでは？

FPGAによる解析・復号の動作と目標見積もり
9
✓ データフォーマットに応じた処理で復号・解析
✓ ワード長に合わないデータへの対応も適当なバッファで対応できそう
✓ 仮に，データ入出力幅512bitを動作周波数100MHzでさばければ，
✓ 出力が4Byte単位であれば，1600Mアイテム/sで処理可能という超楽観的な見積もり
✓ データ入出力帯域 51.2Gbps(=6.4 GBps) は，それなりに現実的
✓ うまくデータ並列性，パイプライン化できるアーキテクチャを考えればいい!!
a
b
c
d
e
f
g
復号・解析後のデータ
…. c’f’ a’b’d’e’g’
FPGA
….
．
．
．
ID毎のフォーマットに
合わせた復号・解析処理
ID ID
a’ = a * 3.14
b’ = b[2:0] + b[5:3]
c’ = c[0]

例題: CANデータの復号・解析
10
テーブルID
データ長
付加情報
ヘッダデータ
ID
長さ
値
ID
長さ
値
ID
長さ
値
ID
長さ
値
ID
長さ
値
ID
長さ
値
ID
長さ
値
ある機器から，あるタイミングで
送られてきたデータ
ここがワードアライメントに
乗るかどうかは保証はされない
✓ 車種，データ長および付加情報の載ったヘッダ+CANデータの連続
512bit
テーブルID
データ長
付加情報

専用ロジックを考えてみる…
11
アライメント
データ
対象データ構造毎
のロジック
非アライメント
データ
✓ ナイーブな実装方式
入力データ出力データ
処理ロジック
✓非整列データをビット・バイトレベルで処理すると必要サイクル数が増加する
✓ストリームデータの入力フロントエンドで，オフセットをあわせる

専用ロジックを考えてみる…
12
アライメント
データ
対象データ構造毎
のロジック
非アライメント
データ
✓ ナイーブな実装方式
入力データ出力データ
処理ロジック
Item ALM (427200) M20K(2713) DSP Blocks(1518)
処理ロジック 4065 (0.95%) 38(1.4%) 2-4(0.13-0.26%)
Data Fetcher 2076 22
Data Emitter 1124 16
PE 656
✓ Arria® 10 GX FPGA 10AX115N2F40E2LG(Intel PAC) を想定してのリソース使用率
✓ ある対象データの処理(ビット切り出し，加減算，浮動小数点数演算)ロジックの実装例
✓ 甘く見積もっても100個くらいしか入らない
✓ 同じ対象データが連続してくると処理レイテンシが隠蔽できない
=> 対象データに対して汎用的な演算機構が必要

課題とアプローチ
13
◆ 処理対象のバリエーションが大きい
◆ どの処理を適用するか決定する処理で性能が律速
◆ 関連研究: UDP @ MICRO50
◆複数の命令フェッチを可能にする専用演算ユニットを追加
← FPGAの場合，多ポートのメモリ/メモリバンド幅が問題に
→ フェッチ機構を前倒しすることで，時間方向で多重化
MA, USA Y. Fang et al.
ad engine.
xpanding variety of
e control ow, large
chine-standard data
these philosophies
roducing poor per-
el lanes (Figure 3a),
oding. Parallel lanes
ncoding and trans-
cludes support for
(a) 64-lane UDP. (b) UDP lane adds three elem ents (green) to a tradi-
tional CPU m icro-architecture.
Figure 3: UDP and UDP Lane M icro-architecture.
3.2 UDP Lane: Fast Sym bol and Branch
Processing
The UDP’s 64 lanes each accelerate symbol-oriented conditional
processing. The four most important UDP lane capabilities include:
1) multi-way dispatch, 2) variable-size symbol support, 3) exible
Y. Fang, C. Zou, A.J. Elmore, and A.A. Chien, “Udp: A programmable accelerator for extract-transform-load workloads and more,”
Proceedings of the 50th Annual IEEE/ACM International Symposium on Microarchitec- ture, pp.55–68, MICRO-50 ’17, ACM, New York, NY, USA, 2017.

アーキテクチャ概要
14
入力データに応じて，
対象車種用の命令列をフェッチ
対象車種16bitとして，
DRAMのアドレスにマッピング
与えられた命令列を使って
入力データをパース，物理量変換
✓ 命令フェッチをデータ処理に先行して実行
それなりの個数並べればFPGA上の
簡単なコアでもデータをさばける，と期待

処理の記述方式
15
a
b
c
d
e
f
g
…. c’f’ a’b’d’e’g’…. ID ID
a’ = a * 3.14
b’ = b[2:0] + b[5:3]
c’ = c[0]
parser test{
table : 11;
value : <64;
}
task test(id=1){
v0 : int<10> { return v0 + 10; }
v1 : int<7> { return v1 * 2; }
}
task test(id=2){
v0 : float<5> { return v0 - 16; }
v1 : int<16>
v2 : int<16> { return v1 + v2; }
}

命令フェッチユニット
16
✓ 入力データを処理に先行してパース，車種に応じた命令列を読み出す
✓ DRAMリードレイテンシ分(数百サイクル程度)を稼ぐのが目的

命令フェッチユニット
17
id=1 len=128 attr
id=2 len=192 attr
data
data
data
data
data
id=2 len=64 attr
data id=3 len=512 data
id=4 len=128 attr data
入力データ
対象ノードに振り分けて出力
読んだ命令を各ノードに出力
命令読み出し

演算ユニット
18
✓ 命令列に従ってCANデータを解析・復号．
✓ データアライメント・パディングは前・後段で処理
✓ CANデータフレームを一つずつ読み出せるようData Fetcherで前さばき
✓ ← controllerの対象フレームは必ずワードの先頭からはじまる

入力データと命令形式
19
ID
(11bit)
長さ
OP
これをキーに，
命令メモリから
最初の命令を
読み出す
入力データ
対象ビット長
定数
命令(32bit)
入力データに順々に適用
Source
(reg./FIFO)
Destination
(reg./FIFO)
命令/データメモリ
先頭11bit分は
入力データから
飛んでくる
(=割り込みベクタ)
2K命令 + 14K命令
= 16K命令 = 64KB
5 3 3 105
✓算術演算
✓論理演算
✓比較
✓条件分岐
✓ロード・ストア
(出力ビット長)
51

20
if pe_src(2) = '0' then -- use register file
case to_integer(unsigned(pe_src(1 downto 0))) is
when 0 => src0 := register_file(31 downto 0);
when others => src0 := (others => '0');
end case;
elsif pe_src = "110" then -- use imm
src0(7 downto 0) := pe_imm(9 downto 2);
src0(31 downto 8) := (others => '0');
elsif pe_src = "111" then -- use imm(signed ext)
src0(7 downto 0) := pe_imm(9 downto 2);
src0(31 downto 8) := (others => pe_imm(9));
else -- use FIFO
-- get fifo data into src0
if data_bits < 31 then
src0(data_bits downto 0) := target_data_reg(data_bits downto 0);
if pe_src(0) = '0' then
src0(31 downto data_bits+1) := (others => '0');
else
src0(31 downto data_bits+1) := (others => target_data_reg(data_bits));
end if;
else
src0 := target_data_reg(31 downto 0);
end if;
-- consume fifo data
target_update_data(63-(data_bits+1) downto 0) := target_data_reg(63 downto (data_bits+1));
target_update_data(63 downto 63-(data_bits+1)+1) := (others => '0');
target_update_we := '1';
end if;
✓ ソースオペランド0: FIFOかレジスタか即値
レジスタファイルから
定数フィールドから
(unsigned/signed)
FIFOから長さ指定
(unsigned/signed)

21
if pe_dst(2) = '1' then
fifo_out_v := result;
fifo_we_v := '1';
register_update_we := '0';
else
fifo_we_v := '0';
case to_integer(unsigned(pe_dst(1 downto 0))) is
when 0 =>
register_update_data(127 downto 32) := register_file(127 downto 32);
register_update_data(31 downto 0) := result;
when 1 =>
when 2 =>
when 3 =>
when others =>
register_update_data := register_file;
end case;
end if;
✓ 演算結果の出力: FIFOかレジスタ
FIFOへ出力
レジスタファイル
への出力

演算ユニット
22
データと命令がきたら
演算を実行

演算ユニット
23
PE_OP_LI, 1,00000,00000,000,000,0011111111
PE_OP_ADD, 1,00000,00000,000,100,0000000000
PE_OP_MOV, 1,00000,00000,100,100,0000000000
PE_OP_MOV, 1,00000,00000,100,100,0000000000
PE_OP_MOV, 1,00000,00000,100,100,0000000000
PE_OP_MOV, 1,00000,00000,100,100,0000000000
PE_OP_MOV, 1,00000,00000,100,100,0000000000
PE_OP_MOV, 1,00000,00000,100,100,0000000000
PE_OP_MOV, 1,00000,00000,100,100,0000000000
PE_OP_MOV, 1,00000,00000,100,100,0000000000
PE_OP_MOV, 1,00000,00000,100,100,0000000000
PE_OP_HALT,0,00000,00000,100,100,0000000000
毎サイクル入力されたデータを1bitずつ切り出して
32bit化して出力している

演算ユニット
24
ADD NOT EQ FADD RSHIFT MOV JMP
SUB AND NEQ FMUL LSHIFT MOVS JZ
MUL OR GT F2I ZERO HALT
DIV XOR LT I2F LI
✓ 命令(いまのところ)

ターゲット環境とリソース使用量
25
FPGA Intel® Arria10 GT FPGA 10AT115S2F45E2SG
1150K LEs, 53Mb(M20K)
メモリ 8GB DDR4
I/F PCIe Gen3 x8, QSFP 4x10G x2
✓ ターゲットFPGAボードのスペック
✓ リソース使用量
ALM M20K
ペリフェラル 75342(17%) 137(5.0%)
命令フェッチユニット 4133(0.27%) 30(1.1%)
セレクタ 1042(0.24%) 5(0.18%)
演算ユニット(1個)
演算コア 3073(0.72%) 30(1.1%)
データフェッチ/エミッタ 3200(0.77%) 20(1.48%)
演算ユニット 30個時 269634(63%) 2272(83%)
演算ユニット 20個時 206925(49%) 1572(57%)

実行性能見積もり
26
✓ベストケース: 128bit入力から64bitのデータを生成(処理しない場合)
-> kick, MOV, MOVの3サイクル
-> 15nsで，128bitの入力を処理
-> 入力データに対する処理スループット = 約 8.5Gbps
✓典型的なシナリオの一例: 64bitのデータを16bitのデータに分割して出力
-> kick, LI, LI, ADD, LI, LI, ADD, LI, LI, ADD, LI, LI, ADD
-> 65nsで，128bitの入力を処理
-> 入力データに対する処理スループット = 約 2.0Gbps
たとえば，40Gbpsの入力データをさばくためにはコアを20個並べればよい
（注: 出力は十分に速いか，適当に捨てられるデータがある必要はある）
✓ スループット(コアが200MHzで動作する場合)

メモリレイテンシの隠蔽について
27
パケットサイズ(Bytes)
サイクル数
n=30時の隠蔽可能なメモリレイテンシ
✓ 命令読み出しレイテンシ L サイクル，搭載演算ユニット数 n
✓ パケットサイズ l word = l * 256 bit
✓ メモリレイテンシを隠蔽するためには， L < l * n が必要
✓演算ユニット数 n=30,レイテンシ L=200 ならば， l > 6.6
← l=7 は，パケットサイズ1792bit(= 224Byte)に相当＝ CANデータ13～14個
命令読み出し
レイテンシを隠せる部分

まとめと今後の課題
28
◆ 非整列な組み込み機器のデータ復号・解析処理向けのプロセッサコアを検討
◆汎用プロセッサでの性能向上は，結構難しい(25Mアイテム/秒)
◆FPGA上にプロセッサを構成，命令フェッチユニットを前倒し
◆データ転送を1命令で実行可能な命令セット
◆FPGA上に実装可能な演算ユニット数について評価
◆処理スループットの見積もり
◆入力データパケットサイズと隠蔽可能な命令読み出しレイテンシの見積もり
◆ 実環境，実データでの評価
◆ もう少し汎化できないか
← フェッチユニットなどをコンフィギュレーションして対応できると
他のデータにも対応できてうれしい？
✓ まとめ
✓ 今後の課題

Reconf 201901

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Reconf 201901

Similar to Reconf 201901 (20)

More from Takefumi MIYOSHI

More from Takefumi MIYOSHI (20)

Reconf 201901