はじめに

Wilson Research Group が 2024年に世界的な規模で実施し、Siemens EDAのHarry D. Foster氏が分析した「Functional Verification Study 2024」によると、FPGA開発においてテストベンチにPythonを使用していると回答したプロジェクトは全体の27%であり、PythonベースのメソドロジAPI群である cocotbを使用していると回答したプロジェクトは9%である。いずれも複数回答可能な設問である。 この 27%を母集団として、さらに FPGA プロジェクトの中でPythonがどのように使われているかの設問では、回答の選択肢としてランタイムマネジメント、スティミュラス生成、cocotbなどのメソドロジ、その他が列挙されている中から、スティミュラス生成を選択したのは47.2%である。
このことから、FPGAプロジェクトでPythonを使ってスティミュラス生成を行なっているプロジェクトは27% X 47.2% = 12.7%であることが分かる。

地域的にはヨーロッパでの使用率が米国のそれを上回り、また設計言語ではVerilogやSystemVerilogよりもVHDLで設計しているユーザーがPythonを好んで使用する傾向がある。また複数回答が可能であることから、プロジェクトの主要なテストベンチ言語はSystemVerilogであってもモジュールによって、あるいは担当者によってPythonを使ってスティミュラスを生成している可能性もある。

本稿ではテストベンチを構成する言語としてのPythonについて、特に SystemVerilog 言語との比較において特徴を導き出すことにより、読者が適切に判断することができるための材料を提供したい。

テストベンチ言語比較の指標

テストベンチ言語を選択する、あるいは比較する際に、どのような側面を評価すれば良いだろうか。まずはそれをリストアップしてみたい。

ここでリストされたものは必ずしも互いに排他的ではない。高い抽象度は書きやすさも上がるし、再利用性も上がるだろう。標準プロトコルの検証IPの存在は再利用性が高いことを示す。

Pythonの特徴

プログラミング言語としてPythonを捉えると、インタープリタ実行形式のオブジェクト指向言語であり、コード抽象度としては高水準であり、変数の型定義は動的に行える言語である。しかも C++など従来のオブジェクト指向言語とは異なり、Pythonではすべてがオブジェクトであり、クラス定義とインスタンス化したオブジェクトやそのタイプが分かれていない。図 1.に SystemVerilogコード例とPythonのコード例を示す。

SystemVerilogのコードではpfという名称のuvm_put_portオブジェクトはtxn_aというタイプを扱うことが宣言されている。同時にpbオブジェクトはtxn_bタイプとしてインスタンス化されている。最後の行でpf.put(pb)、つまり pf という名称のuvm_put_portが持つメソッドであるputに対して、異なるタイプのオブジェクトのpbを指定すると、エラーになる。これに対してPythonのコード例では、異なるタイプオブジェクトであるpbもputすることができる。このタイプによる寛容性が高いため、SystemVerilogと比べると、宣言文やパラメタライゼーションの手続きが省略できるというメリットが分かる。この背景にある仕組みについて図 2.で説明する。

変数yrには2025が、変数piには3.14が格納されている。Pythonではyrやpiは実際にデータが格納されているメモリ領域へのハンドルである。ここでyr = piとしてpiのデータの内容をyrにアサインすると、実際にはハンドルがコピーされ、両方のハンドルが同じメモリ領域を指すことになる。この際にダイナミックにタイプが変更される。図3にPythonのコード例と、その実行例を示す。

typeというのはすべてのオブジェクトが持つメソッドで、そのオブジェクトの型を返す。yr = pi 実行後は yr のタイプが int から float に自動的に再定義されていることがわかる。この手軽さはSystemVerilogでは味わうことができない。書きやすさや理解しやすさ、習熟しやすさではPythonの方が優っていると言える。

Pythonの特徴として最後に挙げたいのは、その人気の高さである。ソフトウェアの品質評価とトラッキングを行なっている団体であるTIOBEは、ソフトウェアシステムの構築を開始する際にどのプログラミング言語を使用すべきかに関するTIOBE Indexを公表している。
それによれば 2025年7月のインデックスは26.98%を記録しており、2位のC++、3位の C、4位のJAVA、5位のC#を大きく引き離している。

cocotb とは

cocotbは Coroutine CoSimulation TestBenchの略である。Python開発者は、コルーチンを追加し、イベントドリブン型のコードと同期し、やり取りできるメカニズムが実現可能となった。例えば、このコルーチンを使うと、ユーザがキーボードのキーを押したときにコードに応答させるようなことが実現できる。
一方でcocotbの開発者、は、イベントドリブン型のPythonコードが、同じくイベントドリブン型のHDLシミュレータと相性が良いことを認識し、実行中のシミュレータと連携するパッケージを作成した。
開発にあたってはオープンソースのプロジェクトをGitHubで管理し、世界中のエンジニアコミュニティによって機能追加やバグ改修、保守が行われており、また財務、法務面での支援を非営利団体であるFOSSi Foundationから受けている。

図 5.ではテストベンチとDUTを含む環境を示している。

図 5.においてTestbench Software部分はcocotb以外のPythonで実現する。機能検証においてテストベンチは極めてソフトウェアである。この点においてプログラミング言語であるPythonは非常に魅力的であると言える。その理由はPythonにはさまざまな用途のライブラリが存在するからである。

NumPy、SciPyのような科学計算・データ処理系ライブラリ、Matplotlibのような可視化ライブラリ、scapy、socketのような通信・ネットワーク系ライブラリ、scikit-learn、TensorFlow、PyTorchのような機械学習・AI 系ライブラリ、sqlite3のようなデータベース・ファイル操作系ライブラリを呼び出し、テストシナリオとして活用することができる。
また図 5.において BFM – Bus Function ModelのAPI 部分は、cocotbで実現する。 Pythonから呼出し可能なAPIを定義し、シミュレーション用のRTLで表現するBFMを介してDUTの制御、観測ができる。それはcocotbにはclockやwaitなどイベントドリブンで同期をするメカニズムが実装されているからである。

図 6.にPythonとRTLシミュレータの連携を示す。

テストベンチの中ではコルーチンを複数立ち上げてテストを構成する。シリアルに実行するだけでなく、Verilogの fork~join などのように複数スレッドの同時実行もサポートされている。ランダムにも対応しており、変数のランダマイズ機能やグローバルに指定可能なランダムシードなどの機能も備えている。

ここまでで分かるように、cocotbはPythonの環境とRTL シミュレーションを同期させながら相互にやり取りするインタフェースとしての役割を実現している。
現在GitHub上にあるさまざまな検証用パッケージ、例えばpyuvm、cocotbext-axiなどは、このcocotbの機能をベースとして開発されている。

pyuvm とは

pyuvmはPythonおよびcocotbにより IEEE 1800.2 UVM仕様を実装している。Accellera が標準化したUVMはIEEEに寄贈された後、それまでSystemVerilogで実装されていた詳細は省略され、ユーザが扱うAPIに特化して標準化された。SystemVerilogのUVMはAccellera が保守しており、IEEE 1800.2に対するリファレンス実装ライブラリという位置付けになっている。つまりUVMのAPIは必ずしもSystemVerilogで実装される必要はなく、事実AccelleraのSystemCワーキンググループではSystemCを用いてUVMを実現しようとしている。

多くのプロジェクトではUVMが採用されているが、それは AccelleraがSystemVerilogによって実装した API群をそれぞれのEDAベンダがコンパイルし、シミュレータのインストールツリー下に置いたものが使用されている。よくUVMの採用は困難だと言われるが、その理由のほとんどはクラスライブラリの内在的な複雑さよりもSystemVerilogの言語としての制限に起因するケースがほとんどである。
例えば、UVMファクトリやコンフィギュレーションデータベースを扱うのに必要となるコーディングの複雑さは、SystemVerilogが持つ強力な型付けに対する回避策とも言うことができる。
Pythonではタイプ定義やパラメタライズといった煩雑さ、複雑さが一切ないため、SystemVerilogのUVMに比べ簡単に実装することが可能である。その一つの例として、図 7.にファクトリを使ってUVMのbuild_phaseにおけるドライバやモニターの構築の記述を、SystemVerilogのUVMとPythonのpyuvmとで比較してみる。

Pythonのpyuvmではファクトリーによるコンポーネント生成の記述も簡素化されており、記述しやすく、また可読性にも優れている。このことは再利用性にも、そして習熟の容易性にもつながることを意味している。

その一方で、現在のプロジェクトでSystemVerilogのUVMがどのように使われているかを見てみると、実際には EDA ベンダや IP ベンダが提供する検証IPが使われていることが多い。オンチップバスに加えて Ethernet、USB、PCI Express、MIPIなどさまざまな標準プロトコルを実装する必要のあるプロジェクトでは、個々のUVMエージェントを独自に開発することは不可能である。Pythonベースのpyuvmに対して、そのような検証IPが提供されるエコシステムがあるかというと、残念ながら、そのようなエコシステムは存在しない。つまりいくらUVMがPythonベースで実装されたからといって、すくに検証IPにアクセスできるわけではない。

Pythonベースのテストベンチの評価

ここまでプログラミング言語としてのPython、テストベンチ環境としての cocotb およびメソドロジである pyuvm について見てきた。ここで冒頭に挙げたテストベンチを記述するための言語の評価について、まとめてみたい。

• 言語の習熟しやすさSystemVerilogおよび UVMに対してPythonベースが優れている
• 書きやすさ、読みやすさ特に型付け、タイプ宣言やパラメタライゼーションの有無を考えれば、Pythonの方が書きやすさや読みやすさの点で優れている
• 再利用性の高さ、拡張性の容易さSystemVerilogもPythonもオブジェクト指向をサポートしており、再利用性、拡張性という意味では同等だが、プロトコルに依存した検証IPの再利用となるとSystemVerilog/UVMベースに優位性があるだろう
• RTLよりも高い抽象度これは SystemVerilogであってもPythonであっても、Bus Functional Modelを採用している時点で通常のRTLよりは抽象度が高いと言える
• 制約付きランダム検証手法の実現性制約付きランダム検証手法については、SystemVerilog/UVMでもPython/pyuvmでも、実現することは可能である
• カバレッジドリブン検証手法の実現性Pythonではカバレッジのパッケージがいくつかあるものの、pyuvmには機能カバレッジのサポートがなく、全体としてカバレッジドリブン検証手法としては既存のSystemVerilog/UVMの方が優れていると言わざるをえない
• 標準メソドロジ（UVM）のサポートIEEE 1800.2の実装という意味ではどちらもサポートしているが、サポート範囲の広さとしては既存のSystemVerilog/UVMの方が広い。
• 標準プロトコルの検証IPをサポートするエコシステム明らかに 既存のSystemVerilog/UVMをベースとした検証 IP に分がある
• テストシナリオの資産とそれへのアクセステストシナリオは範囲が広いが、SystemVerilogでDPIを用いることでCライブラリに容易にアクセスすることができるほか、SystemVerilog/UVMに対しては新たなPSSというシナリオを自動的に生成するアクセレラ標準が存在する。一方でPythonでも同じくCライブラリへのアクセスができる事に加えて、Pythonで記述されたネイティブなライブラリが豊富にある。この意味合いで言えば、若干Pythonに分があると言えるだろう。
• 言語ユーザ数言語ユーザ数については数字として比較できるものはないが、恐らく桁違いでPythonユーザの方が多いだろう。ハードウェア設計者数よりもソフトウェア設計者数の方が桁違いに多い中、前出のTIOBE IndexによればPython人口は増え続けている。現場の肌感覚からしても、例えば大学から企業に就職したエンジニアの中でSystemVerilogを記述できる人はほとんどいないのではないだろうか。 Pythonであれば大学の授業や研究室で使ったことがある人が多いのが一般的であろう。
  このユーザ数の違いは検証エンジニアを探す、もしくは教育する上での差につながるだろう。またインターネット上にあるコードやパッケージなどのリソース量の差にもつながる。そして今後ますます活用が期待されるLLMやAIの学習量の差につながる。

まとめ

テストベンチの言語を評価する上で大切な点は、自分の設計の特徴を理解することである。もし主要機能に対してUSBやEthernet、PCI Expressなど標準的なインタフェースが多いような場合には、すでに検証IPが流通しているSystemVerilog/UVMを選ぶのが良いだろう。
アルゴリズム検証でCライブラリが豊富にある場合は、UVMは使用せずにSystemVerilogとDPIを組み合わせた使い方も検討に値する。Pythonのライブラリやパッケージがテストシナリオのリソースとして使用できる場合は、cocotbを中心にテストベンチを構築するのが良いかも知れない。さらに自分の設計の中でも部分的にはSystemVerilog/UVMを使用し、部分的にはcocotbやpyuvmを使うという選択肢もあるだろう。本稿での考察が、適切なテストベンチ言語に関する戦略策定の一助になれば幸いである。
cocotbの開発と保守の中心人物は Philipp Wagner氏である。彼は昼間IBMのサーバーやプロセッサの検証業務に終われ、 夜はPythonを使ってcocotbの開発や保守、そして改善に余念がない。
最後に彼がプレゼンテーション等で必ず使うフレーズを紹介して本稿を終えたい。

参考文献

• [1] Design and Verification Conference – Japan 2023, Python を用いた RTL 検証
• [2] Design and Verification Conference – Europe 2024, cocotb 2.0 How to get the best out of the new major version of the Python-based testbench framework
• [3] GitHub cocotb repository - https://github.com/cocotb/cocotb
• [4] GitHub pyuvm repository - https://github.com/pyuvm/pyuvm