メディア

SoC設計フローの変化微細化と最新EDAツールがもたらす(3/3 ページ)

» 2010年10月01日 00時00分 公開
[Ron WilsonEDN]
前のページへ 1|2|3       

合成と検証

 Open-Silicon社、Vitesse社、Redpine社の設計チームにとって、合成のステップは大きな問題にはならなかった。それよりも、このステップにおける作業のやり直しをどのようにして回避するかという点に注意した。

 Open-Silicon社のMadraswala氏は、「RTLコードの各ブロックを、それぞれ独立したチップであるかのように扱った。そして、各ブロックに対し、十分に高い品質で、設計フロー内の各ステップを終えられるように細心の注意を払った。おそらくそれが功を奏して、クロックゲートを挿入した後、たった1度のパスで合成を終えることができた」と述べる。同社は、自社開発の合成ツールを用いてクロックゲートの自動挿入を行った。それ以外には、「アーキテクチャレベルの構成設定によってチップ内の電源管理を行った」(Madraswala氏)。また、「電圧アイランドは存在するが、電源管理についてはRTLコードによって明らかであったため、CPFのようなものは必要なかった」(同氏)という。

 同様に、Vitesse社の設計では、大規模なクロックゲーティングを使用しているものの、パワーゲーティングを適用したブロックは1つしか存在しない。Chadha氏は、「通常の合成ステップで何の問題も生じなかった」と語る。

図2 Redpine社の設計フロー 図2 Redpine社の設計フロー Redpine社の設計フローには、初期段階における電力要件を把握するステップと、後の段階で行う実装確認のステップが存在する。

 他方、Redpine社は、さらに積極的な電源管理を行うための設計を行い、さらに厳しい要件をツールに課した。この要件は、設計フローにも影響を与えた(図2)。Mattela氏は、「理論的には、正しいRTLコードを用意し、電力に関する要件を正確に把握すれば、RTLコード、UPFファイル、省電力ライブラリを入力して合成を行い、アイソレータ、レベルシフター、制御がすべて正しく配置されたネットリストを得ることができるはずだ。しかし、実際には、ボタンを押して合成を実行しても、そのような結果は得られない」と嘆く。構造的にすべてが正しいように見えても、ツールや手作業による詳細な検証を行うと、問題が見つかるケースがあるのだ。

 検証については、合成以上に、新たな要求に適応しているようである。複雑さが増すに連れ、機能検証はさらに初期段階の、より抽象的なレベルから始めるようになってきている。

 Vitesse社のChadha氏は、「当社では、カバレッジベースのOVM(Open Verification Methodology)手法を用いた検証を行った」と述べる。同社は、検証の作業を設計フローの初期段階に行った。まずは、24ポートのスイッチコアと米MIPS Technologies社のプロセッサコアのビヘイビアモデルを用いて実際の信号トラフィックを適用することにより、チップの動作を理解する作業が行われた。その後、詳細部分へと検証の適用個所を広げていき、最終的には、テストベンチを使って、クロックゲーティング回路とアイソレータを配置したゲートレベルのモデルを動作させた。Chadha氏は、「今回の検証ステップでは、要件仕様書に基づいて、具体的な目標を設定した。その目標をコードカバレッジのメトリクスで表し、検証作業の指標とした」と述べる。

 Redpine社のMattela氏によれば、「当社のDVFS設計には、特別な注意が必要だった」という。問題の1つは、信号レベルの不整合によって電圧アイランド間のパスに発生する問題を、ロジックシミュレータでは検出できないことであった。そこでRedpine社の検証技術者は、あるノードを強制的にトライステート出力の状態にして下流の様子を観測するといった、手作業による手法を採用した。またMattela氏は、「ほかにも、使用しているモデルを信頼できないという問題がある」と警告する。同氏は、「電圧が複数存在する状況では、モデルを信用してはならない。モデルを記述したのは、ハードウエア担当の技術者ではなく、1は必ず1で0は必ず0であると考えているソフトウエア担当の技術者かもしれないからだ」と主張する。

物理的設計

 次に、配置、配線、クロージャという物理的設計のステップについて検討する必要がある。このステップではIPの再利用と設計の複雑さの影響は小さくなるが、決して消えるわけではない。そして、半導体製造プロセスの微細化による問題が大きな影響を与える。

 まず、ツールの改良が進み、つい最近まで手作業で行われていた新しい作業の多くが自動的に行われるようになった。これは、多くの設計マネジャらが同意する見解のようである。Open-Silicon社のMadraswala氏は、「当社は、米Synopsys社の自動配置配線ツール『IC Compiler』が備えるDFM機能を利用することにより、微細な半導体製造プロセスを用いる場合に必要になる複雑な設計ルールに対応することができた」と述べる。また、Redpine社のMattela氏も、「数年前は、電源管理の設計については、テープアウトに導くまでのすべてが手作業だった。現在では、特にポストレイアウト検証については、大幅な改善が図られた」という見解を示す。

 その一方で、いくつかの問題も指摘されている。確かに、新しい作業は新しいツールによって対応できるようになったが、新しいツールは問題を伴うことが多いのだ。Vitesse社のChadha氏は、「ポイントツールの一部はまだ成熟していない」と訴える。また、ツールが処理できる設計の規模が小さいことは、さらに大きな問題となっている。Chadha氏は、「設計を分割して、分割したそれぞれの部分に対してツールを適用しなければならない。幸い、今回開発したスイッチング機器用SoCの回路のほとんどの部分は問題なく分割することができた。最も困難だったのは、自動配置配線によってスイッチを構築する作業だった」と説明する。

 Madraswala氏も、ツールの配置配線の能力に限界があると見ている。「IC CompilerのDFM機能をオンにすると、設計の規模が限定される。われわれの場合、配置可能なインスタンスが約40万個に限定されたので、非常に小さな単位で、ゲート数が1億個の設計を構築していかなければならなかった」と同氏は述べる。

 配置配線ツールの問題は、その能力の限界だけにとどまらない。最新の配線ツールはタイミングを認識する。つまり、すべての配線に対する最良の経路を検出するのではなく、設計のタイミング制約を読み込み、すべての配線におけるタイミングを満たすように処理を実行する。この処理を行うには、ツールが提案する経路の遅延を見積もる必要がある。つまり、その経路の容量値を見積もる必要があるわけだ。従って、最新の配線ツールは、使いものにならないほど時間を浪費するおそれのあるサインオフ用抽出ツールか、ツールに内蔵された“応急処置的な”抽出エスティメータを呼び出すことになる。65nmクラスの微細プロセスを利用するとしたら、寄生容量を抽出するのに、膨大な時間を要する複雑な処理を行わなければならなくなる。手っ取り早く近似値を得る既知の方法は存在しないのだ。Madraswala氏は、「IC Compilerと現実との間には大きな相違がある」と嘆息する。

 Chadha氏はさらに手厳しい。同氏は、具体的な配置配線ツールの名称を明らかにはしなかったが、「ツールによる容量値の見積もりはあまり正確ではない。また、われわれが使用したツールは、かなり迂回するような配線を生成したため、設計フローを後戻りして配線し直さなければならなかった」と強調する。

 タイミングの見積もりの問題は、EDAベンダーに苦しい選択を迫る。配線ツールの内蔵機能による容量値の高速な見積もりが正しくない場合、設計者は、抽出、タイミング調整、再配線という繰り返し作業を行わなければならなくなる。一方、配線ツールがサインオフ用の抽出ツールやタイミングツールを呼び出す場合には、実行時間と能力の限界の問題が生じる。サインオフ用の抽出ツールやタイミングツールは、微細な半導体製造プロセスのジオメトリのあらゆる影響に対処しなければならないことから、複雑な処理を行うためである。

 米Cadence Design Systems社とSynopsys社はそれぞれ、予備的な配置とタイミングの見積もりを、設計フロー上流の合成ステップで行うという第3の手法を発表した。見積もりの精度が高くなるわけではないが、配線ツールが誤った見積もりや配線を行うようなネットリストを、合成ツールが生成しないようにしたいというのが、両社の狙いである。

 配線ツールと設計ルールに関しても同様の問題が存在する。配線ツールが設計ルールに従わない場合、最終的なファイルには多くのルール違反が生じてしまう。従って、配線ツールはLEF(Layout Exchange Format)ファイルを参照し、配線がそれに従っていることを確認しながら処理を進める。この手法は、65nmプロセスを用いたデジタル回路では有効なようである。しかし、Mentor社のMadhani氏は、「LEFは、ピンチルールなど、微細な製造プロセスで用いられている一部の設計ルールを表現することができない」と警告する。そのため、Mentor社は、同社の配線ツール「Olympus」の実行時に、DRC(Design Rule Check)のためのサインオフツール「Calibre」を呼び出すようにしている。この場合も、処理速度が犠牲となるが、誤りが生じるよりは遅いほうがましというわけだ。

 意外かもしれないが、上記すべての作業をフロントエンド設計で実施しても、電源ドメインとサードパーティIPの問題は、バックエンド設計にも影響を与える。ASICベンダーである台湾Global Unichip社のマーケティング担当ディレクタを務めるKeh-Ching Huang氏は、「電源ドメインが複数存在すると、クロージャが複雑になる可能性がある。それらに対しては、手作業による処理と手入力のスクリプトを用いる必要が出てくる」と述べる。「IPの選択もクロージャのステップに影響を与える。例えば、顧客が低速なDDR(Double Data Rate)インターフェースを使用する場合、通常はソフトウエアで提供されるIPブロックを合成しなければならない。この場合、ブロック内にはタイミングクロージャの問題が存在する可能性がある。一方、顧客が高速なDDRインターフェースを利用する場合、それはハードウエアIPとしてライセンス提供されるので、クロージャの処理はまったく異なるものとなる。問題が存在する場合、その原因は通常ハードウエアIPにある」(Huang氏)という。とはいえ、主にサードパーティのIPで構成される設計が、設計クロージャの複雑さに与える影響については、まだあまり探究されていないというのが実情だ。

 最後に、新たな設計環境がアナログ設計に影響を与えるという問題がある。Vitesse社は、同社の既存の銅線用PHYを、低消費電力のものに再設計して利用した。その再設計の作業において、同社のアナログ設計者は、65nmプロセスのレイアウトに起因する新たな問題に遭遇した。Chadha氏は、「ウェル近接効果とドレイン配置がデバイスの性能に与える影響について学んだ。デバイスのモデルは、これらの効果を適切に表現したが、それでも、回路を期待どおりに動作させるためには、レイアウトからの抽出処理を繰り返す必要があった」と述べる。

問題が起きるのは新たな部分

 今日のSoC設計において、特に長い配線や、複雑なクロック/電源管理を扱う場合には、事前の計画が重要である。検証に関する計画を事前に行うことも必須だ。設計チームは、合成ツールで多くの処理が行われていることを理解する必要がある。このステップは、もはやVerilogステートメントを単純にスタンダードセルに置換するというものではない。特に、ゲーティドクロックツリーやスキャンチェーンを用いたテスト回路といった細心の注意を要する構造を配置した後には、合成ツールにおける繰り返し処理の回数が最少となるように計画を立てなければならない。また、設計チームは、積極的な電源管理を行うことによって検証が非常に複雑になる可能性があることを理解しておく必要がある。つまり、電源管理の設計指針として、複雑なものよりも体系的なものを選択するほうがよいかもしれないということだ。

 そして、物理設計とクロージャはますます難しくなっている。有効なフロントエンドツールを選択したり、スクリプトを作成したりして、早い段階で配線混雑の問題を取り除く必要がある。また、配線ツールとサインオフツールの結果はおそらく一致しないため、両ツールの間で処理を繰り返すことを計画に含めておく。

 基本的な構造は、これまでの設計フローと変わらない。しかし、問題が起きるのは新たな部分である。Open-Silicon社のMadraswala氏は、「当社の設計フローの60%以上は、これまでと同じステップだった。残りの約30〜40%が65nmプロセスに特有のものであり、問題の大部分はこれらのステップで生じた」と述べている。

前のページへ 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.