RTLを語る会(18)に参加してきました
どもです。
早速ですが、参加&発表してきました。
今回はその模様について可能な限りレポートしつつ、自身の発表内容について伝え忘れたことや補足等をまとめたいと思います。
今回のテーマについて
今回のテーマは「おかえりaltera, こんにちはGowin」でした。
(ちなみに前回は「こんにちはEfinix」でした)
そのテーマの通り、昨今のFPGA界隈では
という2大イベントがあり、これを仮テーマにした会ということになります。
(ちなみに、小テーマは毎回ありますが発表内容がこれに沿ったものである必要は無い、という認識です。ゆるさが良いのだ。)
(さらに言えば、私の発表は「RTLを語る」内容かどうかすら怪しいです。この会はゆるさが良いのだ。)
参加人数について
全員で50人弱いました。主催者もここまでの人数になることは想定していなかった様子です。
私は見通しの甘さで大遅刻をかましてしまい、デスク席に座れませんでした・・・・w
うげー発表時間ギリギリ
— AUDIY (@AUDIY14) November 8, 2025
こりゃシバく会でシバかれる#talkrtl
そして参加者の面々が強い方々!中にはDesign Solution ForumやDVCon等で発表実績のある方々もいます。まぁ緊張しますね。
なお参加者の面々が強すぎて「これワイが発表して良かったんか」となってる(おいおい) #talkrtl https://t.co/IglARacoyG
— AUDIY (@AUDIY14) November 8, 2025
まぁ良いでしょう。「論よりRUN」と言いますしw
発表内容
Questa - Altera FPGA Starter Editionでアサーション検証を実践してみた、という報告です。
私みたいな「回路設計部署の一員がFPGA設計も担当する」部署の場合、FPGA担当が設計も検証も行うと少数精鋭(笑)で設計しなければなりません。
そんなところがステートマシンだの複数モジュールのコントロールロジックだのを実装する場合、波形確認だけでは事前検証が追いつかないです。
(これはあくまで推測ですが、事前検証の時間を確保させてもらえないがゆえ、「仕様書がない」、「RTLのバージョン管理がされない」、「変更したら実機ぶち込み検証」の三拍子が揃うところが出てくるのだと思います。)
波形確認だけでは絶対に見落とす可能性もあるので、「見落としそうな波形やシーケンスの確認はアサーション検証機能にまかせてしまおう」、そんなお話でした。
補足事項
発表の中で伝えそこねた補足事項をここにまとめておきたいと思います。
Questa FSEのライセンス
Questa FSEですが、無償で使用できるもののライセンスを1年毎に更新する必要があります。
しかもそのライセンスは使用するPCのMACアドレスに紐づけされるので、使用する際はインターネット接続環境が必要です。
ライセンス発行手順については代理店のマクニカ社がまとめている内容が最も正確かと思います。
Verilatorで実行するアサーションについて
「Verilatorでも実行可能」と伝えましたが、現状は「同一クロックサイクル内で監視が完了するアサーションのみ実行可能」という制限があります。
つまり、現在では時相論理を含むシーケンスに対するアサーションはできません。
まぁVerilatorは実行速度の高速性がウリみたいなところもあるので、適材適所で別のアサーション検証可能なシミュレータと使い分ければ良いと思います(私もRTL書き終えたらVerilatorでシミュレーションし、問題なければQuestaで詳細見ます)。
学生の特権シミュレータ
「学生のみ無償で使用できるAldecのシミュレータ」についてちょこっと触れましたが、下記リンク先に詳細あります。
自分が学生のときに触れてみたかったなぁ・・・
「仕様」と「アサーション」
「仕様からアサーションを書き起こしていく」という手順について話しましたが、ここで伝え損ねたことは「仕様書の記述を盲信しない」ということです。
仕様書は図や表とともに自然言語で書く以上、どうしても曖昧さが出てくる場面があります。
例えば、仕様からアサーションを記述する過程で「仕様を満たすアサーションの書き方が複数あるぞ・・・・」となった場合、もとにする仕様が曖昧すぎるがゆえにアサーションの記述が定まらない状況になっている可能性があります。このような場合は仕様書の内容を修正したほうが良いでしょう(仕様の作成者含め、あとから読む人の理解を妨げる要因になります)。
そういう意味では、「アサーションを記述する」ということは、「仕様書の内容を見直す」ということにもつながります。
SVAか、PSLか、OVLか
さまざまな要因が絡むので一概にオススメを述べることはできませんが、おそらくWeb上で最も情報が入手しやすいのはSVAだと思います。
一方でSVAはSystemVerilog標準の検証機能のため、Verilog (IEEE 1364)やVHDLのコード内に記述できません。
PSLはそれ自体が規格化されていることや、コード上にコメントとして埋め込むのでVerilog/SystemVerilog/VHDLいずれのハードウェア記述言語でも使用できます。また、記述自体はコメント上に埋め込むため、アサーションそのものやPSLに対応しない検証ツールは記述を無視できるという利点もあります。
OVLも同様にVerilog/SystemVerilog/VHDLで使用できます。また、チェックする項目がモジュール化されており、一部チェック項目では論理合成も可能なので、フラグ出力などをOVLに任せる、なんてこともできます。ただし、ちゃんと管理しないと余計な回路をデザイン内に含む可能性はありそうです。
Verylがアツいらしい
今回の発表者で開発にVerylを使用している方がそこそこ多かったのが驚きです。
正直なことを言うと私はRTLはVerilogで書いてて、テストベンチをSystemVerilogで書いています。
理由としては
- SystemVerilogは論理合成向け記述のベンダーの対応状況がまばら
- 単純にVerilogに慣れている
- でもSystemVerilogの検証機能が使えるように準備はしておきたい
といった感じです。
全然試せていないのが現状なので、今度環境を導入してみようと思います。
翌日
秋葉原でTang Nano 4K + カメラを買いました。
映像処理にも手を出してみようと思った次第です。
カメラが欲しくなったのでカメラ付きSoC FPGA買った(あとラズピコのデバッガも) pic.twitter.com/j7tB9VgAfv
— AUDIY (@AUDIY14) November 9, 2025
え?「Tang Mega 138Kシバかないのか」ですって?
https://ja.aliexpress.com/item/1005006080116482.html
KR260シバいてからにします・・・
最後に
今回、若手(30歳以下)発表枠で発表させていただきましたが、圧倒的に強いFPGA/ASIC/RTL設計/検証エンジニアの前で緊張しながらではありましたが発表の機会を持てたことは大変貴重な機会でした。
回路設計部署の中で少数精鋭(笑)の状態でFPGA設計しているとなかなか情報交換の機会を持てなかったり、部署の他メンバーへの説明がなかなかすんなり受け入れられなかったりで悩むことも多いですが、一歩外に出れば同様の人はたくさんいるということも改めて感じました。
幸い、30歳まであと数年ありますので、もう一回くらい若手発表枠で発表してみたいところです。