シリコン実証済みインターオペラブルPDK SpringSoft社

シリコン実証済みインターオペラブルPDK SpringSoft社

   SpringSoft社、Laker テクニカル・マーケティング・マネージャ、Rich Morse

   TSMC社、デザイン・サービス・マーケティング、副ディレクター、Tom Quan

 

  2009年7月21日に、TSMC社は業界最初のインターオペラブル・プロセス・デザイン・キット(iPDK)のリリースを発表しました。このキットは、TSMC社の65ナノメータ(nm)MS/RFプロセスで完全に認証されており、Cadence社、Ciranova社、Magma社、Mentor社、SpringSoft社、Syonpsys社、その他主要EDAベンダー全てがサポートすることを発表しました。2010年3月24日に、TSMC社がメンバーの一員であるInteroperable PDK Library(IPL) Allianceは、IPL 1.0スタンダードを発表し、業界全体が利用可能なTSMC iPDKの基礎となるテクノロジを作成しました。

 

■PDKの持つ問題
プロセス・デザイン・キット(PDK)という用語は、ファウンダリが提供するPCellライブラリの中で初めて引用されました。それぞれのPDKで、どのデザイン・ルール・チェッキング(DRC)デッキとシミュレーション・モデルを使うべきかという問題が常にあったため、PDKは最終的にカスタムIC設計に必要な文書や設計インフラ要素全てを含むようになりました。現在、主なPDK要素とは、以下のものになります。

・電子設計ルール
・ 様々な種類のシミュレーション・モデル
・ 製造設計ルールや物理的/電子的レイアウトを検証ツール向けDRC/LVSランセット・ファイル
・ レイアウト・ツール向けのスケマティック・シンボル・ライブラリ、パラメータ化されたセル(PCell)、レイヤーマップとテクノロジ(tech)ファイル

 

最近まで、全てのPDKは、特定のファウンダリ、テクノロジ・ノード、プロセスに限定されていたことに加えて、特定のEDAベンダー仕様になっていました。今日、SpringSoft社、Cadence社、Mentor Graphics社をはじめとするカスタムIC設計ツールの主要プロバイダは全て、PDKの共同開発/認証においてTSMC社と協業しています。しかしながら、独占的なPDKが長年に渡って利用できているものの、今日、カスタムIC設計ツールのサプライヤの数は増加し、サポートされるテクノロジの数が増大し続けており、最先端技術向けのPDKはますます複雑になってきています(図1)。より多くのツール、より複雑なプロセスが利用できるようになり、2007年だけで新規/修正版PDKを2,500もリリースしたTSMC社のような大規模ファウンダリにとって、様々な組合せ全てに対するPDKをサポート/認証することは非常に難しい問題になっています。

 

TSMC社にとって、この問題に対する解決策は、サポート問題を軽減し、顧客により多くの選択肢を提供するためにインターオペラブルなPDK(すなわち、複数のベンダー・ツールで直接使用し、同じ結果を出せるPDK)の可能性を探ることでした。この解決策の内の1つが、オープンなPCellインフラを作ることでした。

<図1>

Spring2010-06-01.jpg 
 

■PCellとは何か?
PCellは、アナログやカスタム・デジタル回路設計で使用され、所定の可変パラメータ(図2)に基づいてフィジカル・レイアウトを定義するために使用するソフトウェア・スクリプトです。PCellは、カスタム・デザインのブロックを構成する基礎的要素で、様々なセルを描く代わりに、一つのプログラム可能なPCellで表示します。特定の次元変数(パラメータ)に対して異なる値を置き換えることにより、レイアウト・エンジニアは、ほとんど無限のバリエーションを作ることができます。例えば、1つのNMOSトランジスタに対して1つのPCellは、各特定の配置や"インスタンス"に対するゲート長パラメータを変更するだけで、様々なNMOSデバイスの作成に使用することができます。その後EDAツールは、1つのPCellから、ユーザが手作業で一つの形状を描くことなく、この新しいパラメータを基に正しくサイズ化されたPCellレイアウトを自動的に生成します。

<図2>


Spring2010-06-02.jpg

 

カスタム回路は、PDKで提供されるシンボルを使用して、スケマティック・フォームで設計されます。このシンボルは、関連したデフォルト値を指定した特定のPCellに対応しています。レイアウトを始める前に、回路設計者は、各PCellインスタンスのパラメータ値を、PDKで提供されるシミュレーション・モデルを使ってシミュレーションを行うことで修正することができます。対応するPCellがレイアウトに配置されると、レイアウト・システムによって生成されたレイアウトは、調節された値を自動的に反映し、シミュレーションと一致するシリコン結果を得ることができます。

 

PDK自体と同様に、PCellには、より最先端の機能を可能にする多くのインフラ・サブコンポーネントが必要です。このサブ・コンポーネントには、ストレッチ・ハンドルや自動アバットメント、後でご説明する"コールバック"や"DCFデータベース"用のセパレート・ファイルといった組込み機能が含まれます。
複雑さが企業やアプリケーションによって異なる一方で、PCell機能はPCell開発者がどれほど多くのコードを書くかによって確定/制限されます。PCellは非常に高度な機能を自動化することができ、複雑な相関性を維持し、環境と連動させることができます。TSMC社によって開発された先進的なプロセスでは、デザイン・ルールはますます複雑になり、デバイス内の相関性は互いに非常に影響を受けやすくなっているため、ユーザは世界規模の生産量を可能にするために、ますますTSMC PDKに依存するようになります。先進のPCellアルゴリズムが、他にはない価値をTSMC PDKに与えています。

 

■ソリューションの始まり: 共有データベース
幸いにも、インターオペラブルPDKを実現する上で必要な、多くの作業が既に終了している。最初のソリューション要素は、Cadence社が作成し、2001年頃に標準化団体であるSilicon Integration Initiatie(Si2)(
www.si2.org)に寄付されたOpenAccess(OA)データベースです。現在、OAはカスタムIC設計ツール向けの事実上のスタンダード・データベースになっています。

 

過去、EDA企業は、他のベンダーのツールで読み込むと、大抵の場合若干機能性が低くなるものの、データ変換しなければならない独自のデータベースを開発してきました。今日、Si2 OpenAccess Coalitionには、30以上の主要EDAベンダー企業が所属しており、ユーザとともにこのデータベース・スタンダードの開発、維持で協力しています。OA準拠のEDAツールは、データを変換することなく、また、場合によってはリアルタイムで、同時に使用することができます。

 

■インターオペラブルなPCell
オープンなPCellインフラを実現するために必要な第2の要素は、インターオペラブルなスクリプト言語です。OpenAccessスタンダードは、Tcl、C++、Pythonのような多くのオープンなスタンダード・スクリプト言語にプラグインします。コードが充分にあれば、どの言語を使用してもOAベースのツールで読み込めるPCellを作成することができます。しかしながら、IPLの創立メンバーの一員であるCiranova社には、PyCells™という、インターオペラブルの基礎となる、OpenAccessベースのPython PCellがあります。

 

IPLが設立された時、創設メンバーはEDA企業5社の8種のツールで即座に稼動可能な、"proof-of-concept PCell library"を開発/リリースするために、この新しい技術を利用することで同意しました。これは、既存のテクノロジでインターオペラブルなPCell作成が可能であることを示す上で、非常に説得力のある行為でした。TSMC社はOAとPyCellの可能性を認め、プロトタイプ・プロジェクトを作るために、IPLメンバー・グループと協力することに同意しました。

 

■PyCell
Ciranova社は、オブジェクト指向プログラミング、Pythonプログラマへの対応、迅速な実行時間等、最新機能を備えているため、Tclの代わりにPythonスクリプト言語を使用することに決めました。PyCellは、通常のPCellよりもコードの行がはるかに少ないだけではなく、従来のPCellと比較して、性能も改善されています。また、PyCellは、アバットメント、ストレッチ・ハンドル、DFMルールのような先進機能もサポートします。Ciranova社からダウンロード可能な無償のPyCell Studio™は、PCell開発の生産性と開発期間を改善するために、PyCellの開発と効率的なPyCellデバッギングが可能なインタラクティブな環境を提供する。さらに、PyCell Studioは、カスタマイズ可能でPDKの最先端機能をサポートする、多くのPCell仕様のPython拡張機能をサポートしています。

 

■CDFとは何か?
コンポーネント記述フォーマット(CDF)には、基本的に、PCellのパラメータを表示するパラメータ特性フォーム(図3)の内容が記述され、ユーザは市販のスケマティック/レイアウト・エディッティング・システムを使用して修正を行なうことができます。ソースに関係なく、この非常に基本的な情報のやりとりができるように、全てのツールが共通のシンタクスを使うことが重要です。

<図3>

Spring2010-06-03.jpg 
 
このCDFファイルには、下記のアイテムが格納されています。

・長さ、幅、スペース等のパラメータ名
・ パラメータ特性フォームでパラメータをどのように表示するか、どのパラメータを表示するか、どのパラメータをユーザによる記述を可能にするか。
・ PCell のパラメータのデフォルト値

 

iPDKに最初に格納されたPyCellにはCDFが含まれていて、PyCellのプロパティとしてOAデータベースに保管されています。しかし、シンボルがスケマティックに配置される度に、あるいはPCellが手作業でレイアウトにインスタンス化される度に、パラメータ特性フォームが自動的に開かれ、このCDF情報を表示します。一度シンボルもしくはPCellが配置(インスタンス化)されると、全てのCDF情報とデフォルト値に対する変更が、インスタンスのプロパティとしてOAデータベースに保管されます。後で行ったCDFの値に対する変更は、配置されたインスタンスに自動的には反映されません。また、その逆も同様です。

 

CDFの内容や機能はかなり一般的なもので、全てのツールが同じ、もしくは類似した機能を提供しています。しかし、CDFをインターオペラブルにするためには、全てのIPLメンバーが特定のシンタクスや各条件の定義で同意しなければなりませんでした。IPLスタンダードの他の要素と同様に、Synopsys社は既に"iparams"というCDFに類似したシンタックスの開発を完了しており、後にIPLに寄付しています。 現在、このシンタックスはユーザの混乱を避けるために"iCDF"(インターオペラブルCDF)と呼ばれています。

 

■コールバック
最先端のPCellは、形状間の必要な関連性を維持するために、いくつかの変数に対して、式や機能を代用する("callbacks")ことができます。単純なレベルで、コールバックはX> 0のようなリーガル値の入力をコントロールできるだけでなく、パラメータ特性フォームにイリーガルな値が入力された場合、警告メッセージを出すべきか、あるいは自動的に最もリーガル値に近い値にするといった、ツールが次に取るべきことを定義することもできます。さらに、コールバックは従属パラメータを維持するためにも用いられます。図4の例では、OD(拡散)層を広げることによってポリ・ゲート幅が増加した場合、コールバックがポリ・エンドキャップの大きさを維持し、トランジスタの中心に対称的な変更を行い、十分なスペースがあれば、コンタクトを加えています。

<図4>

Spring2010-06-04.jpg             
 

コールバック機能名は、"フォーム・フィールド・コールバック"と呼ばれ、通常CDFに保存されます。しかし、コールバック自体はPCellのように、TclもしくはPythonのようなスクリプト言語で記述されています。コールバックにPythonを使用しようとする一方で、非常に多くのIPLパートナーが、既にTclコールバック技術に実質的な投資を行っていました。また、既に述べたように、このアライアンスは、最も抵抗を受けずに、かつ成功しやすい手段として、既存の実証済み技術共に歩んでいました。

 

■ストレッチ・ハンドルと自動アバットメント
ストレッチ・ハンドルは、PCellレイアウトで小さなダイヤモンドか正方形で表示され、伸縮自在な形状のエッジを示します。伸縮自在なエッジは、図4にあるように、ゲート長あるいはゲート幅といった特定のパラメータと関連付けされています。ストレッチ・ハンドルによって、ユーザはレイアウト・エディタで印付けされたエッジを、手作業で調節することができます。そうすることによって、この例のコンタクト数のように、適切なコールバックを実行できるように、パラメータ特性フォームで関連パラメータの値を変えることができます。また、従属する基準全てを満たすために、レイアウトをリアルタイムでダイナミックに調節することができます。

自動アバットメントは、接続性を持たされた2つのPCellを自動的に統合する機能を提供します。この機能は、トランジスタの拡散領域を共有するために実行され、レイアウトのサイズを削減します。また、セルも再び2つの別々のトランジスタに分けるため、"アン?アバットメント"される場合があります。

PCellをストレッチやアバットメントするために、Tclファイルにビヘイビアを記述し、PCellスクリプトから呼び出します。

<図5 自動アバットメントAutoabut>

 

Spring2010-06-05.jpg       

■プロジェクトの開始
TSMC社がインターオペラブルなPDKを開発するためにEDAパートナーとチームを組んだ時、PCellの基本的な基盤の多くは既に確立されていました。しかし、このiPDKチームにとって、複雑なPCellライブラリを最先端プロセス上で、理想的に確立され、製造実績のあるPDKとして動作させる現実的なPDK仕様を持つことは、必須条件でした。独自のPCellで開発されたTSMC社の65nmミックスドシグナルRFシングル・ベンダーPDKは、この条件に完全に合致しました。このPDKには、480のPCellがありました。最も複雑なMOSトランジスタには、68のCDFオプションがあり、コールバック機能には、4,000行以上のコードがありました。

 

■IPDKプロジェクト
iPDKプロジェクトの初期段階では、これらのPDK要素全てをテストし、OpenAccess、PyCell、PyCell Studio、iCDFやTclコールバックと一致させました。世界中のオフィスで、様々な企業が進行状況を確認するために毎週ミーティングを開き、TSMC 65nm MS/RF iPDKの作成と認定を行いました。その背後では、標準化を展開し、開発段階で発生した課題を克服するため、全てのツールを調整しなければなりませんでした。

 

最初のコンセプトの実証として、TSMC社はライブラリで最も難しい課題に代表的な2つのMOSfetデバイスを選択しました。この2つのPCellには共に、89のCDFオプションと比較的大量のコールバック・コードがありました。結果を認証するために、全てのパラメータとコールバックを完全に実行したレイアウトを生成し、既存の製造実証済みPDKと比較しました。この過程で、各バージョンのPCell生成には複数のリーガルな方法があり、それを認証する唯一の実際的な方法は、最終的にはライブラリ全体を認証することになるのですが、例えより多くのコード行が必要であっても、既存のPCellにPycellを適合させなければならないということが、明らかになりました。

 

一度、セルが認証されると、TSMC社は、ライブラリのPCellの様々なタイプの内、少なくとも1つを表した93のPCellセットを選択しました。開発の間、従来不可能であった機能のいくつかを既存のPDKに適合させ、PyCellライブラリに追加しました。一旦、93のPCellが認証されると、PyCellライブラリ全体を完成させ、生産価値のあるiPDKを準備する決断が下されました。

 

およそこの時期に、TSMC社は初のファウンダリ・メンバーとしてIPLに加わりました。2008年のDesign Automation Conference(DAC)で、初のマルチベンダー・インターオペラブルPDKが、TSMC iPDK PyCellライブラリの一部と小型低ノイズ・アンプ(LNA)デバイスを使って公開されました。EDAベンダー5社の8つのツールが、データを変換することなく、リアルタイムで設計やレイアウト・データの修正や受け渡しを、実演しました。

 

初のiPDKの適格化には、独自の課題がいくつかありました。全く新しいメソドロジであったため、従来の認証済みシングル・ベンダーPDKよりも、極めて厳密にテストをする必要があったのです。iPDKがあらゆる状況で動作できることを検証するために、パラメータとコールバックのあらゆる組合せ全てをテストする必要がありました。

 

TSMC iPDK検証は、極めて厳密なものでした。最終的な品質テストには、480のPyCellがあり、セルあたり200インスタンス(インダクタ)から200,000インスタンス(MOSfets)にまで渡り、出力データ・サイズが300GB以上になりました。どんなに小さなものでも、各矛盾は解析し、採用もしくは却下しなければなりませんでした。却下された場合、PyCell、CDF、あるいはコールバックを修正し、検証が再び行わなければなりませんでした。最終的に、全てのライブラリが検証されました。

 

一度、1つのツールでiPDKが完全に適格化されると、他のEDAレイアウト・ツールで同じテストが実行され、その結果と最初のツールの適格化済み出力結果の比較が行われました。同じiPDKから実行される場合、XORエラー出力(レイアウトのどんな相違点にもフラグを立てるDRCのようなチェック)は、一貫してエラーのない状態でした。

 

さらにTSMC社は、既存のPDKのCDFやSKILL®コールバックとiPDKのPyCellを一対一で見た場合、iPDKがCadence Virtuoso®プラットフォームで適切に動作することを検証するために、iPDKをテストすることもできました。

 

■世界初の IPDK
完全に適格化されたTSMC 65nmミックスドシグナルRF iPDKは、2009年にDACで発表され、あらゆる主要ベンダーが、このiPDKをサポートすることを発表しました。DACを通じて、TSMC Open Innovation Platformブースと同様に、多くのベンダーでマルチベンダー・インターオペラビリティ・デモンストレーションが紹介されました。

 

TSMC社の統合iPDKは、複数のOpenAccessベースのEDA設計環境で稼動し、複数の独自のPDKは不要となり、異なるカスタムIC設計ツール間で設計データの完全な再利用が可能になります。
TSMC iPDKは、IPLスタンダードに基づいており、IPLスタンダードを保証する上で役立ちました。TSMC iPDKは、Si2のOpenAccessデータベースとデータ・モデルを採用しています。その特徴は、パラメータ化されたレイアウト・セル向けのオープンな標準言語、Tcl及びPython、やコールバックです。iPDKにはまた、現在のOpenAccessベースのPDKとCadence IC6.1環境を互換させるための、SKILLコールバックやコンポーネント記述フォーマット(CDF)ファイルも搭載されています。

 

2010年2月現在、TSMC 65nm iPDKは、ベータ・テスト中で、2010年の第2四半期に一般リリースが予定されています。iPDKを使用して開発された多くのIPブロックが、既にテープ・アウトされ、シリコン・レベルで実証されています。現在、28nmと40nmのiPDKが、iPDK開発チーム・メンバーとTSMC社によって開発中です。

 

インターオペラブルPDKは、全てのTSMCデザイン・チェーンにメリットを提供します。TSMC社の顧客は、複数のEDAベンダー・ツールが最先端機能を提供する、1つの統合インターオペラブルPDKを使用することができ、設計精度を改善し、設計期間を短縮し、設計の再利用を促進することができます。EDAベンダーは、TSMC社の顧客に対して革新的な新しいカスタムIC設計ツールを提供することができます。TSMC社は、サポートするツールの数を拡大すると同時に、PDK開発、認証、サポート、販売コストを削減することができます。協業によるこのようなメリットは、顧客に対して設計投資対効果を向上します。

***

SpringSoft,  SpringSoftのロゴ,それに Lakerは SpringSoft社の商標、もしくは登録商標です。 TSMC社のロゴは TSMC社の登録商標です。その他の商標あるいは登録商標は、各々の所有者の資産です。  

 

お問い合わせ:株式会社スプリングソフト