Verilator v5.046にContributeしたお話
どもです。
タイトルの通り、Verilatorのv5.026にて一部Contributeしました。
テスト通ったε-(´∀｀; )https://t.co/UUIIDysx25
— AUDIY (@AUDIY14) February 24, 2026
Verilatorとは
このブログの読者の殆どはご存知かと思いますが、念のため書いておきます。
VerilatorはオープンソースのVerilog/SystemVerilogシミュレータです。
Verilog/SystemVerilogコードを実行可能なC++に変換したうえで実行することで高速なシミュレーションを実現しており「世界一高速なVerilog/SystemVerilogシミュレータ」を謳っています。
NXPなどの半導体開発の大企業も採用しているらしく（根拠の提示はありませんが）、オープンソースのRTLシミュレータの中で最も勢いがあると思います。
CHIPS Allianceによる支援を受けており、antmicroなどの企業からも積極的な開発サポートを受けています。
近年だと「UVM 2017-1.0に対応した！」とか
「制約付きランダムへの対応を始めた！」とか
非常に高額な有償シミュレータでしか対応してなかった検証機能への対応も始めています。
（個人的にはSystemVerilog Assertionのコンカレントアサーションにも対応してほしいところですが）
要望の内容
「Verilatorのコードカバレッジのアノテーション（コード上に埋め込むテスト結果）から、どの種類のカバレッジが計測されたかわかるようにしてほしい」というものです。
Verilator、フリーのツールとしては非常に強力なコードカバレッジの機能があるのですが、v5.044までは
- アノテーション上で「実行されたこと」はわかるが、「実行されたカバレッジの種類」は記載されない
- HTML形式のカバレッジレポートも出力できるが、lcov（本来はソフトウェア用のカバレッジ測定ツール）を使っている関係でラインカバレッジ以外は全てブランチカバレッジとしてカウントされてレポートに出力される
と、カバレッジの結果が少々分かりづらいところもありました。
Verilatorのカバレッジを実行した際に出力されるデータファイル（coverage.dat）にはカバレッジの種類が記載されているので、「やろうと思えばできるはず！」ということで試してみることにしました。
Issueの提起
まずはIssueを提起します。
するとものの数分でメンテナーのWilson Snyder氏からコメントが。
Thought there was a way to get more information, but looks like not.
Might you prepare a pull to make this the permanent (don't think need option) behavior? Thanks.
VerilatorのContributeに関するルールをあまり読まないままIssueを投げてしまったのですが、どうやら「基本的には修正点を含めてIssueを提起し、Pull requestをよこしてほしい」ということの様です。
該当部分を探す
さて、ここから必死にアノテーションのコメントを記述する箇所をC++コードから探すことになります。
最初はchatGPTを使って探してもらったのですが、私のプロンプトが悪いのか「それはC++ではなくPerlスクリプトで実行される」とわけのわからないことを言われ、結局自分で探すことになるのでした。
見つけた！
どうやって見つけたかもはや覚えていませんが、意外と時間がかからず見つかりました
アノテーション表示の実体をやっと見つけた。プルリク作るっきゃねぇ！https://t.co/WyYE48kTcV
— AUDIY (@AUDIY14) February 23, 2026
これを以下のように修正しました。
意外と多い変更点
こういう「しっかりしたオープンソースソフトウェア」は、テスト環境もちゃんと整っています。
コードの変更だけだとテストが通らず、テスト比較用のファイルも一式差し替えることなりました。
最小はちまちま直してましたが、最終的には手元のLinuxマシンでビルドして得られたテスト用の出力ファイルをプッシュしました。
（ちまちま直してる途中でメンテナーから注意されました。みなさんは真似しないようにしましょう。）
その他にも・・・
ドキュメンテーション上のアノテーション例を修正しました。
こちらはすんなり反映されました。
そしてリリース
2026年2月28日にリリースされた安定版のv5.046にてこの機能が有効になっています。
先のちまちまプッシュもそうですが、2月28日最新リリース予定とはしらず、ギリギリの日程でプルリクエストを出してしまい、反省しています。迅速に対応してくれたメンテナーに感謝です。
感想
今回はたまたま軽微なソースコード変更で済みましたが、まずはプロジェクトのContributionに関するルールを確認すべきでした。
ただ、普段は「使う側」の私が実際の開発に貢献できるのはオープンソースの最大の良さだと思います。自分のスキルの限りで修正できそうなところがあれば今後も積極的にContributeしていきたいです。
「Questa-Altera FPGA Starter Editionで始めるRTL検証」を公開しました
どもです。
本記事はQiitaのHardware Description Language Advent Calenderの参加記事になります。
掲題の通り、「Questa-Altera FPGA Starter Editionで始めるRTL検証」を公開しました。
この記事では、本書を公開するに至った経緯や本書に書かれていない裏話を含めて紹介したいと思います。
経緯
きっかけとしては、Altera FPGA開発ソフトウェアであるQuartus Primeに付属するRTLシミュレータがModelSimからQuestaに変更になったことです。
詳細については下記リンク先をご確認いただければと思いますが、これまで付属していたModelSim-ISEと比較してシミュレーション速度の高速化や、各種検証機能の追加が行われています。
近年は他にも高度な検証機能が使用できる無償シミュレータが増えてきていますが、当時はなかなか画期的なニュースだったと記憶しています。
早速筆者も所有のPCにインストールし、使ってみることにしたのでした。
GUIでは使いにくい
これはModelSim-ISEを使用していたときから思っていたことではありますが、GUIで全ての操作を行おうとすると、非常に効率が悪いです。
「どうしたものかなー」と当初は思っていましたが、なんとコマンドやそれらを集約したバッチファイルからシミュレーション実行を自動化できると知り、「これはまとめておかねば」と思った次第です。
また、それらのバッチ実行からコードカバレッジやアサーションなどの検証も実行できるとのことで、この時点で何かの形態で公開しておきたいなーと思った次第です。
少数精鋭（笑）だからこそ検証は慎重に！
で、まぁなぜ筆者がまとめたかと言いますと、「筆者の本職のFPGA開発担当が少数精鋭（笑）だから」です。
※「少数精鋭（笑）」・・・本来はメンバーが足りておらず行き当たりばったりなのに管理職や経営陣が認めたくなくて虚勢を張っているさま。
そもそもFPGA設計専門の部署など存在せず、回路設計部署の中で1プロジェクトあたり1~2名ほどがFPGAのRTL設計&検証も兼任するという状況です（ひどいところだと回路設計20年のベテランが、全く経験したことのないRTL設計に放り込まれる有り様）。
で、そういう部隊で発生しているのが
- RTLの仕様書がない（回路やシステム全体の仕様書はあるのに）
- RTLの事前検証の形跡がない（回路やシステムの検証はちゃんと記録・保管されるのに）
- RTLの事前検証なく実機ぶち込み
- 適切に処理されていない非同期設計のオンパレード
少数精鋭（笑）だからといって認められるはずがありません。
で、このような少数部隊でのFPGA開発は職業のみならず趣味の場面でも発生します。
まぁ趣味でFPGA使って何か開発しているような人たちは少数精鋭（笑）ではなく（真の）少数精鋭だと思いますが、他に検証してくれる人がいない以上慎重に目を光らせて検証すべきであることには変わりありません。
ということで、趣味でFPGAを使って何か作っているような人たちが少しでも検証が楽になればと思い、Zennにまとめることにしました。
趣味でFPGAつくる人の中にはCPUなどの非同期設計のオンパレードなものを開発する人もいるようなので、今後RTL検証の重要性は高まるばかりと思います。
構成
本書の構成は以下の通りになります。
- まえがき
- イントロダクション
- Questa-Altera FPGA Starter Editionの導入
- 基本的なRTLシミュレーション~GUI実行~
- 基本的なRTLシミュレーション~バッチ実行~
- 高度な検証1：X/Z追跡（信号追跡）
- 高度な検証2：コードカバレッジ
- 高度な検証3：アサーションベース検証
- まとめ
- あとがき
基本的なシミュレーション方法を含め、近年のRTL検証で行われているコードカバレッジおよびアサーションベース検証について触れることのできる内容となっています。
聞いたところによると「UVMの基本機能も使える」とのことなので、随時情報を追加していけたらと思っています。
サンプルプロジェクト
本書に記載の内容を実際に試していただけるサンプルプロジェクトを以下リンク先のGitHubに公開しています。
ライセンスはCERN-OHL-P v2としています。ライセンスの範囲内でご自由にお使いいただければと思います。
また、プロジェクトを使いやすくするためのプルリク等大歓迎です！
表紙について
表紙はChatGPT（無償版）を利用して生成した画像になります。思いのほか「理想的に」「同人誌っぽく」「可愛く」仕上がりました。
実は表紙の画像を描いてくださるイラストレーターさんを募集していましたが、公開までに見つからず生成AIに頼んでみた形になります。
Questa本（仮称）の表紙デザインしてくださる方募集します。
— AUDIY (@AUDIY14) November 3, 2025
報酬については私自身相場が判然としていない部分もあるので相談させていただければと思います。 https://t.co/avsRsjwSWT
引き続き報酬付きで募集していますので、「われこそは！」という方はぜひAUDIYにご連絡いただければと思います。
PDF & 紙書籍での販売について
需要があれば出そうと思っています。また、PDFや紙の書籍は有償での販売になる代わりにコラム等の「Zennでは見れない情報」も追加できればと思っています。
しかし、書籍化にあたり参考文献の記述などを見直す必要があるのも事実です。Word等のオフィスソフトを使うか、TeXで書くか、非常に悩ましいところです・・・
・・・まぁ需要に応じてゆっくりやりたいと思いますw
以上、「Questa-Altera FPGA Starter Editionで始めるRTL検証」（通称Questa本）の公開報告でした。
本書を通じて、本業・趣味に関わらず、読者のRTL設計検証の効率化に少しでも寄与できたのであれば幸いです。
さてさて、本格的にKR260と格闘しましょうかね。
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歳まであと数年ありますので、もう一回くらい若手発表枠で発表してみたいところです。
オーバーサンプリングデジタルフィルタモジュール"FIR_x2"をバージョンアップしました
どもです。
「モジュール内部の非同期設計をなくすべく進行中」と言っていたFIR_x2ですが、ついに作業が終了しました。
FIR_x2をv2.00として公開しました。
FIR_x2について
これまで以下のようにブログをまとめています。
PCM信号を2倍にオーバーサンプリングするFIRデジタルフィルタのVerilogモジュールです。
オーバーサンプリング比を2倍に固定することで、生成したFIRフィルタの係数を並び替えることなくオーバーサンプリングできることが特徴です。
縦続接続すればマスタークロック周波数に余裕がある限り2倍、4倍、8倍、・・・とオーバーサンプリング比率を高めていくことができます（その代わり、レイテンシは増えてしまいますが）。
変更内容
以下、公開当初からの変更点です
- データの取り込みや出力で非同期設計（立ち上がりで取り込み、たち下がりで出力）をなくしました
- カスタムFIRフィルタ係数の生成法について記載しました
FIR_x2（2倍オーバーサンプリングデジタルフィルター）の係数生成サンプルを作ってみた - 電子回路わからん日記 参照
- 非同期リセットに対応しました
- サンプルプロジェクトの非同期リセット周りのケアを見直しました（リセットシンクロナイザ挿入）
非同期設計をしていたがうえ、かなり多くのレジスタを消費していたようです。
2chのオーバーサンプリング（44.1kHz/48kHz→88.2kHz/96kHz）でブロックRAMを使って800LEs弱に収まりました。
動作確認済デバイス
以下ツイートのような感じで動作確認しました。
CMOD S7の動作確認も完了 pic.twitter.com/778cQYfZA3
— AUDIY (@AUDIY14) August 24, 2025
以下7デバイスにて動作確認済です。
- Altera Cyclone10 LP 10CL025YU256I7G
- Altera CycloneIV E EP4CE22F17C6N
- Altera MAX10 10M50DAF484C7G
- Efinix Trion T20F256I4
- AMD Artix-7 XC7A35T-1CPG236C
- AMD Spartan-7 XC7S25-1CSGA225C
- Gowin Arora GW2A-LV18PG256C8/I7
「このデバイスで動作確認してほしい！」みたいな要望があればお気軽にAUDIYのXアカウントにご相談いただければと思います。
個人的にはGowinのLittleBeeシリーズへの組み込みはやってみたいです。Tang Nano 9K買って組み込んでみますかね。
今後の展望について
FIR_x2の開発についてはここで一区切りとしたいと思っています。
この開発で学んだことを活かして、もう少し汎用性の高いFIRデジタルフィルタIPの実装に挑戦したいですね。
2倍オーバーサンプリングのみならず、単純なフィルタリングやデシメーションもパラメタライズで実装できるようなモジュールです。
GitHubで調べたところ、今のところそれに類するものはなさそうです。
fir-filter · GitHub Topics · GitHub
次の成果物が公開でき次第、現在のFIR_x2はアーカイブする予定です。
以上、FIR_x2の新バージョン公開報告でした。
人生で初めて本格的に開発したものかもしれません。いろいろとやることがあり、ペースを上げていくことは難しいですが今後も継続的に開発していければと思います。
ところでFPGA開発者のみなさん、以下イベントには参加しますか？
私は参加予定です。非常に楽しみですね。
ラズピコでPIOをパタパタしてみる~まずはLチカ~
どもです。
FPGAのみならずマイコンでもオーディオ信号処理やってみたいなと思い、Raspberry Pi Picoを触り始めています。
で、オーディオ信号のやり取りにご多分に漏れずI2Sを使うわけですが、Raspberry Piのマイコン（RP2040/RP2350）にはI2Sがペリフェラルとして存在せず、開発者がProgrammable IO（PIO）を使用してペリフェラルを構築する必要があります。
ということで、Raspberry Pi Pico (RP2040)を使ってPIOで遊んでみました。
Programmable IOとは
直訳すれば「プログラム可能なIO」となりますが、実態はRP2040/RP2350のCPUコアとは分離されたステートマシンとFIFOなどから構成されるIO制御専用のハードウェアです。
一つのPIOブロックあたりに4つのステートマシン、4ペアの送受信用FIFO、命令メモリと割り込みから構成されます。
ステートマシンは2つのスクラッチレジスタ、入力用/出力用シフトレジスタ、プログラムカウンタ、分周器、命令制御ロジックで構成されます。ふむふむ。
CPUを介さずにステートマシンにメモリ（レジスタ）とI/Oのやり取りを任せるというのは、DMAに似たサムシングを感じますね。
PIOのプログラム
で、ここからPIOならではの難しさというか奥深さに触れていくことになるのですが、なんとPIO自体のプログラムは最大32命令のアセンブリ言語（C/C++で開発する場合）になります。
最大32命令で各種インターフェイスを実装する必要があるということです。
ただし、ここに繰り返し実行される命令はカウントされないので、この「繰り返し」を使って上手に命令をまとめる必要がありそうです。
とりあえずLチカさせてみる
なんかよくわからん部分も多いのでとりあえずサンプルコードをいじってPIOでLチカしてみます。
今回はVScode上にRaspberry Pi Pico開発プラグインが構築されている前提で進めます。
「New C/C++ Project」を選択し、
今回はプロジェクト名を「pio_led」としました。
Features一覧から「PIO interface」を選択します。
stdio supportはRaspberry Pi Pico単体でも見ることができるように「Console over USB」にしておきます。
なんと、LEDを点滅させるサンプルプログラムが記述された状態でコード一式が出力されます。初心者には大変助かります。
とりあえず実行してみます。
とりあえずPIOでLチカ（デフォでサンプルプログラムが出力されたのでそのまま動かしただけ） pic.twitter.com/lVnqZJhfJx
— AUDIY (@AUDIY14) July 27, 2025
まぁ問題なく動きますね。
アセンブリ言語の本体を見てみましょう。
以下サイトの内容と照らし合わせながら読んでいくと次のようになります。
- TX FIFO上の32bitデータを出力シフトレジスタに格納
- スクラッチレジスタYに出力シフトレジスタ上の32bitのデータを格納
- スクラッチレジスタXにスクラッチレジスタYの値を代入
- 設定したGPIO（今回はLEDにつながるGPIO25）の論理を1に設定
- （ここからlp1）スクラッチレジスタXの値を1減らし、スクラッチレジスタの値が0でなければlp1冒頭に移動
- スクラッチレジスタXの値が0になったら再びスクラッチレジスタXにスクラッチレジスタYの値を代入
- 設定したGPIO（今回はLEDにつながるGPIO25）の論理を1に設定（lp1ここまで）
- （ここからlp2）スクラッチレジスタXの値を1減らし、スクラッチレジスタの値が0でなければlp2冒頭に移動
- スクラッチレジスタXの値が0になったら3番に戻る
フローチャートにするとこんな感じではないでしょうか（noとYesが逆です）。
これを1命令あたり最速1クロックサイクルで実行するというから非常に高速です。もちろん、ステートマシン内部の分周器や各命令に遅延命令を付加することで実行速度を調整できます。
Cプログラムを覗く
さて、アセンブリ言語でプログラムされたPIOはC言語からどのように制御されているか見てみます。
Cプログラムの中でblink_pin_forever関数が呼び出されています。
関数の定義を追っていきます。pio_sm_set_enabled()関数はC/C++ SDK上で定義されているので何も考えないこととし、blink_program_init()関数の定義を追ってみると・・・
blink.pio.hというヘッダファイル内に定義があります。
これですが、定義そのものは自分で書く必要がありそうです。
実はアセンブリ言語の下部に同じ定義が記述されています。おそらくはこれをもとにヘッダファイルが生成されるのだと思います。
このあたりは1からやってみないことにはわからないですね
いちから書いてみる
「見様見真似でいちから書いてみます」ということで書いてみようとしましたが、VScodeのRaspberry Pi Pico開発環境に慣れていないこともあり、非常に時間がかかりそうなので今回はここまでとします。
まずはPIOを使って任意周波数の矩形波を出力できるようにしたいですね。
FIR_x2（2倍オーバーサンプリングデジタルフィルター）の係数生成サンプルを作ってみた
どもです。
およそ1年半前に公開したFIR_x2ですが、処理の非同期設計を極力なくす作業を実行中です。
その中で「公開したのは良いけど、これ自分の設計したFIRフィルタの組み込み方法書いてないな」ということに気づいたので、FIR_x2に組み込む形式のFIRフィルタ係数データを生成するサンプルプログラムを追加しました。
このブログではその使用方法について簡単に記したいと思います。
生成AIすげぇな
ここに書く内容の英語版は、GitHub上にまとめてあります。
英語が大の苦手なAUDIYなので、作ったサンプルプログラムを添付した状態でファイルの生成手順を箇条書きにして送信したら、この文章が出てきました。
少しばかり単語に修正は加えましたが、2~3語ほどの修正のみでした。今後も活用していきたいです。
生成手順
大まかな生成手順は以下4ステップです。サンプルプロジェクトもアップロードしていますが、条件を満たせば他のツールを使っても問題ないと思います。
浮動小数のフィルタを生成
浮動小数のFIRフィルタを生成します。PythonやMATLAB、Octaveなどを使うと作りやすいと思います。
ここでのタップ数は奇数にしておくことをオススメします。偶数を入れるとインパルス応答のピークが出ません。
フィルタ係数の量子化
浮動小数のフィルタを任意のビット数の整数（固定小数）に量子化します。単純に四捨五入すると係数の総和がオーバーフローすることがあるので、基本的には床関数を使うのが良いと思います。床関数を使うにも少々コツがいります。このあたりはまた機会があれば説明することにします。
先頭データの0埋め
基本的に係数の個数は2のべき乗になりますが、タップ数は奇数に指定しましたので、格納する個数に対し実際のフィルタ係数が1つ足りない状態になります。
ここは先頭に0を挿入して、個数を揃えます。
ここまでの内容を実行するPythonサンプルスクリプトをGitHubにアップしていますので、参考になれば幸いです。
スクリプトでは上記の操作の他にオーバーフロー確認や係数データのテキストファイルへの保存、インパルス応答のプロットを行っています。
符号付き16進数への変換
保存された係数は符号付きの10進数の整数なので、これをVerilogの$readmembや$readmemhで読み込みできるように16進数または2進数に変換します。
また、符号付き整数の表現を2の補数にする必要があります。
Pythonでそのまま実行できればよかったのですが、筆者のスキルではその方法を見つけるに至らず、今回はawkのサンプルスクリプトを用意することにしました。
冒頭にコメントアウトでコマンド例も記載してありますので、これで16進数の係数を出力します。
C言語等で同様の処理を実現するプログラムを作ってもよいでしょう。
また、出力するファイルの拡張子は".data"をオススメします。FIR_x2のリポジトリ上では".hex"で保存していますが、".data"にしておけばVivadoでもすんなりとプロジェクトに追加・使用することができます。
あとは係数ファイルを必要な場所に保存して、FIR_x2のパラメータを変更して動作を確認してください。
ということで、FIR_x2向けのフィルタ係数生成手順を示しました。
コレで自分の好きなFIRフィルタを自由に使うことができますね！
新卒入社して5年が経ったらしいので改めて感想を
どもです。
表題の通り、現職に新卒入社して5年が経ったそうです。
恐ろしや、恐ろしや・・・・・
もう2年経ったのか
あれからもう2年経ったんですね
これまでの2年（4年目 & 5年目）を振り返る前に、転職を考えていた上記の記事を見ていただけるとこの内容も少しはわかりやすくなるかと思いますので、ぜひ読んでいただけると嬉しいです。
それでは早速始めていきましょー。w
4年目開始早々組織再編
さて、転職するかどうかを常に頭の片隅に考えつつ、4年目にさしかかるあたりで組織再編になります。
あまり細かい内容は言えませんが、別部署の電気設計部隊と合流する形です。
とはいえ業務内容も担当分野も大きく変化することはなく、4年目の業務は進行します。
担当の設計を通じて
さて、4年目の設計は入社3年記事で容赦ない発言をした上司と設計することになります（詳しくは上記記事を読んでください）。
上司、「影分身してるんですか？」と聞きたくなるくらいには仕事が早く、
- 異なるテーマの協議内容に対する返答メールが数分おきに返ってくる
- 回路検証も気がついたら終えている
- さらに基板設計も進めてしまう
- なんか別案件の問題対応も進めている
というのを並行して進めていました。
そして一部業務が私のところで停滞するという私の無能さがより鮮明にでてくる環境でしたｗ
ただ、その意思決定の早さ、正確さには非常に助けられる場面も多く
- 「こうしようと思うんですが・・・」と自信のない提案でも正しければ「よしそれでいこう！」と即決してくれて余計な時間を割かない。
- 他の上司から降りてくる重大な事項に対しても自分がハンドルするのに困る場合は先んじて返答する（自身の成長のためには本来コレでは良くないんですけどね・・・）
- これらによって回路設計や検証に業務の比重を割くことができる
ということで、非常に助けられることが多かったです。
とはいえ設計リーダーというものは・・・
実はこの案件は設計リーダーというものをやってみたのですが、上記によりだいぶ負担がなくなっていたとはいえど「できればやりたくない」担当ではあります。
というのも
- 関係部署との交渉ごとが多く回路設計等を他メンバーに割り振らないといけないことが多い
- 「設計リーダーでしょ？何やってるの？」「設計リーダーなのにどうして〇〇しないの？」など、暗黙の了解で設計リーダーがやってきた仕事がされないと他部署のマネージャーが不満を爆発させてくる
- とりあえず会議・資料作成が増える。設計業務を遂行できている感覚が皆無
と、回路や技術に満足に触れられない状況に入ります。
サンドバッグ状態になるので、鋼のメンタルと鋼の体力の持ち主でもない限り身体か心のどちらかを壊します。
というか他部署のマネージャーが自部署のマネージャーを通さずに設計リーダーというサンドバッグに苦情を直接出してくるって正直「なんでもアリ」状態ですよね。設計リーダーが最低限やるべき仕事を明文化するか、事前にマネージャーを通す体制にしてほしいものです。
見違えるほど円滑に進む
とまぁ、こまごました不満はありつつも上記の上司や周辺のつよつよなエンジニアのおかげで、某初担当炎上案件が夢だったかのごとく円滑に進みます。
・・・毎回コレだったら良いのに。w
コロナ禍に伴う部品の置き換え等で設計に2年半を費やした炎上案件に対し、4年目の担当案件は1年で済みました。しかも部品も好きなように選べましたから完成度も高い。
マジでコロナ許さねぇ。w
FPGA設計のヘルプ
とまぁ2つめの案件が落ち着いたのもつかの間、別部署からヘルプ要請が。
「電源投入して時間が経つと通信に失敗する・復帰しない」ということで、FPGA設計エンジニアからしたら「いやなニオイがする」現象です。
まぁ追っていくと出るわ出るわ、安易な非同期設計、どうなっているかもはや追えないタイミング制約、めちゃくちゃ高いロジック使用率、とコンプリート！
不要なロジックを削ったりタイミング制約を見直したり、そこから実機検証したりとなんだかんだで2~3ヶ月間はこのヘルプにあたっていました。
こういうのはたいてい原因と対策をまとめてエンジニアに水平展開するんですが、あんまり重たい内容だったりすると勉強会をすることになります。
FPGAの勉強会、どこから話しますかね（遠い目）
5年目も半年
そして気づいたら5年目が始まっていたわけですが、そんな5年目も途中でまた組織再編になります。
この5年で3度目の組織再編。「各案件部門ではなく担当分野ごとに一つの部署にまとめる」とのことで、コレはコレで分野特定の業務はハンドリングしやすくなりましたが、まったくやったことのない案件やることになったらどうしましょう・・・？という状況です。
あと組織再編多すぎませんかね・・・？
とはいえ国内企業、組織再編のみならず2~3年おきに別部署へ移動、なんて企業もたくさん聞きますから、そんなことなく入社してから一貫した分野に携われている自分はエンジニアとしては幸運な方なんだと思います。
次の技術者像は・・・？
5年経った今でも「昨日入社した」感が鮮明に残る（←それでは困る）AUDIYですが、6年目以降はもう少し「実験する」エンジニアになりたいと思っているところです。
継続や完成よりも大事。 pic.twitter.com/qrpfIWX9wO
— 木賃ふくよし(芸名) @ 寿烏丸るみの中身 (@wb_opus_1) March 31, 2025
例えば「このデバイスのこのレジスタ、書き換えると挙動がどう変化するのか想像つかないなー」となったときに、実機検証に入るまで「とりあえずデフォルトで！」みたいなことも多かったです。
ただしこの方法だと実機検証時のデバッグに時間を費やしたりすることも多かったりするので「その場でちゃちゃっと実験する」ことであとあとの実機検証を楽にしたいな～と感じることが増えてきました。
そういう意味で、「検討↔実験」のサイクルを回せるエンジニアになることが次のステップアップの一歩かな、と思っているところです。
そういう意味でいえばFPGAは評価ボード等で実験に移行しやすい環境にはあったりするんですが、特定用途のデバイスだと純正評価ボードはクソ高いし、自分で評価ボード起こすにも数週間~数ヶ月かかるしで、どうするかは考えどころです・・・
転職は・・・？
気になってる企業はいくつかあるのですが
- 総合的に見て現状には概ね不満がない
- 正直自分の現在のスキルで転職できる気もしない
- 転職できても待遇が改善するかビミョー
ということで、3年経ったときほどは転職を考えていません。
ただ身の回りをみていると
- 入社3年以上経ってから休職した人
- 入社2年経たずに転職した人
- 入社1年目から精神病んだ人
といろんな人がいますので、「AUDIYがたまたま5年残れた」だけであり「石の上にも3年」などとは微塵も思っていません。
無理した結果身体やメンタルを壊したらなかなか戻らない（特にメンタル）ですから、少しでも無理と思ったら即動くべきだとは思います。
私もまたメンタルやられたら考え直すことにします・・・
後輩は増えるが・・・
ここ2年は特に大卒・大学院卒の新入社員が多く、職場も全体的に若返りが図られています。
ただし、へーしゃでは分野ごとに偏りが大きく
- 圧倒的にソフトウェア設計が大多数
- 回路設計はこの2年間でゼロ
- あとは他部署が少数
自分が所属している回路設計に絞って言えばだいぶ芳しくない状況ですねコレ。
さすがに人事部も全体の状況を把握してて採用しているとは思うのですが、ソフトウェア設計が圧倒的に足りていないのか、回路設計希望が圧倒的に少ないのか、個人的には気になります。
以上、新卒入社5年までのまとめでした。
入社3年経ったときと比べて内容はそこまで濃くなかったかもしれませんが、少しずつ「職場環境も良くなってきている」ということなのだと思います。
これまでの5年をまとめるとするなら
- 怖い上司は強い
- 組織再編多いな
- FPGA勉強会どうしよう
- 相変わらずソフトウェア設計の新卒が多い
- 転職のタイミングは人それぞれ
- もっとこまめに手を動かすエンジニアになりたい
といったところです。
とりあえずは「5年」という節目で改めて書いてみましたが、次書くとしたら10年ですかね？その間に転職・リストラなどに巻き込まれていたらそれはそれで面白い記事が書けそうです。
