2023年1月25日に開催した、「実践的!FPGA開発セミナーvol.18」の当日資料です。
Copyright© Fixstars Group実践的!FPGA開発セミナーvol.182023/01/25 18:00~
View Slide
Copyright© Fixstars Groupテストとノウハウ編:FPGA の論理を Chiselでゴリゴリ開発してみた話
Copyright© Fixstars GroupWho I amYoshitakaTAKEMOTO竹本 義孝ソリューション第四事業部 シニアエンジニア
Copyright© Fixstars Group前回のコメント等への回答
Copyright© Fixstars GroupChisel と Verilog の簡易比較Verilog Chiselport 宣言 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:endcasewhen().elsewhen().otherwise が良いMuxLookupやswitch-is があるにはあるが …instance 化 my_module i1 (.x(x),.y(y));val i1 = Module(new MyModule)i1.io.x := xi1.io.y := yコメント:switch is でいいのでは?私:switch is は default がないコメント: 次のように書けばいいx := defaultValueswitch~~指摘に気が付いてなくてすみません
Copyright© Fixstars Groupswitch is を好まない理由switch 構文は本質的に実装忘れに気が付けないからx := defaultXy := defaultYswitch(cnd) {is (CND1) {x := 1.Uy := 1.U}is (CND2) {x := 2.U// y := 2.U 実装忘れ}}when(cnd === CND1) {x := 1.Uy := 1.U}.elsewhen(cnd === CND2) {x := 2.U//y := 2.U 実装忘れ}.otherwise {x := defaultXy := defaultY}yに未定義はないのでコンパイルエラーなしyの未定義を検知してコンパイルエラー
Copyright© Fixstars GroupChiselのメリットが何なのか結局よくわからない立場によって違うと思われます個人:● Verilog より IDE 等の補完が強力● 記述が圧縮できる● Verilog より楽しい(個人の感想)● そもそも新しいパラダイムや機構に触れること以上のメリットが必要か?組織:● 微妙
Copyright© Fixstars GroupChisel でテスト
Copyright© Fixstars GroupChisel でテストChisel のテストは、シミュレータを操作することで値を入力したり、値が正しいかの確認を行う※ Chisel 3.6からは CIRCT に変わります
Copyright© Fixstars GroupChisel でテストを作るenableが1の時のinを加算し、出力するモジュール
Copyright© Fixstars GroupChisel でテストを作るsbt で test とタイプするとテストを実行できる成功すると[success]とでて終了する
Copyright© Fixstars GroupChisel でテストを作るsbt で test とタイプするとテストを実行できる成功すると[success]とでて終了する正しく修正
Copyright© Fixstars GroupChisel でテストを作るit should “テスト名” test(new テストベンチモジュール) { tb => }を追加してテストを増やしていく
Copyright© Fixstars GroupChisel でテストを作る………いや、何で失敗すんのよ波形、波形をくれ
Copyright© Fixstars GroupChisel でテストを作る波形を取得する為に 「testOnly * – -DwriteVcd=1」を実行コマンドの意味は、全てのテスト実行する(* のワイルドカード)。オプションとしてwriteVcd=1(波形ファイルの書き出し)を渡すということtest_run_dirに 「〇_should_●」ディレクトリがありその中に vcd ファイルが保存されるGTKWave などで波形を確認してください
Copyright© Fixstars GroupChisel assertionVerilog の assetion の様に毎クロック値を確認する、というようなテストをモジュール内に書けますassertを使って形式的検証ができるようになる、という動画を見たけど使い方はよくわかってません…誰か教えて
Copyright© Fixstars GroupChisel assertionrose とかの関数はあって便利だけど、もっと System Verilog の謎記法(↓)チックに書けないの?property foobar;@(posedge clk) $rose(valid) |=> foo;endpropertyFOOBAR : assert property(foobar);chiselverify を使えばポートに関しては書けそう?https://github.com/chiselverify/chiselverify
Copyright© Fixstars GroupChisel assertion出力される Verilog が汚くなるのはご愛敬………?何とかならない?
Copyright© Fixstars GroupChiselVerify:追記セミナー御担当の方は既にご存じかもしれませんが、Chisel で Test - ChiselVerifyhttps://github.com/chiselverify/のような活動もあるようです。御参考になるようでしたら幸いです。やばい、System Verilogの並列アサーションもどきとしか書いてないじゃないのちょっと README 読んできます
Copyright© Fixstars GroupChiselVerify:何ができるの?※ 実際に動かして試したわけじゃないです(これ書いてるの1/24 21:51ですもん)● Chiselテストの便利関数提供○ ファンクショナルカバレッジ■ 3p 前で 謎記法 もどきと言ってるやつ○ 制約付きランダム検証機能■ System Verilog の rand + constraint と同等と思われる○ AXI4 バス操作関数● 比較動作検証機能の提供(と思われる)○ モデル動作として作った RTL や Software の出力と同じ結果になるかどうかの比較検証をするための機能だと思う■ マイコン開発してた時に「C++ の概念実装」と「Verilogで作ったRTL」の出力比較をするテストベンチを DPI-Cで作ったことがありますが、それっぽい気がする間違いあったら指摘お願いします
Copyright© Fixstars GroupChisel のテストを Verilator で実行論路規模が大きくなってくると、 FIRRTL のシミュレーションでは時間がかかる遅いと思ったら Verilator でシミュレーションすることを検討すると良い.withAnnotations(Seq(VerilatorBackendAnnotation))Verilator のコンパイルに時間はかかるけど、シミュレーションは早い
Copyright© Fixstars GroupVerilator がおかしくなったらVerilator が成功するはずのテストで何故か失敗することがある- Verilator は失敗するが FIRRTL は成功する- ポート名などを変更しても VCD に反映されない- そもそも VCD 波形が出ない一度 sbt を終了し、以下のディレクトリを削除するとうまくいく(場合がある)- target ディレクトリ(target chisel/target)- test_run_dir ディレクトリ何が・どれが悪いのかはよくわからない
Copyright© Fixstars GroupChisel でテスト メリット● 書くのが簡単○ shell script とか用意しなくても実行集計すぐできる○ エディタの補完が効くのは偉大● 外部のライブラリなどをそのまま使える○ CRC計算の結果があってるかとか、一度ファイルに出すとかせずにライブラリ呼び出した結果を直接使える● Scala の強力な構文が色々使える○ for とか○ match とか
Copyright© Fixstars GroupChisel でテスト デメリット● 書くのが辛い○ Verilog で言ってしまえば、テストベンチの initial 内で全部のテストを記述するようなもの○ always の様な時間の並列化や、 @(posedge 信号) みたいな記述が簡単にできない○ 内部の信号に簡単にアクセスできない● マルチ ドメイン クロックのテストが辛い○ RTL 側は withClock で CDC は割と簡単に書ける○ テスト側はテストベンチのクロック単位でしか時間が進まないので CDC が書けない■ 私はテストベンチ用 モジュールでカウンタを使ってクロックを作るようなやり方で記述した● it should “” の単位でテストを実行できない (やり方がわからない)○ VSCode のGUIからはできるのだけども…tag というのを使えばできる?○ (波形を見たい時に困ってます)● 入力がクロックの立ち下がりに同期してるのが辛い○ 信号が増えると目がバグるのでエッジをそろえないでほしい…
Copyright© Fixstars GroupChisel でテスト まとめ● Chisel でテストする方法について○ 基本的には poke で値を突っ込んで expect で確認■ peek〇 で値として読みだすこともできます○ assert を使えば毎クロック勝手にチェック可能● Chisel のテストを Verilator で走らせる方法について○ VerilatorBackendAnnotation をつける○ よく変になるので target ディレクトリとtest_run_dir を削除して sbt 再起動● Chisel のメリット ・ デメリット○ 割とテスト書くのしんどい
Copyright© Fixstars Group閑話休題論理どうやって設計してる?
Copyright© Fixstars Group論理どうやって設計してる?● VSCode + Markdown + mermaid + Draw.io +タイミングチャート清書サービス(改造)
Copyright© Fixstars Group論理どうやって設計してる?● 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 で編集できるので便利
Copyright© Fixstars Group論理どうやって設計してる?● WaveDrom○ https://wavedrom.com/editor.html○ 美しいタイミング図が作れる○ 最近はこれが使われていることが多い印象■ 正直タイミング図を書くならこれ一択■ GitHub 対応してくれないかな…でも書くの面倒くさい ※個人の感想です。用法容量を守って正しくお使いください
Copyright© Fixstars Group論理どうやって設計してる?● タイミングチャート清書サービス○ 何も考えずに書ける○ 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%B930
Copyright© Fixstars Group論理どうやって設計してる?● タイミングチャート清書サービス(改造)○ こんな感じに2カラム化して出力ファイル名を変えれるようにしてる○ SVG の先頭にオリジナルデータが格納されてるので復元できるようにしてる○ SVG なので Markdown でそのまま表示できる。便利○ 信号名で幅の調整しないと見切れるのは如何なものか…■ タイミグチャート清書サービス記法→WaveDrom→SVG の仕組みを作ろうと思い早や幾年
Copyright© Fixstars GroupChisel 開発ノウハウ(あくまで個人のノウハウ)32
Copyright© Fixstars GroupFFの作り方 あれこれ
Copyright© Fixstars GroupFFの作り方 あれこれ決まり切った所は関数化
Copyright© Fixstars GroupChisel と コンストラクタ と フィールド● Chisel でロジックを書くこの部分はコンストラクタ● ここにモジュールや信号なども定義していくのがチュートリアル的なスタイル○ 定義した信号などはフィールドとなり外部からアクセス可能ioポートではなく、レジスタのb.ioの書き忘れ
Copyright© Fixstars GroupChisel と コンストラクタ と フィールド出てくるエラーが スタック トレース何が悪いのか全然わからん
Copyright© Fixstars GroupChisel と コンストラクタ と フィールド● 極力 private val にするようにした● private をつけるのも面倒になって {} でくくるようになった
Copyright© Fixstars GroupChisel と IO Bundleチュートリアルでは、入出力が反転するポートは Flipped を使って書かれるStream の様に入出力がはっきりしてる Bundle なら覚えやすいが、複雑な Bundle になってくるとどちらで反転するのかわからなくなる39val primary = new HogeBundle val secondary = Flipped(new HogeBundle)
Copyright© Fixstars GroupChisel と IO Bundle結局 SystemVerilog の modport をまねる形に落ち着いた40class HogeBundle extends Bundle {val moge = Output( 略)val piyo = Input( 略)}object HogeBundle {def apply() = new HogeBundledef ctrl = new HogeBundledef func = Flipped(new HogeBundle)}val ctrl = HogeBundle.ctrlval func = HogeBundle.func
Copyright© Fixstars GroupChisel ノウハウ まとめ● FFの作り方○ RegNextPair という object を作って使ってます● 内部信号にアクセスする悲劇○ private val を使いましょう○ 面倒なら { } で囲いましょう● IO Bundle の Flipped○ 結局 SystemVerilog の modport は良いスタイルだと思う
Copyright© Fixstars Group最後に42
Copyright© Fixstars GroupChisel は救いになるか。● 個人的には Verilog よりもずっと好きだし、書いていて楽しい● 趣味用途には今日からの使用をお勧めします● 仕事に使えるかどうかは、微妙○ 万人が使える物ではない■ 非プログラマとプログラマで書きあがるコードに大きな差が確実に出る○ エラーがきつい○ 保証がないことにどう向き合うか?● 既存モジュール接続のためのグルーロジックとしては仕事に使える○ 読める程度の Verilog コードしか出てこないなら問題は何もない● 小さなロジックで社外に出ないコードなら活用可能
Copyright© Fixstars Group最後に● Scala の資産を容易に取り込めるのは強い○ 一方で、 Scala の上に構築されているが故の問題点があるのも事実● メタ プログラミング的な話もしたかったけど、時間足りないので削った○ バグなのか、自分のミスなのかもわからないことが多いので手を出さない方が賢明● 私が思う Chisel の最大の成果は FIRRTL○ そして時代は LLVM-CIRCT へ○ 今後もっと LLVM-CIRCT を介してトランスパイルする言語が増えると面白いですね● Chisel は今後も安泰?○ お金の流れ的に十分安泰。後はユーザー数の問題かと○ むろん、JavaScript で言う Chisel = CoffeeScript で今後 TypeScript が出てくる可能性も■ でも、 CoffeeScript は今でも俺たちの心の中で輝いてるよね?ぜひ Chisel を使ってみましょう!
Copyright© Fixstars GroupLightning Talk!
Copyright© Fixstars Group10 Things Every (Fixstars')FPGA Engineer Should Know
Copyright© Fixstars GroupWho I am写真Shinya KAJI梶 信也ソリューション第四事業部 事業部長
Copyright© Fixstars GroupFixstars で 7 年以上 PM を担当してきた経験からPM の立場で FPGA エンジニアに期待することがたくさんあります。今回の LT では PDCA サイクルのステップ毎に、“10 Things Every (Fixstars')FPGA Engineer Should Know”としてご紹介します。
Copyright© Fixstars Group1. ゴールまでのマイルストーンを描くプロジェクトゴールに至るまでの過程をプロジェクトメンバーと共有する。マイルストーンが不明瞭でメンバー間で共有されていないと余計な手数を踏むことが多い。
Copyright© Fixstars Group2. 計画はほどほどに計画はあくまで計画。過剰に労力をかけない。
Copyright© Fixstars Group3. 失敗を恐れずにまずはやってみるやればできることや既に分かっていることが仕事として依頼されることは稀なこと。やることでしか分からないことばかりなので失敗を恐れずやってみる!https://twitter.com/suntory/status/1311131655474733057/photo/1
Copyright© Fixstars Group4. 自分が出来ることではなく、求められていることを叶える経験が長いエンジニアほどやり方が確立され、自分の出来ることと出来ないことが明確に認識できる。自分なりの方法論を採用することは確実性が高いかもしれないが、ステークホルダーが求めているとは限らない。
Copyright© Fixstars Group5. エンドユーザ思考システムを最終的に使うユーザのことを考え、どうあるべきかを考え続ける。
Copyright© Fixstars Group6. 求められているのは価値創造プロセス (Process) よりも価値創造 (Produce) を大切にする価値創造ProduceプロセスProcess
Copyright© Fixstars Group7. システム思考ソフトウェアでもなくハードウェアでもなく、顧客が求めるものはシステムでありソリューションであることを忘れない
Copyright© Fixstars Group8. 自問自答を繰り返すこの設計は妥当か?この実装よりも良いものはないか?自動化して属人性を排除できないか?言いたいことは伝えられているか?プロジェクトに関係するメンバー間で知識レベルや前提知識は違って当然。相手が分かってくれることを期待せず、相手に知ってもらうために自分の成果を客観視する!
Copyright© Fixstars Group9. 僅かな努力を積み上げる力日々 0.1% の成長を 10 年間コツコツと積み上げたエンジニアの成長は著しい
Copyright© Fixstars Group10. AI everywhereAI for your familyAI for your friendsAI for your teamAI for your clientsAI for yourself
Copyright © Fixstars GroupThank you!お問い合わせ窓口 : [email protected]