バックナンバーはこちら

today&tomorrow

Industry Trend

  • T&T HOME
  • Industry Trend
  • マルチレベルの物理階層フロアプランニング―2階層のみのフロアプランニングに対する優位性

2017 Jan Winter vol.105

マルチレベルの物理階層フロアプランニング―2階層のみのフロアプランニングに対する優位性

シノプシス テクニカル・マーケティング・マネージャー Steve Kister

現在のSoCデザインでは、複数の物理階層にまたがる階層型レイアウト・メソドロジが必要です。しかしこれまでのフィジカル設計ツールは一度に2つの物理階層しか扱えないものが多く、レイアウト完了期限までに十分な結果品質(QoR)を達成することができませんでした。シノプシスのIC Compiler™ IIは、マルチレベルの階層を持つデザインも自動で扱うことができます。これにより最短期間で最高の結果品質が得られ、フィジカル設計チームの生産性が最大限に向上します。

本稿では、一度に2つの階層しか扱えないツールが抱える本質的な課題について見た後、マルチレベルの物理階層フロアプランニングが必要とされる理由、そして現在のSoCのフロアプランニングが直面している課題をIC Compiler IIがどのように解決するのかについてご説明します。

大規模で複雑なSoCのフロアプランニングにおける課題

大規模で複雑なSoCデザインは高速化と高機能化が急速に進んでおり、これらデザインのフィジカル・インプリメンテーションは気の遠くなるような作業となっています。現在の設計チームが扱うゲート数は数億に達しており、配置可能インスタンスは数千万を数えます。この複雑さに対処するため、フィジカル設計チームは階層型インプリメンテーション・メソドロジを採用して1個のチップを複数のサブチップに分割して作業しています。このサブチップでさえも規模が大きく複雑すぎる場合は、さらに小さなサブチップに分割します(図1)。現在では1個のデザインをインプリメントするのに3~4、あるいは5つの物理階層を使用するのが当たり前になってきています。

3階層のサブチップに分割したフィジカル・フロアプラン

図1:3階層のサブチップに分割したフィジカル・フロアプラン

現在最先端の非常に大規模で複雑なSoCのフロアプランニングにおいて、一度に2つの物理階層(最上位とブロック)しか扱えないツールを使用していたのではフィジカル・プランニングの実行と管理は困難になる一方です。このようなフィジカル・インプリメンテーション・フローでは、必然的に再帰フローが発生します。するとフローの複雑さが増し、データ管理の負担も増えるため、設計チームの生産性が低下し、設計スケジュールに遅れが生じます。プランニングおよび配置配線ツールがマルチレベルの物理階層プランニングおよびレイアウトを完全にサポートするようになれば設計の生産性と効率が改善し、設計スケジュールを最短に抑えられる可能性が大きく開けます。

一度に2階層しか扱えない再帰的手法の限界

一度に2階層までしか扱えないフィジカル・インプリメンテーション・フローでは、設計チームはブロック形状の設定、各ブロックのピン配置の設定、ブロック・タイミング制約のバジェットを1階層ごとに行う必要があります。この場合、設計チームは上位階層に対して定義した制約のコンテキストで下位階層のプランニングを実行することを余儀なくされ、すべての下位階層のプランニングをフルチップ・デザインのコンテキストで実行するのは非常に困難です(図2)。

マルチレベルの物理フロアプランをいくつかの2階層(最上位とブロック)フロアプランに分割

図2:マルチレベルの物理フロアプランをいくつかの2階層(最上位とブロック)フロアプランに分割

親階層レベルで設定した形状、ピン配置、バジェットが子階層レベルのハード制約となります。下位階層のいずれかのブロックに設計チームが変更を加えると、その変更がデザインの最上位階層に影響します。このような変更に対処するには、ある変更が他の階層にどのように影響するのか、そしてその変更を加えるとどのような作業が余分に発生するのかを考慮する必要があります。こうした変更の1つをインプリメントするプランを作成するだけでも設計チームのメンバー間で多くの交渉が必要で、非常に煩雑な作業となります。このようなやり方ではスケジュールの遅れを招くことがしばしばです。

事実、一度に2階層までしか扱えないフィジカル・インプリメンテーション・フローを採用している設計チームは、設計期間全体の大部分をデータ管理とタスク追跡に費やしています。たとえばデザインの複雑さに対処してメモリ使用量を最小限に抑えるため、ネットリスト・データがあるにもかかわらずある階層の子レベルをブラックボックスに変換することもよく行われます。この場合、面積の要件は経験豊富なエンジニアの勘に頼って決めることが多く、子ブロック内にハード・マクロを配置するために必要な形状やサイズの制約は人手で作成する必要があります。こうしていったん作成したブラックボックス・モデルは、後で実際のネットリスト・データで置き換える必要があります。

カテゴリートップ