技術文献
Questa CoverCheck - コードカバレッジ・クロージャの自動ソリューション
デバッグは依然として今日の設計フローが抱える最大のボトルネックです。エンジニアは、アーキテクチャ・モデルやRTLモデル、さらに検証コードやテストの中に潜むバグを検出することがデバッグであると考えがちですが、デバッグはカバレッジ・クロージャという骨の折れる作業を含め、設計フロー全体に関わっています。実際、未到達のカバレッジ項目を追跡していった結果、到達不能であることが判明してがっかりすることもあります。本稿では、メンター・グラフィックスのQuestaフォーマル解析手法のなかで重要な位置を占めるQuesta CoverCheckを通じて達成できるコードカバレッジ・クロージャという観点からデバッグを考察します。Questa CoverCheckには、コードカバレッジ向上のためにシミュレーション除外ファイルを自動生成するという独自の機能が備わっており、到達不能なコードへの到達を試みる時間の無駄を省きます。
パワー・アウェア設計のスタティック・フォーマル検証: UPFベースのRTL検証
UPF（Unified Power Format）はローパワー仕様の標準規格であり、アイソレーション・セルとレベル・シフタの挿入をRTL（レジスタ転送レベル）で明示的に定義します。本稿ではRudra Mukherjeeら執筆者が、マルチ電圧設計内でバグの発生しやすい箇所を特定する方法について解説します。設計者はUPFに基づいて、パワードメイン、システム・パワー・ステート、スイッチといったパワー・マネジメント機能の仕様を含むローパワー設計意図を定義します。この情報を検証ツールに取り込むと、通常のシミュレーション・データでは検出困難だったパワードメイン／ボルテージドメインのクロッシングに対して、スタティックなリント・チェックが実行できます。本稿では、ツールを使ってフォーマル検証を自動化し、設計者の負担を軽減する方法についても紹介します。この方法ではアサーションを自動生成することによって、パワー・コントロールのシーケンスをテストしたり、スリープ・モードへの不正遷移がないかどうかをチェックするほか、リテンション・コントロール（セーブ、リストアなど）ならびに設計コントロール（クロック、セット、リセットなど）の競合状態を検出します。
シミュレーション・ファームで真の生産性を確保
現在の電子設計では、検証工程が設計サイクルのかなりの部分を占めています。検証エンジニアは、デザインの検証にスティミュラスを効率的に記述、生成するための新たな方法を求めています。設計規模の増大に伴い検証領域が拡大するにつれて、シミュレーション実行時間も増大しています。
一方、最近のコンピューティング・ファームは、少数の高性能プロセッサではなく、適度な性能のプロセッサを大量に使用する方向に進んでいます。現在では、ほとんどすべての企業がコンピューティング・ファームを持つようになりました。そのため検証エンジニアは、こうしたコンピューティング・リソースを活用して設計をより効率的に検証できる高効率な方法を必要としています。
OVM シーケンスでの inFact の使用
ほとんどの OVMユーザは、ダイレクテッド・テストまたは制約付きランダムテストとして実装した OVMシーケンス（ovm_sequence）をスティミュラス生成に利用する方法について理解しています。ただし、同じ OVMシーケンス・コンストラクトが inFactインテリジェント・テストベンチ・オートメーションでもサポートされていることは、あまり知られていません。本稿では、inFactのカバレッジドリブン・スティミュラス生成ソリューションを OVMシーケンス環境に導入し、制約付きランダム手法で開発されたシーケンスとinFactで開発されたシーケンスのシミュレーション性能を比較します。
OVMコンフィギュレーションとバーチャル・インタフェース
本稿では、OVMテストベンチの構成方法（コンフィギュレーション設定）およびテストとDUTの通信方法について説明します。ここでいうテストベンチの構成方法とは、テストベンチの構造と動作に影響を及ぼす値のコンフィギュレーション設定を意味します。このような値の設定は、単一の場所（テスト）からの設定が理想であり、これによりコンフィギュレーション値を設定している箇所の特定や再構成が容易になります。
SystemVerilogクラスベースのテストベンチ作成
論理検証の効率化の切り札として、制約付ランダム検証手法およびTLM（Transaction Level Modeling）が注目されています。制約付ランダム検証手法とTLMをSystemVerilogで実現する際には、classの概念が重要な役割を果たします。しかし、classの概念に馴染みの薄いハードウェア設計技術者が、自習と実践の繰り返しの中でclassをベースとするテストベンチの作成方法を会得するには、多大な時間を費やしてしまうことでしょう。こうした“技術を身につけるための時間”は以前ならば許容されたかもしれませんが、エレクトロニクス業界全体が過酷な国際競争にさらされている今日では、自己の技術力研鑽のための時間を最小限に留めなければならないこともしばしばです。
そこで、メンター・グラフィックスは、誰もが効果的なSystemVerilogのclassベース・テストベンチを効率的に作成できるように、AVM（Advanced Verification Methodology）を提唱し、オープンソースで公開しています。AVMの導入により、classに不慣れなハードウェア設計技術者も、SystemVerilog classベース・テストベンチを簡単に作れるようになります。
本稿では、AVMを用いたSystemVerilog classベース・テストベンチの作成手順について、ハードウェア設計技術者の視点から解説していきます。
機能検証の新しい波: インテリジェント・テストベンチ・オートメーション
設計の複雑性が高まるにつれ、機能検証はますます複雑になってきました。実際のデザインを作成する時間より、そのデザインが動作することを検証するために費やす時間が長いことは、多くのプロジェクト・チームにとって珍しいことではありません。この検証効率を向上させるため、フォーマル検証と機能シミュレーションの両方を含む様々なツールに投資が行われています。フォーマル解析はデザインのプロパティを静的に、場合によっては動的に検証する有益なチェックを行います。機能シミュレーションはデザインを活性化させ、外部の、時には内部のスティミュラスおよびデータに対する応答を検証するものです。しかし、シミュレーションを使った検証にはテストベンチが必要であり、複雑なデザインに対して良いテストベンチを作成することは難しい作業です。チップの複雑性の拡大、HW/SW統合、モジュールとシステムレベル間の設計要件などの問題により、高い機能カバレッジを達成するテストベンチを手作業で作成することはいっそう難しくなりました。
高品質 CDC 検証のための5つのステップ
今日の複雑なASIC設計ではクロックドメインの数が増えており、CDC（Clock Domain Crossing）を完全に検証することはかつてなく重要かつ困難になっています。機能検証同様、CDC問題の完全な検証を確実にするには、包括的なテストプランが欠かせません。私たちは、北米、日本、ヨーロッパでの数多くの顧客との作業経験を基に、5つのステップで構成される CDC検証のためのプランニングプロセスを開発しました。
CDCのテストプランを立てた後には、構造検証、プロトコル検証、およびメタスタビリティ検証を含む効果的なCDC検証手法が必須となります。これにより、設計段階より CDC 信号の取り扱いを確実に行い、製造後のリスピンを回避できます。本稿では、ブロックレベルおよびトップレベルの RTLモジュールに対してこれらを適用する方法を概説します。また、CDC違反の一般的な例をいくつか説明すると共に、それらが本当の設計上の問題であるか否かを判定するテクニックについても説明します。最後に、いくつかのデザインに対するこの手法の適用結果について、まとめて解説します。
CDC（Clock Domain Crossing）非同期検証自動化の必要性
CDCPaper メンター・グラフィックスでは注力分野であるファンクショナル・ベリフィケーションの一つ、非同期検証に関するホワイトペーパーを作成いたしました。以下にその中から要約、目次、そして最初の項目である「はじめに」をご紹介します。
Ethernet検証IP: AVMからOVMへの簡単な移行事例
オープンソースの検証メソドロジの潮流を作ったAVM(Advanced Verification Methodology)は、新たな設計検証言語、SystemVerilogを用いて発展してきました。そして今、OVM(Open Verification Methodology)へと、その発展を続けています。AVMからOVMへは、幸いにも既存コードを変更することなく移行できます。
検証 IPが単独で充分に検証されたものだとしても、ユーザ環境であるチップで充分に使えるとは限りません。OVM手法は、検証IPがブロック単位からチップレベルへの再利用、そしてシーケンスのレイヤ化機能を定義しています。これによりAVMで開発された検証IPは、OVM互換の検証IPとして容易に移行できるのです。
米Sibridge社はEthernet検証IPの移行において、AVMからOVMへの互換性レイヤを用い、OVM互換とすることに成功しました。この論文では、容易な方法で検証IPをスケーラブルに移行できることをSibridge社の検証IPを例に解説しています。
OVM: オープンで相互運用可能な検証メソドロジ
メンター・グラフィックスとケイデンスが共同で開発したプロジェクトOVM（Open Verification Methodology）は、SystemVerilogのオープンな検証手法です。OVMが、通信メカニズムやユーティリティなどのクラスライブラリを提供するため、ユーザはSystemVerilogを使って検証の問題に専念することができます。
OVMには、ユーザがコード化した検証すべきコンポーネントを再利用できるようにするため、さまざまなコンポーネントが互いに持っている関係をアーキテクチャに織り込んでいます。
ここで重要なことは、コンポーネントのインタフェースをきちんと定義しておくことです。インタフェースがそろっていれば、テスト環境を簡単に作成でき、テスト環境の一部に変化が起きてもコンポーネントを分離してモジュールにすることも可能になります。
OVM WorldのWebサイトは2008年1月に公開されましたが、2008年10月現在5500人以上が登録しオンライン・フォーラムにおいて540ものスレッドに参加しています。