2021 年度 修士論文

System-on-a-Chip を用いた
組み込みシステム開発基盤の構築と FPGA 間通信の実証— 次世代高エネルギー実験制御系への応用
Development of an embedded system using System-on-a-Chipand demonstration of communication between FPGAs






— Application to a control systemof next generation high-energy physics experiments


東京大学大学院理学系研究科物理学専攻
素粒子物理国際研究センター
石野研究室

博士課程（前期課程）2 年
学籍番号 35–206023

岡崎健人
2022 年 1 月 6 日

ii

概要
2027 年から開始される高輝度 LHC-ATLAS 実験において、ミューオントリガーエレクトロニクスはすべて刷新される。ミューオントリガーシステムの後段回路 Sector Logic（SL）は大規模 FPGA を搭載し、送信されたす
べてのヒット信号を用いてオンライン演算や読み出しがなされる。SL の制御系高度化のため、Zynq UltraScale+

MPSoC を搭載した市販のメザニンカード（Mercury XU5）を導入する。Zynq MPSoC の OS として CentOS 7 を採用し、ボード上の素子の制御を行う。また ATLAS control network（ATCN）と Endcap SL のインターフェースとなる。さらに AXI Chip2Chip を用いた高速シリアル通信で大型 FPGA のレジスタ制御や読み出しデータのダンプを行うことで、トリガーや読み出しのロジックに関わるパラメータの設定や、コミッショニングやキャリブレー
ション時のテストリードアウト環境のコンフィグレーション、フロントエンド FPGA のリモートでの操作を行う。
本研究ではまず Zynq MPSoC で SD カード起点で CentOS 7 を起動し、基本的なファームウェア開発を行なった。これにより組み込みシステムとしての Zynq MPSoC 開発の技術基盤を確立した。また 2021 年 10 月に完成した Endcap SL 第 1 試作機上の Zynq MPSoC で CentOS 7 を起動し、クロックジェネレータや温度センサなどの素子をソフトウェアから操作できることを確認し、それらの検証の中で Endcap SL 第 1 試作機上の配線上の問題を指摘した。さらに Zynq MPSoC で Xilinx Virtual Cable という技術を使い、ネットワーク越しに Zynq MPSoC から大型 FPGA のプログラムやデバッグができることを示した。AXI Chip2Chip と Gigabit transceiver を用いた高速シリアル通信のリンクも確立し、Zynq MPSoC から大型 FPGA のメモリにアクセスできることを確認した。大型 FPGA のレジスタ制御に用いられる、AXI Chip2Chip とレジスタとのインターコネクトの開発も行なった。これにより HL-LHC に向けた Endcap SL の Zynq MPSoC 周りの開発基盤が整った。
本研究は比較的安価な市販品のメザニンカードを、実験のためのカスタムボードに搭載し運用に成功した好例であり、本研究におけるボードデザインや、ソフトウェアやファームウェアの実装の知見および運用経験は、今後の物理実験における制御系のデザインにも活用できる。本研究では高エネルギー実験における制御系高度化のための

1 つの標準型を確立し、重要な技術基盤を築いた。

v

目次

第1章

高輝度 LHC-ATLAS 実験における Level-0 Muon Trigger System

1

ATLAS 検出器における TGC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.1.1

ATLAS 検出器 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.1.2

Thin Gap Camber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2Phase-II Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.2.1

L0Muon トリガーシステム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

1.2.2

HL-LHC における TGC エレクトロニクス . . . . . . . . . . . . . . . . . . . . . . . . . .

5

1.2.3

Endcap Sector Logic における Zynq MPSoC . . . . . . . . . . . . . . . . . . . . . . . . .

8

1.3

研究目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

1.4

本論文の構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10Zynq MPSoC を用いた組み込みシステムの開発

11

1.1

1.2

第2章

2.1

Zynq UltraScale+ MPSoC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1

Processing System（PS） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.2

Programmable Logic（PL） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.3

Mercury XU5 と Mercury+ PE1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2

Zynq MPSoC におけるブートシーケンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3

Zynq MPSoC の開発手順 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4

2.5

第3章

2.3.1

開発環境と使用するツール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

2.3.2

ブートに必要なファイルと作成方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

2.3.3

一般的な開発の流れ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

ZCU102 評価ボードでの開発例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.1

Vivado を用いたファームウェアの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4.2

PetaLinux でのブートファイル作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4.3

SD カードからのブート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.4.4

PL のロジックを PS から操作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Mercury XU5 と Mercury+ PE1 での開発パスの確立 . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.1

Vivado と PetaLinux を用いたパス（リファレンスデザインの利用） . . . . . . . . . . . . 25

2.5.2

PetaLinux の代用として EBE を用いたパス . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Endcap Sector Logic 第 1 試作機上の MPSoC の動作検証

29

3.1

準備

3.2

CentOS 7 の SD カードブート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

目次

vi
3.3

Gigabit Ethernet の開通 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.1

スワップされた配線の問題と PS Ethernet（ETH0）の開通

3.3.2

PL Ethernet（ETH1）の開通 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

. . . . . . . . . . . . . . . . . 32

2

3.4

I C 通信プロトコルによる clock jitter attenuator の設定 . . . . . . . . . . . . . . . . . . . . . . . 34

3.5

Xilinx Virtual Cable を使った FPGA のデバッグおよびプログラム . . . . . . . . . . . . . . . . . 35

3.6

第4章

3.5.1

Zynq MPSoC PL のデバッグ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.5.2

XCVU13P のデバッグおよびプログラム . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

その他の細かな確認事項. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.6.1

JTAG からの Zynq MPSoC PL のプログラム . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.6.2

I2 C での温度センサの確認 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.6.3

Zynq MPSoC からの Si5345 入力クロックの指定 . . . . . . . . . . . . . . . . . . . . . . . 40

AXI Chip2Chip を用いた FPGA 間シリアル通信用ファームウェアの開発

41

4.1

目指す完成形 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

4.2

AXI Chip2Chip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.1

AXI Chip2Chip を使うことの利点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2.2

AXI Chip2Chip と Aurora コア . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.3

Endcap SL 上でのファームウェアの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.4

Endcap SL での高速シリアル通信試験の結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.5

register interface の作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.5.1

register interface 内部のステートマシン . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.5.2

register interface を用いたテストベンチシミュレーションの実行 . . . . . . . . . . . . . . . 49

本章のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

第5章

まとめと今後の展望

53

付録 A

典型的な PetaLinux での作業の詳細

55

付録 B

Ultra96-V2 を用いた開発パスの確認と物体検出処理の高速化

57

4.6

B.1

Linux のブート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
B.1.1 提供されている Linux イメージの SD カードブート . . . . . . . . . . . . . . . . . . . . . 58
B.1.2 PetaLinux の BSP を用いた Linux のブート . . . . . . . . . . . . . . . . . . . . . . . . . . 58
B.1.3 Vivado の BDF を用いたファームウェアの作成 . . . . . . . . . . . . . . . . . . . . . . . . 60

B.2

ニューラルネットワークの行列演算をハードウェア化する . . . . . . . . . . . . . . . . . . . . . .

63

B.2.1 行列演算 IP の作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
B.2.2 カーネルモジュール u-dma-buf の利用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
B.2.3 行列演算 IP のテスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
B.2.4 YOLOv3 の高速化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
付録 CLinux からのメモリアクセスによるモジュールの操作

73

付録 D

Linux からの I2 C デバイス操作方法

75

D.1

PetaLinux での準備 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

D.2

ブートログや I2 C Tools を用いた I2 C デバイスの確認 . . . . . . . . . . . . . . . . . . . . . . . . .

77

vii
D.3

ソフトウェアからの I2 C デバイスの操作方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

D.4

Si5345 の操作方法（ページの概念） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

付録 E

XVC 開発の詳細

79

83

E.1

PetaLinux での操作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

E.2

XVC サーバアプリケーションの開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

付録 F

回路図

87

付録 G

Endcap SL 第 1 試作機で使用したファームウェアのブロックデザイン

91

付録 H

AXI4 プロトコル

93

H.1

基本的なコンセプト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

93

H.2

AXI4-Stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

H.3

AXI4-Lite と AXI4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
H.3.1 チャンネル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
H.3.2 信号線 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
H.3.3 バースト転送 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

付録 I

AXI Chip2Chip のテストベンチシミュレーションの実行

101

付録 J

ZCU102 評価ボードを用いたループバック試験

103

J.1

BRAM-C2C interconnect の構想 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

謝辞

107

引用文献

109

ix

図目次

1.1

LHC と 4 つの検出器 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2

ATLAS における座標系の定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.3

TGC Big Wheel と Endcap Inner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.4

TGC の構造 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.5

doublet と triplet の断面図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.62021 年 1 月に更新された LHC/HL-LHC アップグレード計画 . . . . . . . . . . . . . . . . . . . .

4

1.7

HL-LHC での ATLAS 実験における TDAQ システムの全体像 . . . . . . . . . . . . . . . . . . . .

5

1.8

HL-LHC における endcap 部の L0Muon トリガーシステム . . . . . . . . . . . . . . . . . . . . .

6

1.9

1/24 セクターをカバーする TGC エレクトロニクスシステムの概念図 . . . . . . . . . . . . . . . .

6

1.10

PS ボードの簡略化した回路図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

1.11

Endcap SL のダイアグラム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

1.12

Endcap SL のパターンマッチングアルゴリズムと CW を用いた pT . . . . . . . . . . . . . . . . .

9

1.13

Endcap SL における Zynq MPSoC の機能の概略図 . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1

Zynq UltraScale+ MPSoC のブロックダイアグラム . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2

Mercury XU5 メザニンカード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3

Mercury+ PE1 ベースボード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4

Mercury XU5 と Mercury+ PE1-300 のハードウェアブロックダイアグラム . . . . . . . . . . . . 15

2.5

ブートシーケンスの例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.6Zynq MPSoC のブートに必要なファイルと制御の流れの例 1 . . . . . . . . . . . . . . . . . . . . . 17

2.7

Zynq MPSoC のブートに必要なファイルと制御の流れの例 2 . . . . . . . . . . . . . . . . . . . . . 18

2.8

Zynq MPSoC PS の設定画面の例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.9

[Address Editor]のタブの例

2.10

BRAM と AXI GPIO LED を用いたブロックデザインの例 . . . . . . . . . . . . . . . . . . . . . . 22

2.11

ZCU102 評価ボード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.12

Mercury+ PE1 にマウントさせた Mercury XU5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.13

Mercury XU5 PE1 リファレンスデザインのブロックダイアグラム . . . . . . . . . . . . . . . . . . 25

2.14

Vivado と PetaLinux を用いた Mercury XU5 の開発フロー . . . . . . . . . . . . . . . . . . . . . 26

2.15

EBE によるコンフィギュレーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.16

EBE を用いた Mercury XU5 開発パスの例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1

Endcap SL 第 1 試作機にマウントした Mercury XU5 の様子 . . . . . . . . . . . . . . . . . . . . . 29

3.2

microSD カードスロット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.3

Vivado で CD の機能を無効化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

15

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

図目次

x
3.4

メザニンとのコネクタピン A81 と A98 を接続した様子

3.5

Endcap SL 上の ETH0 用 RJ45 コネクタと Mercury XU5 とのコネクタ A の ETH0 に関する部分

3.6

内部で信号線をスワップさせた LAN ケーブルを作製した

3.7

Endcap SL 上の Si5345 clock jitter attenuator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.8

Endcap SL 上の TCA9548A I2 C channel multiplexer . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.9

Zynq MPSoC の PL をデバッグする際の XVC の構成 . . . . . . . . . . . . . . . . . . . . . . . . 36

3.10

PL デバッグ用に置いた 2 つの Debug Bridge コア . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.11

XVC を用いて Zynq MPSoC の PL に組み込んだ 6-bit counter をプローブしている様子 . . . . . . 37

3.12

[From AXI to JTAG]モードでの Debug Bridge 使用例

3.13

XVC での XCVU13P のプログラムに成功した様子 . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.14

リモートで IBERT 試験を行っている様子 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.15

JTAG からローカルに Zynq MPSoC の PL をプログラムした様子 . . . . . . . . . . . . . . . . . . 39

4.1

レジスタ制御の完成模式図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2

AXI Chip2Chip と Aurora コアのクロックとリセットの接続 . . . . . . . . . . . . . . . . . . . . . 43

4.3

AXI Chip2Chip を用いた FPGA 間通信のデモンストレーション . . . . . . . . . . . . . . . . . . . 43

4.4

AXI Chip2Chip master は AXI SmartConnect を介して PS と接続できる . . . . . . . . . . . . . . 44

4.5

[Address Editor]では AXI Chip2Chip master に物理アドレスが割り当てられていた . . . . . . . .

4.6Endcap SL 第 1 試作機で AXI Chip2Chip の試験をする際使用したクロックとピン . . . . . . . . . 45

4.7

XCVU13P 側の AXI Chip2Chip と Aurora 64B/66B のデバッグポートを ILA で見て、リンクの. . . . . . . . . . . . . . . . . . . . . . . 31
32

. . . . . . . . . . . . . . . . . . . . . . 33

. . . . . . . . . . . . . . . . . . . . . . . . 38

確立を確認した . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

41

45

46

4.8

AXI Chip2Chip のテストベンチシミュレーション . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.9

register interface を加えたテストベンチシミュレーション . . . . . . . . . . . . . . . . . . . . . . 48

4.10

register interface とレジスタとの接続 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.11

register interface の読み出しに関するステートマシンのタイミングチャート . . . . . . . . . . . . . 49

4.12

register interface の書き込みに関するステートマシンのタイミングチャート . . . . . . . . . . . . . 50

4.13

10 個のレジスタに正しく書き込めた様子 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.14

4 つのレジスタに表 4.3 のような役割を持たせたときの挙動 . . . . . . . . . . . . . . . . . . . . . 51

A.1

petalinux-config 画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

B.1

Ultra96-V2 シングルボードコンピュータ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

B.2

Wi-Fi で Ultra96-V2 を検出 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

B.3

Ultra96-V2 のウェブアプリの例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

B.4

Ultra96-V2 の開発フロー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

B.5

OOB のブロックデザイン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

B.6

新たに作成した BRAM のブロックデザイン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

B.7

BRAM のアドレス割り振り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

B.8

YOLOv3 を用いて画像の物体検出をした例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

B.9

HLS_accel をブロックデザインに追加し、AXI DMA を介して PS と接続した . . . . . . . . . . . 65

B.10

HLS_accel を用いた行列演算のためのソフトウェア、ファームウェア構造 . . . . . . . . . . . . . 67

B.11

物体検出処理時間の結果

62. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

xi
D.1

I2 C デバイスドライバを追加 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

D.2

Si5345 の I2 C スレーブアドレス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

E.1

UIO を使うためのデバイスドライバを追加 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

F.1

Mercury XU5 のコネクタ A と B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

F.2

Endcap SL 上の Mercury XU5 とのコネクタ A . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

F.3

Endcap SL 上の Mercury XU5 とのコネクタ B . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

G.1

XCVU13P 側のブロックデザイン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

G.2

Zynq MPSoC 側のブロックデザイン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

H.1

Interconnect を介した複数のマスターとスレーブの接続 . . . . . . . . . . . . . . . . . . . . . . . . 93

H.2

AXI4 におけるハンドシェイク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

H.3

AXI4 の transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

H.4

各チャンネル間のハンドシェイクの依存性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

H.5

AXI4 burst read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

H.6

読み出しバースト転送の例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

99

H.7

書き込みバースト転送の例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

99

I.1

AXI Chip2Chip のサンプルデザイン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

I.2

マスターが書き込むデータをすべて 0xDEADBEEF にしたとき、スレーブがそれを受け取る様子 . . 102

I.3

RIDが 0x39 のときマスターがデータ 0xDEADBEEF を受け取る様子 . . . . . . . . . . . . . . . . . 102

J.1

ZCU102 評価ボードでのループバック試験 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

J.2

ZCU102 の Bank 230 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

J.3

オシロスコープで 125 MHz を確認 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

J.4

BRAM-C2C interconnect を組み込んだループバックファームウェア . . . . . . . . . . . . . . . . 105

96

xiii

表目次

2.1

ブートに用いるファイルと作成方法

4.1

XCVU13P のプローブ結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2

Zynq MPSoC のプローブ結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3

4 つのレジスタに与えた役割 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

H.1

AXI4-Lite と AXI4 で使われる 5 つのチャンネル . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

H.2

AXI4 と AXI4-Lite の信号線 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

J.1

新たに作成すべき BRAM アドレスマップ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

xv

コードブロック目次
A.1 ZCU102 で行った設定の例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
B.1 GitHub から BDF と HDL ファイルの一式をクローンして Vivado プロジェクトを作成 . . . . . . . 60
B.2 編集した run_hls_script.tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
B.3 編集したデバイスツリー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
B.4 HLS_accel による行列計算結果をソフトウェアでの計算結果と比較するプログラム matrix.c の一部 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C.1

68

devmem と同様の機能を持つ C 言語によるプログラム . . . . . . . . . . . . . . . . . . . . . . . . . 73

D.1 Endcap SL 上の I2 C MUX（図 3.8）についてのデバイスツリーの記述 . . . . . . . . . . . . . . . . 76
D.2 ブートログから I2 C デバイスが検出されていることの確認 . . . . . . . . . . . . . . . . . . . . . . . 77
D.3

/dev/i2c-* というデバイスファイルを 9 つ検出 . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

D.4

i2cdetect -l で使用可能な I2 C デバイスを確認できる . . . . . . . . . . . . . . . . . . . . . . . 78

D.5

i2cdetect -y -r 4 の出力結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

D.6

i2cdump コマンドでレジスタの内容をダンプした結果 . . . . . . . . . . . . . . . . . . . . . . . . 79

D.7 I2 C-read 関数の例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
D.8 I2 C-write 関数の例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
E.1

debug_bridge_0 の情報をデバイスツリーに追加 . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

E.2 CentOS 7 から debug_bridge が /dev/uio0 に割り当てられている様子 . . . . . . . . . . . . . . 83
E.3 XVC サーバ起動時にはインストラクションメッセージを表示させるようにした . . . . . . . . . . . 84

1

第1章

高輝度 LHC-ATLAS 実験における Level-0

Muon Trigger System
1.1 ATLAS 検出器における TGC
欧州原子核研究機構（CERN）はスイスジュネーブ郊外に所在する世界最大規模の素粒子物理研究機関である。その地下およそ 100 m にはフランスとの国境をまたぐ形で Large Hadron Collider（LHC）が敷設されている。LHCは周長 26.66 km の陽子-陽子衝突型円形加速器で、2022 年から開始される運転（Run 3）での重心エネルギーは

13.6 TeV、瞬間ルミノシティはピークで 2.0 × 1034 cm−2 s−1 になる。
図 1.1 のように LHC の 4 つの衝突点にはそれぞれ Large Hadron Collider beauty（LHCb）、A Large Ion CollidEr（ALICE）、Compact Muon Solenoid（CMS）、そして A Toroidal Lhc ApparatuS（ATLAS）という粒子検出器が置かれている。

図 1.1

LHC と 4 つの検出器（Mouche 2014）

1.1.1 ATLAS 検出器
ATLAS 検出器は全長 44 m、直径 25 m の円筒状をしており、質量 7 kt の大型汎用検出器である。LHC によって 7 TeV まで加速された 1011 個の陽子を含むバンチが 40.079 MHz で検出器中心で交差し（24.95 ns に 1 回のバ第 1 章 高輝度 LHC-ATLAS 実験における Level-0 Muon Trigger System

2(a) 直交座標系(b) 円筒座標系
図 1.2 ATLAS における座標系の定義

ンチ交差頻度）、その中で生じる陽子陽子衝突の測定を行う。
陽子バンチ同士が衝突する ATLAS 検出器の中心を衝突点（Interaction Point、IP）とよぶ。ATLAS 実験においては 2 つの座標系、直交座標系と円筒座標系が用いられる。直交座標系では図 1.2(a) のように IP を原点とし、LHC の中心を向く方向に x 軸、鉛直上向きに y 軸をとり、右手系に従って z 軸をとる。また図 1.2(b) のように、z軸からの距離を R、z 軸となす角を θ 、x–y 平面となす角を ϕ とする円筒座標系を採用する。さらに θ を用いて

[

( )]
θ
η ≡ − ln tan2と定義される擬ラピディティという量も用いられる。

ATLAS 検出器は円筒形をしているが、円筒の側面をバレル部（barrel）、円筒の底面部をエンドキャップ部（endcap）という。本研究で取り扱うミューオントリガーは、バレル部とエンドキャップ部で異なる検出器、トリ
ガーロジックを実装するが、おおよそ |η| = 1 のあたりがバレルシステムとエンドキャップシステムの境界である。
また図 1.2(a) において z > 0 の側を A-side、z < 0 の側を C-side とよぶ。

1.1.2

Thin Gap Camber

ATLAS 検出器の両端には TGC（Thin Gap Chambers）が設置されている。これはエンドキャップ部のミューオ
ントリガーを担当する検出器である。TGC はエンドキャップトロイド磁石の内側にある Endcap Inner（EIL4）と外側にある Big Wheel（BW）から構成される（図 1.3）。TGC は ATLAS 検出器の最外層に設置されており、荷電粒子の中で最も透過力の大きいミューオンを主に検出する。多層の位置情報を統合することで横運動量を概算し、あらかじめ設定した運動量閾値を超えたミューオンを含んだ事象をトリガーする。

TGC 検出器を構成する最小単位は、1 m から 2 m 四辺の台形型をした multi-wire propotional chamber（MWPC）のユニットである。その構造を図 1.4 に示す。直径 50 µm のアノードワイヤーが 1.8 mm 間隔で並んでおり、そのアノード面から 1.4 mm 離れてカソードストリップがある。これにより２次元的な読み出しができる。ガス増幅部には二酸化炭素と n-C5 H12 （n-ペンタン）がそれぞれ 55%, 45% の割合で混合されたガスが充填されている。ア
ノードとカソード間には約 2.9 kV の電圧が印加されていて、電離した電子の増幅を促す。これにより約 3 × 105 のガスゲインが得られている。

A-side、C-side それぞれ 7 層のガス層で構成される TGC BW は、3 つのステーションに分かれて設置されており、IP に近い順に M1、M2、M3 と呼ばれている。M1 は 3 層、M2 と M3 はどちらも 2 層のガス層からなるため、M1 は doublet、M2 と M3 は triplet とも呼ばれる。それらの断面図を図 1.5 に示す。

1.2 Phase-II Upgrade

3

図 1.3

ple of operation

2008 JINST 3 S08003, bending coordinate is measured by the TGC wire groups, the azimuthal coordinate
rips. The TGC’s need good time resolution to tag the beam-crossing with high9%) and fine granularity to provide a sufficiently sharp cut-off in the momentum ofmuon. To match the granularity to the required momentum resolution, the size ofvaries from 6 to 31 as a function of h, corresponding to a variation in width from
8 mm. The alignment of wire groups in consecutive layers is staggered to optimise
olution for a given number of electronics channels. The radial strips are staggered
to achieve an azimuthal granularity of 2–3 mrad, as seen from the interaction point.
shows a longitudinal cut through the end-cap. TGC’s are located in the innermost
and in the middle layers (EM-wheels marked M1–M3, corresponding to TGC1–3).
the MDT in a small (S) and large sector (L) are shown for reference. The location
radial extension of the TGC wheels are given in table 6.11. A detailed listing of all
ction parameters is given in the TGC parameter book [212].

TGC Big Wheel と Endcap Inner

15 in azimuth in the inner and 7.5 in the outer part.

の 1.05 of<streamers|η| < 1.92
1.92 < |η| < 2.4 の領域をフォーワードと呼んでいる。エy quenching gas preventsTGC
the occurrence
in allの領域をエンドキャップ、
operating conditions.
EM big wheel
I layerTotal
M1 triplet
M2 doublet
M3 doublet
I doublet
ンドキャップ領域を放射状に 48 分割、フォーワード領域を放射状に 24 分割した単位はトリガーセクターと呼ばれModularity
Inner Outer Inner Outer Inner Outer Inner Outere height observed in the interaction of low energy neutrons (1–10 MeV) is only a
Modules/sector
2
4
4
2
4
larger than for a minimum
ionising particle.
ており、トリガー回路としてそれぞれ独立である。さらにエンドキャップ領域の4 21つのトリガーセクターとフォー
Units/module
1
4
5
1
5
Chambers/unit

3

3

ワード領域の2 つのトリガーセクターをあわせた単位を1/12Units/sector
セクターと呼ぶ。
2
16c field around the TGC
wires and the small
wire-to-wire distance lead to very good
Units/side24
192
for the large majority of the tracks. Only tracks at normal incidence passing midway
Units/system
48
384
Chambers/sector
648
res have much longer drift times due to the vanishing drift field in this region. This
Chambers/side72
576
dy discussed in the context of the CSC’s which have a similar cell geometry, seeChambers/system
1441152
n the TGC wheels, however, the angle of incidence for tracks emerging from the

1.2 Phase-II Upgrade

2
2
24
48
4
48
96

2
20
240
480
40
480
960

2
2
24
48
4
48
96

2
20
240
480
40
480
960

24
48

21
42

789
1578

48
96

42
84

1794
3588

新物理探索とヒッグス粒子の精密測定のため、LHC は瞬間ルミノシティを 7.5 × 1034 cm−2 s−1 に増強して高輝

All TGC units are enclosed on their periphery by a gas-tight envelope which is continuously

flushed by CO2 . This is done to keep a dry atmosphere in the region where the HV elements are
度 LHC（High-Luminosity LHC、HL-LHC）として運転を行う。このための検出器、トリガー読み出しシステム
located as well as to dilute any potential leak of the operating gas (n-pentane). If traces of thisのアップグレードを Phase-II Upgrade という。アップグレードとオペレーションのロードマップを図
1.6
flammable gas are detected in the CO2 stream at the output of the chambers,
HVに示す。
and LV as well as– 199 –

重心系エネルギーは 14 TeV になり、運転期間全体で 3000 fb−1 のデータを収集する。

gas supplies are automatically switched off, and an alarm is activated.

6.8.4 Signal
readout, and detector controls
Run 3 でパイルアップ数（1 回のバンチ交差での衝突回数）は60path,であるのに対して、高輝度化により
HL-LHC で
The data flow starting with the primary wire and strip signals is as follows. After amplification in。このような発生粒子の密度が高い環境においても、
新粒子探索や精密は 200 になる
（ATLAS Collaboration 2017）
the front-end amplifiers, signals are time-aligned and synchronised to the beam-crossing frequency.

The検出器を構成する検出器や、
subsequent signal processing makes use ofTrigger
the redundancy
the track
measurement in the
測定の性能を高く保って物理成果を上げるべく、ATLAS
andofData
AQuisition（TDAQ）システムに関わるエレクトロニクスもアップデートする。
– 201 –

2008 JINST 3 S08003

tional parameters of the TGC’s
Pick-up strip
in table 6.12.
Graphite layer
multi-wire proportional chamcharacteristic that the wire-toce of 1.4 mm is smaller than
1.8 mme distance of 1.8 mm, as shown+HV
With a highly quenching
1.4 mm
50 µm wire
CO2 and n-C5 H12 (n-pentane),
etry allows for operation in amode, i.e. with a gas gain ofrelatively low gas gain, com1.6 mm G-10
Figure 6.32: Cross-section of a TGC triplet and doublet module. The triplet has three wire layers
us implementations of the TGC
but only 図
two 1.5
strip layers.
Theとdimensions
the gas gaps（
areenlargedwith respect
tripletdoubletof の断面図
The
ATLAS
Col-to the othernot allow to make full use of Figure 6.31: TGC structure showing anodeelements.
図 1.4 TGC
（The
ATLAS
et al. 2008）
e from the primary ionisation.
wires,の構造
graphitecathodes,
G-10Collaboration
layers and a picklaboration et al. 2008）
aracteristics are still kept, even up strip, orthogonal to the wires.
Table 6.13: TGC modularity. Each wheel consists of 12 sectors, each sector containing an inner(forward) and an outer (end-cap) part, having a different azimuthal segmentation. A module coverss gain. In particular:

第 1 章 高輝度 LHC-ATLAS 実験における Level-0 Muon Trigger System

4

LHC
Run 1
LS1

7 TeV

HL-LHC

Run 2

8 TeV

Run 3
LS2

EYETS

13 TeV

splice consolidation
button collimators
R2E project

cryolimit
interaction
regions

Diodes Consolidation
LIU Installation

Run 4 - 5...

13 - 14 TeV EYETS
inner triplet
radiation limit

Civil Eng. P1-P5

LS3

14 TeV

HL-LHC
installation
2027

experimentbeam pipes
75% nominal Lumi

upgrade phase 1

nominal Lumi

2 x nominal Lumi

30 fb-1

ALICE - LHCb
upgrade2040
5 to 7.5 x nominal Lumi

ATLAS - CMS

ATLAS - CMS
HL upgrade

2 x nominal Lumi

-1
integrated 3000 fb
luminosity 4000 fb-1

350 fb-1

190 fb-1

HL-LHC TECHNICAL EQUIPMENT:
DESIGN STUDYPROTOTYPESCONSTRUCTIONINSTALLATION & COMM.

PHYSICS

HL-LHC CIVIL ENGINEERING:
DEFINITION

図 1.6

1.2.1

EXCAVATIONBUILDINGS

2021 年 1 月に更新された LHC/HL-LHC アップグレード計画（CERN 2021）

L0Muon トリガーシステム

HL-LHC での ATLAS 実験において、トリガーシステムは大きく分けて 2 段階に分かれる。TDAQ システムの全体像を図 1.7 に示す。初段は Level-0（L0）トリガーと呼ばれ、ここでハードウェアベースの高速な事象選別を行い、1 MHz のトリガーレート帯域に収まるように事象選別を行う。後段のトリガーシステムは Event Filter（EF）と呼ばれ、ソフトウェアによる精密な事象選別を行う。事象レートは最終的に 10 kHz まで落とされ、この選別をパスした事象の情報が CERN の Permanent Storage に保存される。なお現行（2022 年より開始する Run 3）ではハードウェアベースの初段トリガーレートが 100 kHz、ソフトウェアを用いた事象の記録レートが 1 kHz である。
また初段トリガー判定に使える時間を 2.5 µs から 10 µs に拡張することでより洗練されたトリガーアルゴリズムを使えるようにする。
図 1.7 にあるように、L0 トリガーシステムは L0Muon、L0Calo、MUCTPI、CTP などから構成される。本論文
は L0Muon（Level-0 Muon Trigger System）に関するものである。

HL-LHC における L0Muon は Endcap Sector Logic（Endcap SL）、Barrel Sector Logic（Barrel SL）、MDT
Trigger Processor、NSW Trigger Processor から構成される。Monitored Drift Tubes（MDT）はミューオン検出器全域（|η| < 2.7）でミューオンの運動量を精密に測定する検出器である。また New Small Wheel（NSW）はエ
ンドキャップトロイド磁石の内側に設置されたガス検出器であり、1.3 < |η| < 2.7 の範囲をカバーする。NSW

Trigger Processor は NSW のヒット情報から飛跡再構成を行い飛跡情報を Endcap SL に送る。Endcap SL は他にも PS ボードから TGC のヒット情報、RPC（BIS78）からのヒット情報、タイルカロリメータからのエネルギー
情報を受け取る。Endcap SL はこれらの情報からミューオンを検出し、飛跡再構成をして MDT Trigger Processorに渡す。MDT Trigger Processor では MDT からのヒット情報と Endcap SL からの再構成された飛跡情報をもとに、より精密な運動量測定を行い、その結果を Endcap SL に返す。最終的なミューオンの飛跡候補は Level-0

Muon Central Trigger Processor Interface（MUCTPI）へと送られる。バレル部でのトリガーは RPC、タイルカロ
リメータ、MDT Trigger Processor からの情報をもとに Barrel SL によって下され、ここでの飛跡情報も Level-0

MUCTPI へ送られる。
Front-End LInk eXchange（FELIX）は Level-0 Accept（L0A）信号を各検出器のフロントエンド回路に発行す1.4 Baseline
1.2 Phase-II
UpgradeArchitecture and Structure of the Upgrade Project

図 1.7 1.3:HL-LHC
での
TDAQ
システムの全体像（ATLAS
Collaborationof2017
FigureDesign oftheATLAS
TDAQ 実験におけるPhase-II upgradearchitecture,highlighting
the organisationthe ）Upgrade Project in three main systems: Level-0 Trigger, DAQ (Readout and Dataflow subsystems),
and Event Filter. Direct connections between each Level-0 trigger component and the Readout system are suppressed forsimplicity.
BCID
る。L0A 信号で許可されたのイベントの情報は L0 バッファからソフトウェアベースの Level-1 トリガーシ

ステムに読み出される。この段階でトリガーレートは 40 MHz から 1 MHz になる。
14

1.2.2 HL-LHC における TGC エレクトロニクス
図 1.9 に TGC エレクトロニクスシステムの概念図を示す。TGC 検出器から出力されるアナログ信号は、TGCユニットの縁に設置された Ampliﬁer-Shaper-Discriminator（ASD）ボード上の 4 つの ASIC によって増幅、波形整形、波高弁別されデジタル信号に変換される。このデジタル信号は Low Voltage Diﬀerential Signaling（LVDS）

5

第 1 章 高輝度 LHC-ATLAS 実験における Level-0 Muon Trigger System6

図 1.8A simplified
HL-LHC におけるendcap 部のL0Muon
トリガーシステム（ATLAS
Collaboration
Figure 8.4:
block diagramof theproposed
Level-0 Muon
Trigger
System2017
for ）HL-LHC.
The top and bottom parts show the diagrams for the barrel and the endcap, respectively.
M2,M3 Doublets (1/24)
62
62
64
64
64
64
64
64
60
60
64
64
64
64
64
64
64
64
64
64
64
64
64
64
212 212206 206
64 64
64 64
192 192
220 22064 6464 64

on-detector

off-detector

NSW

TILE

BIS78

6 Rx

2 Rx

2 Rx

18 PS boards
36 Rx

18 Tx and redundancy of the trigger by(see Section 8.5) is proposed to improve the robustness
Endcap:performing a combined
track
segment
reconstruction
by sTGC and
6 or 8 RxMM. MDT
GbE SW-Hub
160 ASD boards
Trigger
244
64

250
64

2 Rx
2 Tx

80 ASD boards
Forward:32 ASD boards
8 ASD boards

2 JATHubs

8.3.2 Improvementof the Trigger Performance
Total:4318 channels
M1 Triplet (1/24)
72
64

72
64

11 PS boards

6 or 8 Tx

4 Tx

Endcap
Sector Logic 1 Rx
4 Tx

Processor
MUCTPI

FELIX

22 Rx
Improvements
69 in
69 trigger performance will be achieved by increasing the detector accept11 Tx
64
64
ance, the trigger
185 185 logic,
Endcap:and the momentum resolution. The upgrade of the muon system
GbE SW-Hub
64
64
TDAQ
84 ASD boards
Ethernetstation as described in
1 Rx barrel inner
towards Phase-II
includesthe
additionofRPCs
in theserver32
ASD
boards274 274
1 Tx
64
Forward:Ref. [8.1]. By 64allowing
for coincidences of hits in the RPCs in the inner and outer stations,
21 ASD boards
1 JATHub
Ethernet
DCS
314
the acceptance64gaps4in
ASDtheboardsbarrel trigger system which are caused by the non-instrumented
1 PS board due to the presence of the structures of the barrel toroid
regions in Total:2090
the barrel
middle station
channels
ATCA Self
4 Rx
IPMI
EIL4closed.
Triplet (1/24)The expected value of the productcoils will be
and the efficiency
1 Tx of the acceptanceManager
96
96
of the muon trigger inthe barrel region is morethan 90% depending on the coincidence
6 ASD boards
GbE SW-Hub
Optical fiber
Total: 192 channels
Rx
6 ASD boards
criteria. The Barrel Sector
Logic in the new design 11includes
the coincidence
the addiCopperof
cable
Tx
1 JATHub

図 1.9

1/24 セクターをカバーする TGC エレクトロニクスシステムの概念図

181

で PS ボードに送られる。

PS ボード（図 1.10）には 8 つ1 の Patch-Panel ASIC（PP ASIC）と 1 つの FPGA が搭載されている。ここでの目的はヒット信号のタイミング調整と BCID の割り振りを行って後段の Endcap SL に送ることである。
節 1.1.1 で説明したように陽子バンチ同士は 40.079 MHz で衝突しており、LHC の各システムはこれと同期した

LHC クロックを使用している。しかし ASD からの LVDS 信号は、IP からの ToF（Time of Flight）の違いやケーブル長の違いにより、同じ衝突事象由来の信号でもタイミングが異なって到達する。PP ASIC はこのようなタイミ

1 マザーボードとドーターボードにそれぞれ 4 つの PP ASIC が搭載されている。

1.2 Phase-II Upgrade

7

ングの異なるヒット信号に遅延をかけることで、1 ns 以下の精度でタイミング調整を行い、LHC クロックと同期したヒット信号を出力する。さらにどの衝突事象由来の信号かを表す Bunch Crossing IDentiﬁcation（BCID）も各信号に割り振る。

PS ボード上の FPGA は同ボード上の QSPI フラッシュメモリに格納された FPGA ビットストリームによりプログラムされる。8 つの PP ASIC によりタイミング調整されたヒット信号はこの FPGA 内の GTX トランシーバを用いて、高速シリアル通信によって後段の Endcap SL に転送される。60 m–100 m 離れた回路室にある Endcap SL とは SFP+ コネクタを介して光ケーブルで接続される。1 つの PS ボードに対して、1 バンチ交差あたりチャンネル数

32 × 8 PP ASICs = 256 のバイナリヒット情報と、64 bit の付属する他の情報の計 320 bit を Endcap SL に送るが、シリアル通信には 8B/10B エンコーディングが行われるため転送レートは 320 bit × 10/8 × 40.079 MHz = 16 Gbpsとなる。このため 8 Gbps に対応した 2 本の光トランシーバを用いて Endcap SL にデータ転送する。Endcap SL からは同様にシリアル通信で PS ボードで用いる LHC クロックと PS ボード上 FPGA の制御信号（後述する Trigger,

Timing, and Control（TTC）信号）が送られる。PS ボードは BW の 1/12 セクターに 4 つ（M1 で 2 つ、M2 とM3 で 2 つ）設置されている PS-Pack 内に収まっている。
from/to
Sector Logic blade

PS Board for HL-LHC
Low Voltage
Mother board
ASD Vth8-ch
DAC

from/to
JATHub board

SFP+ × 3
Data
TTC signals, Control

8-ch
DAC

16-ch
ADC

LEMO

Xilinx
Kintex-7
FPGA

MonitorControl

Data bus

RJ45

Twisted-pair
Debugging

JTAG for configuration
SPI bus for SEM functionality

TTC & I2C/SPI bus

from/to Mezzanine

from/to Mezzanine

from/to Mezzanine

from/to Mezzanine

PP
ASIC

PP
ASIC

PP
ASIC

Mezzanine
ASIC cardPP

from/to Motherfrom/to Motherfrom/to Motherfrom/to Mother

PP

PP

PP

PP
ASIC

Pulse ASD 32ch TestASIC
Pulse ASD 32ch TestASIC
Pulse
ASD 32ch Test Pulse ASD 32ch TestASICVth Data
Vth Data
Vth Data
Vth Data
from/to ASD
from/to ASD
from/to ASD
from/to ASD

ASD 32ch Test Pulse ASD 32ch Test Pulse ASD 32ch Test Pulse ASD 32ch Test Pulse
Vth Data
Vth Data
Vth Data
Vth Data
from/to ASD
from/to ASD
from/to ASD
from/to ASD

図 1.10

PS ボードの簡略化した回路図

運転中の ATLAS 実験ホールは高い放射線環境となるため、PS ボード上の FPGA 内で Single Event Upset（SEU、レジスタやメモリの bit がフリップすること）が発生する。PS ボード上の FPGA には SEU を自動回復させる仕組みが搭載されるが、それでも対応できない放射線損傷を検出し回復手続きを行うのが JTAG Assistance

Hub（JATHub）である。JATHub には Zynq-7000 SoC がメインドライバとして搭載され、Linux が走り回路室とEthernet 通信をする。また、この Linux で走るアプリケーションにより JTAG 線経由の PS ボード上の FPGA のプログラムが行われる。さらに隣の JATHub の SEU の監視と回復手続きをしたり、LHC クロックの位相をモニタする機能も持つ。JATHub は BW の 1/12 セクターの外側に設置された VME クレートに収まっている。

PS ボードを通過したすべてのヒット情報が Endcap Sector Logic （Endcap SL、図 1.11）に転送される。Endcap

第 1 章 高輝度 LHC-ATLAS 実験における Level-0 Muon Trigger System

8

12

TGC
6 FireFly for receivers
4 FireFly for transmitters

12

4

12

4

MUCTPI
1 QSFP+

1212
12Virtex UltraScale+

12
12
12

NSW, RPC (BIS78), and Tile
1 FireFly for receivers

12

MDT
1 FireFly for receivers
1 FireFly for transmitters

124- Sector Logic- Readout Logic- Control- Monitoring

IPMC

AXI C2C12

図 1.11FELIX
1 QSFP+

4

12

Zynq
UltraScale+
MPSoC

Shelf Manager
IPMI

TDAQ Servers/DCS
Ethernet

Endcap SL のダイアグラム

SL はまた RPC（BIS78）、NSW、タイルカロリメータ、MDT Trigger Processor（MDT TP）といったエンドキャッ
プ部のミューオン検出器からもヒットのデータを受信し、飛跡情報を統合してトリガーを後段の Level-0 MUCTPIへ送信する。ここでの飛跡再構成には Xilinx Vertex UltraScale+ XCVU13P という大型の FPGA で、あらかじめRAM に保存された飛跡のパターン（Look-Up Table、LUT）を照合することで、複雑な計算をすることなく高速な飛跡再構成を行う。図 1.12 のように、TGC BW のワイヤーの情報から (η, ∆θ) を、ストリップの情報から (ϕ, ∆ϕ)をパターンマッチングアルゴリズムによって算出し、Coincidence Window（CW）を用いて pT の概算をする。これを MDT TP に送信し、MDT からの情報を統合したより精密な pT を受信する。最終的な飛跡情報を Level-0

MUCTP に送信し、Central Trigger Processor（CTP）でトリガー判定が下される。
実験ホールから離れた回路室には Advanced Telecommunication Computing Architecture（ATCA）クレートが6 台設置されており、そこに合計で 48 台（1 台は 1/24 セクターを担当し、A-side と C-side の 2 サイド分）のEndcap SL が収まる。回路室の放射線レベルは低いため、加速器の運転中であってもここには人員のアクセスが可能である。さらに Endcap SL は FELIX から Trigger, Timing, and Control（TTC）信号（LHC クロックやリセット信号）を受け取り、PS ボードに LHC クロックを配布する。電源投入時には ATCA shelf manager が CERN が開発した IPMI Management Controller（IPMC）を通じてボードの制御やコンフィギュレーションを行う。Endcap

SL にはまた Zynq UltraScale+ MPSoC が搭載された商用のメザニンカードを搭載し、Zynq MPSoC が XCVU13P
を含めたボード上の素子の監視と制御を行う。

1.2.3

Endcap Sector Logic における Zynq MPSoC

Endcap SL 上には Zynq MPSoC が搭載され、同ボード上の監視や制御、XCVU13P を介した前段回路へのアクセスのためのインターフェイスとなる。その機能とそのためのパスを図 1.13 に示した。本論文はこの Zynq MPSoC
に関するものである。

Zynq MPSoC は同ボードの大型 FPGA（XCVU13P）および温度センサや FireFly モジュール（光トランシーバ）などの素子の監視と制御を行う。特に XCVU13P の監視および制御には、AXI Chip2Chip という AXI4 プロトコ
ルのブリッジを用いた高速シリアル通信で、メモリからのデータ読み出しやレジスタ制御を実現する。XCVU13Pの JTAG 線を用いたプログラムや PS ボードの QSPI フラッシュメモリへのパラメータの書き込み、JATHub のブー
トファイルの書き込みなどの機能も持つ。Zynq MPSoC は Ethernet 通信により、TDAQ サーバや Data Control

System（DCS）と Endcap SL のインターフェイスとなる。
Zynq MPSoC では Linux が走り、これらの監視や制御のためのアプリケーションが動作する。この Linux は

ビーム軸

ୈ 4 ষ ߴً౓ LHC ͷͨΊͷॳஈΤϯυΩϟοϓ෦ϛϡʔΦϯτϦΨʔͷ֓ཁ

71

1.2 Phase-II Upgrade

9
ストリップパターンマッチング

ワイヤーパターンマッチングR

代表点 ID

M1

M2

M3

4

6

9

入力(=代表点 ID)
M1 M2 M3
4
4
4
4

5
6
7
8

⋮

9
9
9
9

φ

M1

M2

M3

7

6

4

代表点 IDz

出力(=飛跡情報)

η1, Δθ1
η2, Δθ2
η3, Δθ3
η4, Δθ4

入力(=代表点 ID)
M1 M2 M3

出力(=飛跡情報)

⋮

⋮

7
7
7
7

⋮

4
5
6
7

4
4
4
4

z

ϕ1, Δϕ1
ϕ2, Δϕ2
ϕ3, Δϕ3
ϕ4, Δϕ4

coincidence window
Δθ

20

0.15

18
0.1

16

Δθ2 0.05

14

0

10

12

20 GeV 8
15 GeV 6
10 GeV
4
5 GeV
2

−0.05
−0.1
−0.15
−0.03−0.02−0.01 0

0.01 0.02 0.03
Δφ

0

Δϕ3

ਤ 4.3
: ύλʔϯϚονϯάͷ֓೦ਤ. ϫΠϠʔͱετϦοϓͰಠཱʹύλʔϯϚονϯάΛߦ͍, ඈ੻を用い
図 1.12
Endcap
SL のパターンマッチングアルゴリズムとCW を用いた pT の概算（三野 2020）。LUTͷҐஔ৘ใͱ֯౓৘ใΛநग़͢Δ.
ϫΠϠʔͱετϦοϓͰ‫ٻ‬Ίͨඈ੻ͷ֯౓৘ใ͔Β,CWΛ
て飛跡の位置と角度を求め、角度情報から CW で pT 閾値を求める。
༻͍ͯ pT ᮢ஋Λ‫ٻ‬ΊΔ.

microSD カードから起動する他、QSPI フラッシュメモリや Ethernet からも起動できる。本研究ではデモンスト
レーションするための OS として CentOS 7 を採用したが、HL-LHC プロジェクト全体で使用すべき OS については CERN の IT 部門で検討されている。
この Zynq MPSoC（XCZU-5EV-FSVC784-2-I）は市販されている Mercury XU5 というメザニンカードに搭載されたものを用いる。これによりボードの開発コストを下げ、アプリケーションやファームウェアの開発や試験が別のベースボードを用いて容易になり、さらにボードと切り離せることでメンテナンスの見通しをよくした。この（Kopeliansky
メザニンカードおよび SoC は図 1.13 に示した用途や I/O 数、ATLAS 実験の DCS チームからの要求

and Schlenker 2019）や ATLAS 実験 TDAQ サブシステムにおける SoC の要求（Kopeliansky and Vandelli 2019）を満たすように考慮して選定されている。さらに将来的に冗長性、拡張性をもってソフトウェア、ファームウェア
開発ができるよう Zynq SoC ではなく現段階でミドルエンド以上の Zynq MPSoC を採用した。

第 1 章 高輝度 LHC-ATLAS 実験における Level-0 Muon Trigger System

10
Sector Logic

Mercury XU5 mezzanine card
Zynq UltraScale+ MPSoC
Processing System (PS)ARM Cortex-A53 CPU

microSD
Card Slot
TDAQ Server/DCS

RJ45
Connector (0)Ethernet PHY (0)SDIO Controller

SDRAM
Controller

Ethernet MAC (0)UART

Ethernet MAC (1)I2C Controller

PS DDR4ECC SDRAM

IPMC
SwitchBootable SDwith rootfs

USB-UART Bridge

miniUSB
Connector
External PC

20 FireFly modules
Programmable
Logic (PL)RJ45
Connector (1)Ethernet PHY (1)

SFP+ module

GMII-RGMII
Convertor
I2C multiplexer

TDAQ Server/DCS(spare)AXI SmartConnect

LEDs

VirtexUltraScale+XCVU13P

GPIO

Block RAM

Debug Bridge

Debug Bridge

図 1.13

1.3

Si5344clock jitter attenuator
Temperature sensor
for XCVU13P
Temperature sensor
for Zynq MPSoC

AXI Chip2Chip

Aurora 64B/66B

Si5345clock jitter attenuator

Debug IP

Endcap SL における Zynq MPSoC の機能の概略図

研究目的

節 1.2.3 で説明したように、Endcap SL 上の Zynq MPSoC は HL-LHC において重要な役割を担っている。本番で用いられる Mercury XU5 上の Zynq MPSoC の機能開発のため、Linux を走らせ基本的なファームウェア開発のための開発フローの確立が最優先事項である。Zynq MPSoC は組み込みシステムのコンパイルまでの手続きが煩雑で、開発の初期のハードルが高くなることも多い。さらに 2021 年 10 月に完成した Endcap SL 第 1 試作機上で正常に Linux が起動し、ボード上の素子との通信などの機能が使えることを確認する。また AXI Chip2Chip を使った高速シリアル通信といった、高エネルギー実験のエレクトロニクス制御のための機能実装と、そのデモンス
トレーションをするためのファームウェアの開発も行う。
市販品のメザニンカードと高エネルギー実験のためのフルカスタムのエレクトロニクスを組み合わせたシステムを使った初の運用例を確立し、次世代高エネルギー実験の基盤技術を切り開くことが本研究の目的である。

1.4

本論文の構成第 1 章では HL-LHC での Zynq MPSoC の役割と、そのために必要な背景知識について説明した。第 2 章ではZynq MPSoC のソフトウェアやファームウェア開発に必要な要素や手法を詳細に説明し、実機を用いて基本的な開発パスが確立したことを述べる。第 3 章では Endcap SL 第 1 試作機上の Zynq MPSoC を使って行った動作検証について説明し、第 4 章で FPGA 間高速シリアル通信のためのファームウェア開発現状について述べる。最後に第 5 章では本論文のまとめと今後の展望について説明する。本論文にとって本質的ではないが重要な情報は付録に
掲載した。

11

第2章

Zynq MPSoC を用いた組み込みシステムの開発
Mercury XU5 の Zynq MPSoC は Endcap SL や PS ボードの制御や監視を担う。そのために Zynq MPSoC で走る適切なアプリケーションソフトウェアやファームウェアが開発されるが、そのためにはまず組み込みソフトウェ
ア、ファームウェアの横断的な開発基盤の確立が必要となる。ここでは ZCU102 評価ボードや Mercury+ PE1 ベー
スボードに載せた Mercury XU5 メザニンカードといった様々なプラットフォームで Linux を SD カードからブートさせるまでを実現し、ファームウェアの合成、ソフトウェアのビルド、ブートイメージのパッケージングを含む
基本的な開発環境を構築した。これにより本番で動作するアプリケーションやファームウェアの開発および試験が容易にできるようになっただけでなく、これらの経験によって 2021 年 10 月に完成した Endcap SL 試作機のためのソフトウェア、ファームウェアの開発を素早く行うことができ、Zynq MPSoC 周辺機能の検証をスムーズに進めることができた。
節 2.1 では Zynq MPSoC とそれが搭載された Mercury XU5 メザニンカードについて紹介する。節 2.2 では

Zynq MPSoC でソフトウェアとファームウェアがどのように起動されるかを説明し、それを元に必要な開発要素
およびその作成方法を節 2.3 に示す。ZCU102 評価ボードと Mercury XU5 での Zynq MPSoC 開発例を節 2.4 と節 2.5 に説明する。また PetaLinux を用いた開発パスの参考のため、Zynq MPSoC が搭載された Ultra96-V2 というシングルボードコンピュータを用いた、FPGA による物体認識処理の高速化も試みた。Ultra96-V2 の開発については付録 B で説明している。

2.1 Zynq UltraScale+ MPSoC
プロセッサやメモリ、I/O ポートなど、システムにとって必要なパーツを 1 つのチップとして搭載したものをSystem-on-a-Chip（SoC）という。特に複数のプロセッサを搭載した SoC を MultiProcessor System-on-a-Chip（MPSoC）という。Xilinx® 社は Zynq® -7000 SoC や Zynq UltraScale+™ MPSoC を提供している。以降、Xilinx
社の Zynq UltraScale+ MPSoC を本稿では単に Zynq MPSoC と呼ぶことにする。

Zynq MPSoC の基本的なパーツを示したブロックダイアグラムを図 2.1 に示す。ここに示されているように、
Zynq MPSoC は大きく分けて Processing System（PS）と Programmable Logic（PL）の 2 つのブロックから成り立っている。

第2章

12

図 2.1

2.1.1

Zynq MPSoC を用いた組み込みシステムの開発

Zynq UltraScale+ MPSoC のブロックダイアグラム（Dzemaili 2021）

Processing System（PS）

Zynq MPSoC の PS には、Arm® 社のデュアルまたはクアッドの 64-bit Cortex® -A53 とデュアル Cortex-R5 が搭載されている。Cortex-A53 がデュアルであるかクアッドであるかや、それらの他に GPU も搭載しているかなど
によって CG、EG、EV といった Zynq MPSoC のファミリの違いとして分類される。
デュアルまたはクアッド Arm Cortex-A53 プロセッサと 2 レベルのキャッシュなどをまとめた単位のことをApplication Processing Unit（APU）と呼んでいる。APU は PS の主要部分であり、U-Boot や Linux カーネルな
どのソフトウェアは基本的に APU 上で動作する。またデュアル Arm Cortex-R5 プロセッサとその周辺機能をまとめた単位を Real-time Processing Unit（RPU）という。RPU は処理時間に特定の制限時間があるリアルタイムア
プリケーション1 に使用される。

APU や RPU の他に、PS には Xilinx 社による MicroBlaze™ プロセッサを用いた Platform Management Unit
（PMU）が備わっている。これは APU や RPU とは独立して動作する。PMU は電源投入やシステムのリセット、電源の管理、エラー通知、プロセッサ間割り込みなどの安全機能を担う。
さらにセキュアなブート、温度管理、暗号化キーの管理などのセキュリティー面の機能を担う Conﬁguration

Security Unit（CSU）が組み込まれている。

2.1.2

Programmable Logic（PL）

Zynq SoC や Zynq MPSoC はプロセッサ部（PS）とは別に内部に Field Programmable Gate Array（FPGA）を搭載しており、この部分は Programmable Logic（PL）と呼ばれている。CG、EG、EV デバイスによって違いがあるものの、基本的に PL には LUT の他に Block RAM や UltraRAM などのメモリ、高速通信のための Gigabit
1 たとえば、車のエアバッグは車両が衝突してから発動するまでの時間に厳しい制約がある。またペースメーカなどの医療機器では、シンプルな機能であっても人命に関わるものなので、処理時間が保障されている必要がある。

2.4

Figure 5: Module Top View

Top and Bottom Views

2.1 Zynq2.4.1
UltraScale+MPSoC
Top View

2.4.2

Figure 5: Module Top View

13

Figure 6: Module Bottom View(b) 裏面(a) 表面

2.4.2

Bottom View

Please（notethat depending
Bottom View図 2.2 Mercury XU5 メザニンカード
Enclustra
2019c） on the hardware revision and configuration, the moferent than shown in this document.

Transceiver（GT）などが備わっている。
2 と呼称することにPL をプログラムすることで利用できるようになる機能のことを、本論ではファームウェア
D-0000-445-001
15 / 64する。
図 2.1 にあるように、PS と PL 間のデータ転送には AXI4 が採用されている。Xilinx 社は FPGA の内部バスとしても AXI4 を積極的に採用しており、Vivado で使える IP のインターフェイスとして広く用いられている。内部
バスとして AXI4 を用いることの利点として、Xilinx 社は次のことを挙げている（Xilinx 2017）。

• AXI4 プロトコルを理解するだけで多くの IP の動作を理解でき生産性を上げることができる。
• AXI4 プロトコルには 3 種類のプロトコルが存在するため、用途に合わせてフレキシブルに応用できる。
• Xilinx 社だけでなく多くの IP ベンダーは AXI4 をサポートしているため、可能性を広げることができる。
Figure 6: Module Bottom View

2.1.3 Mercury XU5 と Mercury+ PE1
Please note that depending on the
hardware社は、
revisionXilinx
and configuration,
modulemayを搭載したハードウェアを販売
look slightly difスイスのチューリッヒに所在する
Enclustra
社や Intelthe
社のFPGA
ferent than shown in this document.

している。Enclustra 社の販売している Mercury XU5（図 2.2）は Zynq MPSoC を搭載した、51.5 mm × 54.0 mm
四辺のメザニンカードである。Mercury XU5 には Zynq MPSoC の他に DDR4 SDRAM、Kingston 製の eMMC
（embedded MultiMediaCard）、2 つの Gigabit Ethernet PHY、2 つの USB PHY、QSPI フラッシュメモリ、ユー
D-0000-445-001

15 / 64

Version 07, 25.07.2019

ザ LED などが搭載されている（図 2.4(a)）。裏面にはベースボードに接続するためのコネクタが 2 列ある。

Mercury メザニンカードのベースボードとして、Enclustra 社は Mercury+ PE1 を販売している。Mercury+
PE1 には PE1-200/300/400 の 3 種類のハードウェアがあるが、Mercury+ PE1-300 を開発に用いた。Mercury+PE1-300 の top view を図 2.3 に、ハードウェアのブロックダイアグラムを図 2.4(b) に示す。Mercury+ PE1 には Mercury メザニンカードのためのコネクタはもちろん、microSD、microUSB、Ethernet、JTAG、DC 電源な
どのためのコネクタや、ユーザ LED、ピンヘッダ、ボタン、クロックジェネレータなど多数の機能が備わっている。Mercury メザニンカードを Mercury+ PE1 にマウントすることで、シングルボードコンピュータとして利用で2 一般的に「ファームウェア」というのは ROM に書かれた書き換えできないプログラムのことを指すことが多いが、本論文では特に FPGAに組み込んだ機能のことを単に「ファームウェア」と呼ぶ。

第2章

14

Zynq MPSoC を用いた組み込みシステムの開発

きる。

Zynq MPSoC を直接ボードに搭載するのではなくメザニンカードに搭載されたものを使用することで、ボードの開発コストを下げることができる。特に DDR 通信をするメモリチップ周りの配線は高速アクセスが必要で、設計の制約が多いため一般に困難な箇所である。フルカスタムな実験では、既存のメザニンカードを使うことでこのような設計をメインボードとデカップルし、開発の難易度を下げるのは合理的である。また、高エネルギー実験の制御系のデザインでは、実験ごとの特殊な制約もゆるく、同様のデザインを異なるエレクトロニクスで再利用することも多い。その意味でも市販品のメザニンカードを活用し、メインボードのデザインから分離することは合理的である。さらに運用中に Zynq MPSoC に問題が発生した場合など、交換が容易になる。ルートファイルシステム（root ﬁlesystem、rootfs）や FPGA ビットストリームをメザニンカードではなくボード本体に搭載した SD カードに格納しておくことで、メザニンカードを交換しても以前と変わらない環境をすぐに再現できる。このように商用のメザニンカードを使用して、開発コストを下げ、メンテナンスの見通しをよくする。
Figure 6: Board Top View PE1-300/400 Variants

図 2.3

Mercury+ PE1 ベースボード（Enclustra 2019b）

2.2 Zynq MPSoC におけるブートシーケンス
Zynq MPSoC は eMMC、MMC（SD カード）、QSPI フラッシュメモリ、JTAG、USB などからのブートをサポートしている。ブートプロセスは複数の段階から成り、PMU と CSU で管理および実行される。Zynq MPSoC
で開発やデバッグを行う際、ブートシーケンスを理解しておく必要があるのでここでその説明をする。
ブートシーケンスの例を図 2.5 に示す。POR（Power On Reset）時、つまり電源を投入するとまず PMU が起動
し、PMU ROM に格納されているプリブートタスクを実行してシステムをセットアップする。これには CSU の解放が含まれている。PMU は CSU の解放後、PMU サーバーモードに移行し電力の監視を行う。

2.2 Zynq MPSoC におけるブートシーケンス

15

Chapter 7: System Boot and Configuration(a) Mercury XU5（Enclustra b）
図 2.4

PMU

(b) Mercury+ PE1-300（Enclustra a）

Mercury XU5 と Mercury+ PE1-300 のハードウェアブロックダイアグラム
Figure 16: Boot Flow Example
Release
CSU

CSU

Power
Monitoring
Load
FSBL

RPU

TamperMonitoring
FSBL

ATF

APU

U-BootLinux

Time
X18969-062421

Non-Secure Boot Flow

図 2.5

ブートシーケンスの例（Xilinx 2021b）

In non-secure boot mode, the PMU releases the reset of the configuration security unit (CSU),
and enters the PMU server mode where it monitors power. After the PMU releases the CSU
PMU によってリセットから解放された CSU は On Chip Memory（OCM）、APU、RPU を初期化し、First Stage
from reset, it loads the FSBL into OCM. PMU firmware runs from PMU RAM in parallel to FSBL
Boot Loader（FSBL
へのロード、およびオプションの
PMU（PMUFW）のrun
PMU RAM へのin OCM.
FSBL ）の
is runOCM
on APUor RPU. FSBL runs from APU/RPU
andFirmware
TF-A; U-Bootand Linux
on APU. Other
bootはユーザーがカスタマイズ可能で、電力のほかに温度管理やエラー通知などを行わせるこ
configurations allow the RPU to start and operate wholly independent of
ロードを行う。
PMUFW
the APU and vice-versa.
ともできる。FSBL は APU または RPU で、PMUFW は PMU で、それぞれパラレルに動作する。
• は
OnArm
APU,Trusted
TF-A will
be executed
after
the FSBL handsATF
off toはTF-A.
hands off to a second
FSBL
Firmware（ATF）に制御を移す。
ArmTF-A
アーキテクチャで動作するソフトウェア
stage boot loader like U-Boot which executes and loads an operating system such as Linux.
のためのセキュアな機能をまとめたものである。ATF は U-Boot などの Second Stage Boot Loader に制御を移• On RPU, FSBL hands off to a software application.
す。U-Boot はデバイスツリーの情報、カーネルイメージ、もし U-Boot に rootfs もパッケージされていればそれ• Linux, in turn, loads the executable software.
を RAM にロードする。rootfs が外部（SD カード第 2 パーティションなど）にある場合はそれを利用する。デバ
Note: The operating system manages the multiple Cortex-A53 processors in symmetric multi-processing
イスツリーとは、Linux カーネルが利用可能なハードウェアのコンポーネントをツリー状に記述したデータのこ(SMP) mode.

とである。ブートイメージに FPGA ビットストリームファイルを含む場合、U-Boot はこれを RAM にロードし、
Secure Boot Flow
RAM にロードされたFPGA ビットストリームに従って PL をプログラムする。U-Boot がブート時に読み込む環
境変数と実行するスクリプトをまとめたファイルがあるならば、それを読み込み、実行する。最後に
U-Boot はIn the secure boot mode, the PMU releases the reset of the configuration security unit (CSU) andentersthe
PMU
server
mode
where
it
monitors
power.
After
the
PMU
releases
the
CSU
from
RAM にロードした Linux カーネルに制御を移す。Linux カーネルはデバイスツリーの情報をもとにハードウェア
reset, the CSU checks to determine if authentication is required by the FSBL or the userのデバイスドライバを呼び出す。こうして起動したLinux は対称型マルチプロセッシングで動作するため複数のapplication.
The CSU does the following:• Performs an authentication check and proceeds only if the authentication check passes. Thenchecks the image for any encrypted partitions.

第2章

16

Zynq MPSoC を用いた組み込みシステムの開発

Cortex-A53 プロセッサを利用する。

2.3 Zynq MPSoC の開発手順
2.3.1 開発環境と使用するツール
一般に Zynq SoC のソフトウェアやファームウェアの開発には Windows3 または Ubuntu などの Linux がインストールされたコンピュータを使用する。Xilinx 社は Vivado、Vitis IDE、PetaLinux といった、Zynq SoC の開発に必要なツールを提供している。
Vivado® Design Suite は、Xilinx 社製の FPGA の Hardware Description Language（HDL）によるデザインの作成から論理合成（synthesis）、配置配線（implementation）、FPGA ビットストリームの生成と書き込み、デバッグまでを行うのに用いられる。Vivado ではファームウェアを作成する際、HDL によるコーディングのほかに、GUI
でダイアグラムを作ることでデザインを作成する方法があり、この場合 IP やモジュールのインスタンス化やそれら同士の接続が容易になる4 。こうして作られるダイアグラムをブロックデザインと呼ぶ。

Zynq SoC の PS で動作するソフトウェア5 は Vitis™ Integrated Development Environment（IDE）6 で作成することができる。さらにそのソフトウェアが走るプラットフォーム（APU か RPU か、APU の中でも 4 つのうち何番目の Arm Cortex-A53 を使用するかなど）を選択できたり、JTAG からのソフトウェアのブートを行うこともできる。ソフトウェア開発のため、バージョン 2019.1 までは Xilinx Software Development Kit（SDK）が用いられていたが、バージョン 2019.2 以降は Xilinx SDK は Vitis Uniﬁed Software Platform に統合され、Vitis IDE と呼ぶようになっている。

Xilinx 社の Zynq SoC で動作する Linux カーネルをクロスコンパイル7 するには PetaLinux ツール8 を用いる。
PetaLinux でも FSBL や ATF などのベアメタルソフトウェアをコンパイルできる。したがって本研究では Vitis
IDE を用いる機会はあまりなかった。PetaLinux では次のようなことができる。
• カーネルモジュールの選択、作成• U-Boot の環境変数の設定• デバイスツリーのコンパイル• 組み込みアプリケーションのクロスコンパイル• Linux カーネルのコンパイル• ブートイメージのパッケージ• カーネルイメージのパッケージ（ユーザが操作することなく自動的に行われる）
特に Zynq SoC が搭載された Enclustra 社製のデバイスを使って開発する際、PetaLinux の代わりに Enclustra

3 Vivado は自動的にディレクトリやファイルを生成するのだが、Windows ではパス名の最大長が 260 文字という制約があるため、不必要なエラーに悩まされることが多々あった。また PetaLinux は Linux しかサポートしていないので、ホスト OS として Windows を用いている場合、わざわざ仮想化マシン等を使って Linux をゲスト OS としてインストールするという環境構築の手間が増える。以上のことからホスト OS として Linux を選択することを勧める。
4 FPGA 上で動作する、ある機能をひとまとまりにしたものをモジュールといい、特に Vivado で使用可能な Xilinx が提供しているモジュールを IP という。一般に IP はユーザが設定をカスタマイズできる。モジュールを実際に使うようにすることをインスタンス化やイ
ンスタンシエートといい、そうして使えるようになったものをインスタンスという。
5 ここでソフトウェアというのは FSBL などのベアメタルソフトウェアから OS の上で走るアプリケーションまでを含む。
6 Vitis は/váItIs/のように発音される。
7 対象のプラットフォームで動作するソフトウェアを、異なるプラットフォームでコンパイルすることをクロスコンパイルという。
8 名称に Linux がついているが、これは OS ではなくあくまでクロスコンパイラであることに注意。また PetaLinux を用いてビルドしたLinux のことを PetaLinux と呼んでいる人もいるため文脈による判断が必要な場合がある。研究室内ではそのような Linux は、Zynq
Linux と呼び区別していた。

2.3 Zynq MPSoC の開発手順

17

Build Environment（EBE）を使用する選択肢もある。EBE でも PetaLinux と同じように使用するカーネルモ
ジュールの選択やコンパイルができるが、本研究室や日本 ATLAS グループでは PetaLinux を用いた開発経験が豊富であるため、積極的に EBE を使わなければいけない動機は今のところない。

2.3.2 ブートに必要なファイルと作成方法
節 2.2 に登場したファイルと制御の流れを図 2.6 にまとめた。節 2.2 で説明したように、リセット後は FSBL とPMUFW が起動し、制御は FSBL、ATF、U-Boot と遷移していく。U-Boot が Linux カーネルを起動して Linuxがブートする。図 2.6 において点線で示したファイルはオプションである。実線の矢印はその先にあるファイルをメモリにロードして制御を移すことを表しており、点線の矢印はその先にあるファイルの情報を参照することを示している（ただし devicetree blob は U-Boot によってメモリにロードされ、Linux カーネルはそのロードされた情報を参照する）。 boot.scr は U-Boot のための実行スクリプトであり、U-Boot はこれを参照して Linux カーネルをロードする。PetaLinux 2020.1 以降のバージョンでは、 boot.scr を使う。また uEnv.txt は U-Boot の環境変数の設定が書かれたファイルであり、これはユーザが編集可能である。 uEnv.txt を使うならば、U-Boot がそれを読み込むよう PetaLinux で適切に設定をする。図 2.6 では、これらのファイルを 2 つのファイルにパッケージン
グしている。ここでは PMUFW、FSBL、ATF、U-Boot、FPGA ビットストリームを BOOT.BIN というバイナリ
ファイルに、Linux カーネル、および rootfs は image.ub にパッケージされている例を示した。このパッケージの仕方はあくまで一例である。デバイスごとに異なる system.dtb を用意したいが、デバイスごとにコンパイルする
ことが困難であるという場合などは、このように image.ub から system.dtb を分離しておくことができる。ただし boot.scr 、 uEnv.txt は独立なファイルであり、 BOOT.BIN と並列に保存する。

Boot scripts for U-Bootboot.scr

environment variables
and commands for U-Boot
uEnv.txt

Boot image
BOOT.BIN

FSBL
zynqmp_fsbl.elf

reset

Arm Trusted Firmware
bl31.elf

Kernel image
image.ub

U-Bootu-boot.elf

Linux kernel
Imagerootfsrootfs.cpio.gz.u-boot

PMU firmware
pmufw.elf

FPGA bitstream
system.bit
Devicetree blob
system.dtb

FPGA programmed in PL

Linux boots in PS

図 2.6

Zynq MPSoC のブートに必要なファイルと制御の流れの例 1。ここでは rootfs を image.ub に含め、devicetree blob は含んでいない。
図 2.6 では、rootfs（ rootfs.cpio.gz.u-boot ）は PetaLinux でコンパイルしたもので、 image.ub にパッケージされている例を示した。しかし Linux カーネルが参照する rootfs のロケーションは、PetaLinux により他にも設定可能である。たとえば SD カードの第 2 パーティションに CentOS 7 の rootfs を用意し Linux カーネルがそこを参照するよう設定すれば、OS として CentOS 7 を使うことができる。そのような例を図 2.7 に示した。ここでは rootfs を image.ub に含めていない。また system.dtb は image.ub にパッケージされている。
章 3 で説明する Mercury XU5 と Endcap SL ボードでの開発には、図 2.7 のようなコンフィギュレーションを

第2章

18
Boot scripts for U-Bootboot.scr

Zynq MPSoC を用いた組み込みシステムの開発

environment variables
and commands for U-Boot
uEnv.txt

Boot image
BOOT.BIN

FSBL
zynqmp_fsbl.elf

reset

Arm Trusted Firmware
bl31.elf

Kernel image
image.ub

U-Bootu-boot.elf

Linux kernel
Image

CentOS 7 rootfs/

PMU firmware
pmufw.elf

図 2.7

FPGA bitstream
system.bit

Devicetree blob
system.dtb

FPGA programmed in PL

Linux boots in PS

Zynq MPSoC のブートに必要なファイルと制御の流れの例 2。rootfs はブートイメージ、カーネルイ

メージとは別に用意している。また devicetree blob は image.ub に含めてパッケージングしている。Endcap

SL ではこのコンフィギュレーションを採用した。

採用した。各コンピューティングデバイスは実験全体の方針に合わせて OS が一元管理されるべきであるということと、Linux ベースの OS を使用すべきという各サブシステムからの要請から、OS としては CentOS を採用する。
さらに 48 台の Endcap SL のブートに用いるファイルは同一で良いため、できるだけコンパクトにまとめられた
図 2.7 のようなコンフィギュレーションが好ましい。ただし IP アドレスといった Ethernet の設定は uEnv.txt で指定するため、このファイルだけは各 Endcap SL ボードで異なる。
以上のように、Zynq MPSoC のブートのために用意しなければならないファイルはいくつかある。そのようなファイルの作成に必要な材料、用いるツール、生成物を表 2.1 にまとめた。なお XSA というファイルは直接ブートには関係しないが、ハードウェアやファームウェアの情報を Vivado から開発フロー後段のツールに伝えるのに必要となる。XSA の説明は節 2.3.3 で行う。

fetched source code & *.xsa*.dts , *.dtsi

fetched source code & user’s conﬁguration

fetched source code & user’s conﬁguration
user’s conﬁguration(can be downloaded from a mirror site)user’s conﬁguration–

zynqmp_fsbl.elf , pmufw.elf ,ATF

devicetree blob

U-BootLinux カーネル

rootfsCentOS 7 rootfs

Boot script ﬁleU-Boot env ﬁleBoot image

Kernel image

PetaLinux/EBE

fetched source code & *.xsa

PMUFW

Image , ( system.dtb , rootfs.cpio.tar.gz )bl31.elf , ( system.bit )–fetched source code & *.xsa

FSBL

PetaLinux/EBE

PetaLinux/EBE–

PetaLinux/EBE

PetaLinux/EBE

PetaLinux/EBE

PetaLinux/EBE

Vitis/PetaLinux/EBE

Vitis/PetaLinux/EBE

Vitis/PetaLinux/EBE

system.bit

XSA

VivadoVivadoHDL ﬁles ( *.v , *.vhd , *.sv , etc.),

FPGA ビットストリーム

constraints ﬁles ( *.xdc , *.tcl )Tools used

Input

ブートに用いるファイルと作成方法

Component

表 2.1

image.ub

BOOT.BIN

uEnv.txt

boot.scr/

rootfs.cpio.tar.gz

Imageu-boot.elf

system.dtb

bl31.elf

pmufw.elf

zynqmp_fsbl.elf*.xsa

system.bit

Output ﬁle

2.3 Zynq MPSoC の開発手順
19

第2章

20

Zynq MPSoC を用いた組み込みシステムの開発

2.3.3 一般的な開発の流れ
開発ツールのバージョンは Vivado 2020.1、Vitis 2020.1、PetaLinux 2020.1 を使うことを想定する。表 2.1 に挙げた各要素について、一般的な Zynq MPSoC の開発の流れについて説明する。
まず Vivado を立ち上げ、HDL のコーディングやブロックデザインで PL のためのファームウェアを作成する。

FPGA 外部との物理制約を記述するために、拡張子 .xdc や .tcl の制約ファイル（constraints ﬁle）を作成する。
ブロックデザインの場合は Vivado が自動的に HDL ファイルを作成している。それが完成したら論理合成、配置
配線、FPGA ビットストリーム（ *.bit ）の生成を行う。この間に error や critical warning が出た場合は適宜対処する。FPGA ビットストリームの生成が完了したら、FPGA ビットストリームを含んだ Xilinx Software Archive（XSA）ファイル9 を出力しておく。これにより開発フロー後段の Vitis IDE や PetaLinux にハードウェアや FPGAの情報を伝えられる。なおこの時点で開発用コンピュータと開発ボードを Xilinx Platform Cable USB II などで繋げば、FPGA ビットストリームを用いて PL をプログラムできる。

XSA を Vitis IDE に読み込ませ、FSBL などのベアメタルソフトウェアの作成をする。この時点で、ここで作成したベアメタルソフトウェアは JTAG などを使ってメモリにロードすれば Zynq MPSoC で実行可能になる。ただし Linux をビルドする立場では、Vitis IDE での作業は不要である。

U-Boot や Linux カーネルといった Linux に関連したソフトウェアのクロスコンパイルには PetaLinux を用いる。その場合ファームウェアは U-Boot から PL にプログラムされる。新規 PetaLinux プロジェクトを作成し、

XSA を読み込ませて Linux カーネルや U-Boot の設定などを行い、 petalinux-build というコマンドでビルドする。ビルドが終わったらブートイメージをパッケージングし、 BOOT.BIN を作成する。 image.ub は PetaLinux
での設定にしたがって自動的にパッケージされる。
ここでは特に SD カードからのブートについて説明する。ボード上のブートモードを指定するジャンパーピン
や DIP スイッチを SD カードに対応する設定にすることにより、電源投入時に SD カードにあるブートファイ
ルを参照する。さらに PetaLinux でのコンフィギュレーション時に指定することで、ブートデバイスの優先順位
は boot.scr に記述される。SD カードのパーティションを 2 つに区切って、第 1 パーティションに BOOT.BIN 、

image.ub などのイメージを置き、第 2 パーティションに rootfs を構築しておく。その SD カードをボードの SD
カードスロットに挿入し、電源を投入すれば節 2.2 や節 2.3 で説明したようなフローで PL の FPGA はプログラム
され、PS では Linux が走るようになる。ボードと開発用コンピュータを USB で接続し、UART 通信でコンソー
ルを見れれば、PS で Linux が起動する様子が確認できる。起動しなかった場合でも、ブートシーケンスのどこで問題が発生したかを確認できる。
開発を進める上でファームウェアの変更やカーネルモジュールの追加などは頻繁に行う必要があるが、その度に電源を切って SD カードを抜き挿しするのは面倒である。これを避けるためにはカーネルイメージや FPGA ビッ
トストリームのファイルを更新する操作を、ネットワーク経由で Linux から行えばよい（東田 2019）。Linux カー
ネルの実態はメモリにロードされたプログラムであり、元となるファイルを変更しても、その時点で走っているプ
ログラムやファームウェアには影響は及ばない。変更を反映させるには Linux をリブートさせればよく、これはリモートでも実行可能である。ただし Linux の起動前で問題が発生したときには、直接 SD カードに書き込み直す復旧の手続きが必要になる。

9 Vivado 2019.2 以前のバージョンでは拡張子 .hdf の Hardware Description File が出力されていた。

2.4 ZCU102 評価ボードでの開発例

21

2.4 ZCU102 評価ボードでの開発例
Xilinx 社の ZCU102 評価ボード（Rev 1.1）には Zynq UltraScale+ MPSoC（XCZU9EG-2FFVB1156E）が搭載されている。この評価ボードを用いた開発の流れを以下で説明する。
ここでは PS 上で CentOS 7 を走らせ、PL には Block RAM（BRAM）と AXI GPIO を使った単純なファーム
ウェアを実装した。AXI GPIO の信号はボード上の 8-bit LEDs に繋がっていて、PL から操作できる。さらに PSと PL を接続すれば、CentOS 7 上で動くプログラムから LED を制御できるようになる。開発には Vivado 2020.1と PetaLinux 2020.1 を使用した。

2.4.1 Vivado を用いたファームウェアの作成
テンプレートとして ZCU102 を選択し、新規 Vivado プロジェクトを立ち上げた。新しいブロックデザインを開いた。
たとえば BRAM と AXI GPIO の IP ブロックをブロックデザインに追加し、AXI GPIO の IP ブロックをダブ
ルクリックして [Board interface]の設定を [dip switches 8bits]から [led 8bits]にした。ここで PS も全体のハード
ウェアデザインの一部であり、PS の IP ブロックをブロックデザインに組み込める。PS の IP コアをダブルクリッ
クすれば、PS から使用するペリフェラルの設定もここでできる（図 2.8）
。さらに [Address Editor]のタブから、PL内のモジュールの物理アドレスを指定することができる（図 2.9）。これにより PL 内の機能がアドレス空間に確保され、PS で走る Linux はここで指定したアドレスにアクセスすることにより、PL 内のモジュールを操作できる。

PL 外部とのインターフェイスポートを作成し、然るべく配線することで10 、最終的に図 2.10 のようなブロックデザインが完成した。PS と PL 間のインターフェイスには節 2.1.2 で説明した AXI というプロトコルが採用されている。図 2.10 中の AXI SmartConnect IP は AXI のマルチプレクサとして用いられている。これは AXI のマス
ターとスレーブを最大 16 : 16 で接続でき、データ幅の異なる AXI チャンネルも変換してくれる。

図 2.9 [Address Editor]のタブの例
図 2.8

Zynq MPSoC PS の設定画面の例。左のタブから、どの MIO をどのペリフェラルに割り当てるかなどを設定できる。

ブロックデザインもまた 1 つの大きなモジュールであり、実際に使えるようにするにはこれをインスタ
10 Vivado には auto connection の機能があり、それを使うこともできる。

第2章

22
zynq_ultra_ps_e_0

Zynq MPSoC を用いた組み込みシステムの開発

axi_smc
axi_bram_ctrl_0

pl_ps_irq0[0:0]

M_AXI_HPM0_FPD

S00_AXI

pl_resetn0

M_AXI_HPM1_FPD

S01_AXI

M00_AXI

BRAM_PORTA

BRAM_PORTA

rsta_busy

maxihpm0_fpd_aclk

s_axi_aclk

BRAM_PORTB

BRAM_PORTB

rstb_busy

maxihpm1_fpd_aclk

s_axi_aresetn

AXI BRAM Controller

Zynq UltraScale+ MPSoC

rst_ps8_0_99M
slowest_sync_clk
peripheral_aresetn[0:0]mb_debug_sys_rst
dcm_locked

axi_gpio_0
aclk
aresetn

M01_AXI

S_AXI

s_axi_aclk

AXI SmartConnect

aux_reset_in

Block Memory Generator

pl_clk0

ext_reset_in

blk_mem_gen_0

S_AXI

mb_reset
bus_struct_reset[0:0]GPIO

led_8bits

s_axi_aresetn
AXI GPIO

peripheral_reset[0:0]interconnect_aresetn[0:0]Processor System Reset

図 2.10 BRAM と AXI GPIO LED を用いたブロックデザインの例

ンシエートする必要がある。Vivado ではブロックデザインを保存して、[Sources]タブ上で右クリックをし[Create HDL wrapper]を選択すれば、そのブロックデザインインスタンシエートした HDL ファイルが得られる。この操作は「ラッパーをかける」と呼ばれており、ブロックデザインのファイル名が design_1.bd（HDL フ ァ イ ル design_1.v は Vivado に よ っ て 自 動 生 成 さ れ て い る ）な ら ば 、ラ ッ パ ー を か け た も のは design_1_wrapper.v として得られる。 design_1.v には Zynq MPSoC PS や BRAM などのモジュールがインスタンシエートされたモジュール design_1 が記述されており、 design_1_wrapper.v ではそのモジュー
ル design_1 がインスタンシエートされる。また LED に繋がるインターフェイスポート（図 2.10 の led_8bits）のように FPGA 外部との接続が必要ならば、FPGA Bank のピン配置などを指定した制約ファイルを作成する必要がある。

[Flow Navigator]から [Generate Bitstream]を実行すれば、論理合成、配置配線、FPGA ビットストリームの生成までを Vivado が自動的に行ってくれる。FPGA ビットストリームの生成が成功したら、[Export] →[Export Hardware]から、FPGA ビットストリームを含んだ XSA ファイルを出力する。

2.4.2

PetaLinux でのブートファイル作成

行った詳細な作業やコマンドについては付録 A でまとめることにして、ここでは PetaLinux でできることを大まかに記述する。

PetaLinux でプロジェクトを立ち上げ、Vivado で生成した XSA ファイルを読み込ませて基本的な設定を行う。
これにはブートイメージやカーネルイメージなどのパッケージングの仕方、それらをどこに格納しておくかという
ブートモードの設定（ZCU102 では JTAG、QSPI、SD の選択肢がある）、SD カードは何番を使うか、Linux 起動
時の Ethernet の IP アドレスの設定などが含まれる。
またデバイスドライバを追加したい場合など、rootfs や Linux カーネル、U-Boot の個別な設定もできる。自作の組み込みアプリケーションやカーネルモジュールのもこの時点加えることができる11 。
デバイスツリーの編集もこの時点で行う。デバイスツリーについてはソースコードを Device Tree Source（DTS）といい、コンパイルしたものを Device Tree Blob（DTB）という12 。またデバイスツリーのコンパイラはDevice Tree Compiler（DTC）といい、PetaLinux は内部でこれを用いている。ここではあらかじめ提供されている ZCU102 のデバイスツリーを使用するよう設定した。カスタムボードを使用する場合や、PL に置いたモジュー
ルを Userspace I/O から使えるようにする場合などはその情報をデバイスツリーに加える必要がある。それには11 アプリケーションについては OS 上でも開発可能で、必ずしもこの段階で加える必要はない。後述するように、Endcap SL のアプリケー

ションは主に CentOS 7 上で開発した。
12 DTS の拡張子は .dts または .dtsi 、DTB は .dtb である。

2.5 Mercury XU5 と Mercury+ PE1 での開発パスの確立

23

ユーザ編集用の DTS があるのでそれを編集する。
必要なコンフィギュレーションが済んだら、 petalinux-build というコマンドですべてのクロスコンパイルを行う。完了したら BOOT.BIN のパッケージングを行う。 image.ub のパッケージングはユーザのコンフィギュレー
ションに応じて自動的になされている。

2.4.3 SD カードからのブート
第 1 パーティションは FAT32、第 2 パーティションを EXT4 でフォーマットした SD カードを用意し、第 1 パー
ティションに BOOT.BIN 、 image.ub 、 boot.scr をコピーした。第 2 パーティションには CentOS 7 の rootfs を展開した13 。
使用した ZCU102 評価ボードを図 2.11 に示す。SD カードスロットに SD カードを挿入し、ブートモードを指定するスイッチ SW6 を適切に変更した。またデータ転送用の microUSB ケーブルで開発用コンピュータと繋ぎ、ブート時のメッセージを UART 通信で確認できるようセットアップした14 。SW1 がオフになっていることを確か
め、12 V 電源を ZCU102 の 6 ピン Molex コネクタに接続した。SW1 をオンにしたところ、制御が FSBL、ATF、

U-Boot、そして Linux カーネルと移ってゆくのがコンソール画面で確認でき、最終的に CentOS 7 のログインメッ
セージまで到達した。
デバイスツリーは ZCU102 のテンプレートを使うよう PetaLinux で設定したため（コードブロック A.1）
、LAN
ケーブルを挿せば Ethernet は使用可能な状態であった。CentOS 7 にログインし、パッケージのアップデートや必要なパッケージのインストールを行えば、Zynq MPSoC の CentOS 7 で動作するソフトウェアの開発ができるようになった。

2.4.4 PL のロジックを PS から操作
図 2.9 にあるように、PL 内の BRAM と AXI GPIO にはそれぞれ物理アドレスを割り振られている。このメモ
リアドレスにソフトウェアから /dev/mem を開きアクセスすることで、BRAM や LED を操作することができた。
詳細な説明と用いた C 言語で書いたソースコードは付録 C に残しておく。

2.5 Mercury XU5 と Mercury+ PE1 での開発パスの確立
ここでは Mercury+ PE1 ベースボードに載せた Mercury XU5 メザニンカードでソフトウェアとファームウェアを開発したことについて記す。将来的に Mercury XU5 は Endcap SL に搭載されて運用が行われるが、ここでの経験の蓄積により、Endcap SL 第 1 試作機での開発が円滑に進んだ。また本番の運用で Zynq MPSoC で動作させる
ソフトウェアやアプリケーションなどは Mercury XU5 と Mercury+ PE1 の組み合わせで行うことで開発が容易になる。
基本的には ZCU102 と同様に、Vivado 2020.1 と PetaLinux 2020.1 を用いた。またクロスコンパイラとして

PetaLinux の代わりに EBE を用いた開発パスも実現した。
Enclustra 社は 2020 年 12 月に Mercury XU5 と Mercury+ PE1 のためのリファレンスデザイン（Koeppel et al.
2020）を公開した。これを用いることでゼロから Vivado プロジェクトを作成する必要はなくなり、Vivado を用いた開発が非常に容易になった。さらに Endcap SL の Mercury XU5 とのコネクタ周りの配線は Mercury+ PE1 を
13 北陸先端科学技術大学院大学のミラーサイト http://ftp.jaist.ac.jp/pub/Linux/CentOS-vault/altarch/7.4.1708/isos/

aarch64/ から CentOS-7-aarch64-rootfs-7.4.1708.tar.xz をダウンロードし、それを第 2 パーティションに解凍した。
14 開発用コンピュータのホスト OS が Windows ならば Tera Term を使うことになるだろう。ホスト OS が Ubuntu などの Linux ならば、

screen コマンドを用いて sudo screen /dev/ttyUSB 115200 のように実行すればよい。

第2章

24

図 2.11

図 2.12

Zynq MPSoC を用いた組み込みシステムの開発

ZCU102 評価ボード

Mercury+ PE1 にマウントさせた Mercury XU5

2.5 Mercury XU5 と Mercury+ PE1 での開発パスの確立

25

参考にして設計されているため、このリファレンスデザインを起点にして開発パスを確立することで Endcap SL で2

Reference Design Descriptionの Linux のブートや機能開発といった拡張を自然に行うことができた。リファレンスデザインのブロックダイアグ
ラムを図 2.13 に示す。

Enclustra Mercury+ PE1 Base Board
Enclustra Mercury XU5 SoC Module
Xilinx Zynq UltraScale+ MPSoC
Processing System (PS)ClockGenerator

ARM Cortex-A53 CPU
USB Host/
DeviceConnector(s)USB PHY(×2)

USB
Controller(×2)

QSPI FlashQSPIController

eMMC
Flash

SDIO
Controller

UART

SDIO
Controller

SDRAM
Controller

Ethernet
MAC (0)Ethernet
MAC (1)

Micro SD
Card Slot
RJ45
Connector(0)

Ethernet
PHY (0)User
EEPROM

EEPROM

SystemMonitor

I2C
Controller

SystemController
PS DDR4ECC SDRAM

FTDI
USB
DeviceController
Micro USB
Connector

Programmable
Logic (PL)

LEDsSystemManagement

GMII-RGMII
Converter

Ethernet
PHY (1)

GPIO

SDRAM
Controller

PL DDR4SDRAM

RJ45
Connector(1)

Figure 1: Hardware Block Diagram

図 2.13

Mercury XU5 PE1 リファレンスデザインのブロックダイアグラム（Koeppel et al. 2020）

2.1

Processing System (PS)

2.1.1

Clocks

TheとPS input
clock frequency
is configured to 33.33 MHz. The CPU clock frequency is configured to its cor2.5.1 Vivado
PetaLinux
を用いたパス（リファレンスデザインの利用）

responding maximum APU clock frequency, as specified in the Zynq UltraScale+ MPSoC Data Sheet (DS925)[2]. The maximum CPU (APU) clock performance depends on the device speedgrade and package. Beside
新しく開拓したとMHz
PetaLinux
2020.1fromによる
XU5 の開発パスを図 2.14 に示す。
thatVivado
a 50 MHz2020.1
and a 100
clock are exported
PS toMercury
the PL.

HDL ファイルが共有されていれば、Vivado のプロジェクトやブロックデザインは Tcl ファイルで他人と共These clocks can be modified in the settings of the processing system in Vivado.
有が可能である。リファレンスデザインの Tcl ファイルに書かれたデバイスのプロパティを、Mercury XU5 とMercury+ PE1 に変更した。この Tcl ファイルを Vivado の [Tcl Console]で source することにより、リファレン
スデザインのプロジェクトを再現した。
D-0000-445-002
6 / 30
Version 2020.2_v1.2.0, 04.02.2021
このリファレンスデザインはそのままでも実機上で動作することを確かめた。さらにここでは自分の作成したファームウェアが実際に動作するかを確認するため、ZCU102 の場合と同様に BRAM を追加した。また提供された HDL のコードでは、Mercury XU5 上の 2 つの LED が 3 Hz と 6 Hz でブリンクするようになっていた。ここではこれを変更し、AXI GPIO で PS と接続して、ユーザが Linux から操作できるようにした。

[Generate Bitstream]を実行して論理合成、配置配線、FPGA ビットストリームの生成を行なった。こうして

FPGA ビットストリームを含んだ XSA を出力し、PetaLinux の入力ファイルとした。
PetaLinux では ZCU102 と同様にコンフィギュレーションを行なった。ただしリファレンスデザインでの PSの設定では Mercury XU5 上の eMMC と SD カードをどちらも使うようになっており、Linux のデバイスファ

第2章

26

Zynq MPSoC を用いた組み込みシステムの開発

Mercury XU5Reference Design

Ubuntu 18.04

Mercury+ PE1 (baseboard)

Vivado 2020.1

PetaLinux 2020.1

block design

1. petalinux-config
2. petalinux-build
3. petalinux-package

Mercury XU5 (mezzanine)
Zynq MPSoC

microSDSD cardslot

user logic

🚨🚨
🚨

LEDs

PL
image.ub

Generate Bitstream
Export Hardware

partition 1

partition 2(Linux kernel + device tree)

PS
CentOS 7

boot.scr(script to execute image.ub)

Xilinx Software Archive
Mercury_XU5.xsa

図 2.14

BOOT.BIN(FSBL + U-Boot + FPGA bitstream)

CentOS 7 rootfs

UART, SSH, etc

Vivado と PetaLinux を用いた Mercury XU5 の開発フロー

イル /dev/mmcblk0 は eMMC、 /dev/mmcblk1 が SD カードに対応している15 。したがってブートファイル
は /dev/mmcblk1p1 を、rootfs は /dev/mmcblk1p2 を参照するように PetaLinux でコンフィギュレーションする必要があった。
ソ フ ト ウ ェ ア の ビ ル ド と パ ッ ケ ー ジ ン グ を 行 い 、microSD カ ー ド の 第 1 パ ー テ ィ シ ョ ン に BOOT.BIN 、

image.ub 、 boot.scr をコピーし、第 2 パーティションに CentOS 7 の rootfs を展開した。ブートモードを指定する DIP スイッチを適切に設定して microSD カードを Mercury+ PE1 の SD カードスロットに挿入した。

UART 通信でコンソール画面を確認できるよう、microUSB ケーブルを開発用コンピュータを接続した。12 V 電
源プラグを挿入し電源をオンにしたところ、正常に SD カードブートが完了した。Mercury+ PE1 の RJ45 コネク
タに LAN ケーブルを接続すれば Ethernet が使え、SSH によるログインも可能となった。

2.5.2

PetaLinux の代用として EBE を用いたパス

クロスコンパイラとして PetaLinux ではなく EBE（Enclustra 2019a）を用いてビルドを行うことも可能である。

git clone したリポジトリで、 build.sh というスクリプトを走らせることで EBE が起動する（図 2.15(a)）。
ここで用いるハードウェアやブートモード、ビルドするものを選択し進んでゆく。ブートモードは SD カード
ブートを選択した。途中で FSBL、FPGA ビットストリーム、PMUFW、ATF を指定する段階がある（図 2.15(b)）
。
ここで (default path) を指定すれば、リファレンスデザインであらかじめ生成されたものが使用できる。
デ フ ォ ル ト で は out_<timestamp>_<module>_<board>_<bootmode> の よ う な 名 前 の デ ィ レ ク ト リに boot.bin 、 Image 、 devicetree.dtb 、 uboot.scr が生成される。これらを microSD カードの第 1 パー
ティションにコピーし、第 2 パーティションに CentOS 7 の rootfs を展開した。この方法でも Mercury XU5 でCentOS 7 を起動することができた。
図 2.15 の段階で、FSBL、FPGA ビットストリーム、PMUFW、ATF のバイナリファイルは (default path) を指定していた。これによりこれらの 4 ファイルはリファレンスデザインからプリジェネレートされたものを使用していた。しかし、これらを変更することでユーザが作成したファームウェアを展開することも可能であった。たとえば FPGA ビットストリームを Vivado 2019.1 で、FSBL を Xilinx SDK 2018.3 で生成したものを EBE で選択し、開発した例を図 2.16 に示す。ただし Vivado 2019.1 を用いているため XSA ではなく HDF ファイルを使って15 SD カードが /dev/mmcblk1 ならば、その第 1 パーティションは /dev/mmcblk1p1 、第 2 パーティションは /dev/mmcblk1p2 . . . のように Linux では識別される。

2.5 Mercury XU5 と Mercury+ PE1 での開発パスの確立

27(b) バイナリのカスタマイズ画面(a) EBE welcome screen
図 2.15EBE によるコンフィギュレーション

いる。また Vitis IDE ではなく Xilinx SDK を用いているが、Vitis IDE でも FSBL などのベアメタルソフトウェ
アを作成できるため、Vivado 2020.1、Vitis IDE 2020.1 を用いてもこの開発フローは成功すると考えられる。
Mercury XU5Reference Design

開発用PC

Mercury+ PE1 (Windows 10

ベースボード)メザニン)

Mercury XU5 (Vivado 2019.1

カード
スロット

SD

Xilinx SDK 2018.3

を新規作成
アプリプロジェクトをインポート
作成
操作アプリ作成

1. BSP2.
3. FSBL
4. LED

新規プロジェクト

の配線制約ファイル書き込み

1. GPIO, LED2.

Zynq MPSoC

PL
Generate Bitstream

PS

Export Hardware

CentOS 7
fpga.bit

HDF
design_1_wrapper.hdf

FSBL
FSBL.elf

my appblink_test.elf

Copy to a laptop

SSH

LaptopUbuntu 16.04
devicetree.dtb

Terminal

uboot.scr
Image
Enclustra Build Environment

モジュール、ブートモードなどを選択
FSBL, FPGA bitstreamは自作のものを選択

partiton 1

boot.bin$ (scp blink_test.elf to CentOS 7)$ (ssh login to CentOS 7)[CentOS 7] $ ./blink_test.elf 0x1

partition 2

CentOS 7 rootfs

図 2.16

EBE を用いた Mercury XU5 開発パスの例

29

第3章

Endcap Sector Logic 第 1 試作機上のMPSoC の動作検証
2021 年 10 月 18 日、2 台の Endcap Sector Logic 第 1 試作機が茨城県つくば市の高エネルギー加速器研究機
構（KEK）に納品された。私は KEK に赴き、Mercury XU5（Zynq MPSoC の FPGA のタイプは XCZU-5EV-

FSVC784-2-I）を Endcap SL にマウントさせた際のペリフェラルの試験および Xilinx Virtual Cable をはじめとするいくつかの機能の開発を行なった。以下にその詳細を述べる。
開発環境は Vivado 2020.1 と PetaLinux 2020.1 である。詳細な手順や用いたソースコードなどは https://gitlab.cern.ch/atlas-tdaq-l0tgc/soc/l0muesl に残す予定である。Zynq MPSoC と XCVU13P に実装した最終的なファームウェアのブロックデザインは付録 G にある。

図 3.1 Endcap SL 第 1 試作機にマウントした Mercury XU5 の様子。中央に見える銀色の素子が Zynq
MPSoC で、その上側に見える大きな銀色の素子が Virtex UltraScale+ XCVU13P。

第 3 章 Endcap Sector Logic 第 1 試作機上の MPSoC の動作検証

30

3.1

準備

事前準備として、Mercury XU5 と Endcap SL の回路図を確認した。Mercury XU5 のコネクタピンを介してZynq MPSoC と Endcap SL は接続されるが、それらの信号線の機能や対応関係と、初期試験時の注意事項などをまとめたスプレッドシートを作成した。たとえば UART の信号は、接続先を miniUSB コネクタにするか IPMC にするかをボード上のジャンパーピンで選択できるようになっており（図 F.2 のコネクタピン A105 および A107 を参照）、初期のテストではデバッグ用に開発用コンピュータと接続させるため、ジャンパーピンの 2と 3を接続すればよいことを確認した。他にも Zynq MPSoC のブートモードを指定するためのジャンパーピン（図 F.2 のコネク
タピン A112 および A126 を参照）も搭載されているので、どちらもオープンにしておけばよいことを事前に確認した。初期試験に必要なソフトウェアやファームウェアといった開発項目もこの段階でまとめた。
また初期のファームウェアを作成するために Mercury XU5 のリファレンスデザイン（Koeppel et al. 2020）をコピーした。リファレンスデザインのダイアグラム（図 2.13）の Mercury+ PE1 の部分を Endcap SL に置き換えた
ときに変更すべき点がないかあらかじめリストアップするつもりで双方の回路図を確認したが、実際には Endcap

SL 作成時に開発がスムーズに行えるよう Mercury+ PE1 の回路図を参照しその機能をできるだけ取り込んだため、
リファレンスデザインのほとんどの部分をそのまま使えることがわかった。PS の設定はそのまま利用し、PL のデザインは Endcap SL 第 1 試作機との接続に合わせて修正する計画にした。
図 3.1 のように Mercury XU5 を Endcap SL にマウントした後、電源を投入すると PS のブートが完了していないことを示す LED が点灯し、これをもって Mercury XU5 に電力が供給されていることを確認した。

3.2 CentOS 7 の SD カードブート
Mercury XU5 のリファレンスデザイン（Koeppel et al. 2020）を起点に、Endcap SL で走る CentOS 7 の構築を行なった。図 2.13 にあるように、リファレンスデザインとして必要な PS のペリフェラルの設定と、PL のデザイ
ン例は Enclustra 社から提供されている。最初の試験としては PS の設定をそのままコピーし、PL のロジックは消去して、新たに GPIO LED と BRAM を追加した。また制約ファイルもリファレンスデザインを参照し、PL で用いる I/O に応じて修正した。Vivado で XSA ファイルを出力し、PetaLinux で適切な設定をしたのちカーネルイ
メージとブートイメージのビルドを行なった。FAT32 でフォーマットした microSD カードの第 1 パーティションに BOOT.BIN 、 image.ub 、 boot.scr をコピーし、EXT4 でフォーマットした第 2 パーティションには CentOS

7 の rootfs を展開した。この microSD カードを Endcap SL の SD カードスロットに挿入した。また OS のブート
モードを指定するジャンパーピンを SD カードブートモードに設定し、電源を投入した。miniUSB で開発用コンピュータと接続し、シリアル通信（UART）でコンソール画面を開いて、FSBL や U-Boot の段階のブートメッセー
ジを確認した。
この時 U-Boot は Linux カーネルを mmcblk1（microSD カード）に見つけることができずに通り過ぎ、次にmmcblk0（メザニンカード上の eMMC）を探したが当然存在しないので見つけられず、制御を Linux カーネルに移すことができなかった。Endcap SL の回路図を確認すると、SD カードスロット（図 3.2）から出ている Card

Detection（CD）の信号 SDIODETが Mercury XU5 とのコネクタピン A81 に入っていたが（図 F.2）、Mercury
XU5 側では、A81 は Zynq MPSoC の FPGA Bank と接続されており、CD の MIO に対応するコネクタピンはA98 であった（図 F.1 を参照）。Endcap SL 上では A98 は何にも接続されていなかった。すなわち Endcap SL 上
では、この時点では SDIODETの信号は FPGA に入っていて、CD が確立されていないことから U-Boot はこれを見て SD カードが挿さっていないと勘違いし、eMMC に Linux カーネルを探しに行きストップしたと考えられる。
この問題に対しては、Vivado での PS の設定で MIO45 を用いた CD の手続きを無効化することで対処した

ultiplexer
+3V3D

VCC
22
23
3
1
2

SC0
SD0
SC1
SD1
SC2
SD2
SC3
SD3
SC4
SD4
SC5
SD5
SC6
SD6
SC7
SD7

SCL
SDA
RESET_B
A0
A1
A2
GND

21

+3V3D

+3V3D

+3V3D

+3V3D

+1V8D

+1V8D

+1V8D

+1V8D

+3V3D

+3V3D

+3V3D

D

+3V3D

R122

R123

R124

R125

R126

R127

R128

R129

R130

R131

R132

R133

R134

R135

4.7K

4.7K

4.7K

4.7K

4.7K

4.7K

4.7K

4.7K

4.7K

4.7K

4.7K

4.7K

4.7K

4.7K

24

+3V3D

U23

+3V3D

5
4
7
6
9
8
11
10
14
13
16
15
18
17
20
19

3.3 Gigabit Ethernet の開通

FIRSCLFIRSDAFSFPSCL
FSFPSDA

31

SISCL
SISDA
SI44SCL
SI44SDAFPTMPSCLFPTMPSDAZYTMPSCLZYTMPSDA（図 3.3）。すなわち U-Boot は CD 信号線のレベルによらず、SD カードが挿さっているものと解釈して、Linux
カーネルを SD カードに探しに行きブートを開始する。ブートファイルを作成し直して、SD カードをアップデー
C

TCA9548APWR

12MONSCLMONSDAトしたところ、無事 CentOS 7 が起動した。

microSD connector

+3V3D

C381
0.1U

+3V3D

+3V3D

R138

SDD0
SDD1
SDD2
SDD3
SDCMD

10K

SDCLK

R139

7
8
1
2
3
5

B

CN56

4

+3V3D

VDD

R136
4.7K

DATA0
DATA1
DATA2
DATA3
CMD
CLK

1.1K

VSS

+12V0D

6

+1V8D

SH5
SH4
SH3
SH2
SH1
DETECT
SWITCH

15
14
13
12
11
10
9

R137
4.7K

SDIODET

5031821852

A

図 3.2 microSD カードスロット
Title
Size
A3
Date:
3

Endcap Sector Logic
MPSoC Peripherals 2
Document Number<Doc>
Saturday, May 01, 2021

2

Rev
<RevCode>
Sheet

42

of

図 3.3 Vivado で CD の機能を無効化

501

後日、図 3.4 のように A81 と A98 のピンを導線でジャンパー接続したところ CD を有効にしたままでも SD
カードブートが成功した。

図 3.4

メザニンとのコネクタピン A81 と A98 を接続した様子

3.3 Gigabit Ethernet の開通
Mercury XU5 のリファレンスデザインを参考にして、Endcap SL 上で Gigabit Ethernet を開通させた。図 2.13にあるように、Mercury XU5 には Ethernet PHY が 2 つ搭載されていて、1 つは PS 領域の MIO に接続されている。もう 1 つは PL 領域のユーザ I/O に接続してあり、EMIO を介して PS の Gigabit Ethernet Controller に接続されている。PL 内で GMII-to-RGMII convertor を介して PS と接続すれば使用可能である。Endcap SL にはこれ

5

4

B

MPSoC/Peripherals 3

PCLK_P
PCLK_N
VOUT
IO_P
IO_N
IO_P
IO_N
GND
IO_P
IO_N
IO_P
3
IO_N
GND
I2C_SCL
I2C_SDAI2C_INT#
JTAG_TDIJTAG_TMS
JTAG_TDO
JTAG_TCKGND
USB_DP
USB_DM
VBUS_HDP
ID_HDM
GND
USB_SSRX_P
GND
USB_SSRX_N
GND
ETH0_D_N
ETH0_D_P
ETH0_LED1#
ETH0_C_N
ETH0_C_P
ETH0_CTREF
ETH0_B_N
ETH0_B_P
ETH0_LED2#
ETH0_A_N
ETH0_A_P
GND

85
87
89
91
93
95
97
99
101
103
105
107
109
111
113
115
117
119
121
123
125
127
129
131
133
135
137
139
141
143
145
147
149
151
153
155
157
159
161
163
165
167

JP2

SDCLK
SDCMD
SDD0
SDD1

1
2
3

2

1

SOLUAI2ZSOLUAZ2I

3

microSD cdata & co

JPSW3

SDD2
SDD3
2

1

JP4
I2C0SCL
I2C0SDA

1
2
3

2

JTAGTDIJTAGTMSJTAGTDOJTAGTCK

1

I2C maste

ZYUARTRXZYUARTTX

3

JTAG slav
from exte

JPSW3

第 3 章 Endcap Sector Logic 第 1 試作機上の MPSoC の動作検証

C385 0.1U
C389 0.1U

SHIELD1SHIELD2

TRD1+
TRD1TRD2+
TRD2TRD3+
TRD3TRD4+
TRD4-

11
10
4
5
3
2
8
9

PSETHAPPSETHANPSETHBPPSETHBNPSETHCPPSETHCNPSETHDPPSETHDN

0826-1A1T-23-F

15
16

17
18

TRCT1
TRCT2
TRCT3
TRCT4

GLEDGLED+

12
6
1
7

C384 0.1U

YLEDYLED+

13
14

560

CN58

C383 0.1U

+3V3D

169

A
R142
560

TAB

ZYEHLEB1
R141

560

PSETHAPPSETHANCN57
ZYEHLEA2
126 TRCT1
PSETHBN
1 TRCT2
PSETHBP
7 TRCT3

Gigabit Etherne
for DCS & TDAQ

1314ZYEHLEA1R140DUART for+3V3D

C386 0.1U
C387 0.1U
C388 0.1U

YLEDYLED+

+3V3D

TRD1+
TRD1TRD2+
TRD2TRD3+
TRD3TRD4+TRD4-PSETHCP17
PSETHCN
18 SHIELD1SHIELD2ZYEHLEA1
PSETHDN
PSETHDP

11
10
4
5
3
2
8
9

PLETHAPPLETHAN
PLETHBP
PLETHBNPLETHCPPLETHCN
PLETHDPPLETHDN

Gigabit Ethernet
for DCS & TDAQ server

TRCT4C390 0.1U

GLEDGLED+

RJ45 connector
for GbE

0826-1A1T-23-F

15
16

32

+3V3D
C

R143
560

2020302

FX10A-168P-SV(71)

信号順変更

ZYEHLEA2ZYEHLEB2(a) Endcap SL 上の ETH0 用 RJ45 コネクタ(b) Endcap SL 上の Mercury XU5 とのコネクタ A の ETH0 に関する部分

BridgeEndcap SL 上の ETH0 用 RJ45 コネクタと MercuryUSB-UART
XU5 とのコネクタ
A の ETH0 に関する部分。
(a) RJ45 コネクタから 4 本の信号線が Mercury XU5 とのコネクタに延びている。(b) Mercury XU5 から見て

図 3.5

ZYUARTRXD6ZYUARTTX

ID
D_P

4

2

3

3

2

4

1

5

25

23

22

RXD_I

RTS_O_B

CTS_I_B

26

RI_I_B

24

1
+3V3D

TXD_O

5

27

GND

U25

BLM18KG601SH1D

DSR_I_B

9
8
7
6

CN59

SHLD4
SHLD3
SHLD2
SHLD1

L45

DTR_O_B

SP0503BAHTG

A、B、C、Dのピンに D、C、B、Aの順番でスワップされている。

29

3

28

2

5

DCD_I_B

4

CNR_GND

1

GND1

NC5

D+

GPIO0

D-

GPIO1

VIO

GPIO2

図 C.1

21
20
19
18

Mercu
B

17
16
15

14

NC3

NC4
NC2

NC1

10

GPIO3

13

REGIN

9

C393
1U

8

C392
0.1U

SUSPEND

C394
0.1U

3.3.1 スワップされた配線の問題と PS Ethernet（ETH0）の開通
R144
4.7K

12

USB Connector

VDD

11

7

C391
0.1U

RST_B

6

690-005-299-043

VBUS

VBUS

SUSPEND_B

ら 2 つの Ethernet のインターフェイスとして RJ45 コネクタが 2 つ搭載されている。
D_N

NC6

4

CP2103-GM

図 2.13 のようなリファレンスデザインの PS の設定を用いたので、そのままでも PS Gigabit Ethernet（ETH0）
は使えるはずであったが、Endcap SL 第 1 試作機で試験したところ想定通りに動作しなかった。
C395
1U

L46 BLM18KG601SH1D

A

C396
0.1U

図 3.5(a) の RJ45 コネクタを介した LAN ケーブルからの 4 線の信号 A、B、C、D （さらにそれぞれ Pと Nの極
Title

Endcap Sector Logic性があるため合計で 8 本）は、図 3.5(b) または図 F.2 に示したように、Endcap SL 上では Mercury XU5 とのコネ
Size
A3

MPSoC Peripherals 3

Document Number<Doc>

クタ A145 から A165 の奇数列に接続されている。ここでは Mercury XU5 から見て A、B、C、Dのピンに対して
Date:

5

4

3

Friday, March 12, 2021

2

Sheet

43

1

D、C、B、Aの順番で接続されており、これが動作不良の原因であった1 。
。混線
そこで応急処置的に、Aと D、Bと Cを LAN ケーブル内でスワップさせておいたものを自作した（図 3.6）や断線がないことを両端のコネクタで確認したのち、Endcap SL と開発用コンピュータを接続したところ、無事に

PS Gigabit Ethernet のリンクが確立し、SSH によるログインなどが可能となった。後日、正式な道具を用いてこのようにスワップさせた LAN ケーブルをいくつか作製した。Endcap SL 第 2 試作機ではこの配線を修正することにし、第 1 試作機についてはスワップさせた独自の LAN ケーブルを用いてこれに引き続く試験を行った。

KEK に申請して固定の IP アドレスを取得し、Zynq MPSoC をネットワークに接続した。IP アドレスや MAC
アドレスは、UART 通信でログインし、CentOS 7 の NetworkManager Text User Interface（ nmtui コマンド）を用いることで設定した2 。また PetaLinux でのコンフィギュレーションの段階で、これらの設定を行うこともできる。また後述するように uEnv.txt を用いた IP アドレスと MAC アドレスの指定も可能で、ETH1 の開通後に uEnv.txt を使って設定することにした。

ETH0 が開通したことにより、パッケージのアップデートや、リモートでのアクセスもできるようになった。

1 Mercury XU5 に搭載されている 2 つの Ethernet PHY（KSZ9031RNX、
https://ww1.microchip.com/downloads/en/DeviceDoc/

00002117G.pdf）には、LAN ケーブルのストレートとクロスオーバーのタイプの差を吸収するべく auto MDI/MDI-X の機能がついている。これにより A-B、C-D間のスワップは正しくマップされ直すが、このようなスワップ（A-D、B-C）には対応していなかった。
2 NIC に関する設定ファイルは、Linux では /etc/sysconfig/network-scripts/ 配下に cfg-eth0 のようなファイル名で生成されている。CentOS 7 ではこれらのファイルを直接編集するよりも、 nmtui を用いて設定することが推奨されている。

Rev<RevCode>of50

3.3 Gigabit Ethernet の開通

(a)
図 3.6

33

(b)

(c)

内部で信号線をスワップさせた LAN ケーブルを作製した。(a) 一般的にストレートケーブルであるか

クロスオーバーケーブルであるかは、両端のコネクタを見て、中の導線の色の並びを確認すればわかる。Endcap

SL に用いられている RJ45 コネクタは、コネクタの端から端までを順に A、B、C、Dと定義していたので、ここでは A-D、B-Cのスワップをすべく最両端の色同士（橙色と茶色）、その 1 つ内側の色同士（青色と緑色）をスワップさせることにした。(b) LAN ケーブル中央付近で切断し、被覆した様子。(c) 橙色と茶色、青色と緑色
をハンダで接続し、触れ合わないようにビニールテープを巻いておいた。後日正式な道具を用いて、このようにスワップさせた信号線をかしめた独自の LAN ケーブルを作成した。

3.3.2 PL Ethernet（ETH1）の開通
Ethernet PHY 1 は PL 領域の EMIO と接続されており、PL 内で GMII-to-RGMII convertor を用いることにより使用できる。Xilinx 社は Vivado の IP として GMII-to-RGMII convertor を提供しているが、Mercury XU5 には使えず、Enclustra 社が提供するモジュールを使う必要があった（Koeppel et al. 2020）。 再び FPGA ビットスト
リームを生成し、XSA ファイルを出力、PetaLinux にてブートファイルをビルドし直し起動した。

ETH1 が開通したことを開発用コンピュータとの Peer-to-Peer 通信ができることをもって確認した。ただし ETH1 の基盤上の配線も節 3.3.1 の ETH0 と同様に問題があったため、中の配線をスワップさせた独自のLAN ケーブルを使った。しかし、 uEnv.txt を使わないまま ETH1 が開通すると、ETH0 の MAC アドレ
スや IP アドレスがランダムに上書きされてしまうことがわかった。これを避けるため ETH0/1 の MAC ア
ド レ ス は uEnv.txt に 記 述 し て 設 定 す る よ う に し た3 。U-Boot が uEnv.txt を 参 照 す る よ う に boot.scr を
変 更 す る 必 要 が あ る が 、 boot.scr は バ イ ナ リ を 含 む フ ァ イ ル で あ る た め 、単 純 に テ キ ス ト エ デ ィ タ な
ど で 編 集 し た だ け で は 機 能 し な い こ と が わ か っ て い る 。こ れ を 変 更 す る に は PetaLinux プ ロ ジ ェ ク トの project-spec/meta-user/recipe-bsp/u-boot/u-boot-zynq-scr/boot.cmd.default.initrd を編集してビルドををすれば適切な boot.scr が生成される。
適切な uEnv.txt を準備することで、ETH0 に関しては起動時に指定の IP アドレスが設定された。ETH1 に関しては MAC アドレスは uEnv.txt に書かれたように設定され、IP アドレスは CentOS 7 の rootfs から nmtui などのコマンドを使って設定した。
3 FSBL やデバイスツリーで MAC アドレスや IP アドレスを指定しても、U-Boot はそれらを上書きしてランダムに割り振ってしまう。しかし U-Boot は uEnv.txt の環境変数を参照するので、MAC アドレスや IP アドレスはここに書くのが一番確実であると考えられている。

第 3 章 Endcap Sector Logic 第 1 試作機上の MPSoC の動作検証

34

3.4 I2 C 通信プロトコルによる clock jitter attenuator の設定
5

4

3

2

1

SL には Si5345 jitter attenuating clock multiplier（図 3.7）が搭載されており、これがボード上の Zynq MPSoC
Clock/Clock from TTC

や XCVU13P のシステムクロックやリファレンスクロックの起点となっている。2027 年からの本番の運用では160.316 MHz Clock for
GTY CDR (Bank132)GTRECLKP/N）が主な入力となる
TTC から配布され再構成した 40 MHz の LHC クロック（図3.7FPGAのポート
0の
D

D

+3V3D

が、オンボードの 40.079 MHz テスト用水晶発振器のクロック（ポート 1）や外部クロック（ポート 2）も利用可能
X1

1
2
3

である。

NC

VDD

OE

CLKB

GND

CLK

+3V3D

+3V3D

C1

C2

10U

0.1U

6

5

GTOSCCLN

4GTOSCCLP

590BD-BDG (160.316 MHz)SIIN1B

SIIN2B

C3
0.1U/1005

C4
0.1U/1005
+3V3D

FL1
NFM18PS105D0J3D
1
3

C

2

C

+1V8D

+1V8D

63
64

C7

OUT9

0.1U/1005

0.1U/1005

B

OUT9B

C8

0.1U/1005

C9

SIIN1B
0.1U/1005

OSCCLKR2
100/1005

EXTCLK

SIIN2B

1
2
14
15
61
62

C10
X2

0.1U/1005

2
4

GND XTAL1
GND XTAL2

7
8
9
10

1
3

CX3225SB48000D0FPJC

11
39
16
18
17
19
6

SISCL
SISDA
SIRST

13

22
26
29
33
36
40
43
49
52
57

IN_SEL0
IN_SEL1

OUT0
/OUT0
OUT1
/OUT1

IN0
/IN0

OUT2
/OUT2

IN1
/IN1

OUT3
/OUT3

IN2
/IN2

OUT4
/OUT4

IN3
/IN3

OUT5
/OUT5

X1
XA
XB
X2

OUT6
/OUT6

/OE
I2C_SELSCLK
SDA/SDIO
A1/SDO
A0//CS
/RST

OUT7
/OUT7
OUT8
/OUT8
OUT9
/OUT9

RSVD1
RSVD2
RSVD3
RSVD4
RSVD5

/INTR
/LOL

24
23

ZYSYCLPZYSYCLN

28
27

System Clock for MPSoC PL

GTCLFOP1GTCLFON1

31
30

Input for Clock Fanout Buffer 2

ZYGTCLPZYGTCLN

35
34

MGT Reference Clock for MPSoC PL

GTCLFOP0
GTCLFON038
37

Input for Clock Fanout Buffer 1

FPSYCLP3FPSYCLN3

42
41

System Clock for FPGA BANK 70-71

FPSYCLP1FPSYCLN1

51
50

System Clock for FPGA BANK 65-66

FPSYCLP0FPSYCLN054
53

CLKOTEST

59
58

OUT9
OUT9B

System Clock for FPGA BANK 61-63
R3 18/1005

CLKOTEST1247

B

System Clock for FPGA BANK 73-75

FPSYCLP2FPSYCLN24544

信号順再変更C11

1U/1005
1

SIINTR
SILOL

CN1
142-0701-201

2
3
4
5

CLKOUT

Si5345B-D-GM

65

5
20
21
55
56

VDDA

3
4

INSEL0
INSEL1

VDDO0
VDDO1
VDDO2
VDDO3
VDDO4
VDDO5
VDDO6
VDDO7
VDDO8
VDDO9

R1
100/1005

C6

FINC
FDEC

GND

0.1U/1005

GTRECLKN

U1

60
46
32

48
25

VDD
VDD
VDD

20210316
C5GTRECLKP

A

A

+1V8D

+1V8D

+1V8D

C12

C13

C14

1U/1005

1U/1005

1U/1005

+1V8D

+1V8D

+1V8D

図 3.7

+1V8D

+1V8D

+1V8D

+1V8D

+1V8D

+1V8D

+1V8D

Endcap SL 上の Si5345 clock jitter attenuator

C15

C16

1U/1005

1U/1005

C17

C18

C19

C20

C21

C22

C23

C24

1U/1005

1U/1005

1U/1005

1U/1005

1U/1005

1U/1005

1U/1005

1U/1005

Endcap Sector Logic

Title

CLK_TTC

Size
A3
Date:

5

4

3

Document Number
<Doc>

Rev
<RevCode>

Tuesday, March 16, 2021

2

Sheet

3

of

50

1

Zynq MPSoC PS の I2 C 用 MIO は、図 3.8 の TCA9548A I2 C channel multiplexer（I2 C MUX）を介して Si5345と I2 C の信号線で繋がっている。この I2 C MUX は他にも FireFly モジュール、SFP+ コネクタ、Zynq MPSoC とXCVU13P の温度センサ、Si5344 とも接続されている。ユーザは Zynq MPSoC PS で走るソフトウェアからこれらの I2 C デバイスにアクセスし、それらのステータスの監視やコンフィギュレーションを行う。Linux からの I2 C
デバイスの詳細なアクセス方法は付録 D に譲り、ここでは 40.079 MHz のテスト用水晶発振器の入力クロックから
5

4

3

2

1

XCVU13P の MGT Bank に供給する 240.474 MHz のクロックを出力ポート 1 と 3 から出力する設定について、簡単に述べる。
MPSoC/Peripherals
2

I2C Multiplexer
+3V3D

+3V3D

R213

R120

R121

4.7K

4.7K

4.7K

+3V3D

C379
10U

+3V3D

+3V3D

C380
0.1U

VCC

U23

22
23

I2C0SCL
I2C0SDA

3

I2C0RST

1
2

SC0
SD0
SC1
SD1
SC2
SD2
SC3
SD3
SC4
SD4
SC5
SD5
SC6
SD6
SC7
SD7

SCL
SDA
RESET_B
A0
A1
A2
GND

21

+3V3D

+3V3D

+3V3D

+3V3D

+1V8D

+1V8D

+1V8D

+1V8D

+3V3D

+3V3D

+3V3D

D

+3V3D

R122

R123

R124

R125

R126

R127

R128

R129

R130

R131

R132

R133

R134

R135

4.7K

4.7K

4.7K

4.7K

4.7K

4.7K

4.7K

4.7K

4.7K

4.7K

4.7K

4.7K

4.7K

4.7K

5
4
7
6
9
8
11
10
14
13
16
15
18
17
20
19

MONSCLMONSDAFIRSCLFIRSDAFSFPSCL
FSFPSDA
SISCL
SISDA
SI44SCL
SI44SDAFPTMPSCLFPTMPSDAZYTMPSCLZYTMPSDAC

TCA9548APWR

12

図 3.8

+3V3D

24

+3V3D

Endcap SL 上の TCA9548A I2 C channel multiplexer

Monitoring of on board power by 3V3D
microSD connector+3V3D

まず PetaLinux のプロジェクトで必要な I2 C デバイスドライバが有効になっていることを確認した。I2 C MUX
+3V3D

C381
0.1U

についての情報を付録 D のコードブロック D.1 のようにデバイスツリーに記述して、Linux カーネルが I2 C MUX
C382
0.1U

+3V3D

11
10
12

PWM

V1
V2
V3
V4
V5
V6
V7
V8

1
2
3
4
5
6
7
8

LTC2991CMS#PBF+1V8D+12V0D

R138
10K

R139
1.1K

+3V3D

R136
4.7K

SDD0
SDD1
SDD2
SDD3
SDCMD
SDCLK

7
8
1
2
3
5

B

+3V3D
CN56
DATA0
DATA1
DATA2
DATA3
CMD
CLK

4

+1V2A

VDD

16

SCL
SDA

+0V85D +0V9A

VSS

MONSCLMONSDA

U24
ADR2
ADR1
ADR0

GND

15
14
13

VCC

+3V3D

SH5
SH4
SH3
SH2
SH1
DETECT
SWITCH

15
14
13
12
11
10
9

5031821852

R137
4.7K

SDIODET

3.5 Xilinx Virtual Cable を使った FPGA のデバッグおよびプログラム

35のデバイスを検知できるよう設定した。ブートファイルのコンパイルを行ったところ、CentOS 7 から Si5345 のデバイスファイルが /dev/i2c-4 として見えていることをブートログや i2c-tools というパッケージを用いて確認した。 /dev/i2c-4 は外部デバイスである I2 C ポートへの入出力のためのスペシャルファイルであるが、自動的に割り当てられるスペシャルファイル名は PS の再起動などで変わらないことを確認した。

Si5345 はその内部に多数のレジスタをもっており、I2 C でレジスタの値を読み書きすることでコンフィギュレー
ションや監視ができるようになっている。そのレジスタ数は膨大であるため4 、SkyWorks 社はユーザフレンドリーな Si53xx 設定用アプリケーション ClockBuilder Pro 5 を提供している。このアプリケーションを用いて入力ポー
ト 1 の 40.079 MHz のクロックを受け、出力ポート 1 と 3 から 240.474 MHz のクロックを生成するよう設定した。
さらに ClockBuilder Pro には、このような設定を実現するのにコンフィギュレーションしなければならないレジス
タのアドレスと書き込むべき値が書かれたリストを、を CSV 形式やヘッダーファイルの形式（ .h ）で出力する機能がある。

Si5345 のデバイスファイルが /dev/i2c-4 であることがわかり、レジスタのリストも手に入れたので、このヘッダーファイルをインクルードして I2 C で書き込むプログラムを C 言語で作成した6 。これを Zynq MPSoC で走る

CentOS 7 上で開発とコンパイルし実行したところ、設定通りに出力クロックが出ていることをオシロスコープのプローブを当てて確認した。

3.5 Xilinx Virtual Cable を使った FPGA のデバッグおよびプログラム
Xilinx Virtual Cable（XVC）の機能を用いることで、リモートでの Zynq MPSoC PL のデバッグや XCVU13Pのデバッグおよびプログラムができるようになった。

XVC は TCP/IP 通信を JTAG の信号に変換することで、ネットワーク越しに Xilinx 社のデバイスをプログラムやデバッグする機能のことである。通常、Xilinx 社の FPGA をプログラムしたりデバッグしたりするには、開発用
コンピュータと対象のデバイスを専用の JTAG ケーブルや USB ケーブルで繋いで行うが、XVC を用いることでそのような手間が省け、インターネットを経由し世界中どこからでも FPGA のデバッグコアインターフェースにアクセスすることができるようになる。

XVC の機能を実装するにあたって必要な要件として次のことが挙げられる。
• Zynq SoC と対象の FPGA のテストアクセスポートが JTAG の 4 線で接続されていること• Zynq SoC で XVC サーバが起動していること• 開発用コンピュータと Zynq SoC がネットワーク的に接続可能であること• その開発用コンピュータに Vivado がインストールされていること
Endcap SL 上で Zynq MPSoC と XCVU13P は JTAG の 4 線で接続されており（図 F.3 の B75、B77、B81、B83に接続されている 4 本）、また節 3.3 で述べたように Ethernet のパスが開通したので、あとは PL 内で TCP/IP の
信号を JTAG 信号に変換する準備をし、Zynq MPSoC で動作する XVC サーバアプリケーションを作成すればよかった。
同研究室内で Zynq-7000 デバイスを用いた XVC の経験があり（東田 2019; 田中 2021）、基本的な開発の流れや使用方法はこれらを参考にした。ただし先行研究では Xilinx 社の提供しているモジュールを変更したものを用いて
4 「ページ」が 9 あり、それぞれにレジスタが 256 個あるため単純計算で 9 × 256 = 2304 のレジスタがある。ただし read-only のレジスタも含まれているし、そのすべてが使用できるわけではない。ページについては付録 D.4 を参照のこと。
5 https://www.skyworksinc.com/en/application-pages/clockbuilder-pro-software から入手できる。ただし Windows しかサポートしていないため注意。開発用コンピュータのホスト OS が Linux であれば Wine を使うことでエミュレートできるかもしれない。
6 ただし Si5345 特有のアクセスの仕方があったため、その説明は付録 D.4 に書いておく。

第 3 章 Endcap Sector Logic 第 1 試作機上の MPSoC の動作検証

36

おり、Vivado で使用できる IP は使っていなかった。さらに Zynq MPSoC と JTAG で接続された FPGA をプログ
ラムする手法はまだあまり知られていないことからここにその知見を残しておく。

3.5.1

Zynq MPSoC PL のデバッグ

まず XVC で Zynq MPSoC が自分の PL にある FPGA を、ILA などを用いてデバッグできるような仕組みを開発した。ここでいうデバッグとは、通常 JTAG ケーブルを用いて利用するデバッグコア（ILA、VIO、IBERT など）を用いたデバッグのことを指す。本節で述べるように、Debug Bridge という IP コアをカスケード接続し、PSでのソフトウェアのコマンドをデバッグコアインターフェイスに接続し実現する。Xilinx 社は Zynq MPSoC 用の

XVC のチュートリアル（anunesgu 2021）を提供しているので、基本的にはそれをフォローした。
Target SoC

図 3.9

Debug IP(e.g. ILA, VIO etc)
Debug IP(e.g. ILA, VIO etc)

BSCAN

Debug Hub

AXI

Debug Bridge(From BSCAN to DebugHub)

PL

Debug Bridge(From AXI to BSCAN)

TCP/IP

XVC server

PS

Zynq MPSoC の PL をデバッグする際の XVC の構成

Zynq MPSoC が自身の PL をデバッグする際の構成図を図 3.9 に示す。ブロックデザインに Debug Bridge という IP を 2 つ追加し、1 つ目は [From AXI to BSCAN]、2 つ目は [From BSCAN to DebugHub] というモードにした。1 つ目の AXI のポートは PS と繋がっている AXI SmartConnect に繋ぎ、1 つ目と 2 つ目の BSCANのポートを接続した。1 つ目の Debug Bridge は PS から来る XVC コマンドを AXI4-Lite で受け取り、JTAG

Boundary Scan（BSCAN）というインターフェイスで Debug Hub にそれを伝える。Debug Hub7 というのは FPGAの BSCAN と Integrated Logic Analyzer（ILA）や Integrated Bit Error Ratio Test（IBERT）などのデバッグコ
アのインターフェイスとなる Vivado コアである。今回はテスト用に PS が出す 100 MHz の PL クロックで動作する 6-bit counter の出力を図 3.10 のように ILA で確認するようにした。ちなみに [From AXI to BSCAN]モードと[From BSCAN to DebugHub]モードの 2 つの Debug Bridge に対して、ILA などのデバッグコアは複数あってよいことが経験的にわかっている。
このブロックデザインを保存し、FPGA ビットストリームと XSA を生成した。
以降の操作の詳細は付録 E に書き、ここでは大まかな流れについて説明する。Linux が Userspace I/O（UIO）として Debug Bridge を検出できるよう、デバイスツリーにその情報を追加し、UIO を使えるようにデバイスドラ
イバを追加した。 bootargs （OS 起動時、U-Boot のカーネルコンソールに渡される環境変数）も編集し、ビルドを行った。CentOS 7 を起動すると、 /dev/uio0 が debug_bridge に割り当てられた。

XVC サーバアプリケーションのソースコードを準備し（詳細は付録 E.2）、それを Zynq MPSoC の CentOS 7 に転送してデバッグやコンパイルを行った。これを実行させた状態で、開発用コンピュータの Vivado で Hardware

Manager を開き、Zynq MPSoC の IP アドレスと XVC サーバ用のポートを入力したところ、 debug_bridge_0 が

7 Debug Hub コアはユーザ定義ではない層でインスタンシエートされ、2 つ目の [From BSCAN to DebugHub]モードの Debug Bridge とILA はその層で Debug Hub コアを介して接続されるため、これらの接続はブロックデザインには表されない。

a_init_in

GT_DIFF_REFCLK1

gt_qpllrefclk_quad1_out

GT_SERIAL_RX

gt_refclk1_out

pma_init

link_reset_out

reset_pb

sys_reset_out

user_clk_out

gt_reset_out

init_clk

gt_powergood[0:0]

Aurora 64B66B

axi_bram_ctrl_0

blk_mem_gen_0

S_AXICable を使った
BRAM_PORTA
3.5 Xilinx Virtual
FPGA のデバッグおよびプログラム
s_axi_aclk

BRAM_PORTB

BRAM_PORTA

rsta_busy

BRAM_PORTB

rstb_busy

s_axi_aresetn

Block Memory Generator
AXI BRAM Controller

ila_6bit_counterc_counter_binary_0
clk
CLKQ[5:0]

probe0[5:0]

Binary Counter

ILA (Integrated Logic Analyzer)

debug_bridge_0

debug_bridge_1

m0_bscan

S_BSCANclk

S_AXI

Debug Bridges_axi_aclk
s_axi_aresetn_AXI

Debug Bridge

_AXI

_AXI

Si5345_INSEL

_AXI

_AXI

図 3.10

S_AXI
PL デバッグ用に置いた 2 つの Debug Bridge コア。ILA は 6-bit counter の出力をプローブするようにした。
s_axi_aclk
GPIO

gpio_led

s_axi_aresetn

_AXI

S_AXI

GPIO

s_axi_aclk

gpio_io_o[2:0]

gpio_io_o[1:0]

AXI GPIO

s_axi_aresetn
検出された。さらにILA のプローブファイル8 を指定したところ、図 3.11 のように 6-bit counter の出力をリモー

AXI GPIO
トでプローブできるようになった。
JTAG_bridge_XCVU13P
S_AXI
s_axi_aclk
s_axi_aresetn

tap_tditap_tms
tap_tck
tap_tdoDebug Bridge
xlconcat_2

ila_CFG

In0[0:0]clk

In1[0:0]

dout[1:0]

Concat

図 3.11probe0[1:0]ILA (Integrated Logic Analyzer)

XVC を用いて Zynq MPSoC の PL に組み込んだ 6-bit counter をプローブしている様子

この応用例を持って、リモートによる Zynq MPSoC の PL をデバッグするデモンストレーションに成功した。

3.5.2 XCVU13P のデバッグおよびプログラム
Zynq MPSoC と JTAG で接続されたターゲット FPGA デバイスを、XVC でデバッグおよびプログラムするには節 3.5.1 と同様に Debug Bridge を用いる。今回は図 3.12 のように Debug Bridge を [From AXI to JTAG]モードで Zynq MPSoC の PL に仕込んでおく。
通常 FPGA をプログラムしたりデバッグコアにアクセスするには、現場で Xilinx Platform Cable USB II など
8 Vivado が自動的に <Vivado project directory>/<project>.runs/impl_1/ に拡張子 .ltx のプローブファイルを生成している。

37

第 3 章 Endcap Sector Logic 第 1 試作機上の MPSoC の動作検証

AXI

PS

図 3.12

JTAG

Debug IP(e.g. ILA, VIO etc)

Debug Hub

TCP/IP

Target FPGA

Debug Bridge(From AXI to JTAG)

XVC server

SoC

Debug IP(e.g. ILA, VIO etc)

38

PL

[From AXI to JTAG]モードでの Debug Bridge 使用例

を用いた JTAG 線経由で行う。これをネットワーク経由で行うために Zynq MPSoC で走る XVC サーバを踏み台とする。TCP/IP で受信した情報をもとに外部の 4 本の信号線を介し、JTAG プロトコルにしたがってターゲット

FPGA のテストアクセスポートにアクセスする。したがって Debug Bridge のマスターインターフェイスは JTAGとなり、PS と PL は AXI で接続されているので、スレーブインターフェイスは AXI となるのが合理的である。
そのように Zynq MPSoC のブロックデザインに Debug Bridge を [From AXI to JTAG]モードで追加し、Vi-vado で XSA を出力した。PetaLinux でブートファイルをビルドし直して CentOS 7 を起動し、 /dev/uio1 に
XCVU13P 用の Debug Bridge を確認した9 。
XVC サーバアプリケーションのソースコードの /dev/uio0 を /dev/uio1 に修正してコンパイルした。それを実行して開発用コンピュータの Vivado で Hardware Manager を開き、Zynq MPSoC の IP アドレスと XVC サー
バ用のポートを入力すると xcvu13p_0 が検出された。Debug Bridge の [From AXI to JTAG]モードの使用用途として FPGA のプログラムは想定していないが（Xilinx 2018b）、[Program Device]を実行すれば正常にプログラムができた（図 3.13）。

図 3.13

XVC での XCVU13P のプログラムに成功した様子

今や Endcap SL の Zynq MPSoC は、権限を持っていれば世界中どこからでもアクセスができ、Zynq MPSoC の

PL や XCVU13P をデバッグしたりプログラムできる状態である。たとえば東京から KEK の Zynq MPSoC にア
クセスして XVC サーバを起動し、XCVU13P の GTY のリンクをテストする IBERT の試験もできるようになっ
9 この番号の順番は自明ではないが、経験的に [Address Editor]（図 2.9）で物理アドレスが割り振られた順番になっているように思われる。

3.6 その他の細かな確認事項

39

た。その様子を図 3.14 に示す。

図 3.14

リモートで IBERT 試験を行っている様子

この応用例をもって、Zynq MPSoC を踏み台にしたリモートでの別の FPGA のデバッグおよびプログラムを行うことのデモンストレーションに成功した。

3.6 その他の細かな確認事項
3.6.1 JTAG からの Zynq MPSoC PL のプログラム
通常、Xilinx 社の FPGA をプログラムしたりデバッグしたりするには、Xilinx Platform Cable USB II などを開発用コンピュータと対象のデバイスに接続して行う。Endcap SL にも Zynq MPSoC 用に JTAG コネクタが搭載されており、ここに Xilinx Platform Cable USB II を接続することで、ローカルでの PL のデバッグやプログラムを行うことができる。
これを行ったところ、図 3.15 のように正常に PL がプログラムされたことを確認した。
なお、ソフトウェアに関しては Mercury XU5 は eMMC、QSPI、SD カードからのブートのみサポートしており、JTAG からのブートをサポートしていない。

図 3.15JTAG からローカルに Zynq MPSoC の PL をプログラムした様子

第 3 章 Endcap Sector Logic 第 1 試作機上の MPSoC の動作検証

40

3.6.2

I2 C での温度センサの確認

TGA9548A I2 C MUX（図 3.8）のポート 5 から XCVU13P 用の温度センサ、ポート 6 から Zynq MPSoC 用の温度センサのための I2 C 線が出ている。これらは同じ温度センサ10 で、レジスタ 0x00 と 0x15 の値を I2 C で読むことで、local temperature がわかるようになっている。
節 D.3 と同様にこれらを I2 C-read するプログラムを作成し、実行したところ、正しく温度が測れているように見えた。その結果は Vivado の Hardware Manager のシステムモニタで測った温度とコンシステントであった。

3.6.3

Zynq MPSoC からの Si5345 入力クロックの指定

コネクタピン B103 と B107 から出ているそれぞれ INSEL0と INSEL1という信号線（図 F.3 を参照）が Si5345の IN_SEL[1:0]のポートにつながっており（図 3.7 を参照）、これにより Zynq MPSoC から Si5345 の入力クロッ
クを選択できるようになっている。SL では入力ポート 0 が TTC 信号をソースとする 40 MHz、入力ポート 1 がボード上の発信機をソースとする 40 MHz、入力ポート 2 が LEMO コネクタからの外部入力の、最大 3 つの入力
ソースの選択が可能である。ClockBuilder Pro でのコンフィギュレーションで入力クロックが単一の場合、これらのポートは使用しないように設定されるが、複数の場合はこれらのポートから入力クロックを指定する必要がある。
今回は 2 bit 幅の出力を持つ GPIO を用いて、PS からこれを操作できるようにした。Si5345 は、IN_SEL[1:0]で指定された入力クロックが有効でない場合、元の出力を保持し続ける holdover という機能が備わっている。そのため現在の試験のセットアップでは PS から IN_SEL[1:0]を変えても出力周波数が変更するのを確認できなかった。
しかし Si5345 の IN_SEL[1:0]に対応するピンに直接プローブを当て、確かにソフトウェアから指定した通りに電圧が変わっていることを確認した。

10 TMP431、https://www.ti.com/lit/ds/symlink/tmp432.pdf

41

第4章

AXI Chip2Chip を用いた FPGA 間シリアル
通信用ファームウェアの開発
4.1 目指す完成形
HL-LHC での Zynq MPSoC の役割の 1 つとして、XCVU13P 内のレジスタを読み書きすることにより、回路の動作モードを設定したりリアルタイムで回路の状態を確認するというものがある。Zynq MPSoC（XCZU-5EV-

FSVC784-2-I）には GTH トランシーバ（最大レーンレート 16.375 Gbps）が、XCVU13P には GTY トランシー
バ（最大レーンレート 32.75 Gbps1 ）が搭載されており、これらの Multi Gigabit Transceiver（MGT）を使った高速シリアル通信によって、Zynq MPSoC から XCVU13P のレジスタ制御を実現する。
レジスタ制御機構の完成模式図を図 4.1 に示す。図中の AR、AW、W、R、Bの矢印は AXI4 のチャンネルを、Tの矢印は AXI4-Stream を表している。ただし AXI4 では信号線を機能ごとにまとめたものをチャンネルと呼ぶ。AXI4 プロトコルについては付録 H を参照のこと。Zynq MPSoC の PS で走る CentOS 7 は PL に置かれた AXI Chip2Chip master と AXI4 でやりとりができる。節 4.2.2 で説明する Aurora 64B/66B を使うことでAXI4-Stream 形式のデータを高速シリアル通信の形式にエンコードし、XCVU13P にシリアル線を用いて情報を伝える。XCVU13P 側では情報を Aurora 64B/66B でデコードし AXI Chip2Chip slave が AXI4 に復元する。それ
ぞれのレジスタに命令を振り分けるには register interface を用いる。

B

PS

serial

T

T

W

R

write

register X

TAW

register interface

T

AXI Chip2Chip slave

R

AR

Aurora 64B/66B

W

Linux

slave module (XCVU13P)

Aurora 64B/66B

AR
AW

AXI Chip2Chip mastermaster module (Zynq MPSoC)

read

B

PL

図 4.1

レジスタ制御の完成模式図

このような仕組みにより、Linux で走っているアプリケーションから XCVU13P のレジスタを制御できるようになる。

1 ただしこれはスピードグレードの選択による。選択可能なスピードグレードの中で最大のレーンレートが示した 32.75 Gbps である。

第 4 章 AXI Chip2Chip を用いた FPGA 間シリアル通信用ファームウェアの開発

42

4.2 AXI Chip2Chip
4.2.1

AXI Chip2Chip を使うことの利点

PS と PL 間のインターフェイス、また Xilinx 社の FPGA 内のバスとして AXI4 が用いられていることは節 2.1.2
で説明した。1 つの Zynq のプロセッサをマスターとし、複数の FPGA デバイスをスレーブとして通信を行うのにAXI4 プロトコルを用いるのは自然な発想である。しかし付録 H にあるように AXI4 には多ビットの信号線が多くあり、そのすべてを Zynq の I/O ピンに割り当てるのは現実的ではない。
そのような複数 FPGA 間の、シームレスな AXI4 ブリッジング機能を提供するのが AXI Chip2Chip2 である（Xilinx 2020）。これにより少ないピン数で FPGA 間の AXI4 接続ができるようになり、マスターデバイスはス
レーブデバイス内の回路をあたかも自分のものであるように操作できるようになる。仮想的に AXI4 をデバイス間で用いることで、AXI4 のバースト転送やアウトオブオーダー転送も行うことができる。
さらに AXI Chip2Chip は FPGA 間のインターフェイスとして SelectIO™ と Aurora の 2 種類から選択可能である。ここではシリアル線を用いて FPGA 間通信を行うため、Aurora インターフェイスを採用する。

4.2.2

AXI Chip2Chip と Aurora コア

AXI Chip2Chip にはマスターとスレーブのモードがあり、2 つのデバイスのうち片方をマスター、もう片方をスレーブとして使用する。

AXI Chip2Chip の PHY タイプは次の 4 種類がある。
• SelectIO SDR（single data rate）• SelectIO DDR（double data rate）• Aurora 8B/10B• Aurora 64B/66B
マスターとスレーブデバイスで同じ PHY タイプを使用しなければならない。

Aurora 8B/10B および Aurora 64B/66B は Gigabit Transceiver（GT）を用いて高速シリアル通信を行うためのIP コアである。PHY タイプとして Aurora を選択した場合、AXI Chip2Chip の IP だけでなく Aurora IP もイン
スタンシエートする必要がある。AXI Chip2Chip と Aurora 間のインターフェイスには AXI4-Stream が使われる。XCVU13P の GTY モジュールは Aurora 8B/10B のインスタンシエートをサポートしないため、今回 Zynq

MPSoC と XCVU13P の接続には Aurora 64B/66B を用いた。
AXI Chip2Chip と Aurora コアのクロックとリセットの接続を図 4.2 に示す。左のブロックがマスターデバイ
ス、右のブロックがスレーブデバイスを表しており、AXI Chip2Chip と Aurora の IP とこれらの動作に必要なクロックとリセット信号が描かれている。Aurora 内の GT に用いる GT リファレンスクロックは外部から供給する。AXI Chip2Chip IP に aurora_pma_init_inを供給することにより aurora_pma_init_outが発生し、これがAurora IP の pma_init入力となる。また図 4.2 には描かれていないが AXI Chip2Chip IP の aurora_reset_pb信号
を Aurora の reset_pbに入力する。init_clk の 6 周期以上に相当する時間 aurora_pma_init_inをアサートし、ディ
アサートすることで、Aurora IP のリセットシーケンスに沿ったタイミングで pma_initと reset_pbを発行する。
後述する AXI Chip2Chip IP のサンプルデザインでは init_clk の 16 周期分だけ aurora_pma_init_inをアサートしていた。また lane_up[m-1:0]は各レーン（トランシーバ）が正常に初期化されたことを表し、channel_upはすべ

2 C2C と略記されることが多い。

ŚĂƉƚĞƌϯ͗ Designing with the Core
commonclock operations, the AXI Chip2Chip Slave core connects the Aurora user_clk
4.3 EndcapInSL
上でのファームウェアの作成

to the m_aclk_out output of the core. In this case, the pma_init reset must be handledexternally, and asserting pma_init resets the MMCM generating the user_clk. It is alsoてのレーン（チャンネル）の初期化が完了し、データの送受信の準備が整っていることを示すポートである。他
recommended to connect pma_init to the m_aresetn input of the AXI Chip2Chip Slaveにも mmcm_not_lockedや link_reset_outなどのデバッグ用のポートがあるが、詳細は Xilinx（2018a）や Xilinx
core in Common Clock mode.
（2020）を参照されたい。
X-Ref Target - Figure 3-2

Link Statuss_aclkgt_refclk

user_clk

mmcm_not_lockedAXI Slave
Interface

AXI Chip2Chip
Independent
text
Clock Master

AXI4-Lite
Slave
Interfaces_axi_lite_aclk

channel_up
do_cc
pma_init_out

AuroraIP

Aurora IP
Streaming
Duplex
without
CRC/FC

Streaming
Duplex
without
CRC/FCaurora_init_clk

s_aresetn
pma_init_in

Link Status

gt_refclk

user_clk

c2c_phy_clk

m_aclkmmcm_not_lockedAXI Chip2Chip
Independent/
text
do_cc
Commonpma_init_out Clock Slave
channel_up

AXI Master
Interface
AXI4-Lite
MasterInterfacem_axi_lite_aclk

aurora_init_clk
init_clk

m_aclk_out

c2c_phy_clk

m_aresetn
pma_init_in

init_clk&ŝŐƵƌĞϯͲϮ͗
Chip2Chip
Connectivity
and Clocking with the（Aurora
IP Core
図 4.2 AXIAXI
Chip2Chipと Aurora
コアのクロックとリセットの接続
Xilinx 2020）

Resets

4.3 Endcap SL 上でのファームウェアの作成

W

BRAM Controller

AXI Chip2Chip slave

Aurora 64B/66B

Aurora 64B/66B

W

AXI Chip2Chip master

The AXI Chip2Chip core allows both Master and Slave cores to have independent reset
mapping. The link detect FSM ensures the transactions from the Master device (AXI4 andmaster module (Zynq MPSoC)
slave module (XCVU13P)
AXI4-Lite) get initiated only when both Master and Slave AXI Chip2Chip cores are out ofAR
reset and readyto accept transactions. Reset can also be propagatedfrom Master device toAR
AW
AW In this case, you need to map the reset from MasterSlave device.
device to Slave device.
There is no separate resetT for the AXI4-Lite interface.
The AXI4-Lite interface isBRAM
brought outTof reset when
the link detects FSM is in LINKUP state (when the link status output of theRRB
core is asserted).
All input clocks to the core, including AXI4-Lite
B clock, must be stable when
the core is brought out of reset (when aresetn core input is deasserted).
Linux

PS

T

serialT

PL

It is not recommended to reset either Master or Slave AXI Chip2Chip core during normal
図 4.3 AXI
Chip2Chip
FPGA
間通信のデモンストレーションのため構築したファームウェアのダイアグラム
operation
or を用いたwhen Link
Statusis asserted. For both SelectIO™ and Aurora interfaces,
resetting the Master AXI Chip2Chip results in a link loss condition. If there is a link loss, both
AXI Chip2Chip cores perform LINKUP operations to reestablish the link when the Master AXI
BRAM Controller と BRAM は Vivado の IP として使用可能であり機能することがわかっているため、ここではChip2Chip core is brought out of reset. However for the SelectIO™ interface, this reset
まず AXI Chip2Chip間通信のデモンストレーションのため図
AXI
slave
4.3 のように
sequenceを用いた
requiresFPGA
s_aresetn
to be propagated from the Master
Device totheChip2Chip
Slave
Device.
When
the
Slave
deviceisresetduringnormaloperations,thelinkstatusisのスレーブとして BRAM を置いておいた。この XCVU13P に置いた BRAM に Zynq MPSoC の CPU からアクdeasserted and a link error interrupt is asserted in the Master AXI Chip2Chip core.
セスできることをもって AXI Chip2Chip を用いた FPGA 間通信ができることを確認した。

Endcap SLAn
第asserted
1 試作機上では、AXIinput
Chip2Chipを用いた高速シリアル通信のための信号線が、
0と 1resetの 2 組設け
pma_init
performs
both a general interconnect and transceiverinthe Aurora core,asserted
reset_pb
performs only the8 general
reset in 4 本。0の方のシリアル線られている（それぞれに
TX とand
RXan
、さらに
Pと
N の極性があるため合計で本ある）3interconnect
the Aurora core. The pma_init input is required to be connected to the pma_init_inを用いて、Zynq MPSoC と XCVU13P 間のシリアル通信ができるか試したところ、リンクの確立とデータの転送ができることを確認した。ここでは Zynq MPSoC をマスターとし、XCVU13P をスレーブとする AXI Chip2Chipを用いた通信をデモンストレーションをするためのファームウェアの開発について述べる。
AXI Chip2Chip v5.0
21
PG067
November
24,
2020
www.xilinx.com
XCVU13P 側のファームウェアのブロックデザインは図 G.1 にある。XCVU13P 側では AXI Chip2Chip slaveと Aurora 64B/66B をインスタンシエートし、両者の対応するポートを接続した。AXI Chip2Chip slave の先には BRAM を置いておき、これを Zynq MPSoC の PS から操作することを試みた。また Aurora 64B/66B と AXI
3 図 F.3 のメザニンとのコネクタ列 B の 45、47、51、53 から出ている C2CRXがついた信号線が XCVU13P から見て受信の信号。48、50、54、56 から出ている C2CTXがついた信号線が XCVU13P から見た送信の信号。

43

第 4 章 AXI Chip2Chip を用いた FPGA 間シリアル通信用ファームウェアの開発

44

Chip2Chip slave にはデバッグ用のポートがあり、Concat IP を使ってそれらをまとめ、ILA でプローブできるよ
うにしておいた。

Zynq MPSoC 側でも XCVU13P と同じように、AXI Chip2Chip master と Aurora 64B/66B をインスタンシエー
トし、デバッグ用のポートは ILA でプローブするように設定した。Zynq MPSoC 側のブロックデザインは図 G.2にある。AXI Chip2Chip master の AXI4 の入力は、AXI SmartConnect を介して PS と接続した。すなわち AXI

Chip2Chip master は AXI GPIO や BRAM と同列に PS と接続されており（図 4.4）、また [Address Editor]で物
理アドレスを割り当てることができた（図 4.5）。これにより PS から AXI GPIO や BRAM をするのと同様に、付録 C のようなプログラムでソフトウェアから AXI Chip2Chip master に情報を送り込むという使い方を想定した。

AXI Chip2Chip master には 0x80030000 から 64 kB のメモリが割り当てた。これに対応して、XCVU13P 側のBRAM は幅 32 bit、深さ 64 kB と設定した。
axi_bram_ctrl_0

ZYNQTCKZYNQTDI

BRAM_PORTA
S_AXI

ZYNQTMS

BRAM_PORTBAXI BRAM Controller
gpio_led
S_AXI

GPIO

AXI GPIO
debug_bridge_PL
S_AXI

m0_bscanDebug Bridge
JTAG_bridge_XCVU13P
axi_smc
S_AXI
M00_AXI

Debug Bridge

M01_AXI
M02_AXI

axi_chip2chip_0

M03_AXI

S00_AXI

M04_AXIs_axi

M05_AXIAXIS_RX

AXIS_TX
M06_AXI
M07_AXIAXI SmartConnect

AXI Chip2Chip Bridge
Si5345_INSEL
S_AXI

GPIO

Si5345_INSELAXI GPIO
system_management_wiz
S_AXI_LITE
Vp_Vn

System Management Wizard
axi_gpio_0
zynq_ultra_ps_e

S_AXI

M_AXI_HPM0_LPD

GPIO

AXI GPIO

GMII_ENET1

GMII

MDIO_ENET1

MDIO

Zynq UltraScale+ MPSoC

図 4.4

AXI Chip2Chip master は AXI SmartConnect を介して PS と接続できる

図 4.6 に使用したクロックと信号線、制約ファイルに書いた FPGA ピンを示した。マスター/スレーブともに、

MGT Bank に供給する GT リファレンスクロックは 125 MHz の差動クロックを用いた。本番の運用では、Si5344
jitter attanuator のポート 3 を介した 125 MHz クロック発信器からのものをリファレンスクロックとして用いるが、ここでは節 3.4 で使用経験のある Si5345 を用いた。ClockBuilder Pro で Si5345 のポート 2 と 3（それぞれ Zynq

MPSoC と XCVU13P の GT リファレンスクロックに対応）からボードの発振器をソースとして 125 MHz を出す
ようコンフィギュレーションし、節 3.4 と同様に PS で走るソフトウェアから I2 C で Si5345 を操作した。図 4.6にあるように、ポート 3 から出る差動クロックは Si53302 clock fanout の素子に入る。そのポート 8 から出る差動
クロックを XCVU13P の GT リファレンスクロックとして用い、ポート 0 から出るものを FPGA 内のシステムク
ロックとして用いた。FPGA 内ではシステムクロックから Clocking Wizard を用いて 100 MHz に分周した。さら4.4 Endcap SL での高速シリアル通信試験の結果

図 4.5

45

[Address Editor]では AXI Chip2Chip master に物理アドレスが割り当てられていたにこの 100 MHz で動作する、パルス信号を生成するモジュール（図 G.1 のブロックデザイン中の heartbeat モ
ジュール）を作成し、この信号を Endcap SL 上のデバッグ用 LED に接続した。この仕組みにより、fanout の素子から出る 125 MHz が有効であることを LED の点灯で確認できるようにした。
Si5345jitter attenuator

Si53302
clock fanout
125 MHz

Oscillator(40.079 MHz)IN1

3

FPSYCLP3

CLK0

3B

FPSYCLN3

CLK0B

Q0B
Q0

2 2B

B10

Q8 Q8B

B12
H39

V6 V5

H40

AY36 AY35

MGTREFCLK1MGT REFCLK1MGTHTX0

W4
W3

MGTHRX0

Y2
Y3

B45

E32

C2CRXP0
C2CRXN0D35

C2CTXP0

E37

C2CTXN0E38

MGTYRX0

B47

B48
B50

MGTYTX0

MGT Bank 224
Zynq MPSoC (5ev)
Mercuey XU5

図 4.6

MGT Bank 135

HP Bank 63

XCVU13P

Endcap SL 第 1 試作機で AXI Chip2Chip の試験をする際使用したクロックとピン

Aurora 64B/66B の リ セ ッ ト に は 、init_clkの 16 周 期 だ け aurora_pma_init_inを ア サ ー ト す る モ ジ ュ ー ル（ pma_init_generator ）を作成し、これを PS から AXI GPIO を介して操作できるようにした。

4.4 Endcap SL での高速シリアル通信試験の結果
まず Zynq MPSoC の CentOS 7 から Si5345 で 125 MHz を生成するプログラムを走らせた。次に XVC サーバを起動し、XCVU13P をリモートでプログラムしたところ、デバッグ用 LED が点灯した。これにより XCVU13P が正
常にプログラムされたことと Si53302 fanout から正常に 125 MHz の差動クロックが出力されていることを確認した。また Zynq MPSoC の PL をプログラムするために、OS をリブートした。なお OS をリブートしても電力が供

第 4 章 AXI Chip2Chip を用いた FPGA 間シリアル通信用ファームウェアの開発

46

給されている限り、Si5345 は出力を維持する。以上により、2 つのファームウェアがプログラムされ、XVC で Zynq

MPSoC と XCVU13P に仕込んだ ILA が確認できる状態になった。ソフトウェアから pma_init_generator に命令を送ることで Zynq MPSoC と XCVU13P 間のリンクをリセットした。デバッグ用のポートを ILA で確認す
ると、Zynq MPSoC と XCVU13P の両方で lane_up[0:0]や channel_upがアサートされたことなどから、シリアルリンクが確立されたことを確かめた。XCVU13P のデバッグポートを ILA で確認した際の様子を図 4.7 に示す。
またその結果をまとめた表 4.1 に、Zynq MPSoC 側でのプローブ結果を表 4.2 に示す。

図 4.7

XCVU13P 側の AXI Chip2Chip と Aurora 64B/66B のデバッグポートをモニタし、リンクの確立を確認した

この状態でメモリのアドレス 0x80030000 にアクセスしたところ（付録 C を参照）、問題なく BRAM に PS のソフトウェアからアクセスできた。ただしマスター側とスレーブ側で [ID Width]と [WUSER Width]を一致させる必要がある。
このように、Endcap SL 第 1 試作機の Aurora のシリアル線がハードウェア的に機能し、また AXI Chip2Chipを用いたシリアル通信によるデータ転送ができることを確認した。実際のレーンレートやエラー率などの検証はこれから行う。

4.5 register interface の作成
Vivado では AXI Chip2Chip のサンプルデザインとテストベンチシミュレーション（図 4.8）が利用可能である。
Traﬃc Generator は適当なデータパターンを生成し、ARチャンネル、AWチャンネル、Wチャンネルでデータを
AXI Chip2Chip に送信するもので、Traﬃc Checker は同じ規則で参照データを生成し、Rチャンネルと Bチャン
ネルで AXI Chip2Chip から返された応答が合致しているかを検知するものである。このテストベンチシミュレー
ションの動作については付録 I で述べる。図 4.1 のような機構を実現するため、図 4.8 のテストベンチシミュレーションを編集し、図 4.9 のようなテストベンチシミュレーションを作成した。図 4.8 のスレーブ側にあった Traﬃc

Generator と Traﬃc Checker の代わりにレジスタを複数置き、AXI Chip2Chip slave とレジスタとの間の仲介として register interface を作成した。register interface は AXI4 で命令を受け取り、対象のレジスタにデータの読み書きをするものである。register interface の作成には AXI4 の知識が必要であったので、AXI4 プロトコルについての説明を付録 H に記しておく。

register interface の開発には Verilog-HDL を用いたが、Verilog-HDL では多次元配列のワイヤが使えない。そ4.5 register interface の作成

47

表 4.1 XCVU13P のプローブ結果

ILA bitDebug port

表 4.2 Zynq MPSoC のプローブ結果

Value

ILA bitDebug port Chapter 6

Value

13

axi_c2c_multi_bit_error_out

018

gt_powergood[0:0]112axi_c2c_link_status_out

117

gt_reset_out

0

axi_c2c_conﬁg_error_out
Test
Bench
aurora_pma_init_out
10

0

16

sys_reset_out

0

0

15

link_reset_out

0

11
9

aurora_pma_init_in0
gt_qpllrefclklost_quad1_out
This chapter contains information about
the test bench14
providedin the Vivado® Design

8

Suite.
aurora_reset_pb

7

gt_powergood
mmcm_not_locked_out
Figure 6-1 and Figure 6-2 show the 1demonstration test12
bench witha SelectIO™ interface

0

6

and an Aurora interface, respectively.
gt_reset_out
05

sys_reset_out

4

link_reset_out

3

gt_qpllrefclklost_quad1_out

2

13

0

X-Ref Target - Figure 6-1

AXI Chip2Chip Example Design

gt_qplllock_quad1_out
Traffic
Generator

AW

1

AR

1

mmcm_not_locked_outW0channel_up

00
113-bit value
Traffic
Checker10

hard_err

09gt_pll_lock

18

lane_up[0:0]1AW

channel_up

Figure 6-1:

10

aurora_pma_init_out

0aurora_reset_pb0

axi_c2c_multi_bit_error_out
TrafficB02

axi_c2c_link_error_out

01

axi_c2c_conﬁg_error_out

00

axi_c2c_link_status_out

1

5

AXI
Chip2ChipCore(SlaveOr
Master)3

B

Traffic
CheckerARaurora_pma_init_inW

40x1085R

0

6
SelectIO Interface0

soft_err

7

AXI
Chip2Chip
Core(MasterOr
Slave)

1

11
Demonstration Test Bench0

gt_qplllock_quad1_out

0RGenerator

19-bit value

0x42381

Demonstration Test Bench Block Diagram

X-Ref Target - Figure 6-2

Demonstration Testbench
AXI Chip2Chip Example DesignAW
Traffic
Traffic
Generator
Generator

AW

AR
W

R
Traffic
Traffic
CheckerCheckerAR
AXI
AXI
Chip2Chip
Chip2Chip
Core
Core(Master(MasterOr
Or
Slave)
Slave)

AuroraAurora64B66B
64B66BCore
Core

SerialInterface

AuroraAurora64B66B
64B66B
Core
Core

B

Figure 6-2:
図 4.8

AXI
AXI
Chip2Chip
Chip2ChipCore
Core(Slave(SlaveOr
Or
Master)Master)W

R
B

Traffic
Traffic
CheckerChecker

Traffic
Traffic
Generator
Generator

Demonstration Test Bench with Aurora Interface

AXI Chip2Chip のテストベンチシミュレーション（Xilinx 2020）

AXI Chip2Chip
v5.0
のため図
4.10 のように、ここではレジスタの数に対応した読み書きの信号線
rdata_i、wdata_i（10 41
個のレジスタ
PG067 November 24, 2020
www.xilinx.com
があるならば i = 0, . . . , 9）を用意した。

4.5.1 register interface 内部のステートマシン
register interface 内で走るステートマシンを以下のように設計した。

第 4 章 AXI Chip2Chip を用いた FPGA 間シリアル通信用ファームウェアの開発

48

Test bench

T

W

R

rdata

register interface を加えたテストベンチシミュレーション

register 0

register 0

register 9

wdata_1

register 1...

rdata_9

registerinterface

...

...

rdata_1

wdata_0

register 1...

rdata_0

図 4.10

wdata

B

図 4.9

registerinterfaceregister X

serialAW

register interface

R
B

T

AXI Chip2Chip slave

W

AR

Aurora 8B/10B

AW

Aurora 8B/10B

AR

AXI Chip2Chip master

Traffic
Checker

Traffic
Generator

AXI Chip2Chip example design

wdata_9

register 9

register interface とレジスタとの接続にはそれぞれ独立な信号線を用意した。

読み出しに関するステートマシンを表した表したタイミングチャートを図 4.11 に示す。レジスタからのデータの読み出しについては、次のような 3 つのステートを遷移するようにした。

RESET

ARESETnがディアサートされている間このステートに移る。レジスタ変数を初期化し、IDLE
ステートに移る。

IDLE

ARREADYを ア サ ー ト し て お き 、AXI Chip2Chip か ら の AEVALIDが ア サ ー ト さ れ れ ば
ARADDRと ARIDを受け取る。それらをそれぞれ tmp_raddr と tmp_rid というレジスタ変数に格納し、TRANSFER ステートに移る。

TRANSFER tmp_raddr の値に対応したレジスタから rdata_iを用いてデータを読み出し、結果を AXI

Chip2Chip に返す。その際には RIDとして tmp_rid を返すことで、AXI Chip2Chip との整合性をとる。RRESPとしては基本的に 0b00（OK）を返し、レジスタが存在しないアドレスであれば 0b10（SLVERR）を返す。ステートを IDLE にして次の指令を待つ。
書き込みについても同様のステートマシンを作成した。この書き込みステートマシンを表したタイミングチャー
トを図 4.12 に示した。各ステートでは次のような動作をする。

RESET

ARESETnがディアサートされている間このステートに移る。レジスタ変数を初期化し、IDLE
ステートに移る。

IDLE

AWREADYと WREADYを ア サ ー ト し て 待 機 す る 。AXI Chip2Chip か ら の AWVALIDと WVALIDが ア サ ー ト さ れ れ ば 、AWADDR、AWID、WDATAを そ れ ぞ れ tmp_waddr 、

tmp_wid 、 tmp_wdata というレジスタ変数に格納する。ステートを TRANSFER に移す。
TRANSFER tmp_waddr に対応したレジスタへの信号 wdata_i（i = 0, . . . , 9）を tmp_wdata にする。BID
を tmp_wid にし、BRESPは tmp_waddr が妥当であれば 0b00（OK）、レジスタが存在しな

4.5 register interface の作成

49

aclk
aresetn(reg) r_next_state(reg) r_current_state

IDLE
RESET

TRANSFER
IDLE

IDLE

TRANSFER

TRANSFER
IDLE

TRANS

arready(arvalid)(araddr)a1

a2(arid)

id1

id2(reg) tmp_raddr

a1a2(reg) tmp_rid

id1

id2

(reg) rdata

d1

d2

rvalid, rlast
rdata

d1

rid

id1

rresp

OK

(rready)(reg) rready_counter

図 4.11

0

1

2

3

0

register interface の読み出しに関するステートマシンのタイミングチャート。AXI Chip2Chip からの入力信号は括弧で囲み、AXI Chip2Chip への出力には何もつけていない。またレジスタ変数には (reg) をつけた。(reg) rdata はレジスタからのデータを格納するレジスタ変数である。

いアドレスであれば 0b10（SLVERR）にする。それと同時に BVALIDをアサートしておき、

BREADYもアサートされれば IDLE ステートに戻る。
これら読み出しと書き込みのステートマシンは独立に動作するようにしているが、AXI Chip2Chip から読み出しと書き込みの命令が同時に来たときの排他的処理の機構はまだ設けていない。ただしテストベンチシミュレーショ
ンの運用においては、同時に読み出しと書き込みすることはなかったため問題なく動作した。そのような場合の対処の実装は今後の課題である。

4.5.2 register interface を用いたテストベンチシミュレーションの実行
まず 10 個のレジスタを用意し、それらを register interface と接続した。図 4.9 のマスター側の Traﬃc Generatorと Traﬃc Checker をアドレス 0 から 9 にアクセスするように編集した。テストベンチシミュレーションを実行したところ、10 個のレジスタにデータが正しく書き込まれ（図 4.13）、さらにマスター側でも書き込んだデータが正常に読み出されていることを確かめた。
また 4 つのレジスタに、表 4.3 のようなより実用的な機能を持たせて試験をした。 マスター側からは 32 bit のラ
表 4.3

4 つのレジスタに与えた役割

レジスタのインスタンス名

役割

動作

register_0

reset register

register_1

status register

固定の値 0xEE1234EE を出し続ける。

register_2

control register

マスターにより値が単純に読み書きされる。

register_3

pulse register

自身の値の 0 ビット目を自身のリセット信号として使用する。

自身の値の 0 ビット目をリセット信号として自身とcontrol register に配布する。

第 4 章 AXI Chip2Chip を用いた FPGA 間シリアル通信用ファームウェアの開発

50

aclk
aresetn(reg) w_next_state(reg) w_current_state

IDLE
RESET

TRANSFER
IDLE

IDLE

TRANSFER

TRANSFER
IDLE

TRANSFER

awready(awvalid)(awaddr)a1

a2(awid)

id1

id2

wready(wvalid)(wdata)d1

d2(reg) tmp_waddr

a1a2(reg) tmp_wid

id1

id2

(reg) tmp_wdata

d1

d2

wdata_i (to register)

d1

d2(data in register i)d1bvalid, blast
bid

id1

id2

bresp

OK

OK

(bready)(reg) bready_counter

0

1

2

3

0

図 4.12

register interface の書き込みに関するステートマシンのタイミングチャート。AXI Chip2Chip からの入力信号は括弧で囲み、AXI Chip2Chip への出力には何もつけていない。またレジスタ変数には (reg) をつけた。(reg) rdata はレジスタからのデータを格納するレジスタ変数である。

図 4.13

10 個のレジスタに正しく書き込めた様子。マスターから、2 ずつインクリメントしたデータをレジス
タ 0 からレジスタ 9 まで順に書き込んだ。_regがついているのはレジスタ内部で用いているレジスタ変数。

4.6 本章のまとめ

51

ンダムなデータを生成した。テストベンチシミュレーションを実行すると、図 4.14 のようになった。reset registerに奇数のデータが書き込まれたとき、reset register と control register の値がリセットされ 0x00000000 になっている。また status register は読み出し専用で、正常に 0xEE1234EE を出し続けている。また pulse register に奇数
データが書き込まれたとき、1 クロック分だけ値が変化してその後 0x00000000 にリセットされていることがわかる。これはパルス的に変化する信号を出すのに使用できる。

図 4.14

4 つのレジスタに表 4.3 のような役割を持たせたときの挙動

節 4.3 では Endcap SL 第 1 試作機を用いた高速シリアル通信が確立したが、その前に図 4.9 のファームウェアを実機で試験するため、ZCU102 評価ボードを用いたループバック回路の作成を試みており、その詳細は付録 J で述べる。今後、図 4.9 の機構を Endcap SL 第 1 試作機で実装する予定である。

4.6 本章のまとめ
ここでは物理層のトランシーバを使ったファームウェアを実装し、AXI Chip2Chip を用いたシリアル通信する
デモンストレーションを Endcap SL 第 1 試作機上で成功させた。また register interface の開発とテストベンチシ
ミュレーションを用いた動作検証も完了した。今後はこれらを統合し、Endcap SL 第 1 試作機上で図 4.9 のようなレジスタ制御の機構を実現する。

53

第5章

まとめと今後の展望
本研究では Zynq UltraScale+ MPSoC で CentOS 7 という通常の Linux をブートできることを確認し、基本的なソフトウェアやファームウェアの開発パスを開拓した。Endcap SL 第 1 試作機に Mercury XU5 メザニンカードをマウントし、そこでも microSD カード起点の CentOS 7 のブートができたことを示した。また Endcap SL 上のク
ロックジェネレータや温度センサなどの素子を Zynq MPSoC から監視、制御できることを確認した。さらに Zynq

MPSoC で Xilinx Virtual Cable が使え、Zynq MPSoC のファームウェアのデバッグや、XCVU13P のプログラムやデバッグをネットワーク越しに行うことができることを示した。AXI Chip2Chip のブリッジング機能を用いた

FPGA 間の高速シリアル通信ではリンクを確立させ、Zynq MPSoC から XCVU13P の BRAM にアクセスすることができた。また Zynq MPSoC を用いたソフトウェアやファームウェアの開発や試験のため ZCU102 評価ボード
での開発環境の整備も行なった。
今後は AXI Chip2Chip を用いたシリアル信号線のレーンレートやビットエラー率などの詳細を調査する予定である。また今回は 2 つあるシリアル線のうち 1 つを用いて検証を行なったが、もう片方の検証も行ったり、もう

1 つのクロックジェネレータが動作するかなど、Endcap SL 第 1 試作で行うべき試験はまだ残っている。さらにXCVU13P のレジスタ制御や、Endcap SL を PS ボードと接続して読み出しデータのダンプパスを確立し、2027 年の HL-LHC のための準備を進める。

55

付録 A

典型的な PetaLinux での作業の詳細

source <path to>/petalinux/2020.1/settings.sh # Activate PetaLinux 2020.1
で PetaLinux 2020.1 を使える状態にする1 。

petalinux-create --type project --name <project name> --template zynqMP
cd <project name>
で PetaLinux でプロジェクトを立ち上げ、それに入る。

Vivado で生成した XSA ファイルを読み込ませて基本的な設定を行うにはpetalinux-config --get-hw-description=<path to the dir of XSA>
を実行すれば、図 A.1 のような画面に切り替わり、ここで基本的なコンフィギュレーションを行う。XSA の更新がないならば、 get-hw-description のオプションはなくてよい。

図 A.1

petalinux-config 画面

1 ログイン時に自動的に PetaLinux 2020.1 を使える状態にするように $HOME/.bashrc に書いておいたり、 alias を作成すると便利であ

る。

付録 A

56

典型的な PetaLinux での作業の詳細

ZCU102 に関してはコードブロック A.1 に設定した。これは図 2.7 のようなパッケージングをし、SD カード第1 パーティションに BOOT.BIN 、 image.ub 、 boot.scr を置き、第 2 パーティションの rootfs を使用するような設定である。

Subsystem AUTO Hardware Settings---> Advanced bootable images storage Settings---> boot image settings---> image storage media (primary sd)---> u-boot env partition settings ---> image storage media (primary sd)---> kernel image settings---> image storage media (primary sd)---> jffs2 rootfs image settings---> image storage media (primary flash)---> dtb image settings---> image storage media (from boot image)DTG Settings---> (zcu102-rev1.0) MACHINE_NAME---> Kernel Bootargs---> [ ] generate boot args automatically (console=ttyPS0,115200
clk_ignore_unused root=/dev/mmcblk0p2 rootfstype=ext4 rw rootwait earlyprintk)
user set kernel bootargs
Image Packaging Configuration---> Root filesystem type (EXT4 (SD/eMMC/SATA/USB))---> (/dev/mmcblk0p2) Device node of SD device
コードブロック A.1 ZCU102 で行った設定の例

ユーザ編集用の DTS は<PetaLinux project>/project-spec/meta-user/recipies-bsp/device-tree/files/system-user.dtsiであるので、必要ならばそれを編集する。

petalinux-buildというコマンドでカーネルや FSBL、デバイスツリー、
rootfs などがビルドされ、<PetaLinux project>/images/linux/ の下にできる。

cd images/linux
petalinux-package --boot --fsbl zynqmp_fsbl.elf --fpga system.bit --pmufw pmufw.elf--u-boot --force
これで BOOT.BIN がパッケージされる。 force オプションは初回ならばつけなくていいが、2 回目以降は上書きするのに必要なオプションである。

57

付録 B

Ultra96-V2 を用いた開発パスの確認と物体検出処理の高速化

図 B.1

Ultra96-V2 シングルボードコンピュータ（Avnet）

Avnet® 社が製造している Ultra96-V2 シングルボードコンピュータ（図 B.1）には、Xilinx 社製の Zynq
UltraScale+ MPSoC（ZU3EG）が搭載されている。また Enclustra 社製の Mercury XU5 と Mercury+ PE1 よりもコミュニティが厚く資料も豊富であった。Mercury XU5 と Mercury+ PE1、ZCU102 評価ボードを用いた開発
パスを開拓する前に、この Ultra96-V2 を用いて PetaLinux を使った開発パスの確認と、ファームウェアの作成練習を行った。ファームウェア作成練習の題材としては、YOLOv3 という物体検出に使われるニューラルネットワー
クの行列演算を FPGA で行い、物体検出処理の高速化を試みた。これについては奥畑（2019）を参考にしたが、これは Ultra96-V2 ではなく Ultra96 を用いたものであった。具体的には次のようなことを行った。

• Linux のブート
◦ 提供されている Linux イメージの SD カードブート（節 B.1.1）◦ PetaLinux の BSP を用いた Linux のブート（節 B.1.2）◦ Vivado の BDF を用いたファームウェアの作成（節 B.1.3）• ニューラルネットワークの行列演算をハードウェア化（節 B.2）

付録 B Ultra96-V2 を用いた開発パスの確認と物体検出処理の高速化

58

開発環境には Vivado 2019.2 と PetaLinux 2019.2 を用いた。

B.1

Linux のブート

B.1.1

提供されている Linux イメージの SD カードブート

まず Ultra96-V2 の箱に同封されていた「Ultra96-V2 Quick-Start」というインストラクション1 をフォローした。
これは提供されているイメージファイルを microSD カードに焼き、電源を ON にすることですぐに Linux を起動できるというものだった。
まず提供されているイメージファイルをダウンロードした。これを Etcher というアプリケーションを用いて、microSD に展開し、ブータブル SD を作成した。Ultra96-V2 ボードに SD を挿入し、DIP スィッチの 1 が OFF、2が ON になっていることを確かめた。電源のプラグを挿し（電源ジャックの近くにある LED が緑色に光る）、SW4を押して離すと Linux が起動した。Ultra96-V2 ボードには Wi-Fi チップが搭載されていて、無線 LAN でアクセスできる2 。IP アドレスは 192.168.2.1 が割り振られるようになっていた。また無線 LAN 接続可能な開発用コンピュータからは、Ultra96-V2 デバイスが Ultra96-V2_<MAC address> という名前で検出されたので、これに接続した（図 B.2）。

図 B.2

開発用コンピュータから Wi-Fi で Ultra96-V2 を Ultra96-V2_<MAC address> として検出

ブラウザから http://192.168.2.1 で接続すれば、図 B.3 のウェブアプリから LED の制御をすることができた。またウェブアプリから外部の Wi-Fi ルータに接続するよう設定すれば、インターネットにも接続できた。

SW4 を押して離す、またはコマンド shutdown -h now や poweroff でシャットダウンした。より詳細にはこれは Ultra96-V2 のホームページ（Avnet）の [Technical Documents] → [Ultra96-V2 Getting Started Guide]から入手可能な Getting Started Guide を参照するとよい。

B.1.2

PetaLinux の BSP を用いた Linux のブート

こ の よ う な Xilinx 社 製 の SoC が 搭 載 さ れ た ボ ー ド で は 、そ の ベ ン ダ ー は PetaLinux の Board Support

Package（BSP）を 提 供 し て い る こ と が 多 い 。BSP を 用 い る こ と で 、リ フ ァ レ ン ス デ ザ イ ン の PetaLinux プ ロ ジ ェ ク ト を す ぐ に 作 成 で き る 。Ultra96-V2 の 場 合 、Ultra96-V2 の ホ ー ム ペ ー ジ（Avnet）の[Reference Design]→[PetaLinux Board Support Packages]よ り [Ultra96-V2 – PetaLinux 2019.2 BSP]

1 これは Ultra96-V2 のホームページ（Avnet）の [Technical Documents] → [Ultra96-V2 Quick-Start Card]からも入手可能。
2 ただしブート時にログを見てデバッグする必要があるならば、UART 通信用のモジュールを別途購入する必要がある。

B.1 Linux のブート

59

図 B.3

Ultra96-V2 のウェブアプリの例（ ultra96v2_oob_2019_2.bsp 3 ）をダウンロードし、次のように PetaLinux プロジェクトの作成、ビルド、パッ
ケージングを行った。

petalinux-create -t project -s <path_to>/ultra96v2_oob_2019_2.bsp
cd ultra96v2_oob_2019_2
petalinux-build
cd images/linux
petalinux-package --boot --fsbl zynqmp_fsbl.elf --fpga system.bit --pmufw pmufw.elf--u-boot
こ れ で ブ ー ト イ メ ー ジ BOOT.BIN が パ ッ ケ ー ジ ン ン グ さ れ た 。microSD の 第 1 パ ー テ ィ シ ョ ンに BOOT.BIN と image.ub を コ ピ ー し4 、第 2 パ ー テ ィ シ ョ ン に rootfs.tar.gz を 展 開 し た 。SD カ ー ド
3 oob は out-of-box のことで、「製品などを入手後にすぐ使える」という意味らしい。
4 PetaLinux 2019.2 を用いていたため、 boot.scr は用いずにブートする。 boot.scr が必要となるのはバージョン 2020.1 から。

付録 B Ultra96-V2 を用いた開発パスの確認と物体検出処理の高速化

60を安全に取り外し、Ultra96-V2 ボードに挿入して電源を入れ、Wi-Fi で接続すると、節 B.1.1 と同じ Linux が起動していることを確認できた。

B.1.3

Vivado の BDF を用いたファームウェアの作成

ここでは自分で回路を作成し、Linux 起動時に PL をプログラムして使えるようにした。簡単な回路として、

BRAM を追加し、PS から BRAM の内容を読み書きする。開発の概略図は図 B.4 の通り。

github.com/avnet

Board Definition Files
HDL scripts

Ubuntu 18.04
Vivado 2019.2
1. Generate a project with bdf/ and hdl/
2. Open the project with Vivado
3. Change board design
4. Generate Bitstream
5. Export Hardware

ssh root@192.168.2.1

ULTRA96V2_wrapper.xsa

PetaLinux 2019.2
Copy BOOT.BIN& image.ub in p1

1. Create a project with bsp
2. Configure specifying
ULTRA96V2_wrapper.xsa
3. Build
4. Packaging

Ultra96-V2 board
Zynq
MPSoC

Extract rootfs in p2

図 B.4

Ultra96-V2 の開発フロー

BSP から作成した PetaLinux のプロジェクトディレクトリ ultra96v2_oob_2019_2/ の中のhardware/ULTRA96V2_2019_2/ に は Vivado の プ ロ ジ ェ ク ト フ ァ イ ル 一 式 が 揃 っ て い た 。し か し た と え
ば hardware/ULTRA96V2_2019_2/ULTRA96V2.xpr を Vivado でオープンして FPGA ビットストリームを生成しようとしても、Avnet 社が作成したモジュールなどの情報がないため成功しなかった。
そ こ で 、Avnet の GitHub の リ ポ ジ ト リ か ら Board Deﬁnition Files（BDF）と HDL フ ァ イ ル の 一 式
を git clone して、Vivado プロジェクトを作成した（コードブロック B.1）。BDF というのは、Vivado のプロ
ジェクトを作成するときに便利なテンプレートのようなものである。また HDL ファイルには回路の情報が書いてあり、Tcl ファイルを source することで回路を生成できる。

git clone -b master https://github.com/avnet/bdf.git
git clone -b 2019.2 https://github.com/avnet/hdl.git
cd hdl/Scripts/
source ~/Xilinx/Vivado/2019.2/settings64.sh # Activate Vivado 2019.2
vivado -mode batch -source ./make_ultra96v2_oob.tcl
コードブロック B.1 GitHub から BDF と HDL ファイルの一式をクローンして Vivado プロジェクトを作成

B.1 Linux のブート

61

コードブロック B.1 最後のコマンドは Vivado のバッチモード（CUI）で make_ultra96v2_oob.tcl をソースにすることを意味している。このコマンドは hdl/Scripts/ から実行しなければならない。また GitHub からク
ローンしてきた 2 つのディレクトリ bdf/ と hdl/ は同じディレクトリにいるような構成にしなければならない。

make_ultra96v2_oob.tcl の中で、 bdf/ の Ultra96-V2 のものを相対パスで参照するようになっているからだ。
bdf/ と hdf/ には関係ないボードのファイルが含まれているので、それらは削除してよい。
Vivado による source コマンドの実行が終了したら、hdl/Projects/ultra96v2_oob/ULTRA96V2_2019_2/ にVivado のプロジェクトファイル一式がある。この中の ULTRA96V2.xsa を PetaLinux で持ちいれば、これまでと同様にリファレンスデザインの PL が展開される。また Vivado のプロジェクトは ULTRA96V2.xpr である。この
ブロックデザインを見ると、リファレンスデザイン（oob）のものになっていた（図 B.5）。ここでは練習のために
これらのモジュールをすべて消し、1 から PL のデザインを作った。

図 B.5

OOB のブロックデザイン。これをすべて消して、1 からデザインを作成した。

まず [Add IP]から Zynq UltraScale+ MPSoC の IP ブロックを追加した。このブロックをダブルクリック
し、[PS-PL Conﬁguration] → [PS-PL Interfaces] → [Master Interface] → [AXI HPM0 FPD]にチェックを入れた。pl_clk0のピンと maxihpm0_fpd_aclk 、maxihpm1_fpd_aclk を線で繋いだ。AXI BRAM Controller と Block

Memory Generator の IP を追加した。BRAM にはポート A とポート B があるが 1 つ消してそれらをつなぎ、[Run Block Automation] → [Select All] → [OK]をクリックすると図 ??のようなブロックデザインが完成した。また [Address Editor]のタブを開いて [Auto Assign Address]をクリックして、axi_bram_ctrl_0の物理アドレスを0xA0000000 として割り振った（図 B.7）。

付録 B Ultra96-V2 を用いた開発パスの確認と物体検出処理の高速化

62
zynq_ultra_ps_e_0

axi_smc
axi_bram_ctrl_0
M_AXI_HPM0_FPD

S00_AXI

blk_mem_gen_0

maxihpm0_fpd_aclk
M_AXI_HPM1_FPD

aclk

M00_AXI

S_AXI

maxihpm1_fpd_aclk
pl_resetn0

aresetns_axi_aclk

BRAM_PORTA

BRAM_PORTA

rsta_busy

pl_ps_irq0[0:0]pl_clk0s_axi_aresetn

AXI SmartConnect

Block Memory Generator
AXI BRAM Controller

Zynq UltraScale+ MPSoC

rst_ps8_0_100M
slowest_sync_clk

mb_reset

ext_reset_in

bus_struct_reset[0:0]aux_reset_in

peripheral_reset[0:0]mb_debug_sys_rst
dcm_lockedinterconnect_aresetn[0:0]
peripheral_aresetn[0:0]Processor System Reset

図 B.6

新たに作成した BRAM のブロックデザイン

図 B.7

BRAM のアドレス割り振り

これで [Flow] → [Generate Bitstream]をクリックして、ビットストリームを生成する。処理が終わったら[File] → [Export] → [Export Hardware]をクリック、[Include Bitstream]にチェックを入れて、OK をクリックした。Vivado プロジェクトディレクトリに ULTRA96V2_wrapper.xsa が生成された。

Vivado を終了し、節 B.1.2 の PetaLinux のプロジェクトディレクトリに話を移す。ここでは ULTRA96V2_wrapper.xsa があるディレクトリを指定して petalinux-config を行い、ビルドした。

cd <path to>/ultra96v2_oob_2019_2/
petalinux-config --get-hw-description=<path to>/hdl/Projects/ultra96v2_oob/
ULTRA96V2_2019_2/ --oldconfig
petalinux-build
cd images/linux
petalinux-package --boot --fsbl zynqmp_fsbl.elf --fpga system.bit --pmufw pmufw.elf--u-boot --force
あとは節 B.1.2 と同じように SD の第 1 パーティションに BOOT.BIN と image.ub をコピーし、第 2 パーティ
ションに rootfs.tar.gz を展開した。Ultra96-V2 ボードに SD を挿して起動してログインしたところ、BRAM

B.2 ニューラルネットワークの行列演算をハードウェア化するに割り当てた物理アドレス 0xA0000000 の値を読み書き可能なことを確認した。 rootfs.tar.gz では devmem コ
マンドが使えるので、それを用いた。

root@ultra96v2_oob_2019_2# devmem 0xa0000000
0x00000000
root@ultra96v2_oob_2019_2# devmem 0xa0000000 32 0xdeadbeef
root@ultra96v2_oob_2019_2# devmem 0xa0000000
0xDEADBEEF

B.2 ニューラルネットワークの行列演算をハードウェア化する
YOLOv3（Redmon and Farhadi 2018）は入力された画像から物体の位置と種類を検出する機械学習モデルである。ここでは行列演算 IP を用いた回路を作成し、Ultra96-V2 のハードウェアで物体検出を行うことを試みた。

図 B.8

YOLOv3 を用いて画像の物体検出をした例

B.2.1 行列演算 IP の作成
32 × 32 の行列演算 IP として、Xilinx Application Note 1170（Daniele Bagni et al. 2016）の HLS_accel を活用した。これは 32 × 32 の行列 A と B の要素を AXI4-Stream で受け、それらの積 C = AB を AXI4-

Stream で出力するものである。このリファレンスデザインをダウンロードし解凍すると xapp1170_2015v4/ が入 手 で き た 。こ の IP は Zynq-7000 SoC の も の な の で 、Zynq MPSoC 用 に 高 位 合 成 す る た め の ス ク リ プ
ト xapp1170_2015v4/empty/hls/run_hls_script.tcl を編集した。前半はすべてコメントアウトし、後半をコードブロック B.2 のように編集した。

63

付録 B Ultra96-V2 を用いた開発パスの確認と物体検出処理の高速化

64############################################################## This file is generated automatically by Vivado HLS.
## Please DO NOT edit it.
## Copyright (C) 2012 Xilinx Inc. All rights reserved.
############################################################
open_project hls_wrapped_mmult_prj
set_top HLS_accel
add_files mmult_accel.cpp -cflags "-DDB_DEBUG"
add_files -tb mmult_test.cpp -cflags "-DDB_DEBUG"
open_solution "solution0"# Change below according to Ultra96-V2 board
set_part {xczu3eg-sbva484-1-i}
create_clock -period 10 -name default
set_directive_inline "mmult_hw"
set_directive_pipeline -II 1 "mmult_hw/L2"
set_directive_array_partition -type block -factor 16 -dim 2 "mmult_hw" a
set_directive_array_partition -type block -factor 16 -dim 1 "mmult_hw" bcsim_design -clean#-setupcsynth_design# Add the line below to use HLS_acces as an IP in Vivado block designexport_design -rtl verilog -format ip_catalog
close_projectquit
コードブロック B.2

編集した run_hls_script.tcl 。コメントアウトした前半は省略してある。

編集後、このスクリプトを実行して C 言語によるソースコードから Vivado の IP を生成した。

source <path to>/Vivado/2019.2/settings64.sh # activate Vivado 2019.2
cd <path_to>/xapp1170_2015v4/empty/hls/
vivado_hls -f run_hls_script.tcl
完了すると、HLS_accel が

xapp1170_2015v4/empty/hls/hls_wrapped_mmult_prj/sokution0/impl/ip/
配下にできた。
生 成 し た Vivado の IP を ブ ロ ッ ク デ ザ イ ン に 組 み 込 め る よ う に す る た め 、Vivado プ ロ ジ ェ ク ト で[Tools] → [Settings...] → [IP] → [Repository]から

xapp1170_2015v4/empty/hls/hls_wrapped_mmult_prj/sokution0/impl/ip/

B.2 ニューラルネットワークの行列演算をハードウェア化する

65を選択し、[Apply]をクリックした。新しいブロックデザインを作成し、[Add IP]から HLS_accel を検索してこれを追加した。また Zynq UltraScale+ MPSoC の IP も追加し、ブロックをダブルクリックして次のように設定した。

• [PS-PL Conﬁguration] → [PS-PL Interfaces]◦ [Master Interface]- 2 [AXI HPM0 FPD]- 2
 [AXI HPM0 LPD]
◦ [Slave Interface]- 2 [AXI HPC0 FPD]
• [Clock Conﬁguration] → [Output Clocks] → [PL Fabric Clocks]◦ 2 [PL0] 2
 [PL1] 2
 [PL2] 2
 [PL3]• [I/O Conﬁguration] → [Low Speed] → [I/O Peripherals] → [I/O Peripherals]◦ [UART]- [UART0] → 2
 [MODEM]- [UART1] → 2
 [MODEM]◦ [GPIO] → 2
 [GPIO EMIO]
追加した HLS_accel は AXI4-Stream でデータを入出力するが、PS のインターフェイスは AXI4 であるため直接は接続できない。そこで AXI Direct Memory Access（AXI DMA）を介して AXI4 に変換し、PS に接続した。

AXI DMA の設定は [Enable Scatter Gather Engine]のチェックを外してシンプル DMA モードした。シンプル
DMA モードというのは、転送するメモリ領域の開始アドレスと長さを AXI DMA にセットして実行するものである。最終的に図 B.9 のような回路を作成した。これで FPGA ビットストリームを生成し、XSA を出力した。
axi_interconnect_1
S00_AXI
S01_AXIACLK
ARESETNS00_ACLK

axi_dma_1

S00_ARESETN
M00_AXI
M00_ACLK

M_AXI_MM2S
M01_AXI

S_AXI_LITE

M02_AXI

S_AXIS_S2MM

M00_ARESETNM_AXI_S2MM

M01_ACLK

M_AXIS_MM2S
s_axi_lite_aclk

M01_ARESETN

mm2s_prmry_reset_out_n

axi_interconnect_0

m_axi_mm2s_aclk
S01_ACLK

zynq_ultra_ps_e_0

s2mm_prmry_reset_out_nm_axi_s2mm_aclk

S01_ARESETN

mm2s_introut

S00_AXI

M_AXI_HPM0_FPD

axi_resetn
M02_ACLK

s2mm_introut

M02_ARESETN

S01_AXI

M_AXI_HPM0_LPD

ACLK

AXI Direct Memory Access

GPIO_0

ARESETNGPIO_SENSORSUART_0S_AXI_HPC0_FPD

AXI Interconnect

S00_ACLK

emio_uart0_ctsn
M00_AXI

maxihpm0_fpd_aclk

S00_ARESETN

BT_ctsnemio_uart0_rtsn

BT_rtsn

UART_1

UART1maxihpm0_lpd_aclk
M00_ACLKsaxihpc0_fpd_aclk

HLS_accel_1

proc_sys_reset

M00_ARESETN

pl_resetn0
pl_ps_irq0[0:0]S01_ACLK

pl_clk0

S01_ARESETN

pl_clk1s_axi_CONTROL_BUS
slowest_sync_clk

mb_reset
INPUT_STREAM

ext_reset_in

OUTPUT_STREAM

bus_struct_reset[0:0]pl_clk2
ap_clkaux_reset_ininterrupt

peripheral_reset[0:0]

AXI Interconnect

pl_clk3

ap_rst_nmb_debug_sys_rst
dcm_lockedinterconnect_aresetn[0:0]
peripheral_aresetn[0:0]

Hls_accel (Pre-Production)

Zynq UltraScale+ MPSoC

Processor System Reset
UART0_ctsn
axi_uart16550_0
UART
S_AXI

ctsn

s_axi_aclk

rtsn

s_axi_aresetn
freeze

UART0_rtsn

sin
sout

UART0_txd

ip2intc_irpt

AXI UART16550
UART0_rxd

図 B.9

HLS_accel をブロックデザインに追加し、AXI DMA を介して PS と接続した

B.2.2 カーネルモジュール u-dma-buf の利用
シンプル DMA モードにしたので、Linux のユーザ空間から DMA 転送するのに連続したメモリ領域を確保する必要がある。それをするのに u-dma-buf5 を用いた。これは UIO を使ってユーザ空間でデバイスドライバを動かす
場合の DMA バッファを提供する。
まず PetaLinux のプロジェクトディレクトリに cd し、カーネルモジュールの雛形を作成した。

5 https://github.com/ikwzm/udmabuf

付録 B Ultra96-V2 を用いた開発パスの確認と物体検出処理の高速化

66

petalinux-create -t modules --name u-dma-buf --enable
こ れ で project-spec/meta-user/recipes-modules/u-dma-buf/ に テ ン プ レ ー ト が で き る 。こ の 配 下の files/u-dma-buf.c を GitHub から git clone した u-dma-buf.c と差し替え、モジュールをビルドする。

cd project-spec/meta-user/recipes-modules/u-dma-buf/files/
git clone -b u-dma-buf-master https://github.com/ikwzm/udmabuf.git
cp udmabuf/u-dma-buf.c .
petalinux-build -c u-dma-buf
AXI DMA と HLS_accel を UIO を使ってアクセスできるよう、コードブロック B.3 のようにデバイスツリー6を編集した。

/include/ "system-conf.dtsi"/ {chosen {bootargs = "console=ttyPS0,115200 earlyprintk uio_pdrv_genirq.of_id=genericuio rootfstype=ext4 root=/dev/mmcblk0p2 rw rootwait";
stdout-path = "serial0:115200n8";};
u-dma-buf@0 {compatible = "ikwzm,u-dma-buf";
device-name = "u-dma-buf0";
size = <0x080000>; // 0x080000 Bytes = 524288 Bytes = 512 KiB
dma-coherent;};
u-dma-buf@1 {compatible = "ikwzm,u-dma-buf";
device-name = "u-dma-buf1";
size = <0x080000>; // 0x080000 Bytes = 524288 Bytes = 512 KiB
dma-coherent;};};&axi_dma_1 {compatible = "generic-uio";
dma-coherent;};&HLS_accel_1 {compatible = "generic-uio";};
6

project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi

B.2 ニューラルネットワークの行列演算をハードウェア化する

コードブロック B.3

67

編集したデバイスツリー

petalinux-build
ですべてをビルドし、これまで通りパッケージングをして SD カードの作成をし、Ultra96-V2 を起動した。

B.2.3 行列演算 IP のテスト
Zynq MPSoC
Linux
C programs
dma_simple.h
dmasimple.c
matrix.c

u-dma-buf/dev/u-dma-buf0/dev/u-dma-buf1

AXI DMA/dev/uio4PS

図 B.10A, B
AXI4-Stream

C = AB

HLS_accel(IP)/dev/uio5

行列乗算

PL

HLS_accel を用いた行列演算のためのソフトウェア、ファームウェア構造

Linux を起動すると、/dev/uio4 に HLS_accel が、/dev/uio5 に AXI DMA が割り当てられた。また u-dmabuf が /dev/u-dma-buf0 と /dev/u-dma-buf1 に割り当てられていた。2 つあるのはデータの入力と出力のためである。

root@ultra96v2-oob-2019-2:~# ls /dev/uio
uio0

uio1

uio2

uio3

uio4

uio5

root@ultra96v2-oob-2019-2:~# cat /sys/class/uio/uio*/name
axi-pmonaxi-pmonaxi-pmonaxi-pmon
HLS_acceldma
HLS_accel にデバイスファイルを割り当てているのは、使用開始時に制御インターフェイスのオフセット 0 のアド
レスに 0x81 を書く必要があるためである。 /sys/class/u-dma-buf/u-dma-buf*/size には 524288 （これは 10 進数で、デバイスツリーで指定した 0x8000 に対応）が書かれており、/sys/class/u-dma-buf/u-dma-buf*/phys_addr にはメモリの開始アドレスが書かれていた。
root@ultra96v2-oob-2019-2:~# cat /sys/class/u-dma-buf/u-dma-buf*/size
524288524288root@ultra96v2-oob-2019-2:~# cat /sys/class/u-dma-buf/u-dma-buf*/phys_addr
0x000000005fd00000
0x000000005fd80000

付録 B Ultra96-V2 を用いた開発パスの確認と物体検出処理の高速化

68

u-dma-buf のカーネルモジュールは /lib/modules/4.19.0-xilinx-v2019.2/extra/u-dma-buf.ko であるので、これをモジュールとしてロードした。

# insmod u-dma-buf.ko u-dma-buf0=1048576 u-dma-buf1=1048576
insmod: ERROR: could not insert module u-dma-buf.ko: File exists
このエラーはもうロード済みだったことを示しており、無視して良い。
さて HLS_accel を使って行列演算ができるか、動作確認をした。コードブロック B.4 は HLS_accel での行列計算の結果を単純にソフトウェアでの計算結果と比較するプログラム matrix.c の一部である。ここでは最初に行列 a ,b の要素を intake_buf.buf にコピーしている。DMA への入力 intake_buf.buf と出力 outlet_buf.buf のアドレスを、 dma_setup 関数で設定している。 dma_start で転送サイズを書いて転送が開始される（1 要素 4 B
なのですべての要素数の 4 倍）。 outlet_buf.buf への DMA 転送が完了するまで dma_wait_irq で待つ。転送が完了したら outlet_buf.buf から要素を c に取り出して、ソフトウェアで計算した cref と値を比較している。
詳細な説明は奥畑（2019）を参照されたい。

for (i = 0; i < m; i++) {for (j = 0; j < n; j++) {((float *)(intake_buf.buf))[i * n + j] = a[i * n + j];// Copy matrix a}}for (i = 0; i < m; i++) {for (j = 0; j < n; j++) {((float *)(intake_buf.buf))[i * n + j + m * m] =b[i * n + j];// Copy matrix b}}// Set the addresses of AXI DMA input intake_buf.buf and output outlet_buf.buf
dma_setup(dma_regs, intake_buf.phys_addr, outlet_buf.phys_addr);// Start DMA transfer (i.e. starting matrix calculation process)dma_outlet_start(dma_regs, (m * m * 4));
dma_intake_start(dma_regs, (m * m * 2 * 4));// Wait for the transfer
dma_wait_irq(dma_regs);
dma_clear_status(dma_regs);for (i = 0; i < m; i++) {for (j = 0; j < n; j++) {// Copy values in DMA buffer into the matrix cc[i * n + j] = ((float *)(outlet_buf.buf))[i * n + j];}B.2 ニューラルネットワークの行列演算をハードウェア化する}// Software-based calculation of matrix creffor (i = 0; i < m; i++) {for (j = 0; j < n; j++) {float sum = 0;
for (t = 0; t < k; t++) { sum += a[i * k + t] * b[t * n + j]; }cref[i * n + j] = sum;}}// Compare c and cref
int cnt_ok = 0;
int cnt_ng = 0;
for (i = 0; i < m * m; i++) {if (c[i] == cref[i]) {cnt_ok++;} else {printf("NG: hw %f, sw %f\n", c[i], cref[i]);cnt_ng++;}}// Print the result of comparison above
printf("OK: %d, NG: %d, Total: %d\n", cnt_ok, cnt_ng, (m * m));
コードブロック B.4 HLS_accel による行列計算結果をソフトウェアでの計算結果と比較するプログラム matrix.c の一部

これをコンパイルし実行すると、HLS_accel で計算した値とソフトウェアで計算した値が正しく一致したことが確かめられた。

# gcc -O0 matrix.c dma_simple.c# ./a.out
OK: 1024, NG: 0, Total: 1024

B.2.4 YOLOv3 の高速化
HLS_accel を用いて YOLOv3 での物体検出処理がどのくらい高速化できるのかを試した。
まず https://github.com/pjreddie/darknet.git のコミットハッシュ f6d8617 のものを git clone して、HLS_accel を使わずに処理をした。

# First, logged in to Linux running on Ultra96-V2
git clone -b f6d8617 https://github.com/pjreddie/darknet.git
cd darknet

69

付録 B Ultra96-V2 を用いた開発パスの確認と物体検出処理の高速化

70
make

wget https://pjreddie.com/media/files/yolov3.weights # Download pre-trained weights./darknet detect cfg/yolov3.cfg yolov3.weights data/dog.jpg # Detect
モデルが形成され、検出が行われる。出力結果の画像は predictions.png に反映された。

data/dog.jpg: Predicted in 149.737438 seconds.
dog: 100%truck: 92%
bicycle: 99%
この処理を 10 回行い実行時間の平均をとると 149.86 s であった。
次に FPGA の HLS_accel を使うように、 git clone したリポジトリ darknet/ の以下のソースコードを編集した。どのように編集したかも奥畑（2019）を参照されたい。

• src/convolutional_layer.c• examples/detector.c• includes/darknet.h• Makefile
また dma_simple.c と dma_simple.h を src/ に配置して、コンパイルし検出処理を実行した。

make./darknet detect cfg/yolov3.cfg yolov3.weights data/dog.jpg
10 回処理時間の測定を行ったところ平均は 148.15 s となり、処理は 2 s ほど早くなった（図 B.11）。

図 B.11

物体検出処理時間の結果。ハードウェアベースの HLS_accel を用いた処理の方が 2 s ほど早くなった。

革新的に高速化ができたとは言えないが、HLS_accel が正しく動作しハードウェアベースの処理ができたと考えられる。さらなる高速化のための手法として挙げられるのは、• 行列のサイズを 32 × 32 から 64 × 64 に大きくする

B.2 ニューラルネットワークの行列演算をハードウェア化する• クロック周波数（ここでは 100 MHz）を上げる• データ転送時のデータ幅（ここでは 32 bit）を拡張しサイクル数を減らすなどが考えられる。

71

73

付録 C

Linux からのメモリアクセスによるモジュー
ルの操作
Ubuntu ならば devmem というコマンドを使うことで、ユーザ空間から任意のメモリにアクセスすることができるが、CentOS 7 は Ubuntu とは系統が異なるためか、そのようなコマンドは存在していないようだった。しかしCentOS 7 にも /dev/mem という、Linux カーネルが使用できるすべての物理アドレス空間のキャラクターデバイ
スが存在する。これを open し mmap することで、Ubuntu の devmem と同様の機能を持つソフトウェアを作成することができた。その例をコードブロック C.1 に示す。ソースコードの初めに define している PHYS_ADDR で、
図 2.9 の [Address Editor]で割り振った物理アドレスを指定している。

#include <fcntl.h>// open() etc.

#include <stdint.h>// uintX_t etc.

#include <stdio.h>// printf() etc.

#include <sys/mman.h>// mmap() etc.

#include <sys/stat.h>// open() etc.

#include <sys/types.h>// open() etc.

#include <unistd.h>// sysconf() etc.

#define PHYS_ADDR 0xA0000000
int main() {
int

fd;

uint32_t

page_size = sysconf(_SC_PAGESIZE);

uint32_t

phys_addr, page_addr, page_offset;

volatile uint32_t* ptr;// Open /dev/mem with read-write mode.
fd = open("/dev/mem", O_RDWR);// File Descriptor. fd >= 0 if successful

if (fd < 0) {printf("Error opening /dev/mem\n");return -1;}

付録 C Linux からのメモリアクセスによるモジュールの操作

74// Initialize ptr
phys_addr= PHYS_ADDR;

page_addr= (phys_addr & ~(page_size - 1));

page_offset = phys_addr - page_addr;
ptr= mmap(NULL, page_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd,
page_addr);

if (ptr == MAP_FAILED) {printf("Failed to map physical address.\n");close(fd);return -1;}
ptr += page_offset;
uint32_t offset = 0;
uint32_t data

= 0xdeadbeef;// Readprintf("offset = %d, \tdata = 0x%x\n", offset, *(ptr + offset));// Write*(ptr + offset) = data;// Read again
printf("offset = %d, \tdata = 0x%x\n", offset, *(ptr + offset));close(fd);return 0;}
コードブロック C.1

devmem と同様の機能を持つ C 言語によるプログラム

たとえばこれを BRAM に対して実行し成功すれば$ gcc -std=c99 -Wall -g -O0 devmem.c -o devmem$ sudo ./devmem
offset = 0, data=0x0
offset = 0, data=0xdeadbeefのように値を読み書きできた。

75

付録 D

Linux からの I2C デバイス操作方法
Zynq MPSoC で走る Linux から I2 C のペリフェラルを操作する方法を確認したので、大事な技術としてここに記しておく。大まかに次のような手順で開発を進める。

1. PetaLinux で I2 C デバイスドライバを有効にする
2. 回路図などから操作したい対象の I2 C デバイスの I2 C スレーブアドレスを確認しておく
3. デバイスツリーに I2 C デバイスの情報を追加する
4. ブートログや i2c-tools を用いて、対象の I2 C デバイスのデバイスファイルを特定する
5. 対象のデバイスファイルを open して値を読み書きする C 言語のアプリケーションを作成し実行する
1、2、3 については節 D.1 で、4 と 5 についてはそれぞれ次の節 D.2 と D.3 で説明する。

D.1 PetaLinux での準備
1 については
petalinux-config -c u-bootでDevice Drivers ---> I2C supportとナビゲートし、図 D.1 のようにデバイスドライバを有効化する。通常デフォルトで有効化されているので、それを確かめる。

2 の段階において、知っておくべきなのは I2 C MUX と対象の I2 C デバイスのスレーブアドレスである。たとえば Endcap SL に搭載されている Si5345 について、図 3.7 の回路図を見れば、ハードウェアで A0、A1が Low になっていることがわかる。このことと Si5345 のデータシートにより（図 D.2）、スレーブアドレスは 0b1101000
すなわち 0x68 であることがわかる。Endcap SL に搭載されている I2 C MUX についても同様に、A0、A1、A2がすべて Low になっていることから、スレーブアドレスは 0x70 であると決定できる。

3 についてはボード上に搭載されている I2 C デバイスによって書き方は変わるが、Endcap SL 上の I2 C MUX についての記述はコードブロック D.1 のようにした1 。Endcap SL 上の I2 C MUX は ZCU102 上のものと同じである
ため、ZCU102 のデバイスツリーを参照した。ここで I2 C スレーブアドレスを入力しておく。

1 https://mjmwired.net/kernel/Documentation/devicetree/bindings/clock/silabs,si5341.txt に Si534x のデバイス

ツリーの書き方が示されているので、これを参考にした。

When in I2C mode, the serial interface operates in slave mode with 7-bit addressing and can operate in Standard-Mode (100 kbps) or
Fast-Mode (400 kbps) and supports burst data transfer with auto address increments. The I2C bus consists of a bidirectional serial dataline (SDA) and a serial clock input (SCL) as shown in Figure 9.4 I2C Write Operation on page 51. Both the SDA and SCL pins must
be connected to a supply via an external pull-up (4.7 kΩ) as recommended by the I2C specification as shown in Figure 9.2 I2C Configuration on page 51. Two address select bits (A0, A1) are provided allowing up to four Si5345/44/42 devices to communicate on thesame bus. This also allows four choices in the I2C address for systems that may have other overlapping addresses for other I2C devices.
付録 D Linux からの I2 C デバイス操作方法

76

I2C

VDD

VDDI2CI2C_SELSDA

To I2C Bus
or HostSCLK

A0LSBs of I2C
Address

A1

Si5345/44/42

Figure 9.2. I2C Configuration
The 7-bit slave device address of the Si5345/44/42 consists
5-bit fixed address plus 2 pins which are selectable for the last two
図 D.1 ofI2 Caデバイスドライバを追加
2
bits, as shown in Figure 9.3 7-bit I C Slave Address Bit-Configuration on page 51.

Slave Address
図 D.2

6

5

4

3

2

1

0

1

1

0

1

0

A1 A0

Figure 9.3. 7-bit I2C Slave Address Bit-Configuration
Si5345 の I2 C スレーブアドレスはこのように決まっている（Silicon Labs 2018）。

Data is transferred MSB first in 8-bit words as specified by the I2C specification. A write command consists of a 7-bit device (slave)address + a write bit, an 8-bit register address, and 8 bits of data as shown in Figure 9.6 SPI Interface Connections on page 53. A
write burst operation is also shown where subsequent data words are written using to an auto-incremented address.

&i2c0 {
Write
Operation
Byte
i2c-mux@70{ –/*Single
U23 */
S

compatible
Slv
Addr [6:0] =0 "nxp,pca9548";
A Reg Addr [7:0] A#address-cells = <1>;

Data [7:0]AP

reg = <0x70>;
Write Operation- Burst (Auto Address Increment)
i2c@3 {S Slv Addr [6:0] 0 A Reg Addr [7:0] A Data [7:0]#address-cells = <1>;A

Data [7:0]#size-cells = <0>;#size-cells = <0>;A

P

Reg Addr +1

reg = <3>;

1 – Read
0 – Write
compatible = "silabs,si5345";
A – Acknowledge (SDA LOW)
Si5345/44/42
N – Not Acknowledge (SDA HIGH)
reg = <0x68>;
S – START condition#clock-cells = <2>;
P – STOP condition
clocks = <40000000>; // 40 MHz

Host si5345b:
Si5345/44/42
clock-generator@68 { /* U1 */Hostclock-names = "in0";

Figure 9.4. I2C Write Operation

out@0 { reg = <0>; };out@1 { reg = <1>; };silabs.com | Building a more connected out@2world. { reg = <2>; };out@3 { reg = <3>; };out@4 { reg = <4>; };Rev. 1.3 | 51

D.2 ブートログや I2 C Tools を用いた I2 C デバイスの確認
out@5 { reg = <5>; };out@6 { reg = <6>; };out@7 { reg = <7>; };out@8 { reg = <8>; };};};i2c@4 {
#address-cells = <1>;#size-cells = <0>;
reg = <4>;si5344b: clock-generator@68 { /* U2 */compatible = "silabs,si5344";
reg = <0x68>;#clock-cells = <2>;
clocks = <40000000>; // 40 MHz
clock-names = "in0";
out@0 { reg = <0>; };out@1 { reg = <1>; };out@2 { reg = <2>; };out@3 { reg = <3>; };};};/* port 7 unconnected */};};コードブロック D.1 Endcap SL 上の I2 C MUX（図 3.8）についてのデバイスツリーの記述

D.2 ブートログや I2 C Tools を用いた I2 C デバイスの確認
ブートファイルを作成し CentOS 7 を起動すれば、Linux が I2 C デバイスを検出したことをコードブロック D.2のようにブートログから確認できる。コードブロック D.2 からは 8 チャンネルの I2 C MUX が i2c-0 として検出され、I2 C スレーブアドレスが 0x70 であることも確認できた。さらに /dev/i2c-* というデバイスファイル。
が /dev/i2c-0 から /dev/i2c-8 まで現れる（コードブロック D.3）

$ dmesg | grep -e i2c -e I2C[

2.821281] i2c /dev entries driver[

3.648600] i2c i2c-0: Added multiplexed i2c bus 1[

3.682426] i2c i2c-0: Added multiplexed i2c bus 2[

3.693040] i2c i2c-0: Added multiplexed i2c bus 3[

3.698014] i2c i2c-0: Added multiplexed i2c bus 4[

3.702981] i2c i2c-0: Added multiplexed i2c bus 5[

3.707866] i2c i2c-0: Added multiplexed i2c bus 677

付録 D Linux からの I2 C デバイス操作方法

78[3.744817] i2c i2c-0: Added multiplexed i2c bus 7[

3.749750] i2c i2c-0: Added multiplexed i2c bus 8[

3.754542] pca954x 0-0070: registered 8 multiplexed busses for I2C switch pca9548[

3.762121] cdns-i2c ff020000.i2c: 400 kHz mmio ff020000 irq 32
コードブロック D.2 ブートログから I2 C デバイスが検出されていることの確認$ ls /dev/i2c-*/dev/i2c-0/dev/i2c-2/dev/i2c-4/dev/i2c-6/dev/i2c-1/dev/i2c-3/dev/i2c-5/dev/i2c-7

コードブロック D.3/dev/i2c-8/dev/i2c-* というデバイスファイルを 9 つ検出

さて i2c-tools はコマンドラインから I2 C デバイスにアクセスするためのパッケージである。CentOS 7 には

sudo yum install -y i2c-toolsを実行すればインストールされるはずである。たとえば i2cdetect というコマンドを -l オプションとともに使え
ば OS が検出している I2 C デバイスの一覧を確認できる。

$ sudo i2cdetect -l
i2c-3

i2c

i2c-0-mux (chan_id 2)

I2C adapter

i2c-1

i2c

i2c-0-mux (chan_id 0)

I2C adapter

i2c-8

i2c

i2c-0-mux (chan_id 7)

I2C adapter

i2c-6

i2c

i2c-0-mux (chan_id 5)

I2C adapter

i2c-4

i2c

i2c-0-mux (chan_id 3)

I2C adapter

i2c-2

i2c

i2c-0-mux (chan_id 1)

I2C adapter

i2c-0

i2c

Cadence I2C at ff020000

I2C adapter

i2c-7

i2c

i2c-0-mux (chan_id 6)

I2C adapter

i2c-5

i2c

i2c-0-mux (chan_id 4)

I2C adapter

コードブロック D.4

i2cdetect -l で使用可能な I2 C デバイスを確認できる

Si5345 の I2 C 信号線は I2 C MUX のポート 3 から延びているため、コードブロック D.4 の結果から /dev/i2c-4 がそのデバイスファイルであると考えられる。 i2cdetect -y -r <i2cbus> を実行すればその I2 C デバイスのア
ドレスをスキャンして、表を出力する。ここで <i2cbus> は I2 C デバイスに付けられた数字であり、今回の場合は 4 となる。出力結果をコードブロック D.5 に示す。返された表の数字はプローブした結果なんらかの反応があったアドレスを表しており、 UU は反応があったがドライバなどによって使用されていることを意味している。ここでは 68 は Si534 のスレーブアドレス 0x68 に一致し、 UU がある 0x70 は I2 C MUX のスレーブアドレスに一致する。したがって Si5345 のデバイスファイルは /dev/i2c-4 であると決定できる。

$ sudo i2cdetect -y -r 4
0
00:

1

2

3

4

5

6

7

8

9

a

b

c

d

e

f

-- -- -- -- -- -- -- -- -- -- -- -- --10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --D.3 ソフトウェアからの I2 C デバイスの操作方法

79

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -70: UU -- -- -- -- -- -- -コードブロック D.5

i2cdetect -y -r 4 の出力結果

i2cdump -y <i2cbus> <address> を実行すればその I2 C デバイスのレジスタの値をダンプして表示してくれる。たとえば i2cdump -y 4 68 を実行すると結果はコードブロック D.6 のようになり、何らかのデータが入っていることが確認できる。

$ i2cdump -y 4 0x68
No size specified (using byte-data access)
0

1

2

3

4

5

6

7

8

f

0123456789abcdef

00: 05 00 45 53 01 03 10 07 00 00 00 68 d9 00 0f ff?.ES????...h?.?.

10: 00 df ff 2f ff 03 02 dc ff 00 00 f6 00 00 00 00.?./.???...?....

20: 00 0f 00 fe 0b 00 00 00 00 00 00 02 00 00 00 00.?.??......?....

30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00................

40: 04 00 00 00 00 0c 00 00 00 00 00 00 00 00 00 00?....?..........

50: 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00?...............

60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00................

70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00................

80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00................

90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00................

a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00................

b0: 00 00 00 00 00 00 00 01 00 c3 31 7b 07 00 00 00.......?.?1{?...

c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00................

d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00................

e0: 00 00 03 00 00 01 00 00 00 00 00 00 00 00 00 00..?..?..........

f0: 00 00 00 00 00 00 0d 03 00 2f ff 00 00 00 0f 00......??./....?.

コードブロック D.6

9

a

b

c

d

e

i2cdump コマンドでレジスタの内容をダンプした結果

D.3 ソフトウェアからの I2 C デバイスの操作方法/dev/i2c-* デバイスファイルをインターフェイスとして Linux のユーザスペースから I2 C デバイスを操作することができる。これには i2c-dev というカーネルモジュールを追加しておく必要がある。START コンディショ
ンや STOP コンディションといった I2 C 特有の操作はこのカーネルモジュールが自動的に行ってくれる。
プレーンな I2 C 通信をするには、 ioctl() 関数を I2C_SLAVE モードで使用して I2 C スレーブアドレスをセッ
トし、 read() / write() 関数を用いてレジスタアドレスやデータを読み書きすればよい。I2 C-read/write をする関数の例をそれぞれコードブロック D.7 とコードブロック D.8 に示す。ただしエラー処理は省略している。

#include <linux/i2c-dev.h>// I2C_SLAVE

付録 D Linux からの I2 C デバイス操作方法

80#include <stdint.h>// uintX_t#include <sys/ioctl.h>// ioctl()

static const char* dev_file ="/dev/i2c-4";// Si5345 (U1) on Endcap SL, connected from the port 3 on// pca9548 (U23)static const uint8_t dev_addr = 0x68;// Si5345 slave address

int i2c_read(uint8_t reg_addr, uint8_t* pdata) {// Open the I2C device file
int fd = open(dev_file, O_RDWR);// Set I2C slave address
int ret = ioctl(fd, I2C_SLAVE, dev_addr);// I2C read
write(fd, &reg_addr, 1);// set register addressread(fd, pdata, 1);// read its dataclose(fd);return 0;}
コードブロック D.7 I2 C-read 関数の例

#include <linux/i2c-dev.h>// I2C_SLAVE#include <stdint.h>// uintX_t#include <sys/ioctl.h>// ioctl()

static const char *dev_file ="/dev/i2c-4";// Si5345 (U1) on Endcap SL, connected from the port 3 on// pca9548 (U23)static const uint8_t dev_addr = 0x68;// Si5345 slave address

int i2c_write(uint8_t reg_addr, uint8_t data) {// Open the I2C device file
int fd = open(dev_file, O_RDWR);// Set I2C slave address
int ret = ioctl(fd, I2C_SLAVE, dev_addr);// I2C writeD.4 Si5345 の操作方法（ページの概念）

81

uint8_t packet[2];packet[0] = reg_addr;
packet[1] = data;
write(fd, packet, 2);close(fd);return 0;}
コードブロック D.8 I2 C-write 関数の例

これらを用いて、たとえば 0xAA のレジスタの値は

uint8_t data = 0;i2c_read(0xaa, &data);
printf("data 0x%02x\n", data);とすれば取得でき、0xBB のレジスタに 0xBB を書き込みたければ

i2c_write(0xaa, 0xbb);とすればよい。

D.4 Si5345 の操作方法（ページの概念）
Si5345 のレジスタアクセスは少し特殊であったため記しておく。Si5345 のレジスタアドレスは 16 bit であるが、その上位 8 bit は「ページ」を表している。つまりたとえばあるレジスタのアドレスが 0x051A ならば、「ページ 0x05 の 0x1A 番目のレジスタ」と解釈する。
各ページの 0x01 番目のレジスタは PAGE register と呼ばれており、最初にここにアクセスしたいレジスタのページを書き込む必要がある。たとえばアドレス 0x051A のレジスタを I2 C-read する場合、1.（現在どのページにいるかはわからないが）アドレス 0x01 のレジスタに 0x05 を書く（ページ 0x05 に移動）
2. アドレス 0x1A のレジスタを読むのように手順を踏む。同様にアドレス 0x051A のレジスタに 0x03 というデータを I2 C-write したいならば、

1.（現在どのページにいるかはわからないが）アドレス 0x01 のレジスタに 0x05 を書く（ページ 0x05 に移動）
2. アドレス 0x1A のレジスタに 0x03 というデータを書くという手順を踏む必要がある。

83

付録 E

XVC 開発の詳細
E.1 PetaLinux での操作
Linux が Userspace I/O（UIO）として Debug Bridge を検出できるよう、デバイスツリーに以下を追加した。ここの debug_bridge_0 というのは図 3.10 のブロックデザイン内の名前と同じにしなくてはならない。

// Allow the Debug Bridge to communicate in the Linux uio space.
&debug_bridge_0 {compatible = "generic-uio";};
コードブロック E.1

debug_bridge_0 の情報をデバイスツリーに追加

また UIO を使えるように

petalinux-config -c kernelにおいてDevice Drivers ---> Userspace I/O driversと進み図 E.1 のようにデバイスドライバを追加する。さらにCPU Power Management ---> CPU Idle ---> [ ] CPU idle PM supporをアンチェックする。

petalinux-config --get-hw-description=<path ot XSA file>に お い て 、Kernel bootargs に uio_pdrv_genirq.of_id=generic-uio cpuidle.off=1 を 追 加 す る 。もし uEnv.txt を使って bootargs を設定しているならば、そこにも追加しておく。
こうして petalinux-build を行う。

CentOS 7 を起動したら、UIO に debug_bridge に割り当てられていることを確認する（コードブロック E.2）。
$ cat /sys/class/uio/uio0/namedebug_bridge
コードブロック E.2 CentOS 7 から debug_bridge が /dev/uio0 に割り当てられている様子

付録 E XVC 開発の詳細

84

図 E.1

E.2

UIO を使うためのデバイスドライバを追加

XVC サーバアプリケーションの開発

もし参照のチュートリアル（anunesgu 2021）のように PetaLinux プロジェクトで XVC サーバアプリケー
ションをコンパイルしたならば、それは PetaLinux が生成する rootfs に組み込まれる。すなわち実行ファイル
が /usr/bin/ に置かれた状態で生成される。しかし今回は Zynq MPSoC にアクセスできる状態であり、PetaLinuxの rootfs ではなく CentOS 7 のものを使用している。そこで PetaLinux の段階では XVC サーバアプリケーション
はコンパイルせず、Zynq MPSoC 上の CentOS 7 でコンパイルした。完成したら実行ファイルを /usr/bin/ に置
けば、PetaLinux が生成する rootfs と同じくコマンドとして利用できるようになる。

XVC サーバアプリケーションのソースコードは、Xilinx 社が GitHub で提供しているもの（Xilinx 2021a）
を利用した。それにデバッグオプションや使い方のメッセージ（コードブロック E.3）を表示するよう変更した。ただしソースコード内で debug_bridge が /dev/uio0 に割り当てられていることをハードコードしている。

xvcserver.c を Zynq MPSoC の CentOS 7 に転送し、そこでデバッグやコンパイルを行った。
$ sudo ./xvcserver0
Xilinx Virtual Cable server starting.
---- Instruction ---0. Make sure you’re going to open /dev/uio0. If needed,change the variable UIO_PATH in the source code.
1. Check my IP address first.
2. Open Hardware Manager in Vivado in your computer.
3. "Open Target" > "Open New Target" > "Local server"> "Add Xilinx Virtual Cable".
4. Enter hostname: <my IP address>, port: 2542.
5. Enjoy!

E.2 XVC サーバアプリケーションの開発--------------------コードブロック E.3 XVC サーバ起動時にはインストラクションメッセージを表示させるようにした

85

87

付録 F

回路図
ここでは説明上必要だった回路図を掲載しておく。
6

5

4

3

2

Module Connector A
VCC_MOD

Module Connector B

VCC_MOD
J800

A1
A3
A5
A7
A9
A11
A13
A15
A17
A19
A21
A23
A25
A27
A29
A31
A33
A35
A37
A39
A41
A43
A45
A47
A49
A51
A53
A55
A57
A59
A61
A63
A65
A67
A69
A71
A73
A75
A77
A79
A81
A83
A85
A87
A89
A91
A93
A95
A97
A99
A101
A103
A105
A107
A109
A111
A113
A115
A117
A119
A121
A123
A125
A127
A129
A131
A133
A135
A137
A139
A141
A143
A145
A147
A149
A151
A153
A155
A157
A159
A161
A163
A165
A167

D
[3]
[3]
[3]
[3]
VCC_3V3

[3]
[3]
[3]
[3]

VCC_IO_BO

[3]
[3]
[3]
[3]

VCC_2V5

C

[3]
[3]
[3]
[3]

VCC_2V5

[3]
[3]
[3]
[3]

VCC_CFG_MIO

[3]
[3]
[3]
[3]

VCC_2V5

[3]
[3]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[5]

B

[9]
[9]
[9,13]
[2]
[2]
[2]
[2]
[15]
[15]
[15]
[15]

[13]
[13]
[13]
[13]
[13]

A

[13]
[13]
[13]
[13]
[13]

IO_BN_L9_AD11_W14_P
IO_BN_L9_AD11_W13_N
IO_BN_L10_AD10_Y14_P
IO_BN_L10_AD10_Y13_N
IO_BN_L12_AD8_Y12_P
IO_BN_L12_AD8_AA12_N
IO_BN_L2_AD14_AG14_P
IO_BN_L2_AD14_AH14_N
IO_BN_L7_HDGC_AA13_P
IO_BN_L7_HDGC_AB13_N
IO_BN_L5_HDGC_AD15_P
IO_BN_L5_HDGC_AD14_N
IO_BO_L7_HDGC_AD5_AD11_P
IO_BO_L7_HDGC_AD5_AD10_N
IO_BO_L1_AD11_AG10_P
IO_BO_L1_AD11_AH10_N
IO_BO_L4_AD8_AE10_P
IO_BO_L4_AD8_AF10_N
IO_BO_L3_AD9_AH12_P
IO_BO_L3_AD9_AH11_N
IO_BO_L2_AD10_AF11_P
IO_BO_L2_AD10_AG11_N
IO_BO_L12_AD0_AB10_P
IO_BO_L12_AD0_AB9_N
IO_BO_L5_HDGC_AD7_AE12_P
IO_BO_L5_HDGC_AD7_AF12_N
PS_MIO51_SDCLK
PS_MIO50_SDCMD
PS_MIO46_SDD0
PS_MIO47_SDD1
PS_MIO48_SDD2
PS_MIO49_SDD3
PS_MIO38_UARTRXPS_MIO39_UARTTXI2C_SCL
I2C_SDAI2C_INT#
JTAG_TDIJTAG_TMS
JTAG_TDO
JTAG_TCK
USB_D_P
USB_D_N
USBH_D_P
USBH_D_N

ETH0_D_N
ETH0_D_P
ETH0_LED1#
ETH0_C_N
ETH0_C_P
ETH0_CTREF
ETH0_B_N
ETH0_B_P
ETH0_LED2#
ETH0_A_N
ETH0_A_P

1

VIN_MOD
VIN_MOD
VIN_MOD
VIN_MOD
VIN_MOD
VIN_MOD
GND
IO_P
IO_N
IO_P
IO_N
GND
IO_P
IO_N
VOUT_3V3
IO_P
IO_N
GND
IO_P
IO_N
VIN_IO
IO_P
IO_N
GND
SCLK_P
SCLK_N
VOUT
IO_P
IO_N
GND
IO_P
IO_N
VOUT
IO_P
IO_N
GND
IO_P
IO_N
VIN_CFG
IO_P
IO_N
GND
PCLK_P
PCLK_N
VOUT
IO_P
IO_N
IO_P
IO_N
GND
IO_P
IO_N
IO_P
IO_N
GND
I2C_SCL
I2C_SDAI2C_INT#
JTAG_TDIJTAG_TMS
JTAG_TDO
JTAG_TCKGND
USB_DP
USB_DM
VBUS_HDP
ID_HDM
GND
USB_SSRX_P
GND
USB_SSRX__N
GND
ETH0_D_N
ETH0_D_P
ETH0_LED1#
ETH0_C_N
ETH0_C_P
ETH0_CTREF
ETH0_B_N
ETH0_B_P
ETH0_LED2#
ETH0_A_N
ETH0_A_P
GND

J801

A

VIN_MOD
VIN_MOD
VIN_MOD
VIN_MODPWR_ENPWR_GOODGND
SCLK_P
SCLK_N
GND
IO_P
IO_N
VOUT_3V3
IO_P
IO_N
GND
IO_P
IO_N
VIN_IO
IO_P
IO_N
GND
PCLK_P
PCLK_N
VOUT_3V3
IO_P
IO_N
GND
IO_P
IO_N
VOUT
IO_P
IO_N
GND
IO_P
IO_N
VIN_CFG
IO_P
IO_N
GND
IO_P
IO_N
VOUT_3V3
IO_P
IO_N
IO_P
IO_N
GND
IO_P
IO_N
VMON
SCLK_P
SCLK_N
GND
RSVD
RSVD
FLASH_DI
FLASH_CS#
FLASH_CLKGND
FLASH_DO
SRST#_RDY#
BOOT_MODE
USB_CPEN
FPGA_DONE
POR#_LOAD#
GND
USB_SSTX_P
GND
USB_SSTX_N
GND
ETH1_D_N
ETH1_D_P
ETH1_LED1#
ETH1_C_N
ETH1_C_P
ETH1_CTREF
ETH1_B_N
ETH1_B_P
ETH1_LED2#
ETH1_A_N
ETH1_A_P
GND
VIN_BAT

A2
A4
A6
A8
A10
A12
A14
A16
A18
A20
A22
A24
A26
A28
A30
A32
A34
A36
A38
A40
A42
A44
A46
A48
A50
A52
A54
A56
A58
A60
A62
A64
A66
A68
A70
A72
A74
A76
A78
A80
A82
A84
A86
A88
A90
A92
A94
A96
A98
A100
A102
A104
A106
A108
A110
A112
A114
A116
A118
A120
A122
A124
A126
A128
A130
A132
A134
A136
A138
A140
A142
A144
A146
A148
A150
A152
A154
A156
A158
A160
A162
A164
A166
A168

PWR_ENPWR_GOOD
IO_BN_L8_HDGC_AB15_P
IO_BN_L8_HDGC_AB14_N
IO_BN_L11_AD9_W12_P
IO_BN_L11_AD9_W11_N
IO_BN_L1_AD15_AE15_P
IO_BN_L1_AD15_AE14_N
IO_BN_L4_AD12_AE13_P
IO_BN_L4_AD12_AF13_N
IO_BN_L3_AD13_AG13_P
IO_BN_L3_AD13_AH13_N
IO_BN_L6_HDGC_AC14_P
IO_BN_L6_HDGC_AC13_N
IO_BO_L8_HDGC_AD4_AB11_P
IO_BO_L8_HDGC_AD4_AC11_N
IO_BO_L9_AD3_AA11_P
IO_BO_L9_AD3_AA10_N
IO_BO_L11_AD1_Y9_P
IO_BO_L11_AD1_AA8_N
IO_BO_L10_AD2_W10_P
IO_BO_L10_AD2_Y10_N
IO_BO_L6_HDGC_AD6_AC12_P
IO_BO_L6_HDGC_AD6_AD12_N
IO_BF_L8_HDGC_AD4_F15_MIO40_P
IO_BF_L8_HDGC_AD4_E15_MIO41_N
IO_BE_L7_HDGC_E10_P
IO_BE_L7_HDGC_D10_N
IO_BE_L8_HDGC_E12_P
IO_BE_L8_HDGC_D11_N
PS_MIO45_SDCD#
PS_MIO44
VMON_INT
PS_MIO42_PERST#
PS_MIO43
VBUS_DETECT
BOOT_MODE1
FLASH_DI
FLASH_CS#
FLASH_CLK
FLASH_DO
PS_SRST#
BOOT_MODE0
USB_CPEN
PS_DONE
PS_POR#

[14]
[14]
[14]
[14]

[2]

[14]

[3]
[3]
[3]
[3]

[14]
VCC_3V3

[14]
[14]

[3]
[3]
[3]
[3]

[14]
VCC_IO_BN

[14]
[14]

[3]
[3]
[3]
[3]

[14]
VCC_3V3

[3]
[3]
[3]
[3]

VCC_2V5VCC_CFG_MIO

[2]
[2]

VCC_3V3

[3]
[3]
[3]
[3]
[5]
[5]
[18]
[2,5]
[5]

[4]
[4]
[4]
[4]
[4]
[4]
[4]
[4]

[15]
[2]
[16]
[16]
[16]

VCC_3V3[16][2,16][2][15][2][2,13,16]

VCC_3V3

[4]
[4]
[4]
[4]
[4]
[4]
[4]
[4]
[4]
[4]
[4]
[4]

[13]
[13]
[13]
[13]
[13]
[13]
[13]
[13]
[13]
[13]

[4]
[4]
[4]
[4]

VCC_IO_B66

VCC_IO_B66
ETH1_D_N
ETH1_D_P
ETH1_LED1#
ETH1_C_N
ETH1_C_P
ETH0_CTREF
ETH1_B_N
ETH1_B_P
ETH1_LED2#
ETH1_A_N
ETH1_A_P

[14]
[14]
[14]
[14]

VCC_3V3

[3]
[3]

[14]
[14]
[4]
[4]

VCC_IO_B66

[3]
[3]
[3]
[3]

[14]
[14]
VCC_3V3

[4]
[4]
[4]
[4]

VCC_3V3

[4]
[4]
[4]
[4]

VCC_BAT

[4]
[4]
[18]

MGT_B224_REFCLK0_Y6_B66_L11_D4_P
MGT_B224_REFCLK0_Y5_B66_L11_C4_N
MGTPS_REFCLK1_E21_B66_L1_G1_P
MGTPS_REFCLK1_E22_B66_L1_F1_N
MGTPS_TX0_E25_MGT_B224_TX0_W4_P
MGTPS_TX0_E26_MGT_B224_TX0_W3_N
MGTPS_TX1_D23_MGT_B224_TX1_U4_P
MGTPS_TX1_D24_MGT_B224_TX1_U3_N
MGTPS_TX2_C25_MGT_B224_TX2_R4_P
MGTPS_TX2_C26_MGT_B224_TX2_R3_N
MGTPS_TX3_B23_MGT_B224_TX3_N4_P
MGTPS_TX3_B24_MGT_B224_TX3_N3_N
MGT_B224_TX0_W4_B66_L2_E1_P
MGT_B224_TX0_W3_B66_L2_D1_N
MGT_B224_TX1_U4_B66_L3_F2_P
MGT_B224_TX1_U3_B66_L3_E2_N
IO_B66_L12_GC_C3_P
IO_B66_L12_GC_C2_N
MGT_B224_TX2_R4_B66_L4_G3_P
MGT_B224_TX2_R3_B66_L4_F3_N
MGT_B224_TX3_N4_B66_L5_E4_P
MGT_B224_TX3_N3_B66_L5_E3_N
IO_B66_L7_AD13_C1_P
IO_B66_L7_AD13_B1_N
IO_B66_L6_AD6_G5_P
IO_B66_L6_AD6_F5_N
IO_B66_L8_AD5_A2_P
IO_B66_L8_AD5_A1_N
IO_B66_L9_AD12_B3_P
IO_B66_L9_AD12_A3_N
IO_B66_L10_AD4_B4_P
IO_B66_L10_AD4_A4_N
IO_B66_L19_AD9_B5_P
IO_B66_L19_AD9_A5_N
IO_B66_L20_AD1_C6_P
IO_B66_L20_AD1_B6_N
IO_B66_L21_AD8_A7_P
IO_B66_L21_AD8_A6_N
IO_B66_L23_A9_P
IO_B66_L23_A8_N
IO_B66_L13_GC_D7_P
IO_B66_L13_GC_D6_N
IO_B66_L22_AD0_C8_P
IO_B66_L22_AD0_B8_N
IO_B66_L24_C9_P
IO_B66_L24_B9_N
IO_B66_L18_AD2_E9_P
IO_B66_L18_AD2_D9_N
IO_B66_L17_AD10_F8_P
IO_B66_L17_AD10_E8_N
IO_B66_L14_GC_E5_P
IO_B66_L14_GC_D5_N
IO_B66_L16_AD3_G8_P
IO_B66_L16_AD3_F7_N
IO_B66_L15_AD11_G6_P
IO_B66_L15_AD11_F6_N
VMON_0V9

B1
B3
B5
B7
B9
B11
B13
B15
B17
B19
B21
B23
B25
B27
B29
B31
B33
B35
B37
B39
B41
B43
B45
B47
B49
B51
B53
B55
B57
B59
B61
B63
B65
B67
B69
B71
B73
B75
B77
B79
B81
B83
B85
B87
B89
B91
B93
B95
B97
B99
B101
B103
B105
B107
B109
B111
B113
B115
B117
B119
B121
B123
B125
B127
B129
B131
B133
B135
B137
B139
B141
B143
B145
B147
B149
B151
B153
B155
B157
B159
B161
B163
B165
B167

FX10A-168S-SV

GND
IO_P
IO_N
IO_P
IO_N
GND
MGT_TX0_P
GND
MGT_TX0_N
GND
MGT_TX1_P
GND
MGT_TX1_N
GND
MGT_TX2_P
GND
MGT_TX2_N
GND
MGT_TX3_P
GND
MGT_TX3_N
GND
IO_P
IO_N
GND
IO_P
IO_N
VOUT_3V3
IO_P
IO_N
GND
IO_P
IO_N
VIN_IO
IO_P
IO_N
GND
IO_P
IO_N
VOUT_3V3
IO_P
IO_N
GND
IO_P
IO_N
IO_P
IO_N
VIN_IO
IO_P
IO_N
IO_P
IO_N
GND
IO_P
IO_N
IO_P
IO_N
VOUT_3V3
IO_P
IO_N
GND
IO_P
IO_N
VOUT_3V3
IO_P
IO_N
IO_P
IO_N
GND
IO_P
IO_N
VIN_IO
IO_P
IO_N
GND
IO_P
IO_N
VOUT_3V3
IO_P
IO_N
GND
IO_P
IO_N
VMON

B

GND
MGT_CLK0_P
MGT_CLK0_N
VMON
MGT_CLK1_P
MGT_CLK1_N
GND
MGT_RX0_P
GND
MGT_RX0_N
GND
MGT_RX1_P
GND
MGT_RX1_N
GND
MGT_RX2_P
GND
MGT_RX2_N
GND
MGT_RX3_P
GND
MGT_RX3_N
GND
IO_P
IO_N
VOUT
IO_P
IO_N
GND
IO_P
IO_N
VIN_IO
IO_P
IO_N
GND
IO_P
IO_N
VOUT
IO_P
IO_N
GND
IO_P
IO_N
VIN_IO
IO_P
IO_N
IO_P
IO_N
GND
IO_P
IO_N
IO_P
IO_N
VOUT
IO_P
IO_N
IO_P
IO_N
GND
IO_P
IO_N
IO_P
IO_N
VOUT
IO_P
IO_N
GND
IO_P
IO_N
VIN_IO
IO_P
IO_N
GND
IO_P
IO_N
VOUT_3V3
IO_P
IO_N
GND
IO_P
IO_N
IO_P
IO_N
VMON

B2
B4
B6
B8
B10
B12
B14
B16
B18
B20
B22
B24
B26
B28
B30
B32
B34
B36
B38
B40
B42
B44
B46
B48
B50
B52
B54
B56
B58
B60
B62
B64
B66
B68
B70
B72
B74
B76
B78
B80
B82
B84
B86
B88
B90
B92
B94
B96
B98
B100
B102
B104
B106
B108
B110
B112
B114
B116
B118
B120
B122
B124
B126
B128
B130
B132
B134
B136
B138
B140
B142
B144
B146
B148
B150
B152
B154
B156
B158
B160
B162
B164
B166
B168

MGTPS_REFCLK0_F23_MGT_B224_REFCLK0_Y6_P
MGTPS_REFCLK0_F24_MGT_B224_REFCLK0_Y5_N
VMON_1V2
MGTPS_REFCLK1_E21_MGT_B224_REFCLK1_V6_P
MGTPS_REFCLK1_E22_MGT_B224_REFCLK1_V5_N
MGTPS_RX0_F27_MGT_B224_RX0_Y2_P
MGTPS_RX0_F28_MGT_B224_RX0_Y1_N
MGTPS_RX1_D27_MGT_B224_RX1_V2_P
MGTPS_RX1_D28_MGT_B224_RX1_V1_N
MGTPS_RX2_B27_MGT_B224_RX2_T2_P
MGTPS_RX2_B28_MGT_B224_RX2_T1_N
MGTPS_RX3_A25_MGT_B224_RX3_P2_P
MGTPS_RX3_A26_MGT_B224_RX3_P1_N
MGT_B224_RX0_Y2_B65_L11_K4_P
MGT_B224_RX0_Y1_B65_L11_K3_N
MGT_B224_RX1_V2_B65_L3_U8_P
MGT_B224_RX1_V1_B65_L3_V8_N
MGT_B224_RX2_T2_B65_L4_R8_P
MGT_B224_RX2_T1_B65_L4_T8_N
MGT_B224_RX3_P2_B65_L5_R7_P
MGT_B224_RX3_P1_B65_L5_T7_N
IO_B65_L6_AD6_R6_P
IO_B65_L6_AD6_T6_N
IO_B65_L12_GC_L3_P
IO_B65_L12_GC_L2_N
IO_B65_L7_AD13_L1_P
IO_B65_L7_AD13_K1_N
IO_B65_L8_AD5_J1_P
IO_B65_L8_AD5_H1_N
IO_B65_L9_AD12_K2_P
IO_B65_L9_AD12_J2_N
IO_B65_L16_AD3_P7_P
IO_B65_L16_AD3_P6_N
IO_B65_L10_AD4_H4_P
IO_B65_L10_AD4_H3_N
IO_B65_L19_AD9_J5_P
IO_B65_L19_AD9_J4_N
IO_B65_L20_AD1_J6_P
IO_B65_L20_AD1_H6_N
IO_B65_L21_AD8_J7_P
IO_B65_L21_AD8_H7_N
IO_B65_L24_SDA_H9_P
IO_B65_L24_PERST#_H8_N
IO_B65_L13_GC_L7_P
IO_B65_L13_GC_L6_N
IO_B65_L22_AD0_K8_P
IO_B65_L22_AD0_K7_N
IO_B65_L23_SCLK_K9_P
IO_B65_L23_J9_N
IO_B65_L18_AD2_M8_P
IO_B65_L18_AD2_L8_N
IO_B65_L14_GC_M6_P
IO_B65_L14_GC_L5_N
IO_B65_L15_AD11_N7_P
IO_B65_L15_AD11_N6_N
IO_B65_L17_AD10_N9_P
IO_B65_L17_AD10_N8_N
VMON_PSINT

D

[14]
[14]
[6,18]
[14]
[14]
[14]
[14]
[14]
[14]
[14]
[14]
[14]
[14]

VCC_1V8

[14]
[14]
[14]
[14]
[14]
[14]

VCC_IO_B65

[4]
[4]

VCC_1V8

[4]
[4]
[4]
[4]

VCC_IO_B65

[4]
[4]
[4]
[4]
[4]
[4]
[4]
[4]

VCC_1V8

[4]
[4]
[4]
[4]
[4]
[4]
[4]
[2,4]

B
VCC_1V8

[4]
[4]
[4]
[4]

VCC_IO_B65

[4]
[4]
[4]
[4]

VCC_3V3

[4]
[4]
[4]
[4]
[4]
[4]
[18]

A

FX10A-168S-SV

Copyright© 2019 by Enclustra GmbH

Sheet Name

08_MODULE_CONNECTORS_A_B

Customer No

0000

Revision

R1.2

Company

Enclustra FPGA Solution Center

Project

Mercury XU5Project No

445

Designed

MHEI

図 F.1

Mercury XU5 のコネクタ A と B

DNE = do not equip
Date

29 Aug 2019

C

[14]
[14]

Confidential
Sheet/sheets

8 / 22

付録 F 回路図

88

5

4

3

2

1

+12V0D+VO3V3D

MPSoC/Connector for
Mezzanine Card A

3
C348
1U

C349
1U

C350
1U

C351
1U

C352
1U

C353
1U

3

Mercury_XU5
2
2
4

C344
GCM188R71C155KA64J

4

C

B

169

TAB

CN53-229, 38, 41, 50, 74, 77ピンへ付ける

CN53-1
VIN_MOD
VIN_MOD
VIN_MOD
VIN_MOD
VIN_MOD
VIN_MOD
GND
IO_P
IO_N
IO_P
IO_N
GND
IO_P
IO_N
VOUT_3V3
IO_P
IO_N
GND
IO_P
IO_N
VIN_IO
IO_P
IO_N
GND
SCLK_P
SCLK_N
VOUT
IO_P
IO_N
GND
IO_P
IO_N
VOUT
IO_P
IO_N
GND
IO_P
IO_N
VIN_CFG
IO_P
IO_N
GND
PCLK_P
PCLK_N
VOUT
IO_P
IO_N
IO_P
IO_N
GND
IO_P
IO_N
IO_P
IO_N
GND
I2C_SCL
I2C_SDAI2C_INT#
JTAG_TDIJTAG_TMS
JTAG_TDO
JTAG_TCKGND
USB_DP
USB_DM
VBUS_HDP
ID_HDM
GND
USB_SSRX_P
GND
USB_SSRX_N
GND
ETH0_D_N
ETH0_D_P
ETH0_LED1#
ETH0_C_N
ETH0_C_P
ETH0_CTREF
ETH0_B_N
ETH0_B_P
ETH0_LED2#
ETH0_A_N
ETH0_A_P
GND

1
3
5
7
9
11
13
15
17
19
21
23
25
27
29
31
33
35
37
39
41
43
45
47
49
51
53
55
57
59
61
63
65
67
69
71
73
75
77
79
81
83
85
87
89
91
93
95
97
99
101
103
105
107
109
111
113
115
117
119
121
123
125
127
129
131
133
135
137
139
141
143
145
147
149
151
153
155
157
159
161
163
165
167

+VO3V3D

QSFP+ control+VO3V3D
I2C0RSTFIRINTFIRRST+VO3V3D

R103

R104

10K

10K

R105

R106

R107

100

10K

10K

LOS0
LOS1

FireFly control

C354
0.1U
C358 0.1U

Jitter cleaner status
ZYSYCLPZYSYCLN

C359 0.1U

MPSoC system clock
originatingfrom jitter cleaner

SPIUAZ2ISPIUAI2ZFPALERT1
FPTHERM1ZYALERT1+VO3V3DZYTHERM1SDIODET

SDCLK
SDCMD
SDD0
SDD1

JP2
2

1
2
3

1

SOLUAI2ZSOLUAZ2I

3

JPSW3

SDD2
SDD3

microSD card
data & control

JP4
I2C0SCL
I2C0SDAJTAGTDIJTAGTMSJTAGTDOJTAGTCK

2

1
2
3

1
ZYUARTRXZYUARTTX

3

I2C master
JTAG slavefrom external PC or IPMC

JPSW3UART for debug

PSETHAPPSETHANZYEHLEA2
PSETHBNPSETHBPPSETHCPPSETHCNZYEHLEA1
PSETHDN
PSETHDP

2020302

FX10A-168P-SV(71)

C345
GCM188R71C155KA64J+12V0D+12V0D

D

A

SY1
1
1

Gigabit Ethernet
for DCS & TDAQ server (Spare)
Gigabit Ethernet
for DCS & TDAQ server
170

TAB

VIN_MOD
VIN_MOD
VIN_MOD
VIN_MODPWR_ENPWR_GOODGND
SCLK_P
SCLK_N
GND
IO_P
IO_N
VOUT_3V3
IO_P
IO_N
GND
IO_P
IO_N
VIN_IO
IO_P
IO_N
GND
PCLK_P
PCLK_N
VOUT_3V3
IO_P
IO_N
GND
IO_P
IO_N
VOUT
IO_P
IO_N
GND
IO_P
IO_N
VIN_CFG
IO_P
IO_N
GND
IO_P
IO_N
VOUT_3V3
IO_P
IO_N
IO_P
IO_N
GND
IO_P
IO_N
VMON
SCLK_P
SCLK_N
GND
RSVD
RSVD
FLASH_DI
FLASH_CS#
FLASH_CLKGND
FLASH_DO
SRST#_RDY#
BOOT_MODE
USB_CPEN
FPGA_DONE
POR#_LOAD#
GND
USB_SSTX_P
GND
USB_SSTX_N
GND
ETH1_D_N
ETH1_D_P
ETH1_LED1#
ETH1_C_N
ETH1_C_P
ETH1_CTREF
ETH1_B_N
ETH1_B_P
ETH1_LED2#
ETH1_A_N
ETH1_A_P
GND
VIN_BAT

2
4
6
8
10
12
14
16
18
20
22
24
26
28
30
32
34
36
38
40
42
44
46
48
50
52
54
56
58
60
62
64
66
68
70
72
74
76
78
80
82
84
86
88
90
92
94
96
98
100
102
104
106
108
110
112
114
116
118
120
122
124
126
128
130
132
134
136
138
140
142
144
146
148
150
152
154
156
158
160
162
164
166
168

C347
GCM188R71C155KA64J+VO3V3D

R98

R99

10K

10K

R100

R101

R102

100

10K

10K

EN3RD
PGZYNQ

D

C355
0.1U
C356 0.1U
SUBCLKP2

FIRSEL0FIRSEL1+VO3V3DFIRSEL2FIRSEL3FIRSEL4FIRSEL5

SUBCLKN2
C357 0.1U+VO3V3DFIRSEL6FIRSEL7+VO3V3DFIRSEL8FIRSEL9CFIRSEL10FIRSEL11FIRSEL12FIRSEL13FIRSEL14FIRSEL15+VO3V3D

FireFly module selectFIRSEL16FIRSEL17FIRSEL[19:0]+VO3V3DFIRSEL18
FIRSEL19

OPEN=1
CLOSE=0

JP3
1
2 1
2

VMONPL

BOOTMOD1

JPSW2

R108
470

JP5
1
2 1
2

PSSRST
PSDONEPSPORFIRSEL0FIRSEL1FIRSEL2FIRSEL3FIRSEL4FIRSEL5FIRSEL6FIRSEL7FIRSEL8FIRSEL9FIRSEL10FIRSEL11FIRSEL12FIRSEL13FIRSEL14FIRSEL15FIRSEL16FIRSEL17FIRSEL18
FIRSEL19

B

JPSW2

R109
470

MPSoC boot mode select & reset

PLETHAPPLETHANZYEHLEB2
PLETHBNPLETHBP
PLETHCPPLETHCNZYEHLEB1
PLETHDN
PLETHDP20210302

信号順変更

A

FX10A-168P-SV(71)

信号順変更

Title
Size
A3
Date:
5

C346
GCM188R71C155KA64J

4

3

2

図 F.2 Endcap SL 上の Mercury XU5 とのコネクタ A

Endcap Sector Logic
Connector for Mezzanine Card A
Document Number<Doc>
Tuesday, June 01, 2021

Rev
<RevCode>
Sheet
1

39

of

50

89

5

4

3

2

1

+VO1V8D

MPSoC/Connector for
Mezzanine Card B

青字はスワップ不可
C360
1U

C361
1U

C362
1U

C363
1U

C364
1U

C365
1U

64, 67, 88, 95, 140, 143ピンへ付ける

D

D

C366 0.01U/1005
SUBCLKP3
CN54-1

C

B

A

169

GND
MGT_B224_REFCLK0_P
MGT_B224_REFCLK0_N
IO_P
IO_N
GND
MGT_TX_P
GND
MGT_TX_N
GND
MGT_TX_P
GND
MGT_TX_N
GND
MGT_TX_P
GND
MGT_TX_N
GND
MGT_TX_P
GND
MGT_TX_N
GND
IO_P
IO_N
GND
IO_P
IO_N
VOUT_3V3
IO_P
IO_N
GND
IO_P
IO_N
VIN_IO
IO_P
IO_N
GND
IO_P
IO_N
VOUT_3V3
IO_P
IO_N
GND
IO_P
IO_N
IO_P
IO_N
VIN_IO
IO_P
IO_N
IO_P
IO_N
GND
IO_P
IO_N
IO_P
IO_N
VOUT_3V3
IO_P
IO_N
GND
IO_P
IO_N
VOUT_3V3
IO_P
IO_N
IO_P
IO_N
GND
IO_P
IO_N
VIN_IO
IO_P
IO_N
GND
IO_P
IO_N
VOUT_3V3
IO_P
IO_N
GND
IO_P
IO_N
TAB
VMON

1
3
5
7
9
11
13
15
17
19
21
23
25
27
29
31
33
35
37
39
41
43
45
47
49
51
53
55
57
59
61
63
65
67
69
71
73
75
77
79
81
83
85
87
89
91
93
95
97
99
101
103
105
107
109
111
113
115
117
119
121
123
125
127
129
131
133
135
137
139
141
143
145
147
149
151
153
155
157
159
161
163
165
167

CN54-2

C368 0.01U/1005
SUBCLKN3
AXICCP0
AXICCN0JTAG master to FPGA
Optical Ethernet
for TDAQ server & DCS

C2CRXP0
C2CRXN0+VO3V3D

C2CRXP1C2CRXN1

Serial AXI C2C
to FPGA
using Aurora Protocol

C2CSUBP0
C2CSUBN0
AXICCP1
AXICCN1+VO1V8D

AXICCP2
AXICCN2ZYNQTMSZYNQTCK+VO3V3DZYNQTDIZYNQTDO
SIRST
SILOL
SIINTR
SI44RST

Jitter cleaner control+VO1V8D

SI44LOL
SI44LOSX
SI44INTRINSEL0
INSEL1
CFGPROG
CFGINITCFGDONE

AXI C2C from/to FPGA
+VO3V3D

AXICCP3
AXICCN3
AXICCP4
AXICCN4+VO3V3D

AXICCP5
AXICCN5
AXICCP6
AXICCN6
AXICCP7
AXICCN7+VO1V8D

AXICCP8
AXICCN8AXICCP9
AXICCN9+VO3V3D

AXICCP10
AXICCN10
AXICCP11
AXICCN11170
VMON0V9GND
MGT_CLK_P
MGT_CLK_N
VMON
MGT_B224_REFCLK1_P
MGT_B224_REFCLK1_N
GND
MGT_RX_P
GND
MGT_RX_N
GND
MGT_RX_P
GND
MGT_RX_N
GND
MGT_RX_P
GND
MGT_RX_N
GND
MGT_RX_P
GND
MGT_RX_N
GND
IO_P
IO_N
VOUT
IO_P
IO_N
GND
IO_P
IO_N
VIN_IO
IO_P
IO_N
GND
IO_P
IO_N
VOUT
IO_P
IO_N
GND
IO_P
IO_N
VIN_IO
IO_P
IO_N
IO_P
IO_N
GND
IO_P
IO_N
IO_P
IO_N
VOUT
IO_P
IO_N
IO_P
IO_N
GND
IO_P
IO_N
IO_P
IO_N
VOUT
IO_P
IO_N
GND
IO_P
IO_N
VIN_IO
IO_P
IO_N
GND
IO_P
IO_N
VOUT_3V3
IO_P
IO_N
GND
IO_P
IO_N
IO_P
IO_N
TAB
VMON

2
4
6
8
10
12
14
16
18
20
22
24
26
28
30
32
34
36
38
40
42
44
46
48
50
52
54
56
58
60
62
64
66
68
70
72
74
76
78
80
82
84
86
88
90
92
94
96
98
100
102
104
106
108
110
112
114
116
118
120
122
124
126
128
130
132
134
136
138
140
142
144
146
148
150
152
154
156
158
160
162
164
166
168

C367 0.01U/1005
ZYGTCLPVMON1V2

AXICCP[31:0]

Serial AXI C2Cfrom FPGA
using Aurora Protocol
C370 0.1U/1005
C2CTXP0
C371 0.1U/1005
C2CTXN0+VO1V8D

C2CTXP1
AXICCP12
AXICCN12+VO1V8D

C372 0.1U/1005

AXICCP13
AXICCN13
AXICCP14
AXICCN14C2CTXN1

AXICCP15
AXICCN15
AXICCP16
AXICCN16

C373 0.1U/1005+VO1V8D+VO1V8D

AXICCP19
AXICCN19
AXICCP20
AXICCN20

AXICCN[31:0]
AXICCN1
AXICCN2
AXICCN3
AXICCN4
AXICCN5
AXICCN6
AXICCN7
AXICCN8AXICCN9AXICCN10
AXICCN11
AXICCN12AXICCN13
AXICCN14
AXICCN15
AXICCN16
AXICCN17
AXICCN18
AXICCN19
AXICCN20
AXICCN21
AXICCN22
AXICCN23
AXICCN24
AXICCN25
AXICCN26
AXICCN27
AXICCN28
AXICCN29
AXICCN30
AXICCN31+VO1V8D

AXICCP21
AXICCN21
AXICCP22
AXICCN22
AXICCP23
AXICCN23
AXICCP24
AXICCN24+VO1V8D

AXICCP25
AXICCN25
AXICCP26
AXICCN26+VO1V8D

AXICCP27
AXICCN27
AXICCP28
AXICCN28+VO3V3D

AXICCP30
AXICCN30
AXICCP31
AXICCN31A

VMONPS

Title

Date:
4

3

B

AXICCP29
AXICCN29

Size
A3
5

C

AXI C2C from/to FPGAAXICCP17
AXICCN17
AXICCP18
AXICCN18

FX10A-168P-SV(71)FX10A-168P-SV(71)

AXICCP1
AXICCP2
AXICCP3
AXICCP4
AXICCP5
AXICCP6
AXICCP7
AXICCP8
AXICCP9
AXICCP10
AXICCP11
AXICCP12
AXICCP13
AXICCP14
AXICCP15
AXICCP16
AXICCP17
AXICCP18
AXICCP19
AXICCP20
AXICCP21
AXICCP22
AXICCP23
AXICCP24
AXICCP25
AXICCP26
AXICCP27
AXICCP28
AXICCP29
AXICCP30
AXICCP31ZYGTCLN
C369 0.01U/10052

図 F.3 Endcap SL 上の Mercury XU5 とのコネクタ B

Endcap Sector Logic
Connector for Mezzanine Card B
Document Number<Doc>
Friday, March 12, 2021

Rev
<RevCode>
Sheet
1

40

of

50

91

付録 G

Endcap SL 第 1 試作機で使用したファーム
ウェアのブロックデザイン
Endcap SL に実装したファームウェアのブロックデザインを掲載しておく。
pma_init_generator_0
resetnaur_init_clk

pma_init_in

pma_init_generator_v1_0
axi_chip2chip_0

axi_bram_ctrl_0
m_axi

aurora_64b66b_0

axi_c2c_m2s_intr_out[3:0]

GT_DIFF_REFCLK1

GT_DIFF_REFCLK1

USER_DATA_M_AXIS_RX
USER_DATA_S_AXIS_TX

clk_wiz

AXIS_RXaurora_do_cc

CLK_IN1_D

lockedrsta_busy

BRAM_PORTB

rstb_busy

s_axi_aresetn

AXIS_TX

AXI BRAM Controller
xlconcat_0

aurora_init_clk
m_aresetn

Clocking Wizard

GT_SERIAL_Z2F

BRAM_PORTA

BRAM_PORTB

m_aclkclk100

GT_SERIAL_F2Z

BRAM_PORTA

Block Memory Generator

aurora_pma_init_in

clk125_D

axi_bram_ctrl_0_bram

S_AXI
s_axi_aclk

CORE_STATUS
GT_SERIAL_TX

channel_up

GT_SERIAL_RX

mmcm_not_locked_out

CORE_CONTROL

axi_c2c_s2m_intr_in[3:0]axi_c2c_aurora_channel_up
aurora_mmcm_not_locked
axi_c2c_phy_clk

axi_c2c_link_status_out

In12[0:0]

axi_c2c_multi_bit_error_out

In13[0:0]

axi_c2c_config_error_out

In11[0:0]

aurora_reset_pb

In8[0:0]

aurora_pma_init_out

init_clk
QPLL_CONTROL_OUT

AXI Chip2Chip Bridge

gt_qplllock_quad1_out

In2[0:0]

gt_qpllrefclklost_quad1_out

In3[0:0]

user_clk_out

In9[0:0]

pma_init

In10[0:0]

reset_pb
link_reset_out

In4[0:0]tx_out_clk

In0[0:0]In1[0:0]

sys_reset_out

In5[0:0]

gt_reset_out

In6[0:0]

ila_2

sync_clk_out
gt_powergood[0:0]dout[13:0]

probe0[13:0]

In7[0:0]clk

gt_qpllclk_quad1_out

Concatgt_qpllrefclk_quad1_out

ILA (Integrated Logic Analyzer)

gt_refclk1_out

ila_1
counter_0

Aurora 64B66B

clk
clk

dout[5:0]

counter_v1_0

probe0[5:0]ILA (Integrated Logic Analyzer)
heartbeat_0
clk100dout[0:0]

resetnheartbeat_v1_0

図 G.1

XCVU13P 側のブロックデザイン（2022 年 1 月 28 日現在）

heartbeat[0:0]ext_reset_in

Aurora 64B66B

In3[0:0]s_aresetn

aurora_init_clk

s_aclkConcatxlconcat_2
dout[1:0]

ZYNQTDO

dcm_lockedinterconnect_aresetn[0:0]

peripheral_reset[0:0]bus_struct_reset[0:0]

図 G.2

BRAM_PORTB

BRAM_PORTA

S_AXI

vccint_alarm_out

AXI GPIO

Q[5:0]

init_clk

user_clk_out

reset_pb

pma_init

GT_SERIAL_RX

ila_CFGGPIO

rstb_busy

rsta_busy

ILA (Integrated Logic Analyzer)

probe0[5:0]clk

ila_6bit_counter

Debug Bridge

tap_tcks_axi_aresetn

tap_tdo

tap_tditap_tms

S_AXI
s_axi_aclk

JTAG_bridge_XCVU13PAXI GPIO

s_axi_aresetn

s_axi_aclk

GPIO

Si5345_INSEL

Debug Bridge

S_BSCAN

S_AXI

clk

debug_bridge_1

Block Memory Generator

BRAM_PORTB

BRAM_PORTA

blk_mem_gen_0

ILA (Integrated Logic Analyzer)

clk

probe0[1:0]

gt_powergood[0:0]

gt_reset_out

sys_reset_out

link_reset_out

gt_refclk1_out

gt_qpllrefclk_quad1_out

gt_qpllclk_quad1_out

sync_clk_out

tx_out_clk

gt_qpllrefclklost_quad1_out

In18[0:0]

In17[0:0]

In16[0:0]

In15[0:0]

In14[0:0]

In13[0:0]

In11[0:0]

In12[0:0]

In8[0:0]In10[0:0]

In9[0:0]In7[0:0]

ConcatZynq MPSoC 側のブロックデザイン（2022 年 1 月 28 日現在）。RGMII-GMII convertor はこれの外側にある。

Binary Counter

CLK

eos_out
busy_out

gpio_io_o[2:0]c_counter_binary_0

s_axi_aresetn

s_axi_aclk

S_AXI

gpio_led

System Management Wizard

alarm_out

eoc_outchannel_out[5:0]

ot_outvccaux_alarm_out

vccpsaux_alarm_out

vccpsintfp_alarm_out

vccpsintlp_alarm_out

s_axi_aclk
s_axi_aresetn

user_temp_alarm_out

Vp_Vn

S_AXI_LITE

ip2intc_irptm0_bscansystem_management_wiz

AXI GPIO

s_axi_aresetn

s_axi_aclk

gpio_io_o[0:0]

GPIO

S_AXI

axi_gpio_0

Debug Bridges_axi_aresetn

s_axi_aclk

debug_bridge_PL

AXI BRAM Controller

s_axi_aresetn

S_AXI
s_axi_aclk

mb_resetslowest_sync_clk

peripheral_aresetn[0:0]Processor System Resetmb_debug_sys_rst

axi_bram_ctrl_0

In1[0:0]In0[0:0]

axi_c2c_m2s_intr_in[3:0]

aurora_pma_init_in

gt_qplllock_quad1_out

xlconcat_0

dout[18:0]

ila_0

din[2:0]

resetnclk100clk_wiz_0

heartbeat_v1_0

heartbeat_0
dout[2:0]

lockedclk_out4

clk_out3

clk_out2

clk_out1

Clocking Wizard

clk_in1resetnILA (Integrated Logic Analyzer)

clk

probe0[18:0]

GT_SERIAL_Z2F

LED[2:0]ZYNQTCKZYNQTMSZYNQTDISi5345_INSEL

ETH_resetn

ETH_CLK10

ETH_CLK25

ETH_CLK125_90

ETH_CLK125

MDIO

CFGINITCFGDONE

rst_ps8_99M

M01_AXI

emio_enet1_dma_bus_width[1:0]

pl_clk1

GT_DIFF_REFCLK1QPLL_CONTROL_OUT

In0[0:0]In1[0:0]In4[0:0]In5[0:0]

GMII

aux_reset_in

M06_AXI

emio_enet0_enet_tsu_timer_cnt[93:0]

AXI SmartConnect

M07_AXI

emio_enet1_tsu_timer_cmp_val

pl_resetn0

AXI Chip2Chip Bridge

axi_c2c_phy_clk

soft_err
GT_SERIAL_TX

GT_SERIAL_F2Z

Zynq UltraScale+ MPSoC

M02_AXI

pl_clk0

M03_AXI
M00_AXI

aresetn

MDIO_ENET1

M05_AXI

M04_AXI

maxihpm0_lpd_aclk

aclk

S00_AXI

GMII_ENET1

M_AXI_HPM0_LPD

gt_pll_lock

mmcm_not_locked_out

lane_up[0:0]

GT_DIFF_REFCLK1

emio_enet1_ext_int_in

emio_enet1_tsu_inc_ctrl[1:0]zynq_ultra_ps_echannel_up

CORE_CONTROL
hard_err

CORE_STATUS

USER_DATA_M_AXIS_RX

In6[0:0]s_axi

aurora_64b66b_0
USER_DATA_S_AXIS_TX

In2[0:0]

gpio_reset

aurora_reset_pb

axi_c2c_multi_bit_error_out

aurora_pma_init_out

axi_c2c_link_error_out

axi_c2c_link_status_out

aurora_do_cc

axi_c2c_config_error_out

axi_smc

pma_init_in

init_clk

AXIS_TX
AXIS_RXaxi_c2c_s2m_intr_out[3:0]

aurora_mmcm_not_locked

axi_c2c_aurora_channel_up

pma_init_generator_v1_0

resetnpma_init_generator_0

axi_chip2chip_092
付録 G Endcap SL 第 1 試作機で使用したファームウェアのブロックデザイン

The read data channel carries both the read data and the read response information from the Subordinate to theManager, and includes:
The data bus, which can be 8, 16, 32, 64, 128, 256, 512, or 1024 bits wide.
A read response signal indicating the completion status of the read transaction.
93

Write data channel

The write data channel carries the write data from the Manager to the Subordinate and includes:
The data bus, which can be 8, 16, 32, 64, 128, 256, 512, or 1024 bits wide.
A byte lane strobe signal for every eight data bits, indicating the bytes of the data that are valid.

付録 H

Write data channel information is always treated as buffered, so that the Manager can perform write transactions
without Subordinate acknowledgement of previous write transactions.

AXI4 プロトコル

Write response channel

A Subordinate uses the write response channel to respond to write transactions. All write transactions require
ompletion signaling on the write response channel.

As Figure A1-1 on page A1-27 shows, completion is signaled only for a complete transaction, not for each data
AXI Chip2Chip を用いたファームウェアを開発するのにあたって、AXI4 プロトコルを理解することが必要で
ransfer in a transaction.
あった。ここでは簡単にその説明をする。

Advanced eXtensible Interface 4（AXI4）は ARM
ace and interconnect® 社による第 4 世代の Advanced Microcontroller Bus

Architecture（AMBA® ）インターフェースプロトコルの 1 つである。基本的にマスターとスレーブを 1 対 1 で

A typical system接続する規格だが、図consists of several Manager
and Subordinate
devicesthat are connected together through some
1 interconnect
H.1 のようにを使えば複数のマスターとスレーブに拡張できる。たとえば
orm of interconnect, as Figure A1-3 shows.
Vivado で使用可能な AXI SmartConnect IP は最大 16 対 16 のマスターとスレーブの接続をサポートしている。
Manager1

Manager2

Manager3
Interface

Interconnect
Interface
Subordinate1
図 H.1

Subordinate2

Subordinate3

Subordinate4

Interconnect を介した複数のマスターとスレーブの接続（ARM）
Figure A1-3 Interface
and2021interconnect

The AXI protocol provides a single interface definition, for the interfaces between:
AXI4 は AXI4-Full、AXI4-Lite、AXI4-Stream の 3 種類のプロトコルの集合である。AXI4-Full と AXI4-Lite
A Manager and the interconnect
は memory-mapped プロトコル（transaction 中にメモリ空間のアドレスの情報を含む）だが、AXI4-Stream はそ
A Subordinate and the interconnect
うではない。それぞれ次のような特徴を持つ。
A Manager and a Subordinate
AXI4-Full

バースト転送を基調とした高いスループットを持つ memory-mapped プロトコル

AXI4-Lite
バースト転送はできないものの軽量な memory-mapped プロトコル
Copyright AXI4-Stream© 2003-2021 Arm
Limited or its affiliates. All rights reserved.
ARM IHI 0022H.c
高速にデータを流す軽量なプロトコル
Non-Confidential
ID012621

AXI4-Full のことを単に AXI4 と呼ぶことが非常に多く、本論文でもそのように言葉を使っている。
なお単一のデータの転送を transfer とし、複数のデータ転送のことを transaction と呼ぶように定義しておく。

H.1 基本的なコンセプト
グローバルシグナルとしてクロック線 ACLKとリセット線 ARESETnがある。接頭辞の Aは AXI プロトコルに関連していることを示す。また ARESETnの接尾辞 nは active-low であることを表している。
1 ARM（2021）
ではバージョン H.b から master/slave という語の代わりに manager/subordinate という単語を使うようになった。

READYnels use the same VALID/READY handshake process to transfer address, data, and control
ay flow control mechanism means both the master and slave can control the rate at which
etween master and slave. The source generates the VALID signal to indicate when the
Figure A3-2 VALID before READY handshake
nformation is available. The destination generates the READY signal to indicate that it canTransfer occurs only when both the VALID and READY signals are HIGH.
A source is not permitted to wait until READY is asserted before asserting VALID.
rfaces there must be no combinatorial paths between input and output signals.
Once VALID is asserted it must remain asserted until the handshake occurs, at a rising clock edge at which VALID
and READY are both asserted.
3-4 on page A3-40 show examples of the handshake process.

FigureA3-3, the destination
asserts READY, after T1, before the address, data or control information is valid,
ce presents the address, data or control information afterInT1
and asserts
VALID signal.
94 after T2, and the source must keep its indicating
AXI4
that
it canacceptthe information. The source presents the information, and付録
assertsH
VALID,
afterプロトコル
T2, andhe READY signal
information
stableuntil
the transfer
the transfer occurs at T3, when this assertion is recognized. In this case, transfer occurs in a single cycle.
assertion is recognized.
T1

T2

T1

T3

ACLK

ACLK

INFORMATIONINFORMATION

VALID

VALID

READY

READY

Figure A3-2 VALID before READY handshake(a) VALID before READY

T2

T3

Figure A3-3 READY before VALID handshake(b) READY before VALID

A destination is permitted to wait for VALID to be asserted before asserting the corresponding READY.
d to wait until READY is asserted before asserting VALID.

図 H.2

AXI4 におけるハンドシェイク（ARM 2021）

READY
asserted,
it is VALID
permitted to deassert READY before VALID is asserted.
it must remain asserted until the handshake occurs, at aIfrisingclockisedge
at whichserted.

nation asserts READY, after T1, before the address, data or control information is valid,
すべてのプロトコルには共通して
VALIDafter、READY
ept the information. The
source presents the information, and asserts VALID,
T2, and 、そして何らかの情報を示すバス（ここではその信号名を仮, when this assertion is recognized. In this case, transfer occurs in a single cycle.

に INFORMATIONとする）の信号線がある。マスターは INFORMATIONを送信する際、または有効な情報が含ま
ARM IHI 0022E

Copyright © 2003, 2004, 2010, 2011, 2013 ARM. All rights reserved.

A3-39

T1 をアサートし、スレーブにそのことを伝える。ただし
T2
T3
ID033013 VALID
Non-Confidential
れている間ずっと
ARESETnがディアサートされている時は、マスターは
VALIDをアサートすることは許されていない。またスレーブは情報を受け取る余裕がある間
ACLK

READY
をアサートする。すなわちマスターとスレーブ間で transfer が行われるのは ACLKの立ち上がりで VALIDINFORMATIONと READYVALID
がともにアサートされている時である。両者はそれをもって transfer が完了したことを知る。
READY
このようなハンドシェイクの例を図H.2 に示した。図 H.2(a) ではマスターが先に INFORMATIONを準備し

VALIDを立てている。図中の T2 の時点ではスレーブは READYを立てていないため、transfer は行われず、マス
Figure A3-3 READY before VALID handshake
ターはその出力状態を維持しなければならない。
T2 の直後でスレーブが READYをアサートしているが ACLKのd to wait for VALID
to be asserted before assertingthe corresponding
READY. T3 で VALIDと READYがどちらもアサートされているため、ここ立ち上がりが来るまで
transferは完了しない。

t is permitted to deassert
READY
before VALID
is asserted.
の時点でtransferが完了する。一方図H.2(b) ではスレーブが待機状態であるため READYを最初に立てている。

図 H.2(a) と同様に T3 で transfer が完了する。

AXI4 ではマスターは一度 VALIDをアサートしたら transfer が完了するまでそれを維持しなければならず、またINFORMATIONの値も変更してはならない。ただしスレーブは
READYをアサートしても、VALIDがディアサート
A3-39

2003, 2004, 2010, 2011, 2013 ARM. All rights reserved.
Non-Confidential

されている状態であればそのアサートを待たずにディアサートできる。
さらに AXI4 では、マスターは VALIDを立てるのに READYを待ってはいけないという約束がある。このことを統一しないと両者は互いの信号がアサートされるまで待ち合うというデッドロックの問題が発生するからである。
ただしスレーブは VALIDのアサートを待って READYを立てても構わない。

H.2

AXI4-Stream

AXI4-Stream は AXI4 プロトコルのうち最もシンプルなプロトコルである。各信号線名には AXI4-Stream であることを示すため、TVALIDや TREADYのように接頭辞 Tをつける。アドレスといった概念が必要でなく、マス
ターからスレーブに一方的にデータを高速に流すのに AXI4-Stream が用いられる。

AXI Chip2Chip の実装では AXI Chip2Chip と Aurora 間の通信で送信用と受信用で 2 つの AXI4-Stream チャ
ンネルが使われる。その信号は TVALID、TREADY、TDATAから構成されていた。TDATAは多ビットの信号線である。それらの transfer の行われ方は節 H.1 で説明した通りである。
ただし AXI4-Stream で必須の信号線は TVALIDで、その他はオプションであるという特徴がある。たとえばAurora のデータ送信用チャンネルでは TVALIDと TDATAのみで TREADYは省略されている。これは Aurora のAXI4-Stream のスレーブとなるモジュールがすべての transfer を受け取れる前提であるか、AXI4-Stream マスターとしての Aurora がバックプレッシャを意図的に受け取らないようにしていると考えられる。また TDATAを省略し••Write data channel
Managerinterface

Write
data

Write
data

Write
data

Write
data

SubordinateAnaddress channel carries control information that describes the nature of the data to be transferred. The data isinterfacetransferred between Manager and Subordinate using either:•Write response channel

Write data, which has signal names beginning with W.
Write response, which has signal names beginning with B.

A write data channel to transfer data from the Manager to the Subordinate. In a write transaction, theSubordinate uses the write response channel to signal the completion of the transfer to the Manager.

•
A read data channel to transfer data from the Subordinate to the Manager.
Write
The AXI protocol:
response•
Permits address information to be issued ahead of the actual data transfer.
•
Supports multiple outstanding transactions.
•Supports out-of-order completion of transactions.

H.3 AXI4-Lite と AXI4

95

Figure A1-1 shows how a write transaction uses the write address, write data, and write response channels.

Figure A1-1 Channel architecture of writes
Figure A1-2 shows how a read transaction uses the read address and read data channels.

Write address channel
Addressand control

Read address channel
Addressand control

Write data channel

Managerinterface

Subordinate
interface

Read data channel
Read
data

Read
data

Managerinterface

Read
data

Write
data

Write
data

Write
data

Write
data

Subordinate
interface

Write response channel

Read
data

Write
response(a)Figure
読み出しA1-2 Channel architecture of reads

A1-1 Channel architecture of writes(b)Figure
書き込み

Figure A1-2 shows how a read transaction uses the read address and read data channels.

図 H.3

AXI4 の transaction（ARM 2021）

Copyright © 2003-2021 Arm Limited or its affiliates. All rights reserved.
Non-Confidential

A1-27

Read address channel
Addressand control

Manager
Subordinate
た場合は TKEEPといった別の信号が必要になるが、AXI Chip2Chipと Aurora の実装では TDATAを省略すること
interfaceinterface
Read data channelはないため、詳細は ARM（2010）
に譲る。

Read
data

H.3 AXI4-Lite と AXI4

Read
data

Read
data

Read
data

Figure A1-2 Channel architecture of reads

ARM IHI 0022H.c

Copyright © 2003-2021 Arm Limited or its affiliates. All rights reserved.

A1-27

ID012621
Non-Confidential
AXI4-Lite と AXI4-Full は memory-mapped
プロトコルである。すなわち
transaction にはターゲットのアドレスの情報が含まれる。

H.3.1 チャンネル
AXI4-Lite と AXI4 では信号線を役割ごとにグループ化したチャンネルという概念を持っている。チャンネルは5 種類ある。各チャンネルはそれぞれ独自に VALIDと READYの信号を持っているため、ある程度互いに独立してtransaction を行うことができる。5 チャンネルを一覧にしたものが表 H.1 である。
表 H.1 AXI4-Lite と AXI4 で使われる 5 つのチャンネル

ChannelSignal preﬁx

Data source

日本語での呼ばれ方

Read address channel

AR

Master

読み出しアドレスチャンネル

Read data channel

R

Slave

読み出しデータチャンネル

Write address channel

AW

Master

書き込みアドレスチャンネル

Write data channel

W

Master

書き込みデータチャンネル

Write response channel

B

Slave

書き込み応答チャンネル

AXI4 におけるそれぞれのチャンネルの役割を示したのが図 H.3 である。図 H.3(a) のようにデータの読み出し時
はマスターが ARチャンネルを使ってターゲットのアドレスをスレーブに伝える。スレーブはそれに対応したデー
タを Rチャンネルを用いてマスターに返す。これには読み出しデータの他に読み出しの成否の情報（読み出し応答、

read response）も含まれる。ただし図 H.3 では AXI4 に特有なバースト転送（burst transaction）が行われているため、1 つの読み出しアドレスの transfer に対して複数のデータが返送されている。バースト転送については節 H.3.3
で後述する。図 H.3(b) は書き込み transaction の構造を表している。マスターは AWチャンネルと Wチャンネルを使ってそれぞれ書き込む対象のアドレスとデータをスレーブに送信する。スレーブはその成否を Bチャンネルを用いてマスターに返す。
スレーブはマスターから読み出しアドレスを受け取らないと、読み出しデータと読み出し応答の transaction を開始できない。同様に書き込みアドレスと書き込みデータを受け取らないと、書き込み応答の transaction を開始でき

ARVALID is asserted•

the slave can wait for AWVALID or WVALID, or both, before asserting WREADY•

the slave can assert WREADY before AWVALID or WVALID, or both, are assertednd ARREADY to be asserted before it asserts RVALID to indicate•

the slave must also wait for WLAST to be asserted before asserting BVALID, because the write response,
BRESP, must be signaled only after the last data transfer of a write transaction

assert RREADY before asserting RVALID

sserted before it asserts RREADY96

RVALID is asserted.
ARVALID

the slave must wait for both WVALID and WREADY to be asserted before asserting BVALID•

the slave must not wait for the master to assert BREADY before asserting BVALID•

the master can wait for BVALID before asserting BREADY•

the master can assert BREADY before BVALID is asserted.

RVALIDARREADYWVALID†AWVALIDAWREADY

RREADY付録 H AXI4 プロトコル
BVALID

BREADYWREADY† Dependencies on the assertion of WVALID also require the assertion of WLAST

Figure A3-5 Read transaction handshake dependencies

Figure A3-6 Writetransaction handshake dependencies(b) 書き込み(a) 読み出し

各チャンネル間のハンドシェイクの依存性（ARM 2021）。X→Yは、Xは Yを待ってのアサートをして

図 H.4はならないが、Yは Xを待たずにアサートしても構わないことを表している。X↠Yは、Yは Xを待ってアサート
hake signal dependencies,
and shows that in a write transaction:
しなければならないことを表している。
ARM IHI 0022E

Copyright © 2003, 2004, 2010, 2011, 2013 ARM. All rights reserved.
Non-Confidential

assert AWREADY or WREADYID033013
before asserting AWVALID or

A3-43ない。このことと、節 H.1 で説明した VALIDがアサートされるのに READYのアサートを待ってはいけないといVALID, or both before asserting AWREADY
うルールから、各チャンネルの VALIDと READYの間には図 H.4 のような時間的依存性が発生することが理解で
AWVALID or WVALID, or both, are asserted
きる。
VALID, or both, before asserting WREADYWVALID or WVALID,
both, are asserted
H.3.2 or信号線

nd WREADY to be asserted before asserting BVALID
AXI4 と AXI4-Lite の主要な信号線を表 H.2 にまとめた。ただし必須の信号線とオプションの信号線は区別し
be asserted before asserting BVALID, because the write response,ておらず、AXI Chip2Chip のサンプルデザインで使われていたものをまとめている。AXI4 と AXI4-Lite に共通
last data transfer of a write transaction
して存在する信号は Common、AXI4 のみに存在する信号は AXI4 only と書き込んでいる。このように AXI4 はassert BREADY before asserting BVALID
AXI4-Lite を包含している関係にある。どちらにも存在しない信号は–と書き込んでいる。たとえば ARチャンネル
asserting BREADYは読み出しアドレスをマスターからスレーブに伝えるためのものなので、ARDATAという信号は存在しない。ここBVALID is asserted.
で AXI4 only と書かれている信号はほとんど節 H.3.3 で後述するバースト転送に関わるものである。
WVALID†BVALID

ChannelWREADY

Signal

表 H.2

Write address

Read address

Write data

Write response

Read data

AW-

AR-

W-

B-

R-

CommonCommonCommonCommonCommonCommonCommonCommonBREADYWREADY-VALID
Commons on the assertion of WVALID also
require the assertionof WLAST-READY

AXI4 と AXI4-Lite の信号線

CommonFigure A3-6 Write transaction handshake dependencies-ID

AXI4 only

AXI4 only–

AXI4 only

AXI4 only-USER

AXI4 only

AXI4 only

AXI4 only

AXI4 only

AXI4 only-ADDR

CommonCommon

–

–

–

-PROT

CommonCommon

–

–

–

A3-43
AXI4 only

AXI4 only

–

–

–

-SIZE

AXI4 only

AXI4 only–––-BURST

AXI4 only

AXI4 only

–

–

–

-DATA

–

–

Common–Common

-STRB

–

–

Common

–

–

-LAST

–

–

AXI4 only–

AXI4 only

-RESP

–

–

–

CommonCommon1, 2013 ARM. All rights reserved. -LEN
idential

表 H.2 で Common となっている信号について簡単に説明する。すなわち AXI4-Lite の説明でもある。VALIDと READYは 5 つのチャンネルすべてで用いられている。ARADDRと AWADDRはターゲットのアドレスを転送すH.3 AXI4-Lite と AXI4

97

るための信号である。幅 3 bit の ARPROTと AWPROTはプロテクションタイプをマスターが指定するためのもの
で、Vivado では値 0b000 が推奨されている。WDATAについてはマスターが送信する書き込みデータを、RDATA
はスレーブが送り返す読み出しデータを表す。WSTRBはストローブ信号で、マスターが有効なバイトレーンを指示する。すなわち WSTRB[n]が 1 ならば WDATA[(8n+7):(8n)]が有効であることを意味する。WDATAの幅が 32 bit
ならば WSTRB幅はその 1/8 倍の 4 bit である。BRESPと RRESTはそれぞれ書き込みと読み出しの成否をスレー
ブがマスターに伝えるものである。読み出し transaction についてはスレーブが VALIDをドライブするため読み出
しデータと一緒に読み出し応答をマスターに送ることができる。しかし書き込みの transaction についてはアドレスとデータのチャンネルどちらも VALIDはマスターがハンドルしているため書き込み応答専用のチャンネルが必要である。BRESPと RRESTはどちらも幅 2 の信号で、通常アクセスしたら 0b00 となる。上位 1 bit が 0b1 であればエラーを表す。詳細は ARM（2021）を参照のこと。

H.3.3 バースト転送
AXI4-Full はバースト転送をベースとしたプロトコルである。マスターは制御情報と最初のアドレスだけを指定し、そのあとのアドレスはスレーブ側が責任を持つ。
図 H.5 に読み出し transaction のバースト転送の例を示した。ただし ACLKや VALIDなどは省略している。1transfer は 1 つのデータについての transaction であるとすると、図 H.5 では 4 つの transfer を 1 burst としている。このように 1 burst あたりいくつの transfer を含んでいるかを burst length と呼ぶ。また 1 回の transfer でのデータサイズを burst size といい、この場合 4 B である。
Example behaviour of burst readmaster

0

1

2

3

4

5

6

7

8

9

10

11

12

araddr[31:0]

addr1

addr5

arid[5:0]

id1

id5

slave

d1

d2

rid[5:0]

d3
id1

14

15

16

17

18

burst length = 4 transfers in a burst

burst size = 4 Byte in a transfer

rdata[31:0]

13

d4

d5

d6
id2

rlast

図 H.5

AXI4 burst read

図 H.5 で、マスターは ARチャンネルを使ってアドレス addr1 と transaction ID id1 をスレーブに渡している。
スレーブは addr1 から始まる 4 つのアドレスのデータを連続してマスターに伝えている。その際マスターから渡された transaction ID を RID信号を使って付している。最後に burst の終わりを示す RLASTをアサートしてバースト転送が完了する。
どのようにアドレスをインクリメントさせるかや、burst length や burst size の値はマスターが専用の信号を使ってスレーブに指示する。AxLEN[7:0]は burst length を、また AxSIZE[2:0]は burst size をそれぞれ次のように指定するものである（ただし xは Rまたは W）。

(burst length) = 1 + AxLEN[7:0],
log2 (burst size) = AxSIZE[2:0].
またバースト開始時の最初のアドレス（starting address）は(starting address) = AxADDR

付録 H AXI4 プロトコル

98となる。AxBRST[1:0]はバーストタイプを指定するためのものである。バーストタイプは 3 種類あり、それぞれ次のようになっている。

FIXED 同じアドレスにアクセスし続ける。0b00 で指定する。
INCR

アドレスをインクリメントする。ただしインクリメントの幅は burst size である。0b01 で指定する。

WRAP INCR バーストとほぼ同様だが、upper wrap boundary に達したら lower wrap boundary に戻る。

0b10 で指定する。
である。
バーストタイプが FIXED の場合、i 回めの transfer のアドレスはすべて

addri = (starting address)
である。バーストタイプが INCR または WRAP の場合、⌋(starting address)× (burst size)(aligned address) =(burst size)
⌊

として、

{

addri =

(starting address)(aligned address) + i × (burst size)for i = 1,
for i ≥ 2となる。特に WRAP バーストの場合、(transaction size) = (burst length) × (burst size),⌊⌋(starting address)(lower wrap boundary) =× (transaction size),(transaction size)(upper wrap boundary) = (lower wrap boundary) + (transaction size)
として、addri ≥ (upper wrap boundary) となるならば addri = (lower wrap boundary) とする。
次のような注意点がある。

• transaction size は 4 kB を超えないようにしなければならない。
• INCR バーストについては burst length は最大 256 まで取れるが、その他のバーストタイプについては最大
16 までである。特に WRAP バーストについては、burst length は 2、4、8、16 のいずれかでなければならない。

-USERはユーザが定義した信号として使うことができる。
WLASTと RLASTは burst の最後の transfer であることを示すのに使われる。
ARID、AWID、RID、BIDを使って各バーストに transaction ID を付けることによって、マスターとスレーブでどのデータがどのバーストに関連しているかを共有することができる。ただし WDATAの順序は AWADDRと同じであるため、WIDはその冗長性により AXI4 から廃止されている。AXI3 と AXI4 のインターフェイスを接続する場
合は WIDの代替として WUSERを使えばよい。transaction ID によりマスターはスレーブからの応答を待たずに次のバーストを開始できたり、準備のできたデータから処理を行うようなアウトオブオーダー転送も可能である。た
とえばマスターが id1、id2、id3 の順番でバーストを開始したとき、スレーブは id1、id3、id2 のように応答しても両者は問題なくデータとアドレスを取り扱える。これにより処理の時間短縮も可能だと考えられる。
を参照のこと。
その他のオプションの信号線については ARM（2021）
最後に読み出し、書き込みバースト転送の例をそれぞれ図 H.6 と図 H.7 に示す。

H.3 AXI4-Lite と AXI4

99

Example behaviour of burst read in AXI4 protocol
0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

aclk

Read data channel (R)Read address channel (AR)resetnarsize[2:0]0b011 (4 bytes in a transfer)arlen[7:0]0d3 (4 transfers in a burst)

arburst[1:0]0b01 (burst type = incrementing)araddr[31:0]

addr1

addr5

arid[5:0]

id1

id2

arvalidarreadyrvalidrdata[31:0]

d1

d2

rid[5:0]

d3

d4

d5

id1

d6
id2

rlast
rresp[1:0]

OK

OK

OK

OK

OK

OK

rready

図 H.6

読み出しバースト転送の例

Example behaviour of burst write in AXI4 protocol
0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

aclk

Write address chan. (AW)resetnawsize[2:0]0b011 (4 bytes in a transfer)awlen[7:0]0d3 (4 transfers in a burst)

awburst[1:0]0b01 (burst type = incrementing)awaddr[31:0]

addr1

addr5

awid[5:0]

id1

id2

awvalid

Write response chan. (B)Write data chan. (W)awready

wstrb[3:0]0b1111

wvalidwdata[31:0]

d1

d2

d3

d4

d5

wlast
wreadybvalidbresp[1:0]OK

bid[5:0]

id1

bready

図 H.7

書き込みバースト転送の例

d6

101

付録 I

AXI Chip2Chip のテストベンチシミュレー
ションの実行
Vivado では AXI Chip2Chip のサンプルデザインが利用可能である。そのサンプルデザインは図 I.1 のようになっており、AXI Chip2Chip と Aurora のインスタンスと Traﬃc Generator と Traﬃc Checker というモジュールが使われている。SelectIO または Aurora の選択や、Aurora 8B/10B または Aurora 64B/66B の選択などは、サンプルデザインを生成するときに選択できる。ここではインターフェイスとして Aurora 8B/10B を用いた。Traﬃc

Generator は適当なデータパターンを生成し、ARチャンネル、AWチャンネル、Wチャンネルでデータを AXI
Chip2Chip に送信する。Traﬃc Checker は同じ規則で参照データを生成し、R
チャンネルと Bチャンネルで AXI
Chapter 5: Example Design
Chip2Chip から返された応答が合致しているかを検知するものである。
X-Ref Target - Figure 5-2

AXI Chip2Chip Example DesignAW
Traffic
Traffic
Generator
Generator

AR
W
AXI
AXI
Chip2Chip
Chip2Chip
Core
Core

AuroraAurora64B66B
64B66BCore
Core

Serial Interface

R
Traffic
Traffic
CheckerChecker

B

Figure 5-2: Example Design Block Diagram with Aurora Interface
図 I.1 AXI Chip2Chip のサンプルデザイン（Xilinx 2020）
The example design contains the following:• An instance of the AXI4.8
Chip2Chip
core
さらにサンプルデザインには図のテストベンチシミュレーションが含まれている。マスター側にはサンプル
デザインが、スレーブ側ではラッパーをかけていないサンプルデザインが用いられている。このテストベンチシ• Clocking wizard to generate clock signals for the example design
ミュレーションの動作は、まずマスターとスレーブ間のリンクの確立を確認したのち両者の間でデータ転送を行• Traffic generator for AXI4 and AXI4-Lite interfaces
い、期待されているデータが送られてきたことを Traﬃc Checker が判別して、その結果を出力するというもので• Traffic checker for AXI4 and AXI4-Lite interfaces
あった。
• an instance of the Aurora 64B66B core in duplex configuration.
IMPORTANT: Be sure to select the right device when simulating, synthesizing, and implementing theexample design of the AXI Chip2Chip with PHY type set as Aurora.

付録 I AXI Chip2Chip のテストベンチシミュレーションの実行

102

提供されているテストベンチシミュレーションはそのままでは動作せず、若干のデバッグ1 をすることでシ
ミュレーションが完了した。さらにマスター側の Traﬃc Generator を編集し、すべての WID[5:0]で書き込みデー
タ WDATA[31:0]が 0xDEADBEEF になるようにしたところ、スレーブ側の Traﬃc Checker でもそれが見えていることを確認した（図 I.2）。またスレーブ側の Traﬃc Generator で RID[5:0]が 0x39 のときに読み出しデータ

RDATA[31:0]が 0xDEADBEEF になるようにしたところ、これもマスター側の Traﬃc Checker で見えていることを確認した（図 I.3）。

図 I.2

マスターが書き込むデータをすべて 0xDEADBEEF にしたとき、スレーブがそれを受け取る様子

図 I.3

RIDが 0x39 のときマスターがデータ 0xDEADBEEF を受け取る様子

1 スレーブ側の aurora_8b10b_0_partner というモジュールではなく、マスター側に合わせて aurora_8b10b_0 を使うようにした。

103

付録 J

ZCU102 評価ボードを用いたループバック
試験
図 4.9 のファームウェアを実機で試験するため、図 J.1 のように ZCU102 評価ボードでループバック試験をすることを考えた。
ZCU102 evaluation board
Zynq UltraScale+ MPSoC

Linux

PS
PL
register
AR AW WR

register

🚨🚨🚨🚨
LEDs

B

register interface

AR AW WR

B

AXI Chip2Chip master

AXI Chip2Chip slave

TT

TT

Aurora 64B/66B

Aurora 64B/66B

SFP+
connector

SFP+
connector

optical cableoptical cable

図 J.1

ZCU102 評価ボードでのループバック試験

ZCU102 には 2 × 2 の SFP/SFP+ クアッドコネクタが搭載されており、SFP0（right-top connector）と SFP1

_0
_1
_2
_MGT

MGT_228_0
MGT_228_1
MGT_228_2
MGT_228_3
MGT_228_REFCLK_0
MGT_228_REFCLK_1_SI5324_OUT_RX_CLK_HPC1_DP_4_HPC1_DP_5_HPC1_DP_6_HPC1_DP_7

FMC_HPC0_DP6
FMC_HPC0_DP5
FMC_HPC0_DP7
FMC_HPC0_DP4
FMC_HPC0_GBTCLK1
Not connected

BANK 229104

付録 J ZCU102 評価ボードを用いたループバック試験

MGT_229_0 FMC_HPC0_DP3
MGT_229_1 FMC_HPC0_DP1
MGT_229_2 FMC_HPC0_DP0（right-lower connector）を使用する。これらの SFP+ クアッドコネクタは Zynq MPSoC の GTH トランシーバとMGT_229_3 FMC_HPC0_DP2

接続されており、
Quad 230 という GT Bank を使う（図 J.2）。
MGT_229_REFCLK_0

R_MGT_SI570_CLOCK1
R_SMA_MGT_CLOCK

MGT_229_REFCLK_1

FMC_HPC0_GBTCLK0
Not connected

BANK 230_HPC1_DP_0_HPC1_DP_1_HPC1_DP_2_HPC1_DP_3

MGT_230_0
MGT_230_1
MGT_230_2
MGT_230_3_HPC1_GBTCLK_0_HPC1_GBTCLK_1

MGT_230_REFCLK_0
MGT_230_REFCLK_1

SPF0
SPF1
SPF2
SPF3
USER_MGT_SI570_CLOCK2
SFP_SI5328_OUT
X16543-071917

Figure 3-36:

GTH Bank Assignments
図 J.2 ZCU102 の Bank 230（Xilinx 2019）
図 J.3

オシロスコープで 125 MHz を確認

mon FPGA column are provided by PL-side MGT banks 228 and 229.
e clocks includeMGT_230_REFCLK_0
the FMC defined GBT clocks
0 and 1 上のfor HPC_0,には ZCU102
Si570 ajitter attenuator からのクロックを入れる。これはデフォルト
ock, and a jitter attenuated recovered clock from a Si5328. The MGT
で 156.25
MHz を出力するが、Si5345 と同様に Linux から I2 C でコンフィギュレーションできる。またコンフィ
ated in adjacent
MGT banks,
228, 229, and 230.

ギュレーションすべきレジスタはレジスタ７から 18 と、135 と 137 のみで、Si5345 に比べて圧倒的に少ない。ここでは 125 MHz を出力するようレジスタの値を計算し、節 3.4 と同様に Linux から I2 C で操作した。オシロス

コープでSi570 の出力をプローブし、図のように
mon FPGA column
are provided
by PL-side MGT banksJ.3
129
and 130.125 MHz が出力されていることを確認した。
e clocks includeMGT_230_REFCLK_1
the FMC defined GBT clocks
0
and
1
for
HPC_1,
a からの出力を用いる。FPGA によって出力された差動リカには Si5328 jitter attenuatorock, and a user provided SMA clock. The MGT reference clocks are
バリクロックが Si5328 に入り、その出力が MGT_230_REFCLK_1に入る。Si5328 はまた PS からの I2 C 操作でT banks, 128, 129, and 130.
コンフィギュレーションできるが、これはまだ実行していない。

ide

J.1 BRAM-C2C interconnect の構想
4.4 のように AXI SmartConnect を介した PS からの今後 ZCU102 でのループバック試験を行うが、ここでも節86
www.xilinx.com
アクセスした際に問題が発生するようであれば、PS から BRAM への読み書きは経験があるため、代替手法として
BRAM を介して PS から AXI Chip2Chip master に情報を送ることを考案した。また BRAM と AXI Chip2Chip
master を介するものとして BRAM-C2C interconnect の機構も設計した。その場合のファームウェアのヒエラル
キーは図 J.4 のようになる。
表 J.1 に示すような BRAM のアドレスマップを決めておく。ユーザ（ソフトウェア）は BRAM の指定のオフ
セットに ARADDRや WDATAなどを書いておき、OPERATIONのアドレスに 0b01（読み出し）、0b10（書き込み）、または 0b11（読み書き両方）のオペレーションを書くことで、自動的に動作が開始されるようにした。また

BRAM-C2C interconnect は、動作が開始されれば STATUSのアドレスにそれを表すデータを書いておき、ソフト
ウェアはそれを見て BRAM を操作しない仕組みにした。

BRAM-C2C interconnect は次のようなステートマシンで動作する。
1. レジスタ変数の初期化を行う。
2. BRAM の OPERATIONのアドレスに書かれたデータを読み、動作を開始する。STATUSのアドレスに動作が開始されたことを表すデータを書く。

3. オペレーションに応じて ARチャンネル、AWチャンネル、Wチャンネルの情報を BRAM から取得する。
4. AXI Chip2Chip master と AXI4 の transaction を開始して情報を渡す。

J.1 BRAM-C2C interconnect の構想

105
top

design_1
PS
Linux

BRAM

slave partregisterregister

🚨🚨🚨🚨
LEDs

master part

BRAM-C2C interconnect

AR AW W

B

AR AW WR

B

AXI Chip2Chip master

AXI Chip2Chip slave

T

T

Aurora 64B/66B

Aurora 64B/66B

TX

図 J.4

R

register interface

RX

TX

RX

BRAM-C2C interconnect を組み込んだループバックファームウェア

5. AXI Chip2Chip master から transaction の結果を受け取る。
6. 受け取った結果を BRAM に書き込み、STATUSのデータをクリアする。また OPERATIONのアドレスに0b00 を書いて 2 のステートに戻る。
BRAM-C2C interconnect を作成し、CentOS 7 で動作するソフトウェアも開発したが、BRAM-C2C interconnectが正しく情報を取得せず、レジスタに読み書きができなかった。原因を調査すると、PS（ソフトウェア）側からとロジック側からでは BRAM のアクセスの仕方が次のように異なることが判明した。

• PS から見てオフセット x にあるデータは、ロジック側から 4x としてアクセスすることで共有できる。
• ロジック側から書き込んだ 32 bit のデータは、PS からは下位 8 bit しか観測できない。
この検証結果から BRAM のアドレスマップを表 J.1 のように修正した。これを受けてソフトウェアとファーム
ウェアも修正する予定である。

付録 J ZCU102 評価ボードを用いたループバック試験

106

表 J.1 新たに作成すべき BRAM アドレスマップ

AXI4 commands

width/bit

BRAM address

Address oﬀset

OPERATION

2

0×4

0

STATUS

2

1×4

1

ARADDR32(2 to 9) ×4

2 to 9ARID

6(10 to 11) ×4

10 to 11ARLEN

8(12 to 13) ×4

12 to 13ARSIZE3

14 × 4

14

ARBURST2

15 × 4

15

RDATA

32

(16 to 23) ×4

16 to 23RID

6

(24 to 25) ×4

24 to 25

RRESP

2

26 × 426

AWADDR32(27 to 34) ×4

27 to 34AWID

6

(35 to 36) ×4

35 to 36AWLEN

8(37 to 38) ×4

37 to 38AWSIZE3

39 × 439

AWBURST2

40 × 4

40

WDATA

32

(41 to 48) ×4

41 to 48WUSER

449 × 4

49

WSTRB

4

50 × 450BID

6(51 to 52) ×4

51 to 52

BRESP

2

53 × 4

53

107

謝辞
本研究室の石野雅也教授と奥村恭幸准教授のご尽力により、新型コロナウイルスの蔓延によるリモートワークでもそれらの影響を感じることなく研究をすることができました。指導教官である石野雅也教授には毎週の研究室会議などで的確なアドバイスやコメントをいただきました。この論文の添削もかなり細かくアドバイスをいただき、心より感謝しております。また Mercury+ PE1 を破損させてしまった時や、KEK で急に LAN ケーブルのかしめ
工具が必要になった時など、素早く対応していただきありがとうございました。京都のアパート探しについての相談でもお世話になりました。また奥村恭幸准教授には、研究室会議で毎週必ずコメントや次にすべきことのアドバ
イスなどをいただき、自分の研究を円滑に進めることができました。VHDL や C/C++ の書き方、オシロスコープの使い方など、テクニカルな面でも勉強させていただきました。また研究室に Ubuntu サーバを構築していただき

Vivado と PetaLinux が使えるようになったことで、大幅な時間短縮になりました。お 2 人には大変お世話になりました。誠にありがとうございました。
研究室内で Phase-II の学生として一緒だった、先輩の田中碧人さんと同期の青木匠くんにも大変お世話になりました。田中さんには PetaLinux の使い方をレクチャーしてもらいました。また参考になるソースコードをいただいたり、その他にもさまざまな細かいアドバイスをいただきました。また青木は Vivado の使い方が僕より上手で、ファームウェアのエラーで数日悩んでいる時に彼に相談すれば、一発で解決して驚いた1 のをよく覚えています。

Endcap SL で CentOS 7 からの I2 C の操作がうまくいかなかった時など、困難に直面したときは親身になって一緒に考えてくれました。そのおかげで I2 C の信号線をオシロスコープでプローブしてみようということになり、それによって僕のコーディングに誤りがあることがわかりました。後輩の三島章煕くんは AXI Chip2Chip に関してお手伝いをしてくれました。彼と議論していて AXI SmartConnect を使えば AXI Chip2Chip が PS から使えることに気づいたし、実際に初めて AXI Chip2Chip を使ったシリアル通信を試験したのは彼でした。お互い KEK に出張するのが初めてで、一緒に作業ができて楽しかったです。また慶應義塾大学から一緒だった同期の林雄一郎くんにも長い間お世話になりました。彼と ICEPP の見学会に来たのがきっかけでこの研究室に入ることにしたし、日吉の喫茶店で協力して院試の勉強をしたのはいい思い出です。就職活動もお互い情報共有してやってきました。博士進学するとのことなので、道は違えどお互い頑張りましょう。

ICEPP の他の学生やスタッフにもお世話になりました。研究室での会議では鋭い質問をいただき、自分では当たり前だと思っていたが実はよくわかっていなかったことなどをあぶり出すことができました。半分オンラインでの

CERN 夏の学校では様々な興味深い講義を提供していただきありがとうございました。特に CERN 現地のスタッ
フの方々に中継で ATLAS 検出器を見させていただいたことで、そもそも ATLAS が本当に存在することを初めて実感しましたし、現場の雰囲気も感じることができました。
大学院まで支えてくれた両親と親戚にも深く感謝をしています。2021 年 9 月に亡くなった祖父は、これまで常に僕の学業を応援してくれていました。彼にこの修士論文を見せられなかったことや、晩年会いに行けなかったことが悔やまれます。他にもアルバイト先の方々や友達にも多くの面でお世話になりました。
多くの方々に助けられ、この修士論文が書けたのだと改めて思います。皆さま、どうもありがとうございました。
1 生年月日が 1 日違いなのも驚きました。

109

引用文献
[1] anunesgu 2021 “Designing an XVC project for Remote Debugging of Zynq UltraScale+ devices,” https://support.xilinx.com/s/article/974879.
[2] ARM 2010

AMBA 4 AXI4-Stream Protocol Speciﬁcation, URL: https://developer.arm.com/

documentation/ihi0051/a/.
[3]2021 AMBA AXI and ACE Protocol Speciﬁcation, URL: https://developer.arm.com/
documentation/ihi0022/hc/.

[4] ATLAS Collaboration 2017 “Technical Design Report for the Phase-II Upgrade of the ATLAS TDAQ
System,” URL: https://cds.cern.ch/record/2285584.
[5] Avnet

Ultra96-V2 product page, URL: https://www.avnet.com/wps/portal/us/products/

avnet-boards/avnet-board-families/ultra96-v2/.
[6] CERN

2021

“The

HL-LHC

project,”

https://hilumilhc.web.cern.ch/content/hl-lhc-project.
[7] Daniele Bagni, A., Di Fresco, J., and Noguera, F. M. V. 2016 A Zynq Accelerator for Floating Point
Matrix Multiplication Designed with Vivado HLS (XAPP1170 v2.0), URL: https://www.xilinx.com/
support/documentation/application_notes/xapp1170-zynq-hls.pdf.
[8] Dzemaili, N. 2021 “A reliable booting system for Zynq Ultrascale+ MPSoC devices,” URL: https://cds.cern.ch/record/2763095, Presented 17 Mar 2021.
[9] Enclustra

2019a“Enclustra

Build

Environment,”

https://github.com/enclustra-bsp/

bsp-xilinx.
[10]

2019b Mercury+ PE1 Base Board User Manual, URL: https://www.enclustra.com/en/
products/base-boards/mercury-pe1-200-300-400/.

[11]

2019c Mercury XU5 SoC Module User Manual, URL: https://www.enclustra.com/en/
products/system-on-chip-modules/mercury-xu5/.

[12]

Mercury+ PE1-200/300/400 product page, URL: https://www.enclustra.com/en/
products/base-boards/mercury-pe1-200-300-400/.

[13]

Mercury XU5 product page,

URL: https://www.enclustra.com/en/products/

system-on-chip-modules/mercury-xu5/.
[14]

Koeppel, G., Duerner, D., and Ruder, A. 2020 “Mercury XU5 PE1 Reference Design,” https://github.
com/enclustra/Mercury_XU5_PE1_Reference_Design.

[15]

Kopeliansky, R. and Schlenker, S. 2019 “DCS for TDAQ subsystems: Requirements Document for HLLHC,” URL: https://edms.cern.ch/document/1992002/4.

[16]

Kopeliansky, R. and Vandelli, W. 2019 “SoC for TDAQ subsystems: Requirements Document for HLLHC,” URL: https://edms.cern.ch/document/2188675/1.

引用文献

110

[17] Mouche, P. 2014 “Overall view of the LHC. Vue d’ensemble du LHC,” URL: https://cds.cern.ch/record/1708847, General Photo.
[18] Redmon, J. and Farhadi, A. 2018 “YOLOv3: An Incremental Improvement,” arXiv:1804.02767, URL:
https://pjreddie.com/darknet/yolo/.
[19] Silicon Labs 2018 Si5345, Si5344, Si5342 Rev. D Family Reference Manual, URL: https://twiki.
nevis.columbia.edu/twiki/pub/ATLAS/AnalogTestboard/Si5345-44-42-D-RM.pdf.
[20] The ATLAS Collaboration, Aad, G., Abat, E. et al. 2008 “The ATLAS Experiment at the CERN Large
Hadron Collider,” Journal of Instrumentation 3, No. 08, S08003–S08003, DOI: 10.1088/1748-0221/3/
08/s08003.
[21] Xilinx 2017

Vivado Design Suite AXI Reference Guide (UG1037 v4.0),

URL: https://www.xilinx.com/support/documentation/ip_documentation/axi_ref_guide/latest/
ug1037-vivado-axi-reference-guide.pdf.
[22]

2018a

Aurora 64B/66B v11.2 LogiCORE IP Product Guide (PG074),

URL:

https://www.xilinx.com/support/documentation/ip_documentation/aurora_64b66b/v11_2/pg074-aurora-64b66b.pdf.
[23]

2018b

Debug Bridge v3.0 LogiCORE IP Product Guide (PG245 v3.0),

URL:

https://www.xilinx.com/support/documentation/ip_documentation/debug_bridge/
v3_0/pg245-debug-bridge.pdf.
[24]2019 ZCU102 Evaluation Board User Guide (UG1182 v1.6), URL: https://www.xilinx.
com/support/documentation/boards_and_kits/zcu102/ug1182-zcu102-eval-bd.pdf.

[25]

2020

AXI Chip2Chip v5.0 LogiCORE IP Product Guide (PG067), URL: https://www.xilinx.com/support/documentation/ip_documentation/axi_chip2chip/v5_0/
pg067-axi-chip2chip.pdf.
[26]2021a “XilinxVirtualCable,” https://github.com/Xilinx/XilinxVirtualCable.git.

[27]

2021b
URL:

Zynq UltraScale+ MPSoC Software Developer Guide (UG1137 v2021.2),

https://japan.xilinx.com/support/documentation/sw_manuals_j/xilinx2021_

2/ug1137-zynq-ultrascale-mpsoc-swdev.pdf.
[28] 奥畑宏之 2019 『Interface 2019 年 1 月号小型リアルタイム組み込み人工知能』，CQ 出版社．
[29] 三野裕哉 2020 「高輝度 LHC ATLAS 実験に向けた初段ミューオントリガーアルゴリズムの開発およびハードウェアへの実装」，修士論文，京都大学大学院理学研究科物理学・宇宙物理学専攻，URL：

https://www-he.scphys.kyoto-u.ac.jp/theses/master/mino_mt.pdf．
[30] 田中碧人 2021 「System-on-a-Chip を用いたエレクトロニクス制御回路の開発−高放射線環境での大規模システムへの応用」，修士論文，東京大学大学院理学系研究科物理学専攻，URL：https://www.icepp.

s.u-tokyo.ac.jp/download/master/m2020_tanaka.pdf．
[31] 東田旺大 2019 「大規模高エネルギー実験における電子回路モジュール制御への system-on-a-chip デバ
イスの応用研究」，修士論文，東京大学大学院理学系研究科物理学専攻，URL：https://www.icepp.s.

u-tokyo.ac.jp/download/master/m2018_higashida.pdf．