技術文献
SystemVerilogクラスベースのテストベンチ作成
論理検証の効率化の切り札として、制約付ランダム検証手法およびTLM（Transaction Level Modeling）が注目されています。制約付ランダム検証手法とTLMをSystemVerilogで実現する際には、classの概念が重要な役割を果たします。しかし、classの概念に馴染みの薄いハードウェア設計技術者が、自習と実践の繰り返しの中でclassをベースとするテストベンチの作成方法を会得するには、多大な時間を費やしてしまうことでしょう。こうした“技術を身につけるための時間”は以前ならば許容されたかもしれませんが、エレクトロニクス業界全体が過酷な国際競争にさらされている今日では、自己の技術力研鑽のための時間を最小限に留めなければならないこともしばしばです。
そこで、メンター・グラフィックスは、誰もが効果的なSystemVerilogのclassベース・テストベンチを効率的に作成できるように、AVM（Advanced Verification Methodology）を提唱し、オープンソースで公開しています。AVMの導入により、classに不慣れなハードウェア設計技術者も、SystemVerilog classベース・テストベンチを簡単に作れるようになります。
本稿では、AVMを用いたSystemVerilog classベース・テストベンチの作成手順について、ハードウェア設計技術者の視点から解説していきます。
その他の技術文献
検証マネジメントでリスピンへの懸念を軽減
検証が管理されていないと、プロジェクトがスケジュール通りに進まず、品質が脅かされ、リスピンの危険性が大幅に高まります。こうした好ましくない状況が発生する頻度が次第に増加しているようです。メンター・グラフィックスが実施した独自の検証調査によれば、シリコン製造が初回で成功する率は徐々に低下し、2002年の40%前後から2007年には30%未満にまで落ち込んでいます。リスピンの主な原因は設計の機能的または論理的欠陥で、検証マネジメントのプロセス全体で問題が増加していると推測されます。こうした問題が起こる背景には、仕様に基づいて検証プロセスを推進し、検証中に生成される大量のデータを管理できるツールの欠如があります。必要なのは、すべての関係者、つまり、システムアーキテクト、ソフトウェア・エンジニア、設計者、検証スペシャリストがプロジェクトをリアルタイムで可視化できる共通のプラットフォームと環境です。単に検証プランに対してだけでなく、時間とともに変更されることの多い仕様と設計に対してもリアルタイムでの可視化が必要です。IC設計プロジェクトには、プロセス、ツール、データといった3つの側面があります。検証マネジメントに包括的にアプローチするには、それらすべてに対応することが求められます。
プロセッサドリブン検証によるマルチプロセッサ同期のリスク軽減
マルチプロセッサ同期手法は、シングル・プロセッサのマルチスレッドで確立されたソフトウェアベースの同期手法を拡張したものです。こうしたマルチプロセッサ同期手法を実現するには、ハードウェア・ロジックとプロセッサ命令ロジックに対する高度な並列性に対する可視性が欠かせません。マルチプロセッサ同期のハードウェア・ロジックとプロセッサ命令ロジックを検証する際のリスクは、プロセッサドリブン検証手法とそのサポート・ツールを利用すると、最も効果的に軽減できます。検証でのスティミュラスは、システムレベル・テストベンチ上でプロセッサから発生させる必要があります。また、マルチプロセッサを使用した設計内のハードウェアやすべてのプロセッサのステートに対する並列可視性を提供できる非侵入型（デバッグ・ツールを使うことにより対象の状態を変えることのないという意味）のデバッグ・ツールが必要です。
OVM/UVM マクロの弊害性: コスト／メリット分析
マクロの使用は弊害をもたらすのでしょうか。答えはイエスでもありノーでもあります。マクロはあらゆるソフトウェアに不可欠な構成要素であり、Open Verification Methodology（OVM）ライブラリやUniversal VerificationMethodology（UVM）ライブラリも例外ではありません。マクロは、少量のコードの繰り返し入力の軽減、異なるベンダのシミュレータ間での実装や制限の差の吸収、重要機能の確実な実行を目的として、控え目に使用すべきです。OVM/UVM マクロのメリットは明白で直接的かもしれませんが、ベンチマークや頻発するサポートを通じて、隠れたコストが明らかになってきました。マクロの中には、複雑で大規模なコードブロックに展開して性能や生産性に悪影響を与えるものや、シンプルで柔軟なAPI の使用を不必要に分かりにくくし、その使用を制限してしまうものも存在します。
機能検証のトランスフォーマー: 新生Questa
今日の複雑なASICやマルチコアに代表されるようなSoC設計において、検証はその困難さを極めています。従来のモノリシック的な手法の改善やプロジェクトメンバーの増員などのアプローチでは、その困難さに追従することができないのが現状です。設計が機能していることを確かめることがやっとで、プロジェクトの終了間際からクロックを乗せ換える部分で発生する非同期転送の検証を行い、さらに後追いでコーナーケースを叩くようなシナリオをパターン化して検証するようなケースも多くなってきています。結果としてシリコンのやり直し（リスピン）が発生し、予期せぬコスト増につながることも少なくありません。SoCの場合にはソフトウェアで回避する方法も可能性として挙げられますが、確かな方法ではありません。FPGAプロトタイピングなどを導入するプロジェクトも増えていますが、環境立上げの労力やその後の実稼働率が問題となり、必ずしもTAT短縮に充分な貢献ができているとは言えません。検証の在り方を根本的に考え直し、トランスフォームを実践することが必要だと言えるでしょう。
シミュレーション・ファームで真の生産性を確保
現在の電子設計では、検証工程が設計サイクルのかなりの部分を占めています。検証エンジニアは、デザインの検証にスティミュラスを効率的に記述、生成するための新たな方法を求めています。設計規模の増大に伴い検証領域が拡大するにつれて、シミュレーション実行時間も増大しています。
一方、最近のコンピューティング・ファームは、少数の高性能プロセッサではなく、適度な性能のプロセッサを大量に使用する方向に進んでいます。現在では、ほとんどすべての企業がコンピューティング・ファームを持つようになりました。そのため検証エンジニアは、こうしたコンピューティング・リソースを活用して設計をより効率的に検証できる高効率な方法を必要としています。
OVM シーケンスでの inFact の使用
ほとんどの OVMユーザは、ダイレクテッド・テストまたは制約付きランダムテストとして実装した OVMシーケンス（ovm_sequence）をスティミュラス生成に利用する方法について理解しています。ただし、同じ OVMシーケンス・コンストラクトが inFactインテリジェント・テストベンチ・オートメーションでもサポートされていることは、あまり知られていません。本稿では、inFactのカバレッジドリブン・スティミュラス生成ソリューションを OVMシーケンス環境に導入し、制約付きランダム手法で開発されたシーケンスとinFactで開発されたシーケンスのシミュレーション性能を比較します。