Home 製品情報機能検証リソース技術文献

技術文献

	Publication Name	Design Tasks
	Questa CoverCheck - コードカバレッジ・クロージャの自動ソリューションデバッグは依然として今日の設計フローが抱える最大のボトルネックです。エンジニアは、アーキテクチャ・モデルやRTLモデル、さらに検証コードやテストの中に潜むバグを検出することがデバッグであると考えがちですが、デバッグはカバレッジ・クロージャという骨の折れる作業を含め、設計フロー全体に関わっています。実際、未到達のカバレッジ項目を追跡していった結果、到達不能であることが判明してがっかりすることもあります。本稿では、メンター・グラフィックスのQuestaフォーマル解析手法のなかで重要な位置を占めるQuesta CoverCheckを通じて達成できるコードカバレッジ・クロージャという観点からデバッグを考察します。Questa CoverCheckには、コードカバレッジ向上のためにシミュレーション除外ファイルを自動生成するという独自の機能が備わっており、到達不能なコードへの到達を試みる時間の無駄を省きます。	機能検証
	Veloceのエミュレーション　システムレベルのパワー解析と検証最新世代のVeloceエミュレータは、非常に効率的で精度の高いシステムレベルのパワー・アウェア検証とパワー解析のソリューションを提供するとともに、長時間テストなどエミュレーションに欠かせない機能を備えています。本稿では、RTL（レジスタ転送レベル）技術とゲートレベル技術から移行し、パワー解析と検証の機能および対象範囲をシステムレベルに引き上げる必要性について説明します。また、システムレベルのパワー解析と検証にとってエミュレーション技術が理想的な理由、エミュレーション機能の利用方法、そして複雑なSoCの設計、検証、品質、消費電力にエミュレーションがもたらすメリットについて紹介します。	エミュレーション・システム
	パワー・アウェア設計のスタティック・フォーマル検証: UPFベースのRTL検証 UPF（Unified Power Format）はローパワー仕様の標準規格であり、アイソレーション・セルとレベル・シフタの挿入をRTL（レジスタ転送レベル）で明示的に定義します。本稿ではRudra Mukherjeeら執筆者が、マルチ電圧設計内でバグの発生しやすい箇所を特定する方法について解説します。設計者はUPFに基づいて、パワードメイン、システム・パワー・ステート、スイッチといったパワー・マネジメント機能の仕様を含むローパワー設計意図を定義します。この情報を検証ツールに取り込むと、通常のシミュレーション・データでは検出困難だったパワードメイン／ボルテージドメインのクロッシングに対して、スタティックなリント・チェックが実行できます。本稿では、ツールを使ってフォーマル検証を自動化し、設計者の負担を軽減する方法についても紹介します。この方法ではアサーションを自動生成することによって、パワー・コントロールのシーケンスをテストしたり、スリープ・モードへの不正遷移がないかどうかをチェックするほか、リテンション・コントロール（セーブ、リストアなど）ならびに設計コントロール（クロック、セット、リセットなど）の競合状態を検出します。	機能検証
	検証マネジメントによるプロセス改革と導入事例最新の機能検証手法の導入により、大規模化／複雑化する半導体の検証に一定の効果が上がっているように見受けられます。機能検証の質を上げるにはカバレッジを上げること、機能検証のコストを下げるにはカバレッジ達成の時間短縮や効果的なプロセスが重要となっています。この資料では、機能検証において最重要項目とされるカバレッジの一元化と管理によるプロセス改革についてご説明します。	機能検証
	スプレッドシートでは対応しきれなくなったら 2011年、イタリアのアグラテ（ミラノ近郊）にあるSTマイクロエレクトロニクスの工場で32ビット・マイクロコントローラの組込みソフトウェアを書いているエンジニアは、メンター・グラフィックスの要求仕様追跡ツールのReqTracerを使うことを考え始めていました。マイクロコントローラの製作にとって欠陥ゼロという顧客の期待に沿うことがますます重要になっており、それに応えるためには最初の見積もり依頼から開発サイクルのすべてにわたって要求仕様を追跡し続けなければなりません。ReqTracerを採用する以前のハードウェア・エンジニアはExcelとカスタムスクリプトに大きく依存していたため、顧客とコミュニケーションを取ったり、自動車業界における暗黙の要求仕様に応えたりするうえで欠かせない、追跡マトリックスの作成と影響分析をしていましたが、そこには限界があり、簡単ではありませんでした。マイクロコントローラのソフトウェアを書くにあたって要求仕様を追跡し続けることは、少なくともハードウェア設計と同じくらいやっかいな仕事です。その理由の1つとして、Automotive SPICEや最近ではISO26262といった標準規格に適合しなければならないことが挙げられます。しかし、たとえ、もっぱら手作業に頼る使いにくい方法でも、すでに要求仕様の追跡に何らかの使い慣れた方法を持っている25 人のエンジニアで構成されるチームの作業手順はそう簡単には変えられません。結局、ソフトウェア設計チームは小さなパイロットプロジェクトでそのツールを試してみることにしました。そして、すぐに、多くの要求仕様が単純にソースコードにまで正しく反映されていないということに気づきました。	機能検証
	最新のローパワー設計検証リーク電流による消費電力量は、バッテリ駆動による100nm以下の設計の全消費電力において大きな割合を占めています。このため、さまざまなパワー・マネジメント手法を導入せざるを得ない設計チームから、リーク電力の最も効率的なパワー・マネジメント手法として注目を集めているのがパワー・ゲーティングです。65nm以下のプロセス・ノードではリーク電力を最小化するため、パワー・ゲーティングと各種のバイアス手法を組み合わせています。パワー・ゲーティングや基板バイアス（バック・バイアスあるいはサブストレート・バイアスとも呼ばれる）などのローパワー手法を導入した場合、一筋縄では解決できない検証課題が数多く発生します。本稿では、パワー・マネジメント手法を検証する最新のシミュレーション技術について解説します。	機能検証
	UVM Express - UVM導入とUVMによる検証スタイル UVM Expressについてご紹介します。UVM ExpressはUVMの導入を容易にするパッケージで、この資料ではその検証スタイルについて学んでいただくことができます。この資料はVerification Academy - www.verificationacademy.com に動画で掲載されているUVM ExpressのトレーニングモジュールをPDF化したものです。まず最初にUVM Expressの概要についてご説明します。この資料を通して使用するDUTについて、またその信号、信号に対してアクセスするBFMのタスク、検証していくためのプランニングについてご紹介します。次に機能カバレッジについてご説明しています。同じDUTに対してオリジナルのテストを用いて、そこに機能カバレッジを追加します。カバレッジのエージェントやモニター、カバレッジコレクタなどについて説明します。トランザクションの構成についても見ていただけます。	機能検証
	リソースを使用した最先端のテストベンチ・コンフィギュレーション堅牢で再利用可能なテストベントを構築するには、テストベンチ要素が構成可能でなければなりません。要するに、テストベンチの構成とは、データベースに名前／値ペアを追加し、テストベンチ・オブジェクトがそのデータベースにアクセスできるようにすることです。名前／値ペアの格納と検索がすべてではありません。高度に構成可能で再利用可能なテストベンチを構築するにあたり、アーキテクチャ上には、データベースを設計する方法、および項目をデータベースに効率的に追加し使用する方法に関する多くの問題が存在しています。UVMは、コンフィギュレーション・インフラストラクチャとAPIを提供するリソースと呼ばれるファシリティを備えています。ここでは、リソースに共通するコンフィギュレーションの問題を取り上げます。リソースを使用して、精巧なコンフィギュレーションの使用モデルを実装する方法を紹介します。	機能検証
	特定プロトコル用ホストおよびペリフェラル・インタフェースのための仮想デバイス限られた機能から、複雑で多機能なネットワーク接続へと、デバイスの進化は止まるところを知りません。この動きを受けて、企業ではチップ、システム、組込みソフトウェア開発における検証をこれまでと違う総合的な視野から見直す必要に迫られています。シミュレーション実行時間の短縮や設計サイクルの早期におけるシステム全体の検証だけでなく、ブロック・レベルの検証からシステム・レベルの検証への移行についても、明確な必要性を裏付ける資料が多数、提出されています。ハードウェア支援検証、つまりエミュレーションは、極めて高速なフルSoCテストを実行するキャパシティと性能を提供します。エミュレーションでは、テスト・ケース期間やテスト件数が増加しても実行時間を短縮できるため、より多くの設計要件をカバーし、より多くのバグを検出できます。しかし、エミュレーションはもはやキャパシティと性能という基本的なメリットをはるかに超えた領域に到達しています。かつては複数の物理的なハードウェア接続が必要だった各種の操作を、今ではエミュレータを使用して仮想的に実現できるようになりました。このため、電子設計分野の主導的な企業は、メガヘルツ・クラスの検証速度と、ブロック・レベルからシステム・レベルまでの完全な仮想化によって加速された検証フローという、両方のメリットを活用したいと考えています。仮想化によって、社内の設計チーム全員がより簡単にエミュレーションを使用できるようになり、エミュレーション環境の柔軟性、可視性、キャパシティが向上します。仮想化ソリューションは、将来の機能検証を一変させるような幅広い機能をもたらしてくれます。例えば、トランザクションベースのコ・モデリング・チャネル・テクノロジによって実現される、仮想ホストおよびペリフェラル・モデル（「仮想デバイス」と呼ばれる）テクノロジやソフトウェア・デバッグ・テクノロジなどです。新しいテクノロジ、仮想デバイスではケーブルやハードウェア・ユニットを追加せずに従来のインサーキット・エミュレーション（In-Circuit Emulation: ICE）ソリューションと同じ機能を持つ製品が登場しはじめています。本稿は、仮想デバイスの系譜を簡単にたどって技術的な特徴とメリットを解説し、2 つの設計アプリケーションの機能性と効率性の高さについて例を交えて紹介します。	エミュレーション・システム
	検証マネジメントでリスピンへの懸念を軽減検証が管理されていないと、プロジェクトがスケジュール通りに進まず、品質が脅かされ、リスピンの危険性が大幅に高まります。こうした好ましくない状況が発生する頻度が次第に増加しているようです。メンター・グラフィックスが実施した独自の検証調査によれば、シリコン製造が初回で成功する率は徐々に低下し、2002年の40%前後から2007年には30%未満にまで落ち込んでいます。リスピンの主な原因は設計の機能的または論理的欠陥で、検証マネジメントのプロセス全体で問題が増加していると推測されます。こうした問題が起こる背景には、仕様に基づいて検証プロセスを推進し、検証中に生成される大量のデータを管理できるツールの欠如があります。必要なのは、すべての関係者、つまり、システムアーキテクト、ソフトウェア・エンジニア、設計者、検証スペシャリストがプロジェクトをリアルタイムで可視化できる共通のプラットフォームと環境です。単に検証プランに対してだけでなく、時間とともに変更されることの多い仕様と設計に対してもリアルタイムでの可視化が必要です。IC設計プロジェクトには、プロセス、ツール、データといった3つの側面があります。検証マネジメントに包括的にアプローチするには、それらすべてに対応することが求められます。	機能検証
	「ソフトICE」-ソフトモデル・ソリューションとしてのiSolve USB ペリフェラルメンター・グラフィックスのiSolve USBペリフェラルは、ハードディスクドライブ、フラッシュドライブ、USBメモリなどのUSBペリフェラル・マスストレージ・デバイスと通信するUSB 2.0 ホスト・コントローラ・ポートを含むSoC（System-on-Chip）設計を、システムレベルで検証するための高速ソリューションを提供します。静的ICE（インサーキット・エミュレーション）ソリューションとして知られる現在のソリューションは、Veloceハードウェア・エミュレータに専用ハードウェア・ユニットを接続して使用し、Veloceから供給されるクロッキングにしたがって動作します。本稿では、静的ICEソリューションの代わりにソフトモデルを使用して同じ機能を提供する新たなアプローチについて取り上げます。ソフトモデルは、Veloce内の合成されたRTLコード、標準のVeloceホストワークステーションで稼働する実行可能なソフトウェアから構成されています。ここでは、このアプローチの相対的なメリット、ハードウェア／ソフトウェアの可視性の向上、全体的な使用の柔軟性について説明します。	エミュレーション・システム
	プロセッサドリブン検証によるマルチプロセッサ同期のリスク軽減マルチプロセッサ同期手法は、シングル・プロセッサのマルチスレッドで確立されたソフトウェアベースの同期手法を拡張したものです。こうしたマルチプロセッサ同期手法を実現するには、ハードウェア・ロジックとプロセッサ命令ロジックに対する高度な並列性に対する可視性が欠かせません。マルチプロセッサ同期のハードウェア・ロジックとプロセッサ命令ロジックを検証する際のリスクは、プロセッサドリブン検証手法とそのサポート・ツールを利用すると、最も効果的に軽減できます。検証でのスティミュラスは、システムレベル・テストベンチ上でプロセッサから発生させる必要があります。また、マルチプロセッサを使用した設計内のハードウェアやすべてのプロセッサのステートに対する並列可視性を提供できる非侵入型（デバッグ・ツールを使うことにより対象の状態を変えることのないという意味）のデバッグ・ツールが必要です。	機能検証
	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で開発されたシーケンスのシミュレーション性能を比較します。	機能検証
	OVMコンフィギュレーションとバーチャル・インタフェース本稿では、OVMテストベンチの構成方法（コンフィギュレーション設定）およびテストとDUTの通信方法について説明します。ここでいうテストベンチの構成方法とは、テストベンチの構造と動作に影響を及ぼす値のコンフィギュレーション設定を意味します。このような値の設定は、単一の場所（テスト）からの設定が理想であり、これによりコンフィギュレーション値を設定している箇所の特定や再構成が容易になります。	機能検証
	SCE-MI 2 に基づくアクセラレーション対応のOVMメソドロジ Open Verification Methodology（OVM）は構造化手法を用いて、相互運用可能かつ再利用可能な検証コンポーネントを記述するためのオープンソースのメソドロジです。本稿では、トランザクションベースのアクセラレーションをサポートするための、OVMに対するメソドロジ上のアップデートを提案します。このメソドロジは、強く求められている高い効率の処理実行をSCE-MI 2.0ベースのコ・エミュレーション・モデリングの技術を用いて実現し、OVMテストベンチのトランザクションベース検証を可能にするものです。	エミュレーション・システム
	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ものスレッドに参加しています。	機能検証
	RTOSアプリケーション・コードを使ったハードウェア／ソフトウェア協調検証ハード／ソフト協調検証は一般的に抽象度の低いレベルで行なわれ、デザインの他の部分のVerilogまたはVHDLモデルとともにCPUの命令セットシミュレーション(ISS)モデルが使われます。この論文では、ソフトウェアの抽象度のより高いレベルについて述べています。CPUのサブシステムは、 RTOSシミュレータやRTOSのApplication Programmers Interface(API)に書かれたアプリケーション・コードに置き換わるでしょう。VerilogあるいはVHDLはその他の部分のデザインのモデルとしてまだ使われます。	機能検証
	SystemCを使った設計および検証 SystemCはモデリングと検証に使うことができます。SystemCはシミュレーション・パフォーマンスを上げ、ソフトウェア開発と同じ実行プラットフォームを使い、システム全体を検証します。この包括的な論文には多くの画像と用語集およびコード付属書が含まれています。	機能検証
	SystemVerilogによる簡潔で明瞭なデザイン記述 SystemVerilog は多くのユーザに利用されている Verilog 言語（IEEE 1364-2001）に対する次世代への拡張です。SystemVerilog の開発は、Accellera (設計言語やライブラリ・フォーマットなどの標準化・普及推進団体) の下でここ数年の間に行われました。Design Automation Conference (DAC) 2002 において承認されたバージョン 3.0 は、合成可能なデザインを記述する方法を拡張することに主眼がおかれました。DAC 2003 においてバージョン 3.1 が承認され、ここでは検証を目的とした拡張が追加されました。DAC 2004 において、さらに拡張されたバージョン 3.1a が標準化のために IEEE へ公式に移譲されました。メンター・グラフィックスでもスケーラブル検証ソリューションを担う技術として SystemVerilog のサポートを積極的に推進しています。この資料では、デザインを効率的に記述する方法について解説いたします。	機能検証
	TBX - トランザクションベースのアクセラレータメンター・グラフィックスのトランザクションベース・アクセラレータであるVeloce® TestBench Xpress（TBX）を使用すると、ユーザは高位の抽象度における検証メソドロジを開発することが可能になります。テスト・アプリケーションを開発する言語としてC、C++、SystemC、そしてSystemVerilogが使用可能です。これらの言語は、業界で確立しつつあるOVMやTLM標準など共に使用され、非常に柔軟なトランザクションベースのテストベンチ・メソドロジとして広まっています。TBXはこれらの標準との互換性を持つことにより、ソフトウェアベースのシミュレータと共に使用されます。標準ベースのTBX通信インタフェースおよびXRTLモデリング・サブセットは、SystemVerilog言語に対して互換性かつ再利用性があります。つまり本稿に示すガイドラインに従うことにより、まったく同じソースモデル（テストベンチ、DUT、トランザクタ）を、ネイティブなソフトウェア・シミュレータおよびVeloce TBXを用いたアクセラレーションの両方で使用することが可能になります。	エミュレーション・システム
	アサーションは足りていますか? 機能的な意図や設計実装の正しさについて、定義を形式的に入力した「アサーション」が検証をより確実にする手段として検証プロセスに取り入れられるようになってきました。設計検証言語SystemVerilogは、検証の一部としてアサーションをカバーしています。現在、必要なアサーションの欠落を検出する方法としてアサーション密度というメトリクス（指標）が提案されています。これまでは、コード数に対するアサーション数を測定するAPLOC(Assertions PerLines Of Code)が用いられていましたが、APLOC数は現実を正しく表すとは言えません。DUTの論理構造に基づくアサーション密度の測定手法の方が、より現実的と言えます。ここでは、レジスタが論理回路の状態を保持する要素として、レジスタからレジスタまで、あるいはレジスタからアサーションまでの距離を用いた最小レジスタ距離をMSD(Minimum Sequential Distance)として、アサーション密度の測定基準とすることを提案しています。このMSDが特定の数値を超えた場合、アサーション密度が欠落していると判断するものです。	機能検証
	インテリジェント･テストベンチの自動化: 約束から現実解へ機能検証ツール「Questa®」と、インテリジェント・テストベンチ自動化ツール「inFact™」を組み合わせると、少人数の設計チームでも、従来の制約付きランダム・テスト手法よりも短時間かつ少ないリソースで、SoC設計をフルに検証できるようになります。この論文で紹介するI2Cコントローラ回路のテストは、APBバス・インタフェース、プロセッサへのIRQインタフェース、DMAコントローラ・インタフェース、I2Cバス・インタフェースの4つのインタフェースを含んでいます。従来の制約付きランダム・テストでは66万回のテストが必要であったのに対して、inFactでは6万回のテストで済みました。inFactでは、ルール・グラフを作成し、その上を繰り返し移動し、固有のケースがすべて試されるまでテスト・プログラムが生成されるので、カバレッジ到達時間が短くなります。複数のアルゴリズムを利用して、インテリジェントなテスト・シーケンスを生成してシミュレーションをしています。もちろんランダム・テストもこのアルゴリズムの1つです。	機能検証
	シナリオ・ベース・スティミュラス生成の概要スティミュラス生成のニーズはますます多様化していますが、検証のスティミュラスを複雑にする要因は様々で、高機能のIPをデザインに使用している、ハードウェア機能とソフトウェアの高度なレベルでの通信が必要、バス・プロトコルが非常に複雑、検証環境の大部分を再利用したい、などが例として挙げられます。その結果、スティミュラス生成には次のような新しいニーズが生まれています。実行形態(シリアル/パラレル)を制御できるスティミュラス・モジュールの作成スティミュラス生成と実際のテストベンチの分離単一プロトコル生成におけるスティミュラスのレイヤ化。レイヤ化スティミュラスを単一プロトコルにカプセル化。一例はEOS（Ethernet over SONET）スティミュラス生成と検証IPコンポーネントを一緒にパッケージ化レイヤ化スティミュラスはOVMのパッケージとして実装されているため、シナリオを利用して上記のスティミュラス生成のニーズに対応することが可能です。シナリオは、ビルディング・ブロック方式で検証スティミュラスの複雑なニーズに対応するものです。シナリオの作成、共用、再利用によって従来のテスト作成方法に比べてモジュール化が著しく進み、手間をかけずに必要なスティミュラスを生成できるようになりました。ここではシナリオの概要と、OVMでシナリオを利用する場合に必要なコードをすべて説明します。	機能検証
	マルチコア・デザインにおける同期障害のデバッグマルチコア・プロセッサ・システムでは、互いに独立しているコア間の同期に起因する問題が多くなります。そこで、個々の問題を切り分ける能力が解決のキーポイントとなってきます。共有メモリが壊れたり、スレッドの順番が崩れメッセージが届かないといった問題が起きたり、同時に走っているスレッドがお互いに見合っているうちにロックしないままデッドロック状態に陥ってしまったり---というようなことがしばしば発生します。メンター・グラフィックスは統合マルチコア・コード・デバッガQuesta Codelinkを提供しています。これは、システム内の各コアに使うソース、変数、メモリなどを表示でき、システム内で何が発生しているかを的確に知ることができます。Questaを使って、こういった状態を表示することでシミュレーションの再生に、それまで十数時間かかっていた処理を数秒で済ませることが可能になりました。さらに、インタラクティブにデバッグできるうえ、RTLプロセッサ・モデル上で実行するコードもデバッグできます。現時点ではARMコアやMIPSコアを中心にサポートしています。	機能検証
	マルチプロセッサ・ベース設計の効率的検証を目的としたハードウェア支援検証システム・オン・チップ（SoC）におけるマルチプロセッサの活用は、シングルプロセッサ・ソリューションの性能と帯域幅が限界に達したことにより、ますます増大しています。このような背景から、マルチプロセッサ環境の検証における課題も顕在化し、効率的な検証ソリューションの必要性が生じています。本稿では、マルチプロセッサのSoC検証に向けた正確かつ高性能なソリューションを提供する、ハードウェア支援検証の活用について説明します。	エミュレーション・システム
	メカトロニクス・アプリケーションにおけるFPGAの設計と検証オートモーティブにおけるFPGAの適用が注目を浴びています。FPGAを自動車に応用するに当たり、まず設計手法の確立が最大の問題となります。この分野ではフィードバック制御が重要視され、センサー、アナログ／デジタル回路、アクチュエーターといった、一連の制御ループをFPGAを使って設計することになります。特に、デジタルではない部分の設計が問題です。時間連続性、微分方程式、台数方程式、伝達関数、物理学、アナログ回路モデルSPICE、統計分布などをどう表現して設計に取り込めばよいのでしょうか。ここでメンター・グラフィックスが提案するのは、VHDLを拡張した「VHDL-AMS言語」です。この言語を用いれば、どのようなモデルでも非線形微分方程式や台数方程式で表現することが可能となります。VHDL- AMSは、FPGA設計者にはまだ馴染みのない言語ですが、デジタル以外のコンテキストにおける条件定義や、その検証には強力なツールとなるでしょう。	機能検証
	メタスタビリティ効果のもれがなく正確なシミュレーション・モデル作成方法低消費電力化に伴うクロック・ゲーティングや、設計資産の再利用、様々な周波数で規定されている標準規格への対応など、最近のASIC/SOC設計では複数のクロックによる非同期設計が当たり前になっています。異なるクロックドメイン間でのデータ転送を確実に行うために、受信側の同期化回路挿入や送信側のプロトコル厳守、グレイコード・エンコーディングなどの対策が取られていますが、それでもメタスタビリティは発生してしまいます。この論文は「メタスタビリティ効果のもれがなく正確なシミュレーション・モデル作成方法」と題して、メンター・グラフィックスのRoger Sabbagh氏および富士通研究所の岩下様の共著によるもので、2008年のDVCon(Design and Verification Conference)で取り上げられました。皆様の設計・検証にも非常に参考になると思われる論文であるため、日本語化いたしました。是非ともご一読いただきたいと思います。	機能検証
	今日の複雑なクロック・モデリングの問題に対するVeloce技術によるソリューション現在のデザインに比べて以前のデザインは、より小規模かつシンプルで、クロック構成も単純でした。数年前の検証ははるかに容易で、クロックのモデリングがそれほど大きな問題になることはありませんでした。ところがシステム・オン･チップ（SoC）適用範囲の急激な拡大と共に、考慮すべきペリフェラルや外部インタフェースの数と種類も増大し、今日のデザインは非常に複雑なものとなり、多数の非同期クロックに対処する必要が生じています。非同期クロックの増加原因は、SoCにおけるペリフェラル・インタフェースの種類増加にあります。一般的に、それぞれのペリフェラルでは他のクロックに対して非同期な独自のクロックが使用されています。設計者がこれらのペリフェラル用クロックを制御する手段はあまりありません。SoCは様々な用途で利用されます。複数のアプリケーションに対応する柔軟なチップは、単一用途のチップに比べ、多くのインタフェースを持っています。非同期クロックによりペリフェラルIPの再利用や省電力ステートの実装も可能となりますが、これは設計チームや検証チームに新たな検証課題をもたらすものです。従来まで最善とされていた技術およびソフトウェア・ツールが活かせるのは、同期設計によるデザインと、多くとも2つの非同期クロックによるデザインまでです。デザインが更に複雑になり、クロック・ドメインが3種類以上になると、エミュレーションは不可欠になります。このホワイトペーパーではユーザによる適切な検証ツール選択を可能とするために、異なる種類のエミュレータと様々なシチュエーションについて説明します。	エミュレーション・システム
	戦略的なシステム検証を実現するスケーラブルな検証アプローチ SoC設計の課題を克服しその恩恵を得るために、エンジニア・チームは設計サイクルのあらゆる面に対応し、LSI製造能力と検証能力の間に生じる「検証ギャップ」を埋める新しい検証戦略を必要としています。この論文では、Scalable Verificationや設計の抽象度、アサーション・ベース技術、そして改善されたデバッグ手法がいかに設計チームが直面している根本的な課題に対処しているかを検討しています。	機能検証
	既存フローへのフォーマル機能検証の統合 Harry D. Foster（以下Foster）によるホワイトペーパー「Integrating Functional Formal Verification Into Your Flow」の日本語版「既存フローへのフォーマル機能検証の統合」が完成いたしましたのでご案内いたします。	機能検証
	組込みシステムにおける設計／検証の最適化どんな複雑なSoC設計も、設計の統合に至る前に数回の設計のやり直しが必要です。しかし、現在のデザインの入力、検証、解析および修正サイクルは時間がかかりすぎます。製品を適切な時期に市場に出すためにしばしば、チップが設計仕様を満たすように完全に検証する前に設計を切りあげることになります。優れたハード／ソフト設計と検証の環境は、機能上とファームウェアの両方の問題を見つけ、シリコンに落とす前に設計を統合することを支援します。この論文では、今日のSoC設計のこのような課題を議論し、チップやシステムの仕様を満たすために必要なデザインの入力、検証、解析および修正のタスクに対応するハード／ソフトの設計と検証の環境を提供します。	機能検証

英文技術文献のダウンロードはこちらから

機能検証

機能検証関連情報

技術文献