メディア

改めて探る、IPベース設計の課題SoC設計の抽象化は実現できたのか?(3/3 ページ)

» 2010年12月01日 00時04分 公開
[Ron Wilson,EDN]
前のページへ 1|2|3       

IPの集積における問題点

 IPブロックの機能や、IPブロック間のインターフェース以外にも、IPの集積に関する問題は存在する。その1つが電源管理である。現在は、スタティック/ダイナミック消費電力をチップレベルで削減するために多種多様な手法が用いられている。まず、デバイスレベルの手法としては、閾(しきい)値電圧が異なるトランジスタを選択したり、閾値を変更できるようにバックバイアスを調整可能なトランジスタを選択したりするというものがある。ほかにも、シグナルゲーティングや細粒度クロックゲーティングなどの回路レベルの手法や、疎粒度クロックゲーティング、電圧アイランド、DVFS(動的電圧周波数スケーリング)、パワーゲーティングといったブロックレベルの手法がある。IPを集積する上での問題は、チップレベルにおける電源管理の手法を、いかにIP設計者が仮定している前提に合わせて調整できるかにかかっているのである。

 Open-Silicon社のMadraswala氏は、「IPブロックにおける電源管理の条件としては、例えば、そのブロックは自らシャットダウンできるか、独立した電源アイランドは必要か、DVFSが可能かといったことがある。チップ設計者がこうした条件を理解していれば、話が早い」と述べる。チップ設計者は、IPブロックの機能に関してデータシートに記載されたすべての情報を、チップの電源の設計に適用しなければならない。

 プロジェクトが計画から実装の段階に移行すると、今度は別の方向に影響が出てくる可能性がある。Wagner氏は、「ソフトIPでは、一般的に顧客が電源管理の基本方針を決める。そして、IPベンダーまたは顧客が実装を行う」と述べる。IPを使用するそもそもの目的は、チップの設計チームにとっての抽象化のレベルを高めることである。そのため、新しい電源管理の方針を盛り込むためにRTLのコードを変更するというのは、好ましい選択ではない。しかし、時にチップの設計チームは、ブロックの構造を理解することなく、ブロックの消費電力を改善する必要に迫られることがある。

 合成ツールは、チップ設計チームの手を煩わせることなく、シグナルゲーティングやクロックゲーティングといったネットリストレベルの省電力手法を盛り込む機能を備える。Wagner氏は、「設計チームが、中身を熟知していないIPのネットリストを変更する場合には、必ずロジック等価性チェッカーを使用するように」と助言する。

 パワーゲーティングのように、IPの構造を変更する手法を用いる際には、IP開発者の手を積極的に借りるか、SoCチームがリバースエンジニアリングを行うといった対処が必要になるだろう。IPの構造を変更すると、省電力モードをテストするだけのために、テストベンチの変更が必要になる場合もある。設計チームは、ブロック内で削減できるエネルギーの量と、その削減を実現することで犠牲になる抽象度の度合いを天秤にかけ、バランスをとる必要があるだろう。

 スキャンの挿入も、下流工程における自動化された作業の1つだが、これはIPのブラックボックス化に対して何の障害にもならないはずである。ただし、例外は存在する。Madraswala氏は、「高性能なIPのベンダーは、ブロックのスキャンチェーンについて非常に保守的な考えを持つ傾向があり、クリティカルパス上のフリップフロップはスキャンしたがらない」と述べる。

 またMadraswala氏は、「クロックゲーティングの適用も、チップ設計者がIPブロックの内部を詳しく知らなくても実施できる手法だ」と述べる。クロックの構造に関する情報はすべて提供されているはずだし、クロックについての要件はデータシートに記載されているはずである。少なくとも、疎粒度クロックゲーティングを実現するためにクロックを再構成しない限り、IPブロックをブラックボックスのまま扱うことができる。

タイミングクロージャの問題

 IPブロックの中身を見ることなく、タイミングやシグナルインテグリティ、パワーインテグリティに問題がないか、デザインルールを順守しているかといったことを確認し、タイミングクロージャを達成できれば理想的である。IPベンダーは、「ブロックは、指定された周波数における静的タイミング解析に合格するだろうし、シグナルインテグリティにも問題はない。DRC(デザインルールチェック)も完了した状態になる」と主張してきたことだろう。今日のほとんどのIPは、レジスタを介した入出力を使用しているし、ブロックの境界にまたがるタイミングパスは存在しないはずだ。すなわち、階層的にタイミングクロージャを達成することには何の問題もないはずである。

 ただし、IPベンダーのこうした主張は、独自のツールやスクリプト、ライブラリを用いた合成、配置、配線に基づいており、結果は状況によって異なる可能性がある。Wagner氏は、「場合によっては、顧客のスタンダードセルとSRAMのライブラリを使用した場合でも、タイミングを満たすことを確認するためにIPを再合成することもあり得る」と述べる。

 IPブロックをうまくブラックボックスとして扱うことができた場合、設計チームはタイミングクロージャの問題の解決に必要な知識を持っていないことになる。ブラックボックスの整合性を保ったまま問題を解決する方法は、IPの開発者に依頼することだ。IPの開発者であれば、ネットリストや制約ファイルについて理解しているだろう。ただし、新しい電源管理モードをサポートするために変更を加えた場合には、IPの開発者であっても状況を把握できないことになる。そうなれば、IP設計チームとSoC設計チームの連携以外に選択肢はないであろう。

 特に、高度な電源管理を使用する場合には、IPチームとチップ設計チームの密接な連携が必須である。米LSI社のマーケティング担当シニアディレクタを務めるHarmel Sangha氏は、「状況によっては、パワーゲーティングを使用することもある。そのような場合には、担当者同士の連携や定期的なレビューによって意図を伝達する」と語る。

 また、同社で技術マーケティング担当ディレクタを務めるRobert Madge氏は、「設計に携わるのが、毎回同じ人物であると助かる。サードパーティ製のIPを使用する場合には、そのサプライヤにチームに参加してもらう。例えば、サプライヤのIPをわれわれの独自のテストチップに配置して、サプライヤとともに結果を解析するという具合だ」と述べている。


 IPの集積におけるプロセスを重要なステップごとに検証すると、一部のケースにおいては、新しいツールが自動化に貢献していることがわかる。そのほかのケースについては、集積フローの負担を大きく軽減するような新たなツールの登場が期待される。さらに、ブラックボックスとしてのIPの抽象度を維持するためには、IPの開発チームとSoCの開発チームがいかに密接な協力体制を構築できるかも重要なポイントになると言えるだろう。IPの集積を自動化するツールは開発できても、技術者同士の連携を自動化するツールを実現することはできないことを忘れてはならない。

前のページへ 1|2|3       

Copyright © ITmedia, Inc. All Rights Reserved.

RSSフィード

公式SNS

EDN 海外ネットワーク

All material on this site Copyright © ITmedia, Inc. All Rights Reserved.
This site contains articles under license from AspenCore LLC.