技術文献

その他の技術文献

次世代のパワーアウェアCDC検証: 新たに明らかになったこと

Posted in: 機能検証

本稿では、ローパワー設計のCDC(クロックドメインクロッシング)パス検証で現在用いられている手法について説明します。その後、ローパワー設計で発生している最新の問題と、そうした問題を検証する手法について解説します。最後に、最新世代のUPF(Unified Power Format)であるUPF 2.0とUPF 2.1の登場により、CDC設計手法や検証手法がどのように進化しているのかについて議論します。

Download

ハードウェア/ソフトウェア検証の生産性を大幅に改善
Verification Horizons

Posted in: 機能検証

今日では、1つまたは複数の組込みプロセッサを含む複雑な設計が増えてきました。設計機能全体に占めるソフトウェアの役割が拡大していることを考えると、ハードウェアとソフトウェアの相互作用をシステムレベルで検証するために組込みプロセッサを活用することがますます重要になっています。検証プロセスの早い段階でハードウェアとソフトウェアの相互作用を低い抽象度で包括的に検証することで、OSあるいはアプリケーションをラボで立ち上げるまで発見できないであろうバグを見つけやすくなります。検証サイクルの早期にこうしたバグを特定、分類、デバッグ、修正できれば、コストも時間もかかりません。

Download

Verification Academy: UVM基本編
Webセミナー資料

Posted in: 機能検証

Verification Academyへようこそ。
「UVM基本編」では、全8回のセッションでUVMの基礎について学んでいただきます。

Download

パワー・アウェア設計のスタティック・フォーマル検証: UPFベースのRTL検証

Posted in: 機能検証

UPF(Unified Power Format)はローパワー仕様の標準規格であり、アイソレーション・セルとレベル・シフタの挿入をRTL(レジスタ転送レベル)で明示的に定義します。本稿ではRudra Mukherjeeら執筆者が、マルチ電圧設計内でバグの発生しやすい箇所を特定する方法について解説します。設計者はUPFに基づいて、パワードメイン、システム・パワー・ステート、スイッチといったパワー・マネジメント機能の仕様を含むローパワー設計意図を定義します。この情報を検証ツールに取り込むと、通常のシミュレーション・データでは検出困難だったパワードメイン/ボルテージドメインのクロッシングに対して、スタティックなリント・チェックが実行できます。本稿では、ツールを使ってフォーマル検証を自動化し、設計者の負担を軽減する方法についても紹介します。この方法ではアサーションを自動生成することによって、パワー・コントロールのシーケンスをテストしたり、スリープ・モードへの不正遷移がないかどうかをチェックするほか、リテンション・コントロール(セーブ、リストアなど)ならびに設計コントロール(クロック、セット、リセットなど)の競合状態を検出します。

Download

検証マネジメントによるプロセス改革と導入事例
Webセミナー資料

Posted in: 機能検証

最新の機能検証手法の導入により、大規模化/複雑化する半導体の検証に一定の効果が上がっているように見受けられます。機能検証の質を上げるにはカバレッジを上げること、機能検証のコストを下げるにはカバレッジ達成の時間短縮や効果的なプロセスが重要となっています。

この資料では、機能検証において最重要項目とされるカバレッジの一元化と管理によるプロセス改革についてご説明します。

Download

スプレッドシートでは対応しきれなくなったら

Posted in: 機能検証

2011年、イタリアのアグラテ(ミラノ近郊)にあるSTマイクロエレクトロニクスの工場で32ビット・マイクロコントローラの組込みソフトウェアを書いているエンジニアは、メンター・グラフィックスの要求仕様追跡ツールのReqTracerを使うことを考え始めていました。マイクロコントローラの製作にとって欠陥ゼロという顧客の期待に沿うことがますます重要になっており、それに応えるためには最初の見積もり依頼から開発サイクルのすべてにわたって要求仕様を追跡し続けなければなりません。ReqTracerを採用する以前のハードウェア・エンジニアはExcelとカスタムスクリプトに大きく依存していたため、顧客とコミュニケーションを取ったり、自動車業界における暗黙の要求仕様に応えたりするうえで欠かせない、追跡マトリックスの作成と影響分析をしていましたが、そこには限界があり、簡単ではありませんでした。マイクロコントローラのソフトウェアを書くにあたって要求仕様を追跡し続けることは、少なくともハードウェア設計と同じくらいやっかいな仕事です。その理由の1つとして、Automotive SPICEや最近ではISO26262といった標準規格に適合しなければならないことが挙げられます。しかし、たとえ、もっぱら手作業に頼る使いにくい方法でも、すでに要求仕様の追跡に何らかの使い慣れた方法を持っている25 人のエンジニアで構成されるチームの作業手順はそう簡単には変えられません。結局、ソフトウェア設計チームは小さなパイロットプロジェクトでそのツールを試してみることにしました。そして、すぐに、多くの要求仕様が単純にソースコードにまで正しく反映されていないということに気づきました。

Download