改めて探る、IPベース設計の課題：SoC設計の抽象化は実現できたのか？（2/3 ページ）

[Ron Wilson，EDN]

ブロック間のインターフェース

　IPブロックの端子を明確に定義する業界標準が存在しない場合には、（1）インターフェースの定義を抽出すること、（2）それを設計要件に変換すること、（3）ブロック同士が正しく接続されているかどうかを検証すること、が重要となる。現在、これらの作業はほとんど手作業をベースとして行われている。

　IP化されたインターフェースが標準に準拠したものであるならば、その仕様は容易に理解できる。そして、そのインターフェースがVIPによる検証に合格すれば、そのままブラックボックスとして設計に使用することができるはずだ。実際、そうした作業を行うためのFPGA用開発ツールも存在する。そうしたツールでは、システム構築において、IPブロックを標準バス上に組み合わせ、ソフトウエア開発者向けのレジスタマップとドライバライブラリを作成するという作業を行うことになる。

　EDAの標準化団体である米AccelleraのIP-XACT規格は、SoCに関して、より積極的とも言える手法を採用している。自動化ツールが、設計要件に基づいてIPの候補を特定し、SoCの構築に必要なインターフェースコードを作成できるように、IPブロックの機能と動作（インターフェースの動作）に関する情報を、XML（Extensible Markup Language）ベースの標準化された形式でコード化するというものである（別掲記事『IP-XACTへの期待と課題』を参照）。オランダPhilips Semiconductors社（現在のNXP Semiconductors社）のある研究チームは、このようなXMLによる記述を扱う、システム構築用の自動化ツールの開発に取り組んでいた。だが、NXP社が社内のSoC設計チームを売却した際に、この取り組みをほぼ廃止してしまったようである。

　IP-XACTの構想は、優れたものであるように感じられる。しかし、例のごとく、問題は細かい部分に潜んでいる。Open-Silicon社のMadraswala氏は、「残念ながら、標準インターフェースについてでさえも、誰もが命名規則にすら従っているとは限らない」と述べる。そのため、端子を接続するにはさらなる検証や設計が必要かもしれない。昔からスムーズな設計作業を妨げる要因となっている極性については、特にそうだと言えるだろう。また、標準インターフェース用のものであるからといって、テストベンチを無条件に信頼するわけにはいかない。

　PMC-Sierra社のWagner氏は、「ブロックの実使用の状態を適切に反映した入力信号や、適切なモニター機能を作成/適用することができないのであれば、インサーキットエミュレータを使用しても、インターフェースIPのタイミングを完全に確認するのは難しいかもしれない」と述べる。同氏の指摘は、ある規格に厳格に準拠している場合にも当てはまる。また、オーバークロッキングやサイドバンドシグナリングなど、標準的な使用条件の範囲を超えた動作に対しては、カスタムのテストベンチの構築が必須である。さらにWagner氏は、技術者に対し、テストベンチのカバレッジと性能を上げるように助言している。その上で、「静的/動的なアサーションがあれば理想的だ」（Wagner氏）と付け加えた。

　アサーションは、デリケートな問題を抱えている。多くのSoC開発チームがアサーションベース検証を採用するようになっているが、ある非公式な調査によると、IPとともにアサーションを提供する動きはそれほど活発ではないという。そのため、SoCの開発チームは、IPに対して自力でアサーションを作成しなければならず、それにはデータシートを慎重に確認するとともに、おそらくはRTLのコードを調べることが必要になる。

　ただし、この点については、EDA業界から明るいニュースがもたらされている。新興企業の米Zocalo Tech社と米NextOp Software社が、アサーションの作成を支援するツールを発表したのである。Zocalo社のツールは、アサーションの適用が適切だと思われる信号を特定してくれる。NextOp社のツールは、それよりももう一歩踏み込んで、アサーションを合成するものとなっている。両ツールが、ブラックボックスとしてのサードパーティ製IPに対し、どの程度有効であるかについては今後の調査が必要だ。

　あまり理想的ではない状況として、IPブロックのポートが、明確に定義された規格に従っていないケースが挙げられる。このような場合には、独自のアサーションを作成するときと同様に、設計者がデータシートを熟読しなくてはならない。Wagner氏は、「データシートに記載されているIPの仕様に基づいて、インターフェースのセマンティクスを解析する必要がある」と述べる。だが、ポートが複雑な場合、当然のことながらこうした作業は誤りの生じやすいものとなる。まずは、IPブロックのポートの動作を理解しなくてはならない。また、ポートをSoCの設計と結合させる作業も必要になる。これには、FIFO（First-in/First-out）バッファやプロトコルの変換回路といったロジック設計が必要になるだろう。だが、このようなインターフェースを生成できる合成ツールは存在しない。

　理想的には、IPブロックを組み合わせてSoCを構築する際に、IPブロックのテストベンチがSoC用の検証スイートの一部となり、ブロックの境界をまたがるトランザクション用の入力やアサーションを生成できることが望ましい。しかし、現状ではこのようなVIPの再利用も手作業であり、自動化が望まれる領域となっている。

IP-XACTへの期待と課題　　Scott Wolf Xilinx社

　筆者が所属する米Xilinx社は、顧客によるIPの利用/再利用をより適切に支援することや、IPパートナーに一貫性を提供すること、社内の効率を向上させることを目的として、AccelleraのIP-XACTを採用しようとしている。IP-XACTは標準化された規格であり、多くの独立系IP企業がこれを採用している。当社がこの規格を採用すれば、当社のIPエコシステムでは、当社の開発ツールと互換性のあるIPを容易に提供できるようになり、IPについてより多くの選択肢を顧客に対して与えられることになる。

　当社は、IPやソフトウエアツールを段階的にIP-XACTに対応するよう変更していく予定だ。最初のフェーズでは、「Xilinx CORE Generator System」に重点を置いてロジックベースのIPとツールをサポートすることを考えている。Xilinx CORE Generator Systemは、当社の開発環境「ISE Design Suite」に含まれているもので、顧客に対し、アーキテクチャやドメイン、市場に特化したIPを提供する。IP-XACTを使用することで、IP固有の情報を標準化された規格にのっとった形で表現することができる。その情報を活用するためには、当社のIPをIP-XACTに対応したものとするだけでなく、ソフトウエアツールもIP-XACTをサポートできるものに変更する必要がある。当社は、サポートツールやソフトウエアのライブラリのほか、IP-XACTを採用したプロセスを構築できるようにするために、かなりのリソースを割いている。

　IPとツールにIP-XACTの実装が進むに連れて、当社は課題に直面した。例えば、IP-XACTの仕様の解釈に関していくつかの決断を下さなければならなかった。そうした事柄の中には、要件を満たすための設計環境が具体的に指定されていたものもあれば、情報をモデル化するための手法がIP-XACTに複数存在するものもあった。

　もう1つの課題は、ベンダーによる拡張機能の使用に関するものである。IPについての情報を記述するIP-XACTファイルは、その情報を集中的に管理するには便利なものだが、このデータを管理するために拡張機能を利用するのか否かを適切に判断しなくてはならない。

　拡張機能の使用や仕様の解釈について決断を下さなければならないということは、ほかのIPやソフトウエアツールとの互換性を損なう危険性があるということを意味している。このような危険性の存在は、相互運用性という目標に相反するものだ。

　ともあれ、IP-XACTがIEEE 1685として承認されたことは、大きな前進である。IP-XACTの進化に伴い、業界で同規格の採用がさらに加速することを期待したい。