はじめに
趣味でSystemVerilogシミュレータ「sukimasim」を開発しています。sukimasimはIEEE 1800-2023準拠を目指したC++20製のシミュレータで、現在 Ibex がシンプルなDV（Design Verification）環境では動作するレベルになっています。
次の目標として、Ibex UVM DV環境での動作を目指しています。Ibexはlowrisc.orgが開発するオープンソースの32bit RISC-Vプロセッサコア（2ステージ・インオーダー、RV32IMC対応）で、GoogleのOpenTitanプロジェクトのRoot of Trustにも採用されています。そのDV環境は、SystemVerilog/UVMベースの本格的な検証テストベンチです。
Ibex UVM DV環境の構成を簡単に紹介すると、以下のようになっています。
- RISCV-DV（Google開発）によるランダム命令生成 → コンパイル → バイナリ生成
- メモリインターフェースエージェント（命令フェッチ用 / LSU用の2つ）がスレーブシーケンスでコアのメモリリクエストに応答
- 割り込みエージェントがテスト中にランダムな割り込み刺激を投入
- コアの実行トレースとISSゴールデンモデル（Spike）のトレースを比較して正当性を検証
- OpenTitanのVerification Stagesに基づいて検証成熟度を管理（V2S達成済み：コード/機能カバレッジ90%超）
このテストベンチはUVMのフェーズ機構をフル活用しており、run phaseでの各種シーケンス実行、objectionによるテスト終了制御、タイムアウト管理などが不可欠です。sukimasimでこの環境を動かすためには、シミュレータ側でrun phaseを正しく実装する必要があり、その過程で得た知見を本記事にまとめました。
本記事では、UVMのrun phaseについて通常のユーザー視点に加え、シミュレータ実装側の視点も交えて解説してみます。
UVMフェーズの全体像
UVMのテストベンチは、フェーズと呼ばれる一連のステップに従って実行されます。大きく3つのグループに分かれます。
| グループ | フェーズ | 時間消費 | 実行方向 |
|---|---|---|---|
| Build-time |
build → connect → end_of_elaboration → start_of_simulation
|
なし | function |
| Run-time |
run（+ 12個のsub-phase） |
あり | task |
| Post-run |
extract → check → report → final
|
なし | function |
Build-timeフェーズでテストベンチの構築と接続を行い、run-timeフェーズでシミュレーションを実行し、post-runフェーズで結果の確認とレポートを行う、という流れです。
フェーズの実行方向
functionベースのフェーズには実行方向があり、これは意外と見落とされがちなポイントという気がします。
| フェーズ | 実行方向 | 基底クラス |
|---|---|---|
build_phase |
トップダウン | uvm_topdown_phase |
connect_phase |
ボトムアップ | uvm_bottomup_phase |
end_of_elaboration_phase |
ボトムアップ | uvm_bottomup_phase |
start_of_simulation_phase |
ボトムアップ | uvm_bottomup_phase |
extract_phase |
ボトムアップ | uvm_bottomup_phase |
check_phase |
ボトムアップ | uvm_bottomup_phase |
report_phase |
ボトムアップ | uvm_bottomup_phase |
final_phase |
トップダウン | uvm_topdown_phase |
build_phaseがトップダウンなのは、親コンポーネントが子コンポーネントを生成（create）する必要があるため、論理的に必然です。
注目すべきは final_phaseもトップダウン である点です。UVM全体でトップダウンのフェーズはbuild_phaseとfinal_phaseの2つだけであり、他はすべてボトムアップまたは並行実行（taskフェーズ）です。final_phaseがトップダウンである理由は、親が先にリソース解放やファイルクローズの最終処理を行い、子がそれに続く、という順序が自然だからです。
run_phase（およびサブフェーズ）はtaskベースであり、各コンポーネントのtaskが fork-join_none で同時起動されるため、トップダウン/ボトムアップの概念はありません。
run_phaseの基本
taskベースのフェーズ
run phaseの最大の特徴は、他のフェーズと異なり taskとして定義される 点です。UVMソースコードでは uvm_run_phase extends uvm_task_phase と定義されています。
// build_phaseはfunction（時間消費なし）
function void build_phase(uvm_phase phase);
// ...
endfunction
// run_phaseはtask（時間消費あり）
task run_phase(uvm_phase phase);
// クロック待ち、ドライブ、モニタなど時間消費する処理が書ける
@(posedge clk);
// ...
endtask
functionフェーズは呼び出し元に即座に戻りますが、run_phaseはtaskなので #delay、@event、wait などの時間消費文を含むことができます。シミュレータ側から見ると、これはrun_phaseの本体をプロセス（スレッド）としてスケジューリングする必要があることを意味します。
重要な点として、UVM 1.2リファレンスには「The completion of the task does not imply, nor is it required for, the end of phase（taskの完了はフェーズの終了を意味しないし、必須でもない）」と記載されています。つまり、run_phaseのtask自体がreturnしても、他のコンポーネントがobjectionを保持していればフェーズは終了しません。
objectionメカニズム
run_phaseの終了は、objection（異議）メカニズムによって制御されます。
task run_phase(uvm_phase phase);
phase.raise_objection(this, "Start test"); // 「まだ終わらないで」
// テストシーケンスの実行
seq.start(sequencer);
phase.drop_objection(this, "End test"); // 「終わってOK」
endtask
すべてのコンポーネントがobjectionをdropした時点で、run_phaseが終了します。どのコンポーネントもobjectionをraiseしなかった場合、run_phaseは即座に終了します。 これはUVM初心者が最も陥りやすい落とし穴の一つです。
objectionの内部構造
シミュレータ実装の観点から、uvm_objectionクラスの内部構造を見てみましょう。UVMリファレンス実装では以下の連想配列で管理されています。
-
m_source_count[uvm_object]：そのオブジェクト自身が発行したobjection数 -
m_total_count[uvm_object]：そのオブジェクトと全子孫の合計objection数 -
m_drain_time[uvm_object]：オブジェクトごとのdrain time
objectionのraise/dropは階層的に伝播します。子コンポーネントがraise_objectionすると、そのコンポーネントのm_source_countとm_total_countが+1され、さらに親→祖親→uvm_topまでm_total_countのみが+1されます。uvm_topのm_total_countが0になった時点で、フェーズ終了処理が開始されます。
child.raise_objection()
→ child: m_source_count=1, m_total_count=1
→ parent: m_total_count=1 (伝播)
→ uvm_top: m_total_count=1 (伝播)
child.drop_objection()
→ child: m_source_count=0, m_total_count=0
→ parent: m_total_count=0 (伝播)
→ uvm_top: m_total_count=0 (伝播) → フェーズ終了処理開始
drain_time
drain_timeのデフォルト値は0nsです。全objectionがdropされた後に追加の待機時間を挿入したい場合、set_drain_time()で設定します。
task run_phase(uvm_phase phase);
// drain_timeを設定（UVM 1.2推奨の書き方）
phase.phase_done.set_drain_time(this, 100ns);
phase.raise_objection(this);
seq.start(sequencer);
phase.drop_objection(this);
// → drop後、100ns待ってからフェーズ終了
endtask
drain_time中に新たなobjectionがraiseされると、drain処理はキャンセルされ、通常のraise処理が再開されます。この「キャンセル可能なタイマー」の実装は、シミュレータ側でも考慮が必要です。
raise(A) → raise(B) → drop(A) → drop(B) → [drain_time 100ns] → フェーズ終了
count=1 count=2 count=1 count=0 ↑ この間にraiseされたらキャンセル
run_phaseの12個のsub-phase
sub-phaseとは
UVM 1.1以降、run_phaseには12個のsub-phase（サブフェーズ）が定義されています。
run_phase（全体を包含）
│
├── pre_reset_phase
├── reset_phase
├── post_reset_phase
├── pre_configure_phase
├── configure_phase
├── post_configure_phase
├── pre_main_phase
├── main_phase
├── post_main_phase
├── pre_shutdown_phase
├── shutdown_phase
└── post_shutdown_phase
各サブフェーズの意図する役割は以下のとおりです。
| サブフェーズ群 | 役割 |
|---|---|
pre_reset / reset / post_reset
|
リセット投入・解除・安定化 |
pre_configure / configure / post_configure
|
レジスタ設定・SW初期化 |
pre_main / main / post_main
|
メインのテストトラフィック実行 |
pre_shutdown / shutdown / post_shutdown
|
残留トランザクション処理・終了処理 |
run_phaseとsub-phaseの関係 ― Phase Domain
ここが少しややこしいポイントです。run_phaseと12個のsub-phaseは 並行して実行 されます。UVM 1.2リファレンスにも以下のように明記されています。
This uvm_task_phase calls the uvm_component::run_phase virtual method. This phase runs in parallel to the runtime phases, uvm_pre_reset_phase through uvm_post_shutdown_phase.
この並行実行のメカニズムはPhase Domain（フェーズドメイン） によって実現されています。
-
run_phase→ Common Domain に所属 - 12個のサブフェーズ → UVM Domain に所属
2つのドメインは以下のように同期します。
start_of_simulation_phase 終了
│
┌─────┴──────────────────┐
│ │
▼ ▼
run_phase pre_reset_phase
(Common Domain) │
│ reset_phase
│ │
│ post_reset_phase
│ │
│ ... (順次実行) ...
│ │
│ post_shutdown_phase
│ (UVM Domain)
└─────┬──────────────────┘
│ ← 両方の完了を待つ
▼
extract_phase
実務上の重要な含意として、run_phaseにobjectionをraiseしているコンポーネントがある限り、たとえ全サブフェーズが終了していてもextract_phaseには進みません（逆も同様）。両方のドメインが完了して初めてpost-runフェーズに遷移します。
sub-phaseの使いどころ
実務では、sub-phaseを細かく使い分けるプロジェクトと、run_phaseだけで済ませるプロジェクトに分かれます。
sub-phaseを使う例：
task reset_phase(uvm_phase phase);
phase.raise_objection(this);
// リセットシーケンスを実行
vif.rst_n <= 1'b0;
#100ns;
vif.rst_n <= 1'b1;
#10ns;
phase.drop_objection(this);
endtask
task main_phase(uvm_phase phase);
phase.raise_objection(this);
// メインのテストシーケンスを実行
seq.start(sequencer);
phase.drop_objection(this);
endtask
task shutdown_phase(uvm_phase phase);
phase.raise_objection(this);
// 残留トランザクションの完了を待つ
wait(scoreboard.pending_count == 0);
phase.drop_objection(this);
endtask
sub-phaseを使うメリットは、検証フローの各段階が明確に分離される点です。特にリセットシーケンスが複雑な設計や、複数のエージェントが協調して動作する環境で有用です。
一方、多くのプロジェクトでは run_phase 内でシーケンスを直列に記述するだけで十分なため、sub-phaseの実装は省略されることも多いです。DVConの論文 "Run-Time Phasing in UVM: Ready for the Big Time or Dead in the Water?" でも、サブフェーズの実用性については賛否が議論されています。
phase_ready_to_end ― フェーズ終了前の最後の介入点
phase_ready_to_end(uvm_phase phase) は uvm_component の仮想関数コールバックで、全objectionがdropされた直後、フェーズが実際に終了する前に呼ばれます。
function void phase_ready_to_end(uvm_phase phase);
if (phase.get_name() == "run") begin
// スコアボードにまだ未比較のトランザクションが残っていたらフェーズを延長
if (scoreboard.pending_count > 0) begin
phase.raise_objection(this, "Waiting for scoreboard drain");
fork begin
wait(scoreboard.pending_count == 0);
phase.drop_objection(this, "Scoreboard drained");
end join_none
end
end
endfunction
この仕組みにより、「テストシーケンスは終わったが、パイプラインにまだデータが残っている」という状況でフェーズを安全に延長できます。
注意点として、phase_ready_to_end内でobjectionをraise→dropすると、再びphase_ready_to_endが呼ばれます。このイテレーションは最大20回（max_ready_to_end_iterで変更可能）に制限されており、超過すると強制終了されます。
UVM 1.2でのシーケンス実行パターンの変更
starting_phaseのprotected化
UVM 1.1以前では、シーケンスのstarting_phaseメンバに直接アクセスしてobjectionを操作していました。
// UVM 1.1スタイル（非推奨）
task body();
starting_phase.raise_objection(this);
// ...
starting_phase.drop_objection(this);
endtask
UVM 1.2ではこのメンバがprotected化され、get_starting_phase() / set_starting_phase() でアクセスする方式に変更されています。
set_automatic_phase_objection
UVM 1.2で追加された便利な機能として、set_automatic_phase_objection(1) があります。
class my_sequence extends uvm_sequence #(my_item);
function new(string name = "my_sequence");
super.new(name);
set_automatic_phase_objection(1); // 自動objection有効化
endfunction
task body();
// raise/dropを手動で書く必要がない
// start()時に自動raise、body()完了時に自動drop
`uvm_do(req)
endtask
endclass
ただし、body()にforeverループがある場合、taskが永遠に完了しないためobjectionがdropされません。この場合は手動でのobjection管理が必要です。
シミュレータ実装側から見たrun_phase
sukimasimの開発で実際に対応が必要だった（あるいは今後必要になる）項目を整理します。Ibex UVM DV環境では、run_phase内でRISCV-DVが生成したバイナリのロード、メモリインターフェースエージェントのスレーブシーケンス実行、割り込みエージェントによるランダム刺激の投入、テストタイムアウトの監視などが行われるため、以下の各項目はすべて実践的に重要です。
1. プロセスとしてのフェーズ実行
run_phaseはtaskなので、各コンポーネントのrun_phaseをそれぞれ独立したプロセスとして起動する必要があります。すべてのコンポーネントのrun_phaseが fork-join_none 的に同時起動され、objectionベースで終了が管理されます。
コンポーネントA.run_phase ──fork──→ プロセスA
コンポーネントB.run_phase ──fork──→ プロセスB
コンポーネントC.run_phase ──fork──→ プロセスC
│
全objection drop
│
phase_ready_to_end (各コンポーネント)
│
drain_time 経過
│
phase_ended (各コンポーネント)
│
全プロセスkill → フェーズ終了
2. phase.raise/drop_objectionのDPI経由の実装
UVMはSystemVerilogのクラスライブラリですが、シミュレータはobjectionカウンタの状態を把握してフェーズ遷移を制御する必要があります。純粋にSystemVerilog側で完結する実装と、シミュレータカーネルと連携する実装の両方が考えられます。
3. timeout機構
UVMにはrun_phaseのタイムアウト機構があります。デフォルト値はUVM_DEFAULT_TIMEOUTマクロで定義されており、UVM 1.2ソースコード（src/macros/uvm_global_defines.svh）では 9200秒（= 9.2 × 10¹² ns）に設定されています。
// ソースコードでの定義
`define UVM_DEFAULT_TIMEOUT 9200s
タイムアウトに到達すると UVM_FATAL（タグ[PH_TIMEOUT]）が発行され、シミュレーションが即座に終了します。変更方法は3つあり、優先度順に以下のとおりです。
// 方法1: コマンドラインplusarg（最優先）
// +UVM_TIMEOUT=200000,NO
// 第2引数: YES=以降の上書き可 / NO=以降の上書き不可
// 方法2: 実行時に設定
uvm_top.set_timeout(1ms, 0); // 第2引数0で以降の上書きを禁止
// 方法3: コンパイル時にマクロを上書き
// +define+UVM_DEFAULT_TIMEOUT=500us
4. phase jumpへの対応
UVMはフェーズの「ジャンプ」をサポートしています。phase jumpはハードジャンプのみであり、ソフトジャンプ（ネゴシエーション型）は実装されていません。
task main_phase(uvm_phase phase);
phase.raise_objection(this);
fork
begin: main_traffic
main_seq.start(agent.sequencer);
end
begin: reset_watch
// 動作中のリセットを検出
@(negedge vif.rstn);
phase.jump(uvm_pre_reset_phase::get());
end
join_any
phase.drop_objection(this);
endtask
phase jump時の内部動作は以下のとおりです。
-
set_jump_phase(phase)でターゲットフェーズを指定 -
end_prematurely()で現在のフェーズを即座に終了 - 実行中の全プロセスとシーケンスが即座にkillされる
- objectionカウントは自動的に0にリセットされる
-
phase_ready_to_endは呼ばれない -
phase_endedは呼ばれる（クリーンアップに使用可能）
phase_ended内ではget_jump_target()でジャンプ先を取得でき、get_run_count()で再実行回数を確認できます。無限ループ防止のガードに使えます。
function void phase_ended(uvm_phase phase);
uvm_phase jump_to = phase.get_jump_target();
if (jump_to != null)
`uvm_info("JUMP", $sformatf("Jumping to %s", jump_to.get_name()), UVM_LOW)
endfunction
重要な制約として、phase jumpはUVM Domainの12サブフェーズ内でのみ機能します。Common Domain（build、connect等）への後方ジャンプはサポートされていません。また、前方ジャンプ（サブフェーズのスキップ）は技術的に可能ですが、前提条件が満たされない危険があるため注意が必要です。
5. phase_started / phase_endedコールバック
シミュレータが正しくフェーズ遷移を管理するには、以下の3つのコールバックを適切に発火させる必要があります。
| コールバック | 呼ばれるタイミング | phase jump時 |
|---|---|---|
phase_started(phase) |
フェーズ開始直前 | 呼ばれる |
phase_ready_to_end(phase) |
全objection drop後、終了前 | 呼ばれない |
phase_ended(phase) |
フェーズ終了直後 | 呼ばれる |
phase_ready_to_endがphase jump時に呼ばれないのは非対称な動作であり、実装時に注意が必要です。
デバッグ用コマンドラインオプション
UVMはフェーズとobjectionのデバッグ用にplusargを提供しています（Accellera実装固有、IEEE 1800.2標準には含まれません）。
# フェーズ遷移のトレース
+UVM_PHASE_TRACE
# objectionのraise/dropのトレース
+UVM_OBJECTION_TRACE
+UVM_PHASE_TRACEを有効にすると、各フェーズの開始・終了・ジャンプが時刻付きで表示されます。+UVM_OBJECTION_TRACEではobjectionのraise/dropが呼び出し元の情報付きで表示されます。フェーズ終了のハングやobjectionの漏れを調査する際に非常に有用です。
まとめ
| 項目 | 内容 |
|---|---|
| run_phaseの性質 | taskベース（uvm_task_phase継承）、時間消費あり |
| 終了制御 | objectionメカニズム（階層的カウンタ方式） |
| drain_time | デフォルト0ns、set_drain_time()で設定 |
| sub-phase | 12個、run_phaseとPhase Domainで並行実行 |
| phase_ready_to_end | 全objection drop後のコールバック（最大20回） |
| phase jump | ハードジャンプのみ、UVM Domain内で後方/前方 |
| timeout | デフォルト9200秒、plusarg +UVM_TIMEOUT で変更 |
| デバッグ |
+UVM_PHASE_TRACE、+UVM_OBJECTION_TRACE
|
| シミュレータ側の課題 | プロセス管理、objection追跡、コールバック発火順序、phase jump |
run_phaseはUVM検証環境の実行エンジンであり、ユーザーから見れば「テストシーケンスを走らせる場所」ですが、シミュレータ開発側から見ると「複数プロセスの協調実行と動的な終了制御」という実装課題が詰まったフェーズでした。
特にphase jump時のphase_ready_to_endの非発火、Phase Domainによる並行実行の同期制御、objectionの階層的な伝播など、ドキュメントだけでは分かりにくい挙動が多く、sukimasimの開発を通じてUVMの仕組みの裏側を理解できたのは良い経験でした。
Ibex UVM DV環境は、RISCV-DVによるランダム命令生成、複数エージェントの協調動作、ISSとのco-simulationなど、run phaseの機能をフル活用した実践的なテストベンチです。sukimasimでこの環境を動かせるようになることが当面の目標であり、その過程で得た知見は今後も記事にしていきたいと思います。
参考
- IEEE Std 1800.2-2020 (UVM Standard)
- IEEE Std 1800-2023 (SystemVerilog LRM)
- UVM 1.2 Reference Manual (Accellera)
- Accellera UVM Reference Implementation (GitHub)
- lowRISC Ibex RISC-V Core Documentation: Verification