VLSI KoreaUVMから始めないでください：デジタル検証職を目指すためのロードマップ
UVMの文法より、RTLとプロトコルの理解が先です。デジタル検証職を目指す人のために、実践的な6週間の学習順序とポートフォリオの基準を解説します。
最近、身近な半導体業界への就職を目指す人や若手エンジニアから、繰り返し耳にする悩みがあります。「デジタル検証職を目指すなら、まずUVMを学ぶべきですか？」特定の個人の話ではなく、実名・学校・会社に関する情報をすべて除き、共通する悩みだけを一般化して答えます。
一言で答えると： UVMから始めないでください。RTLの理解 → self-checking testbench → AXIなどのプロトコル → assertion・coverage → UVMの順がはるかに速いです。
UVMは重要です。しかしUVMは検証の基礎というより、すでに理解している検証要素を再利用可能な構造に整理するフレームワークに近いものです。DUTがどのサイクルでどの値を出すべきか説明できないまま、factoryやsequenceの文法から暗記すると、構造はもっともらしくてもバグを見つけられないテストベンチになりがちです。
検証組織が実際にどのような仕事をしているかを先に知りたい場合は、Design Verificationチームガイドもあわせてお読みください。本稿では、その次の段階である「何をどの順序で準備するか」に焦点を当てます。
UVMより先にRTLを学ぶべき理由
検証エンジニアは設計コードを代わりに書く人ではありません。しかし、バグが生じ得る状態空間を想像するには、RTLの時間軸を読み取れなければなりません。
- 組み合わせ論理と順序論理の境界はどこか
- reset直後にすべての状態が定義されているか
validが立った後にreadyが遅れた場合、データは保持されるか- パラメータやデータ幅が変わったときに比較式が破綻しないか
- 同時に届いた要求の優先順位とstarvationの条件は何か
これらの問いに答えられてこそ、stimulusとcheckerを設計できます。UVM classを数多く知っていることと、検証対象を理解していることは別の能力です。
現役エンジニアが勧める6週間の学習順序
1週目：小規模なRTLブロックを自分で設計する
カウンターより一段複雑なブロックを選んでください。FIFO、round-robin arbiter、register file、簡単なinterrupt controllerなどが適しています。コードを書く前に、まず要件表とタイミング図を作成してください。
ポートフォリオの出発点は「動作するRTL」ではなく、「何が正しい動作なのかを説明できる仕様」です。
2週目：波形確認をself-checking testに変える
波形を目視して正しいと判断するテストは、反復実行や回帰検証が困難です。少なくとも次の要素を分離してください。
- 入力を生成するstimulus
- DUTのピンを駆動するdriver
- 出力を収集するmonitor
- 期待値を生成するreference model
- 実測値と期待値を比較するscoreboard
シミュレーションの終了時には、人が波形を開かなくてもpass/failと失敗原因が分かるようにします。
3週目：AXI4-Liteの一部分を正しく理解する
最初からAXI4全体を暗記しないでください。AXI4-Lite slaveを1つ設計して検証しながら、まず独立チャネルとbackpressureを理解するほうが効果的です。
VALIDは相手のREADYを待ってから立てる信号ではありません。- アドレスチャネルとデータチャネルが常に同じ順序で到着すると仮定してはいけません。
- 応答が遅延したときに次の要求を受け付けられるか、仕様を明確にする必要があります。
- reset、連続転送、backpressure、不正アドレスを個別にテストする必要があります。
AMDは、VivadoにSystemVerilogベースのAXI Verification IPを追加料金なしで含めていると説明しています。サンプルテストベンチとprotocol checkerを利用すれば、自作テストで見落とした規則を確認するのに役立ちます。
4週目：assertionとfunctional coverageを追加する
優れたassertionは実装コードを書き直すものではありません。インターフェースが守るべき契約を表現します。例えば、valid && !readyの間はpayloadが安定していなければならないという規則や、FIFOがfullのときはwrite pointerが動いてはならないという規則が該当します。
coverageも数値から見ないでください。まず検証計画を作成してください。
| Function | Normal conditions | Boundary/error conditions | Verification method |
|---|---|---|---|
| AXI write | Single/continuous writes | backpressure, invalid address | scoreboard + assertion |
| AXI read | Single/continuous reads | Response delay, unmapped address | reference model |
| reset | reset while idle | reset during transaction | directed test + assertion |
5週目：SystemVerilog classでリファクタリングする
次に、transaction、generator、driver、monitor、scoreboardをclassに分離してください。interface、virtual interface、mailboxがなぜ必要なのかを、「すでに直面した問題」と結び付けて理解できます。
6週目：最後にUVMへ移行する
これまでに作った要素をUVM構造にマッピングします。
- transaction →
uvm_sequence_item - generator → sequence / sequencer
- driver →
uvm_driver - monitor →
uvm_monitor - scoreboard →
uvm_scoreboard - 接続と設定 → agent / env / config DB
この順序で進めれば、phaseとfactoryは暗記項目ではなく、再利用とconfigurationの問題に対する答えとして理解できます。
就職ポートフォリオで面接官が確認したいこと
リポジトリのトップ画面で、次の5項目が見えるようにしてください。
- ブロック仕様とタイミング図
- 要件とテストを結び付けた検証計画
- 1つのコマンドで実行できるregressionとpass/failログ
- assertionとfunctional coverageの結果
- 実際に発見したバグの再現・原因・修正・再発防止の記録
面接で強い言葉は「UVMを勉強しました」ではありません。「アドレスチャネルとデータチャネルの順序を固定して仮定していたバグをrandom delayとassertionで見つけ、regressionに再発防止テストを追加しました」という説明に近いものです。
よくある質問
Q. 学部生もUVMに取り組むべきですか？
取り組む価値はありますが、完成度の低いUVMプロジェクトを1件作るより、小規模なRTLを仕様からcoverageまで完遂したプロジェクトのほうが強みになります。UVMは最後のリファクタリング段階で導入してください。
Q. C++やPythonを先に学ぶべきですか？
言語そのものより、DUTとprotocolの理解が先です。Python・cocotbは迅速な実験とreference modelに有用で、C++はDPIや性能モデリングで強みがあります。しかし、RTLのcycle-level動作を理解していなければ、どの言語を使ってもcheckerの品質は向上しません。
Q. コードカバレッジが100%なら検証は完了ですか？
いいえ。コードカバレッジは実行された構造を示すだけで、要件が正しいことを保証しません。functional coverage、assertion、scoreboardの結果とあわせて確認する必要があります。
Q. プロジェクトはいくつが適切ですか？
浅いプロジェクトを複数作るより、1つのプロジェクトを仕様・検証計画・自動化・バグ記録まで完結させるほうが効果的です。時間があれば、同じ構造を別のprotocolやUVMへ拡張してください。
まとめ
UVMが到達点であることは確かです。ただし、出発点ではありません。RTLの時間軸を読み、protocolの契約を理解し、期待値を自動比較する習慣が先です。その上にUVMを構築してこそ、フレームワークが実力を覆い隠さず、実力を拡張します。
公開情報源
- Accellera UVM Community
- Accellera UVM standard downloads
- AMD AXI Verification IP
- AMD Vivado Verification
編集方針：本稿は、身近で繰り返し耳にした匿名の悩みを一般化して執筆しました。個人・学校・会社・事例を特定できる情報は使用していません。
