構造化アセンブリを始めよう：複雑なSoC設計で導入すべき（2/2 ページ）
日々、複雑化するSoC（System-on-Chip）の設計。そうした中でSoC設計に「構造化アセンブリ」を導入することで、多くの課題を解決、回避できる。そこで、構造化アセンブリについて紹介する。
実装
Arteris IPの IPDプラットフォームは、コマンドライン（CLI）モードまたはGUIモードで使用できます。GUIモードはトレーニング、レビューイング、デバッギングの際にとりわけ役に立ちます。CLIモードはおそらく、プロダクション設計フロー、バッチ作成、リグレッション、ならびに継続的なインテグレーション／デプロイメントで使用されることの方が多いでしょう。本記事ではCLIモードに焦点を当てています。Pythonスクリプトはプラットフォームシェルを起動するCLIコマンドに続く入力として直接供給できます。
スクリプトによって設計のIP-XACTデータベースが作成／修正／更新されます。これらは他の付帯物とともに一つのデータ管理システム内に組み込むことができます。IP-XACTデータベースからは、設計段階に関係なく、Verilog、SystemVerilog、VHDLのいずれかでネットリストを生成できます。このとき、末端までの全てのIPを含んだシミュレーション／実装用ネットリストと、必要なIP設計RTLを組み込むために適切なライブラリオプションを追加するツールコマンドスクリプトが生成されます。
レガシーデータの統合
全てのIPのIP-XACTモデルが存在するわけではありません。一般に、社内で設計されたIPは構造化アセンブリオプションが検討される前に設計されたものです。IPDプラットフォームでは、既存のIPからそれらのモデルを容易に作成するためのインポートオプションが提供されています。
このオプションを使用すればRTLを複数のフォーマットで読み込み、RTLおよび、プロトコルインターフェースの定義を参照しながらIP-XACTモデルを作成することができます。ローカルの命名規則が標準の命名規則と異なる場合もあるため、ローカルポート名と標準プロトコル名のマッピングがユーザーにより定義される可能性を見込み、このステップは通常GUIから実行されます。また、ユーザー定義の信号入力も可能です。このインポートオプションで扱えるのはレガシーIPだけではありません。構造化アセンブリでの派生開発をサポートするためレガシー設計もインポートできるようになっています。図4はこのインポート機能で使用できるオプションを示しています。
大半のIPはシミュレーションのコマンドラインコントロールから始まるため、このステップで各IPに数分以上の時間がかかるのをみて驚かれるかもしれません。設計に変更がない限り、インポートを実行する必要があるのは一度だけです。スクリプトによるでは自動化と変更が見込まれているため、IPの再インポートおよび、アップデート時のやり直しを減らすことができます。IPのレジスタマップといったさらなる情報は後からモデルに追加できます。本件については、別の機会に記事で紹介する予定です。
スケーラブルなSoCアセンブリ
大半の設計チームは、SoCのトップレベルのRTLを直接人手で作成することはもはや実際的ではないという考えに同意するでしょう。問題は、この方法を何に置き換えるべきなのか、ということです。社内製のスクリプトが一つの初期のソリューションでしたが、それらのスクリプトの設計と保守がオーバヘッドの増加を招いていました。それならば広く採用されているIPDプラットフォームを介して統合した方がはるかに良いでしょう。IPDプラットフォームは、開発の強固な基盤となり、自動化されたアセンブリをサポートするアプリケーションが増加する一方で、差別化された自動化のためのスクリプト作成において、設計の創造性を発揮する事ができます。このプラットフォームは、電力、メモリ管理ユニット、安全／セキュリティ管理にまつわる高度な設計アーキテクチャのサポートにおいて真の差別化を実現しています。Arteris IP IPDプラットフォームの詳細についてはこちらをご覧ください。
著者プロフィール
Tim Schneider ／ Arteris IPシニアアプリケーションエンジニア
数々のリーディングカンパニーとともに25年にわたり高性能SoC（system-on-chip）設計の検証に携わる。アナログ設計、論理、フォーマル、ハードウェア／ソフトウェア検証、医療機器産業向けのEdgeベースのAIアプリケーションを用いたマシンビジョンなどの分野で豊富な経験を持つ。ウィチタ州立大学でBSEE（電気工学学士号）を取得。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
改めて探る、IPベース設計の課題
昨今のSoC設計では、そのフローの大部分をIPの集積作業が占めると言っても過言ではない。それにもかかわらず、IPの選定や集積の作業を自動化するツールはほとんど存在しないし、IPを本当にブラックボックスとして扱うことができているわけではないというのが実情である。IPは、設計作業の抽象度を高めるという役割を本当に果たすことができているのだろうか。
バックエンドのタイミングクロージャー問題の解消法
昨今、チップ設計は複雑性が増し、設計期間は長くなっています。特に、タイミングクロージャー問題が、設計期間を延ばし、最悪の場合、タイミングを収束できずチップ設計自体が中止になる場合があります。そこでチップ開発終盤のタイミングクロージャー問題を回避する方法を提案します。
SoC設計フローの変化
最先端の機器に用いられるようなSoCを設計するためには、最新のEDAツールの適用や、微細な半導体製造プロセスへの対応など、これまでとは異なる設計フローが必要になっている。本稿では、まず、SoCの設計フローに変化をもたらしている要因について説明する。そして、最新のSoC設計の事例を基に、新たなSoCの設計フローで留意すべきポイントについてまとめる。
NoC（Network-on-Chip）こそがSoCである
NoC（Network-on-Chip）とはどのようなものか。これから複数回にわたり考察していきます。
なぜNoCがクロスバースイッチに取って代わったのか
インターコネクト機能として単純なクロスバー方式を採用するという選択もあり得るでしょう。しかしシステム内のエレメントの数が増え始め、さらにエレメント間の距離が意図されたクロック周期に対して長くなってくると、クロスバーではもはやどうにもならず、NoC（Network-on-Chip）方式を採用する必要があります。