【ITニュース解説】RISC-V Lockstep Co-Simulation: Retirement-Level Step-and-Compare for Faster Verification & Debug

システムエンジニアを目指す皆さんにとって、コンピュータの「頭脳」であるCPUの設計や、それが正しく動くことをどうやって確認するか、というのは興味深いテーマだろう。特に最近注目されている「RISC-V（リスクファイブ）」というCPUの設計図は、柔軟性が高く、様々なデバイスに使われることが期待されている。しかし、この柔軟性が高いゆえに、その設計が本当に意図通りに動くのかを検証することは非常に難しい課題となる。

ここで紹介するのが、「RISC-Vロックステップコシミュレーション」という、革新的な検証とデバッグの手法である。これは、私たちが作ったCPUの設計（これをRTLと呼ぶ）と、完全に正しいとされる「参照モデル」という別のモデルを、並行して同時に動かし、それぞれの動作を厳密に比較することで、設計ミスを素早く見つけ出す方法である。

なぜこのような手法が必要なのか。RISC-Vは、小さなマイコンから高性能なサーバーCPUまで、目的に合わせて様々な形にカスタマイズできる。キャッシュメモリの有無、複数のCPUコア（ハート）を持つか、データの扱いの厳密さ（メモリモデル）など、選択肢が多岐にわたるため、どんな設計であっても確実に動作することを検証するには、工夫が必要となるのだ。ロックステップコシミュレーションは、既存の検証手法（UVMなど）とも相性が良く、SynopsysのVCSやVerdiといったよく使われる検証ツールともスムーズに連携できる。また、「RVVI（RISC-V Verification Interface）」という共通のルールを使うことで、設計と参照モデル、そしてテスト環境の間で、CPUの実行状態やイベント情報などを簡単にやり取りできるようになる。これにより、通常の命令実行だけでなく、突然発生する割り込みやエラー（例外）、デバッグ時の動作変更といった「非同期イベント」も、テスト中に再現性を持って検証できるため、複雑な状況でのバグも見つけやすくなるのだ。

このロックステップコシミュレーションの仕組みは、シンプルでありながら非常に効果的である。RTLと参照モデルは、検証のために用意された同じプログラムを並行して実行する。そして、CPUが一つ一つの命令の実行を完全に終え、その結果がプロセッサの「アーキテクチャ状態」、つまりプログラムから見えるレジスタやメモリの内容などに反映された時点を「インストラクションリタイアメント」と呼ぶが、この節目ごとに、両者のアーキテクチャ状態を瞬時に捕捉し、比較する。もし、この二つの状態にわずかでも違いがあれば、その場で不一致が報告される。これにより、無駄なシミュレーション時間を費やすことなく、問題が発生したまさにその瞬間にデバッグを開始できる。また、CPUの内部で一時的に変化するような「過渡的な状態」ではなく、プログラムから見える最終的な状態を比較するため、「これはバグではないのに、なぜか不一致と報告される」といった誤検出（False Positive）が少なく、本当に修正すべき問題に集中できるメリットがある。

比較するアーキテクチャ状態は、検証の進捗に合わせて柔軟に設定できる。たとえば、設計の初期段階では、次に実行する命令のアドレスを示す「プログラムカウンタ（PC）」だけを比較して、CPUが正しく命令をたどっているかを確認する。設計が進んだら、データの計算に使う「汎用レジスタ（GPRs）」も追加して、計算結果が正しいかを検証する。さらに、CPUの動作モードや設定を制御する「制御ステータスレジスタ（CSRs）」も比較対象に加えることで、特権モードの切り替えやエラー処理が正しく行われるかを確認できる。最終的には、メモリ全体の状態まで比較することで、設計の最終的な保証（サインオフ）に必要な高い信頼性を確保する。このように、比較対象を段階的に広げられるため、開発の初期から最終段階まで、幅広い検証ニーズに対応できるのだ。

従来の検証手法として、「トレース」と呼ばれる、CPUの動作ログを後から解析する方法や、「セルフチェック」という、テストプログラム自身が自分の結果をチェックする方法がある。しかし、これらの方法では、問題が発生してからかなり時間が経った後、あるいはテストの最後にようやくエラーが報告されることが少なくない。ロックステップコシミュレーションでは、不一致が起きると、その原因となった最初の命令を即座に特定できる。これにより、CPUの設定レジスタの予期せぬ副作用や、特権モードの切り替えミス、命令の実行順序に関する微妙なバグなど、トレースやセルフチェックでは見逃しやすいような問題も、確実に、しかも素早く発見できる。特定された各エラーは、どの命令で、どのような違いが生じたかが明確に記録されるため、テストを何度でも同じように再現でき、根本原因の解析が格段に早まる。

不一致が検出された場合、システムはその不一致が発生した命令のインデックス、命令の内容、期待された値と実際の値、そしてその直前のいくつかの命令の情報までを記録する。エンジニアはこれらの情報を使って、すぐにCPUの内部信号の変化を示す「波形」や詳細なログに飛び込み、どの部分の回路が誤った動作をしたのかを特定できる。問題箇所を特定し、修正を適用した後も、同じテストを同じ条件（「シード」という乱数生成の初期値を用いることで、ランダムなテストでも再現性を確保できる）で再実行するだけで、修正が正しく反映されたかを確認できる。このように、問題が発生したその場でデバッグできるワークフローは、デバッグにかかる時間を大幅に短縮する。

より多くの種類のバグを見つけるためには、様々なテスト入力が必要となる。この検証手法では、ランダムな命令列を生成したり、RISC-Vの特定の命令セットを狙ったテストを組み合わせたりする。さらに、テストの途中でランダムに割り込みなどの非同期イベントを発生させることで、CPUが様々な状況下で正しく動作するかを徹底的に検証する。RVVIインターフェースを使うことで、これらのランダムなイベントも、デバッグ時に再現可能な形で管理できるため、複雑なバグの解析も可能となる。特に、仮想メモリの操作、CPU設定レジスタの様々な副作用、そして異なるメモリモデルの挙動などを集中的にテストすることで、通常では見過ごされがちな稀なバグ（コーナーケースバグ）も確実に発見し、設計全体の堅牢性を高めることができる。

このロックステップコシミュレーションは、既存の検証フローに容易に組み込むことが可能だ。UVMという検証フレームワークのコンポーネントとして、RTLと参照モデルの同期を取り、RVVIを通じて状態やイベントをやり取りし、その結果を検証の進捗を管理する「スコアボード」や「カバレッジ」ツールに連携させることができる。SynopsysとImperasという企業が協力して、この手法をVCSやVerdiといった業界標準のツールと組み合わせて活用する方法も提供しており、参照モデルをRTL検証に直接組み込むことが一般的になっている。

実運用においては、検証の初期段階で性能を重視し、プログラムカウンタと汎用レジスタの比較から始め、設計の信頼性が向上するにつれて、制御ステータスレジスタやメモリなど、比較対象の範囲を広げていくのが一般的である。また、タイマーやランダムな入出力など、予測が難しい「非決定的な要素」は、一時的に無効化したり、代替の仕組みを設けたりして、誤検出を避けるように工夫する。RVVIに基づくハンドシェイク機構により、ランダムな割り込みやデバッグ要求を導入しながらも、テストの再現性を保つことができる。長時間の検証（リグレッションテスト）を行う場合でも、途中の状態を保存する「チェックポイント」機能や、乱数生成の初期値（シード）を確実に記録する仕組みにより、いつでもテストを再現できる保証が得られる。

まとめると、インストラクションリタイアメントレベルでのロックステップコシミュレーションは、RISC-V設計チームがCPUのアーキテクチャとしての正確性を厳密に検証するための強力な手段を提供する。設定可能な状態を各命令のリタイアメント時に比較することで、設計の不一致を即座に検出し、無駄なシミュレーションサイクルを削減し、問題の発生したまさにその地点でデバッグを行うことができる。SystemVerilog/UVM環境への統合、RVVIインターフェースの活用、ImperasFPMのような検証済みの参照モデル、そしてVCSやVerdiといった主要な検証ツールのサポートにより、このアプローチは設計の初期段階から最終的なリリース前検証まで、あらゆるフェーズでその威力を発揮し、従来のトレースベースやセルフチェックによる検証手法を補完する。システムエンジニアとしてCPU設計の品質を追求する上で、この手法は不可欠なものとなるだろう。