Questa Prime Lite向け テストフレームワークを自作してみた

2025年末の仕事納め、皆さん進捗いかがでしたか？ 私はダメでした、goldear@JiN_C125です。

突然ですが、FPGA の検証ではシミュレーション作業が欠かせません。Siemens 社製の Questa Prime Lite という無償ツールがあるのですが、有償版ほどの機能がなく、標準フローもやや難があります。そこで 2025年の “残務処理” として自分向けに、一連のシミュレーションを効率化できるテストフレームワークを作ってみました。

このフレームワークは Windows OS を対象として PowerShell + Tcl + Python を組み合わせ、以下のような点を実現します。

  • テストの自動実行
  • テストシナリオごとのログ出力
  • Pass/Fail 判定の明確化

対象読者は Questa Prime Lite ユーザーの個人開発者／中規模プロジェクトの検証担当者 です。

スポンサーリンク

なぜテストフレームワークを自作したのか？

(ぶっちゃけ残務処理。。。) 業務では、回帰テスト、ログ管理、再現性の確保、証跡の保存といった検証フローは、ある意味“当たり前”のように整備されています。一方で、個人開発になると「そこまでの仕組みを用意するのは大変」という理由から、どうしても場当たり的なテストになりがちです。

今回は、「業務で当たり前に行っている検証フローを、無償ツール環境でどこまで再現できるか？」という点をテーマに、Questa Prime Lite 向けのテストフレームワークを自作しました。

目標は “ただテストを回す” ではなく、少なくとも次の4点を運用として成立させることです。

  • 回帰テストとして継続的に回せること
  • ログが整理された形で残ること
  • 実行条件が明確で再現性があること
  • 後から見返せる証跡として残ること

特徴

個人向けながら以下の点を高機能化しています。

独立したテストシナリオ

各テストがそのまま独立実行でき、ログや波形も別管理です。結果を追いやすく、失敗時の原因追跡がスムーズ。

ログ解析 → Pass/Fail 判定

Tcl 側で生成されるログを Python でパースし、以下の条件を判定：

  • ルール違反(SVA)エラー
  • Scoreboard 失敗
  • 明示的な FAIL タグ

このルールベース判定で、一貫した合否判定ができます。

PowerShell ベースの制御

Windows 上でシンプルに実行でき、ファイル操作やログ集計もスクリプト化できます。ターミナル一発で回せるのは効率が高いです。ただし、PowerShell を Shell Script に置き換えることで、Linuxでも実行可能(未検証)です。

全体構成とGitHub

今回の実装は以下の GitHub リポジトリで公開しています

GitHub - jin820-dev/GN-sim_questa_env: PowerShell-based simulation environment for Questa Prime Lite.
PowerShell-based simulation environment for Questa Prime Lite. - jin820-dev/GN-sim_questa_env
github.com
 
.
├─ run_sim.ps1            # テスト実行
├─ run_sim_single.ps1     # 指定したテストシナリオの実行
├─ run_clean.ps1          # 環境クリーンアップ
├─ run_cov_merge.ps1      # カバレッジマージ（Lite 版は未検証）
├─ run_cov_report.ps1     # レポート生成（Lite 版は未検証）
│
├─ tcl/
│   ├─ compile.tcl        # コンパイル手順
│   ├─ sim.tcl            # シミュレーション制御
│   ├─ default.tcl        # デフォルト設定
│   ├─ dumpmisc.tcl       # 波形ダンプ制御
│   └─ summarize_questa_logs.py # ログ解析
│
├─ result/
│   ├─ log/               # ログファイル
│   ├─ wave/              # 波形ファイル
│   ├─ cov/               # カバレッジ
│   └─ covmerge/          # マージ済みカバレッジ
│
└─ tmp/                   # 一時ファイル

この設計によりテストシナリオ毎に独立したログと波形ファイルを残し、後からの結果解析や継続的な改善がしやすいフローを確立しました。

Questa Prime Lite 向けテストフレームワークの全体実行フロー図を示す。

この図は、本フレームワークの全体的な処理の流れと、各スクリプト・ツールの役割関係を示したものです。
ユーザーはまず run_sim.ps1 を実行します。このスクリプトはテストリストを読み込み、複数のテストシナリオがある場合は、それらを1件ずつ順番に処理します。各シナリオの実行は run_sim_single.ps1 に委譲され、ここで1テスト分の処理が完結します。

run_sim_single.ps1 からは default.tcl が呼び出され、以降の Tcl スクリプト群を統括します。default.tcl はいわば司令塔の役割を持ち、コンパイル処理を行う compile.tcl、シミュレーションを起動する sim.tcl、および波形出力などの補助処理を行う dumpmisc.tcl を順に実行します。

これらの Tcl スクリプトは Siemens Questa を制御し、テストベンチと指定されたシナリオを用いたシミュレーションを実行します。実行結果は、ログ（result/log）、波形ファイル（result/wave）、カバレッジデータ（result/cov）としてシナリオ単位で保存されます。

すべてのシナリオの実行が完了すると、run_sim.ps1 によって Python スクリプト summarize_questa_logs.py が呼び出されます。このスクリプトは各ログを解析し、Pass/Fail の集計結果をコンソールに表示するとともに、summary.csv として一覧形式の結果を出力します。

なお、本図は理解しやすさを優先し、1シナリオ分の処理フローとして簡略化して描いています。実際には、複数のシナリオがある場合、それぞれが同じ流れで順番に実行される形になります。

使い方の一例

ここまでで、本フレームワークの全体構成と処理の流れを説明しました。ここからは、実際にはどのように実行し、どのようなログや結果が出力されるのかを説明します。

基本的な使い方は非常にシンプルで、PowerShell から run_sim.ps1 を実行するだけです。

複数のテストシナリオが定義されている場合でも、スクリプト側で順番に処理されるため、ユーザーは個々のテストを意識する必要はありません。

以下は、実際に全テストを一括で実行した例です。

> .\run_sim.ps1 (DUT_ROOT) -a -w -c

オプション：

  • -a: 全テスト実行
  • -w: 波形ファイル出力
  • -c: カバレッジ収集

※カバレッジのマージ・レポート生成機能を含みますが、Questa Prime Lite では未検証。

以下に特徴的な実行ログの抜粋を示します。

実行を開始すると、まずテストの実行条件がログに出力されます。ここには DUT のパス、使用するモデル、乱数シード、対象となるテストリスト、GUI の有無、波形・カバレッジの有効／無効といった情報がまとめて表示されます。

このように、**「どの条件で実行したか」**が明示的に残るため、後からログを見返した際にも再現性を保つことができます。

PS E:\git\GN-sim_questa_env> .\run_sim.ps1 ..\GN-hdl_axi4l_test -a -w -c
=== run.ps1 start ===
DUT_ROOT : ..\GN-hdl_axi4l_test
MDL_ROOT : E:\git\GN-mdl_axi4_lite;E:\git\GN-mdl_clock;E:\git\GN-mdl_reset
SEED : 1
TESTMODE : all
TESTLIST : sample_test axi4l_reg_access_test
GUI : 0
Wave : 1
Coverage : 1

次に各テストシナリオが1件ずつ実行されます。本フレームワークでは、シナリオごとにログが独立して出力されるため、どのテストで何が起きたのかを追いやすくなっています。以下は、テスト実行中のログの一部です。

# === START sample_test
# RD RW0 = 0x00000000 resp=0
# [TEST] RESULT=PASS
# === DONE sample_test

このように、単に Pass/Fail だけでなく、各操作の内容や期待値（exp）と実測値（act）がログとして残るため、波形を開かなくてもある程度の状況を把握できます。

すべてのテストシナリオの実行が完了すると、最後に Python スクリプトによるログ集計が行われます。その結果が、以下のような SUMMARY として表示されます。

=== Summarizing simulation logs ===
=== SUMMARY ===
SCENARIO RESULT SRC SEED TRANSFERS ERRS Q_ERR Q_WARN LOG
————————————————————————————————————————
axi4l_reg_access_tes PASS TEST 1 0 1 .\result\log\axi4l_reg_access_test.log
sample_test PASS TEST 1 0 1 .\result\log\sample_test.log
————————————————————————————————————————
TOTAL=2 PASS=2 FAIL=0 UNKNOWN=0
CSV written: result/summary.csv
All tests PASSED

ここでは、各シナリオの Pass/Fail、警告数、対応するログファイルのパスなどが一覧形式で表示されます。
また、この内容は summary.csv としてファイルにも保存されるため、後から集計したり、履歴として管理したりすることができます。
※補足 WARNINGの理由として +accの都合で最適化警告が出るが、テスト結果の合否とは切り分けている

> vsim -view .\result\wave\axi4l_reg_access_test.wlf

Questa Prime のコマンド実行で、各テストシナリオの波形ファイルをGUIで確認できます。

開発して気づいた点

今回フレームワークを作ってみて、「業務と同じことをそのまま個人環境に持ち込むのは、やはり難しい」という点を改めて実感しました。Questa Prime Lite という無償ツールである以上、どうしても以下のような制約があります。

  • カバレッジのマージや高度な分析は制限がある
  • HTML 形式のレポート自動生成のような機能は標準では用意されていない
  • UVM のような本格的な検証フレームワークは使用できない

つまり、「業務と同じことをそのまま再現する」ことはできません。

一方で、「何ができないか」がはっきりしたことで、Questa Prime Lite 環境なりの落としどころも見えてきました。

  • 少なくとも、テストの実行条件・ログ・結果を機械的に残すことはできる
  • 回帰テストとして“回し続ける”形には持っていける
  • 人が波形を見る前に、まずサマリで当たりを付けられる

業務レベルの検証環境には及ばないものの、「個人開発でここまで揃っていれば十分実用的」というラインは作れたと思っています。

この記事で紹介するのは“業務環境の代替”ではなく、“個人環境としての現実的な落としどころ”です。これ以上の検証となると残念ながら難しいです。

今後の改善案

今後の改善としては、大掛かりな自動生成よりも「運用で効く改善」を優先したいと考えています。具体的には、summary.csv の情報をもう少し増やすこと（実行時間やFAIL理由など）、FAIL時にログの見どころを自動で抜粋することあたりが現実的です。また、summary.csv は機械処理に便利ですが、人間が眺める用途としてはHTMLレポートがあると嬉しいので、余裕があれば Python で出力してみたいところです。

まとめ

この記事では、Questa Prime Lite 向けに自作したテストフレームワークの設計思想と実装について紹介しました。
シミュレーション自動化は地味な作業ですが、繰り返しの精度と開発速度を大きく上げてくれます。これ以上の検証機能を求めるなら、有償版ツールを使うのが良いですが、個人開発・中規模プロジェクトならこのフレームワークで十分戦えます。

コメント