実践的！FPGA開発セミナーvol.18 / FPGA_seminar_18_fixstars_corporation_20230125

Copyright© Fixstars Group
実践的！FPGA開発セミナー
vol.18
2023/01/25 18:00～

View Slide

テストとノウハウ編
：FPGA の論理を Chisel
でゴリゴリ開発してみた
話

View Slide

Who I am
Yoshitaka
TAKEMOTO
竹本義孝
ソリューション第四事業部　
シニアエンジニア

View Slide

前回のコメント等への
回答

View Slide

Chisel と Verilog の簡易比較
Verilog Chisel
port 宣言 module X (
input [1:0] a,
output [2:0] b
);
val io = IO( new Bundle {
val a = Input(UInt(2.W))
val b = Output(UInt(3.W))
})
三項演算子連打 logic x;
assign x = c1 ? a1:
c2 ? a2:
c3 ? a3:
x_default;
val x = WireInit( xDefault )
when(c1) { x := a1 }
when(c2) { x := a2 }
when(c3) { x := a3 }
MuxCaseというのもあるにはある
switch 文 case (state)
X:
endcase
when().elsewhen().otherwise が良い
MuxLookupやswitch-is があるにはあるが …
instance 化 my_module i1 (
.x(x),
.y(y)
);
val i1 = Module(new MyModule)
i1.io.x := x
i1.io.y := y
コメント：switch is でいいのでは？
私：switch is は default がない
コメント：次のように書けばいい
x := defaultValue
switch～～
指摘に気が付いてなくてすみません

View Slide

switch is を好まない理由
switch 構文は本質的に実装忘れに気が付けないから
x := defaultX
y := defaultY
switch(cnd) {
is (CND1) {
x := 1.U
y := 1.U
}
is (CND2) {
x := 2.U
// y := 2.U 実装忘れ
}
}
when(cnd === CND1) {
x := 1.U
y := 1.U
}.elsewhen(cnd === CND2) {
x := 2.U
//y := 2.U 実装忘れ
}.otherwise {
x := defaultX
y := defaultY
}
yに未定義はないので
コンパイルエラーなし
yの未定義を検知して
コンパイルエラー

View Slide

Chiselのメリットが何なのか結局よくわからない
立場によって違うと思われます
個人：
● Verilog より IDE 等の補完が強力
● 記述が圧縮できる
● Verilog より楽しい（個人の感想）
● そもそも新しいパラダイムや機構に触れること以上のメリットが必要か？
組織：
● 微妙

View Slide

Chisel でテスト

View Slide

Chisel でテスト
Chisel のテストは、シミュレータを操作することで値を入力したり、値が正しいかの確認を行う
※ Chisel 3.6からは CIRCT に変わります

View Slide

Chisel でテストを作る
enableが
1の時のinを
加算し、
出力する
モジュール

View Slide

sbt で test とタイプするとテストを実行できる
成功すると[success]とでて終了する

View Slide

sbt で test とタイプするとテストを実行できる
成功すると[success]とでて終了する
正しく修正

View Slide

it should “テスト名” test(new テストベンチモジュール) { tb => }
を追加してテストを増やしていく

View Slide

………いや、何で失敗すんのよ
波形、波形をくれ

View Slide

波形を取得する為に「testOnly * – -DwriteVcd=1」を実行
コマンドの意味は、全てのテスト実行する（* のワイルドカード）。
オプションとしてwriteVcd=1（波形ファイルの書き出し）を渡す
ということ
test_run_dirに「〇_should_●」ディレクトリがあり
その中に vcd ファイルが保存される
GTKWave などで波形を確認してください

View Slide

Chisel assertion
Verilog の assetion の様に毎クロック値を確認する、というようなテストをモジュール内に書けます
assertを使って形式的検証ができるようになる、
という動画を見たけど使い方はよくわかってません…誰か教えて

View Slide

Chisel assertion
rose とかの関数はあって便利だけど、もっと System Verilog の謎記法（↓）チックに書けないの？
property foobar;
@(posedge clk) $rose(valid) |=> foo;
endproperty
FOOBAR : assert property(foobar);
chiselverify を使えばポートに関しては書けそう？
https://github.com/chiselverify/chiselverify

View Slide

Chisel assertion
出力される Verilog が汚くなるのはご愛敬………?
何とかならない？

View Slide

ChiselVerify：追記
セミナー御担当の方は既にご存じかもしれませんが、
Chisel で Test - ChiselVerify
https://github.com/chiselverify/
のような活動もあるようです。
御参考になるようでしたら幸いです。
やばい、System Verilogの並列アサーションもどきとしか書いてないじゃないの
ちょっと README 読んできます

View Slide

ChiselVerify：何ができるの？
※　実際に動かして試したわけじゃないです（これ書いてるの1/24 21:51ですもん）
● Chiselテストの便利関数提供
○ ファンクショナルカバレッジ
■ 3p 前で謎記法もどきと言ってるやつ
○ 制約付きランダム検証機能
■ System Verilog の rand + constraint と同等と思われる
○ AXI4 バス操作関数
● 比較動作検証機能の提供（と思われる）
○ モデル動作として作った RTL や Software の出力と同じ結果になるかどうかの比較検証をするための機能だと思う
■ マイコン開発してた時に「C++ の概念実装」と「Verilogで作ったRTL」の出力比較をするテストベンチを DPI-C
で作ったことがありますが、それっぽい気がする
間違いあったら指摘お願いします

View Slide

Chisel のテストを Verilator で実行
論路規模が大きくなってくると、 FIRRTL のシミュレーションでは時間がかかる
遅いと思ったら Verilator でシミュレーションすることを検討すると良い
.withAnnotations(Seq(VerilatorBackendAnnotation))
Verilator のコンパイルに時間はかかるけど、シミュレーションは早い

View Slide

Verilator がおかしくなったら
Verilator が成功するはずのテストで何故か失敗することがある
- Verilator は失敗するが FIRRTL は成功する
- ポート名などを変更しても VCD に反映されない
- そもそも VCD 波形が出ない
一度 sbt を終了し、以下のディレクトリを削除するとうまくいく（場合がある）
- target ディレクトリ（target　chisel/target）
- test_run_dir ディレクトリ
何が・どれが悪いのかはよくわからない

View Slide

Chisel でテスト　メリット
● 書くのが簡単
○ shell script とか用意しなくても実行集計すぐできる
○ エディタの補完が効くのは偉大
● 外部のライブラリなどをそのまま使える
○ CRC計算の結果があってるかとか、一度ファイルに出すとかせずにライブラリ呼び出した結
果を直接使える
● Scala の強力な構文が色々使える
○ for とか
○ match とか

View Slide

Chisel でテスト　デメリット
● 書くのが辛い
○ Verilog で言ってしまえば、テストベンチの initial 内で全部のテストを記述するようなもの
○ always の様な時間の並列化や、 @(posedge 信号) みたいな記述が簡単にできない
○ 内部の信号に簡単にアクセスできない
● マルチドメインクロックのテストが辛い
○ RTL 側は withClock で CDC は割と簡単に書ける
○ テスト側はテストベンチのクロック単位でしか時間が進まないので CDC が書けない
■ 私はテストベンチ用モジュールでカウンタを使ってクロックを作るようなやり方で記述した
● it should “” の単位でテストを実行できない　（やり方がわからない）
○ VSCode のGUIからはできるのだけども…tag というのを使えばできる？
○ （波形を見たい時に困ってます）
● 入力がクロックの立ち下がりに同期してるのが辛い
○ 信号が増えると目がバグるのでエッジをそろえないでほしい…

View Slide

Chisel でテスト　まとめ
● Chisel でテストする方法について
○ 基本的には poke で値を突っ込んで expect で確認
■ peek〇で値として読みだすこともできます
○ assert を使えば毎クロック勝手にチェック可能
● Chisel のテストを Verilator で走らせる方法について
○ VerilatorBackendAnnotation をつける
○ よく変になるので target ディレクトリとtest_run_dir を削除して sbt 再起動
● Chisel のメリット・デメリット
○ 割とテスト書くのしんどい

View Slide

閑話休題
論理どうやって設計してる？

View Slide

● VSCode + Markdown + mermaid + Draw.io +
タイミングチャート清書サービス(改造)

View Slide

● VSCode
○ 昨今独り勝ち状態のエディタ。Atomさん…
● Markdown
○ いわずもがな
● mermaid
○ 状態遷移図作成等に利用
○ GitHub で Markdown に埋め込んでそのまま表示できる
○ VSCode には Markdown Preview Mermaid Support を導入すれば Markdown に組み込める
■ https://marketplace.visualstudio.com/items?itemName=bierner.markdown-mermaid
● Draw.io
○ HTML5/JavaScript で作られた Visio みたいなもの
○ VSCode では Draw.io Integration で VSCode 上で使うことができる
■ https://marketplace.visualstudio.com/items?itemName=hediet.vscode-drawio
○ *.drawio.svg という拡張子にして保存すれば、Markdown に組み込めて、Draw.io で編集できるので便利

View Slide

● WaveDrom
○ https://wavedrom.com/editor.html
○ 美しいタイミング図が作れる
○ 最近はこれが使われていることが多い印象
■ 正直タイミング図を書くならこれ一択
■ GitHub 対応してくれないかな…
でも書くの面倒くさい　
※個人の感想です。用法容量を守って正しくお使いください

View Slide

● タイミングチャート清書サービス
○ 何も考えずに書ける
○ https://dora.bk.tsukuba.ac.jp/~takeuchi/?%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3
%82%A2%2F%E3%82%BF%E3%82%A4%E3%83%9F%E3%83%B3%E3%82%B0%E3%83%81%E3%83%A3%E3%83
%BC%E3%83%88%E6%B8%85%E6%9B%B8%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9
30

View Slide

● タイミングチャート清書サービス（改造）
○ こんな感じに2カラム化して出力ファイル名を変えれるようにしてる
○ SVG の先頭にオリジナルデータが格納されてるので復元できるようにしてる
○ SVG なので Markdown でそのまま表示できる。便利
○ 信号名で幅の調整しないと見切れるのは如何なものか…
■ タイミグチャート清書サービス記法→WaveDrom→SVG の仕組みを作ろうと思い早や幾年

View Slide

Chisel 開発ノウハウ
（あくまで個人のノウハウ）
32

View Slide

FFの作り方　あれこれ

View Slide

FFの作り方　あれこれ
決まり切った所は関数化

View Slide

Chisel とコンストラクタとフィールド
● Chisel でロジックを書くこの部分はコンストラクタ
● ここにモジュールや信号なども定義していくのがチュートリアル的なスタイル
○ 定義した信号などはフィールドとなり外部からアクセス可能
ioポートではなく、レジスタのb
.ioの書き忘れ

View Slide

出てくるエラーがスタックトレース
何が悪いのか全然わからん

View Slide

● 極力 private val にするようにした
● private をつけるのも面倒になって {} でくくるようになった

View Slide

Chisel と IO Bundle
チュートリアルでは、入出力が反転するポートは Flipped を使って書かれる
Stream の様に入出力がはっきりしてる Bundle なら覚えやすいが、
複雑な Bundle になってくるとどちらで反転するのかわからなくなる
39
val primary = new HogeBundle val secondary = Flipped(new HogeBundle)

View Slide

Chisel と IO Bundle
結局 SystemVerilog の modport をまねる形に落ち着いた
40
class HogeBundle extends Bundle {
val moge = Output( 略)
val piyo = Input( 略)
}
object HogeBundle {
def apply() = new HogeBundle
def ctrl = new HogeBundle
def func = Flipped(new HogeBundle)
}
val ctrl = HogeBundle.ctrl
val func = HogeBundle.func

View Slide

Chisel ノウハウ　まとめ
● FFの作り方
○ RegNextPair という object を作って使ってます
● 内部信号にアクセスする悲劇
○ private val を使いましょう
○ 面倒なら { } で囲いましょう
● IO Bundle の Flipped
○ 結局 SystemVerilog の modport は良いスタイルだと思う

View Slide

最後に
42

View Slide

Chisel は救いになるか。
● 個人的には Verilog よりもずっと好きだし、書いていて楽しい
● 趣味用途には今日からの使用をお勧めします
● 仕事に使えるかどうかは、微妙
○ 万人が使える物ではない
■ 非プログラマとプログラマで書きあがるコードに大きな差が確実に出る
○ エラーがきつい
○ 保証がないことにどう向き合うか？
● 既存モジュール接続のためのグルーロジックとしては仕事に使える
○ 読める程度の Verilog コードしか出てこないなら問題は何もない
● 小さなロジックで社外に出ないコードなら活用可能

View Slide

最後に
● Scala の資産を容易に取り込めるのは強い
○ 一方で、 Scala の上に構築されているが故の問題点があるのも事実
● メタプログラミング的な話もしたかったけど、時間足りないので削った
○ バグなのか、自分のミスなのかもわからないことが多いので手を出さない方が賢明
● 私が思う Chisel の最大の成果は FIRRTL
○ そして時代は LLVM-CIRCT へ
○ 今後もっと LLVM-CIRCT を介してトランスパイルする言語が増えると面白いですね
● Chisel は今後も安泰？
○ お金の流れ的に十分安泰。後はユーザー数の問題かと
○ むろん、JavaScript で言う Chisel = CoﬀeeScript で今後 TypeScript が出てくる可能性も
■ でも、 CoﬀeeScript は今でも俺たちの心の中で輝いてるよね？
ぜひ Chisel を使ってみましょう！

View Slide

Lightning Talk！

View Slide

10 Things Every (Fixstars')
FPGA Engineer Should Know

View Slide

Who I am
写真
Shinya KAJI
梶信也
ソリューション第四事業部　
事業部長

View Slide

Fixstars で 7 年以上 PM を担当してきた経験から
PM の立場で FPGA エンジニアに期待することが
たくさんあります。
今回の LT では PDCA サイクルのステップ毎に、
“10 Things Every (Fixstars')
FPGA Engineer Should Know”
としてご紹介します。

View Slide

1. ゴールまでのマイルストーンを描く
プロジェクトゴールに至るまでの過程をプロジェクトメンバーと共有する。
マイルストーンが不明瞭でメンバー間で共有されていないと余計な手数を踏むことが多い。

View Slide

2. 計画はほどほどに
計画はあくまで計画。過剰に労力をかけない。

View Slide

3. 失敗を恐れずにまずはやってみる
やればできることや既に分かっていることが
仕事として依頼されることは稀なこと。
やることでしか分からないことばかりなので
失敗を恐れずやってみる！
https://twitter.com/suntory/status/1311131655474733057/photo/1

View Slide

4. 自分が出来ることではなく、求められていることを叶える
経験が長いエンジニアほどやり方が確立され、自分の出来ることと出来ないこと
が明確に認識できる。自分なりの方法論を採用することは確実性が高いかもしれ
ないが、ステークホルダーが求めているとは限らない。

View Slide

5. エンドユーザ思考
システムを最終的に使うユーザのことを考え、どうあるべきかを考え続ける。

View Slide

6. 求められているのは価値創造
プロセス (Process) よりも価値創造 (Produce) を大切にする
価値創造
Produce
プロセス
Process

View Slide

7. システム思考
ソフトウェアでもなくハードウェアでもなく、顧客が求めるものはシステムであ
りソリューションであることを忘れない

View Slide

8. 自問自答を繰り返す
この設計は妥当か？
この実装よりも良いものはないか？
自動化して属人性を排除できないか？
言いたいことは伝えられているか？
プロジェクトに関係するメンバー間で知
識レベルや前提知識は違って当然。
相手が分かってくれることを期待せず、
相手に知ってもらうために自分の成果を
客観視する！

View Slide

9. 僅かな努力を積み上げる力
日々 0.1% の成長を 10 年間コツコツと積み上げたエンジニアの成長は著しい

View Slide

10. AI everywhere
AI for your family
AI for your friends
AI for your team
AI for your clients
AI for yourself

View Slide

実践的！FPGA開発セミナーvol.18 / FPGA_seminar_18_fixstars_corporation_20230125

実践的！FPGA開発セミナーvol.18 / FPGA_seminar_18_fixstars_corporation_20230125

株式会社フィックスターズ

More Decks by 株式会社フィックスターズ

Other Decks in Programming

Featured

Transcript