イタレーション：スケジュール遅れの元凶 -...
TRANSCRIPT
17
イタレーション：スケジュール遅れの元凶
正式なRTLサインオフ・プロセスの導入
IPにはシノプシス、ARM®社、Imagination Technologies社、CEVA®社などのベンダから提供される商用のサードパーティ・ブロックもありますが、圧倒的に多いのはターゲット・アプリケーションに合わせて開発した専用ブロックや旧世代の製品からの再利用IPなど、チップ・メーカーが内製したIPです。
より高度なシステム統合を可能にするには、先端テクノロジ・ノードへの移行が必要です。しかしチップ寸法を縮小すればムーアの法則の恩恵をすべて受けることができる一方、設計とインプリメンテーションの複雑さが増し、設計スケジュールの面では深刻なリスクと課題に直面します（図2）。
どのようなデザインも、設計過程のどこかで必ずイタレーション（反復）が発生します。イタレーションの一般的な原因としては、新規に調達したIPの問題、既存IPのバグ、IPの使用方法の誤り、消費電力 / パフォーマンス / コストが仕様を満たしていない、などがあります。
プロジェクトのある特定の工程内で完結するイタレーション（ショート・ループ）は比較的容易に対処できます。一般的なプロジェクトでは各工程で複数のショート・ループが発生することがありますが、1つのループは通常1～2日で解決できるため、スケジュールにはそれほど大きく影響しません。
しかしデザインの異なる抽象度にまたがって発生するミドル・ループやロング・ループとなると、下流工程で見つかったバグをRTLで修正することになるため、対処ははるかに困難です。バックエンドの配置配線で見つかったバグを
フロントエンドで修正するといったイタレーションは、1回につき数週間ものスケジュールの遅れを招きます（図3）。設計スケジュールの終盤になってバグが見つかった場合、修正には想定外のロング・ループが必要となり、数ヶ月から1年の遅れが生じることも珍しくありません。
バグの修正は、設計サイクルの終盤になるほど設計コストの上昇を招きます。インプリメンテーション工程でバグを見つけて修正した場合、仕様定義の段階でのバグ修正に比べ20倍のコストがかかり、RTL設計段階でのバグ修正と比べても10倍のコストがかかります。
設計コストの上昇だけでなく、設計の遅れは甚大な収益損失も招きます。製品投入の遅れによる売上の減少、そしてエンジニアが次のプロジェクトに着手できないという機会損失を考えると、12ヶ月の遅れはプロジェクトの商業的な失敗を意味します。
デザインに対して正式なサインオフを実施するという考え方は、設計フローのバックエンドでは定着しています。これ以外に、何らかの形でRTLサインオフを採用している設計チームもあります。通常、これはRTLが機能検証に合格したことをもってサインオフとするというものです。しかしこのアプローチではRTL構造やインプリメンテーションの容易性まで考慮されません。
正式なRTLサインオフ・プロセス（図4）には、設計フローの次の工程に進む前にRTLが必ず合格しておかなければならない要件をすべて含めておく必要が
図4. RTLサインオフを取り入れた設計フロー
図3. スケジュール遅れの元凶となるイタレーション
新規IP 既存IP サードパーティIP
IPのRTLサインオフ
IP統合
SoCのRTLサインオフ
インプリメンテーション（合成、配置配線）
検証
設計の手間
新規IP 既存IP サードパーティIP
IP統合
インプリメンテーション（合成、配置配線）
検証
設計の手間
ミドル・ループ
ロング・ループ
ショート・ループ
S
upport Q&
A検
証編
Support Q
&A
フィ
ジカ
ル編
Support Q
&A
論理
合成
編N
ews R
eleaseニ
ュー
スリ
リー
スW
hat's New
in DesignW
are IP?
I ndustry TrendTechnology U
pdate最
新技
術情
報S
uccess Story
新年
のご
挨拶
前ページより続く
18
SoC設計のイタレーション長期化を解消するRTLサインオフTechnology Update
Verification Continuumの一角を占めるSpyGlass
まとめ
シノプシスのRTLサインオフ・ソリューションSpyGlass
あります。その狙いは、設計フローの下流工程にバグを持ち込むリスクを最小限に抑えることにあります。
RTLサインオフ・プロセスは、設計の不具合を早期に発見して修正するための切り札となります。これにより設計の手間とリスクが抑えられ、プロセスの予測性と収束性が向上します。
シノプシスのRTLサインオフ・ソリューションSpyGlassは、バグを最小限に抑えた、より高品質なIPの作成と統合を支援します。SpyGlassはRTLの構造の正しさ、およびインプリメンテーションに最適化されているかどうかをチェックし、機能検証ソリューションを補完する役割を果たします（図5）。
SpyGlassは、RTL合成前に使用します。SpyGlassからはすぐにフィードバックが得られるため、RTL設計の段階で問題点を見つけて修正できます。これにより、下流工程でバグが顕在化してその修正に大きな手間とコストが発生するのを防ぎます。
SpyGlassはスタティックおよびフォーマル解析を利用して、DFT、消費電力、パワー・インテント、制約、フィジカル・インプリメンテーションの容易さなど、RTL構造の潜在的な問題点をさまざまな面からチェックします（図5）。
SpyGlassには構造的および機能的なCDC（クロック・ドメイン・クロッシング）の問題に対処する機能もあります。現在のSoCには数十、場合によっては数百もの非同期クロック・ドメインが存在しており、従来のシミュレーション
やスタティックタイミング解析（STA）を使ってこれらを検証するのは非常に困難です。このため、現在ではCDCが設計エラーの最大の要因の1つになっています。SpyGlassは容易にセットアップでき、デザインからクロック、ドメイン、リセットを自動で抽出してくれます。
擬似エラーを減らすため、SpyGlassには幅広い種類の同期回路を認識し、準静的信号を自動で検出する機能があります。階層型SoCフローでSpyGlassを使用してIPベースの設計メソドロジをサポートすると、非常に大規模なSoCでも短TAT化を実現できます。
SpyGlassは簡単に導入して利用できます。チーム内のRTL設計専門家がSpyGlassを使用してベスト・プラクティスをコーディングしておけば、他のチームもそのコーディング・ガイドラインに従うことができ、効果的な知識移転を実現できます。このアプローチにより設計者の効率と生産性が向上します。
SpyG l a s sは、シノプシスの包括的な検証プラットフォームであるVerification Continuumを構成する要素の1つとして最近追加されました。Verification Continuumプラットフォームには、バーチャル / FPGAベース・プロトタイピング、スタティック / フォーマル検証、シミュレーション / エミュレーション、プランニング、デバッグなど、多くの製品とテクノロジが含まれます。RTLサインオフ・ソリューションのSpyGlassを用いると設計工程でRTLの品質向上を図ることができるため、デバッグ、シミュレーション、検証用IPといった既存のテクノロジ資産をより効果的に活用できます。
正式なRTLサインオフ・プロセスを導入することで、設計チームは複数の抽象度をまたいだイタレーションのリスクを減らすことができ、スケジュール遅れの最大の要因を取り除くことができます。
RTLサインオフ・プロセスにはスタティック解析の機能が含まれるため、既存の機能検証を補完する役割も果たします。
SpyGlassを利用して正式なRTLサインオフ・プロセスを導入すると、設計リスクを軽減しながらデザインの品質を高めることができます。RTLの品質が向上することで下流ツールの結果品質も向上し、より早期でのデザイン・クロージャが可能になります。
以前ならシリコン実装後にバグが顕在化して完全なリスピンが必要となったような不具合も、RTLサインオフを導入すれば早期に発見できることが実証されています。
詳細情報● ウェブページ：SpyGlass http://www.synopsys.com/JP2/Tools/Verification/SpyGlass● ウェブページ：Verification Continuum http://www.synopsys.com/JP2/solutions/verification-continuum
著者紹介Piyush Sancheti：シノプシス、ベリフィケーション・マーケティング担当シニア・ディレクタ。マーケティング、セールス、ビジネス開発、エンジニアリング分野で20年以上の経験を持つ。これまで、Atrenta社、Cadence® Design Systems社、Sente社、Sequence Design社で上級職を務める。アイオワ州立大学にて計算機工学の修士号、インドール大学（インド）にて電子 / 電気通信工学の学士号を取得。
図5. RTLサインオフ ソリューションSpyGlass
SpyGlassによるRTLサインオフ
リント
クロック / リセット検証
消費電力推定 / 削減
パワー・インテント検証
タイミング制約検証
DFT（Design-For-Test）