参加するのは2度めで、前回「どえらく濃い場に来てしまったぞ・・・」と感じた記憶があります。HLS(Xilinxの高位合成系)を使い倒して得られた諸々の話が展開されていて「貴重な場だ・・・」という感想でした(KONMAI感)。資料が公開されている分についてはイベント資料一覧で確認できます。一部の資料は公開されていません(これも大変得るものが多いセッションで、現地参加して本当によかったと思いました)。3)に関する話をしました。端折りましたが、実際には18分ぐらい喋っていた気がします。3日目西a-05abでScala+Chisel入門記事の載った技術書が出ますやChiselで開発を始める小冊子(MFT2016配布物)の小改訂版を100円で販売しますで紹介しているのでここでは触れません。3とそのバックエンドであるFIRRTLについてこれまであまり言及していないので書きます。2とほぼ互換性を保った記法を採用していますが、中身の実装が大きく異なります。代表的な違いは、構造のフロントエンドとバックエンドが切り分けられた点です(図1)。2は実行時に回路情報に基づいた.v/.cppファイルを自前生成し、.cppの場合はそれをコンパイルして開発環境用のネイティブバイナリを生成します。生成されたバイナリをDUTとしてChisel側に用意したテストコードと接続してシミュレーション検証をおこないます。3では、バックエンドがFIRRTLというプロジェクトへ切り出されました。Chisel本体が担うのはFIRRTLの生成と、FIRRTLの先で生成されたバイナリとの通信によるシミュレーション検証作業のみへと軽減されます。2でマルチクロック利用などの込み入ったコードを書くと、回避の面倒なバグを踏むことが多くあります(代表的なのが#696です)。2から生成した.cppコードがそもそもコンパイルを通らないケースもあります(マルチクロック利用時にcpp側のスコープ切りがおかしいパターンほか)。3+FIRRTLでは.cppコードの生成がChisel内部からFIRRTL側へ移っただけでなく、生成にVerilator*1を利用するようになりました*2。Verilatorは高速なHDLシミュレータ兼、HDL→C++コードの生成ユーティリティです。2/3とFIRRTLの話をしたところで本題です。3世代では、バギーでメンテしづらいC++コード生成系を切り離せたことで今後のChiselプロジェクトの見通しがよくなることを期待できる一方、Chiselと同列にあたるFIRRTLのフロントエンドを比較的簡単に作れるようになりました。実は最近、Kindleへ突っ込んでおいたFIRRTLの言語仕様書を空いた時間でせっせと読んでいました。今回は運良く会場へのまとまった移動時間がありました。そこで「FIRRTLのフロントエンドとなる自前DSLを作ってみよう。C#ターゲットで」と思い立ち、作ってみました。ここでC#を選択したのは自分が使い慣れているのに加えて、IDEが充実しており「プログラマ負荷の低いHDLを構築できる下地がある」可能性があるためです。FIRRTLのフロントエンドとしては、FIRRTL言語仕様に従ったコードを生成する機能があれば最低限の要件を満たせます(これに加えてDUTとの通信・テスト機能などを適宜作り込むことになります)。FIRRTL#そして作ったのがFIRRTL#という処理系です。.NET向けのクラスとして書いており、「回路内の単一モジュール定義と、モジュールの入出力ポートでAND/XOR処理をできる」ものです。HDLコードを生成できます。halfadder_io_a;...FIRRTL#、おいしいの?おいしくありません。6時点の構文でどの程度直感的かつ柔軟なHDL記法を実現できるか、という検討を重視しました。見で厳しそうだな、と思ったところは案の定厳しいものです。I/OポートのIDEでのコード補完ぐらいは効きます。I/O内の信号宣言時に個別の型指定をおこなうことで、型検証の道を残しつつ簡便な記法を維持することもできました。これを育てていけば形になりそうにも見えますが、実際は次のように大きな問題が複数あります。致命的なのが、C#を利用している限り<=を信号の受け渡し用演算子として自然な記法で成立させられないことです。これは演算子のオーバーロードでは解決できない問題で、C#が1;のような記述を許さないためです。io.b);のようなif+空ステートメントの組み合わせでコードを記述できますが、この構文を許容するぐらいなら圧倒的にScalaを学んだほうが生産的です。io.b;という微妙に嫌な構文で妥協することも許されません。io.b;といった記法は可能かもしれませんが、許容しがたい記法なので深く検討していません。C#は構文上の制約としてシンボルに指定できる文字種が少ないため、たとえば<==といったメソッドを作るのも無理筋です(さらに、中置記法もないので自然な形には収められません)。このあたりを満たす言語を作って、そこからC#コードを生成するという手はなくもないのですがFIRRTLの性質を考えると本末転倒です。名前は.NET向け各種バインディングの慣習に従ってFIRRTL#と付けましたが、大したことはやっていません。firrtl-sharpにてコードを公開しておきます。6時点の構文でどの程度直感的かつ柔軟な記法を実現できるか、という検討に時間を多く使った結果、FIRRTLコード生成部分は見るも無残な感じになりました。これを拡張してもどこにもたどり着きはしないと思います。他言語でFIRRTL対応DSLを組むために最低限必要な要素が何かを知りたい場合には多少参考になるかもしれません。languageとしてのHDL生成系がコンセプトとしてアリか否かを検討し、可能な範囲で試作してみるというのがメイン目的だったので、目的は満たせました。テストハーネスなどは作っていないので、生成されたHDLの自動テストができるわけでもありません。まとめFIRRTLによってHDL生成系を分離できたのはChiselの将来にとって良さそうで、この先割と良いバランスの立ち位置に落ち着きそう。MacBookを4/10に注文、4/14出荷、届いたのは4/17だったので正確にはもうすぐ2ヶ月ですが。Dockerで簡単にGPU対応のTensorFlow入りコンテナを作る方法こんにちは。作品群を読んでいたら連休が終わりそうです。重くなるので読み込まないようにすればOK。資料を補足するシリーズです。途中でやったことや、参考情報を書いていきます。