Verify2012 UVMテストベンチとEVEのエミュレータを繋げてみました、QNETの事例

2012年9月28日、今回で13回目の開催となるLSI検証技術セミナー「Verify 2012」が新横浜のホテルで開催された。


ここでは、同セミナーでユーザー事例として紹介された「UVMとエミュレータの協調シミュレーションによる検証高速化」について紹介する。同講演を行ったのは、富士通九州ネットワークテクノロジーズ株式会社 システムロジック開発センター 第一開発部の由利英介氏である。

由利氏はハードウェアの開発手法の研究・構築を行い、それを社内に展開する立場の人物で、今回はSystemVerilogベースの検証メソドロジ「UVM」の導入事例ならびに、UVMテストベンチとEVE社のエミュレーターの接続事例について語ってくれた。

verify2012-05.jpg

※画像は由利氏の講演の様子


由利氏の話によると、QNETでは元々検証メソドロジ「OVM」を利用していたようで(少なくとも由利氏は利用していた)、「UVM」の導入はある意味自然の流れと言える。由利氏が「UVM」を実際使ってみた分かった良い所として挙げたのは大きく下記3点。

・テストベンチがきれいに書ける
・規則性があるのでスクリプトで自動化出来る
・クラスの拡張と置き換えの利便性

由利氏が最も強調していたのは、テストベンチがきれいに書けるという点で、仮に他人が書いたテストベンチであっても整理された記述スタイルにより、テストベンチのバグ原因を突き止めやすい等のメリットがあるとの事。ディレクトリ構成や命名規則などローカルルールを作って運用するのがおすすめと語った。

またQNETでは、規則的な部分をスクリプトで自動化し、検証フレームワークやローカル・ルールで作ったディレクトリ構成などを自動生成することで検証環境の立ち上げ期間を短縮しているほか、DPI(Direct Programming Interface)を用いて検証対象のC言語のリファレンス・モデルを叩き、ダイナイックに期待値を生成することで論理的な期待値一致を完全に自動化。従来手法と比較して検証工数を30%程削減し、現場の検証エンジニアからも「理想の検証環境」と評価を得ているという。

verify2012-06.jpg

verify2012-07.jpg
※画像は由利氏の講演データ(以下、全て同様)


しかし便利な「UVM」の導入にも障壁はあると由利氏。
出来るだけ過去の資産を流用したいという設計現場の考えは厚い壁で、仮にそれを乗り越えたとしても、オブジェクト指向に対する「先入観」が「UVM」導入の更なる壁として立ちはだかるとの事。こんな現状に対し由利氏は、「UVM」はオブジェクト指向で難しい「分析と設計」を不要とする業界のノウハウの集大成であるため、オブジェクト指向を恐れることなく利用して欲しいと語った。

続いてUVMテストベンチとEVE社のエミュレーター「ZeBu」との接続に関する話。

由利氏は、検証時間の短縮という誰もが目指す目的の延長線上で、「UVM」の利便性と「ZeBu」の高速性を融合させたいと両環境の接続に挑戦。本来であれば、DUTとテストベンチを全て「ZeBu」に実装する方法が一番高速化が見込めるが、「複雑なテストベンチをZeBuに実装するのは手間がかかる」と、シミュレーター上のテストベンチとDUTを実装した「ZeBu」で協調シミュレーションする形を選んだ。

協調シミュレーションを行うにあたり幾つか必要な作業があった。まず、「ZeBu」ではFPGAのマクロを実装出来ないため、評価対象のデザインからマクロを抜き出す作業を行った。これらの作業は工数にして約3日(1名)で完了し、この状態で信号レベルの協調シミュレーションは容易に実現できた。続いて、トランザクション・ベースのシミュレーションを行うためにトランザクタの設計とテストベンチの修正を行った。

verify2012-08.jpg
トランザクタの設計には、EVEの用意する合成ツール「ZEMI-3」を用いて合成する方法とEVEの用意するマクロを用いて手設計する方法があるが、前者の場合マルチスレッドの動作制約があるため、今回はマクロ・ベースでトランザクタを設計。具体的にはマクロを制御するFSMとDUTとのI/Fを設計した。これらの作業はFPGAのマクロ対策に加えて更に5日を要した。テストベンチの修正は通信手段の合わせこみとモニタとドライバの修正のみで1日で完了。これらの準備により、シミュレーターと「ZeBu」とシミュレーション・エンジンを簡単に切り替える環境を構築出来た。(あくまでも静的な切り替え)

verify2012-09.jpg

verify2012-10.jpg
環境が整ったところで評価を実施。論理シミュレーターと協調シミュレーションとで信号レベル、トランザクション・レベルでのシミュレーション時間をそれぞれ比較してみたところ、当初の想定ほど高速化は実現できなかった。(※下の図を参照)

verify2012-11.jpg
しかし、「ZeBu」の処理時間を0時間と仮定して高速化の限界値を算出してみたところ、協調シミュレーションによる高速化の結果がさほど悪くないという事が分かった。(※下の図を参照)

verify2012-12.jpg
また、シミュレーター側のアサーション(SVA)を「ZeBu」に実装した場合でも高速化にに成功。更にトランザクション・レベルのシミュレーションにおいて、1回当たりのデータ転送量を増やすことで高速化が実現できる事も確認した。(※下の図を参照)

verify2012-13.jpg
verify2012-14.jpg
由利氏はこれら協調シミュレーションの評価にあたり、高速化のためのテクニックとして、テストベンチとZebu間の通信回数を減らすのがポイントと指摘。具体的な手法として、通信でトランザクタの「Message Inport」を使用せずDPIとZeBu-APIを利用してバックドアでRAMを介して通信する方法を紹介。更にテストベンチの負荷を下げることも高速化のカギとした上で、下記4つのヒントを示した。

・トランザクションの転送量を減らす/転送量を増やす
・できる限りUnTimedにする
・DUTに対するアサーションは出来る限り多い方が良い
・無駄なランダマイズを減らす

verify2012-15.jpg


= EDA EXPRESS 菰田 浩 =
(2012.11.05 )